Requirements Development

Tasks and techniques in requirements development. Source: Wiegers and Beatty 2013, table 3-1.
Tasks and techniques in requirements development. Source: Wiegers and Beatty 2013, table 3-1.

It's hard to build the right product without knowing why it's needed or what features are expected of it. Requirements Development provides answers to these questions. It involves many stakeholders: users, designers, developers, architects, and managers. It identifies user needs, studies technical feasibility, derives exact requirements, and validates those requirements.

Requirements are various: business vs technical, functional vs non-functional, system vs component, hardware vs software, etc. Getting the requirements right mitigates risk, avoids costly rework, and improves customer satisfaction.

Traditionally requirements were identified at the start of the project. In Agile or in any iterative process, requirements are developed continuously as features are added/updated or bugs need to be fixed. Requirements development is so important that Karl Weigers once said,

If you don't get the requirements right, it doesn't matter how well you do anything else.

Discussion

  • What's the requirements engineering process?
    The Requirements Engineering (RE) process. Source: Westfall 2014, fig. 2.
    The Requirements Engineering (RE) process. Source: Westfall 2014, fig. 2.

    Requirements Engineering (RE) has two parts:

    • Requirements Development (RD): Requirements are developed by understanding customer needs and stakeholder expectations. These are refined and documented as formal specifications. Once specifications are validated, they set the baseline or the starting point for the architecture and the design phases of the project. Getting the requirements right is an iterative process consisting of elicitation, analysis, specification and validation. With each iteration, gaps and defects are addressed.
    • Requirements Management (RM): Requirements are rarely static. Changes to baseline requirements are common. These changes are managed with a clear process. Requirements are tied to project plans and schedules. Requirements are traced to design, code and tests.

    RD precedes RM when baseline requirements are defined. Thereafter, requirements are continuously refined even in later phases of the software development life cycle.

    It's useful to clarify verification versus validation. Requirements verification checks that requirements are well formed. Requirements validation checks that requirements specify the right system fulfilling the needs of stakeholders.

  • What are the different types of requirements?
    Types of requirements with relations: storage (solid arrows) and influence (dotted arrows). Source: Wiegers and Beatty 2013, fig. 1-1.
    Types of requirements with relations: storage (solid arrows) and influence (dotted arrows). Source: Wiegers and Beatty 2013, fig. 1-1.

    For architects and developers, the word "requirements" typically means product requirements. For project managers, it may instead mean project requirements. Project requirements will include development/testing infrastructure, tools, licenses, staff training, compliance, and more.

    Product requirements can be defined at different levels. Business requirements capture why the product is being built. Managers and marketing folks are involved. Then business analysts come in to define user requirements from the perspective of users. Finally, functional requirements are those that the product should satisfy. Functional requirements are inputs to designers, developers and testers.

    Then there are non-functional requirements such as usability, reliability, performance, safety, etc. Data requirements, interface requirements and design constraints are also non-functional requirements.

    For example, "customer can pay for gas at the pump" is a business requirement. User requirements include "swipe credit card" and "request receipt". Functional requirements include "prompt user for card swipe" and "parse card's magnetic strip". A non-functional requirement could be "complete the entire payment procedure within 60 seconds".

  • What's the expected output of requirements development?
    Output artefacts of requirements development. Source: Adapted from Wiegers and Beatty 2013, fig. 8-3, 10-2.
    Output artefacts of requirements development. Source: Adapted from Wiegers and Beatty 2013, fig. 8-3, 10-2.

    Requirements specification is the main output of requirements development. This may be a single document or organized as many documents: Business Requirements Specification, Software Requirements Specification (SRS), Stakeholder Requirements Specification, and System Requirements Specification.

    Specifications may be captured as Microsoft Word or PDF documents. Alternatively, they're in spreadsheets, a database or in a custom requirements management tool. In any case, specifications must be well-organized, amenable to tracing and easily accessible by all stakeholders.

    During requirements analysis, various models, diagrams or tables might be employed. Use case diagrams, class diagrams, data flow diagrams, and state transition diagrams are examples. Specifications must link to these diagrams.

    Finally, let's understand requirements versus specifications. Requirements can be treated as questions and specifications as answers. We start with requirements that're rough statements. Through requirements analysis and validation, we refine these into formal specifications. In another interpretation, specification is a structured collection of requirements.

  • Could you explain requirements elicitation?
    Different elicitation techniques by project characteristic. Source: Wiegers and Beatty 2013, fig. 7-3.
    Different elicitation techniques by project characteristic. Source: Wiegers and Beatty 2013, fig. 7-3.

    Requirements elicitation identifies users, user groups and other stakeholders. It attempts to understand their real needs. This in turn sets the product scope.

    It's not as simple as asking users what they want. Henry Ford once said, "If I had asked people what they wanted, they would have said faster horses." Empathy is needed to see things from the user perspective. Build a rough prototype. Observe how users interact with it. This will likely provide useful insights.

    Interviews and user focus groups can help. For diverse perspectives from all stakeholders, Joint Application Design (JAD) workshops could be organized. User stories, use cases (aka scenarios) and storyboards are some techniques to elicit requirements. These are effective since they dive into the level of actors, needs and interactions.

    Sometimes implementations may be wrongly written down as requirements. Asking "why" questions to understand the context will reveal the hidden requirements. In fact, requirements elicitation is really about answering the questions what, why, and who.

    Requirements elicitation is in fact nuanced. To call it requirements capture or gathering is perhaps an oversimplification.

  • Could you explain requirements analysis?

    Requirements analysis refines and adds details to the requirements identified via requirements elicitation. It's done iteratively until requirements can be clearly written down as specifications. High-level requirements are translated into technical product requirements at various levels.

    Modelling is done, perhaps using Unified Modelling Language (UML). Visualizations help analyse the system from various perspectives. Some of these are data flow diagrams, entity relationship diagrams, state transition diagrams/tables, class diagrams, sequence diagrams, activity diagrams, process flow diagrams, decision trees, and event/response tables. Through analysis, incomplete, inconsistent or incorrect requirements can be uncovered.

    Different aspects or viewpoints can be modelled: organizational, data, behavioural, domain, and non-functional requirements.

  • What roles do business rules play in requirements development?
    How business rules influence requirements. Source: Wiegers and Beatty 2013, table 9-1.
    How business rules influence requirements. Source: Wiegers and Beatty 2013, table 9-1.

    Business requirements frame the problem and the motivation for starting the project. On the other hand, business rules are policies, standards, practices, regulations or guidelines that are defined at the organizational level. Products are expected to adhere to these rules. Business rules affect use cases. System state, input, and user role are some factors that're used to define business rules.

    One study identified five types of business rules: facts, constraints, action enablers, inferences and computations. Atomic business rules are better than one complex rule that combines multiple rules.

    Consider a firm making a payment gateway. Due to an ongoing litigation, there may be a business rule prohibiting integration with a specific bank. The firm and another bank may be part of the same parent company. For this bank, there may be a rule waiving transaction fees. Due to local regulations, there may be a rule that sets the maximum value of a transaction. Such rules must be translated into functional requirements that developers need to implement.

  • Could you give some tips for better requirements development?

    Biases can affect requirements development. Some of these are optimism bias, overconfidence bias, strategic misrepresentation, anchoring, and more.

    Avoid copying a competitor and jumping straight into implementing features. Likewise, avoid building the opposite of a failed product. Real failure here is skipping requirements engineering and assuming requirements can be transferred from one product to another.

    A product packed with features but solicits user feedback very late is risky. Don't be afraid to involve customers to test prototypes and clarify requirements. Early adopters often like to give feedback and ideas.

    Avoid "gold plating", that is, implementing features that developers thought would be nice to have. Delivering something that the user doesn't need wastes resources. It could also confuse users.

    Document requirements clearly in the specifications. Each requirement must be unambiguous, validated, necessary, complete, consistent, feasible, traceable, verifiable and understandable.

  • What resources can help me learn more about requirements development?

    Software Requirements by Wiegers and Beatty (2013) is a good book to read. Other books from Wiegers include Software Requirements Essentials and More About Software Requirements. An older book is The Requirements Engineering Handbook by Young (2004).

    The International Requirements Engineering Board (IREB) certifies engineers in the RE discipline. One study guide is Requirements Engineering Fundamentals by Pohl and Rupp (2015).

    ISO/IEC/IEEE 29148:2018 is the main standard to read. Also worth reading are its related standards ISO/IEC/IEEE 15288:2023 (system life cycle processes) and ISO/IEC/IEEE 12207:2017 (software life cycle processes).

    Penzenstadler's video lectures on Requirements Engineering are available on YouTube. Coursera's Requirements Engineering: Secure Software Specifications Specialization has five courses in RE with security as a focus.

    CMU SEI and INCOSE are two useful sources for guides and white papers. Search for the keyword "requirements" at their websites. As an example, we mention INCOSE's Guide to Writing Requirements (2023).

