Solution Delivery Lifecycles
In short How a solution is delivered (in one release or in increments, with requirements fixed up front or discovered as you go) changes what the analyst does and when. The BCS book compares the main lifecycles and gives practical criteria for choosing between them.
Based on: D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 12; IIBA, BABOK® Guide v3, section 11.3.
On this page
Key ideas#
Two questions decide the approach#
The BCS book suggests looking at context first: organizational culture, the business reason for the change, project constraints, and drivers such as a regulatory deadline or a race for competitive advantage. Then two questions narrow the choice:
- Delivery: one release, or several increments?
- Development: can the team work closely with business users, and are the requirements clear enough to define up front?
The BABOK® Guide’s Information Technology perspective draws a similar line between predictive approaches (structured, formally documented, sequential) and adaptive ones (iterative and incremental), with hybrids in between.
Waterfall#
Stages run in sequence: feasibility study, analysis, design, development, testing, implementation. Each stage builds on a signed-off previous one. The analyst is mainly involved in feasibility and analysis, then again in acceptance testing and implementation support.
- Strength: strong control at each stage, which supports quality.
- Weakness: a long cycle that leaves the business waiting, and changes are expensive because a whole chain of documents must be revised.
V-model#
A variant of waterfall, folded after development to show which test stage checks which earlier stage: user acceptance checks the requirements, system testing checks the solution design, unit testing checks the modules. The extended V-model adds business needs analysis and a business case on the left, and a benefits review on the right. In this version the analyst is involved throughout: from defining needs, through supporting design and impact assessment, to acceptance and benefits review.
Incremental delivery#
Analysis and high-level design are done once for the whole solution; then the solution is built, tested and deployed in several increments, with the most urgent requirements first. The BCS book warns of a hidden cost: total cost is higher than a single delivery, because each increment needs regression testing, and the high-level design must anticipate later increments or earlier ones will need rework.
Spiral model#
Boehm’s spiral model (1986) does not require a full set of requirements at the start. Each loop agrees a set of requirements by priority, explores technical options and risks through prototypes with business users, evaluates the prototype and builds, then deploys a release or increment. The BCS book lists reasons iterative approaches became popular: there is no time to define everything first; the business often does not know exactly what it wants, especially in new areas; early results help keep stakeholder support; and requirements age quickly when the business changes fast.
The most flexible option, according to the BCS book, combines iterative development with incremental delivery.
Unified Process and agile#
The Unified Process is iterative and incremental, configured to each organization, and provides guidance on using UML (see RUP in Brief). Agile methods such as DSDM Atern and Scrum respond to fast-changing business needs and leave room to decide how to implement each requirement. The BCS book cites an 80/20 rule: 80% of a full solution can often be delivered for 20% of the effort of complete development. Key techniques are evolutionary prototyping, timeboxing and MoSCoW prioritization. Revisiting earlier steps is normal rather than an exception that needs formal change control. The book also warns that prototypes without proper documentation and testing cause problems in operation.
Mapping MoSCoW to increments#
The BCS book links MoSCoW categories to incremental delivery:
| Category | Role in delivery |
|---|---|
| Must have | First increment or first prototype. |
| Should have | Flexibility buffer; can be covered by a temporary manual workaround if the deadline is tight. Anything not delivered becomes a Must in the next release. |
| Could have | Contingency inside the timebox; dropped first if time runs short. |
| Won’t have this time | Deliberately deferred; may become a Must when a triggering event occurs, such as a law coming into force. |
Buy vs. build#
Off-the-shelf (COTS) packages are usually cheaper, faster to deploy, supported by the vendor and kept up to date with legislation. But they never fit perfectly: you either adapt your processes or pay for customization, and a package available to competitors rarely gives competitive advantage. The BCS book advises that requirements for a package focus on what is needed, not how, and that the organization be ready to adapt its processes.
How to apply it#
- Answer the two questions (delivery and development) with the sponsor before planning analysis work.
- Match your deliverables to the lifecycle. Waterfall needs a complete, signed-off specification; agile needs a prioritized backlog with detail just in time.
- Plan your involvement after requirements. In V-model and agile approaches the analyst stays involved through testing and benefits review.
- Budget for increments. If you deliver incrementally, add regression testing and design for future increments.
- Use MoSCoW deliberately. Keep “Should” items as the buffer, not as hidden Musts.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, chooses iterative development with incremental delivery. Increment 1 (Must): online booking before the spring rush. Increment 2: repair-status notifications. Parts ordering is a candidate for an off-the-shelf stock tool, so the analyst writes its requirements as needs, not screens, and asks the owner whether workshops will adapt their ordering routine to fit a package.
Sources and further reading#
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 12 (delivering the requirements: lifecycles, MoSCoW, bespoke vs. off-the-shelf).
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 11.3 (Information Technology perspective: predictive and adaptive approaches).
- B. Boehm’s spiral model (1986), as described in the BCS book.