When embarking on any software project, from the development of a new system down to a small change to an existing system, it’s important to have a clear statement of what that project should achieve. However, capturing and documenting requirements can be a tricky process, so here are a few tips to check whether your requirements specification does its job.
1. Are the business aims clear? Rather than launching straight into what you want to change, take a step back and state why you want to change it. There may be a simpler solution that you haven’t considered. Starting from this point will also help ensure that all the requirements are relevant to the project.
2. Should the project be broken into parts? It’s quicker and lower-risk to break things down into small steps, and it’s easier to specify the correct requirements for the next step once the previous step has been implemented.
3. Are all the inputs and outputs clearly specified? Samples of real data are helpful at this point, to ensure that the complete range of possible values will be handled correctly.
4. Are all use cases covered? End-users may require different things from the product, depending on their role – the requirements should take account of all their needs, while ensuring that there isn’t any conflict between them.
5. Do all parties involved understand the requirements? Explain any jargon or acronyms, and guard against vagueness – for example, if you’re changing an existing product make sure references to pages/forms/fields are unambiguous.
6. Are all the requirements achievable? There’s no point including something that can’t be implemented, however happy that would make some stakeholder in the project.
7. Are all the requirements testable? It should be possible to design a set of test cases that will show whether the requirements have been met.
8. Are the requirements complete? Ultimately, this is the measure of the success of the project: if all the requirements are met, then will the end result be acceptable?
Requirements gathering can seem an unwelcome distraction when you’re keen to get on with a project. But ultimately the time is well-spent, ensuring that the scope and cost are clear from the start and preventing time-consuming and costly fixes later.
The DataSalon Blog 