Question: Did you meet the requirements?
Right Answer: Yes, let me show you our requirements matrix …
Wrong answer: What requirements?
Problem:
OK so you (and your team) are about done with the project. You’ve tested it and got most all the bugs out. You even wrote some documentation for whoever will have to maintain your code in the future (aren’t you proud of yourselves for doing that, even though nobody asked!). Now comes the $1 Million question: does the code you produce meet all the requirements? Well you said, we never got real requirement, the sales team just said it had to work like the last version but had to have a Bluetooth interface in addition to the WiFi, so that’s what we did.
Hmm, that’s when the real problem starts. See, without formal requirements, you assumed the Bluetooth and the WiFi didn’t have to be on at the same time, the sales guy thought that was a given so he didn’t even mention it. Nobody said anything about the extra LED on the top of the box that the mechanical guy made a hole for, and the display menu doesn’t say anything about a Bluetooth option (since it was supposed to the same display menu as the last product)!
Now you have to back to the drawing board, sit down with the marketing team and figure out what they really wanted, and the project is going to be 2 months late. It’s the same thing every time, there’s got to be a better way!
Solution:
The first step in your development process should have a formal requirement document as a deliverable. Do not start coding without one! Tell your boss your job and hers depend on it.
Good requirements provide:
– guidance on what needs to be done,
– agreement between the provider and the client on what the deliverables are,
– basis for the next documents such as the sub system requirements, test requirements, etc.
Who should write the requirements? In a properly run gate and phase projects, there are probably more than one set of requirements, each with different author. Most likely the first one come from the marketing team as marketing requirements. It’s used in the early gate to get the project going. That marketing requirements is then used by the engineering team to write the engineering requirements, and the tests requirements, and so on. In the waterfall development model, those requirements are usually fairly static and do change very often. In the Agile style of development, they can be broken down in much smaller documents and revised on much faster cycle.
So, help your team, have the “Right Answer”.
