Centers for Disease Control and Prevention - Your Online Source for Credible Health Information

Search The CDC Search Button



Requirements Management

Newsletter Archive Click Here to Subscribe

Volume 3 | Issue 9 | September 2009

Daniel Vitek, MBA, PMP

Requirements management is a systematic approach to finding, documenting, organizing, and tracking requirements and any changes that may occur throughout the project’s life cycle. Diligent requirements Management helps to ensure that the end product meets the needs and expectations of sponsors and stakeholders. Key to effective requirements management is the predetermination and agreement of specific requirements gathering processes, and documentation, traceability, and validation expectations.

REQUIREMENTS DEFINITION
Defining requirements early in the life cycle of a project provides stakeholders the first view into what the intended project outcome must achieve and how it should perform. This practice establishes the basis for design and serves as a foundation for testing, user acceptance of the end product or service, helps to ensure that project efforts meet their intended objectives within the boundaries of agreed upon time, cost, and scope by asking questions such as:

• What problem are we trying to solve?
• What do we need to do to solve the problem?
• How do we accomplish solving the problem?

REQUIREMENTS GATHERING
Requirement gathering is an iterative process that involves interacting with stakeholders to gain consensus on the details of project requirements. There is no one perfect method for gathering and analyzing requirements. The most appropriate method will differ from project-to-project. However, some commonly used techniques include:

• Prototyping
• Requirements Gathering Workshops
• Use Cases
• User Stories

Requirements Gathering Workshops provide an opportunity for individual perspectives to be shared, refined, and combined in a group environment to enhance and develop business requirements.

Prototyping is a technique for building a quick, rough version of a desired product or part of that product. The prototype illustrates the system capabilities to users and designers. It serves as a communication tool that enables reviewers to better understand and interact with the product.

Use Cases are narrative documents that describe the sequence of events that a user performs to complete a process. Use Cases are meant to capture the intended behavior of the system being developed, without specifying how that behavior is to be implemented.

User Stories are a simple approach to requirements gathering that shift the requirements gathering focus from formal written documentation to simple conversation. This approach enables a project to be more responsive from its inception. User stories differ from Use Cases in that User Stories are written by the customers outlining functions that the system should be able to perform and usually consist of only a few sentences of written text.

REQUIREMENTS TRACEABILITY
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 through the entire life cycle of a project. Requirements tracing captures all levels of requirements and helps ensure that the project meets 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. Some commonly identified types of requirements include:

• Functionality
• Performance
• Regulatory/Legal
• Reliability
• Supportability
• Usability

Functionality requirements identify aspects of the desired final product such as what the system should do and how the system should do it, as it relates to the user’s interaction with the system.

Performance requirements identify aspects of the desired final product such as response time for a transaction (minimum, average, maximum); throughput (e.g., transactions per second); resource utilization of memory, disk, communications, etc.

Regulatory/Legal requirements identify aspects of the desired final product such as compliance related requirements associated with conforming to CPIC, C&A, and other federal, state, and local policies.

Reliability requirements identify aspects of the desired final product such as availability – specific percentage of time available, hours of use, maintenance access, degraded mode operations etc.; accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output; maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs per function-point.

Supportability requirements identify aspects of the desired final product’s maintainability, items such as such as coding standards, naming conventions, maintenance access, etc.
Usability requirements identify aspects of the desired final product such as required training for end users to become operationally proficient in its use.

Security requirements identify aspects of the desired final product such as degree to which a system and its data are protected against internal and external threats.

A distinction also needs to be made between project requirements and product requirements.

• Project Requirements define how the work will be managed. This includes budgets, communications, resources, quality, risk, and scope. Project requirements focus on the who, when, where, and how something gets done and are generally documented within the Project Management Plan.
• Product Requirements include high-level features, functions, or capabilities that the business team has committed to delivering to a customer. Product requirements do not specify how the features or the capabilities will be designed.

Some best practices to consider when managing requirements include

• Identifying and involving stakeholders
• Applying an iterative approach to requirements management, it is an ongoing practice that should be performed over the entire project life cycle
• Verifying and validating defined requirements with stakeholders
• Documenting defined requirements

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 http://www.cdc.gov/cdcup/. Please also visit the CDC Unified Process Newsletter Archive located at http://www2.cdc.gov/cdcup/library/newsletter/ for access to many additional newsletters, articles, and management related topics and information.
CDC UNIFIED PROCESS PRESENTATIONS 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 cdcup@cdc.gov or visit http://www.cdc.gov/cdcup/ to arrange a short overview presentation for your group. CONTACT THE CDC UNIFIED PROCESS  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 atcdcup@cdc.gov or visithttp://www.cdc.gov/cdcup/		PROJECT MANAGEMENT COMMUNITY OF PRACTICE January 23, 2009 Topic: Project Metrics - Which to Whom February 06, 2009 Topic: 2009 Project Management Summit March 27, 2009 Topic: Agile Development at CDC April 24, 2009 Topic: Integrating EA into your Project May 15, 2009 Topic: The C&A Process June 19, 2009 Topic: Program Management & PMOs July 31, 2009 Topic: Risk Management August 28, 2009 Topic: Managing Teams Across Generations September 25, 2009 Topic: More on Records Management October 30, 2009 Topic: Stage Gate Reviews - EPLC Lessons December 04, 2009 Topic: Authority, Power, & Influence