Skill Hub — Business Analysis

Requirements Elicitation Working Skill

Turn vague stakeholder complaints into requirements, assumptions, risks, and acceptance criteria that a developer, tester, or AI agent can act on.

What this skill is for

Stakeholders rarely state requirements. They state complaints, solutions, wishes, and constraints. This skill separates the signal from the noise and produces a Requirements Brief that contains: the underlying need, testable requirement statements, explicit assumptions, business rules, constraints, risks, and acceptance criteria. The output is usable by developers, testers, project managers, and AI agents without further translation.

When to use this skill

A new project or phase starts and the scope is described in a single sentence.
Scope creep is detected: new requests appear that do not map to any documented requirement.
A change request arrives with a solution but no description of the problem it solves.
An incident recurs and the post-mortem concludes that "the system should have caught this."
An integration failure requires a new validation rule, but no one has defined what valid means.
A data migration is planned and the business says "just move everything" without field-level clarity.

Real work situations

SAP rollout: "The system is too slow"

A warehouse manager says the system is too slow during goods receipt posting. The real need is not "faster system" — it is "post 500 line items within 30 minutes during peak shift." The requirement must specify throughput, concurrency, and peak time windows. Without this, infrastructure teams guess at hardware instead of measuring actual load.

Data migration: "Just move everything"

A finance director asks to migrate all customer master data to the new SAP S/4 system. Elicitation reveals that "everything" includes inactive customers, duplicate account groups, and unvalidated tax numbers. The requirement must specify: active-only, deduplication rules, tax validation, and cut-off date. Without this, the migration loads garbage that blocks invoicing.

Post-incident: "This should never happen again"

After a sales order bypassed credit check due to a missing credit segment, the sales manager says this should never happen again. The requirement is not "fix credit check" — it is "block order creation when credit segment is missing, route to credit team, and alert within 15 minutes." Without this, developers patch the symptom and leave the monitoring gap.

Integration failure: "The API should handle it"

An e-commerce integration drops orders when the customer record has an unsupported country code. The requirement is not "handle it" — it is "reject unsupported country codes at the API boundary with error code 422, log to monitoring, and queue for manual review." Without this, the integration silently drops orders or creates invalid data.

Inputs required

Stakeholder Interview Briefs from relevant business and technical owners.
Existing system documentation, configuration guides, or transaction codes involved.
Incident tickets or error logs that triggered the need.
Process maps or Process Analysis Notes for the affected workflow.
Regulatory documents or compliance constraints (if applicable).
Current-state data samples showing the problem (if data-related).
List of known constraints: budget, timeline, system versions, integration contracts.

Questions to ask

What business process stops or slows down if this requirement is not met?
Which fields, tables, or transactions must be present for this rule to execute correctly?
Who loses time, money, or compliance standing when this fails?
What is the minimum acceptable outcome, not the ideal outcome?
What are you assuming to be true about the current data, configuration, or user behavior?
Has this worked differently in the past? When did it change and why?
Who can confirm that this requirement is correct and complete?
What would prove that this requirement is met? What would prove it is not met?

Working method

Collect raw statements. Gather everything stakeholders have said: emails, meeting notes, tickets, complaints, proposals. Do not filter yet.
Classify each statement. Label each item as: need, solution idea, assumption, constraint, risk, or complaint. Use a table or color code.
Separate solution from requirement. For every solution idea, ask: "What problem does this solve?" Write the problem as the need. Discard the solution unless it is a constraint.
Write testable requirement statements. Format: "The system/process must [action] so that [outcome]." Each statement must be verifiable.
Identify missing context. For each requirement, list what you do not know: field names, transaction codes, volume estimates, owner names. Flag these as open questions.
Map to business rules. Identify rules that constrain the requirement. Document them separately so they can be validated.
Validate with the requirement owner. Walk through each requirement, assumption, and acceptance criterion with the named business owner. Revise based on feedback.
Package into Requirements Briefs. One brief per distinct business need. Link related briefs. Include traceability to source statements.

Decision rules

