Service

Requirements Analysis & Software Discovery

Before software is built, we clarify goals, processes, requirements and risks. The result is a solid basis for scope, architecture, effort and implementation — or a well-founded recommendation not to build.

Start a projectView our work
Executive Summary

Requirements Analysis & Software Discovery in one minute.

For decision-makers: our position at a glance — when it fits, how we approach it, what we optimize for.

Discovery fits when
a project is still open from a business perspective, spans several departments or has to connect to existing systems.
A lighter approach is enough when
goal, users and scope are already clear and the project has few dependencies on other systems.
Typical trigger
an idea without a reliable effort estimate, or a process that currently lives in spreadsheets, emails and individual know-how.
What we clarify
Goals, user roles, actual processes, requirements, data, interfaces and open decisions.
Typical risks
the solution before the problem, the documented process instead of the one actually lived, and a scope without boundaries.
What you have at the end
a prioritized, documented scope with risks, acceptance criteria and a well-founded effort range.
What we deliberately avoid
Workshops for their own sake, requirement lists without priorities and commitments on an unclear basis.
Possible outcome
a recommendation for off-the-shelf software, a smaller scope or not pursuing the project at all.
Risk Radar

Risks we catch early.

What typically goes wrong in systems like this — and how we prevent it before it shows up in production.

  1. 01

    The solution before the problem

    Why
    A project starts with a finished solution in mind — an app, a portal, an AI feature. Requirements are then written to confirm that solution instead of describing the problem.
    Early warning signs
    Requirements name screens and tools but no goal; the question about value is answered with a list of features.
    How we prevent it
    We start with the goal and today’s process and only then assess the desired solution — against off-the-shelf software, a smaller scope and not building at all.
    Trade-off
    Cost: the original idea gets examined instead of being implemented right away. Different when: the solution has already been validated — then we focus on scope and risks.
  2. 02

    The documented process instead of the one actually lived

    Why
    Process descriptions and manuals show how work is supposed to be done. Actual work contains exceptions, workarounds and side lists that are written down nowhere — and that is exactly where the expensive requirements are.
    Early warning signs
    Answers start with “well, actually”; spreadsheets and inboxes handle steps that a system officially takes care of; only one person knows the special cases.
    How we prevent it
    We talk to the people who do the work, look at real cases and record exceptions as requirements — not as footnotes.
    Trade-off
    Cost: time from business users that is missing from day-to-day operations. Different when: the process is new and there is no established practice yet.
  3. 03

    Scope without boundaries

    Why
    Every requirement is reasonable on its own. Without priorities and boundaries, the scope grows until effort, deadline and budget no longer fit together.
    Early warning signs
    Everything is a must-have; there is no list of what will not be built; new requests are added without any existing one being dropped.
    How we prevent it
    Must-haves and nice-to-haves are separated, the initial scope is cut along one complete process, and what is out of scope is explicitly recorded.
    Trade-off
    Cost: visible trade-offs in the first phase. Different when: the scope is fixed externally — then we prioritize the order instead of the volume.
  4. 04

    Hidden dependencies

    Why
    Existing systems, data sources and responsibilities outside the project often determine pace and feasibility. Discovered late, they shift architecture, effort and schedule all at once.
    Early warning signs
    Interfaces “exist” but are not documented; data quality is unknown; nobody can say who is responsible for a connected system.
    How we prevent it
    We capture data, interfaces and owners early, test critical access with real examples and track open items as risks with a deadline.
    Trade-off
    Cost: effort for the owners of existing systems before implementation is confirmed. Different when: the project is self-contained and touches no existing systems.
Decision checklist

The questions we ask before writing code.

