Requirement Management 

02- Analysis Quality Model

In order to have certified analysis, you should ensure completeness, consistency, correctness.

From the OOA perspective, the process should be as follow:

1. Object responsibility

2. Object configuration

3. Domain generic attributes

4. Domain-specific attributes

5. Object functionalities

6. Main scenarios

7. Alternative scenarios

8. BRM: Business rules management

9. BPM: Business process management

10. Object Views

11. Object states

12. Sender: What to send to the world

13. Subscribers: What to listen for from the world

14. Integration requirements

• Cross modules

• Third Parties

15. Reports and visualization

16. Object Security

• Object metadata

• Object data

03-Requirements Management Process

Requirements Management ensures that business needs are systematically elicited, validated, analyzed, baselined, traced, and approved before they are handed over to architecture and development.

1. Requirements Planning & Preparation

• Review the approved Requirements Elicitation Plan.

• Review available business, commercial, and impact-analysis information.

• Establish the project landscape and create the EA/Azure DevOps starting point.

• Define the system boundary and identify what is inside and outside the solution scope.

• Identify related systems, integration points, and organizational dependencies.

• Identify the appropriate customer-side business and domain experts.

Primary Role: Product Owner (PO)
Supporting Roles: Business/Customer, Enterprise Architect (EA), Project Manager (PM)

Key Outputs:

• Project/EA Start Page

• System Boundary

• Initial Integration Boundaries

• Requirements Sources

2. Requirements Elicitation

The Product Owner works with stakeholders to understand the business problem, expected outcomes, users, and operational context.

• Study the business domain, applicable standards, competitors, and comparable solutions.

• Identify user personas and their business objectives.

• Identify opportunities that can provide additional value beyond existing solutions.

• Prepare stakeholder interview questions using appropriate techniques such as:

  • Pyramid – move from broad questions to detailed questions.

  • Funnel – start broad and progressively narrow the discussion.

  • Diamond – expand, narrow, and then expand again to explore alternatives.

• Understand the current business/system workflow.

• Capture functional requirements.

• Capture quantitative non-functional requirements, such as performance, availability, security, usability, and response time.

• Capture quantitative digital-transformation requirements.

Primary Role: Product Owner
Supporting Roles: Customer/Business Stakeholders, Scrum Master, Business Analyst, EA

Key Output:

• Identified and documented requirements

• Initial user stories

• Current-state workflow

3. Requirements Documentation & Specification

Requirements are transformed into structured and understandable work products.

• Define the required content and documentation format.

• Prepare and distribute the approved content through the appropriate project channels.

• Document required software and hardware interfaces.

• Identify associated product documentation and training requirements.

• Define acceptance criteria for requirements and user stories.

• Document requirements using the approved repository and project tools.

Primary Roles: PO, Scrum Master
Supporting Roles: Business Analyst, Technical Lead, QC/Test Team

Key Outputs:

• Structured User Stories

• Acceptance Criteria

• Interface Requirements

• Supporting Documentation

4. Requirements Traceability & Approval

Requirements must be traceable from business needs through use cases and implementation.

• Establish traceability between:

  • Requirements ↔ Use Cases

  • Personas ↔ Use Cases

  • Use Cases ↔ Classes/Objects

• Review requirements with the requirement provider/customer.

• Obtain formal approval through the agreed mechanism, such as:

  • Email approval

  • Meeting Minutes (MOM)

  • Electronic/signature approval

• Store approved requirements in the Enterprise Architect/Azure DevOps repository.

Primary Role: Product Owner
Supporting Roles: Technical Lead, Customer/Requirement Provider, EA

Key Output:

• Approved and traceable requirements

5. Requirements Validation

Validation confirms that requirements are complete, consistent, unambiguous, traceable, and testable.

• Review EA models and requirements for quality.

• Verify that every formal requirement is traceable to a higher-level requirement.

• Identify inconsistencies between requirements and project work products.

• Record findings in a deficiency/defect report.

• Classify and prioritize identified defects.

• Assign defects to the responsible analyst.

• Correct the defects and update the affected requirements.

• Revalidate the corrections.

• Close the defects after successful verification.

Primary Roles: Test Team (TT), Customer, Test Manager (TM)
Supporting Roles: Analyst (AN), Product Owner

Key Outputs:

• Defect/Deficiency Report

• Corrected Requirements

• Validated Requirements

• Baselined EA Repository

6. Requirements Analysis

Validated requirements are analyzed in sufficient detail to support solution design and implementation.

• Examine the solution type and determine the required level of detail.

• Refine and classify user stories.

• Establish traceability to high-level requirements/use cases.

