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