Milestones

1975

Brooks in his book Mythical Man-Month writes about the need to consult users when writing system specifications. Some important ideas include user feedback, iterative development, separation of specification and design, and user manual as the external specification of the product. Until then, users weren't considered as important to either identifying requirements or writing specifications.

1977
Requirements definition. Source: Ross and Schoman 1977.
Requirements definition. Source: Ross and Schoman 1977.

Ross and Schoman propose the use of the term "requirements definition" over the more widely used but rather ill-defined term "requirements analysis". To them, Requirements Definition "encompasses all aspects of system development prior to actual system design." It deals with three things: context analysis (why the system is needed), functional specification (what the system is to be), and design constraints (how the system is to be constructed within defined boundary conditions). Multiple viewpoints (technical, operational, economic) must be considered.

1979
Early history of requirement engineering. Source: Kolligs and Thomas 2020, table II.
Early history of requirement engineering. Source: Kolligs and Thomas 2020, table II.

The TRW Defense and Space group proposes the Software Requirements Engineering Methodology to address project failures due to poor requirements. The early evolution of requirements engineering up to this point is from systems engineering.

1983
An early definition of the word requirement. Source: IEEE 1983, p. 29.
An early definition of the word requirement. Source: IEEE 1983, p. 29.

The IEEE Std 729-1983 defines the word "requirement". The definition encompasses user need, contractual necessity, and the starting point for system development. This definition is revised in 1990 to include the aspect of documentation.

