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!