26 KiB
Executable File
Use Case Scoring Standard
Status: Draft Standard 0.1
File: UseCaseScoringStandard.md
Purpose: Provide a reusable scoring and classification standard for UseCaseCatalog.md files used in product discovery, software category research, prototype planning, MVP selection, enhancement planning, and architecture development.
1. Intent
A UseCaseCatalog.md should not only collect use cases. It should help teams, product owners, architects, and AI agents understand which use cases are important, which are risky, which are useful for learning, which shape architecture, and which should be selected for prototype, MVP, v1, or later development.
This standard defines a measurable, lightweight scoring model for use cases.
The standard is designed to answer five recurring questions:
- What is the use case about?
- Who benefits from it?
- How valuable is it?
- How hard or risky is it to build?
- When should it be considered for delivery?
The scoring model supports judgment. It does not replace judgment.
2. Scope
This standard applies to use case catalogs for:
- software products;
- internal platforms;
- developer tools;
- SaaS products;
- multi-tenant and multi-vendor systems;
- AI-assisted systems;
- canonical data model research;
- infrastructure and operations platforms;
- product category research.
It is especially useful when many potential use cases exist and a team needs a systematic way to orient itself.
3. Core Principles
3.1 Use cases are product evidence
A use case is not merely a feature request. It is evidence that a user, operator, developer, organization, system, or agent needs the product to behave in a certain way.
3.2 Scoring supports orientation, not automation
Scores should make comparisons easier, but they should not be treated as an automatic decision engine. A low-scoring use case may still be strategically important. A high-scoring use case may still be inappropriate for the next development stage.
3.3 Prototype, MVP, and enhancement use cases differ
A prototype use case should prove or explore something.
An MVP use case should create coherent first product value.
An enhancement use case should deepen, extend, harden, or scale an already useful product.
3.4 Learning value matters early
Early product work is not only about user value. It is also about reducing uncertainty. Therefore, Learning Value and Proof Value are first-class scoring dimensions.
3.5 Architecture-driving use cases must be visible
Some use cases are important because they shape architecture, terminology, boundaries, data models, policy models, or operational design. These use cases should be marked explicitly even if they are not built immediately.
4. Recommended Score Scale
The default score scale is 0–3.
| Score | Meaning |
|---|---|
| 0 | None, irrelevant, unknown, or not applicable |
| 1 | Low relevance or minor impact |
| 2 | Important, meaningful, or clearly useful |
| 3 | Critical, defining, or strongly differentiating |
A 0–2 scale MAY be used for simpler catalogs.
| Score | Meaning |
|---|---|
| 0 | Not relevant, not present, or unknown |
| 1 | Relevant / useful |
| 2 | Important / strong |
When using a 0–2 scale, all scoring tables MUST state that reduced scale explicitly.
5. Mandatory Use Case Fields
Every use case SHOULD include the following fields.
| Field | Description |
|---|---|
ID |
Stable use case identifier, e.g. UC-001 |
Name |
Short human-readable name |
Summary |
One or two sentence explanation |
Primary Actor |
Main actor performing the use case |
Beneficiary |
Person, group, organization, or system receiving value |
Source |
Origin of the use case |
Status |
Candidate, accepted, deferred, rejected, implemented |
Recommended Stage |
Prototype, MVP, V1, Later |
Priority Signal |
Low, Medium, High, Critical |
6. Classification Dimensions
Classification dimensions are descriptive. They are used for filtering, clustering, and navigation.
6.1 Actor Type
Who initiates or performs the use case?
Allowed values SHOULD include:
End UserAdminTenant AdminPlatform OperatorDeveloperIntegratorAuditorSupport AgentAI AgentExternal System
6.2 Beneficiary Type
Who benefits from the use case?
Allowed values SHOULD include:
Individual UserTeamTenantVendorPlatformCustomer OrganizationSupportOperationsComplianceFinanceDeveloper Community
6.3 Interaction Mode
How is the use case performed?
Allowed values SHOULD include:
UICLIAPIAutomationBackground ProcessAgent WorkflowIntegration EventManual Procedure
6.4 Scope Level
At what level does the use case apply?
Allowed values SHOULD include:
InstallationPlatformVendorTenantOrganizationDomainGroupUserAgentResourceSessionRequest
6.5 Lifecycle Phase
Where in the lifecycle does this use case appear?
Allowed values SHOULD include:
ResearchSetupOnboardingConfigurationDaily UseException HandlingIncident ResponseMonitoringAuditOptimizationMigrationRetirement
6.6 Environment
Where does the use case happen?
Allowed values SHOULD include:
Local DevelopmentTestStagingProductionCustomer-HostedSaaSHybridEdgeOffline
7. Value Scoring Dimensions
Value dimensions estimate why a use case matters.
7.1 User Value
How much value does the use case create for the direct user?
| Score | Meaning |
|---|---|
| 0 | No clear direct user value |
| 1 | Convenience or minor improvement |
| 2 | Meaningful improvement or important user need |
| 3 | Essential for the user to achieve their goal |
7.2 Business Value
How much does the use case support revenue, retention, differentiation, adoption, or cost reduction?
| Score | Meaning |
|---|---|
| 0 | No clear business relevance |
| 1 | Minor business relevance |
| 2 | Supports important business goals |
| 3 | Critical for revenue, retention, differentiation, or strategic adoption |
7.3 Operational Value
How much does the use case reduce operational work, support load, failure handling, manual intervention, or cognitive load?
| Score | Meaning |
|---|---|
| 0 | No operational benefit |
| 1 | Minor operational simplification |
| 2 | Significant reduction of manual work or support effort |
| 3 | Critical for scalable or safe operation |
7.4 Strategic Value
How strongly does the use case support the long-term product direction?
| Score | Meaning |
|---|---|
| 0 | No strategic relevance |
| 1 | Compatible with strategy but not central |
| 2 | Supports a strategic direction |
| 3 | Defines or strongly validates the strategic direction |
7.5 Learning Value
How much will implementing or prototyping this use case teach the team?
| Score | Meaning |
|---|---|
| 0 | Little or no learning expected |
| 1 | Some useful learning |
| 2 | Meaningful reduction of uncertainty |
| 3 | Critical learning about product, users, architecture, market, or feasibility |
7.6 Proof Value
How strongly does the use case prove or disprove a core product, architecture, or market hypothesis?
| Score | Meaning |
|---|---|
| 0 | Does not test an important hypothesis |
| 1 | Tests a minor assumption |
| 2 | Tests an important assumption |
| 3 | Tests a core hypothesis that the product depends on |
7.7 Frequency
How often is the use case expected to occur?
| Score | Meaning |
|---|---|
| 0 | Rare or unknown |
| 1 | Occasional |
| 2 | Regular |
| 3 | Frequent or continuous |
7.8 Urgency
How painful is it if the use case is not supported soon?
| Score | Meaning |
|---|---|
| 0 | No urgency |
| 1 | Can wait without major consequences |
| 2 | Needed soon for meaningful adoption or operation |
| 3 | Blocking, time-critical, or severe pain if missing |
8. Delivery Scoring Dimensions
Delivery dimensions estimate effort, complexity, risk, and readiness.
8.1 Implementation Effort
How much development effort is needed?
| Score | Meaning |
|---|---|
| 0 | Trivial or already available |
| 1 | Small implementation effort |
| 2 | Moderate effort |
| 3 | Large effort or major implementation project |
8.2 Complexity
How difficult is the use case conceptually and technically?
| Score | Meaning |
|---|---|
| 0 | Simple and well understood |
| 1 | Some complexity |
| 2 | Complicated; requires careful design |
| 3 | Complex; uncertain behavior, many interactions, or emergent effects |
8.3 Integration Load
How many components, repositories, systems, APIs, or organizational boundaries are touched?
| Score | Meaning |
|---|---|
| 0 | Isolated or local |
| 1 | Touches one adjacent component |
| 2 | Cross-component or cross-team integration |
| 3 | Cross-repo, cross-platform, customer, vendor, or ecosystem integration |
8.4 Data Sensitivity
How sensitive is the data handled by the use case?
| Score | Meaning |
|---|---|
| 0 | No sensitive data |
| 1 | Internal or low-sensitivity data |
| 2 | Personal, customer, tenant, commercial, or security-relevant data |
| 3 | Highly sensitive, regulated, confidential, or privileged data |
8.5 Security Risk
Could misuse, misconfiguration, or failure create a security issue?
| Score | Meaning |
|---|---|
| 0 | No meaningful security risk |
| 1 | Low risk, limited blast radius |
| 2 | Meaningful risk requiring controls |
| 3 | High risk requiring strong controls, auditability, or formal review |
8.6 Operational Risk
Could the use case break production operation, customer workflows, support processes, deployments, billing, or access?
| Score | Meaning |
|---|---|
| 0 | No relevant operational risk |
| 1 | Minor operational risk |
| 2 | Meaningful operational risk |
| 3 | Severe operational risk or production-critical behavior |
8.7 UX Risk
How likely is it that users misunderstand, misuse, or fail with this use case?
| Score | Meaning |
|---|---|
| 0 | Very clear and low risk |
| 1 | Some UX ambiguity |
| 2 | Requires careful UX design |
| 3 | High chance of misuse, confusion, or harmful action |
8.8 Reversibility
How easy is it to undo mistakes?
For this dimension, higher score means easier reversibility.
| Score | Meaning |
|---|---|
| 0 | Irreversible or very hard to undo |
| 1 | Reversible with significant manual effort |
| 2 | Reversible with normal admin or operational effort |
| 3 | Easily reversible, safe to experiment with |
8.9 Testability
How easy is it to verify that the use case works correctly?
For this dimension, higher score means easier testability.
| Score | Meaning |
|---|---|
| 0 | Hard to test or mostly subjective |
| 1 | Some manual testing possible |
| 2 | Good manual and partial automated testing possible |
| 3 | Strong automated, reproducible, and observable testing possible |
9. Architecture Scoring Dimensions
Architecture dimensions identify use cases that shape the system.
9.1 Architecture Pressure
How much architectural impact does the use case create?
| Score | Meaning |
|---|---|
| 0 | No notable architecture impact |
| 1 | Local design impact |
| 2 | Cross-component architecture impact |
| 3 | Cross-repo, platform-wide, or ecosystem-level architecture impact |
Recommended label values:
NoneLocalCross-componentCross-repoPlatform-wide
9.2 Canon Impact
How much does the use case affect terminology, canonical data models, or shared standards?
| Score | Meaning |
|---|---|
| 0 | No canon impact |
| 1 | Uses existing terminology or models |
| 2 | Extends existing terminology or models |
| 3 | Challenges or reshapes the canon |
Recommended label values:
NoneUses canonExtends canonChallenges canon
9.3 Policy Impact
How strongly does the use case require rules, permissions, governance, compliance, or auditability?
| Score | Meaning |
|---|---|
| 0 | No relevant policy impact |
| 1 | Minor policy relevance |
| 2 | Requires explicit policy design |
| 3 | Requires strong governance, auditability, or compliance handling |
9.4 Reuse Potential
How likely is the use case to generalize into reusable functionality?
| Score | Meaning |
|---|---|
| 0 | Very specific, little reuse expected |
| 1 | Some reuse in similar contexts |
| 2 | Reusable across several components or products |
| 3 | Strong platform, library, or canon candidate |
9.5 Compute Impact
How much does the use case affect compute, storage, bandwidth, runtime cost, or efficiency?
| Score | Meaning |
|---|---|
| 0 | No meaningful compute impact |
| 1 | Minor compute impact |
| 2 | Meaningful cost, scaling, or efficiency relevance |
| 3 | Critical for runtime economics, scalability, or resource control |
9.6 Observability Need
How important is logging, tracing, measuring, explaining, or auditing this use case?
| Score | Meaning |
|---|---|
| 0 | Little or no observability needed |
| 1 | Basic logs or events sufficient |
| 2 | Requires structured observability |
| 3 | Requires strong traceability, audit trails, explainability, or evidence records |
10. Derived Signals
Derived signals summarize scoring into actionable planning guidance.
10.1 Value Score
Suggested formula:
Value Score = User Value
+ Business Value
+ Operational Value
+ Strategic Value
+ Learning Value
+ Proof Value
+ Frequency
+ Urgency
Maximum on the default scale: 24.
10.2 Delivery Cost Score
Suggested formula:
Delivery Cost Score = Implementation Effort
+ Complexity
+ Integration Load
+ Data Sensitivity
+ Security Risk
+ Operational Risk
+ UX Risk
Maximum on the default scale: 21.
Reversibility and Testability are not included directly because higher scores are positive, while most delivery dimensions are cost or risk dimensions. They SHOULD be used as modifiers.
10.3 Architecture Score
Suggested formula:
Architecture Score = Architecture Pressure
+ Canon Impact
+ Policy Impact
+ Reuse Potential
+ Compute Impact
+ Observability Need
Maximum on the default scale: 18.
10.4 Prototype Fit
A use case is a good prototype candidate when it has:
- high
Learning Value; - high
Proof Value; - low to moderate
Implementation Effort; - low to moderate
Integration Load; - high
Reversibility; - good
Testability.
Suggested heuristic:
Prototype Fit = Learning Value
+ Proof Value
+ Reversibility
+ Testability
- Implementation Effort
- Integration Load
- Operational Risk
Interpretation:
| Prototype Fit | Meaning |
|---|---|
| 5 or higher | Strong prototype candidate |
| 2 to 4 | Possible prototype candidate |
| 1 or lower | Weak prototype candidate |
10.5 MVP Fit
A use case is a good MVP candidate when it is needed for coherent first product value.
Suggested heuristic:
MVP Fit = User Value
+ Business Value
+ Operational Value
+ Proof Value
+ Urgency
- Implementation Effort
- Integration Load
- Security Risk
Interpretation:
| MVP Fit | Meaning |
|---|---|
| 6 or higher | Strong MVP candidate |
| 3 to 5 | Possible MVP candidate |
| 2 or lower | Usually not MVP unless strategically required |
10.6 Enhancement Fit
A use case is a good enhancement candidate when it has clear value but is not necessary for the first coherent product version.
Good enhancement candidates often have:
- medium to high value;
- medium to high complexity;
- dependencies on core functionality;
- lower urgency than MVP use cases;
- strong usability, scale, governance, or integration value.
10.7 Architecture Driver Signal
A use case SHOULD be marked as architecture-driving if one or more are true:
Architecture Pressure >= 2;Canon Impact >= 2;Policy Impact >= 2;Reuse Potential >= 3;Observability Need >= 3;- the use case changes component boundaries;
- the use case introduces a cross-repo concern;
- the use case defines a shared concept other systems must use.
Architecture-driving use cases do not necessarily need to be built early. They do need to be understood early.
11. Priority Signal
The Priority Signal field provides a human-readable summary.
Allowed values:
LowMediumHighCritical
Suggested interpretation:
| Priority Signal | Meaning |
|---|---|
| Low | Useful to record, but not currently important |
| Medium | Worth considering during normal planning |
| High | Strong candidate for near-term planning |
| Critical | Blocking, strategically defining, or required for product viability |
Priority Signal SHOULD be set by judgment using the scores as input.
12. Recommended Stage
Allowed values:
PrototypeMVPV1EnhancementLaterResearch OnlyRejected
12.1 Prototype
Use this stage when the use case is primarily valuable for learning, validation, exploration, or de-risking.
Typical pattern:
- high learning value;
- high proof value;
- low or manageable risk;
- reversible;
- testable;
- implementation does not require full production infrastructure.
12.2 MVP
Use this stage when the use case is required for the first coherent product experience.
Typical pattern:
- high user value;
- high business or operational value;
- important proof value;
- necessary to make the product usable;
- acceptable implementation and risk profile.
12.3 V1
Use this stage when the use case is important for a complete first production-grade version but not strictly necessary for MVP validation.
Typical pattern:
- strong value;
- production hardening relevance;
- governance, audit, scale, or integration maturity;
- may require more complete architecture.
12.4 Enhancement
Use this stage when the use case extends or improves an already useful product.
Typical pattern:
- clear value;
- not needed for first adoption;
- may depend on later user feedback;
- may optimize experience, efficiency, governance, or ecosystem integration.
12.5 Later
Use this stage when the use case is plausible but currently too uncertain, too expensive, too risky, or not sufficiently valuable.
12.6 Research Only
Use this stage when the use case is useful for understanding the domain but should not currently be implemented.
12.7 Rejected
Use this stage when the use case is explicitly out of scope, harmful, obsolete, or inconsistent with the product intent.
13. Standard Use Case Entry Template
## UC-000 — Use Case Name
### Summary
Short description of the use case.
### Source
- Source Type: Research / Customer Request / Internal Need / Regulatory / Architecture Hypothesis / Competitor Analysis / Support Observation
- Source Note: ...
### Actors
| Role | Description |
|---|---|
| Primary Actor | ... |
| Beneficiary | ... |
| Supporting Actor | ... |
### Scenario
1. Actor starts from a specific situation.
2. Actor performs an action.
3. System responds.
4. Actor receives value or the system reaches a useful state.
### Classification
| Dimension | Value |
|---|---|
| Actor Type | ... |
| Beneficiary Type | ... |
| Interaction Mode | ... |
| Scope Level | ... |
| Lifecycle Phase | ... |
| Environment | ... |
### Value Scoring
| Dimension | Score | Notes |
|---|---:|---|
| User Value | | |
| Business Value | | |
| Operational Value | | |
| Strategic Value | | |
| Learning Value | | |
| Proof Value | | |
| Frequency | | |
| Urgency | | |
### Delivery Scoring
| Dimension | Score | Notes |
|---|---:|---|
| Implementation Effort | | |
| Complexity | | |
| Integration Load | | |
| Data Sensitivity | | |
| Security Risk | | |
| Operational Risk | | |
| UX Risk | | |
| Reversibility | | |
| Testability | | |
### Architecture Scoring
| Dimension | Score | Notes |
|---|---:|---|
| Architecture Pressure | | |
| Canon Impact | | |
| Policy Impact | | |
| Reuse Potential | | |
| Compute Impact | | |
| Observability Need | | |
### Derived Signals
| Signal | Value |
|---|---:|
| Value Score | |
| Delivery Cost Score | |
| Architecture Score | |
| Prototype Fit | |
| MVP Fit | |
### Recommendation
| Field | Value |
|---|---|
| Priority Signal | Low / Medium / High / Critical |
| Recommended Stage | Prototype / MVP / V1 / Enhancement / Later / Research Only / Rejected |
| Architecture Driver | Yes / No |
| Selection Reason | ... |
| Dependencies | ... |
| Open Questions | ... |
14. Catalog Summary Table Template
Every UseCaseCatalog.md SHOULD include a summary table near the top.
| ID | Use Case | Actor | Scope | Value | Cost | Risk | Proof | Architecture | Stage | Priority |
|---|---|---|---|---:|---:|---:|---:|---:|---|---|
| UC-001 | Example use case | Admin | Tenant | 18 | 7 | 4 | 3 | 8 | MVP | High |
Recommended columns:
| Column | Description |
|---|---|
ID |
Stable use case ID |
Use Case |
Short name |
Actor |
Primary actor |
Scope |
Scope level |
Value |
Derived value score |
Cost |
Delivery cost score |
Risk |
Combined risk indication or highest relevant risk |
Proof |
Proof Value score |
Architecture |
Architecture score |
Stage |
Recommended stage |
Priority |
Priority signal |
15. Selection Views
A UseCaseCatalog.md SHOULD contain curated views after the full catalog.
15.1 Prototype Candidates
List use cases with high learning or proof value and low implementation risk.
## Prototype Candidates
| ID | Use Case | Reason |
|---|---|---|
| UC-001 | ... | High proof value, low integration load |
15.2 MVP Candidates
List use cases required for coherent first product value.
## MVP Candidates
| ID | Use Case | Reason |
|---|---|---|
| UC-002 | ... | Core user workflow, high operational value |
15.3 V1 Candidates
List use cases required for a strong first production-grade version.
15.4 Enhancement Candidates
List valuable but non-essential later improvements.
15.5 Architecture-Driving Use Cases
List use cases that shape architecture, canon, policy, observability, or reuse.
## Architecture-Driving Use Cases
| ID | Use Case | Architecture Driver |
|---|---|---|
| UC-010 | ... | Cross-repo policy resolution |
15.6 Research-Only Use Cases
List use cases that are useful for understanding the category but should not currently be built.
16. Recommended Workflow
Step 1: Capture broadly
Collect use cases without scoring too early. Include research, customer needs, competitor behavior, internal operations, developer experience, governance, edge cases, and failure cases.
Step 2: Normalize
Merge duplicates, split overloaded use cases, and align terminology.
Step 3: Classify
Assign actor, beneficiary, interaction mode, scope, lifecycle phase, and environment.
Step 4: Score
Score value, delivery, and architecture dimensions. Use short notes to explain non-obvious scores.
Step 5: Identify drivers
Mark use cases with high proof value, high learning value, high architecture pressure, or strong canon impact.
Step 6: Build selection views
Create prototype, MVP, V1, enhancement, architecture-driving, and research-only views.
Step 7: Review with judgment
Review the score-driven result and adjust recommendations where strategy, timing, or external constraints require it.
17. Guidance for AI Agents
When an AI agent creates or updates a UseCaseCatalog.md, it SHOULD:
- preserve stable use case IDs;
- avoid silently changing scores without explanation;
- include short notes for unusual scores;
- distinguish direct user value from learning and proof value;
- mark architecture-driving use cases explicitly;
- avoid treating formulas as final decisions;
- propose selection views when enough use cases are present;
- call out uncertainty instead of inventing precision;
- recommend splitting use cases that contain multiple actors, scopes, or outcomes;
- maintain consistency with project terminology and applicable canonical standards.
18. Minimal Lightweight Variant
For small projects, the following compact scoring fields MAY be sufficient.
| Dimension | Score | Notes |
|---|---:|---|
| User Value | | |
| Business / Operational Value | | |
| Learning / Proof Value | | |
| Effort | | |
| Risk | | |
| Architecture Impact | | |
| Reuse Potential | | |
And the recommendation block:
**Priority Signal:** Low / Medium / High / Critical
**Recommended Stage:** Prototype / MVP / V1 / Enhancement / Later
**Reason:** ...
The full standard SHOULD be used when catalogs contain many use cases or when the product has significant architectural, operational, security, or multi-tenant complexity.
19. Standard Compliance Levels
Basic Compliance
A catalog is basically compliant if every use case contains:
- ID;
- name;
- summary;
- actor;
- beneficiary;
- value score;
- effort score;
- risk score;
- recommended stage.
Standard Compliance
A catalog is standard-compliant if every use case contains:
- mandatory identity fields;
- classification dimensions;
- value scoring;
- delivery scoring;
- architecture scoring;
- derived recommendation.
Advanced Compliance
A catalog is advanced-compliant if it also contains:
- derived score formulas;
- prototype/MVP/enhancement views;
- architecture-driving use case view;
- explicit uncertainty notes;
- traceable source references;
- change history for score revisions.
20. Change History
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-06-14 | Initial draft standard |