Effective requirements are a critical component of any software project. The successful gathering and documentation of these requirements depends on the collaboration between the business owners of the software and the project development team. This joint effort determines the business goals and objectives (high-level requirements), defines the detailed functional requirements to address these needs (User Stories), and identifies the technical and non-functional system requirements it will take to implement a successful product. This process highlights how requirements evolve throughout software projects.
Gathering business requirements can be accomplished through multiple methods. Initially, group meetings with project sponsors are held to understand what problems the business is trying to solve and how this relates to their company’s strategy. Additionally, stakeholder interviews and surveys can be completed to get a more in depth view of the company’s existing processes and current issues. Lastly, user observations can be conducted to further investigate discovered pain points. The information from these sources will be compiled into Business Objectives and Requirement Stories created from these objectives and requirements demonstrate the value that the project will bring to the company and/or their customers. These high-level requirements do not define how the issues will be addressed, they act as a starting point to drive solution and design discussions. The stronger the foundation and understanding of the project intentions, the better it will go when development begins. The Business Objectives and Requirements must be digested and signed off by key project stakeholders to formalize the overall effort’s intent – these can be seen as a lighthouse for the project team.
Business Requirement Story format:
As an [internal or external customer/entity]
I can [achieve business goal]
So that [value to the Internal or external customer/entity]
Example:
As an Online Product Retailer
I can offer customers multiple ways to identify items to purchase
So that our site remains competitive in the market and delivers best-in-class curated product lists
The value in this business story is achieved by offering customers options that the current system does not provide but other retailers are offering. The story does not describe any detail how this goal will be met but it does open up the conversation. Business Requirement Stories are not planned to be implementable because they describe the business need and the value of addressing it. With this understanding of the business goal, the project team can begin discussions around a design and solution. A single Business Requirement is then converted into multiple functional requirements and user stories.
The Functional and User requirements written as User Stories, describe the expected functionality and can be handed off to developers for implementation. At this level, the purpose is to breakdown the Business Objectives and Requirements into the smallest actionable unit of work while still delivering functionality that can be demonstrated & validated. To achieve this, follow-up interview sessions with stakeholders who were in the first meetings and newly identified ones will drive the additional details documented in the functional and user requirements. While conducting interview sessions, we may learn of certain needs not included in this project’s scope, but have that reside in the backlog. The results are a description of the functionality, supporting artifacts and acceptance criteria. Like the Business requirements, the Functional and User requirements remain solution neutral and describe only what is desired.
User Story format:
As a [role]
I can [functionality]
So that [user value]
Example:
As a Customer
I want to keep track of any products that I like from the online catalog
So that I can retrieve them at a later time for possible purchase
Supporting artifacts and acceptance criteria are added to the User Story to further elaborate upon the details for clarification purposes. The artifacts are an additional way to communicate to the developers what functional needs in a visual format. Examples include (but not limited to) documentation of:
• Wireframes
• Creative Designs
• Data flows
• Use Cases
The Acceptance Criteria are the necessary conditions used to validate and test the functionality. If the Acceptance Criteria is met, the User Story is considered completed. This will include descriptions of all the business rules, scenarios and the results expected in each case (both positive and negative outcomes) and should be co-authored minimally by the business analyst, developer, and QA engineer.
Acceptance Criteria Format:
Precondition [qualification]
Action [action taken]
Result [outcome]
Example:
Precondition – When a signed in customer has identified an item they are considering buying
Action – They can select and save the product
Result – Product item, color, size, and quantity are saved to the customer’s account for future review
The last step in this requirement evolution is often overlooked but equally important, the Technical and Non-Functional System requirements. These requirements can reach across multiple stories and should always be considered when developing a testing approach. Common Non-Functional System requirements are usability, security, reliability, infrastructure, and performance related. Technical requirements may take shape in defining computing hardware requirements to support the solution; specifications in how the solution integrates with other systems; or schematic designs the solution must follow. Business stakeholders will probably not have awareness of these requirements unless they have technical representation. If this is the case, the project developers will need to assist in identification of these requirements based on their expertise.
Documentation of the Technical and Non-Functional requirements can be done in more than one way and it just depends on the project team’s preference. Often referred to as “constraints”, these requirements can be added to User Stories as additional Acceptance Criteria. A constraint is a condition to make requirements align with quality expectations and is an additional validation to be sure the non-functional requirement has been met. Another possibility is to create a Technical and Non-Functional Requirement Specification document that as an additional artifact. One last way to document these requirements is to utilize the User Story format.
User Story Example:
As a CTO
I want to use the existing orders database rather than create a new one
So that we don’t increase the number of databases we have to maintain
Acceptance Criteria Example:
Precondition – When a signed in customer has identified an item they are considering buying
Action – They can select and save the product
Result – Customer Account and the associated product data are stored in the existing orders database
Gathering requirements is an evolutionary process with the focus starting on the High Level business goals and objectives. Without clear understanding of the business requirements, a solution could be developed that will not meet the intended project vision. However, if the time is spent up front there is a much higher probability that once implemented, the detailed and the technical nonfunctional system requirements will produce value to both the business and their external customers