6.2 Requirements Classification: Business, Stakeholder, Functional & Non-Functional

6.2 Requirements Classification: Business, Stakeholder, Functional & Non-Functional

Quick Answer: The BABOK taxonomy classifies requirements into five categories: (1) Business Requirements (high-level enterprise goals and strategic outcomes), (2) Stakeholder Requirements (needs and workflows of specific user groups or personas), (3) Solution Functional Requirements (explicit system behaviors, automation rules, and calculations), (4) Solution Non-Functional Requirements (system quality attributes like performance, security, and scalability), and (5) Transition Requirements (temporary capabilities like data migration and user training required to go live).

When eliciting and documenting requirements for Salesforce initiatives, business analysts frequently receive a jumble of strategic aspirations, individual employee complaints, technical design preferences, and compliance mandates. To bring order to this complexity, professional analysts rely on the requirements taxonomy established by the Business Analysis Body of Knowledge (BABOK® Guide). Mastering this taxonomy is vital not only for passing the Salesforce Certified Business Analyst exam, but also for ensuring that technical architects build systems that fulfill strategic executive promises while maintaining enterprise security and performance standards.

---

The Five-Tier Requirements Taxonomy Applied to Salesforce

                                 ┌─────────────────────────┐
                                 │  Business Requirements  │  <-- Strategic Goals & ROI Targets
                                 └────────────┬────────────┘
                                              │
                                 ┌────────────▼────────────┐
                                 │ Stakeholder Requirements│  <-- Persona Needs & Department Workflows
                                 └────────────┬────────────┘
                                              │
                        ┌─────────────────────┴─────────────────────┐
                        │                                           │
           ┌────────────▼────────────┐                 ┌────────────▼────────────┐
           │  Solution Functional    │                 │ Solution Non-Functional │
           │      Requirements       │                 │   Requirements (NFRs)   │
           └─────────────────────────┘                 └─────────────────────────┘
             (System Behaviors, Flows,                   (Performance, Security,
               Validations & Logic)                       Scalability & Limits)
                        │                                           │
                        └─────────────────────┬─────────────────────┘
                                              │
                                 ┌────────────▼────────────┐
                                 │ Transition Requirements │  <-- Data Migration, Cutover & Training
                                 └─────────────────────────┘

1. Business Requirements

Business Requirements represent high-level statements of the goals, objectives, and outcomes of the enterprise. They describe why an initiative has been funded and what quantifiable business value leadership expects to realize.

• Primary Focus: Strategic business impact, financial return, market expansion, operational efficiency, or risk mitigation.
• Scope: Technology-agnostic. A business requirement remains identical whether the organization chooses Salesforce, Microsoft Dynamics, or manual whiteboards.
• Key Characteristic: Must be measurable and time-bound, frequently linked directly to executive OKRs or corporate KPIs.
• Salesforce Examples:
  • "Reduce average customer onboarding cycle time from 14 business days to under 48 hours across global commercial accounts by Q4."
  • "Increase field sales representative quote turnaround capacity by 35% without increasing back-office deal desk headcount."
  • "Decrease tier-1 customer support operational expenditure by $1.2M annually through customer self-service deflections."

2. Stakeholder Requirements

Stakeholder Requirements (often called user requirements) bridge the gap between high-level business goals and technical system features. They articulate the specific needs, daily challenges, and operational desires of distinct personas, user groups, or functional departments.

• Primary Focus: What a particular user group needs to accomplish their work effectively.
• Scope: Departmental or role-specific. They describe interactions between users and their business environment.
• Salesforce Examples:
  • "The Billing and Finance team requires automated generation and delivery of branded PDF invoices immediately upon contract execution."
  • "Inside Sales Managers require real-time visibility into rep pipeline stage progression and discount overrides exceeding 15%."
  • "Field Service Engineers require offline mobile access to customer asset service histories and warranty entitlement statuses while on customer premises."

3. Solution Requirements: Functional Requirements

Solution Requirements describe the specific capabilities and characteristics of the system being developed to satisfy the business and stakeholder requirements. They are subdivided into Functional and Non-Functional requirements.

Functional Requirements define the explicit behaviors, operations, calculations, and data transformations that the Salesforce platform must execute. They describe what the system will do in response to specific triggers, inputs, or user actions.

• Salesforce Declarative & Programmatic Constructs:
  • Automation Logic: Record-Triggered Flows, Scheduled Flows, Subflows, and Apex Invocable Methods.
  • Data Validation: Validation Rules enforcing field formats, cross-object validation, and required fields based on lifecycle stage.
  • User Interface: Dynamic Forms, Lightning Record Pages, Component Visibility Filters, and Screen Flow wizards.
  • Approval Routing: Multi-step Approval Processes with dynamic approver assignment based on deal size.
