This project is read-only.

Chapter 5 - System Requirements Model

The process of accepting a software-intensive system is inherently dependent on the system tested and the test cases used. Your test cases are designed to test for specific requirements. Therefore before designing your test cases it is imperative you know the requirements that they are intended to test.

Requirements and Acceptance

The acceptance of a software-intensive system is clearly related to whether it meets the requirements. Assessing whether it meets the requirements involves the process of testing the software using test cases that are in some way related to the requirements. Therefore, requirements are an important component of the acceptance process even if they are not directly a testing-related artifact.
The term ”requirements“ is somewhat contentious. Some people believe that you merely need to talk to potential users and ask them for their requirements. Frequently, this is referred to as requirements elicitation or requirements gathering. This is illustrated in Figure 1.
Figure 1
Figure 1 Gathering Requirements directly from users
In Figure 1 we see the requirements from the users being translated directly into product by the product development team. In effect, the requirements become the coarse-grained work items for the product development team. In iterative and incremental processes, the product is built one requirement at a time, indicated here by the lines within the product. There may be an opportunity for users to provide feedback on one version of the product before additional requirements are implemented.
Some people believe that requirements cannot be gathered like strawberries or mushrooms; instead, they believe requirements must be based on the definition of a product that is designed to meet the potential users' needs. This guide summarizes this process as product design which acts as a placeholder for a wide range of activities that may involve specialized product design skills. This process is illustrated in Figure 2. For a serious treatment of the topics of product design and experience design see [HSPK] as well as effective low-fidelity product experience design techniques by [BuxtonOnDesignForUsability].
Figure 2
Figure 2 Getting Requirements via Product Design
In Figure 2 we see the user requirements being augmented with observations from researchers. These observations and requirements are input into the product design process executed by the product design team which may be the development team or a separate group of specialists. The resulting product design (often externalized in the form of prototypes) is then tested with potential users to find out how well it satisfies the users needs. The test results are then incorporated into the product design. Several refinement cycles may take place. The actual construction of the product is based on the results of this feedback. In iterative and incremental processes, the product is built one requirement at a time, indicated here by the lines within the product. There may be an opportunity for users to provide feedback on one version of the product before additional requirements are implemented.
The product design approach involves explicit activities to validate that the requirements truly satisfy the needs of the users. This validation can be done as part of an acceptance testing phase, but that is rather late to discover that what you built is going to require significant changes before it will meet the users' needs. Therefore, we advocate acceptance testing of the proposed product design (not the software design) before the software is built. Techniques such as experience sketching [BuxtonOnDesignForUsability], paper prototyping and Wizard of Oz testing [GouldLewisOnDesignForUsability] can be used to verify that you are "building the right system" very early in the project while there is still time to adjust the product design. For information about these techniques, see the Usability Testing thumbnail in Volume IV.

Types of Requirements

The requirements, however derived, are typically divided into two broad categories, functional requirements and non-functional requirements (also known as para-functional requirements, extra-functional requirements, system attributes or quality attributes.) Functional requirements describe the functionality to be provided to users or administrators of the software-intensive system. Non-functional requirements transcend the functionality. The relationship between the two kinds of requirements is illustrated in Figure 3.
Figure 3
Figure 3 Functional vs. non-functional requirements
Different techniques are used for describing the various kinds of requirements and for verifying that those requirements are met.

Functional Requirements

Functional requirements describe how various types of users expect the system to help them do their jobs. The functional requirements, whether explored and gathered directly or derived from a product design, can be organized and communicated a number of different ways, including the following:r
  • Business processes
  • Use cases
  • User stories
  • Business rules
  • Subsystems
  • Feature lists
  • Scenarios
  • Protocol specifications
  • Functional specifications
  • State models
Figure 4 illustrates a very high level system requirement model that includes business workflow tying together several use cases. The requirements include the need to interact with System 4 as part of some of the use cases. It also requires Systems 1, 2 and 3 to exchange information created or modified during the workflow.r
Figure 4
Figure 4 Requirements involving Users, Use Cases and User Stories
This guide highlights a small set of popular requirements practices (see Volume II). They are used to illustrate how the requirements practices and artifacts are related to the tests you may use during acceptance of a software-intensive system. The User Modeling activity is used to capture salient information about the users of the software. It can help the product development team understand the requirements better by understanding how the users think and what motivates their behavior. Use Case Modeling is used to capture what the users want the system to help them achieve. Each use case describes one kind of interaction (e.g. transaction) between a user and the system. A use case typically requires many test cases but often cannot be tested without testing other use cases. User Stories are used to break the functionality of the system into very small but still useful and testable chunks that can be built in just a few days or weeks. They are typically much smaller than use cases but may span 2 or more use cases. They might describe a business rule or even just one scenario of an inter-system communication. User stories map to one or more test cases.
These requirements activities and artifacts help us understand the types of tests we may need to execute to gather the data on which the acceptance decision is made.

Non-functiona Requirements

