Insights

Use Cases – Discovering and Understanding Requirements

Introduction

Use Cases are an innovative thinking method, first proposed in 1987 the method popularised within system analysis and computer engineering as a way of discovering and gaining a better understanding of the requirements of a product or system. They act as a documented user’s journey and help understand the user’s goals in interacting with a system.

Use Cases in its most basic form is a method of storytelling. However, when implemented in rich detail, it can be said that “Use case diagrams are the blueprints for your system” - McLaughlin.

Although use cases can be used to learn about those interacting with existing systems, they are most powerful when used to plan for systems which do not exist. This power is because they allow for a detailed plan to be drawn before any resources are allocated. Use Cases are concept stories that do not just help you figure out how to talk about a product, but how to build the product.

Often the process of developing a system or product includes

  1. Requirements gathering
  2. Analysis
  3. Design
  4. Construction
  5. Testing
  6. Deployment
  7. Maintenance

With analysis, design and construction often taking the
spotlight, requirements gathering can often be overlooked. However, to
effectively build a full-solution, requirements gathering needs time and
resources allocated to provide a strong foundation for any project.

Daryl Kulak states “It’s no exaggeration to say that the requirements themselves are the needs of the users.”, and as most products will have an end user or ‘actor’, it is essential to diagnose their requirements before any substantial resources are invested in designing and developing a solution or system.

The Cost of Requirements Errors

The first step in any problem-solving exercise is to
understand the root causes of the problem itself. As mentioned, product teams often
focus on the product analysis, design and construction but leave less of a
focus on requirements gathering.

In a study into project requirements, the Standish Group reported that 52.7% of IT application development projects would cost 189% of their original estimates. The Standish Group also published survey results that outline the three most common challenging factors in a project:

  1. Lack of user input (13%)
  2. Incomplete requirements and specifications (12%)
  3. Changing requirements and specifications (12%)

Requirements gathering is the lease cost to repair in a product’s development lifecycle. Studies conducted with companies including IBM, HP, TRW and GTE measured and assigned costs to errors occurring at different stages of a product’s lifecycle, the studies found that as much as 200:1 cost savings can be found in the effort invested in correcting errors during the requirements gathering stage as opposed to the maintenance stage.

UML

The Unified Modelling Language (UML) is a formalised standard developed by Grady Booch, Ivar Jacobson and James Rumbaugh to help teams visualise systems and assess their requirements. UML emerged in the mid-1990s through the combination of previously competing object-oriented (OO) software engineering methods.

The UML is composed of nine model diagram:

  1. Use case diagram
  2. Sequence diagram
  3. Collaboration diagram
  4. Statechart diagram
  5. Activity diagram
  6. Class diagram
  7. Object diagram
  8. Component diagram
  9. Deployment diagram

UML and the Relationship to Use Cases

In the context of Unified Modelling Language (UML), a use case diagram can compile the technicalities and requirements of a system's users and their interactions with the system in high detail.

UML, while useful in software development, provides a strict set of rules and terminology that is standardised amongst those who
employ it in their line of work.

When working with everyday teams, it is important not to worry about external standards and instead develop a use case template internally that communicates the system requirements effectively. The most important factor when developing and using use cases is to use terms and concepts consistently, doing so will develop a language that is easy to understand across the team.

Use Cases

In plain English, use cases are text documents that
critically assess concepts relating to an interaction with a product or system.
Use cases define –

  • Scope
  • The Primary Actor
  • Level
  • Actors
  • Stakeholders
  • Preconditions & Guarantees
  • Success Scenario
  • Extensions

Use cases give a solid baseline to design products from, one that allows investment into low-level resources to achieve a high-level view sometimes referred to as the 10,000-foot view of the product requirements. This base knowledge will provide certainty and insight into how the final product will be used and mitigates the risk of errors later in the system lifecycle.

Use Case Narrative vs Use Case Diagrams

Use Cases are not diagrams; they are text representations of processes and requirements. Use Cases can be represented with Use Case Diagrams, as a form of visual illustration.

Use case diagrams summarise the content found in a use case being modelled together in one picture. Use case diagrams allow analysts to at a glance understand the functionality required without focusing on the high-level specifications of a system.

Andrew Gemino and Drew Parker of Simon Fraser University experimented in comparing the effectiveness of use cases with and without supporting use case diagrams in conceptual modelling. The experiments concluded that participants viewing the use cases with a supporting diagram developed a significantly more profound level of understanding than participants provided with use cases alone.

Understanding Use Case Concepts

Use Cases often differ in terminology; there is no one correct way of implementing a use case. However, many common concepts can be found throughout use cases. The primary focus is made on scope, primary actor(s), and the level of the use case. Many of the listed definitions of these concepts are informed by agile software development expert Alistair Cockburn.