If a stakeholder describes a solution, ask what problem it solves before writing a requirement.
If a requirement has no acceptance criterion, it is not a requirement yet — it is a need statement.
If two stakeholders give conflicting requirements, document both, flag the conflict, and ask who has decision authority.
If a requirement references a system field, table, or transaction, verify that it exists and behaves as assumed before finalizing.
If no owner can confirm a requirement, mark it as an assumption and add a risk that the requirement may be wrong.
If a requirement came from an incident ticket, verify that the ticket root cause is addressed, not just the symptom.
If a requirement is stated as "must be fast," "must be secure," or "must be user-friendly," rewrite it with a measurable threshold.

Deliverables

Requirements Brief — One per distinct business need. Contains need, requirement statement, assumptions, rules, constraints, risks, acceptance criteria, priority, owner, dependencies. See template below.
Stakeholder Interview Brief — Record of what each stakeholder said, classified. Reference Artifact Templates for the full format.
Assumptions Log — List of all assumptions with validation status and risk if false.
Requirements Traceability Matrix — Maps each requirement to source statement, stakeholder, business rule, and acceptance criterion.

Templates

Requirements Brief (compact)

---
artifact: Requirements Brief
id: REQ-001
source: Stakeholder interview | Ticket | Audit | Regulation
status: draft | reviewed | approved
---

## Business need


## Requirement statement


## Assumptions


## Business rules


## Constraints


## Acceptance criteria


## Priority


## Owner


## Dependencies


## Risks


## Related requirements

Quality checklist

Every requirement has at least one acceptance criterion.
Every requirement has a named business owner who can confirm it.
No requirement contains a solution disguised as a need.
Assumptions are separated from facts and have a validation plan.
Conflicts between stakeholders are flagged, not hidden.
Each requirement traces back to a source statement or ticket.
All vague qualifiers (fast, secure, user-friendly) have measurable thresholds.

Common mistakes

Recording solutions as requirements. Consequence: the team builds what was asked, not what was needed. The real problem recurs in a different form.
Skipping acceptance criteria. Consequence: no way to verify delivery. Disputes about whether the requirement is met continue indefinitely.
Failing to document assumptions. Consequence: requirements break when assumptions turn out to be false. Rework is required late in the project.
Hiding conflicts between stakeholders. Consequence: late-stage scope disputes, change requests, and project delays when the conflict surfaces during testing.
Writing requirements without system verification. Consequence: requirements reference non-existent fields or transactions, making them impossible to implement.

Agent instructions

When using this skill, an AI agent must:

Gather all raw stakeholder statements first. Do not summarize or filter before classification. Ask: what is the complaint, what is the proposed solution, what is the constraint, what is the risk?
Classify each statement as need, solution, assumption, constraint, risk, or complaint before writing any requirement.
Never write a requirement without an acceptance criterion. If the criterion is missing, flag the item as an unclassified need.
Separate facts from assumptions explicitly. Label assumptions and state the risk if each assumption is false.
If a field, table, transaction, or system is referenced, verify it exists in the current landscape before including it in a requirement.
Produce one Requirements Brief per distinct business need. Link related briefs. Do not bundle unrelated needs into a single brief.
Flag conflicts instead of resolving them silently. Document both conflicting requirements and ask who has decision authority.
Avoid generic framework language. Do not write "the system shall be user-friendly." Write specific, testable statements.
Link to Atlas diagnostics when requirements relate to SAP processes. For example, credit management requirements should reference SAP Credit Management Diagnostics.

Related skills

Related Atlas pages

Order-to-Cash — Process context for O2C requirements.
SAP Process Audit — Diagnostic context for process-related requirements.
Master Data Issues Blocking Sales Orders — Scenario linking master data gaps to requirements.

Verification status and limitations

This skill is a public working interpretation of requirements elicitation practices. It is not official BABOK or IIBA documentation. It focuses on practical enterprise and SAP contexts and may not cover specialized domains such as safety-critical systems or financial trading platforms.

Known limitations: the skill assumes access to stakeholders and system documentation. In environments with high turnover or poor documentation, additional discovery work is needed before elicitation can be effective. The skill does not cover formal requirements engineering tools or model-driven specification methods.