Authored by : Hitesh Sanghavi
SEI authorized Lead AppraiserHitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)

Legend:
RM: Requirements Management

Requirements management and requirements development play a very important role in the project management activity. Project managers have to keep a constant vigil on these two activities.

The purpose of Requirements Management (RM) is to “manage” the requirements of the project's products and product components

RM identifies inconsistencies between requirements and project's plans/work products

RM stakeholders:
RM stakeholders are customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product/process.

RM defines process for collecting and defining Customer requirements, Project management requirements and process specific requirements, necessary to be satisfied by the organization. This checklist may help RM activity:
1. Has the final statement of requirements been checked against the original source?
2. What other requirements relate to this requirement? Are they clearly noted via cross reference matrix or other mechanism? Does the requirement violate any domain constraints?
3. Is the requirement traceable to any system model that has been created?
4. Is the requirement traceable to overall system/product objectives?
5. Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?
6. Has an index for the specification been created?
7. Is the source (e.g., a person, a regulation, a document) of the requirement identified?
8. RM ensures reduction of costly rework, or customer rejection by establishing the criteria for the acceptance of requirements to se that requirements are clear, complete, consistent with each other, uniquely identified, implementable, verifiable and traceable.

RM process area expects a common understanding to be developed between the project stake holders from the customer’s side and software development organization. Project related requirements from process areas like RD, technical solutions, Product integration, verification and validation (testing) shall be created when these process areas are enacted. These evolving project and process requirements changes may “dynamically and often recursively” affect all other engineering process areas. Functional and non functional requirements review by SME (Subject matter expert) ensures consistency between the RM document, project planning, WBS, work products and products components to ensure smooth implementation of the design and coding activities. RM takes care of managing the requirements developed in the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. In the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. As and when RD changes the requirements, RM manages and controls the requirement changes and assesses its impact on other work products and the phases of the life cycle. RM process ensures that requirements are reviewed by an agreed SPOC (Single point of Contact) from the customer, after necessary review on functional, non functional and technical specifications. The requirements are decomposed for clarity and systematically negotiated without keeping any TBD (to be decided) factors. This ensures that misunderstanding, misconception and assumptions in the documents are resolve at an early stage of life cycle. This prevents them to be converted into risk in later phases of the life cycle.

RM
1. Deals with communication between requirements analysts and customer. RM is customer management
oriented.
2. RM process defines a clear and explicit understanding of all the project activities executed by the SW
development organization. This is also agreed by the customer SPOC, and PM communicates various
technical/ non technical aspects of the requirements to his team members.
3. RM manages the activities emerging out of RD and other PA in the life cycle. Several process activities
shall get added to the project plan (e.g. Staff training, review requirements, test equipments, interfaces,
integration environments, documentation requirements, prototyping needs etc) at various phases of
SDLC.
4. Bi–directional requirements traceability is maintained using matrix format which helps in managing
control of requirement changes by using CRL (Change request log) and version control process
configuration management) and its impact on project planning, design, WBS, coding and the testing
activities is logged.
5. RM uses requirements tracking tools, traceability tools and bi-directional matrix to manage requirement
changes
6. RM training includes: Application domain, ??Requirements definition, analysis, review, ??Configuration
management and RM tools, ??Negotiation and conflict resolution
7. RM deliverables placed under configuration management are requirements and requirements traceability
matrix.
8. Work products reviewed include requirements and requirements traceability matrix.
9. RM does not have any advance practice built on the base practice.
10. Typical RM work products are:

For successful RM implementation, we have the following work products.
1. Criterion for evaluation and acceptance of requirements with results of analyses against criteria.
2. An agreed to set of documented requirements (complete, consistent, verifiable, traceable, unique and
appropriate to implement) with commitments .This can be in a document called URS (User
requirements specification)
3. Requirements Impact assessments.
4. Requirements status in requirements database with decision statements.
5. Requirements Traceability Matrix and tracking system procedures.
6. Documentation of inconsistencies including sources conditions and rationales and the follow-up
corrective actions.
7. Corrective actions on Requirements review