• Salesforce Examples:
  • "When an Opportunity stage is set to 'Closed Won', the system must automatically create an active Contract record, populate the start date with the Opportunity Close Date, and copy all Opportunity Line Items as Contract Assets."
  • "The system must prevent a user from changing a Case status to 'Closed' if the 'Root Cause Resolution' field is blank, displaying an on-screen validation error message."
  • "A guided Screen Flow must lead the customer service representative through a 4-step warranty validation checklist before allowing an RMA (Return Merchandise Authorization) record to be saved."

4. Solution Requirements: Non-Functional Requirements (NFRs)

Non-Functional Requirements (NFRs) define the environmental conditions, quality attributes, performance constraints, and governance standards under which the functional requirements must operate. While functional requirements define what the system does, NFRs define how well the system performs.

In enterprise Salesforce environments, NFRs are critical because Salesforce operates in a multi-tenant cloud architecture governed by strict execution limits. NFRs are commonly organized under the URACCS framework (Usability, Reliability, Availability, Capacity, Compliance, and Security):

5. Transition Requirements

Transition Requirements represent temporary capabilities, processes, and tools required to move an organization from its current operational state to the desired future state. Once the new system is live and stable, transition requirements become obsolete.

• Primary Focus: Go-live readiness, legacy cutover, data hygiene, and organizational enablement.
• Salesforce Examples:
  • "Data Migration: Extract, transform, and load (ETL) 1.2 million legacy Account and Contact records, scrubbing duplicate email addresses and remapping historical custom field values into standard Salesforce fields prior to final cutover."
  • "Cutover Strategy: Establish a 48-hour parallel running window during the Labor Day weekend where transactions are logged in both the legacy ERP and Salesforce to verify financial reconciliation before legacy decommissioning."
  • "User Enablement: Conduct mandatory role-based Lightning Experience training for 300 inside sales reps, requiring an 85% passing score on the interactive sandbox simulation prior to receiving production login credentials."

---

Requirements Taxonomy Comparison Matrix

---

Realistic Scenario: Deconstructing a Complex Business Initiative

To see how the five requirements categories interact in practice, analyze this realistic enterprise scenario:

The Initiative: MedTech Global Field Service Modernization

MedTech Global manufactures medical diagnostic equipment installed in hospitals. Service dispatching is currently managed via spreadsheets and phone calls, resulting in slow equipment repairs and hospital complaints.

1. Business Requirement: "Improve medical equipment uptime across hospital partner networks from 92% to 98.5% within 12 months, reducing SLA penalty payouts by $2.4M annually."
2. Stakeholder Requirement (Hospital Dispatcher): "Hospital biomedical engineering leads require a self-service portal to submit emergency repair requests and view real-time GPS arrival estimates for dispatched technicians."
3. Solution Functional Requirement: "When an emergency work order is submitted via Experience Cloud, Salesforce Field Service must automatically evaluate technician skill sets, geographic location, and current van inventory to assign the service appointment to the optimal available engineer within 30 seconds."
4. Solution Non-Functional Requirement: "All patient health information (PHI) and hospital identifier codes stored within the Work Order and Service Appointment records must be encrypted at rest using Salesforce Shield 256-bit AES encryption, complying with HIPAA Title II security rules."
5. Transition Requirement: "Extract 85,000 active hospital machine serial numbers, warranty contracts, and service histories from the legacy SQL database, cleanse orphaned equipment records, and load them into Salesforce Asset records 72 hours before production cutover."

---

Common Exam Traps & Pitfalls

• Trap 1: Classifying Security and Performance as Functional Requirements: A question may describe data encryption, page load times, or governor limit handling. Candidates often classify these as functional requirements because "they require configuration in Setup." Remember: What the system does is functional; how well, securely, or quickly it performs is non-functional.
• Trap 2: Confusing Stakeholder Requirements with Business Requirements: If a requirement describes the specific operational desire of a department (e.g., "The Marketing team needs automated lead scoring"), it is a stakeholder requirement. If it describes high-level financial or enterprise metrics (e.g., "Increase qualified inbound pipeline revenue by 20%"), it is a business requirement.
• Trap 3: Overlooking Transition Requirements in Project Planning: Exam scenarios often depict projects that were delivered on time technically but suffered disastrous user adoption or data corruption at go-live. The root cause is almost always the omission of transition requirements (such as data cleansing or cutover dry runs).