Requirements Management

Overview of requirements management. Source: Oberg et al. 2000, fig. 15.
Overview of requirements management. Source: Oberg et al. 2000, fig. 15.

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.

Discussion

  • What are the main tasks in requirements management?
    Key practices or tasks in RM. Source: Wiegers 2017, 7:28.
    Key practices or tasks in RM. Source: Wiegers 2017, 7:28.

    Given that RD has produced a set of requirements, here are the main RM tasks:

    • Evaluation: Evaluate requirements specification for quality. Requirements have to be clear, concise, consistent, complete, structured, modular, and categorized.
    • Prioritization: Classify requirements into high, medium or low priorities. High ones are scheduled right away. Medium ones can be considered at the next iteration. A cost-benefit analysis can help determine priorities.
    • Change Management: Changes must follow a strict process of review, analysis and approval. Requirements are versioned so that changes can be tracked.
    • Tracing: High-level requirements can depend on many sub-requirements. Each requirement must be traceable to design, code and tests. Likewise, these artefacts must be traceable to their requirements. Traceability improves impact analysis and project scheduling when requirements change.
    • Automation: Visualizing requirements in a hierarchy, scheduling a subset of requirements, updating status, linking to design models, notifying team leads of changes, generating reports, and exporting data are just some tasks that need to be automated. Many tools aid automation.
  • What's the Requirements Change Management (RCM) process?
    Requirements change management process flow in SAP. Source: Ahmed Khan 2021.
    Requirements change management process flow in SAP. Source: Ahmed Khan 2021.

    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.

  • How should requirements be structured?
    Requirements metamodel. Source: Goknil et al. 2014, fig. 3.
    Requirements metamodel. Source: Goknil et al. 2014, fig. 3.

    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.

  • What's impact analysis in RM?

    When any change is proposed, impact analysis determines what requirements and sub-requirements are affected. It looks at the extent of change in terms of architecture, design, coding and testing. It estimates the effort to implement the changes. In projects where safety and quality are critical, such as in healthcare or automotive, impact analysis becomes all the more important.

    Impact analysis is not just about code or implementation. It concerns technical and non-technical aspects, existing and new requirements. We can analyze dependency information, utilize slicing techniques, consult design specifications, and interview experts. Requirements attributes can also be used for impact analysis.

    Since requirements are often written in natural language, NLP has been applied to assess impact. Latent Semantic Indexing (LSI) is one suitable technique. An alternative technique uses the phrasal structure of requirements statements.

  • What are the main challenges with RM?
    Challenges with requirements change management. Source: Akbar et al. 2020, fig. 5.
    Challenges with requirements change management. Source: Akbar et al. 2020, fig. 5.

    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.

  • How can we avoid scope creep?
    Top reasons for scope creep. Source: Lucidchart 2021.
    Top reasons for scope creep. Source: Lucidchart 2021.

    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.

  • What should we look for in an RM tool?
    Screenshot of codeBeamer RM tool. Source: Aston 2023.
    Screenshot of codeBeamer RM tool. Source: Aston 2023.

    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.
  • How can we assess a project's RM maturity?
    Empirical RMM model observed at Jama Software. Source: Osofsky 2020.
    Empirical RMM model observed at Jama Software. Source: Osofsky 2020.

    Requirements Management Maturity (RMM) has five levels of maturity:

    • Written: A basis towards common understanding and client contracts.
    • Organized: Requirements are well formatted, centralized, accessible, and version controlled,.
    • Structured: Requirements are categorized. Attributes are used for planning, querying and filtering.
    • Traced: Impact analysis and coverage analysis become possible with traceability.
    • Integrated: Integrated with design, testing, project management, change management, etc. Requirements become central to many software development processes.

    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.

Milestones

1984

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

1991

The early 1990s sees interest in requirements engineering and related tooling. Richard Stevens (through his company QSS) releases to the UK Ministry of Defence an RM tool named DOORS (Dynamic Object-Oriented Requirements System). First commercial version of DOORS is released in April 1993. DOORS captures relationships among requirements. It's visually simple and customizable. In time, DOORS becomes a market leader.

1993