Concept Definition / Detail
Scope What is the system under discussion?
Primary Actor Who has the goal? The stakeholder who initiates an interaction with the system under discussion (SuD) to achieve a goal.
Level How high or low level is the goal?
Actor Anyone or anything with behaviour. Actors always define entities that exist outside of the system but have interactions with the system.
Stakeholder Someone or something with a vested interest in the behaviour of the system under discussion (SuD).
Use Case A contract for the behaviour of the SuD.
Preconditions & Guarantees What must be true before and after the use case runs.
Success Scenario A best-case scenario in which nothing goes wrong.
Extensions What can happen differently during that scenario?
Related Cases When a use case references another use case, the referenced use case is underlined.

Developing a Use Case

Understanding the concepts and history of use cases is
enough to familiarise anyone to the topic, but to truly understand use cases
and the processes involved in modelling a system, it is essential to develop
one with a case study. Creating a use case requires a deeper understanding of
the concepts outlined in the previous table.

Scope

The scope is the boundary of the system being designed. While to single-author written use cases, it may seem obvious the scope of the use case, it is essential to clearly state the obvious, as when future authors and managers work on the system, they will need to know what responsibilities they are inheriting from the project.

Identifying the Stakeholders

A stakeholder in the context of use cases is defined as “an individual who is materially affected by the outcome of the system or the project(s) producing the system.”.

Listing any stakeholders
related to a system is essential to identify the actor(s) and primary actor
in the use case. Having a clear list to refer to allows for system analysts to
consider all stakeholders before developing a new use case or to assess whether
they are included in an existing use case.

It is important to remember that all stakeholders are not necessarily actors. Interactions within a system can affect those involved in a project without the stakeholders participating as direct influencers or ‘actors’ in the use case.

Primary Actor

A primary actor initiates a use case. As a result, all use cases begin with a primary actor creating input to a system which then responds. This input and response is the catalyst for any use case.

Level Goals

There are three types of level goals in use cases. Including user-level, strategic-level and subfunction-level goals. All three levels can also be referenced by a colour keyword (Indigo/Black/White/Blue) by those familiar with the terminology.

  • User-level goals – The goal of the primary actor
  • Strategic-level goals – Involves several
    user-level goals
  • Subfunction-level goals – Necessary for the
    completion of user-level goals

Actor(s)

Aside from the primary actor, use cases can include secondary actors. Secondary actors can also provide inputs to a system; however, they are not often the focus on a use case, and where the focus is required it will be more suitable to create another case study to explore that acts as a primary actor.

Preconditions and Guarantees

Understanding the pre-requisites and conditions required for a use case to be triggered is vital as they may hold value or influence over the system. The precondition is written as a simple assertion of the state internal and external environments at the moment a use case begins. Guarantees are another term used to refer to preconditions as these are conditions guaranteed to be true before the initiation of a use case.

Success Scenario

The success scenario should align with the goals of the
primary actor. In a best-case ‘success scenario’ the primary actor will have
completed the use case interaction and will have achieved success in attaining
their intended outcome.

Extensions

Extensions of a use case are alternative pathways or courses
that are not intended for the primary actor to act out within the system. They
explore how a system could be used, other than the success scenario.

Use Case Narrative Example

The following use case is a summary of a full use case
narrative, documenting an interaction between a builder and a job board website
application (See Appendix A for a complete use case narrative example).

‘Fill My Planner’ Web Application Use Case Narrative

Primary Actor:
Builder

Scope: Job Board
(“Fill My Planner”)

Level: User goal

Stakeholders and
interests:

  • Builder – Wants to find appropriate jobs based
    on his trade and area
  • Job Owner – Wants to find appropriate workers
    that are qualified
  • Site Owner – Wants to match applicants and job
    owners

Precondition: User
already has ‘Fill My Planner’ open on their device

Minimal Guarantee:
‘Fill My Planner’ will only allow
approved builders and tradesmen to create
accounts

Success Guarantee:
The site will log any applications made by the builder to the retrospective
job, as well as email confirmation to the applicant and job owner.

Main Success
Scenario:

  1. Builder logs into the Fill My Planner web application
  2. Builder searches for jobs based on trade, location and
    price per day
  3. Builder views the job he is interested in
  4. Builder decides
    to use one of his three application credits
  5. The builder is sent a confirmation email
  6. Builder now has accessed
    the application within his dashboard

Extensions:

  1. If the applicant
    is successful, he is liable for a finder’s fee

Use Case Diagram

Fill My Planner Web Application Use Case Diagram

