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