sf-agent-framework

# Requirement Elicitation Task This task guides business analysts through comprehensive requirement gathering for Salesforce projects using proven elicitation techniques. ## Purpose Enable analysts to: - Gather complete, accurate requirements - Uncover hidden needs and assumptions - Document requirements clearly - Validate understanding with stakeholders - Create actionable user stories ## Elicitation Framework ### 1. Stakeholder Identification **Stakeholder Mapping** ```yaml Primary Stakeholders: - End Users: Daily system users - Process Owners: Business process authorities - Executives: Strategic decision makers - Administrators: System maintainers Secondary Stakeholders: - IT Teams: Technical support - Compliance: Regulatory requirements - Partners: External users - Customers: Indirect impact Stakeholder Analysis: - Influence: High/Medium/Low - Interest: High/Medium/Low - Availability: Schedule constraints - Communication: Preferred methods ``` ### 2. Elicitation Techniques **Interview Structure** ```yaml Opening: - Introduce purpose - Set expectations - Explain how input will be used Discovery Questions: Current State: - 'Walk me through your typical day...' - 'What systems do you use now?' - 'What works well?' - 'What frustrates you?' Pain Points: - 'What takes too long?' - 'Where do errors occur?' - 'What would you change?' - 'What blocks your productivity?' Future State: - 'In an ideal world...' - 'What would make your job easier?' - 'How should this work?' - 'What would success look like?' Probing Techniques: - 'Tell me more about...' - 'Can you give me an example?' - 'What happens when...?' - 'How often does this occur?' - 'Who else is involved?' ``` **Workshop Facilitation** ```yaml Preparation: - Define objectives - Identify participants - Prepare materials - Book resources Activities: Process Mapping: - Current state mapping - Pain point identification - Future state design Prioritization: - MoSCoW method - Dot voting - Value vs effort matrix User Journey: - Persona definition - Journey stages - Touchpoints - Emotions/pain points Documentation: - Capture on walls/boards - Photograph outputs - Assign note-taker - Summarize decisions ``` ### 3. Requirement Types **Functional Requirements** ```yaml Business Process: - 'System shall calculate commission based on...' - 'Users must be able to approve orders...' - 'Reports shall show quarterly sales by...' Data Requirements: - 'Store customer preference history' - 'Track all customer interactions' - 'Maintain audit trail for changes' User Interface: - 'Display accounts in hierarchy view' - 'Show related opportunities on account page' - 'Provide quick actions for common tasks' Integration: - 'Sync customer data with ERP' - 'Receive orders from e-commerce' - 'Send invoices to accounting' ``` **Non-Functional Requirements** ```yaml Performance: - 'Page load within 3 seconds' - 'Process 1000 orders per hour' - 'Support 500 concurrent users' Security: - 'Encrypt sensitive data' - 'Role-based access control' - 'SSO authentication required' Usability: - 'Mobile-responsive interface' - 'Accessible to screen readers' - 'Available in 3 languages' Compliance: - 'GDPR data privacy' - 'SOX audit trail' - 'HIPAA compliance' ``` ## Documentation Templates ### User Story Template ```markdown **User Story ID**: US-001 **Title**: Order Approval Workflow **Story**: As a Sales Manager I want to approve orders over $50,000 So that high-value deals have proper oversight **Acceptance Criteria**: - GIVEN an order over $50,000 is created WHEN the sales rep submits for approval THEN the sales manager receives a notification - GIVEN a manager reviews an order WHEN they approve or reject THEN the sales rep is notified of the decision - GIVEN an order is approved WHEN the approval is complete THEN the order status updates to "Approved" **Dependencies**: - Order object with approval status field - Manager hierarchy defined - Email notifications configured **Assumptions**: - Managers have mobile access - Approval needed within 24 hours - Dollar threshold is fixed **Notes**: - Consider escalation after 24 hours - May need delegation during absence ``` ### Process Documentation ```markdown ## Process: Lead Qualification ### Overview Process for qualifying marketing leads into sales opportunities ### Actors - Marketing Team: Creates leads - Sales Development Rep (SDR): Qualifies leads - Sales Rep: Owns opportunities ### Trigger New lead created with score > 70 ### Steps 1. **Lead Assignment** - System assigns to SDR based on territory - SDR receives notification - SLA: Contact within 4 hours 2. **Initial Contact** - SDR calls/emails lead - Updates lead status - Logs activity 3. **Qualification** - SDR uses BANT criteria - Completes qualification fields - Decision: Qualified/Not Qualified 4. **Conversion** (if qualified) - Convert to Contact/Account/Opportunity - Assign to Sales Rep - Transfer notes and context ### Business Rules - Leads must have email or phone - Company size must be captured - Budget range required for qualification - Industry must match target list ### Exception Paths - No response: 3 attempts then mark "Unresponsive" - Not qualified: Update reason, recycle to marketing - Duplicate found: Merge following data retention rules ``` ### Requirements Traceability Matrix ```markdown | Req ID | Description | Type | Priority | User Story | Status | | ------ | ---------------------------------- | -------------- | -------- | ---------- | --------- | | BR-001 | Calculate commission automatically | Functional | Must | US-045 | Approved | | BR-002 | Manager approval for large deals | Functional | Must | US-001 | In Review | | BR-003 | Page load under 3 seconds | Non-Functional | Should | US-078 | Approved | | BR-004 | GDPR compliance for EU customers | Compliance | Must | US-092 | Pending | ``` ## Validation Techniques ### Requirement Review Sessions ```yaml Participants: - Business stakeholders - Technical team - QA representative - Project manager Review Process: 1. Pre-read requirements 2. Walk through each requirement 3. Clarify ambiguities 4. Confirm understanding 5. Get sign-off Review Checklist: - Clear and unambiguous? - Testable? - Achievable? - Necessary? - Consistent? - Complete? ``` ### Prototype Validation ```yaml Low-Fidelity: - Wireframes - Process flows - Screen mockups High-Fidelity: - Working prototype - Sandbox demo - POC build Validation Method: - User walkthrough - Scenario testing - Feedback collection - Iteration ``` ## Analysis Techniques ### Gap Analysis ```markdown | Current State | Future State | Gap | Priority | | ------------------ | --------------------- | ---------------------- | -------- | | Manual order entry | Automated integration | Build API integration | High | | Excel reporting | Real-time dashboards | Create Analytics | Medium | | Email approvals | In-app workflow | Build approval process | High | ``` ### Impact Analysis ```yaml Change: Add approval workflow Impacts: - Order object: New status field - Page layouts: Add approval history - Permissions: Approver access - Reports: Include approval metrics - Training: New process for users - Integration: Notify ERP of status ``` ## Success Criteria ✅ All stakeholders identified and engaged ✅ Requirements documented clearly ✅ Acceptance criteria defined ✅ Priorities agreed ✅ Dependencies identified ✅ Assumptions documented ✅ Sign-off obtained ✅ Traceability established