• Group related stories into Epics and Features.

• Identify non-functional requirements for each relevant user story, including:

  • Performance

  • Response time

  • Availability

  • Security

  • Connectivity

  • Accessibility

  • Usability

• Establish a common solution glossary for business and technical terminology.

• Create BPMN models where business-process analysis is required.

• Create use-case models.

• Identify system actors and their relationships.

• Define for each use case:

  • Preconditions

  • Postconditions

  • Main scenario

  • Alternative/exception scenarios

  • Triggers

Primary Role: Product Owner
Supporting Roles: QC, Development Team, Scrum Master, UX

7. UX, Workflow & Solution Modeling

Requirements are further analyzed through visual and behavioral models.

• Develop wireframes/prototypes for important scenarios.

• Validate wireframes with the testing and implementation teams.

• Convert use cases into activity diagrams.

• Identify missing or dependent scenarios.

• Develop class/data models based on business entities.

• Create UI mockups and link UI elements to corresponding use cases.

• Apply usability and data-visualization principles.

• Define object:

  • Attributes

  • Operations

  • Lifecycle

  • Filters

  • Reports

  • Dashboards

  • Security requirements

  • Logging requirements

  • Integration requirements

Primary Roles: Product Owner, UX
Supporting Roles: QC, Development Team, Technical Lead

Key Outputs:

• Wireframes

• Use Cases

• Activity Diagrams

• Class/Data Models

• UI Mockups

• Object/Feature Models

8. Analytics, Measurement & Reporting Requirements

Where applicable, define analytical and reporting requirements as part of the requirements analysis.

• Define measurements at:

  • Record/instance level

  • Object level

  • Relationship level

  • Cross-object level

• Define required:

  • KPIs

  • Trends

  • Comparative reports

  • Dashboards

  • Correlations

  • Forecasting

  • Analytical models

• Define required reporting frequency, such as:

  • Daily

  • Weekly

  • Monthly

  • Quarterly

  • Yearly

  • On-demand

Primary Role: Product Owner
Supporting Roles: Business Stakeholders, Data/BI Team, UX, Development Team

9. Requirements Conflict Resolution

Conflicts must be identified and resolved before requirements are baselined.

• Identify requirement-to-requirement conflicts.

• Identify conflicts between different users/personas.

• Identify missing business rules and scenarios.

• Identify requirements that cannot be adequately tested.

• Review conflicts with relevant stakeholders.

• Negotiate and agree on the appropriate resolution.

• Update the requirements and related models.

• Communicate the resolution to affected stakeholders.

Primary Role: Product Owner
Supporting Roles: Customer, QC Team, Development Team, Technical Team

Key Principle:
Requirements should be complete, correct, consistent, feasible, unambiguous, and testable.

10. Requirements Baseline & Commitment

Once requirements have been reviewed and conflicts resolved:

• Update all affected requirements and models.

• Perform final requirements review.

• Baseline the approved requirements and analysis models.

• Obtain formal customer/requirement-provider approval.

• Obtain implementation-team commitment.

• Store the baseline in the approved repository.

• Establish change control for subsequent modifications.

Primary Role: Product Owner
Supporting Roles: Customer, Technical Team, QC, Scrum Master, Project Manager

Key Outputs:

• Baselined Requirements

• Baselined Analysis Models

• Customer Approval

• Team Commitment

11. Handover to Architecture & Development

The approved requirements package becomes the input to the next lifecycle stage.

The baseline should contain, where applicable:

• Approved User Stories

• Epics and Features

• Acceptance Criteria

• Use Cases

• Personas/Actors

• Business Processes

• Activity Diagrams

• Data/Class Models

• UI/Wireframes

• Non-Functional Requirements

• Integration Requirements

• Security Requirements

• Reporting & Analytics Requirements

• Traceability Matrix

• Approved Defects/Resolutions

• Customer Approval

Output: Enterprise Architect Repository / Approved Requirements Baseline

Next Process: Architecture & Solution Design.

Roles & Responsibilities

• Product Owner (PO)

Owns requirements elicitation, analysis, prioritization, clarification, stakeholder alignment and approval

• Customer / Business Stakeholder

Provides business needs, validates requirements and approves the baseline

• Enterprise Architect (EA)

Supports business/system modeling, boundaries, integrations and architecture traceability

• Business Analyst / Analyst (AN)

Analyzes requirements, resolves assigned defects and maintains requirement documentation

• Scrum Master

Facilitates the process, supports documentation and team alignment

• Technical Lead (TL)

Reviews technical feasibility and requirements-to-solution traceability

• UX

Converts requirements into user-centered workflows, wireframes and UI models

