Skip to main content

Requirements Definition Phase – Are We Done Yet?

Written by Cheryl Hill on . Posted in Articles.

RequirementsDefinition1People 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.

Criterion 1: Let the Scope be Your Guide

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:

  • Need: The problem you are trying to solve or the opportunity you want to exploit
  • Goals: Things to accomplish to meet the need
  • Objectives: Criteria for success
  • Interfaces: External entities (people, processes and systems) that will send inputs to, or receive outputs from, your product
  • Drivers and Constraints: For example, regulations, standards, existing systems used with your product, higher level requirements, schedules, budgets, stakeholder expectations
  • Operational concepts: These are stories or scenarios that describe a day-in-the-life of your product for different lifecycle phases (e.g., operations, transportation, installation, maintenance, storage, manufacturing, disposal) from different stakeholder viewpoints

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.

Criterion 2: Look at Your Models

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.

Criterion 3: Look at Your Template

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.

Criterion 4: Conduct a Requirement Review

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:

  • Make sure the requirements document is ready for review. Correct all typos, grammar problems, punctuation errors. Also, make sure that all requirements are written according to the rules for writing good requirements. We want people to focus on the content, not stupid little errors!!
  • Include all project stakeholders in the review. I also recommend that you invite knowledgeable people from outside the project to gain perspective of those not so intimately involved in developing the product requirements. These outside “experts” need to be technically competent and have worked on similar development efforts.
  • Make sure that all reviewers understand the Scope of the project. If people are reviewing the requirements with no concept of the Vision, of the scope, you are wasting everyone’s time.
  • Conduct a Review Kickoff Meeting prior to distribution of the requirements document. In this meeting, presentation topics include:
    • Purpose of the review
    • Expectations of the reviewers
    • Rules for the conduct of the review
      • Criteria for the review
      • Standards
      • Templates
      • Review comments
      • Feedback
    • The project scope
    • Other information you feel the stakeholders need to successfully perform their review tasks

The intent of the requirement review is many-fold:

  • Identify and correct errors and omissions
  • Confirm the correctness and completeness of the requirements
  • Obtain buy-in and agreement from all stakeholders
  • Set expectations
  • Get sign-off

Criterion 5: Cost/Benefit

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.

Conclusion: Are We Done Yet?

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:

  • your defined scope,
  • the developed models
  • your organization’s comprehensive requirements document templates; and
  • you enlist your stakeholders’ participation to confirm a comprehensive and correct set of requirements; and
  • you evaluate the potential costs of future changes with that required to foresee every requirement,

then you can answer that question we often hear during the requirements phase – are we done yet?

The answer??

No we are not done yet but we are done enough to proceed to design.

Don’t forget to leave your comments below

Cheryl Hill, PMP is Chief Operating Officer and senior instructor for Compliance Automation, Inc., a leading provider of requirements training and other services to help companies, government organizations, and individuals produce defect-free requirements in the most efficient and effective manner possible. Cheryl, along with all of CAI’s trainers/consultants, brings to the classroom 20+ years of real experience in project management, requirements and other areas of system engineering and business analysis. Since 1990, over 25,000 of our customers have looked to CAI for pragmatic approaches to analyzing and managing scope and requirements. At CAI, we deliver training to our customers that is necessary and of value to the individual and the organization, long after the training is complete. For more information, call us at 830-249-0308 or visit us at www.complianceautomation.com.

Views: 42