Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing
requirements of a system.
We define a requirement as:
A condition or capability to which the system must conform.
Our formal definition of requirements management is that it is a systematic approach to the following:
-
Eliciting, organizing, and documenting the requirements of the system
-
Establishing and maintaining agreement between the customer and the project team on the changing requirements of
the system
Keys to effective requirements management include maintaining a clear statement of the Requirements,
along with applicable attributes for each requirement
type and Traceability to other requirements and other project work products.
Collecting requirements may sound like a rather straightforward task. In real projects, however, you will run into
difficulties because:
-
Requirements are not always obvious, and can come from many sources.
-
Requirements are not always easy to express clearly in words.
-
There are many different types of requirements at different levels of detail.
-
The number of requirements can become unmanageable if not controlled.
-
Requirements are related to one another and also to other work products of the software engineering process.
-
Requirements have unique properties or property values. For example, they are neither 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 have learned that
the following skills are important to master:
Problem analysis is done to understand problems, initial stakeholder needs, and propose high-level solutions. It is an
act of reasoning and analysis to find "the problem behind the problem". During problem analysis, agreement is gained on
the real problem(s), and who the stakeholders are. Also, you define what from a business perspective are the boundaries
of the solution, as well as business constraints on the solution. You should also have analyzed the business case for
the project so that there is a good understanding of what return is expected on the investment made in the system being
built.
See also Activity: Analyze the Problem.
Requirements come from many sources; examples would be customers, partners, users, and domain experts. You need to know
how to best determine what the sources should be, get access to those sources, and also how to best elicit information
from them. 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 user experience and business domain expertise in your development team. Very often you will start the discussions
at a business model level rather than a system level. If you're developing a product to be sold to a market place, 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 would be a list of requests or needs that are
described textually and graphically, and that have been given priority relative one another.
See also Activity: Understand Stakeholder Needs.
To define the system means to translate and organize the understanding of stakeholder needs into a meaningful
description of the system to be built. Early in system definition, decisions are made on 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 assigned 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 is both natural language and graphical.
See also Activity: Define the System.
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 in the project
or stabilize the architecture of the application. To make sure that you resolve or mitigate risks in a project as early
as possible, you should develop your system incrementally, carefully choosing requirements to for each increment that
mitigates known risks in the project. To do so, you need to negotiate the scope (of each iteration) with the
stakeholders of the project. This typically requires good skills in managing expectations of the output from the
project in its different phases. You also need to have control of the sources of requirements, of how the work products
of the project look, as well as of the development process itself.
See also Activity: Activity: Manage the Scope of the System.
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 it. It needs to cover not only functionality, but also compliance with any legal or regulatory
requirements, usability, reliability, performance, supportability, and maintainability. An error often committed is to
believe 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 since
they don't understand. You should put lots effort into understanding the audience for the documents you are producing
to describe the system. You may often see a need to produce different kinds of descriptions 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 of the system 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.
See also Activity: Refine the System Definition.
No matter how careful you are about defining 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 more or less 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 that
you use traceability links to represent dependencies between requirements and other work products of the development
lifecycle. Managing change includes activities like establishing a baseline, determining which dependencies are
important to trace, establishing traceability between related items, and change control.
See also Activity: Manage Changing Requirements.
More Information on this topic can be found at:
Concept: Requirements
Concept: Types of Requirements
Concept: Traceability
Whitepaper: Applying Requirements Management with Use Cases
|