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.
|