1.1: SYS.1 Requirements Elicitation

What You'll Learn

Here's what you'll take away from this section:

• Describe the purpose and outcomes of SYS.1
• Apply base practices for requirements elicitation
• Integrate AI assistance appropriately (L0-L1)
• Produce compliant stakeholder requirements documentation

Process Definition

Purpose

SYS.1 Purpose: To gather, process, and track stakeholder requirements.

Outcomes

Base Practices with AI Integration

BP Detail

BP1: Identify Stakeholders

Activities:

• Map all parties with interest in the system
• Document stakeholder roles and responsibilities
• Identify stakeholder representatives

Stakeholder Categories:

AI Assistance: None (L0) - Human interpersonal judgment required

BP2: Obtain Stakeholder Requirements

Activities:

• Conduct interviews, workshops, surveys
• Review existing documentation
• Analyze similar systems
• Capture expectations and constraints

Techniques:

AI Assistance (L1):

• Pre-interview analysis of existing documents
• Summarization of previous meeting notes
• Draft question generation

HITL Pattern: Collaborator - AI helps prepare, human conducts

BP3: Document Stakeholder Requirements

Activities:

• Write clear, unambiguous requirements
• Use consistent format and terminology
• Capture rationale and constraints
• Include acceptance criteria

Requirement Attributes:

AI Assistance (L1):

• Draft requirement text from notes
• Suggest consistent terminology
• Identify ambiguous language

HITL Pattern: Reviewer - AI drafts, human reviews/approves

BP4: Analyze Requirements for Completeness

Activities:

• Check for missing areas
• Identify conflicts and overlaps
• Verify clarity and testability
• Assess feasibility

Completeness Checklist:

AI Assistance (L1):

• Automated completeness checking
• Conflict detection
• Ambiguity flagging

HITL Pattern: Reviewer - AI flags issues, human resolves

BP5: Agree on Requirements with Stakeholders

Activities:

• Present requirements for review
• Resolve conflicts and ambiguities
• Obtain formal acceptance
• Document agreements

AI Assistance: None (L0) - Human interpersonal judgment required

BP6: Establish Traceability

Activities:

• Link requirements to sources
• Prepare for downstream tracing
• Enable impact analysis

Traceability Links:

The diagram below illustrates how elicited stakeholder requirements link to their sources and downstream system requirements, enabling end-to-end traceability.

AI Assistance (L1-L2):

• Suggest trace links
• Validate trace completeness
• Identify orphan requirements

HITL Pattern: Monitor - AI maintains, human verifies

Work Products

Input Work Products

Output Work Products

Example: Automotive ECU Stakeholder Requirement

---
ID: STK-BCM-001
Title: Door Lock Response Time
Source: Vehicle Manufacturer (OEM)
Priority: High
---

## Description

The body control module shall lock all vehicle doors within 200ms
of receiving a lock command from the central locking button.

## Rationale

Driver expects immediate response to locking action for
security confidence and feedback.

## Constraints

- Response time measured from button electrical signal
- All doors include front left, front right, rear left, rear right
- Trunk lock is handled separately

## Acceptance Criteria

1. Lock command to door actuator signal: < 150ms
2. Door actuator to locked state: < 50ms
3. Verified under temperature range -40°C to +85°C

## Trace

- Source: OEM Requirements Spec v2.1, Section 4.3.1
- Derives: SYS-BCM-010 (system requirement)

AI Integration Examples

L0 Activities (No AI)

• Stakeholder identification
• Interview conduct
• Requirement agreement
• Conflict resolution

L1 Activities (AI Assists)

Example: Pre-Interview Document Analysis

Input: Previous meeting notes, customer specifications

AI Action: "I've analyzed the customer specification and identified
           these potential requirement areas that weren't discussed
           in previous meetings:
           1. Cybersecurity requirements (Section 7)
           2. OTA update support (mentioned briefly in Section 12)
           3. Power consumption limits (Table 4-3)"

Human Action: Add these topics to interview agenda

L2 Activities (AI Generates)

Example: Traceability Suggestion

AI Action: "Based on requirement text analysis, I suggest these
           trace links:
           STK-BCM-001 ──► SYS-BCM-010 (99% confidence)
           STK-BCM-001 ──► SYS-BCM-011 (87% confidence)
           STK-BCM-002 ──► [No match found]"

Human Action: Confirm 99% link, evaluate 87%, investigate orphan

Common Challenges

Requirements Elicitation Techniques

Overview of Elicitation Methods

Effective requirements gathering requires multiple complementary techniques:

Elicitation Technique Details

1. Interviews

Preparation:

• Create interview guide (not a script - allow flexibility)
• Identify 5-10 key stakeholders per category
• Schedule 1 hour per interview
• Prepare opening, probing, and closing questions

Interview Structure:

Opening (5 min):
├─ Introduce purpose of interview
├─ Explain confidentiality/use of information
└─ Ask permission to record/take notes

Main Questions (40 min):
├─ Open-ended: "What are the main challenges you face?"
├─ Probing: "Can you give me an example?"
├─ Validating: "So you mean... is that correct?"
└─ Non-leading: Avoid "Don't you think...?" style questions

Closing (10 min):
├─ Summarize key points captured
├─ Ask "Did we miss anything important?"
└─ Thank and confirm next steps

Example Questions (Automotive Infotainment System):

