Use Cases - Discovering and Understanding Requirements

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 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.

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

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.

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 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.

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.

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.

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.

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.

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.

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

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.

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.

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 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.

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).

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

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.

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".

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.

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.

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.”

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.

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

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.