Writing effective business requirements

In many organisations, several different people sit between the software developer and the end user. The number varies depending on the size and operational style of the organisation, but very rarely will a software developer be directly interacting with end users. These people who sit between developers and end users (which may include product managers, product owners, business analysts, or project managers) are responsible for eliciting requirements and documenting them in a way that makes sense to both users and developers.

When capturing requirements, however, it is very easy to miss the business need and communicate only the functional requirement. For example – if a project team is developing a website where a large portion of end users are vision impaired, one requirement might be to ensure that the text size can easily be scaled up:

BR10: When using a supported web browser, the user must be able to increase and decrease the text size.

Unfortunately, a business requirement written in this way only communicates what should happen, and not why. Even though this requirement has a clearly testable outcome, there are many other changes required which would make larger text readable on a webpage, such as ensuring that the text field with the new, larger text still fits within the screen's width (responsive design). But as the need for this requirement was not communicated, these details were missed, and during the customer's review they are presented with a product which does not meet their expectations. Even though the text can be increased, why does it stretch past the width of the screen? It should still fit on the screen so it is readable! The response from the development team would be "that requirement wasn't specified".

One way to avoid this communication gap is to write requirements in the form of user stories:

• AS A user with impaired vision
• I WANT TO increase the size of the text on the webpage
• SO THAT I can read the information.

This method of communicating software requirements tells the development and quality assurance teams exactly why the requirement exists, and allows the team members to ask questions and provide their own suggestions up-front, rather than the customer picking up this missing functionality during User Acceptance Testing.

User stories are designed to be a conversation starter, and are not supposed to communicate technical requirements. These still need to be recorded as success criteria, which should follow SMART goals. For example, a login control would require detailed technical and functional documentation. Trying to write "I want user's passwords to be secure" as a user story doesn't provide any benefit over a traditional business requirement. In this case, the conversation starter should be "how do we ensure our login is secure?", and the minimum password requirements would be successes condition on the user story. For example:

• AS A risk manager
• I WANT TO ensure that our website's login is secure
• SO THAT our customer's data is not at risk of being accessed by someone other than the customer.

Success criteria:

1. Passwords must contain at least one letter and one number.
2. Passwords must be at least 8 characters long.
3. Passwords must not start with the word "password".
4. ...

The user story on its own is not specific, measurable, assignable, realistic, or time-related. However, when combined with success criteria which the development and quality assurance teams contribute to, it results in a requirement which effectively communicates the business need as well as providing the functional or technical expectations.