Not advice, but decision questions. Your answers shape the architecture — not the tools.

  1. 01

    Which problem should be solved — and how will we know it is solved?

    Why it matters
    Without a verifiable goal, you can neither prioritize the scope nor determine at the end whether the project was worth it.
    Typical consequence
    If the goal is unclear, we clarify it first. If it is clear, it becomes the yardstick every further requirement is measured against.
  2. 02

    Who uses the system — and who is affected without using it?

    Why it matters
    User roles determine interfaces and permissions. Indirectly affected parties such as accounting, data protection or operations bring requirements that otherwise surface only late.
    Typical consequence
    We involve both groups and derive roles, permissions and non-functional requirements from them.
  3. 03

    Does this need to be custom-built at all?

    Why it matters
    Custom software pays off where off-the-shelf software does not cover the process or where customizing it becomes more expensive than targeted development.
    Typical consequence
    If a standard product meets the need, we recommend it. Custom development is reserved for the part that genuinely sets the company apart.
  4. 04

    Which systems and data are involved?

    Why it matters
    Integrations and data migrations are among the most common causes of delays — and they can be spotted early if you ask about them specifically.
    Typical consequence
    We create an overview of interfaces and data and assess each integration for risk before naming any effort.
  5. 05

    What is the smallest scope that delivers real value?

    Why it matters
    An initial scope that contains everything delivers late and learns little. One that is cut too small delivers nothing anyone uses day to day.
    Typical consequence
    We cut the initial scope along one complete process and arrange the following phases accordingly.
  6. 06

    Which decisions are still open — and by when do they need to be made?

    Why it matters
    Open decisions are normal at the start. They become dangerous when nobody owns them and they get made silently during the project.
    Typical consequence
    Every open decision gets an owner and a date; the effort range names the assumption that stands in for it until then.
Definition

What it is — and what it includes.

Requirements analysis and software discovery are the structured clarification of a software project — usually a web application, portal or platform — before it is built: which problem it should solve, for whom, in which processes, with which data and systems — and which risks and open decisions it involves. Batunet turns this into a documented basis on which scope, architecture, effort and implementation can be decided with good reason.

Scope of services

  • Business goals and expected business value
  • Stakeholders, user roles and responsibilities
  • Existing processes and actual workflows
  • Functional and non-functional requirements
  • Must-have/nice-to-have split and shape of the initial scope
  • Prioritization and dependencies
  • Data, interfaces and existing systems
  • Technical risks, open decisions and acceptance criteria
  • Implementation phases, effort range and documentation
Architecture

Decisions before code is written.

Not what the technology can do, but why we use it the way we do.

  1. 01

    The problem before the solution

    Many projects start with a solution. We first clarify which problem it is meant to solve and how you can tell it has been solved. Only then can the solution be assessed — including against alternatives that require less development.

  2. 02

    Observed workflows instead of the target process

    Documented processes describe how work is supposed to be done. We look at how work is actually done — with exceptions, workarounds and the spreadsheets next to the system. That is where the requirements lie that cost the most later.

  3. 03

    A range instead of a single number

    Uncertainty is greatest at the start of a project. That is why we give a well-founded effort range together with the assumptions behind it, rather than a single number that only pretends to be precise. Every question that gets answered narrows it.

  4. 04

    Open questions stay visible

    Not everything can be clarified before a project starts. Whatever remains open is named, assigned to an owner and given a date by which it must be decided — instead of being silently assumed.

Approach

How we build. The Batunet Engineering Method.

Seven phases — from the first question to operations years later. Not a project process, but the way we think.

  1. 01

    Frame

    The actual problem, its boundaries and a measurable definition of success are established before any solution is considered.

  2. 02

    Model

    The domain is modeled and sliced into contexts — with a precise, shared language.

  3. 03

    Decide

    The load-bearing decisions come first — deliberately and documented, while change is still cheap.

  4. 04

    Prove

    A walking skeleton proves the architecture on the riskiest path — before going broad.

  5. 05

    Build

    On top of the proven skeleton, the system grows in verifiable, reversible steps — with progress visible every week.

  6. 06

    Harden

    Failure cases, load and security are tested, not assumed. “It runs” becomes “it holds.”

  7. 07

    Operate

    We operate, monitor and keep evolving the system — and keep it understandable and changeable.

Engineering

From design to operations.

The system doesn't just have to run — it has to hold up in operation. Every recommendation comes with its cost, and with the case where we decide differently.

Goals and business value

We record what the software is supposed to change: which work goes away, which error no longer happens, which decision can be made faster. Verifiable where possible; stated honestly where not.

Trade-off · Cost: time with the business owners rather than with technology. Different when: the goal is set and undisputed — then a brief confirmation is enough.

Roles and workflows

