The five SDLC phases used in this guide are planning, analysis, design, implementation, and use and maintenance. Implementation includes building, testing, and deploying. Other frameworks split those activities into additional phases; the count is less important than clear ownership and evidence at each decision.
For founders and operators, the software development life cycle is a way to expose missing decisions before they become release problems. A lightweight MVP and a complex enterprise system need different amounts of documentation, but both need scope, design, quality checks, and an operating owner.
Use the software building process for a closer view of the evidence passed between delivery steps. The five-phase map below groups that work for planning.
One delivery map
| Phase | Main output | Accountable decision | Gate before proceeding |
|---|---|---|---|
| Planning | Goal, alternatives, budget assumptions, exclusions | Sponsor approves the next investment | Problem and intended outcome are clear enough to investigate |
| Analysis | Workflow, requirements, risks, acceptance criteria | Product owner agrees what the release must do | Important users, exceptions, data, and constraints are represented |
| Design | Prototype, architecture, data and permission model | Design and technical leads recommend a build path | Critical usability and feasibility assumptions have evidence |
| Implementation | Reviewed code, tests, deployment and recovery plan | Release owner accepts the tested scope | Required checks pass and unresolved risks have a decision |
| Use and maintenance | Monitoring, support, patches, feedback, improvement backlog | Product and operational owners prioritize follow-up | The system remains supportable or is deliberately retired |
These roles can be held by fewer people in a small team. Make that explicit so a responsibility does not disappear between phases.
Phase 1: Planning
Begin with the problem and alternatives, including doing nothing, improving the process, configuring an existing tool, or building software. Define the business outcome, constraints, budget range, decision-maker, and what the first release excludes.
Consider a hypothetical internal purchase-request tool. Requests currently move through email, so staff cannot see who needs to act. The proposed goal is to make request status and approval ownership visible. Version one excludes supplier payments and automatic purchasing.
The planning gate is a decision to investigate that bounded problem. It is not a commitment to every feature in the sponsor’s initial idea. Record uncertain benefits and collect a baseline before claiming savings.
Phase 2: Analysis
Map the current workflow with requesters, approvers, finance, and support. Inspect ordinary cases and exceptions: rejected requests, missing information, absent approvers, cancellations, and duplicate submissions.
For the example, record required fields, approval rules, access boundaries, notifications, audit events, and retention needs. A testable requirement might be: “A requester can view their own request status but cannot approve it or view another department’s restricted request.”
Put acceptance criteria beside requirements, with examples and an owner for unresolved questions. A software requirements specification can be short if the problem is small. Its value is shared understanding and traceability, not page count.
The analysis gate checks whether the team can explain the workflow and estimate the major uncertainties. An unknown identity integration may require a proof of concept before design is finalized.
Phase 3: Design
Design covers the user experience and the technical system. Explore screens and states, data relationships, server-side permissions, integration behavior, errors, deployment, and recovery. Compare alternatives and record why one fits the constraints.
In the purchase-request example, a prototype can test whether employees understand “needs information” versus “rejected.” The technical design specifies who can move a request between states and how duplicate notification delivery is handled.
Do not use a polished prototype as proof that the integration works. Test the hardest technical assumption separately. The design gate requires evidence appropriate to the risk: usability findings, an integration spike, reviewed data handling, or an agreed security model.
Phase 4: Implementation, testing, and deployment
Build in small slices that exercise a complete path. For example, first create and view a request, then add approval, then notifications and exception handling. Review code and tests against the agreed behavior as work proceeds.
Testing should cover normal paths, rejected input, forbidden actions, duplicate requests, integration failures, accessibility, and relevant load. The exact mix depends on the system; more tests do not automatically mean better risk coverage. Connect checks to the failures that would matter to users.
Use development and staging environments with controlled data and access. Before release, verify the build, configuration, database changes, smoke tests, support route, and recovery procedure. A code rollback may not reverse a database migration or external side effect, so rehearse the appropriate recovery path.
For the example pilot, the release owner checks that a requester cannot self-approve, an absent approver has a defined escalation path, and failed notifications are visible. Launch to a bounded group only when those conditions and the agreed baseline controls pass.
Phase 5: Use and maintenance
Operational software needs ongoing ownership. Maintenance includes dependency and security updates, monitoring, backup and restore checks, access reviews, defect triage, vendor changes, and support. It is not an optional extra while people rely on the system.
Measure whether the example tool helps requests move: completion time, overdue approvals, duplicate requests, errors, and support effort. A reduction in clicks alone does not establish a business improvement.
Feed findings into the next planning cycle. If employees return to email, investigate the missing workflow or confusing state before adding another dashboard. If the tool is no longer justified, plan data retention, export, access revocation, and retirement.
Security and quality span every phase
NIST’s Secure Software Development Framework, version 1.1 provides a reference for integrating secure development practices into a life cycle. Security is not a final scanner run or a promise implied by using SDLC.
During planning, identify sensitive data and consequences of misuse. During analysis and design, define permissions and likely abuse cases. During implementation, review dependencies, code, configuration, and negative tests. During operation, patch, monitor, and respond to incidents with a named owner.
Similarly, quality assurance begins when requirements and acceptance criteria are defined. It continues through review, testing, and production feedback.
What happens when a requirement changes during implementation?
Return to the affected decisions before releasing the changed behavior. A change discovered during implementation may reopen analysis, design, and the release plan. It does not require repeating every completed activity. NASA’s requirements-management guidance calls for impact assessment before approval and consistency between requirements, design, and verification. Adapt that principle to the risk of the project; a small internal tool does not need NASA’s full mission process.
Continue the hypothetical purchase-request example. During pilot preparation, the team learns that requests can wait while an approver is absent. The proposed change lets a named substitute approve during an agreed absence. This is an invented scenario, not a reported client result. The original ban on self-approval must still apply.
| Affected phase | Decision and owner | Evidence needed to proceed |
|---|---|---|
| Planning | The sponsor decides whether delegated approval is required for the pilot, can wait, or needs a revised release scope | A recorded choice with the effect on effort, dependencies, and pilot timing |
| Analysis | The product owner agrees who can nominate a substitute, when authority starts and ends, and which requests it covers | Reviewed ordinary and exception cases, including a requester who is also the proposed substitute |
| Design | The technical lead defines permission checks, expiry, and the approval audit record | A reviewed permission model that identifies both the acting person and the delegated authority |
| Implementation | The release owner accepts the changed scope after engineering and QA review the results | Passing checks for valid delegation, expired or revoked authority, self-approval rejection, and the unchanged ordinary approval path |
| Use and maintenance | The operational owner accepts responsibility for ending delegation and investigating disputed actions | An agreed access-review procedure, support route, and a usable record of who approved each request |
These are proposed checks, not test results. Record the actual results and the release version before marking the change accepted. If the team cannot define who may delegate or cannot enforce the original approval restriction, keep delegated approval out of the pilot. Use a separately approved manual escalation route only if the business owner accepts its controls. Otherwise, revise the pilot date or scope.
A new permission rule can invalidate earlier approval tests even when the screens barely change. Keep the previous decision record, identify the checks that must run again, and tell support what changed before release.
Choose among SDLC models based on uncertainty, delivery constraints, and risk. The useful result is a repeatable path from problem to tested software to responsible operation, with enough evidence to decide what happens next.
Carry these deliverables and review gates into an MVP development engagement so the first release includes a responsible operating handoff. Hapy sells product development services and has a commercial interest in that work.
