Requirements are requirements, right? You need a bunch of them to make up a project and you can tweak them along the way, if necessary….right? Wrong! It’s never a good idea to get the project underway with requirements that are less than adequate or that you know need more detail that “can be dealt with later on.” It’s a recipe for disaster. It’s a recipe for uncontrollable scope creep. Or worse, a never-ending stream of change orders that will infuriate your project customer. And they’ll blame you for letting the whole project start before it was ready to start.
Seriously, the quality of the customer requirements means everything to the project. Good, complete, detailed projects mean you start out knowing how to create and what you’re creating. Poorly defined requirements mean you’re always going to be facing risks…always going to be pushing the ceiling of the project budget…always going to be in danger of facing some degree of rework and retooling of the requirements or some key functionalities. It’s a very bad idea to start the project off with bad requirements. But how do you know what bad requirements are? Well, let’s examine that questions further….
A generally accepted list of qualities of good requirements is…
They are truly actually attainable
Your requirements need to be truly attainable. It must be within the budget and schedule and be technically feasible. Don’t write requirements for things that cannot be built or that are not reasonably within the project budget. If you do, it’s a waste of time and effort.
Many feasibility questions will not necessarily be clear-cut. You may not have the expertise to judge whether a requirement is technically feasible. If that is the case, make sure you include members of the development team in the review process to foresee technical problems. Your team may need to conduct research to determine a requirement’s feasibility before it is added to the product baseline. If this research still leaves you uncertain about the feasibility of what you want, consider stating the need as a goal rather than as a requirement. If you can’t back off to a less demanding but obviously feasible requirement, you will have to identify the requirement as a risk and monitor it with other risks and issues throughout the project.
They meet a specific project or customer need
A requirement is a basically a statement of something someone needs. The something is a product or solution that performs a service or function. The someone may be a company, a user, a customer, support, testers, or another product.
Generally, you must 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. The definition of need will depend on the context or circumstances. For instance, if you are spending taxpayers’ or shareholders’ money, need will be narrowly defined. For commercial products, a consumer want is a need for your product when it tips the consumer’s buy decision in your product’s favor.
They are clear and concise…and understandable
A good requirement cannot be misunderstood. It expresses a single thought. It is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements. If possible, decide on specific names for your solution or product and deliverables and refer to them by name alone in your requirements. Use consistent language. As you define subsystems, name them also and refer to them only by those names. Use acronyms if you have to in order to keep them short. The less complex and more consistent everything is from requirement to requirement, the better. Too many words and too many references breed inconsistency and confusion.
They are somehow 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. Determine the specific criteria for product acceptance, which will ensure verifiable requirements.
Summary
Requirements will never be perfect. You could write books about your customer’s requirements and still leave something out. But do make sure that they are as detailed as possible. Do this test…do you feel comfortable building a solution against them? If you don’t, then they probably are not detailed enough. Go back and do more work.
Seriously, the quality of the customer requirements means everything to the project. Good, complete, detailed projects mean you start out knowing how to create and what you’re creating. Poorly defined requirements mean you’re always going to be facing risks…always going to be pushing the ceiling of the project budget…always going to be in danger of facing some degree of rework and retooling of the requirements or some key functionalities. It’s a very bad idea to start the project off with bad requirements. But how do you know what bad requirements are? Well, let’s examine that questions further….
A generally accepted list of qualities of good requirements is…
They are truly actually attainable
Your requirements need to be truly attainable. It must be within the budget and schedule and be technically feasible. Don’t write requirements for things that cannot be built or that are not reasonably within the project budget. If you do, it’s a waste of time and effort.
Many feasibility questions will not necessarily be clear-cut. You may not have the expertise to judge whether a requirement is technically feasible. If that is the case, make sure you include members of the development team in the review process to foresee technical problems. Your team may need to conduct research to determine a requirement’s feasibility before it is added to the product baseline. If this research still leaves you uncertain about the feasibility of what you want, consider stating the need as a goal rather than as a requirement. If you can’t back off to a less demanding but obviously feasible requirement, you will have to identify the requirement as a risk and monitor it with other risks and issues throughout the project.
They meet a specific project or customer need
A requirement is a basically a statement of something someone needs. The something is a product or solution that performs a service or function. The someone may be a company, a user, a customer, support, testers, or another product.
Generally, you must 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. The definition of need will depend on the context or circumstances. For instance, if you are spending taxpayers’ or shareholders’ money, need will be narrowly defined. For commercial products, a consumer want is a need for your product when it tips the consumer’s buy decision in your product’s favor.
They are clear and concise…and understandable
A good requirement cannot be misunderstood. It expresses a single thought. It is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements. If possible, decide on specific names for your solution or product and deliverables and refer to them by name alone in your requirements. Use consistent language. As you define subsystems, name them also and refer to them only by those names. Use acronyms if you have to in order to keep them short. The less complex and more consistent everything is from requirement to requirement, the better. Too many words and too many references breed inconsistency and confusion.
They are somehow 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. Determine the specific criteria for product acceptance, which will ensure verifiable requirements.
Summary
Requirements will never be perfect. You could write books about your customer’s requirements and still leave something out. But do make sure that they are as detailed as possible. Do this test…do you feel comfortable building a solution against them? If you don’t, then they probably are not detailed enough. Go back and do more work.
RSS Feed
