Concepts:
Requirements Management
More Information: Concepts: Requirements
Concepts: Types of Requirements
Concepts: Traceability
White Paper: Applying Requirements
Management with Use Cases
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
- eliciting, organizing, and documenting the requirements
of the system, and
- 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 artifacts.
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 deliverables 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 Workflow Detail: Analyze the Problem.
Requirements come from many sources, examples would be customers, partners,
end 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 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 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 Workflow Detail: 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 Workflow Detail: 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 deliverables of the project look, as well as the
development process itself.
See also Workflow Detail: 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 them. 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 in understanding the audience for the documents you
are producing to describe the system. You may often see a need to produce
different kinds of description 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
tells us what system capabilities will be verified.
See also Workflow Detail: 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 artifacts of the development lifecycle. Managing change include activities
like establishing a baseline, determining which dependencies are important to
trace, establishing traceability between related items, and change control.
See also Workflow Detail: Manage Changing Requirements.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Disciplines >
Requirements >
Concepts >
