Purpose:

Provides the basis for defining and managing the project scope including product scope.

Objective:

Determine, document, and manage stakeholder needs and requirements to meet project objectives.

Description:

The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project. Requirements include conditions or capabilities that are to be met by the project or present in the product, service, or result to satisfy an agreement or other formally imposed specification. Requirements include the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders. These requirements need to be elicited, analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins. Requirements become the foundation of the work breakdown structure. Cost, schedule, quality planning, and sometimes procurement are all based upon these requirements. The development of requirements begins with an analysis of the information contained in the project charter, the stakeholder register, and the stakeholder management plan.

Many organizations categorize requirements into different types, such as business and technical solutions, the former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:

• • Business requirements, which describe the higher-level needs of the organization as a whole, such as business issues or opportunities, and reasons why a project has been undertaken.
  • Stakeholder requirements, which describe the needs of a stakeholder or stakeholder group.
  • Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:
    • Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.
    • Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
  • Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.
  • Project requirements, which describe the actions, processes, or other conditions the project needs to meet.
  • Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.

RASIC:

Entrance Criteria:

• Scope Management Plan
• Requirements Management Plan
• Stakeholder Management Pan
• Project Charter
• Stakeholder Register

Exit Criteria:

• Requirements Documentation
• Requirements Traceability Matrix

Process and Procedures:

• Develop Customer Requirements
• Develop Product Requirements

Tailoring Guidelines:

• None

Process Verification Record(s):

• Correspondence over e-mail clarifying Requirements
  • Stored By: Business Analyst
• Minutes of Meeting – Customer Requirements Review
  • Business Analyst
• Records Containing review feedback on the Customer Requirements Document
  • Business Analyst
• Completed Customer Requirements Checklist
  • Business Analyst
• Completed Peer Review Summary Report
  • Business Analyst
• Records containing review feedback on Customer Requirements Document
  • Business Analyst
• Approval Records from Business Process Owner, Business Project Champion and lead Architect approving Customer Requirements Document.
  • Business Analyst

Measure(s):

• Defect Density – Process Design Summary, total number of defects identified during customer requirements gathering and impact to process design summary
  • Maintained by: Business Analyst
  • Submitted by: Business Analyst
• Bug Density – Customer Requirements, number of defects identified in Customer Requirements Document divided by total number of Customer Requirements. <?>

• • Maintained by: Business Analyst
  • Submitted by: Business Analyst
  • mission: <?>

References:

• • <?>