Use-Case Evolution Guide

Modern product development demands more and more sophisticated designs. This in turn leads to the increased complexity of both demand and implementation. Business is flooding the architecture and development teams with the new and changed requirements. Development teams are struggling to understand what the business demand is and find the best product increment strategy. One of the widely adopted conversational methods is the Use-Cases. This guide is intended to shed light on the process of the requirements development and maturing.

Meet Use-Case

Definition

Description of the behavioral requirements of a system and its interaction with a user. (ISO/IEC/IEEE 2011)

The definition is clear and straightforward. Nevertheless, Use-Cases are used to describe everything: the interactions, the requirements, the system designs and so on.

Before moving forward it’s worth revising the Use-Cases you are working on and put the ones telling about the interactions apart from others.

Use-Case Template

The following template was developed to give a way to elaborate Use-Case step by step improving its quality and maturity. The same time it provides the collaboration grounds to enable teamwork.

Title (Mandatory): <title> Actor (Maturity A, mandatory): <human or entity-alike participants> Goal (Maturity A, mandatory): <goal definition> Context (Maturity A, optional): <execution environment> Scope (Maturity A, optional): <design boundaries> Preconditions (Maturity B, mandatory): <boolean expression> Triggers (Maturity B, mandatory): <boolean expression> Main Scenario (Maturity C, mandatory): <list of actions> Post-conditions (Maturity B, optional): <boolean expression> Alternative Scenarios (Maturity C, optional): <list of action lists> Exceptions (Maturity C, optional): <list of exception lists> Requirements (Maturity B, optional): <list ofrequirements>

Meet Maturity Levels

Maturity Levels is a novelty introduced to formalise the Use-Case development iterations and help designers to align on the levels of the details.

Each maturity level identifies the mandatory properties necessary to provide solid understanding of a Use-Case design goal and sufficient to develop underlying architectures. The optional properties give the insights on the intended design decisions to be made during the Use-Case decomposition.

Each maturity level can be considered as a terminal one and they are structured as follows:

Maturity A
- Design Team frames a design
- Development Teams are free to choose the solution for a problem statement
Maturity B
- Design Team constrains a design by adding details on the anticipated start and end events and conditions
- Development Teams follow the restrictions in the implementation
Maturity C
- Design Team specifies exact solution
- Development Teams assess and implement the solution

Disclaimer: The proposed maturity levels do not necessarily mean a waterfall process of development. Instead they allow you to choose the right level of the details for every product demand.

Maturity A

Maturity A is focused on the very basic properties of a Use-Case. These properties tell the whole story and are sufficient to start doing the engineering design.

The best candidate for this maturity is a common and well-known interaction. As an example it might be a credit card payment using a terminal.

Title (must)

Title tells the whole Use-Case story. It’s best to be written as Verb + Noun + Supplement, as long as it defines the whole Use-Case reason to exist.

Usually Title answers the “WHY” question.

Examples:

Safely wake up person at specified time
Prevent road wheels blocking during braking.

Actor (mandatory)

Actor is the human or organisational entity participating in the Use-Case interactions as a whole. Actors are not decomposed and operate externally to the system-of-interest.

Try to think about the actors as the roles which might be substituted by different entities.

Usually Actor answers the “WHO” question.

Goal (mandatory)

Goal is a short summative purpose of the Use-Case under design. It must be simple and straightforward. There might be a series of Use-Cases targeting the same goal. This is acceptable, Use-Case identifies the one and only interaction between the actor and particular system while the goal might be achieved in multiple ways.

Usually Goal answers the “WHAT” question.

Examples:

Wake up person.
Stop a vehicle safely on a slippery road.

Scope (optional)

Scope frames the design and greatly helps engineering teams to implement only the anticipated behaviour. It helps to keep the Use-Case and the derived designs on track by the complexity control.

Scope identifies the design boundaries: what are the components involved in the interaction, what the time restrictions are, if any, etc. In later stages statements from scope are developed into the requirements and scenarios, but the scope itself is not a requirement and must not be treated as such.

Examples:

Control a deep sleep phase and trigger an alarm when both are true: the timer goes off and the deep sleep phase is over.
Braking system controls the wheels rotation and intervenes when one or more wheels are blocked by reduction of braking force on the corresponding wheels. The driver must be notified each time when the braking system intervenes into the process of braking.

Context (optional)

