Combining Statuses and API in System Analysis

Synthesizing System Analysis Artifacts: Statuses, Use Cases, and APIs in a Unified Model

In system analysis, user stories (US) serve as the foundational requirements. From them, teams derive status models, APIs, and use cases. The traditional approach produces fragmented artifacts: business stakeholders focus on scenarios, developers on endpoints, and QA engineers on test cases. Our proposed approach unifies them into a single status-driven model with explicit API mapping—delivering one coherent view of the process across all roles.

Let’s examine a synthetic example: a cloud infrastructure rental system. A customer estimates cost, submits a request, undergoes risk scoring, pays, and receives resources.

Key User Stories

Stakeholders provide the following user stories:

| # | Title | Description |

|---|-------|-------------|

| US-1 | Estimate Infrastructure Cost | As a prospective customer, I want to estimate the cost of cloud infrastructure for my specific workload so I can assess whether this provider fits my budget and technical needs. |

| US-2 | Submit Request Based on Estimate | As a registered and verified customer, I want to submit an infrastructure deployment request using a previously generated cost estimate—so I don’t re-enter parameters and can move quickly to payment. |

| US-3 | Automated Scoring and Approval Workflow | As the billing system, I want to automatically assess risk for new requests and determine whether manual approval is required—so reliable customers are processed faster and payment default risk is minimized. |

| US-4 | Invoice Generation and Payment | As a customer with an approved request, I want to receive an invoice and pay it via my preferred method—so I can activate the ordered infrastructure and begin using it immediately. |

| US-5 | Automatic Infrastructure Provisioning | As the cloud infrastructure provider system, I want to automatically deploy resources upon confirmed payment—so the customer gains access instantly, without delays or manual intervention. |

These stories define actors and goals—and form the basis for the status model.

Process Status Model

Based on the user stories, we identify the following request lifecycle statuses:

• QUOTE_CREATED — Estimate saved; commercial quote generated.
• ORDER_SUBMITTED — Request submitted; awaiting automated scoring.
• UNDER_REVIEW — Request flagged for manual review by a sales manager.
• APPROVED — Request approved (automatically or manually).
• REJECTED — Request declined (with reason specified).
• INVOICE_ISSUED — Invoice generated and sent to the customer.
• PAID — Payment successfully received.
• EXPIRED — Invoice unpaid past its due date; request canceled.
• PROVISIONING — Infrastructure deployment in progress.
• ACTIVE — Infrastructure is live and access credentials have been issued.
• FAILED — Deployment failed; support ticket auto-created.

These statuses form the structural skeleton of the artifact—grouping related scenarios logically.

Use Cases and Their Expansion

Use cases encapsulate functional capabilities of the billing system. Their expansion integrates them directly with status transitions and API endpoints. The artifact structure includes:

• Business logic: Scenario steps mapped to status changes.
• System state: The status model as the central state framework.
• Technical implementation: Endpoint bindings for each use case.

Example mapping: Transition from ORDER_SUBMITTED to APPROVED triggers POST /score-order, followed by PUT /approve-order.

Benefits of the Unified Artifact

This artifact bridges the abstraction gap across disciplines:

• For business stakeholders: Visual scenario flow via statuses—ideal for walkthroughs and demo sessions.
• For developers: Clear API context within the full lifecycle, with direct links between use cases, status transitions, and interface specifications.
• For QA engineers: Ready-made test case foundation—covering status transitions, endpoint behavior, and alternative flows.
• For project managers: A living implementation checklist—tracking completed APIs and resolved statuses.

Key Considerations

• A unified status/use-case/API artifact aligns cross-functional understanding—no additional tools or translation layers needed.
• The status model acts as the backbone, coherently grouping business workflows and technical endpoints.
• This artifact accelerates test design, development, and UAT—reducing documentation fragmentation and rework.
• It’s especially valuable in projects with complex business logic—not replacing existing artifacts, but connecting them.
• Real-world adoption confirms its effectiveness during stakeholder and team alignment sessions.

Practical Implementation

Build the artifact as a structured table or flow diagram in tools like Draw.io, Confluence, or Markdown. Start with user stories, add statuses, then map use cases and corresponding API endpoints. In one real project, the team used it to align stakeholders: they opened the document, walked through the status chain together, and marked off implemented components. Subjectively, this reduced misalignment by 30–40% across the delivery team.

— Editorial Team