The first IEEE Symposium on Requirements Engineering is held. The following year, the IEEE International Conference on Requirements Engineering is held. In 2002, these two are merged into the IEEE International Requirements Engineering Conference, which is subsequently organized annually.

2002

Tejle and Gorschek propose Requirements Engineering Process Model as part of their masters thesis. This covers both requirements development and management. The five levels of maturity are Initial, Basic, Formulated, Developed and Advanced. In 2003, IBM defines Requirements Management Maturity (RMM) with five levels of maturity. These are specific to requirements management.

2012

Ebert and Jastram propose ReqIF as an interchange format to import/export requirements across RM tools. This would enable better collaboration among business partners. An analysis from 2023 reveals that ReqIF, Excel and CSV are popular exchange formats.

Jan
2017
Requirements change classification. Source: Jayatilleke and Lai 2017, table 10.
Requirements change classification. Source: Jayatilleke and Lai 2017, table 10.

Jayatilleke and Lai publish a review of requirements change management. This includes causes of changes, RCM process models, techniques, and decision making. Their work identifies gaps in change identification, change analysis and cost estimation.

Oct
2017
Polyhierarchy of requirements represented by a design graph. Source: Holder et al. 2017, fig. 14.
Polyhierarchy of requirements represented by a design graph. Source: Holder et al. 2017, fig. 14.

With gear system as an example, Holder et al. illustrate model-based requirements management. They map each requirement to a product component. They propose a graph-based design language (such as UML) to realize this. By decomposing the product into its components a domain-specific vocabulary can be created.

2023

Ozkaya et al. analyze 56 RE tools and find some limitations. Project planning, specification via modelling and requirements analysis are rarely supported. While most can generate documents, only a few can generate code or test scenarios. Code generation is supported by tools that understand modelling languages such as SysML and UML. While Agile is often supported, other methodologies such as Model-Driven Engineering (MDE) and Software Product-Line Engineering (SPLE) are rarely supported.

