Requirements Engineering – Where Empathy Meets Analytical Precision

For me, the people who use the system are always at the center of software development.

Clear goals from the client matter — but understanding the needs of all stakeholders is what makes the difference.

Analytical skills and interpersonal strengths belong together: asking the right questions, listening actively, sharing thoughts — and discussing them constructively when needed.

Working according to IREB/CPRE principles, certified in PRINCE2 Agile

The Balance Between People and Method

  • Understanding people: Different stakeholders have different perspectives — all of them matter
  • Listening actively: What is being said — and what is not being said?
  • Making the implicit explicit: Bringing assumptions and unspoken expectations to light
  • Creating shared understanding: Building a common language between business, IT, and management

My Philosophy: Empathy as a Foundation

Empathy is not just a nice-to-have — it helps make real needs visible and forms the foundation for implementable requirements.

This has been a personal driver for me for a long time.

In fact, it was exactly this passion for requirements engineering that ultimately led me into software development.

My Approach According to IREB/CPRE Standards

Aligned with IREB/CPRE principles , my focus is on measurable, testable, and traceable requirements .

Requirements Elicitation
Elicit requirements
  • Stakeholder workshops moderated in a structured way
  • Interviews with users, IT, and management
  • Observation of existing processes
  • Document analysis of existing systems
  • Prototyping to validate concepts
Requirements Analysis
Analyze requirements
  • Conflict analysis between stakeholder requirements
  • Prioritization by business value and risk
  • Feasibility analysis from technical and organizational perspectives
  • Gap analysis between current and target state
  • Impact analysis on existing systems
Requirements Specification
Specify requirements
  • SRS documents according to IEEE standards
  • Use cases with preconditions and postconditions
  • UML diagrams (activity, sequence, state)
  • Acceptance criteria formulated in a testable way
  • NFR specification (performance, security, etc.)
Requirements Validation
Validate requirements
  • Review workshops with all stakeholders
  • Walkthroughs of use cases and scenarios
  • Prototype demos for early validation
  • Deriving test cases from acceptance criteria
Requirements Management
Manage requirements
  • Traceability matrix between requirements and tests
  • Change management for requirement changes
  • Versioning of all requirements documents
  • Baseline management for regulated environments

Key Work Products & Deliverables

I deliver clear, implementable artifacts that provide the foundation for successful execution:

Requirements Specifications

Functional requirements: What should the system do?

Non-functional requirements: How should it do it? (performance, security, usability)

Constraints: Boundary conditions and limitations

Use Cases & UML Diagrams

Use case specifications: actors, preconditions, main and alternative flows

Activity diagrams: visualized process flows

Sequence diagrams: interactions between system components

State diagrams: state transitions in the system

Acceptance Criteria & Tests

Testable acceptance criteria: When is a requirement fulfilled?

Test scenarios: derive concrete test cases

Given-When-Then: BDD style for acceptance tests

Traceability Matrix

Requirements-to-tests: Which test validates which requirement?

Requirements-to-design: Where is the requirement implemented?

Impact analysis: Which components are affected by changes?

Data & Process Models

Entity-relationship diagrams: visualized data model

BPMN process models: documented business processes

Data flow diagrams: data flows between systems

Feasibility Studies

Proof of concept: validate technical feasibility

Prototypes: create functional demonstrators

Spikes: identify technical risks early

Technical Perspective: Requirements + Feasibility

Even though programming is not typically part of requirements analysis , my practical experience in C#, .NET, and system integration provides unique advantages:

Realistic Effort Estimation

I understand not only what should be implemented, but also how — and can therefore estimate effort and feasibility realistically.

Technical Constraints

I identify technical constraints early and can integrate them into the requirements specification.

Proof-of-Concept Implementations

When needed, I can develop small test applications to validate technical feasibility — especially valuable for integrations with external systems (LIMS, OPC/UA, REST APIs).

A Shared Language with Developers

I speak both the language of business stakeholders and that of developers — and can translate between the two worlds.

The Result

A detailed, implementable concept — ready for implementation. Complexity becomes tangible, and decisions become actionable.

Specialization: Requirements Engineering in Regulated Environments

BioPharma, healthcare IT, and life science place particular demands on requirements engineering:

GxP-Compliant Documentation
  • User Requirements Specification (URS): structured according to GAMP5
  • Functional Specification (FS): how are URS implemented?
  • Design Specification (DS): technical design documented
  • Traceability Matrix: URS → FS → DS → Tests
  • Risk Assessment: which requirements are critical?
Validation & Compliance
  • IQ/OQ/PQ preparation: requirements must be testable
  • 21 CFR Part 11: account for electronic records and signatures
  • Data Integrity (ALCOA+): requirements for audit trail and versioning
  • Change Control: impact assessment for requirement changes
  • Audit readiness: documentation prepared for inspections

Communication: The Bridge Between All Worlds

Requirements engineering is 80% communication and 20% documentation.

Asking the Right Questions

What is the actual problem? What are the goals? Which assumptions exist?

Listening Actively

Not just hearing what is said — but also understanding what is meant .

Sharing Thoughts

Communicating ideas openly, gathering feedback, and finding the best solution together.

Creating Shared Understanding

Between business , IT , and management — so that in the end, everyone means the same system.