1984
Suggested outline for Software Requirements Specification (SRS). Source: IEEE 1984.
Suggested outline for Software Requirements Specification (SRS). Source: IEEE 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. Also in 1984, the European Space Agency describes the Waterfall Model of software development. They separate user requirements from software requirements. They also state that user requirements is an input to defining software requirements.

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.

1994
The RE journey across three dimensions. Source: Pohl 1994, fig. 2.
The RE journey across three dimensions. Source: Pohl 1994, fig. 2.

Pohl proposes a three-dimensional framework for RE. Requirements have to be approached in the dimensions of specification, representation and agreement. They also note five factors that influence the RE process: methods/methodologies, tools, social aspects, cognitive skills, and economical constraints.

1995

Carroll's Scenario-Based Design describes how user scenarios can be used in requirements analysis. The idea of using scenarios is also seen in the research of other authors about the same time. Other complementary analysis techniques such as state transition diagrams and entity relationship diagrams were invented in the late 1970s.

2010

Jarke et al. point out that RE has changed over the last 30 years. RE is no longer about software alone. It's includes business development, software engineering and industrial design. Challenges include massive reuse, COTS components, system integration, vendor-led requirements, fluid design, short iterations, and distributed requirements. Some of these are reiterated by Jantunen et al. (2019) and noted earlier by Reifer (2000).

2011

ISO/IEC/IEEE 29148 titled Systems and software engineering — Life cycle processes — Requirements engineering is published as an international standard. This replaces earlier standards IEEE 830-1998, IEEE 1233-1998, and IEEE 1362-1998. It's updated in 2018 as ISO/IEC/IEEE 29148:2018.

2022
Design thinking for RE can be applied as a process, toolbox or mindset. Source: Hehn and Mendez 2022, fig. 2.
Design thinking for RE can be applied as a process, toolbox or mindset. Source: Hehn and Mendez 2022, fig. 2.

