Skip to main content

Requirements

The requirements process describes how the market opportunities and system requirements are received from Portfolio and Product Management and transformed into epics, features, and stories.

The functional analysis (not the solution/design) is also part of the requirement process and how the functionality from the stakeholder perspective is captured in the user stories. Please note; that a stakeholder for a user story can be an external customer, another subsystem, or anyone else requesting the functionality.

Process Overview​

Principles​

  • Define system requirements
  • Define system epics (consider different types: business, architecture, UX, IP and Enabler)
  • Breakdown system epics into epics, features, and stories
  • It is highly recommended that the size of epics, features, and stories fits in releases, increments, and sprints
  • Ensure the content of epics, features, and stories is clear and precise, including description, acceptance criteria, estimates, paths, links, and security information.
  • Visualize dependencies and ensure consistency and traceability of system epics, epics, features, and stories
  • Implemented epics/features/stories are not maintained, i.e., new epics/features/stories are defined if changes are needed

Activities​

requirement

Artifacts​

Artifact​Description​RACI​Receiver​Comments
System RequirementNeeds from different stakeholders are defined in system requirements.
Owned by PPM​		(R): Product Manager
(A): Product Manager
(C): Cyber Security Engineer, Product Owner, Release Owner, Technical Coordinator, Test Lead
(I): Architect, Head of Cyber Security, Safety Engineer		Product Owner-
System Requirement Change RequestA change request (CR) on a System Requirement.
PPM responsible.		(R): Product Manager
(A): Product Manager
(C): Cyber Security Engineer, Product Owner, Release Owner, Technical Coordinator, Test Lead
(I): Architect, Head of Cyber Security, Safety Engineer		Product Owner-
System EpicThe System Epics are based on an SR from PPM. They can be refined by R&D. Enablers added.(R): Product Owner, Release Owner
(A): Product Owner
(C): Architect, Release Owner, Technical Coordinator, Product Manager
(I): Cyber Security Engineer, Quality Control Manager, Test Lead		Product Owner-
EpicAn Epic is a container for a significant development initiative that captures the more substantial investments within a stream.(R): Product Owner
(A): Product Owner
(C): Architect, Cyber Security Engineer, Development Team, Ex Representative, Release Owner, Test Lead, Product Manager
(I): Quality Control Manager, Technical Coordinator		Dev. Team-
FeatureFeatures are services that fulfill stakeholder needs. Each includes a name, benefits hypothesis, and acceptance criteria. They should have a size to fit within a PI.(R): Development Team
(A): Product Owner
(C): Architect, Cyber Security Engineer, Ex Representative, User Experience Designer, Safety Engineer
(I): Quality Control Manager, Test Lead, Product Manager		Dev. Team-
User StoryFunctional description, shown on team boards.(R): Development Team
(A): Product Owner
(C): Development Team
(I): -		Dev. Team-
Implementation Proposal (IMP)Analyzing requirements (system-, dev. streams), proposing implementation alternatives, and selecting the best one. It serves as the basis for further work.(R): Development Team
(A): Stream Owner
(C): Architect, Cyber Security Engineer, Development Team, Ex Component Responsible, Ex Representative, Product Owner, Test Lead, Safety Engineer
(I): Configuration Manager, Release Owner, Technical Coordinator		Dev. TeamOptional: Use IMP when clarification is needed.
Note: Cyber Security, Safety, and Ex roles should be considered when applicable.

Dependencies​

requirement

References​

  • TBD
Owner: Requirements Team