• QC / Test Team

Validates completeness, testability, missing scenarios, business rules and acceptance criteria

• Test Manager (TM)

Manages requirement-validation defects, prioritization, delegation and closure

• Development Team

Reviews feasibility, identifies technical conflicts and commits to implementation

End-to-End Flow

Plan → Elicit → Document → Trace → Validate → Analyze → Model → Resolve Conflicts → Approve → Baseline → Commit → Handover

This structure preserves the substance of your original SQMS procedure while making it easier to present as a portal learning/process page.

2-Scope Engineering In Agile

Introduction

Agile come with new approach of requirements modeling, which called user story, the evolution of text-based requirements.

User Story in Depth

• Format

  • Who: User

  • What : Requirement

  • Why : Objective

• Good User Story:

  • Simple and easy to read, from 3-9 steps

  • No GUI details

  • No data format

  • At User goal level

• User stories problems:

  • Difficult to prioritize

  • Difficult to understand dependency

  • More smaller makes things worse

  • No single repository of artifacts like MDA, that represents the final version of the solution from all perspectives.

  • Upcoming user stories can replace and supersede previous ones

Persona In User stories

• What is? A persona 

  • Persona is a fictional, detailed profile representing a typical user of a product or system. It's based on real user data, behaviors, goals, and pain points.

  • All requirements are driven from the user persona, using the following pillars:

    • Functional requirements: from the persona values, problems, and challenges that they need to resolve.

    • Non-Functional requirements: from the different characteristics:

      • • Expectation of fast service

        • UX design

• Adding Personas to your user stories will enrich your solution requirements, as it focuses on the following areas:

  • Values:

    • • Goals

      • Demographics & background

      • Pain points & needs 

  • Characteristics

    • User behavior

    • Environment & usage context

Requirements Hierarchy

You can classify requirements as follows:

1. Theme

2. Initiative

3. Epic

4. Story

🧭 1. Theme

• Definition: Strategic business objective (broad direction)

• Scope: Company-wide vision or transformation goal

• Example: "Improve customer digital experience"
  
  

🎯 2. Initiative

• Definition: High-level investment to achieve part of the theme

• Scope: Cross-team or multi-epic objective

• Example: "Modernize online payment infrastructure"
  
  

🧩 3. Epic

• Definition: Large body of work requiring multiple sprints or teams

• Scope: Cross-functional development, decomposable into stories

• Example: "Implement new payment gateway API"
  
  

📋 4. Story (User Story)

• Definition: Smallest unit of work delivering user value

• Scope: Fits within a single sprint (2–5 days work)

• Format: “As a [persona], I want [feature], so that [benefit]”

• Example: "As a returning user, I want to save my credit card for faster checkout"

🔁 How it connects in DevOps:

• Theme → Initiative → Epic → Story

• Stories are implemented via CI/CD pipelines and tracked for metrics like lead time, deployment frequency, and change failure rate.

Example:

• Theme: Improve Platform Security

  1. Initiative: Automate Security Compliance

     1. Epic: Integrate SAST (Static Analysis)

        1. Story: Add SAST tool to CI/CD pipeline

        2. Story: Send alerts when vulnerabilities are found

     2. Epic: RBAC Implementation

        1. Story: Define access roles

        2. Story: Audit access logs

✅ Why it matters:

• Ensures strategic alignment across all levels

• Supports scaling Agile (e.g., SAFe, LeSS)

• Enables traceability, prioritization, and continuous delivery

• Clear breakdown from vision to execution

• Reporting, for example if the user request to review all developed stories regarding e-Payment

3-User Story Slicing Approach

What is User story slicing?

User Story Slicing is the practice of breaking down a large user story (epic or complex feature) into smaller, independent, and valuable stories that can be delivered and tested within a single sprint.

Why We need it?

• The story can’t be completed in a single sprint.

• It lacks a clear Definition of Done (DoD).

• The team struggles with estimating the effort.

• There are dependencies or an unclear scope.

• During backlog refinement or PI/Sprint Planning.

Slicing approaches?

• Scenario-Based: Happy/Alternatives

• Persona-Based: Employees, Customers, Backoffice, Admins

• Channel-Based: Web/Mobile/Kiosk

• Function Type: Functional/Non Functional

Eliminate technical Slicing like:

• Frontend stories

• BE Stories

• Database stories

• API stories

4-User story Vs Use cases

As the classification of DevOps can be as following:

1. Theme

2. Initiative

3. Epic

4. Story

But still the user story is totally different from the following as in the opposite graph, user story is functional, sprint focus, and cannot be considered as single repoitory of truth.