Functional Requirements

Definition and Scope

Concept

Functional requirements: describe specific behaviors, functions, and processes of a system. Define interactions between system and users or other systems. Focus: "What the system does," not "how."

Scope Boundaries

Include: business rules, data manipulation, user commands, system responses. Exclude: performance metrics, security constraints (covered by non-functional requirements).

Importance

Foundation for design, implementation, testing. Incomplete or incorrect functional requirements lead to system failures or rework.

Types of Functional Requirements

Business Requirements

High-level goals or policies driving system behavior. Example: "System shall support online order processing."

User Requirements

Statements reflecting user needs and interactions. Example: "User shall be able to reset password."

System Requirements

Detailed functions and system responses. Example: "System shall send confirmation email upon order placement."

Interface Requirements

Requirements specifying system interactions with external systems or components. Example: "System shall interface with payment gateway API."

Elicitation Techniques

Interviews

Direct discussions with stakeholders to capture explicit and implicit needs.

Workshops

Group sessions encouraging collaboration and consensus on requirements.

Observation

Studying user environment and workflows to identify functional needs.

Document Analysis

Reviewing existing system documentation, manuals, and policies.

Prototyping

Creating preliminary models to clarify and refine requirements.

Specification Methods

Natural Language

Descriptive text using structured templates or controlled vocabulary. Advantage: accessible. Risk: ambiguity.

Use Cases

Structured scenarios describing actor-system interactions. Components: actors, preconditions, flow of events, postconditions.

User Stories

Brief, informal descriptions of functionality from user perspective. Format: "As a [user], I want [function] so that [benefit]."

Formal Specification

Mathematical or logical descriptions ensuring precision and verifiability.

Requirement Templates

Standardized forms capturing unique ID, description, rationale, dependencies, and acceptance criteria.

Modeling Functional Requirements

Use Case Diagrams

Visualize actors and their interactions with system use cases. Clarify functionality boundaries.

Activity Diagrams

Depict workflows and process sequences relevant to functions.

State Machines

Model system states and transitions triggered by events or actions.

Data Flow Diagrams (DFD)

Represent data movement and processing steps within system functions.

Sequence Diagrams

Detail object interactions over time to fulfill functions.

Validation and Verification

Requirement Reviews

Peer evaluations to detect inconsistencies, ambiguities, and omissions.

Prototyping

Early models tested with stakeholders to confirm requirements accuracy.

Test Case Derivation

Creating test scenarios from requirements for validation coverage.

Traceability Analysis

Ensuring each requirement maps to design, implementation, and tests.

Formal Verification

Applying mathematical proofs or model checking to validate critical functions.

Traceability and Management

Traceability Matrix

Mapping requirements to design elements, code modules, and tests. Supports impact analysis.

Change Management

Processes to handle requirement modifications, version control, and stakeholder approvals.

Requirement Attributes

Metadata including priority, status, source, owner, and rationale for tracking.

Tool Support

Requirements management software provides traceability, collaboration, and reporting.

Configuration Management

Ensures consistent requirement sets across project lifecycle.

Prioritization Strategies

Moscow Method

Classify requirements as Must have, Should have, Could have, Won't have.

Weighted Scoring

Assign scores based on factors like value, risk, cost, and effort.

Cost-Benefit Analysis

Evaluate expected benefits against implementation costs to rank requirements.

Risk-Based Prioritization

Focus on high-risk or high-impact requirements first.

Stakeholder Consensus

Use negotiation and voting to align priorities among stakeholders.

Common Challenges

Ambiguity

Unclear wording leads to multiple interpretations.

Incomplete Requirements

Missing functions or scenarios cause gaps in system behavior.

Changing Requirements

Dynamic business environments cause frequent updates.

Conflicting Requirements

Incompatible stakeholder needs require resolution.

Over-Specification

Too detailed requirements limit design flexibility.

Supporting Tools

Requirements Management Systems

Examples: IBM DOORS, Jama Connect. Features: traceability, versioning, collaboration.

Modeling Tools

Examples: Enterprise Architect, Visual Paradigm. Support UML diagrams and formal models.

Prototyping Tools

Examples: Axure, Balsamiq. Facilitate early feedback and validation.

Collaboration Platforms

Examples: Jira, Confluence. Integrate requirements with project management.

Automated Testing Tools

Link test cases to requirements for validation coverage.

Best Practices

Clarity and Precision

Use unambiguous language, define terms, avoid jargon.

Stakeholder Involvement

Engage users, customers, developers continuously.

Incremental Elaboration

Refine requirements iteratively with feedback loops.

Validation Early and Often

Frequent reviews and prototyping reduce errors.

Maintain Traceability

Track requirement lifecycle from origin to implementation.

Case Study

Context

Development of a hospital patient management system with complex workflows and multiple user roles.

Approach

Used interviews, workshops, and document analysis to elicit requirements. Applied use case modeling for clarity.

Challenges

Conflicting priorities between clinical staff and administration. Frequent regulatory changes.

Solution

Implemented traceability matrix and held regular validation sessions. Prioritized requirements using MoSCoW technique.

Outcome

Delivered system meeting functional expectations with minimal rework. Improved stakeholder satisfaction and adoption.

References

• Wiegers, K., & Beatty, J. "Software Requirements," 3rd Ed., Microsoft Press, 2013, pp. 45-78.
• Sommerville, I. "Software Engineering," 10th Ed., Pearson, 2015, pp. 120-148.
• Hull, E., Jackson, K., & Dick, J. "Requirements Engineering," 3rd Ed., Springer, 2011, pp. 55-90.
• Pohl, K. "Requirements Engineering: Fundamentals, Principles, and Techniques," Springer, 2010, pp. 102-135.
• Firesmith, D. "Specifying Requirements with Use Cases," Addison-Wesley, 2004, pp. 23-49.

Structured Information: Use Case Template

ID: UC-001Title: User LoginPrimary Actor: Registered UserGoal: Access system features after authenticationPreconditions: User has valid credentialsMain Success Scenario: 1. User enters username and password 2. System validates credentials 3. System grants access and displays dashboardExtensions: 2a. Invalid credentials 1. System displays error message 2. User retries loginPostconditions: User session initiated

Algorithm: Requirement Prioritization (MoSCoW)

Input: List of requirements ROutput: Prioritized requirements categorized as Must, Should, Could, Won'tFor each requirement r in R: Evaluate business value (BV) Assess implementation cost (IC) Determine risk (R) If BV is critical and IC acceptable: Assign r to Must have Else if BV high but IC higher: Assign r to Should have Else if BV moderate and IC low: Assign r to Could have Else: Assign r to Won't haveReturn categorized sets