[URL Check] The following URLs in this article are outdated. Please update.
Requirements Development ( RD ) and Requirements Management ( RM ) are sub-disciplines of Requirements Engineering ( RE ). Whereas RD identifies requirements and writes them down as formal specifications, RM takes care of change management, impact analysis and traceability of those requirements.
It's common for requirements to change. In Agile and iterative development methodologies, only some requirements are identified at the start. Other requirements are defined with each new iteration. This evolution is also handled by RM . Hence, RM doesn't strictly follow RD in a linear process.
There are many tools to aid RM . However, tools alone don't lead to effective RM . Stakeholders need to communicate. Workflows must be defined and followed.
Given that RD has produced a set of requirements, here are the main RM tasks: 
Inputs to RM are baseline requirements, change requests, and product verification/validation results. Outputs from RM are impact analysis reports, documented and versioned requirements, traceability matrix, and requirements verification/validation reports. Changes to requirements must be approved by a Change Control Board ( CCB ). The CCB will have the essential stakeholders including the client. RCM tasks include change identification, impact analysis, solution analysis, and cost/effort estimation. Requirements specifications, design artefacts, test plans/procedures and other documents must be updated. The figure shows the states through which a requirement goes in a particular SAP product. Good drafts are reviewed and approved. Otherwise, drafts are marked for another iteration of analysis and improvement. Each requirement is assigned to a Work Package ( WP ). They also classify each requirement: completely new requirement, needs customization but no coding, non-functional, etc.
A high-level requirement might lead to many levels of sub-requirements. Thus, requirements can be structured as a hierarchy and visualized in a tree or graph view. Requirements metamodel is a more formal way to structure requirements. This captures the various relations among requirements. For example, one requirement might depend on, be similar to, refined by or constrained by another requirement. Different approaches exist to define a metamodel: goal-oriented, aspect-driven, variability management, use-case, domain-specific, and reuse-driven techniques. Two specific models are Pohl's dependency model and Dahlstedt's dependency model. A dependency model helps us identify both direct and indirect dependencies. It helps us analyze requirements and discover problems. Dependencies aid impact analysis. At the same time, we must be careful of false positives, that is, capturing wrong dependencies.
When requirements are not properly documented or communicated, there's delay, cost overruns and an incomplete product. Not taking customer feedback early on is also a communication issue. If requirements are not centralized and accessible to all, stakeholders resort to emails or hand-written notes. This creates gaps. A 200-page document is a problem since it's hard to read or maintain. Lack of change management happens when we wrongly assume that baseline requirements will never change. When requirements do change, they're likely to be handled in an ad hoc manner. This may lead to constantly revisiting earlier decisions and revising baseline requirements. If requirements are not structured, impact analysis becomes difficult. Requirements creep (aka scope creep) happens when requirements are changed or added to current scope of work. System becomes more complex than it needs to be. Often these changes are unplanned. This affects budgeting, resourcing, productivity and timely deliveries. Lack of automation hurts productivity. Trying to manage requirements in Word or Excel documents and updating them manually is inefficient. Instead, invest in Application Lifecycle Management and RM platforms.
Scope creep can happen when initial scope is unclear or not detailed enough. Having too many or too few decision makers is also a problem for scope management. Lack of clear communication is another reason. Sometimes developers add a "cool" feature even when it wasn't requested. This is called gold plating and can cause problems later on. Involve all stakeholders in discussions to clarify scope. Document the requirements. Consult the stakeholders when prioritizing requirements and planning the schedule. Get feedback early on. Let all changes go through an agreement and approval process. Monitor the progress closely and be on the look out against gold plating. Give importance to requirements priority, effort and risk. Refine the specifications with context and detail. Different descriptions (textual, tabular, graphical) may be needed for different audiences. Scope creep is not always bad but it has to be managed. Clients will be more satisfied if you're able to accommodate their changing requirements. Leadership, negotiation, and planning are essential skills to manage scope creep. Allow some flexibility in the scheduling. Apply the project management triangle to balance scope, schedule and budget.
An RM tool should aid baselining, change management, impact analysis, review comments, traceability, versioning, import/export of data, visualizations, document generation, personalized dashboards and reporting, integration with scheduling tools, real-time collaboration, and setting acceptance criteria. It should address the different needs of developers, project managers and tool administrators. Tools that support modelling and analysis are likely to support code generation and test case generation. It should aid RD tasks as well or at least integrate with an RD tool. It should store or link to RD artefacts such as templates, checklists, analysis reports, and modelling diagrams. In fact, a requirement engineering tool would cater for both RD and RM . Some of the well-known RM tools are Jama Software, ReqSuite® RM , codeBeamer, ReQtest, Perforce Helix RM , IBM Engineering Requirements Management DOORS Next, Accompa, Requirements Management for JIRA (R4J), SpiraTest, and PractiTest. Ian Alexander maintains a longer list of requirements tools.
Requirements Management Maturity ( RMM ) has five levels of maturity: Level 0 implies lack of any requirements. Achieving RRM Level 5 can enable an organization to reach CMM (Capability Maturity Model) Level 3. Sehlhorst gives a more detailed mapping between RMM and CMM .
Jama Software observed how their customers are doing RM . They came up with their own five levels of maturity: document, maintain, comply, reduce risk and improve process. OneSpring's RMM model consists of these five levels: initial, basic, intermediate, advanced, optimizing. REPM, REPM-M, and SRCMIMM are some alternative models.
IEEE publishes IEEE Std 830-1984 titled IEEE Guide to Software Requirements Specifications. This standard is updated in 1993 and 1998 as IEEE Recommended Practice for Software Requirements Specifications. However, this standard is more about RD than RM . It doesn't use the term "requirements management".
