Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
1.2 Requirements Pyramid
Depending on the format, source, and common characteristics, the requirements can be split into different requirement types. Here are some requirement types that are often used in projects:
- Stakeholder need: a requirement from a stakeholder
- Feature: a service provided by the system, usually formulated by a business analyst; a purpose of a feature is to fulfill a stakeholder need
- Use case: a description of system behavior in terms of sequences of actions
- Supplementary requirement: another requirement (usually nonfunctional) that cannot be captured in use cases
- Test case: a specification of test inputs, execution conditions, and expected results
- Scenario: a specific sequence of actions; a specific path through a use case
These requirement types can be presented in the form of a pyramid, as shown in Figure 1.1.
)
Figure 1.1 The requirements pyramid.
At the top level are stakeholder needs. On the lower levels are features, use cases, and supplementary requirements. Quite often, at different levels of these requirements, different levels of detail are captured. The lower the level, the more detailed the requirement. For example, a need might be “Data should be persistent.” The feature can refine this requirement to be “System should use a relational database.” On the supplementary specification level, the requirement is even more specific: “System should use Oracle 9i database.” The further down, the more detailed the requirement. One of the best practices of requirements management is to have at least two different levels of requirement abstraction. For example, the Vision contains high-level requirements (features), and the lower levels in the pyramid express the requirements at a detailed level. Senior stakeholders (such as vice presidents) do not have time to read 200 pages of detailed requirements but should be expected to read a 12-page Vision document.
However, it is up to business analysts to decide on the granularity of requirements at each level. Nothing is wrong with placing quite detailed requirements from stakeholders on the stakeholder needs level.
The main difference between needs and features is in the source of the requirement. Needs come from stakeholders, and features are formulated by business analysts.
The role of test cases is to check if use cases and supplementary requirements are implemented correctly. Scenarios help derive use cases from test cases and facilitate the design and implementation of specific paths through use cases. In RequisitePro we can define many other requirement types, such as glossary terms and actors. They are not pure requirements conforming to the definition provided at the beginning of this chapter, but if we represent them in RequisitePro as requirements, we gain flexibility to track their attributes and traceability using same mechanisms that are provided for other requirement types.