4.1. Requirements capture¶
The first step is to have a good understanding of what functionality the program has to have. This includes an understanding of what constraints are present.
Documenting the requirements or specifications, before you start, is essential for any project. This is important to ensure that everybody is on the same page, and to define what success looks like and how you will know whether you’ve achieved it or not. You don’t want cases where (say) you think your software only has to run on Windows, but your customer thinks it has to run on both Windows and macOS. Or (say) a case where you’re detecting number plates from vehicles in a car park, and you think this only covers cars but your customer thinks this covers both cars and motorbikes. Or, you think you need to detect 99% of the number plates correctly in order for the software to be successful, but your customer thinks it needs to be 99.9%.
You can always change the requirements later on if the project evolves in scope, but this is changing from a fixed established base, and you can ask for more time or money or resources to support the change. In the example above, the software that the customer wants is likely to take much longer to develop and test; and so it will cost more money. It’s very common for clients to implicitly or explicitly want feature creep. That is, more and more features to be added but without giving you any more time or money for adding them. Having a formal requirements capture, that they’ve agreed to in advance, helps stop this from happening.
Sometimes there are factors that you won’t know the answer to until you have an initial proof of concept in place and can do some preliminary tests. (In the example above, preliminary tests might show that 90% is the best you can get in real-world settings so the performance target will need revising.) Sometimes things are just overlooked. (In the example above, is run time important?) There are formal techniques to guide requirements capture and help make sure that you don’t forget any important factors. Overall though, the most important thing is to write down the requirements that you do have so that they are fixed and agreed upon as best possible.
EEEN11202 course notes