docs-onboarding/requirements-engineering-process.md

# Requirements Engineering Process

This document provides a comprehensive overview of our requirements engineering process. It is designed to help experienced professionals understand how we collect, document, and manage requirements using Azure DevOps. By adhering to this guide, we ensure consistency, traceability, and compliance throughout our projects.

The requirements engineering proicess is tightly bound to the [traceability concept](traceability-concept.md) and the [requirements gathering interview](requirements-gathering-interview.md).

Requirements are work items in Azure DevOps and the summarizing AsciiDoc document is located within the [docs-requirements](https://dev.azure.com/ypsag/ITSandbox/_git/docs-requirements) repository.

## Overview

Our requirements engineering process is a structured approach that takes us from the initial stakeholder conversations to a finalized set of requirements. We emphasize:

- **Clarity and Testability:** Requirements should be simple statements that are testable. We are writing test cases along with the stakeholder requirements.
- **Traceability:** Maintaining clear links from requirements through to implementation and testing and back.
- **Compliance:** Ensuring all regulatory requirements are identified and addressed.
- **Stakeholder Engagement:** Actively involving stakeholders throughout the process.
- **Risk Management:** Identifying and mitigating risks associated with requirements. Recording them linked to the requirements.

We use **Azure DevOps** with the **CMMI process template** to manage our Work Items, facilitating collaboration and traceability.

## Process Steps

### 1. Initial Engagement

**Objective:** Establish a foundational understanding of the project and build relationships with stakeholders.

- **Activities:**
  - Conduct initial meetings to understand project vision and objectives with sponsors or, if already appointed, project managers.
  - Establish communication channels and protocols. E.g. use Teams channels, Slack or such for quick communication.
  - Set expectations for the requirements gathering process.

### 2. Stakeholder Identification

**Objective:** Identify all individuals and groups who have an interest in or influence over the project.

- **Activities:**
  - Create a stakeholder register. This should be part of the summarizing AsciiDoc document.
  - Analyze stakeholder roles, interests, and influence.
  - Prioritize stakeholders based on their impact on requirements.

### 3. Requirements Gathering

**Objective:** Collect detailed requirements from stakeholders.

- **Activities:**
  - Conduct interviews using our [Interview Questionnaire](requirements-gathering-interview.md) (refer to the separate file).
  - Hold workshops and brainstorming sessions.
  - Observe existing systems and workflows.
  - Capture raw requirements and create initial Requirement Work Items in Azure DevOps.
  - Demonstrate and teach how unexpierenced stakeholders can review requirements and their current state in Azure DevOps.

### 4. Requirements Documentation

**Objective:** Document requirements clearly and comprehensively.

- **Activities:**
  - Use the "Requirement" Work Item in Azure DevOps to record each requirement.
  - Include detailed descriptions, affected regulations, and stakeholder information.
  - Ensure each requirement is a simple, testable statement. Write test cases along with the requirements.
  - Add acceptance criteria.

### 5. Requirements Analysis

**Objective:** Refine and validate the collected requirements.

- **Activities:**
  - Analyze requirements for clarity, completeness, and feasibility.
  - Identify and resolve conflicts or duplicates.
  - Validate requirements with stakeholders.

### 6. Traceability

**Objective:** Maintain end-to-end traceability of requirements through the project lifecycle.

- **Activities:**
  - Link Requirement Work Items to related Specifications, Design Documents, Implementation Tasks, Test Cases, and other artifacts in Azure DevOps.
  - Use a Traceability Matrix to map relationships (see [traceability concept](traceability-concept.md)).

### 7. Requirements Management

**Objective:** Manage changes to requirements systematically.

- **Principles:**
  - **Immutability of Requirements:** Once a requirement is baselined, it should not be altered. If changes are needed, deprecate the old requirement and create a new version.
  - **Version Control:** Use Azure DevOps Work Items to link older versions with their successors and maintain history.
- **Activities:**
  - Implement a change control process for requirements updates.
  - Communicate changes to all stakeholders.

### 8. Risk Management

**Objective:** Identify and mitigate risks associated with requirements early in the project.

- **Activities:**
  - Document risks as separate work item of type Risk and link it to the Requirement Work Items.
  - Assess the impact and likelihood of each risk.
  - Develop mitigation strategies and documente them along with the risk.

## Azure DevOps Guidelines

### Requirement Work Item Structure

When creating a Requirement Work Item in Azure DevOps, ensure the following fields are populated:

- **Title:** Clear and concise summary of the requirement.
- **Stakeholders:** Names or roles of stakeholders associated with the requirement.
- **Description:** Detailed explanation, including purpose and background.
- **Affected Regulations:** List any laws, standards, or regulations impacting the requirement.
- **Acceptance Criteria:** Conditions that must be met for the requirement to be considered fulfilled.
- **Test Cases:** Linked test cases for validating the requirement.
- **Attachments:** Include supporting documents if necessary.

### Maintaining Traceability

Traceability is crucial for tracking requirements through all stages of development. We use a Traceability Matrix to map requirements to other project artifacts. As of now the document is created manually in AsciiDoc format. We aim to automate this process in the future.

**Template:**

| Requirement ID | Requirement Title | Affected Regulations | Stakeholders | Test Case ID(s) |
|----------------|-------------------|----------------------|--------------|-----------------|
| RQ-001         | [Title]           | [Regulations]        | [Roles]      | TC-001          |

- **Requirement ID:** Unique identifier, we are using the Azure DevOps work item id.
- **Requirement Title:** Summary of the requirement.
- **Affected Regulations:** Relevant laws, standards, or regulations. We are using a link to the requirement work item representing the regulation in Azure DevOps.
- **Test Case ID(s):** Linked test cases for validation, we are using the Azure DevOps Test Case id.

## Best Practices and additional Notes

- **Simple and Testable Statements:** Write requirements that are clear and can be verified through testing.
- **Regulatory Compliance:** When regulations affect a requirement, include specific clauses or references.
- **Versioning:** Do not alter baselined requirements. Deprecate and replace with new versions as needed.
- **Stakeholder Engagement:** Keep stakeholders involved throughout the process for validation and feedback.
- **Risk Identification:** Address risks early by documenting them alongside requirements.
- **Consistent Terminology:** Use standard terms and definitions to avoid confusion.
- **Communication:** Utilize Azure DevOps **Discussion** section in Work Items for conversations and decisions. Set up notifications for stakeholders to keep them informed of updates.
- **Training:** Familiarize yourself with the Azure DevOps CMMI process template and our customized fields. Stay updated on best practices in requirements engineering.
- **Regulatory Awareness:** Stay informed about regulations relevant to our projects (e.g., GDPR, HIPAA). Consult with compliance officers when in doubt.

## LLM Prompt example

```text
Our situation is as follows:
- We are a med tech company producing physical devices incl. embedded hardware and software, mobile apps connected via bluetooth and cloud components like user management device management for those mobile apps
- We are the IT department offering IT infrastructure in the Azure cloud for those products. We are not creating the products and we are not responsible for the processes involved to create the products. We are only providing infrastructure for those products and are responsible for IT infrastructure changes.

We have identified the following list of regulations as potentially relevant:
- ISO/IEC 62304 Medical device software - Software life cycle processes
- ISO/IEC 27001 Information technology - Security techniques - Information security management systems - Requirements
- ISO/IEC 27017 Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services
- ISO/IEC 27002 Information security, cybersecurity and privacy protection Information security controls
- ISO/IEC 27018 Information technology - Security techniques - Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
- ISO 14971 Medical devices Application of risk management to medical devices
- ISO 13485 Medical devices Quality management systems - Requirements for regulatory purposes
- FDA 21 CFR Part 820: Title 21 Code of Federal Regulations Part 820 - Quality System Regulation
- FDA 21 CFR Part 11: Title 21 Code of Federal Regulations (CFR) Part 11 - Electronic Records; Electronic Signatures
- ALCOA+ Principles Compliance

You are an expert in the field of requirements engineering in the regulated environment of a med tech company. I need your support in writing requirement.

When writing requirements, use the following format to clearly articulate the need, the stakeholder’s perspective, the desired outcomes, and the rationale. Adhere strictly to this structure:

When [condition or situation triggering the requirement],
As [stakeholder role],
I want [specific actions or outcomes to achieve].
This ensures [reason or benefit for implementing the requirement].

Key Guidelines:
1. Condition or Situation: Clearly state when or under what circumstances the requirement applies. Use "When..." to frame this.
2. Stakeholder Role: Explicitly identify the stakeholder requesting the requirement. Use "As [stakeholder role]..." to reflect the stakeholder's voice.
3. Desired Outcomes: Use "I want..." to specify what the stakeholder expects or desires to be achieved. List actions or outcomes in a concise, actionable manner.
4. Rationale: Use "This ensures..." to explain why the requirement is important or what benefit it provides.
5. Add a list of relevant acceptance criteria
6. Add a list of test cases
7. Add a list of regulations that are relevant to the requirement inlcluding the requirement of the regulation and the implication of the requirement.

Example:
Title: Document Authorship and Timestamps
When creating or modifying documents,
As IT QA CSV representative,
I want every document to:
- Record the author.
- Include timestamps for creation and all modifications.
This ensures compliance with the "Attributable" principle of ALCOA+.
Acceptance criteria:
- The author's name is recorded on every document.
- Timestamps are added for document creation and all modifications.
Test cases:
- Verify author name is captured on document creation.
- Verify timestamps are added for all document modifications.
List of regulations:
- ALCOA+ Principles Compliance
    - Requirement: Attributable
    - Implication: Every document must record the author and timestamps for creation and modifications.

The input data is:

Requirement title: >>fill in the title<<
Stakeholder: >>fill in the stakeholder role<<
Requirement description: >>fill in the requirement description in your words<<
```