References

  1. Ahmed Khan, M. 2021. "Requirement Management Improvements in Focused Build SP08." Blog, SAP, August 13. Accessed 2024-01-26.
  2. Akbar, M. A., W. Naveed, A. A. Alsanad, L. Alsuwaidan, A. Alsanad, A. Gumaei, M. Shafiq, and M. T. Riaz. 2020. "Requirements Change Management Challenges of Global Software Development: An Empirical Investigation." IEEE Access, vol. 8, pp. 203070-203085. doi: 10.1109/ACCESS.2020.3035829. Accessed 2024-01-26.
  3. Akbar, M. A., A. A. Khan, S. Mahmood, and A. Mishra. 2023. "SRCMIMM: the software requirements change management and implementation maturity model in the domain of global software development industry." Inf Technol Manag, vol. 24, pp. 195–219. Accessed 2024-01-28.
  4. Alexander, I. 2004. "Requirements Management with DOORS: A Success Story." Scenario Plus. Accessed 2024-01-29.
  5. Arora, C., M. Sabetzadeh, A. Goknil, L. C. Briand, and F. Zimmer. 2015. "Change impact analysis for Natural Language requirements: An NLP approach." IEEE 23rd International Requirements Engineering Conference (RE), Ottawa, ON, Canada, pp. 6-15. doi: 10.1109/RE.2015.7320403. Accessed 2024-01-29.
  6. Aston, B. 2023. "10 Best Requirements Management Tools Reviewed For 2024." The Digital Project Manager, November 23. Accessed 2024-01-26.
  7. Awan, R. 2005. "Requirements Engineering Process Maturity Model for Market Driven Projects." M.Sc. Thesis, Blekinge Institute of Technology, October. Accessed 2024-01-28.
  8. Deviniti, D. H. 2018. "Requirements management: 6 best practices." Article, App Central, Atlassian Community, March 5. Accessed 2024-01-26.
  9. Ebert, C. and M. Jastram. 2012. "ReqIF: Seamless Requirements Interchange Format between Business Partners." IEEE Software, vol. 29, no. 5, pp. 82-87, Sep-Oct. doi: 10.1109/MS.2012.121. Accessed 2024-01-28.
  10. G2. 2024. "Best Requirements Management Software." G2. Accessed 2024-01-26.
  11. Geri. 2021. "Scope creep is bad, here’s how to handle it." Blog, Kitchen, May 25. Accessed 2024-01-26.
  12. Goknil, A., I. Kurtev, K. van den Berg, and W. Spijkerman. 2014. "Change impact analysis for requirements: A metamodeling approach." Information and Software Technology, vol. 56, no. 8, pp. 950-972, August. doi: 10.1016/j.infsof.2014.03.002. Accessed 2024-01-28.
  13. Halbleib, H. 2004. "Requirements Management." Information Systems Management, vol. 21, no. 1, pp. 8-14. doi: 10.1201/1078/43877.21.1.20041201/78982.2. Accessed 2024-01-26.
  14. Heumann, J. 2003. "The Five Levels of Requirements Management Maturity." The Rational Edge, Rational Software. Accessed 2024-01-26.
  15. Hoffmann, M., N. Kuhn, M. Weber, and M. Bittner. 2004. "Requirements for requirements management tools." Proc. 12th IEEE International Requirements Engineering Conference, Kyoto, Japan, pp. 301-308. doi: 10.1109/ICRE.2004.1335687. Accessed 2024-01-26.
  16. Holder, K., A. Zech, M. Ramsaier, R. Stetter, H.-P. Niedermeier, S. Rudolph, and M. Till. 2017. "Model-Based Requirements Management in Gear Systems Design Based On Graph-Based Design Languages." Applied Sciences, vol. 7, no. 11:, article no. 1112, October. doi: 10.3390/app7111112. Accessed 2024-01-26.
  17. Hooks, I. 1990. "Why Johnny Can't Write Requirements." Space Programs and Technologies Conference, September 25-27. doi: 10.2514/6.1990-3561. Accessed 2024-01-26.
  18. IEEE. 1984. "IEEE Std 830-1984: IEEE Guide to Software Requirements Specifications." IEEE Computer Society, February 20. Accessed 2024-01-03.
  19. IEEE. 1998. "IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications." IEEE Computer Society, October 20. doi: 10.1109/ieeestd.1998.88286. Accessed 2024-01-03.
  20. Jama Software. 2007. "The Top 3 Myths About Requirements Management... and Real-World Advice for How to Dispel Them." Jama Software, October. Accessed 2024-01-26.
  21. Jama Software. 2023. "Conquering the 5 Biggest Challenges of Requirements Management." Section 1.6 in: The Essential Guide to Requirements Management and Traceability, Jama Software, August 24. Accessed 2024-01-26.
  22. Jayatilleke, S. and R. Lai. 2017. "A systematic review of requirements change management." Information and Software Technology, vol. 93, pp. 163-185, January. doi: 10.1016/j.infsof.2017.09.004. Accessed 2024-01-26.
  23. Jönsson, P. 2005. "Impact Analysis: Organisational Views and Support Techniques." Thesis, Blekinge Institute of Technology, April 21. Accessed 2024-01-29.
  24. Krüger, N. 2020. "Requirements Management: Tips, Tactics, & Tools." Blog, Perforce, September 21. Accessed 2024-01-26.
  25. Lucidchart. 2021. "How to avoid scope creep (and the circumstances that lead to it)." Blog, Lucidchart, February 9. Accessed 2024-01-26.
  26. NASA. 2024. "Requirements Management." Reference, NASA. Accessed 2024-01-26.
  27. Natani, D. 2020. "Challenges in Requirements Management." Article, Jira Software, Atlassian Community, September 7. Accessed 2024-01-26.
  28. No Magic. 2018. "Requirements decomposition." Documentation, SysML Plugin, v19.0 LTR, No Magic, July 2. Accessed 2024-01-29.
  29. Oberg, R., L. Probasco, and M. Ericsson. 2000. "Applying Requirements Management with Use Cases." Technical Paper TP505, v1.4, Rational Software Corporation. Accessed 2024-01-26.
  30. OneSpring. 2013. "Requirements Maturity Enhancing Software Delivery Through Improved Requirements Capability." OneSpring. Accessed 2024-01-28.
  31. Osofsky, M. 2020. "Requirements Management Maturity Model – Empirical vs. Theory." Blog, Jama Software, October 30. Accessed 2024-01-28.
  32. Ozkaya, M., G. Kardas, and M. Alp Kose. 2023. "An Analysis of the Features of Requirements Engineering Tools." Systems, vol. 11, no. 12, article no. 576. doi: 10.3390/systems11120576. Accessed 2024-01-26.
  33. Sehlhorst, S. 2007. "CMMI Levels and Requirements Management Maturity Introduction." Blog, Tyner Blain, January 25. Accessed 2024-01-26.
  34. Taller, H. 2022. "The Top 5 Challenges of Software Requirements Management." Blog, PTC, November 3. Accessed 2024-01-26.
  35. University of Paris. 2005. "Past Conferences." RE 2005, University of Paris 1 -Panthéon Sorbonne. Accessed 2024-01-11.
  36. Westfall, L. 2010. "The Certified Software Quality Engineer Handbook." New Age International, New Delhi.
  37. Westfall, L. 2014. "What, Why, Who, When, and How of Software Requirements." Chapter 1 in: Ghani, I., W. H. N. W. Kadir, and M. N. Ahmad (eds), Handbook of Research on Emerging Advancements and Technologies in Software Engineering, IGI Global, pp. 1-18. doi: 10.4018/978-1-4666-6026-7.ch001. Accessed 2024-01-03.
  38. Wiegers, K. 2017. "Requirements Management Best Practices." Webinar, ModernAnalyst, on YouTube, June 9. Accessed 2024-01-26.
  39. Zhang, H., J. Li, L. Zhu, R. Jeffery, Y. Liu, Q. Wang, and M. Li. 2014. "Investigating dependencies in software requirements for change propagation analysis." Information and Software Technology, vol. 56, no. 1, pp. 40-53, January. doi: 10.1016/j.infsof.2013.07.001. Accessed 2024-01-28.
  40. de Gea, J. M. C., J. Nicolás, J. L. F. Alemán, A. Toval, C. Ebert, and A. Vizcaíno. 2011. "Requirements Engineering Tools." IEEE Software, IEEE Computer Society, pp. 86-91, July/August. Accessed 2024-01-26.

