Development Cases and Readiness

Development cases & readiness

No two projects need the same amount of process. A two-person internal tool and a regulated medical system shouldn't be forced through the same checklist. That's what Development cases are for: they tailor the process to the project.

Development cases

A Development case is a list of lines. Each line says how much the case cares about one element:

Element	Example
A discipline	"Test" is required.
An activity definition	"Detail use cases" is recommended in Elaboration.
A work product definition	The "Vision" is required for Lifecycle Objectives.
A readiness criterion	"Requirements are approved" is recommended for Lifecycle Architecture.

Each line has a level: Required, Recommended, Optional or Disabled, and optionally the milestone it applies to.

Studio ships with two cases:

• Standard (the default): lightweight. Engineering disciplines required, the rest recommended; readiness is advisory.
• Existing System (Brownfield): for work on systems that already exist.

You'll find them, and can create your own, under Configuration → Unified Process → Development Cases.

Applying a case

When you apply a case to a Development, Studio takes a snapshot of its lines together with the case version. If someone later edits the case, your Development keeps working with its snapshot and the overview tells you:

The Development Case changed after it was applied. This Development keeps its snapshot until you re-apply the case.

Re-applying is a deliberate click, so a process change never sneaks into a running project.

Readiness

The Readiness tab answers the question every project manager asks before a milestone: are we really there?

For every criterion the case asks for, you get a status and, most importantly, what is missing, named record by record:

Status	Meaning
Met	Nothing missing.
Missing	A required criterion isn't met.
Not yet	A recommended criterion isn't met.

The criteria

Criterion	What it checks
The current phase has planned iterations	You can't run a phase without iterations.
Required disciplines have someone in their roles	Every required discipline has a person playing one of its roles.
Required work products are baselined	The required work products (Vision, Architecture…) are published.
Required activities are completed or explicitly skipped	Nothing required was silently forgotten.
Business rules are approved	No business rule left in draft.
Business use cases are reviewed	—
Requirements are approved	—
System use cases are reviewed	—
Approved requirements are refined or realized downstream	Every approved requirement is covered by a use case or a trace.
Accepted change requests have an impact analysis	Each accepted change says what it impacts.
Accepted change requests are scheduled	Each accepted change has a target iteration.
Approved requirements are verified by passing tests	From test management.
Reviewed use cases are verified by passing tests	Same, for use cases.
Change requests marked verified have passing test evidence	"Verified" should mean there's evidence.

flowchart TD
    A[Development case<br/>snapshot] --> B{For each readiness line<br/>that applies to the<br/>next milestone}
    B --> C[Evaluate the criterion]
    C --> D{Gaps?}
    D -- none --> E[✅ Met]
    D -- yes, required --> F[❌ Missing + reasons]
    D -- yes, recommended --> G[🟡 Not yet + reasons]

Loading

Readiness is advice

Readiness never blocks you. When you mark a milestone as reached with criteria still unmet, Studio asks you to confirm, and writes what was missing into the milestone's notes. That way the decision is yours, and it's auditable later. Managers like that. Auditors love it.