Context gives the insights on reasoning behind the Use-Case decomposition. It shows the analyst concerns as well as the considered environment and actor states. Context rarely tells about the system-of-interest state because mainly it is covered by Scope as explicit design constraint.

Examples:

Based on the recent studies, users waking up in a non-deep sleep phase are likely more satisfied with their sleep quality. The smart sleep feature is designed to let the user choose between the regular and smart alarm clock.
On a slippery road (icy or wet) vehicle is highly likely to start uncontrollable movement when braking pressure demand makes wheels blocked. In this case the braking system must intervene to unlock the wheels. As long as this might increase the braking distance, the driver needs to be notified. It’s preferred to have a non-visual notification because in such conditions drivers attention is on the road.

Maturity B

Maturity B gives the first insights on what incoming and outgoing states of the system-of-interest and/or actors were considered and what triggers the interaction.

Although the Scope and Context are optional for Maturity A, it’s best to have them completed and agreed before moving to Maturity B.

Use-Cases of this maturity give more insights on what is expected from system-of-interest and the environment to enter into the interaction.

The best candidate here is a story about how to start driving a car. The Use-Case might add non-obvious states like fastened seat belts and triggers like pressing a start/stop button.

Maturity B frames design decisions even tighter thus it is vital having Scope thoroughly thought and agreed between the teams.

Pre-conditions (mandatory)

Preconditions are focused only on the measurable states, on the facts which might be checked using instrumentation. They are clear, concise and concrete.They should not tell about the events, intents, desires, flows or anything else which could not be easily reproduced.

At best they form a boolean statement.

Examples:

Person is sleeping AND the alarm clock is set.
Vehicle is moving.

Triggers (mandatory)

Triggers are the events. They tell what needs to happen to run a scenario. Unlike the preconditions triggers does not tell about the states, they depict the very specific points at the state transitions.

Triggers are measurable and concrete.They are instant, unless they have a synchronisation phase. Although it might take time to synchronise these events and usually the synchronisation tolerance is covered by the requirements.

At best they form a boolean statement.

Examples:

The alarm clock went off.
Driver presses the braking pedal AND at least one wheel rotation speed is around 0 rpm.

Post-conditions (optional)

Post-conditions depict the target states of the actors and functions of the system-of-interest or mentioned in the preconditions. Sometimes the pre- and post-conditions might be the same, but this is a rare case and needs very careful consideration. Please note that the post-conditions are optional and this is a normal situation for the never ending processes.

At best they form a boolean statement.

Examples:

Smartwatch plays wake up alarm pattern.
Road wheels are rotating at least 10 rpm AND Driver feels vibration feedback on the braking pedal.

Requirements (optional)

Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability. (ISO/IEC 2007)

* includes product, service, or enterprise.

Requirement definition is given above. This section helps to enrich the Use-Case with the requirements, adding more clarity to the scenario.

There are hundreds of books related to the requirements development. Some of them consider Use-Case as a specialised form of the requirements, but within the Use-Case they target the non-functional characteristics and/or constraints.

Please note that when you write the functional or behavioural requirements, it usually means that it’s time for the Maturity C.

Examples:

Person Wake Up
1. The smart watch shall allow to change Smart Wake-Up settings for each alarm clock
2. The smart watch shall allow to change Smart Wake-Up settings for each day on recurring alarms
The Anti-Lock Braking
1. The brake pedal feedback force shall have a configuration parameter to choose High/Low in the vehicle configuration
2. The High and Low feedback levels are to be calibrated via D-Tool

Maturity C

Maturity C enforces the development teams to follow the design and identify the gaps only. This form of the Use-Case is the most expensive to write and analyse.

You have to note that doing this right from the beginning often leads to over-engineering. Over-engineered Use-Cases tend to shift focus from interactions between the system-of-interest and actor toward a system structure and particular components behaviour. This in turn increases the review time, adds iterations, but zeroes value because of the endless Use-Case rework.

Maturity C Use-Cases are the best when business develops a novelty. Something that was never seen before. Something that is unique for a product.

The best candidate here is a child birth registration. The Use-Case has many Actors, lots of interactions and alternative branches. The process itself is common but is not obvious at all.

Starting from Maturity A and adding details you likely end up with Maturity C when all scenarios and regulations are considered and agreed upon.

Main Scenario (mandatory)

Main Scenario or Success Story is something that leads actors from the triggers to the post-conditions in the most fast and straightforward manner. It should not include branches, faults, or something that distracts the reader from understanding what exactly needs to be done to complete the scenario. It’s vital to bring the Main Scenario to the review teams solo to ensure that the idea behind is viable.

