|
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.
|
References >
Best Practices >