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.

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.
• Traceability: Maintaining a clear line from requirements through to implementation and testing.
• 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.

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.
  • Establish communication channels and protocols.
  • 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.
  • 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 (refer to the separate file).
  • Hold workshops and brainstorming sessions.
  • Observe existing systems and workflows.
• Outcome:
  • Capture raw requirements and create initial Requirement Work Items 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.

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 Matrix).

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 to track changes 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 in the Requirement Work Items or as separate Risk Work Items.
  • Assess the impact and likelihood of each risk.
  • Develop mitigation strategies.

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.
• Description: Detailed explanation, including purpose and background.
• Acceptance Criteria: Conditions that must be met for the requirement to be considered fulfilled.
• Affected Regulations: List any laws, standards, or regulations impacting the requirement.
• Stakeholders: Names or roles of stakeholders associated with the requirement.
• Tags: Keywords for easy filtering and identification.
• Attachments: Include supporting documents if necessary.

Custom Fields and Links

To capture all necessary information:

• Custom Fields:
  • Stakeholders: If not already available, add a custom field to list stakeholders.
  • Regulations: Add a field to specify affected regulations or compliance requirements.
• Links:
  • Affected By: Use to link the requirement to regulations or higher-level requirements.
  • Related Work Items: Connect to tasks, user stories, or bugs.
  • Test Cases: Link to associated test cases validating the requirement.

Maintaining Traceability

Traceability is crucial for tracking requirements through all stages of development.

Traceability Matrix

We use a Traceability Matrix to map requirements to other project artifacts.

Template:

Requirement ID	Requirement Description	Affected Regulations	Stakeholders	Specification ID	Design Doc ID	Implementation IDs	Test Case ID(s)	Status
RQ-001	[Description]	[Regulations]	[Names]	SP-001	DD-001	[IDs]	TC-001	Open

• Requirement ID: Unique identifier (e.g., RQ-001).
• Specification ID: Reference to detailed specifications.
• Design Doc ID: Reference to design documents.
• Implementation IDs: Linked Work Items for development tasks.
• Test Case ID(s): Linked test cases for validation.

Work Item Linking in Azure DevOps

• Use hierarchical links (Parent/Child) to represent decomposition.
• Use "Related" links for associations between Work Items.
• Enforce link policies to ensure no Work Item is closed without proper linkage.

Best Practices

• 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.
• Documentation: Maintain thorough documentation at each step to support traceability and compliance.
• Risk Identification: Address risks early by documenting them alongside requirements.
• Consistent Terminology: Use standard terms and definitions to avoid confusion.

Additional Notes

• 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.
• Tools and Extensions:
  • Consider using Azure DevOps extensions for enhanced reporting and traceability visualization.
• Regulatory Awareness:
  • Stay informed about regulations relevant to our projects (e.g., GDPR, HIPAA).
  • Consult with compliance officers when in doubt.