Topics
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 appropriate 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.
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. 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.
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 Rational Unified Process (RUP), 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 RUP 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 concept of use cases can be used to represent business processes. We
call this use-case variant a "business use case". It is covered
by the Business Modeling discipline.
- Use cases as software requirements are described in the Requirements discipline.
Use cases constitute an important fundamental concept that must be acceptable
to both the customer, developers and testers of the system.
- In the Project Management discipline, use cases are used as a basis for
planning iterative development.
- Use cases are realized in a design model as part of the Analysis and Design
discipline. Use-case realizations describe how the use case is supported by
the design in terms of interacting objects in the design model.
- Use cases ultimately become implemented and testable scenarios, and so are
an important focus in both the Implementation and Test disciplines. They 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 Deployment discipline, use cases form a foundation for what is described
in user's manuals. Use cases can also be used to define ordering units of
the product. For example, a customer can get a system configured with a particular
mix of use cases.
| |
|