Non-functional requirements are requirements that describe general qualities or behaviors of the system that span specific usage scenarios. Frequently, these requirements are traced back to protection of various stakeholders who may or may not be users of the system in question.
Unlike functional requirements, which vary greatly from system to system, there is a fairly standard list of types of non-functional requirements. Many of these requirements end with the suffix "ility" because they describe characteristics the whole system needs to support either while it is in use or as part of its overall system life cycle.
Requirements that the system needs to satisfy while it is operating include:
  • Availability – When does the system need to be available for use?
  • Data Integrity –The data needs to be stored and processed in a way that it can be reliably retrieved without changing its original value.
  • Safety – The system should not cause physical or emotional harm to a user or stakeholder.
  • Recoverability – When it fails, the system should restore its previous state without undue hardship to the users or supporters of platform.
  • Accessibility – People with diverse limitations should be able to use the system. It may need to conform to standards like those stated by the ADA or other regulatory or standards bodies.
  • Supportability – It should be economical to provide support to users of the product.
  • Reliability –It should work well and resist failure in all situations.
  • Robustness – It should take abuse and still function (fault tolerance).
  • Performance – What speed or throughput benchmarks does it need to meet? Performance includes response time: the system should respond to user actions and requests in a timely manner.
  • Usability – It should be easy to use by its intended users.
  • Installability – The product should be easy to install onto a target platform. This is sometimes part of usability.
  • Security –The product should protect against unauthorized use or intrusion.
  • Scalability – The product should be capable of being scaled up or down to accommodate more users or transactions.
  • Compatibility – With what external components and configurations does it need to work?
Requirements related to the total cost of ownership or product life cycle include:
  • Testability – In what ways should the product be testable?
  • Maintainability – How easy should it be to evolve, fix, or enhance the product?
  • Portability – How easy should it be to port or reuse the technology elsewhere?
  • Localizability – How economical will it be to publish the product in another language?
  • Reusability – How easily can source code (e.g. classes, functions,etc.) be used in other circumstances?
  • Extensibility – How economical should it be to enhance the product with other features and add-ons?
  • Configurability – How easy should it be to prepare the product to be used on a variety of different platforms or for slightly different uses and operations?
The preceding list of types of non-functional requirements is not intended to be exhaustive. It also is not intended to be universal; some of these requirements may be irrelevant for some software-intensive systems. Part of the art of requirements gathering or engineering is deciding which ones are important and which ones are not. Those that are important need to be made explicit and incorporated into the test plans; those that are not important can probably be ignored (but the risk of ignoring them should be assessed before doing so.)
Most of the non-functional requirements cut across the use cases of the system. That is, they apply to many, if not all, of the discrete chunks of functionality described in the functional requirements. Note that some forms of non-functional requirements can be described at least partially in functional terms; security is a good example. You can say that User Role X should be prevented from changing the value of field F on screen S.
The key to testing conformance with non-functional requirements is the classification of each of these requirements indicating to what degree the project stakeholders care about the requirement. For example, for an application one builds for one’s personal use, one may not care about scalability because there will be only one user, but on a large e-commerce application, scalability is very important. It is worth reviewing this list of non-functional requirements and consciously deciding how important each one is to the success of your product or project. The following table lists the goals, importance, and rationale of a variety of non-functional attributes for a specific hypothetical system.
Attribute Goal Importance Rationale
Web site performance under load Less than 500 milliseconds response time High Major source of revenue
Web server capacity under load At least 300 transactions per second. Graceful degradation under load Medium Large number of users
Reliability/availability 7x24x52 Critical Users require instant satisfaction when worried about their money
Usability Easily discoverable High Most users will use infrequently

Appendix X in Volume IV – Testing Activities & Responsibilities is an example of a checklist that can be used to record these decisions.


In order to be able to do a good job of readiness assessment and acceptance testing, the targets (requirements) must be clear. Readiness assessment and acceptance testing are driven by the question "how will we know we are done?" As such, they should ideally start early in the project .
The readiness assessment and acceptance testing activities gather data about how well the system satisfies the requirements. The requirements include both functional and non-functional requirements. There are a number of alternative ways to decompose the requirements into manageable chunks. Some forms of requirements map more directly to test cases than others.

What’s Next?

Things can and do go wrong when building software-intensive systems. Commonly occurring problems include misunderstood requirements and failure to meet non-functional requirements. The next chapter describes techniques for identifying what might go wrong and planning readiness assessment and acceptance testing activities that would discover them as early as possible.


[HSPK] Hendrik Schifferstein, Paul Hekkert (Eds.) Product Experience. Elsevier, 2008.
[BuxtonOnDesignForUsability] Bill Buxton. Sketching User Experiences: Getting the Design Right and the Right Design. Mogran Kauffman, 2007.
[GouldLewisonDesignForUsability] Gould, J.D. and C. Lewis, “Designing for Usability – Key Principles and What Designers Think”, in Proc. of ACM CHI’83 Conference on Human Factors in Computing Systems. p. 50-53, 1983.

Last edited Nov 5, 2009 at 8:29 PM by rburte, version 2


No comments yet.