Hehn and Mendez propose an artefact-based model that combines design thinking and RE. Design thinking focuses on the user perspective and uses low-fidelity prototypes to understand the problem better. RE uses methodologies and tools to specify the requirements in greater detail. The two approaches complement each other. While design thinking is diverging and multi-disciplinary, RE is converging and technical.

References

  1. Alexander, I. F. 1997. "A Historical Perspective on Requirements." Requirenautics Quarterly, Newsletter of the BCS RESG, October. Accessed 2024-01-11.
  2. Carell, A., K. Lauenroth, and D. Platz. 2018. "Using Design Thinking for Requirements Engineering in the Context of Digitalization and Digital Transformation: A Motivation and an Experience Report." In: Gruhn, V. and R. Striemer (eds), The Essence of Software Engineering, Springer. Accessed 2024-01-03.
  3. Firesmith, D. 2007. "Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to Help Solve Them." J. of Object Technology, vol. 6, no. 1, pp. 17-33, January-February. Accessed 2024-01-08.
  4. Hehn, J. and D. Mendez. 2022. "Combining Design Thinking and Software Requirements Engineering to Create Human-Centered Software-Intensive Systems." In: Hehn, J., D. Mendez, W. Brenner, and M. Broy (eds), Design Thinking for Software Engineering. Progress in IS. Springer, Cham. doi: 10.1007/978-3-030-90594-1_2. Accessed 2024-01-03.
  5. 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-08.
  6. Hooks, I. 1993. "Writing Good Requirements." In: Proceedings of the Third International Symposium of the NCOSE - Volume 2. Accessed 2024-01-08.
  7. IEEE. 1983. "ANSI/IEEE Std 729-1983: IEEE Standard Glossary of Software Engineering Terminology." IEEE, February. doi: 10.1109/IEEESTD.1983.7435207. Accessed 2024-01-11.
  8. IEEE. 1984. "IEEE Std 830-1984: IEEE Guide to Software Requirements Specifications." IEEE Computer Society, February 20. Accessed 2024-01-03.
  9. 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.
  10. ISO/IEC/IEEE. 2011a. "ISO/IEC/IEEE 29148:2011: Systems and software engineering--Life cycle processes--Requirements engineering." ISO/IEC/IEEE, December. Accessed 2024-01-11.
  11. ISO/IEC/IEEE. 2011b. "ISO/IEC/IEEE 29148:2011: Systems and software engineering--Life cycle processes--Requirements engineering." ISO/IEC/IEEE, December. Accessed 2024-01-11.
  12. ISO/IEC/IEEE. 2018. "ISO/IEC/IEEE 29148:2018: Systems and software engineering--Life cycle processes--Requirements engineering." ISO/IEC/IEEE, November. Accessed 2024-01-11.
  13. Jantunen, S., R. Dumdum, and D. Gause. 2019. "Towards New Requirements Engineering Competencies." 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), Montreal, QC, Canada, pp. 131-134. doi: 10.1109/CHASE.2019.00038. Accessed 2024-01-03.
  14. Jarke, M., P. Loucopoulos, K. Lyytinen, J. Mylopoulos, and W. Robinson. 2010. "The Brave New World of Design Requirements: Four Key Principles." In: Pernici, B. (ed), Advanced Information Systems Engineering, CAiSE 2010, Lecture Notes in Computer Science, vol. 6051. Springer, Berlin, Heidelberg. doi: 10.1007/978-3-642-13094-6_36. Accessed 2024-01-11.
  15. Kolligs, J. W. and L. D. Thomas. 2020. "The Origins of Requirements." IEEE Systems Journal, vol. 15, no. 3, pp. 3692-3702, September. doi: 10.1109/JSYST.2020.2999557. Accessed 2024-01-03.
  16. Natoli, J. 2016. "Aren't Requirements and Specifications the SAME THING?" Give Good UX, on YouTube, October 25. Accessed 2024-01-11.
  17. Nuseibeh, B. and S. Easterbrook. 2000. "Requirements engineering: a roadmap." ICSE '00: Proceedings of the Conference on The Future of Software Engineering, pp. 35-46, May. Accessed 2024-01-03.
  18. Pohl, K. 1994. "The Three Dimensions of Requirements Engineering." In: Rolland, C., F. Bodart, and C. Cauvet, C. (eds), Advanced Information Systems Engineering. CAiSE 1993. Lecture Notes in Computer Science, vol. 685, Springer, Berlin, Heidelberg. doi: 10.1007/3-540-56777-1_15. Accessed 2024-01-03.
  19. Pohl, K. and C. Rupp. 2015. "Requirements Engineering Fundamentals." 2nd Edition, Rocky Nook. Accessed 2024-01-11.
  20. Reeb, M. 2023. "5 Common Mistakes in Requirements Gathering." Toptal, August 2. Accessed 2024-01-11.
  21. Reifer, D. 2000. "Requirements Management: The Search for Nirvana." IEEE Software, vol. 17, no. 03, pp. 45-47. doi: 10.1109/MS.2000.10022. Accessed 2024-01-03.
  22. Ross, D. T. and K. E. Schoman. 1977. "Structured Analysis for Requirements Definition." IEEE Transactions on Software Engineering, vol. SE-3, no. 1, pp. 6-15, January. doi: 10.1109/TSE.1977.229899. Accessed 2024-01-11.
  23. Sommerville, P. and P. Sawyer. 1997. "Viewpoints: principles, problems and a practical approach to requirements engineering." Annals of Software Engineering, vol. 3, pp. 101–130. Accessed 2024-01-03.
  24. University of Paris. 2005. "Past Conferences." RE 2005, University of Paris 1 -Panthéon Sorbonne. Accessed 2024-01-11.
  25. Westfall, L. 2010. "The Certified Software Quality Engineer Handbook." New Age International, New Delhi.
  26. 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.
  27. Wiegers, K. 2024. "Books." Accessed 2024-01-03.
  28. Wiegers, K. and J. Beatty. 2013. "Software Requirements." Third edition, Microsoft Press. Accessed 2024-01-03.
  29. Young, R. R. 2004. "The Requirements Engineering Handbook." Artech House. Accessed 2024-01-11.
  30. van Lamsweerde, A. 2000. "Requirements Engineering in the Year 00: A Research Perspective." Proceedings of the 2000 International Conference on Software Engineering, ICSE 2000 the New Millennium, Limerick, Ireland, pp. 5-19. doi: 10.1145/337180.337184. Accessed 2024-01-03.

