Can you really start a project without requirements? I know I certainly don’t feel comfortable – even for a short project – starting a project and trying to manage scope without detailed requirements in place for the project. Requirements are key – they are the lifeblood of the project. If you try to build an end solution with only high-level requirements, it won’t work. If you try to deliver something to the end user with knowing what they really need the system to perform – what they require of this solution you are providing them with – you may be delivering something they can’t even use. If you haven’t worked with the customer’s subject matter experts (SMEs) and end users to know what the problem is and what they need, then you have no scope to start from…everything is really just a best guess. And that’s a bad situation – for everyone – but mostly for the project manager and team who will be on the hook to deliver a workable end solution. And it just won’t happen.
What do good requirements mean?
What are good requirements? What are the characteristics of a good requirement? In project management, there are some general criteria that requirements are usually held against to see if they are adequate and appropriate and in the proper detail. If your requirements meet these, then congratulations…you have detailed requirements and you have a basis that you should be able to start from to deliver what they customer wants and needs. Good requirements, generally…
Meet specific existing or future needs
In simple terms, a requirement is a basically a statement of something someone needs. The something is a product or solution that performs a service or function. That may be an end user, the customer, a tester, or some other third party or stakeholder. Also, the project team needs to be able to distinguish between needs and wants. Even if it is verifiable, attainable and well stated, a requirement that is not necessary is not a good requirement – at that point it just becomes gold plating.
Are clear and understandable
When developing your requirements, try to leave no room for interpretation. If there is room, then the requirement is not detailed enough or needs to be broken down further. Also, a truly good requirement cannot be misunderstood. It expresses a single thought and is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements to avoid confusion and interpretation.
Also, use positively whenever possible. It is easier to develop and test a product that does something specific than one that does not do something specific. Proving the positive when testing a requirement is much more straightforward than trying to prove the negative. And finally, make your requirements grammatically correct to ensure proper understanding.
Are attainable
Make sure that the requirement is something that can actually be achieved. It must be within the budget and schedule and be feasible. Don’t write requirements for things that cannot be built or that are not reasonably within the project budget constraints that you and your team have been given. If there are questions on feasibility, reach out to others outside of the project or project team to help answer questions.
Are verifiable
A requirement must state something that can be verified by inspection, analysis, test, or demonstration. As you review a requirement, think about how you will prove that the product meets it. How will you test that the end solution is delivering what the requirement is stating as a need? Determine the specific criteria for product acceptance, which will ensure verifiable requirements.
Summary
Good, detailed requirements are not an exact science…though it sure would be easier if they were. There’s no special machine that helps spits out good requirements for the project so scope will always be somewhat of a risk on every project. But making sure your requirements meet the criteria discussed in this article will help minimize that risk and help to ensure that you’re building the right solution – avoiding the re-work that often comes with poorly documented or incomplete requirements.
