Quality attributes, or the nonfunctional requirements as they are also known, have a huge effect on software. Sadly, very often they are not properly documented or even understood. This article continues the introduction to designing software architectures with a look at what quality attributes are, how they're documented, and how they can assist you in your work as an architect.
Last month's column focused on the making of an ideal requirements specification, including an introduction to writing and diagramming use cases. Because use cases mostly focus on functional requirements, I only briefly mentioned quality attributes, which are equally as important to the design and development of sound software, but far less commonly understood.
Many developers make the mistake of thinking that quality attributes are somewhat superfluous, being not as critical to the end product as functional requirements. As a result, quality attributes are sometimes embedded in use cases as adjectives such as easy or reliable. This not only makes the attributes difficult to locate for later review, it can also lead to loss of meaning; the attribute being poorly described by a single adjective.
While quality attributes seem a rather hazy concept to many developers, the fact is that their utility is increased manifold by an emphasis on measurability. The more concrete and measurable you make your quality attributes, the more positive an impact they'll have on your development process and the end product.
In this month's column, I'll show you how to transform some of the most commonly used, abstract quality attributes into ones that are more concrete and measurable.
Usability, reliability, performance
These are the three big concerns when it comes to defining quality attributes. Unfortunately, none of these terms stands on its own as a sufficient development guideline. Rather than simply embedding the requirement that the application should be "usable" into your use case, try documenting usability requirements separately and concretely.
For example, training time is a crucial factor in the usability of most applications. Minimizing the time it takes users to comfortably use your application greatly improves its prospects. Because training time is measurable, you could write a requirement that the user must be able to start using the system in 15 minutes or less.
Time to completion is another important, measurable usability requirement, especially for Web applications. While a typical quality attribute might declare that adding an item to the shopping cart should be "easy," a better one would stipulate that it happen in just one mouse click. Similarly, rather than say that the user's selection-to-purchase time should be "short" you might write a more clear attribute, such as "Ordering and paying should take no more than 5 minutes."
Reliability is another crucial characteristic that is often far too loosely defined. Rather than assume that you and every other member of your team understand what is meant by this term, try breaking it down to some measurable limits. For example, rather than the entire team working to ensure that downtime is "minimized," why not state that the downtime should be only 0.5% of the running time. Not only does this give the team a clear standard to work to, but it could prove a useful marketing tool after the application is released.
Measures like Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) are also very useful when it comes to defining system reliability. MTBF tells how much time (in hours, weeks, months) must pass between system failures. MTTR specifies how long the system is allowed to be out of use (that is, unrepaired) following a failure. A good MTBF for a Web site might be "over two weeks" but for an elevator it would likely be "under 15 minutes."
Accuracy is another important and measurable factor in reliability, especially if your application's tasks include calculation, measurement, or estimation. For example, a requirement for traffic control software might be that the software must count the volume of cars per hour with an error limit of five cars.
Nobody likes to wait, especially not for common, repetitive, and necessary computing tasks. With performance it is important to set your design goals carefully, with the focus on the right target. The most frequently used operations must be fast, while rarely used ones (like back-up, import/export, and so on) can take more time. Eighty percent of a typical, high-performance application's usage is targeted to 20 percent of its functionality (or 90 percent to 10 percent, depending on whose rule you're using). Keep this in mind the next time you're trying create the fastest back-up function for Web mail.
As with the other big-three quality attributes mentioned here, performance attributes can and should be measurable. Response time is a concrete performance measurement that will have particular impact if you're designing graphics-intensive Web applications. When defining response time for Web applications, don't forget to calculate for the effects of connection speed. The specified response time for an office application on a LAN could be set to maximum 1 second, but on a dialup it might need to be extended.
Throughput is another concrete performance measurement. For example, you could state that your Web application must be able to handle 100 transactions per second. (Like connection speed, this measurement is impacted by hardware considerations; but it's a good starting point for the development team.)
Capacity is a third performance attribute that can have a profound impact on your system design. Defining the number of transactions or customers your system can accommodate at one time gives your team a real-world capacity to design, build, and test for.
Support, maintenance, security
The three attributes under this heading are typically less visible to users (at least until they need them) but can make a big difference to the reputation and long-term success of your company.
While most applications are developed with some notion of support and maintenance, it is rare to see these factors documented. Thinking in advance about the impact of factors such as coding standards, naming conventions, the use of third-party libraries, and so on, is a good way to ensure that your application will be easy (or easier) to support and maintain over the long term. Established coding standards and naming conventions can be particularly helpful on large-scale projects, where leaving each developer to his or her own style could result in a confusing, difficult-to-maintain code tangle.
When it comes to third-party class libraries, the most important consideration is for the future -- if you can't be sure that the library will be supported in the future, then try to acquire the source for yourself. You also want to make sure that you have good version control if and when there are new versions of the class libraries.
Customer support is an important aspect of support and maintenance, so think early on about the kinds of problems your users can be expected to encounter, the tools and information you will need to provide them with, and the type of support framework you can most feasibly do it in. Obviously, the support framework for a twenty-four/seven online banking application is quite different from the one for a stand-alone text-editing or games application.
Confidentiality, integrity, and availability are the three musts of application security. Confidentiality is the requirement that data and processes be protected from unauthorized disclosure. Integrity is the requirement that data and processes be protected from unauthorized modification. Availability is the requirement that data and processes be protected from denial of service to authorized users. The measurable aspects of these requirements should be based, in part, on the type of application you're developing: the requirements for an online banking application are quite different from those for an educational classroom booking system.
Constraints, standards, legal issues
Getting even further away from the visible (to users) aspects of the application, and even deeper into its foundation, you should consider how you want to deal with the impact of design constraints, applicable standards, and legal issues on your application. For example, most companies have certain constraints related to software development and software environments. Examples of such constraints are programming languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, and so on.
If these constraints are imposed from outside, such as by company policy or by the client, they can be frustrating to work with; but that doesn't make them any more flexible. Even if you believe the project would be easier, more efficient, or more ultimately successful if it were based on a different technology or process, you'll do yourself and the project no good by dwelling on it. Accounting for these constraints early on, and then maximizing for them, will better ensure the success of your process.
On the flipside of design constraints are applicable standards, which can often make your development process easier or more successful. Applicable standards can include legal and regulatory standards as well as industry standards for such issues as usability, interoperability, internationalization, operating system compliance, and so on. They're usually well documented and include descriptions of common or important issues. Applying them is one way to avoid re-inventing the wheel.
Your application can be affected by many kinds of legal issues, particularly those pertaining to contracts and software licenses. Make sure your quality attributes include some attention to the details of disclaimers, warranties, copyright notices, patent notices, trademarks, and logo-compliance issues. And make sure you have qualified legal assistance (that is, a lawyer) to ensure the soundness of your decisions.
Defining quality attributes is an often underestimated part of the software design and development process. As I've shown you this month, most commonly used quality attributes can be easily redefined for greater utility, simply by placing more emphasis on what is most concrete, measurable, and actionable about them. Learning to think of quality issues in this way will improve your design process immeasurably. It will give your development team concrete goals to work toward. And it will make your final product far more robust, from the inside out.
That's it for this month's column. Tune in again next month for further discussion about designing software architectures!
- See Mikko's
Designing software architectures, Part 1 (developerWorks, October 2004) for an overview of the architectural design process.>
- Designing software architectures, Part 2 (developerWorks, November 2004) continues the series with a look at the role of the architect.
- In
Designing software architectures, Part 3 (developerWorks, December 2004), Mikko explains the essential qualities of a requirements specification and shows how to write and document use cases.
- The Carnegie-Mellon Software Engineering Institute hosts many valuable articles about software design, including one that specifically addresses the
importance of quality attributes.
- "Supporting Iterative Development Through Requirements Management" (The Rational Edge, January 2004) is an in-depth look at how requirements are established and managed throughout an RUP development life cycle.
- Granville Miller's UML modeling workbook (developerWorks, May 2001 through June 2002) is a hands-on introduction to use case development and the Unified Modeling Language.
- "
Documenting software architectures" (The Rational Edge, January 2004) is one architect's account of the importance of good documentation in large-scale development projects -- as well as a review of a book worth reading.
- "Reference Architecture: The Best of Best Practices" (The Rational Edge, January 2004) is an excellent discussion of the benefits of RUP in software design and development.
- "Risk
reduction with the RUP phase plan" The Rational Edge,
September 2003) is a more example-driven look at how RUP works in a
real-world software development project.
- Don't miss a single installment of Mikko's Architectural manifesto column! See the column series page for a
complete listing of previous installments in this series.
Mikko Kontio works as a Technology Manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in Computer Science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at mikko.kontio@softera.fi.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