Further Reading

  1. IEEE Computer Society. 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.
  2. Kolligs, J. W. and L. D. Thomas. 2020. "The Origins of Requirements." IEEE Systems Journal, vol. 15, no. 3, pp. 3692-3702, September. doi: 10.1109/JSYST.2020.2999557. Accessed 2024-01-03.
  3. Wiegers, K. and J. Beatty. 2013. "Software Requirements." Third edition, Microsoft Press. Accessed 2024-01-03.
  4. Christel, M. G. and K. C. Kang. 1992. "Issues in Requirements Elicitation." Technical Report, CMU/SEI-92-TR-012, SEI, September. Accessed 2024-01-11.
  5. Voas, J. and P. Laplante. 2010. "Effectively Defining "Shall Not" Requirements." IT Professional, vol. 12, no. 3, pp. 46-53, May-June. doi: 10.1109/MITP.2009.87. Accessed 2024-01-08.
  6. Hehn, J. and D. Mendez. 2022. "Combining Design Thinking and Software Requirements Engineering to Create Human-Centered Software-Intensive Systems." In: Hehn, J., D. Mendez, W. Brenner, and M. Broy (eds), Design Thinking for Software Engineering. Progress in IS. Springer, Cham. doi: 10.1007/978-3-030-90594-1_2. Accessed 2024-01-03.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
4
0
1441
2113
Words
0
Likes
14
Hits

Cite As

Devopedia. 2024. "Requirements Development." Version 4, January 16. Accessed 2024-01-16. https://devopedia.org/requirements-development
Contributed by
1 author


Last updated on
2024-01-16 06:33:30

Improve this article
  • Requirements Management
  • Requirements Traceability
  • Requirements Engineering Tools
  • Non-Functional Requirement
  • Bad Requirements
  • Security Quality Requirements Engineering

Article Warnings

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