Problem definition and goals
An agreed description of the starting point, user needs, goals and scope, including the questions that still require a decision.
Business Analysis & Requirements Engineering
Requirements that developers can work with.
What should the software do? Which rules apply, and which exceptions matter? KAN Service combines business analysis and requirements engineering with technical understanding – from the first question to a verifiable requirement.
The starting point
Documented. But fully understood?
A business term means different things to two teams. A business rule describes the normal case but no exceptions. A requirement already specifies a solution while the goal remains unclear.
Such gaps can exist even in extensive specifications. KAN Service works with those involved to make them visible, resolve contradictions and record who needs to make each business decision.
Deliverables
What developers and stakeholders receive.
The following deliverables are developed according to the initiative. Their content and level of detail reflect what your team needs for decisions, implementation and testing.
Terminology and business rules
A shared business vocabulary and documented processes, states and exceptions, so that everyone involved interprets the same requirement consistently.
System context and interfaces
An overview of affected systems, data flows and responsibilities. Dependencies and technical constraints are recorded explicitly.
Requirements and acceptance criteria
Functional and non-functional requirements with verifiable criteria. Outstanding assumptions, priorities and decisions remain traceable.
How I work
Clarify before formalising.
Adrian Wildermuth develops an understanding of your business context and reviews findings continuously with stakeholders and delivery teams. Methods and documentation are adapted to the initiative and the tools already in use.
- 01
Understand the context
Identify goals, stakeholders and existing systems. Clarify what belongs within the initiative and what lies outside it.
- 02
Clarify the problem and rules
Review terminology, rules and exceptions with the business team. Identify contradictions and assign ownership of outstanding decisions.
- 03
Account for dependencies
Work with development and architecture teams to assess which data, interfaces and technical constraints are affected.
- 04
Review together and keep requirements current
Agree and prioritise requirements and acceptance criteria, then update them as new insights emerge during implementation.
Keep development in mind
Business decisions have technical consequences.
How current must the data be? Which system is responsible for it? What should happen during an outage? These questions connect business expectations with architecture and operations. Adrian Wildermuth brings experience in software development and distributed, highly available systems to this work.
Explore Technical Analysis and System ArchitectureAI as an accelerator
Fast implementation still needs clear requirements.
When AI tools create or change code, business rules, constraints and expected behaviour still need to be clear. Verifiable requirements help the team assess whether the result meets the actual need.
Initial conversation
Where does your team need clarity?
Whether at the start of an initiative or when fundamental questions remain during implementation, discuss your situation directly with Adrian Wildermuth. Engagements cover the Bern region and Switzerland through hybrid collaboration.
Discuss your initiative