• "What are the top 3 pain points with current infotainment?"
• "How often do you use voice commands versus touchscreen?"
• "What would make the system more intuitive?"
• "Are there safety concerns with any features?"

Documentation:

• Audio recording (with permission) + summary notes
• Direct quotes for key requirements
• Action items and follow-up questions

AI Assistance:

• L1: Auto-transcription of interviews (whisper, Azure Speech)
• L1: Draft requirement extraction from transcripts
• HITL: Human validates extracted requirements against intent

2. Workshops (Requirements Workshops)

Preparation:

• 6-12 participants (representatives from all stakeholder groups)
• Half-day session (4 hours optimal)
• Facilitator + scribe + SME
• Prepare agenda, materials, room setup

Workshop Agenda:

Opening (15 min):
├─ Overview of project
├─ Goals for workshop
└─ Ground rules (respect, listen, build on ideas)

Part 1: Individual Brainstorming (30 min):
├─ Silent generation: Each person writes requirements
└─ No criticism, no evaluation

Part 2: Consolidation (60 min):
├─ Group discussion of ideas
├─ Identify common themes
├─ Resolve conflicts (voting, structured discussion)

Part 3: Validation (45 min):
├─ Review consolidated requirements
├─ Assign priorities (MoSCoW)
└─ Identify gaps

Closing (30 min):
├─ Summarize outcomes
├─ Confirm next steps
└─ Thank participants

Conflict Resolution in Workshops:

The following diagram depicts a prototype AV system status display, used during stakeholder workshops to elicit concrete feedback on information layout and priority.

Feedback from Users:

• "I want a confidence indicator (% chance of failure)"
• "Show battery/range like my phone"
• "Emergency stop button must be red and thumb-accessible"

Requirements Extracted:

• [SYS-HMI-001] Display confidence level (% not needed, use bar)
• [SYS-HMI-002] Show battery level graphically
• [SYS-HMI-003] Emergency stop is red, 3cm diameter, thumb-accessible

4. Observation (Ethnographic Study)

Method: Follow users in their actual work environment

Example: Hospital infusion pump usage

• Observe nurses preparing and administering infusions
• Identify pain points (alarms not heard, data entry tedious)
• Document workarounds (tape over alarms, printed labels)

Requirements Extracted:

• [SYS-ALARM-001] Alarms must be audible in noisy ICU environment (≥85 dB)
• [SYS-UI-001] Allow pre-programmed drug library (reduce manual entry)
• [SYS-LABEL-001] Support barcode scanning for patient/drug verification

Requirements Writing Standards (ISO/IEC 29148)

Good Requirement Characteristics (ISO/IEC 29148:2018):

Requirement Template (ISO/IEC 29148):

[REQ-XXX-NNN] Requirement Title

Description:
  The system/component/interface shall [action]
  [under conditions] to [achieve purpose].

Rationale:
  Why this requirement exists (regulatory, user need, safety)

Verification Method:
  Test / Analysis / Inspection / Demonstration

Derived From:
  Source stakeholder, regulation, or parent requirement

Traceability:
  Forward link: Design elements implementing this
  Backward link: Stakeholder need this addresses

Example Requirement:

[SYS-SAFE-001] Air-in-Line Detection

Description:
  The system shall detect air bubbles ≥50 microliters in the IV tubing
  and halt infusion within 2 seconds of detection.

Rationale:
  Large air embolism (>5 mL) is potentially fatal (FDA guidance).
  50 µL target provides early warning margin.

Verification Method:
  Test: Introduce calibrated air bubbles (20, 50, 100 µL)
  Verify: Detection within 2 seconds in 19/20 trials (95%)

Derived From:
  Stakeholder: ICU nurses
  Regulation: FDA Infusion Pump Guidance
  Risk: [RISK-004] Air embolism hazard

Traceability:
  Forward: [DESIGN-AIR-001] Air detection architecture
  Backward: [RISK-004] Air embolism mitigation

Traceability Baseline

Requirements Traceability Matrix (RTM) Setup:

Stakeholder Requirement → System Requirement → Design Element → Test Case

Example Path:
[STK-REQ-001] "Nurses need to trust infusion"
           ↓
[SYS-REQ-001] "System shall verify drug correctness via barcode"
           ↓
[DESIGN-BarCode] Barcode scanner module
           ↓
[TEST-001] "Verify barcode reading accuracy (99.9%)"

RTM Tool Setup (Jama, DOORS, SpiraTest):

• Import all stakeholder requirements
• Create system requirement child-requirements
• Link to design elements (traceability forward)
• Link to test cases (verification)
• Track coverage (% of stakeholder → verified)

AI Assistance:

• L1: Suggest RTM links based on keyword matching
• L1: Auto-generate requirement IDs (REQ-001, REQ-002)
• HITL: Human reviews and validates links

Requirements Prioritization

When conflicting requirements arise, use structured prioritization:

AI Assistance: AI can suggest initial prioritization based on:

• Regulatory keywords (shall, must, required)
• Safety-related terminology
• Historical priority patterns from similar projects

Regulatory Requirements Handling

Requirements from regulations require special attention:

Summary

SYS.1 Requirements Elicitation:

• Primary mode: Human-driven (L0-L1)
• AI value: Document analysis, draft generation, consistency checking
• Human essential: Stakeholder interaction, judgment, agreement
• Key outputs: Stakeholder requirements specification
• Traceability: To sources and forward to system requirements