Usually the Main Scenario is written as a numbered list of actions.

The most common scenario item patterns are the following

The actor provides information
The actor receives information
The actor makes a choice
The system provides information
The system asks for information
The system does some work

Any statement in the scenario must be a short affirmation. If something needs to be negated, reserve a place in the Requirements.

Examples:

Person Wake Up
1. The smart watch checks the Smart Wake-Up feature state
2. The Smart Wake-Up feature is turned on by user
3. The smart watch checks the deep sleep phase
4. The smart watch detects the deep sleep phase is over
5. The smart watch starts alarm clock
The Anti-Lock Braking
1. The braking system checks locked wheels
2. The braking system calculates the braking force reduction for each locked wheel
3. The braking system changes the braking force for each locked wheel
4. The braking system actuates braking pedal feedback
5. The braking pedal vibrates to indicate the anti-lock function is active

Alternative Scenarios (optional)

Alternative Scenarios are the scenario branches that lead to the same post-conditions as the Main Scenario does. They alter Main Scenario or other Alternative Scenarios by adding the deviations based on the scenario steps.

Usually the Alternative Scenarios are written as a lettered list to distinguish its points from the Main Scenario. The other design considerations are the same as for the Main Scenario.

Even though they are optional, they would be created during the review process. Rare Use-Case has the one and only way to succeed.

Examples:

Person Wake Up
1. The Smart Wake-Up Feature is disabled
  1. Main Scenario 1.2. The Smart Wake-Up is turned off by user
  2. Skip Main Scenario 1.3-1.4
2. Faulty Deep Sleep Sensor
  1. Main Scenario 1.2. The Deep Sleep Sensor reports failure
  2. Main Scenario 1.2.1 Report sensor failure to user
  3. Skip Main Scenario 1.3-1.4
3. The user is in the deep sleep phase
  1. Main Scenario 1.4. The smart watch detects the user is in the deep sleep
  2. Main Scenario 1.4.1. Wait 100ms
  3. Main Scenario 1.4.2. Start from Main Scenario 1.4
The Anti-Lock Braking
1. The wheels are not locked
  1. Main Scenario 2.1. Detects wheels no wheel is locked
  2. Main Scenario 2.1.1. Stop execution

Exceptions (optional)

Exceptions by their nature are the branches which violate the Post-Conditions. There should be no other place where Use-Case has a non-successful ending. Even the Requirements listing the constraints and restrictions should not break the scenario execution. They instruct a Use-Case designer to add an Exception at the point where the scenario violates the requirement.

Exceptions follow the same guidelines as the Alternative Scenarios (i.e. use lettered list) except they ensure the post-conditions violation.

Examples:

Person Wake Up: no exceptions expected
The Anti-Lock Baking
1. Faulty Wheel Rotation Sensor
  1. Main Scenario 2.1. Detects sensor fault
  2. Main Scenario 2.1.1. Display Braking System Fault
  3. Main Scenario 2.1.2. Stop execution

Meet Design Method

The proposed design method was developed to ensure the development speed and content quality are properly balanced. The design method leverages the Fail Fast technique allowing to detect and mitigate failures before they significantly affect the Use-Cases.

The main ideas behind the method design are

shallow and layered design
clean semantics
teamwork enabler
increased development speed

Even in the era of LLM and generative AI only a person understands their desires and goals. It doesn’t really matter whether human talks to humans or AI, in either case it’s necessary to explain thoughts and ideas clearly and add details as necessary until the outcome of their work is satisfactory. The method helps to focus on the important parts only. The level of the details depends only on the distance between the real and anticipated result. When development teams provide consistent and satisfactory designs based on the Use-Cases it’s totally acceptable to complete only necessary parts. The only note here is, make sure all mandatory fields are complete and agreed between the reams before increasing the Maturity Level.

Specifically I would like to focus on the tendency to do the over-engineering and underestimate the importance of the bird view. This leads to the increased time spent to align on the smaller aspects of the generally inconsistent picture.

In contrast, following the method allows to adapt development to the agile methodologies natively integrating iterations in the do-review-change process.

Design Shallow

The first principle follows the well known practice of agile development with short design cycles, and continuous alignment with all the stakeholders. Each design iteration adds only necessary details to make review as short as possible and keep everyone on the same page. Along with that designers and development teams get accustomed to each other's thinking and work styles faster.

