# Requirements Development

## Summary


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?

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?

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?

**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?

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?

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

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

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

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

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

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

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.