The goal of requirements documentation, or specification, is to state each need of the proposed system or process (who, what, where, when and why) precisely and thoroughly.
Requirements documentation is used to guide the development or configuration of a product or system.
It’s created during the project initiation or scoping phase and is managed throughout the project.
In the case of a RFP (Request for Proposal) for a third-party provided solution, this documentation defines what the procurer wants to buy and what the supplier is required to provide and becomes part of the contract.
Requirements can be specified in either a comprehensive document or a suite of user stories or use cases.
Your project characteristics will influence the method that will work best
Requirements Specifications and Use Cases are typically “BDUF” – Big Design Up Front, as all requirements either are or must be known up front.
This is especially important and useful when purchasing existing systems or services that will require (or allow) little to no enhancements (e.g., when a RFQ/RFP (Request for Quote or Request for Proposal is used).
User stories are typically “DJIT” – Design Just In Time. Therefore, user stories can be more beneficial with an Agile methodology when a custom solution must be developed or major enhancements made to a commercial solution.
Regardless of the format used to document the requirements, it is important (at a minimum) to note the following information for each requirement:
Unique identifier
Description
Priority
Prioritization sets expectations about which requirements are the most important and should be addressed first.
It also helps resolve conflicts, plan for staged deliveries, and make any necessary trade-off decisions.
Source (the stakeholder who defined the requirement)
This is helpful if additional information if needed
1. Requirement Specifications
A Requirement Specification is a comprehensive document which contains all related requirement information in a single document or in a parent document that contains links to supporting information.
It is used to communicate everything that must be included in a system for it to be considered complete.
A Requirement Specification must always include the following:
Functional Requirements
A functional requirement describes what a system or product must do; it specifies the actions, tasks, and operations that a system needs to perform to fulfill user needs and achieve its goals along with the input, behavior, and expected output under specific conditions
Non-functional requirements (NFRs) define the quality attributes, system constraints, and performance characteristics of a system rather than its specific functionalities. They describe how a system should behave rather than what it should do.
A Requirement Specification may also include the following:
Business or System Objectives
User experience (UX) or process flow diagrams
Screen mockups or wireframes to illustrate the system’s proposed design to facilitate understanding and interpretation of the requirements
Environment requirements
Assumptions, constraints & dependencies
The Requirements Specification Template (Spreadsheet) is a spreadsheet template for documenting functional and non-functional requirements in a standard, list format that has built-in option selections for Priority, usage instructions, and a suggested list of Non-Functional requirements provided by the Standards and Architecture Frameworks boards.
The Requirements Specification Template (Word) is a template for documenting Requirements Specifications in a more flexible, textual format with additional sections (e.g., Purpose, Business Objectives & Scope, Glossary, Assumptions & Constraints, Training Requirements, References, Appendices).
2. User Stories
A User Story is an agile-friendly, informal way of capturing requirements from an end-user’s perspective that describes a feature or functionality in simple, non-technical language.
User stories emphasize the who, what, and why of a requirement and are often accompanied by Acceptance Criteria, which define conditions for successful implementation.
The standard format for writing User Stories is: “As a [user role], I want [feature or capability] so that [reason/benefit].”
Example: “As a customer, I want to receive an email confirmation after placing an order so that I have proof of my purchase.”
Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project. Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration.
The User Story Guide provides more detail for creating all levels of user stories.
3. Use Cases
A Use Case is a detailed and structured sequence of interactions that describe how a system interacts with users (or external systems) to achieve a specific goal.
Each use case should convey what the business rules are that govern the activity, the options that the actor will have available to them when undertaking the activity, the ways things could go wrong and what bits of information are needed in the flow of interactions.
A use case typically includes the following components:
Name (a brief, unique name for the scenario)
Description (what the scenario is meant to convey)
Actors (users or systems interacting with the system)
Preconditions (conditions that must be met before execution)
Basic Flow (primary steps of interaction)
Alternative Flows (variations in behavior)
Exceptions (error conditions and system responses)
Post-Conditions (resulting state after the use case has been executed)
Visual Model (diagram depicting the actors and events/activities)
The Use Case Guide provides more detail and step-by-step instructions for creating use cases.
Requirement analysis is the process of reviewing the documented requirements to ensure that:
Requirements are clear in their purpose
What seems obvious to you as a business analyst may not be to your developers or customers.
The success measurement for an effective, written requirement is one that is easily understood so the best product possible can be built or selected the first time.
Requirements are complete with regards to the project or the process
There are no missing requirements
Requirements are prioritized
Requirement analysis may also include an assessment of the impact of any proposed changes to an existing system that may need to integrate with the new or modified product.
After you define your requirements, you must effectively communicate them to necessary stakeholders to provide them with an opportunity to express feedback, request adjustments, and agree or provide approvals.
Once these stakeholders have agreed to the requirements, the RFP (Request for Proposal) or system development process can begin.
Communicating information does not simply involve pushing information out and assuming it was received and understood. The method of delivering the information may need to change if the stakeholders are not receiving or understanding it. Multiple forms of communication might be required for the same information, though reviews are best executed during group or individual collaboration meetings.
While it may seem like a good idea to allow stakeholders to individually review requirements when it works for them, it rarely (if ever) works out that way. In today’s workplace, people have competing priorities and are constantly multi-tasking – and let’s be honest, reviewing project requirements is probably not the most pressing task on their list. Few stakeholders will provide their best input in this manner. When you sit down to review the requirements in a meeting, you know that people are actually reviewing and assessing them. You may also find that one comment leads to another, which can help discover missing or misunderstood requirements before it’s too late.If the stakeholders (i.e., the people benefiting from and contributing to the project) indicate that they can’t spend a couple of hours in a room finalizing what exactly that project is supposed to do.