Who works with the system, who is affected, who decides? We describe user roles and the actual workflows — including the exceptions that come up regularly in day-to-day work.

Trade-off · Cost: interviews and observation with several stakeholders. Different when: a single team uses the system on its own — then a brief overview of roles is sufficient.

Requirements and boundaries

Functional requirements describe what the system does; non-functional ones describe under which conditions — load, availability, data protection, traceability. Both are prioritized and split into must-haves and nice-to-haves.

Trade-off · Cost: requests are visibly deferred. Different when: the scope is already binding — then we check it for gaps and contradictions.

Data, interfaces and existing systems

Which data is created, where does it come from, which system is the source of truth? Which systems need to be connected, and how well are their interfaces documented? This is where most hidden dependencies lie.

Trade-off · Cost: early access to existing systems and their owners. Different when: the project touches no existing data or systems.

Risks and acceptance criteria

Technical risks and open decisions are named and assessed. For every significant requirement, we record how its fulfillment can be recognized — the basis for testing and acceptance.

Trade-off · Cost: uncomfortable questions before commitments are made. Different when: the risk is demonstrably low — then the assessment stays brief.

Phases and effort range

From the prioritized scope and its dependencies, we derive rough implementation phases and an effort range along with its assumptions. It is the basis for the budget, the architecture and the decision whether to build.

Trade-off · Cost: no binding number before clarification. Different when: scope and constraints are so clear that a reliable estimate is possible right away.

Outcome

What you can rely on.

  • 01

    A documented target picture with verifiable criteria

  • 02

    A prioritized scope with a clear must-have/nice-to-have split

  • 03

    An overview of processes, roles and responsibilities

  • 04

    A requirements catalog with acceptance criteria

  • 05

    An overview of interfaces, data sources and existing systems

  • 06

    A risk and dependency analysis including open decisions

  • 07

    A basis for the choice: custom software, off-the-shelf software or not proceeding

  • 08

    Implementation phases and an effort range as the basis for architecture and implementation

Fit

When it fits — and when it doesn't.

An honest answer is part of good advice. We recommend the path that fits the problem.

Good fit

  • A project is not yet fully defined from a business perspective but needs to be budgeted, planned and decided on a solid basis.
  • Several departments, roles or locations work with the same system and bring different expectations.
  • The new software has to fit into existing systems, existing data or ongoing processes.
  • It is still open whether custom software, a standard product or a combination is the right answer.

Not a fit

  • A small, clearly defined project with known users and few dependencies. A brief clarification at the start of implementation is enough there — a separate discovery phase would be overhead.
  • Requirements, scope and constraints are already reliably documented. In that case, we check them for gaps instead of gathering them again.
  • Discovery as a mandatory ritual before every engagement. Workshops that end without a decision produce documents, not a foundation.

Tools & deliverables

Process modelsRequirements catalogsAcceptance criteriaDecision logs
Questions

Questions about Requirements Analysis & Software Discovery

  • Does every project need a discovery phase?

    No. For small, clearly defined projects, a brief clarification at the start of implementation is enough. The depth depends on uncertainty, dependencies and risk — not on a fixed format.

  • How long does a requirements analysis take?

    That depends on the size and uncertainty of the project. For a manageable project, a few conversations and a concise results document are enough; if several departments and existing systems are involved, clarification takes correspondingly longer. We agree on the framework together in advance.

  • How reliable is the effort estimate afterwards?

    More reliable than before, but not arbitrarily precise. You receive an effort range with the assumptions it is based on and the risks that could shift it. The more is clarified, the narrower it becomes.

  • What if it turns out we should not build?

    Then that is a result, not a failure. A well-founded recommendation for off-the-shelf software, a smaller scope or not pursuing the project costs less than a project built on the wrong foundation.

  • Which tools do you work with — and what do we receive?

    With whatever the clarification needs, not with a fixed toolkit: process models for the actual workflows, prioritized requirements catalogs, acceptance criteria for the key requirements and decision logs for what has been decided and what is still open. The analysis does not commit to any particular technology or implementation.

Knowledge graph

Continue your engineering journey.

Related concepts, decisions, playbooks and perspectives — as one connected path, not a list of links.

Let’s talk about your project.

No sales team. A direct conversation with the management.