Figure 2: Use Case
diagram of builder and job board website application

Based on the use case narrative interaction of a builder and a job board website, a use case diagram has been modelled using the latest UML standards.

Class Diagrams, an Alternative to Use Cases?

Figure 3: Class diagram for an ATM system

Class diagrams are one of the most useful types of diagrams in UML. They provide an opportunity to model a system in high-detail. Class diagrams, however, are not without their issues, most of which can be attributed to the same reason they are advantageous.

For novices in UML, class diagrams can be intimidating due
to the complexity that class diagrams offer, commonly requiring the designer to
define clearly –

  • Classes
  • Attributes
  • Operations
  • Relationships between objects

Siau and Lee investigated if use case diagrams were appropriate for stakeholders and found when compared to class diagrams, stakeholders reported they were "interpreted more completely than class diagrams".

Issues with UML Diagrams and Processes

Participation

Client participation is essential for a successful solution
to be designed and developed; failure to involve a clear majority of the team
in the process will result in inaccurate or incomplete results.

UML Diagrams and processes have found many team
compatibility issues, with an article on the ‘Dimensions of UML Diagram Use’
surveying and assessing the feasibility of the systems in real-world database
management applications.

UML Diagram Not well understood by analysts Not useful for most projects Insufficient value to justify the cost Information captured redundantly Not useful with clients Not useful with programmers
Use Case Narrative 29 26 37 29 11 26
Use Case Diagram 32 32 42 19 29 42
Statechart 35 42 28 12 28 33
Activity 48 23 35 35 14 25

Reasons for not using Some UML Diagrams

The results found that use case diagrams alone were not useful to 42% of programmers surveyed, with 42% of the team stating they felt the diagrams provided insufficient value to justify the cost of the diagrams.

However, with use case narratives alone, a reduced but still unimpressive 26% of programmers found the model insufficient.

The journal article concluded that Use Case narratives and
class diagrams were compelling among those with a technical background, whereas
visual diagrams that focused on process over technicalities were favoured in
project management roles.

Terminology and Grammar

UML’s popularity is attributed to the flexibility the modelling system provides, allowing the models to be applied to any context. However, forefront literature argues that this flexibility causes complications, with some arguing that “the domain should determine the specific set of semantics for the diagrams”.

Over the last two decades, the formalisation of UML diagrams has become a primary focus of research in UML and system analysis, with formal grammar and terminology being proposed for use case, activity and class diagrams.

Use Case Contradictions in UML

UML principles imply that the functional requirements of a
system can be visualised and detailed with use cases as a single method
modelling approach. However, as systems become complex a system may require
multiple use cases or sub-cases.

Glinz in his research into the problems of UML highlighted that UML does not allow for references to two use cases running in parallel. Creating issues when needing to use shared state variables that are unpredictable in the form of pre-conditions. Glinz theorises that one could attempt to introduce global state variables in the form of pre/post-conditions, however, he continues to state such specification would “become clumsy for systems with more than a few state variables.”

Use Cases and Inconsistencies

Dobing and Parsons bring focus on the inconsistencies found across the implementation of use cases, sharing that from a review of literature they found “extensive differences in how use cases are defined and used… The existence of different use case formats and roles is not surprising, given UML’s relatively short history.”

UML has since matured and with new specifications has become more strict and rigid in the formats implemented in use cases. However, as Dobing and Parsons point out in the same journal article, use cases aren’t conformed to solely being used in OO (Object-Orientated) systems, and as they are used outside of OO systems, rules will be ignored, and the number of variations invented will only continue to grow.

Conclusion

A good story is good design. Whether designing a solution, product, service or system, using use cases as a strategic tool will allow a deep understanding of the ‘actors’ involved, their challenges and goals. This understanding will help you uncover patterns and opportunities for building an optimal output.

Use cases are famous primarily because they tell coherent stories about how a product or system will be used. Any team allocated to the design of the product get to see in rich-detail what functionality will exist, allowing for early reactions to adjust or reject the proposed stories.

One benefit in combining use cases and use case UML models to represent a system is that anyone can map stages of a process, and visually represent the story to any stakeholders, even those that are not familiar with UML

Relevancy to Business and Innovative Thinking

System analysis and requirements management are not limited to software development. While the discussion on use cases position in UML can be at times polarising, it is no doubt that businesses can benefit from the innovative thinking method.

Use cases provide a strategic problem-solving approach to interactions between consumers of a product and their experiences, allowing for a deep understanding of the challenges, goals and outcomes a system or ‘actor’ will encounter. Staying true to the definition of strategy, being aware of all external and internal environments.

Continue Reading 📚

Tell Me About Your Project