Skip to content
CAPM

Functional Requirements

Functional requirements describe the specific behaviors, features, and capabilities a solution must provide, defining what the system should do in response to inputs or conditions.

Share:

Explanation

Functional requirements specify the actions, processing, and outputs a solution must deliver. They describe the "what" of the solution in concrete, observable terms. Examples include user authentication workflows, calculation rules, data entry validations, report generation capabilities, and notification triggers.

Functional requirements are typically documented using techniques such as use cases, user stories, process flows, and requirements specification documents. Each functional requirement should be written so that it can be independently verified through testing. A well-written functional requirement follows a structured format, such as "The system shall [perform action] when [condition] so that [benefit]."

On the CAPM exam, you need to distinguish functional requirements from non-functional requirements clearly. Functional requirements describe observable behavior and features. If a requirement describes what the system does in response to an action, it is functional. If it describes how well the system performs or a quality constraint, it is non-functional.

Key Points

  • Describe what the solution must do in terms of features, behaviors, and processing
  • Documented through use cases, user stories, and requirements specifications
  • Must be independently testable with clear acceptance criteria
  • A subcategory of solution requirements along with non-functional requirements

Exam Tip

If the requirement describes an action the system performs (e.g., "calculate," "generate," "send"), it is functional. If it describes a quality attribute (e.g., "within 2 seconds," "99.9% uptime"), it is non-functional.

Frequently Asked Questions

Related Topics

High-yield topics our learners drill most before exam day.

Burndown Chart

A Burndown Chart is a graphical representation of work remaining versus time in a Sprint or release, showing whether the team is on track to complete the planned work.

Resource Leveling

Resource leveling is a resource optimization technique in which adjustments are made to the project schedule to keep resource usage at or below a defined limit, often resulting in a longer project duration.

Risk Register

The risk register is a project document that records the details of individual project risks, including their identification, analysis results, response plans, and current status.

Stakeholder Mapping

Stakeholder mapping is the visual representation of stakeholder relationships, influence, interest, or other attributes using grids, matrices, or diagrams to support analysis and engagement planning.

Relative Estimation

Relative Estimation is an agile technique where work items are sized in comparison to each other rather than in absolute units like hours or days, providing faster and more accurate estimates.

Cost Performance Index (CPI)

Cost Performance Index (CPI) is an EVM efficiency metric that measures cost performance as the ratio of earned value to actual cost: CPI = EV / AC.

Schedule Performance Index (SPI)

Schedule Performance Index (SPI) is an EVM efficiency metric that measures schedule performance as the ratio of earned value to planned value: SPI = EV / PV.

Earned Value Management (EVM)

Earned Value Management (EVM) is a methodology that integrates scope, schedule, and cost data to assess project performance and progress objectively.

Power/Influence Grid

The power/influence grid is a stakeholder classification model that groups stakeholders based on their level of authority (power) and their active involvement or ability to affect the project (influence).

Part of

CAPM-Specific Concepts

Study full domain →

Test your knowledge

Practice scenario-based questions on this topic with detailed explanations.