Experience Mapping Requirements
Use When
- converting customer, employee, stakeholder, or ecosystem journeys into traceable requirements across touchpoints, pain points, evidence, and future states; use service-blueprint-requirements for backstage delivery detail.
- Use this procedure when the required source artefacts are available and
Experience map and traceable requirement set is the next lifecycle deliverable.
Do Not Use When
- Use
service-blueprint-requirements when that neighbouring route owns the decision or deliverable.
- Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.
Required Inputs
| Artefact |
Source or provider |
Required? |
Behaviour when missing |
| Research evidence, personas, journey scope, touchpoints, emotions, pain points, and outcomes |
Users, service owners, and discovery evidence |
Yes |
Stop the affected step, name the missing source, and return only a qualified gap record. |
Workflow
- Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.
- Apply this skill's existing domain workflow and decision rules to produce
Experience map and traceable requirement set.
- Stop when a required source, accountable decision owner, or deterministic test oracle is absent.
- Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.
Outputs
| Artefact |
Consumer |
Acceptance condition |
| Experience map and traceable requirement set |
PRD, SRS, UX, testing, rollout, and governance owners |
Required sections are populated, source links resolve, and every material requirement or decision has an observable review or test oracle. |
Evidence Produced
| Evidence |
Reviewer |
Acceptance condition |
Source, decision, trace, and validation record for Experience map and traceable requirement set |
Requirements quality reviewer |
Inputs used, decisions made, checks run, failures, and unassessed items are explicit. |
Capability and permission boundaries
Read and search are required. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require explicit authority.
Degraded mode
Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check not assessed; never convert an unassessed check into a pass.
Decision Rules
| Choice or condition |
Action |
Failure or risk avoided |
| A journey claim has no observation, source, or affected persona |
Mark it as a hypothesis and schedule validation. |
Designed experiences based on invented behaviour. |
| Required inputs and test oracles are complete |
Continue through the existing workflow and record evidence. |
A deliverable whose acceptance cannot be reproduced. |
| A mandatory source or owner is missing |
Stop the affected branch and issue a qualified gap record. |
Fabricated context or unauthorised decisions. |
Quality Standards
- Preserve stable identifiers and bidirectional traceability from project evidence to
Experience map and traceable requirement set and its acceptance checks.
- Apply ISO/IEEE measures only with a named metric, method, threshold, evidence source, and responsible reviewer; run the anti-slop gate before release.
Anti-Patterns
- Producing
Experience map and traceable requirement set from assumed context. Fix: cite the project source or mark the scope blocked.
- Accepting a material requirement without a deterministic oracle. Fix: add a measurable result, boundary, and verification method.
- Crossing into
service-blueprint-requirements without routing the decision. Fix: hand off the named input and preserve trace links.
- Treating an unavailable check as passed. Fix: mark it
not assessed and state the release consequence.
- Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.
References
Output Shape
Write projects/<ProjectName>/<phase>/<document>/experience_mapping_requirements.md with:
- Mapping scope and evidence base.
- Current-state journey table.
- Opportunity and failure analysis.
- Future-state requirement candidates.
- Journey-to-requirements trace matrix.
- Validation hypotheses and open research gaps.
1---2name: 11-experience-mapping-requirements3description: Use when converting customer, employee, stakeholder, or ecosystem journeys into traceable requirements across touchpoints, pain points, evidence, and future states; use service-blueprint-requirements for backstage delivery detail.4---56# Experience Mapping Requirements78<!-- local-contract-start -->9<!-- dual-compat-start -->10## Use When1112- converting customer, employee, stakeholder, or ecosystem journeys into traceable requirements across touchpoints, pain points, evidence, and future states; use service-blueprint-requirements for backstage delivery detail.13- Use this procedure when the required source artefacts are available and `Experience map and traceable requirement set` is the next lifecycle deliverable.1415## Do Not Use When1617- Use `service-blueprint-requirements` when that neighbouring route owns the decision or deliverable.18- Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.1920## Required Inputs2122| Artefact | Source or provider | Required? | Behaviour when missing |23| --- | --- | --- | --- |24| Research evidence, personas, journey scope, touchpoints, emotions, pain points, and outcomes | Users, service owners, and discovery evidence | Yes | Stop the affected step, name the missing source, and return only a qualified gap record. |2526## Workflow27281. Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.292. Apply this skill's existing domain workflow and decision rules to produce `Experience map and traceable requirement set`.303. Stop when a required source, accountable decision owner, or deterministic test oracle is absent.314. Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.3233## Outputs3435| Artefact | Consumer | Acceptance condition |36| --- | --- | --- |37| Experience map and traceable requirement set | PRD, SRS, UX, testing, rollout, and governance owners | Required sections are populated, source links resolve, and every material requirement or decision has an observable review or test oracle. |3839## Evidence Produced4041| Evidence | Reviewer | Acceptance condition |42| --- | --- | --- |43| Source, decision, trace, and validation record for `Experience map and traceable requirement set` | Requirements quality reviewer | Inputs used, decisions made, checks run, failures, and unassessed items are explicit. |4445## Capability and permission boundaries4647Read and search are required. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require explicit authority.4849## Degraded mode5051Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check `not assessed`; never convert an unassessed check into a pass.5253## Decision Rules5455| Choice or condition | Action | Failure or risk avoided |56| --- | --- | --- |57| A journey claim has no observation, source, or affected persona | Mark it as a hypothesis and schedule validation. | Designed experiences based on invented behaviour. |58| Required inputs and test oracles are complete | Continue through the existing workflow and record evidence. | A deliverable whose acceptance cannot be reproduced. |59| A mandatory source or owner is missing | Stop the affected branch and issue a qualified gap record. | Fabricated context or unauthorised decisions. |6061## Quality Standards6263- Preserve stable identifiers and bidirectional traceability from project evidence to `Experience map and traceable requirement set` and its acceptance checks.64- Apply ISO/IEEE measures only with a named metric, method, threshold, evidence source, and responsible reviewer; run the anti-slop gate before release.6566## Anti-Patterns6768- Producing `Experience map and traceable requirement set` from assumed context. Fix: cite the project source or mark the scope blocked.69- Accepting a material requirement without a deterministic oracle. Fix: add a measurable result, boundary, and verification method.70- Crossing into `service-blueprint-requirements` without routing the decision. Fix: hand off the named input and preserve trace links.71- Treating an unavailable check as passed. Fix: mark it `not assessed` and state the release consequence.72- Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.7374## References7576- [Skill authoring and release standard](../../../../docs/skill-authoring-standard.md)77- [Experience Map To Requirement Conversion](references/experience-map-to-requirement-conversion.md)78<!-- dual-compat-end -->79<!-- local-contract-end -->8081## Output Shape8283Write `projects/<ProjectName>/<phase>/<document>/experience_mapping_requirements.md` with:84851. Mapping scope and evidence base.862. Current-state journey table.873. Opportunity and failure analysis.884. Future-state requirement candidates.895. Journey-to-requirements trace matrix.906. Validation hypotheses and open research gaps.
peterbamuhigire