# Requirements Engineering and Management in Scientific Projects

To ensure scientific reproducibility and agile development, we follow a structured approach to capture requirements using OpenProject. This page explains our workflow and tool usage.

## 1\. Requirement Hierarchy

We use a three-tier hierarchy to bridge the gap between high-level goals and technical implementation.

### Epics (The Goal)

*   **Definition:** High-level functional areas or major project milestones. An Epic represents a complete functionality from start to finish.
    
*   **Example:** `Epic: Device Inventory`
    
*   **Status:** Usually _In Specification_ or _Specified_.
    

### Use Cases / Features (The Activity)

*   **Definition:** Closed activities describing an interaction between a user and the system. This is where classical RE happens.
    
*   **Documentation:** Every Use Case must include a **Context Table** (Actors, Pre-conditions, Main Scenario) in its description and/or Use-Case diagramms.
    
*   **Example:** `[UC-01] Register new device`
    
*   **Status:** _In Specification_ or _Specified_.
    

### User Stories & Tasks (The Implementation)

*   **User Stories:** Small, non-breakable functional features.
    
    *   _Format:_ "As a _<role>_, I want _<goal>_, so that _<benefit>_."
        
    *   _Example:_ `US-01: Enter Basic Data`
        
*   **Tasks:** Technical implementation steps or maintenance work.
    
    *   _Example:_ `Task: Create database model`
        

## 2\. Non-Functional Requirements (NFRs)

NFRs (Security, Performance, Data Quality) are essential for research integrity. We capture them based on their scope:

1.  **Scope-based Capture:**
    
    *   **As a User Story:** If the NFR is a requirement from a user's perspective.
        
        *   _Example:_ "As a researcher, I want the system to save my input in less than 2 seconds, so I can continue my work without interruption."
            
    *   **As a Feature:** If the NFR is a global constraint or technical requirement affecting the entire project or a major component.
        
        *   _Example:_ "The system must be immune to SQL injection attacks."
            
    *   **As a Task:** Only for pure technical implementation steps or one-off "to-dos" that don't describe system behaviour.
        
2.  **Categorization:** Every NFR must be assigned a **Category** (e.g., `NFR - Security`, `NFR - Performance`, `NFR - Legal`).
    
3.  **Cross-Cutting Concerns:** If an NFR applies universally (e.g., "Must follow Institute CI"), it is added to the **Definition of Done (DoD)** or the parent Use Case description.
    

## 3\. How to Use the Tools

### Versions & Roadmap

*   Every **Epic** and **Use Case** must be assigned to a **Version** (e.g., `Release 1.0 (MVP)`).
    
*   Use the **Workpackes** or the **Roadmap** modules to get a high-level overview of our progress and upcoming research milestones.
    

### Backlog (Planning)

*   Use the **Backlog** module to prioritize work.
    
*   **Product Backlog:** All refined User Stories.
    
*   **Sprint Backlog:** Stories we committed to for the current development cycle.
    

### Boards (Execution)

*   The **Action Board** is for daily work.
    
*   It is filtered to show only **User Stories** and **Tasks**.
    
*   Move cards from `New` ➡️ `In Progress` ➡️ `Closed` to update the team on your status.
    

> **Note:** Always link your User Story to a parent Use Case and the Use Case to the Epic to maintain traceability!