Software Requirements Shouldn’t Start With Software

A new platform. An automated workflow. A reporting dashboard. A mobile application.

Digital projects often begin with a solution already in mind. The conversation quickly moves to features, screens and technical requirements.

But before deciding what a system should do, there is a more important question:

What does the environment around that software actually look like?

Good software requirements come from understanding the people, workflows, systems, data and decisions the solution will need to work around.

Without that context, requirements can quickly become a detailed description of an assumed solution rather than a clear definition of what actually needs to change.

1. Understand what happens today

Start with the current process, not the future interface.

How does the work begin? Where does information move? Which steps happen inside existing systems, and which rely on spreadsheets, email or manual follow-ups?

Mapping the current process helps identify what a future system needs to improve, preserve or replace.

2. Find where the process breaks down

Not every part of a workflow needs digitising.

Look for delays, duplicate work, manual handovers, missing visibility or information that has to be entered more than once.

These friction points are more useful than an early feature list because they explain why the project exists in the first place.

Technology should respond to the problem, not define it.

3. Look beyond the end user

Operational systems rarely involve only the person using the interface.

Someone may enter information, another person reviews it, a manager approves it, and another team may depend on the resulting data.

Understanding these roles reveals the approvals, permissions, handovers and responsibilities the system needs to support.

The people who never log in may still shape the requirements.

4. Understand the systems already in place

A new digital solution rarely enters an empty environment.

Existing ERPs, CRMs, databases, spreadsheets and third-party platforms may already hold parts of the process or its data.

A new system may need to connect with them rather than replace them.

Understanding these dependencies early helps prevent requirements that look simple on paper but become far more complex in practice.

5. Trace the data and its ownership

Data should not appear in a requirements document simply as an input.

Ask where it comes from, who maintains it, who can edit it, which systems rely on it and who is responsible when something is incorrect.

The same applies to access.

Who should see what? What requires approval? What needs to remain traceable?

These questions can shape the solution long before anyone starts defining screens or database structures.

6. Map decisions, not just tasks

Workflows are rarely completely linear.

There are exceptions, rejections, escalation paths and judgement calls.

A request may follow one route normally and another when information is missing or additional approval is required.

If these decision points are ignored, the requirements may describe the standard process while missing the situations that create the most complexity.

7. Define what would make the change worthwhile

Only after the operating environment is understood should the conversation move towards what needs to improve.

Success should connect directly to the problem.

That may mean reducing approval time, removing duplicate data entry, cutting manual reporting steps or giving teams better visibility into where work is delayed.

This creates a stronger basis for software requirements because every requirement has a clear reason to exist.

Requirements Are Downstream of Context

Detailed requirements still matter.

Functional requirements, technical specifications, integrations, security considerations and acceptance criteria may all become necessary as a project progresses.

The important question is when they are defined.

A better approach is to understand the operating environment first, clarify what needs to change, develop the requirements from that context, and then shape the solution.

The first conversation with a technology partner does not need every screen, feature or architectural choice already decided.

It needs enough context to make the next decision well.

For organisations preparing for a digital initiative, that means understanding the systems, workflows, data, governance and constraints already in place before deciding what should be built next.

Need to understand the environment before defining the solution?

Centangle’s Consulting & Advisory practice helps organisations assess systems, workflows, data, governance and dependencies before moving into architecture, procurement or implementation.