Further Reading

  1. Wiegers, K. 2017. "Requirements Management Best Practices." Webinar, ModernAnalyst, on YouTube, June 9. Accessed 2024-01-26.
  2. Jama Software. 2023. "The Essential Guide to Requirements Management and Traceability." Jama Software, August 24. Accessed 2024-01-26.
  3. Oberg, R., L. Probasco, and M. Ericsson. 2000. "Applying Requirements Management with Use Cases." Technical Paper TP505, v1.4, Rational Software Corporation. Accessed 2024-01-26.
  4. Jayatilleke, S. and R. Lai. 2017. "A systematic review of requirements change management." Information and Software Technology, vol. 93, pp. 163-185, January. doi: 10.1016/j.infsof.2017.09.004. Accessed 2024-01-26.
  5. Ozkaya, M., G. Kardas, and M. Alp Kose. 2023. "An Analysis of the Features of Requirements Engineering Tools." Systems, vol. 11, no. 12, article no. 576. doi: 10.3390/systems11120576. Accessed 2024-01-26.
  6. Almefelt, L., F. Berglund, P. Nilsson, and J. Malmqvist. 2006. "Requirements management in practice: findings from an empirical study in the automotive industry." Res Eng Design, vol. 17, pp. 113-134. doi: 10.1007/s00163-006-0023-5. Accessed 2024-01-26.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
Avatar of user arvindpdmn arvindpdmn
4
0
1393
DevCoins due to articles, chats, their likes and article hits are included.
1870
Words
1
Authors
4
Edits
1
Chats
0
Likes
1079
Hits

Cite As

Devopedia. 2024. "Requirements Management." Version 4, January 29. Accessed 2024-06-26. https://devopedia.org/requirements-management
Contributed by
1 author

Last updated on
2024-01-29 10:09:02

Improve this article
system software quality software engineering requirements

See Also

Article Warnings

  • Readability score of this article is below 50 (47.6). Use shorter sentences. Use simpler words.