by Cheryl Hill, PMP
People often ask me “how do we know when we are done with the requirements phase?” My opinion? You are never completely done with requirements but criteria do exist by which you can assess the completeness of your requirements and gauge your readiness to proceed with design.
Okay, my assumption is that your project has a defined Scope. You know, that’s the document you produce at the outset of the project that serves as the foundation for writing requirements. As a refresher, the components of Scope are:
Every requirement you write should be in response to one or more components of the project’s scope. If the requirement does not help you meet the scope, you probably don’t need it. This said, look at the components of your scope and ask yourself, have you defined the requirements necessary to meet the need, goals, objectives, interfaces, drivers and constraints? Have you documented all the requirements that you derived from the operational concepts? If you answered yes to all these questions, you may be ready to baseline your requirements and proceed to Design, but just to make sure, I recommend that you apply additional criteria.
If you developed models using business process, object-oriented, or structured analysis techniques, then you have on-hand a great way to verify that you have a complete set of requirements. When I speak of models, I am referring to Activity Diagrams, Swim Lane Diagrams, Flowcharts, DFDs, ERDs and the like. I am a staunch advocate of modeling. Developing models is a great way to engage the stakeholder and get them to communicate their requirements in a non-intimidating and comprehensive way. By non-intimidating I mean- how scary is it to draw a picture to graphically present what is done today or that which is wanted in the future? Comprehensive? With a picture, you can easily validate steps and decision points and identify errors and omissions.
When I assess the completeness of my requirements, I prefer to work from both my current state and future state diagrams. By analyzing both states, I increase my confidence level that I have the requirements to sustain existing function, performance, and compliance needs as well as define the requirements essential to achieve the defined Vision and scope.
Did you use a standard outline or template for your requirements? Many organizations have developed standard templates for different type of projects…hardware projects, software projects, maintenance, upgrades, etc. A well-constructed template lists the different types of requirements that are typical for the various types of projects/products of an organization. So, if you use a template, make sure that all relevant requirements have been gathered and documented. Excuse me for stating the obvious but a big hole in your template is a pretty good indicator that you are missing some requirements.
I know…the dreaded review…with your gasp stakeholders!!! But you know, a requirement review does NOT have to be a horrifying experience and it really is the BEST way to ensure that you have a complete set of requirements.
Follow these simple rules and the pain you associate with the requirement review will be minimized:
The intent of the requirement review is many-fold:
Okay, I admit, regardless of what you do to validate you are done with the requirements phase, you still have those “hand-wringers” that refuse to sign-off for fear you are missing some really important requirements. You think you have all the requirements, the majority of the stakeholders think that you have all the requirements, but you, and probably everybody else, secretly want a single one indicator that screams that you have ALL the requirements and are ready to baseline and start designing. Sorry, no such indicator exists. If you are in a quandary about whether you are done with requirements or not ask yourself this question…
What will cost LESS – potential downstream changes because I forgot some requirements or the time, schedule and resource investment required to make sure that I have defined every possible requirement?
A word of caution…there are people who are on the other side of the spectrum from the hand-wringers…I call these people the Schedule Mongers. Schedule Mongers are those who insist on starting the next phase of a project irrespective of the status of the current phase because “see it’s on the schedule and if it’s on the schedule, we HAVE to start!!” When assessing the readiness to move to Design, the Schedule Monger does not necessarily care if the requirements are done and is oblivious to, or in denial of, the fact that starting without a good set of requirements will definitely cause a slip to the product delivery, add costs, and probably result in unsatisfied customers. So beware the Schedule Monger and know that the question you ask about the risk (cost) of proceeding, or not, is just as applicable when dealing with the Schedule Monger as it is with the hand-wringer.
Ludwig Wittgenstein stated “The riddle does not exist. If the question can be put at all, then it can also be answered.”
Hmmm…I suspect that Ludwig never had to deal with requirements!!!
You will never be done with requirements because things change – businesses change, technology changes, competition changes, people change. And, it is because of this inevitable change I feel that the question “When do we know we are done?” cannot be answered with 100% confidence.
However, if you assess requirement completeness within the confines of:
then you can answer that question we often hear during the requirements phase – are we done yet?
No we are not done yet but we are DONE enough to proceed to design.
Do you have a “requirement” question you would like the Requirements Experts team to address? If so, please visit www.reqexperts.com and contact us.
You might also find interesting: