Best Practice: Manage Requirements
- What is Requirements Management?
- How is Development Driven by Use Cases?
Requirements management is a systematic approach to finding, documenting, organizing, and tracking a system’s changing requirements.
We define a requirement as “a condition or capability to which the system must conform”.
We formally define requirements management as a systematic approach to both:
- eliciting, organizing, and documenting the requirements of the system
- establishing and maintaining agreement between the customer and the project team on the system’s changing requirements
Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes and traceability to other requirements and other project artifacts.
Collecting requirements may sound like a rather straightforward task. In reality, however, projects run into difficulties for the following reasons:
- Requirements are not always obvious, and can come from many sources.
- Requirements are not always easily or clearly expressed in words.
- There are many different types of requirements at different levels of detail.
- The number of requirements can become unmanageable if they’re not controlled.
- Requirements are related to one another and also to other deliverables of the software engineering process.
- Requirements have unique properties or property values. For example, they are not necessarily equally important nor equally easy to meet.
- There are many interested parties, which means requirements need to be managed by cross-functional groups of people.
- Requirements change.
So, what skills do you need to develop in your organization to help you manage these difficulties? We’ve learned that the following skills are important to master:
Analyzing the problem
Problems are analyzed to understand problems and initial stakeholder needs, and to propose high-level solutions. It’s an act of reasoning and analysis to find “the problem behind the problem”. During problem analysis, agreement is gained on what the real problems are and on who the stakeholders are. From a business perspective you also define the boundaries of the solution and any business constraints on the solution. The business case for the project must also be analyzed so there is a good understanding of what return is expected on the investment made in the system being built.
Understanding the problem
Requirements come from many sources; for example, customers, partners, end users, and domain experts. You need to know how to determine what the best sources should be, how to access those sources, and how to elicit information from them most effectively. The individuals who provide the primary sources for this information are referred to as stakeholders in the project.
If you’re developing an information system to be used internally within your company, you may include people with end-user experience and business domain expertise in your development team. Very often you will start the discussions at a business model level rather than at a system level. If you’re developing a product to be sold to a specific marketplace, you may make extensive use of your marketing people to better understand the needs of customers in that market.
Elicitation activities may occur using techniques such as interviews, brainstorming, conceptual prototyping, questionnaires, and competitive analysis. The result of the elicitation is a list of requests or needs that are described textually and graphically, and that have been given priority relative to one another.
See the Workflow Detail: Understand the problem for further details on this topic.
Defining the system
Defining the system means translating and organizing the understanding of stakeholder needs into a meaningful description of the system to be built. Early in system definition, decisions are made about what constitutes a requirement, documentation format, language formality, degree of requirements specificity (how many and in what detail), request priority and estimated effort (two very different valuations usually determined by different people in separate exercises), technical and management risks, and initial scope. Part of this activity may include early prototypes and design models directly related to the most important stakeholder requests. The outcome of system definition is a description of the system that uses both natural language and graphical representations.
See the Workflow Detail: Define the System in the Requirements discipline for more details on this topic.
Managing the scope of the project
To efficiently run a project, you need to carefully prioritize the requirements based on input from all stakeholders and manage its scope. Too many projects suffer from developers working on so called “Easter eggs” (features the developer finds interesting and challenging), rather than early focusing on tasks that mitigate a risk to the project or stabilize the architecture of the application. Make sure that you resolve or mitigate risks in a project as early as possible, by developing your system incrementally, carefully choosing requirements for each increment that mitigates known risks in the project. This means you need to negotiate the scope of each iteration with the project’s stakeholders. Typically this requires good skills in managing expectations of the output from the project in its different phases. You also need to control the sources of the requirements, how the deliverables of the project look, as well as the development process itself.
Refining the system definition
The detailed definition of the system needs to be presented in such a way that your stakeholders can understand, agree to, and sign off on them. It needs to cover not only functionality, but also compliance with any legal or regulatory requirements, usability, reliability, performance, supportability, and maintainability. A frequent error is believing that what you feel is complex to build, needs to have a complex definition. This leads to difficulties in explaining the purpose of the project and the system. People may be impressed, but they will not give good input because they don’t understand. Special attention needs to be given to understanding the audience for whom the artifacts are being produced; often, different kinds of description are needed for different audiences.
We have seen that the use-case methodology, often in combination with simple visual prototypes, is a very efficient way of communicating the purpose and defining the details of the system. Use cases help put requirements into a context; they tell a story of how the system will be used.
Another component of the detailed definition of the system is to state how the system should be tested. Test plans and definitions of what tests to perform tell us what system capabilities will be verified.
Managing changing requirements
No matter how carefully you’ve defined your requirements, there will always be things that change. What makes changing requirements complex to manage is not only that a changed requirement means that time has to be spent on implementing a particular new feature, but also that a change to one requirement may have an impact on other requirements. You need to make sure that you give your requirements a structure that is resilient to changes, and you need to use traceability links to represent dependencies between requirements and other artifacts of the development lifecycle. Managing change includes such activities as establishing a baseline, determining which dependencies are important to trace, establishing traceability between related items, and implementing change control.
How is Development Driven by Use Cases?
Our recommended method for organizing your functional requirements is using use cases. Instead of a bulleted list of requirements, organize them in a way that tells a story of how someone may use the system. This provides for greater completeness and consistency, and also provides a better understanding of the importance of a requirement from a user’s perspective.
From a traditional object-oriented system model, it’s often difficult to tell how a system does what it’s supposed to do. This difficulty stems from the lack of a “red thread” through the system when it performs certain tasks. In the Unified Process for EDUcation (UPEDU), use cases are that thread because they define the behavior performed by a system. Use cases are not part of traditional object orientation, but their importance has become even more apparent. This is further emphasized by the fact that use cases are part of the Unified Modeling Language.
The UPEDU employs a “use-case driven approach”, which means that use cases defined for a system are the basis for the entire development process.
Use cases play a part in several disciplines.
- The use-case model is one of the key resulting artifacts from the requirements discipline. The use case model identifies what the system needs to do from the user’s point of view. Use cases constitute an important fundamental concept that must be acceptable to the stakeholders, developers and testers of the system.
- During analysis & design, use cases are realized in a design model. You create use-case realizations, which describe how the use case is supported by the design in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the system that will need to be implemented, and how the parts need to interact to support the required use cases.
- During implementation, the design model acts as the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of collaborating design classes.
- During test, the use cases provide the necessary scenarios that constitute the key basis for identifying functional test scenarios. Those test scenarios are used to derive test cases and test scripts; the functionality of the system is verified by executing test scenarios that exercise each use case.
- In the project management discipline, use cases are used as a basis for planning iterative development.