Someone may argue that shorter iterations are more expensive in terms of the overall process management. They have to consider endless calls and meetings where discussion falls into the details and participants hardly hear each other.

Fail Fast

The second principle is all about not being afraid of faults. Faults are normal, they must be happening. Only the faults align teams on the common understanding of the problem points. The faults uncover the gaps, pitfalls and cognition issues of the design and development teams.

In conjunction with the Design Shallow principle it helps to spot the actual and potential pitfalls before the design team goes deep into the details. Faster reviews and incremental improvements are a key to balance the team's workload.

Focus on Semantics

There are three layers of the review: Formal, Semantic and Logical.

Humans and LLMs are quite good in spotting the Formal failures. I.e. missing field or out-of-order data completion.But this is a low-value error spotting because Formal checks rarely help to improve the Use-Case quality.

Neither Human, nor LLMs are good in understanding Logical failures from the natural languages. Both need to reconstruct a method of thinking of a Use-Case author and prepare their own picture. Nevertheless nobody knows whether the reconstructed picture is right or wrong. There’s nothing wrong with it, but due to the cognitive biases it’s quite a time-consuming and challenging task.

The level where Humans are good is the Semantic checks. It’s easy to study semantically-justified statements and follow this style across the teams and projects. In turn this helps to focus on the Logical level because structure checks are done in the background and even could be automated.

Incremental Maturity

Design Shallow, Fail Fast and Focus on Semantics uncover the hidden gem of Incremental Maturity. It is the core of the method.
The Incremental Maturity is simple: work iteratively, develop in collaboration with the reviewers. Surely it does not replace other well established practices like peer reviews, design freezes, inspections, audits and so on. It focuses on the reduction of the cognitive load and gradual increase of design complexity. Cognitive load reduction itself natively comes from the fact of smaller design chunks compared to the whole structure developed at once.

Make sure all the teams involved in a Use-Case development are on the same page before going to a next step. Perform reviews on each step to find the pitfalls.

Step zero

Before moving forward you have to ensure that all the teams talk the same language. You have to create all necessary dictionaries and align on the terms. The dictionaries might be incomplete (and will be) but working on the Use-Cases you will add as many terms as necessary.

Step one

Frame the Design. It’s purely Maturity A level of a Use-Case deliverable. Focusing on what needs to be done helps to prepare not solely a Use-Case but entire product ontology based on the Goals.
The Maturity A Use-Cases are the best to be aligned with the product, architecture and customer performance teams.

Step two

Frame the Solution. It’s the Maturity B level of a Use-Case deliverable. Focusing on how a product solution needs to look prepares insights on the available engineering solutions. It is the place to agree what needs to be engineered to fulfil the product and customer expectations.

The Maturity B Use-Cases are the best to be aligned with the architecture, engineering, safety and customer performance teams.

Step three

Frame the Engineering. It’s the Maturity C level of a Use-Case deliverable. This is the last step where the change is driven by the Use-Case design team. Framed engineering helps to ensure that the solution exactly matches the product and customer expectations.

The Maturity C Use-Cases are the best to be aligned with the architecture, engineering, safety and legal teams.

Step four

Frame the Signatures. This is the step where all stakeholders agree on the Use-Case, its decomposition and planned implementation. It is a last resort when the Use-Case can be sent to rework. This step is a crucial part of the method based on the collaboration between the teams.

Conclusion

Use-Cases are the one of the oldest and well-known forms of the business requirement deliverables. Although they are rarely cooked well because of the different problems. To name a few, there's the lack of expertise, lots of the Use-Case flavours, time constraints, wrong team assignment, etc. Nevertheless there’s a chance to utilise the Use-Cases for the business analysis and deliver clear and consistent product definition to the development teams.

There are numerous books and articles suggesting how to write Use-Cases well. Most of them agree that the Use-Case needs to be consistent, well aligned with others, simple to understand and so on. This article suggests the same, but focuses on the method of collaborative Use-Case evolution. The method itself fosters the communications based on the Use-Case maturing and alignment to enforce all other properties like common point of view, consistency and so on. Applied well it helps to shorten the development cycles, improve the agile or product planning and empowers the teams with the new instrumentation.

This article puts apart the very important topics of the requirements testing, traceability, exchange, baseline and others. This was intentionally done to focus on the collaboration per se based on the method of Use-Case evolution.

Happy writing and reviewing!

Use-Case Evolution Guide

zproxy.org