CDC Home

Project Management Newsletter

Defining and Managing Requirements

Newsletter Archive
Click Here to Subscribe

Volume 1 | Issue 7 | October 2007

Daniel Vitek, MBA, PMP

Requirements management is a systematic approach to finding, documenting, organizing, and tracking requirements and any changes that may occur to those requirements throughout the life of the project. Managing requirements effectively helps to ensure that the end product meets the needs and expectations of all project’s stakeholders.

Defining requirements effectively simply means figuring out what to make before starting to make it, keeping in mind that the end product should suit the needs of the client rather than the client suit the product.

Requirements are defined during the planning phase of a project by the Business Analyst and managed throughout the entire process from high level requirements, detailed requirements, design, build, and test. The practice of requirements management includes three high-level practice areas:

  • Requirement definition
  • Requirement gathering
  • Requirement traceability

The practice of requirements definition is part of an overarching requirements management practice. This overarching practice is a systematic approach to finding, documenting, organizing, and tracking requirements and the changes that may occur throughout the life of a project.

Projects often encounter major difficulties because they lack clearly defined and documented requirements. A key step to successful requirements management is for all appropriate stakeholders to determine and agree upon specific requirements gathering processes, documentation techniques, traceability, and testing expectations.

The further along the project is in its life cycle the more costly it becomes to correct errors. The cost of correcting a requirement error increases exponentially as the project matures. For example, to correct a requirement error in the operation stage could cost a multiple of 100-times or more than if that same error was fixed earlier in the project’s life.
One way to avoid this and other project issues is by properly defining project requirements. Defining requirements correctly in the early stages of the project is often the single most important practice that prevents costly errors and increases the potential for project success. The challenge however, is to get business stakeholders, end-users, and project teams all on the same page in regards to those requirements.

Requirements definition is often the main practice that serves as a bridge between project teams and business stakeholders. The practice should define both product and project requirements as well as related functional and non-functional requirements.

Properly defined requirements provide the first view of what the intended product must do and how it should perform. They provide a basis for product design and serves as a foundation for testing and user acceptance of the end product by identifying the goals, needs, and objectives of the project.

Sources used to define requirements may come from across the organization and may include input from areas such as management, marketing, legal departments, end-users, business analysis, system engineers, technology specialists, etc.

Requirements definition should begin early in the planning phase. Requirements should then be managed throughout the life of a project from their high level, through detailed requirements, design, build, and test. Requirements captured at all business and product levels help to ensure that the project meets its objectives within the agreed upon limitations of time, scope, resources, and quality.

A well defined requirements definition document establishes a solid foundation for all stakeholders to agree upon the project’s product requirements. It is also good practice for the project team to map business processes with associated project objectives to ensure that the project’s scope aligns with the organization’s goals and objectives. Early agreement and understanding by all project participants, as to what needs to be accomplished, ultimately reduces development and testing efforts, provides a basis for estimating costs and schedules, serve as a baseline for enhancements, and can be used as a tool to verify/validate requirements.

For requirements to be effectively translated into a product they must be clearly understood by the individual building the product’s functionality. This is accomplished by documenting defined requirements in clear and consistent way. A well documented requirement should describe the capabilities of the solution, any conditions that must exist for the requirement to operate, and any constraints that may prevent the solution from being able to fulfill the requirements.

Effective requirements definition also more closely aligns organizational and project expectations of the project’s outcome which results in fewer requirement errors, less rework, and an overall increase in successful project delivery.

Requirements gathering is a sub-practice area of requirements management. Requirements gathering is an iterative process that involves interacting with the client to gain consensus on the details of defined requirements. There is no one perfect method for gathering and analyzing requirements. The most appropriate method for gathering requirements differs from project to project. The important part is to maintain focus on the project objectives as they align with requirements and stakeholder expectations.

Requirements tracing is another sub-practice area of requirements management. Requirements tracing is a practice more specific to systems development and is defined as the ability to describe and follow the life of a requirement, in both a forward and a backward direction throughout the entire project’s life cycle. Requirements tracing captures all levels of requirements and helps ensure that the project meets client expectations.

Requirements traceability can be considered the backbone of any project and helps verify accurate delivery to meet client expectations. Tracing requirements through the entire life cycle provides the ability to ascertain that technical requirements have been satisfied by functional requirements that will in turn satisfy business requirements; from project scope to high level requirements to detailed design, down through coding, and testing.

Verifying requirements is a process that improves the accuracy and completeness of project requirements as they are added to the final product. There is no one perfect method for verifying requirements. The most appropriate method for verifying requirements differs from project-to-project and even requirement-to-requirement. However, this practice decreases the need for rework and increases overall stakeholder satisfaction because requirements are verified through interaction with the client, project team, and other stakeholders.

For more information and tools related to the topic(s) covered in this newsletter, the CDC Unified Process, or the Project Management Community of Practice please visit the CDC Unified Process website at

Please also visit the CDC Unified Process Newsletter Archive located at for access to many additional newsletters, articles, and management related topics and information.


The CDC UP offers a short overview presentation to any CDC FTE or Non-FTE group. Presentations are often performed at your location, on a day of the week convenient for your group, and typically take place over lunch structured as one hour lunch-and-learn style meeting.

Contact the CDC Unified Process at or visit to arrange a short overview presentation for your group.


The CDC Unified Process Project Management Newsletter is authored by Daniel Vitek, MBA, PMP and published by the Office of Surveillance, Epidemiology, and Laboratory Services.

For questions about the CDC Unified Process, comments regarding this newsletter, suggestions for future newsletter topics, or to subscribe to the CDC Unified Process Project Management Newsletter please contact the CDC Unified Process or visit



  • February 23, 2007
    Topic: Managing Virtual Teams
  • March 23, 2007
    Topic: Earned Value Management
  • April 27, 2007
    Topic: Weathering Project Ups and Downs
  • May 18, 2007
    Topic: Tools, Tools, Tools
  • June 22, 2007
    Topic: Enterprise Architecture
  • July 27, 2007
    Topic: Expectation Management
  • August 24, 2007
    Topic: Analysis of Business Analysis
  • September 30, 2007
    Topic: Tips for Delivering Projects on Schedule
  • October 26, 2007
    Topic: Effective Project Management for Public Health IT Initiatives
  • December 07, 2007
    Topic: The Inadvertent Project Manager


Add This Socialize the CDC Unified Process: The U.S. Government's Official Web PortalDepartment of Health and Human Services
Centers for Disease Control and Prevention   1600 Clifton Rd. Atlanta, GA 30333, USA
800-CDC-INFO (800-232-4636) TTY: (888) 232-6348, 24 Hours/Every Day -

A-Z Index

  1. A
  2. B
  3. C
  4. D
  5. E
  6. F
  7. G
  8. H
  9. I
  10. J
  11. K
  12. L
  13. M
  14. N
  15. O
  16. P
  17. Q
  18. R
  19. S
  20. T
  21. U
  22. V
  23. W
  24. X
  25. Y
  26. Z
  27. #