8.2 Tracing Back to Nonfunctionals

Although traceability tends to focus mostly on use cases, other types of software requirements must be traceable into the development lifecycle. Nonfunctionals have traceability that is unique from use cases, but just as important in their own way.

If use cases are the major application traceable requirements , nonfunctionals are the major architecture traceable requirements . Nonfunctionals provide the scope for the architectural needs of the software.

In order to delve into how nonfunctionals provide a basis for software architecture, it is worthwhile now to describe some aspects of architecture. Software architecture is the underlying structure of software application(s). This underlying structure includes how the applications are divided into components (called the component architecture ), and the common set of services (security, navigation, transaction handling, and so on) that many parts of the application need (called the architectural framework ).

The architecture is created to ensure the quality of the way the application responds to the demands made of it by its users. The architecture does not usually provide functions or features itself; instead it makes those functions and features better: faster, more secure, with higher availability, and so on.

Nonfunctionals provide direction for the architecture because they specify how fast, how secure, and how available the application must be to fulfill the business needs. If a nonfunctional requirement states that a software application must have 24 x 7 availability 99.999% of the time, this is a very strenuous requirement. An architect may need to construct a fairly heavy-duty architecture to comply with this architecture, including multiple failover servers, complex load-balancing software to balance the load between the servers, and several other methods of quick recovery from component failures. This will cost a lot of money to design, purchase, construct, and test the hardware and software components.

Businesspeople seem to have an interesting relationship with nonfunctional requirements. With features, and therefore use cases, they seem to understand and appreciate that each one costs money. Nonfunctionals, however, are often viewed by businesspeople as "free of charge." They see a Microsoft Access application that has the features they need and expect it to scale to a thousand- user base without a problem! However, we know that these nonfunctional requirements cost money, often a lot of money. We like to tell our business stakeholders that if they want infinite availability (true 24 x 7) it will cost infinitely . The same is true for any other nonfunctional.

Similarly, the way a software architecture is tested is by creating load/stress test cases based on the nonfunctionals. Perhaps a nonfunctional states that the software must handle a load of 500 users while consistently providing a response time of less than 3 seconds per interaction. The test team can create a set of test cases to simulate this condition, probably using a load testing tool like Mercury Interactive LoadRunner to create virtual users to load the servers as if 500 people were accessing it simultaneously .

Nonfunctional requirements also help provide input to software architects to understand the architectural patterns they may want to use. Some examples of architectural patterns include data-centered, repository, blackboard, pipes-and-filters, publish-and-subscribe , rules engine, and so on. These patterns are described in the book Software Architecture in Practice (Bass 1998).

We cannot provide a guide to translating nonfunctional requirements to architectural patterns. The book we've mentioned has some insights into this art (not science), but for the most part the task simply requires an experienced software architect or talented architecture mentors.

From a product marketing perspective, nonfunctionals play an important role. In a market where several products provide similar functions, nonfunctionals may be the key to winning market share. For instance, if several data translation tools offer the same functions (use cases), the winner may be the one who does it fastest , most securely, or can operate in a multithreaded mode.