At the root of every successful movie played in a theatre will be a well written story board. This is also the case with a good quality software. It’s important to know how to write software requirements because they are vital to the the design stage of any quality software. Customers or stakeholders often think that simply conveying requirements over the phone or by email will be enough to instruct the build, but that’s not the case. These raw requirements must be converted into a software requirements specification to make it easier for the dev to design the software exactly the way the customer envisions. Let’s find out how to write good software requirements.
Why Write Good Quality Software Requirements?
- Writing software requirements will help capture even the smallest details of the customer needs.
- Capturing every details of requirements will help dev achieve great code coverage which will lead to lesser bugs.
- Will help the dev in understanding the business rules better.
- Stake holders can give early feedback on what they intend to see with the software.
Process of Writing Good Software Requirements
In Agile software models, customer requirements are more commonly referred to as User Stories. A good user story should contain the following information.
- Who the requirement is for
- What output will the user expect to see?
- What actions will bring about the output?
User stories can also include ‘conditions of satisfaction’. These terms elaborate the user stories with much more clarity and detail.
Since the Agile software model was created, Mike Cohn, the co-founder of Scrum methodology, proposed a template to write an effective software requirement using the Keywords As, When and Then. The template will look like:
As <user> when < this action happens> then <this will be the output>
“As a retail customer When I click on Login button Then I should be logged into the app and see the home page.”
Here its very important that we specify the usertype. Because in a software there may be many types of users and each user type can have different output for the same action. So its imperative that we specify the usertype for each requirement.
Once we have defined the user story it’s very important that we describe it further. We can do this using conditions of satisfaction, as pointed below:
“As a retail customer, When I click on Login button, Then I should be logged into the app and see the home page.”
- Valid credentials must be entered
- An error message should be shown for invalid credentials
- An error message should be shown for blank credentials
- A loading indicator should be shown during navigation to the home page
- An error message should be shown if the internet connection/server cannot be reached
As you can see from the user story above that covers all the scenarios related to the login functionality, more criteria have been defined so further help to clarify the requirements.
User stories can also be illustrated using wireframes and workflow diagrams as needed.
Tips for when writing Software Requirements
We’ve previously discussed how to write better requirements, but we can list out a few further important tips which you might want to take into account while writing software requirements.
- Write requirement from the customer’s point of view. Try to avoid including any technical terms within it.
- Requirements should be testable. Testers should be able to easily design their test cases from the requirements.
- Requirements should be clear and consistent. Don’t use words or phrases that could be ambiguous or that lack clarity such as – maybe, user-friendly, properly, or fast. You need to be clear on the exact standards that are needed.
- Requirements should be logically written to make it easy for test cases and other design specs to trace back, and visa versa, at any time.
Benefits of having Good Software Requirements
- Better Customer satisfaction
- Reducing the costs of changes and last minute bug fixes
- Maintaining the history of software evolution
A well written software requirement is the building block of any software. Whether you are creating the technical spec or the actual test cases themselves, they all refer back to the original requirement. If you can follow the templates that we discussed here you can write solid software requirements and help develop good quality software applications.