Built From the Requirement Outwards.

Start with what the business needs to achieve.

The useful starting point is not a feature list. It is the problem, the people affected, the current process, the decisions being made and the outcome the organisation needs.

• Business problem
• Users and roles
• Current workflow
• Required outcome

Make the decisions and rules explicit.

Software behaviour is shaped by the rules beneath each action: what may happen, who may do it, which data is required and what follows.

• Inputs
• Rules
• Exceptions
• Outputs

Give the requirement a dependable structure.

Interfaces, logic, data, access and integrations need deliberate boundaries. The architecture is defined against the project rather than assumed in advance.

Design around the people doing the work.

Clear flows, useful defaults, visible status and appropriate permissions can reduce ambiguity without hiding important business context.

• Tasks
• Information
• Decisions
• Feedback

Understand every external dependency.

Connections are assessed against available APIs, authentication, permissions, data formats, technical constraints and supplier terms.

Check the software against the agreed requirement.

Functional testing, workflow review and user acceptance should relate back to agreed behaviours and responsibilities.

Leave room for informed iteration.

Business needs may change. Future work can be evaluated and agreed as requirements, priorities and dependencies become clear.