Services | Develop Actionable Requirements
GET STARTED!Requirement: A capability or quality that a product, process, or person must possess or exhibit in order to be suitable for a given purpose or role.
Documented requirements are one of the primary technical design artifacts of an organization’s software engineering process. By capturing the “who”, “what”, and “why” of each requirement, along with acceptance criteria, in a simple, concise, and consistent way, they:
- Communicate design intent in as much detail as necessary and with as little ambiguity and subjectivity as possible,
- Encourage in-depth and detailed analysis and design during the iterative process of creating the requirement,
- Define the features, capabilities, and qualities that a system must provide,
- Inform build vs buy decisions and provide “shopping list” criteria,
- Enable estimation, prioritization, planning, and tracking,
- Support testing and quality assurance (QA), and
- Facilitate project and requirements management.
Requirements may be business or technical and functional or non-functional. Technical, functional requirements should specify the features and functionality with which users will interact directly, like user interface (UI), business processes and rules, and data persistence and retrieval. “Non-functional” requirements generally describe qualities that support the application and its users like availability and performance criteria, system logging, and exception handling.
Well-written requirements contain detailed, specific, and objectively verifiable acceptance criteria and establish the standard that the requirement will need to meet in order to be considered complete. Rather than the older “the system shall” requirement style, modern requirements are often expressed in terms of single interactions between a user and the system (aka “user stories“) and:
- Enumerate and clarify all relevant system preconditions, the nature of the interaction itself, and all relevant system postconditions,
- Encourage engineers to realistically consider the effort required for testing and QA and to include this effort in their estimates,
- Suggest a minimum set of automated unit test cases that can demonstrate successful completion, identify defects and other issues, and prevent regression as the code base changes over time, and
- Form the basis of test plans for formal QA and user acceptance testing (UAT).
In the context of a project plan that establishes a clear mission and specific, measurable, related objectives, requirements should provide “traceability”, clearly helping to accomplish the mission by supporting one or more objectives and one or more user personas. This traceability may be implemented with descriptive tags or labels that can effectively group requirements.
Requirements, including their revisions, comments, supporting documentation, etc, also establish a history of the project’s evolution and the team’s progress toward a better understanding of each requirement and project’s objectives and mission. At the end of the project the body of completed user stories should clearly establish the delivery of all business and technical requirements and the successful completion of the project.
Capturing requirements can best be accomplished by listening carefully to stakeholders, taking notes, analyzing, asking clarifying questions, documenting, building concensus, and promoting complete transparency.
Let’s create a clear picture of what is required, lay the foundation for successful work, and give your teams and stakeholders the best chance for success!