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!

Templates

Examples