Architecture-First Requirements to Effective Use Cases

Overview

The importance of requirements has been discussed in the Functional and Non-Functional Requirements article. The requirements by themselves may not be enough to build the system properly. They are often just a set of bullet points or rows in a spreadsheet.

The requirements need to be processed before coding has started. This is what Use Cases are for. Use Cases exercise the requirements and sniff out the scenarios the same way coding does without the painful and costly refactoring.

Good Use Cases will discover new requirements or alter current ones. They will force the users to think through scenarios in a way that raw requirements can't. The Use Cases also serve as input for creating Tests Cases, which should cover every path defined in the Use Cases.

Requirements

As stated before, requirements define what the application must support. Regardless, they are not enough to properly build the application.

The Functional Requirements lead to the Business Architecture, which heavily influences the UI and database design. The Non-Functional Requirements lead to the Technical Architecture, which heavily influences the High Level architecture and backend design. The backend design is influenced by the Business Architecture as well.

Below are examples of requirements

• Functional

  • Users should be able to track their orders.

  • Users should add products to a shopping cart.

  • Users should be able to search for products based on criteria.

  • The system should be able to show different experiences to users based on how they have arrived.

  • Users should be able to check out anonymously

  • Registered Users should receive bonus points

  • The system should advertise products to the users

• Non-Functional

  • Product searches should give feedback within 5 seconds.

  • The system should handle burst periods due to holidays, etc.

  • The application should be written to handle more than 20,000 concurrent users.

Use Cases

Use Cases are also considered requirements. They are in a digestible form for developers and testers. Once completed, they can lead to User Stories and Tasks.

Basic Steps for Developing Use Cases

• Steps

  • Identify the Processes

  • Identify the Actors

  • Determine Use Cases per Actor

  • Create Context Diagrams

  • Create the Activity Diagrams

  • Create Use Case Descriptions

Identify the Processes

For a retail example, some processes may be similar to the following

• Marketing and Merchandising

  • Market Goods and Services

  • Sell Products

• Inventory Management

  • Manage Active Stock Quantities

• Finance

  • Manage Customer Purchasing

  • Perform Accounting Services

• Customer Service

  • Manage Returns

  • Assist Customers

• Supply Chain

  • Order Products

  • Interface with Suppliers

These processes are identified by Subject Matter Experts (SMEs) or by interviewing stakeholders.

Identify the Actors

• Actors

  • Customer

    • Registered

    • Guest

  • Merchant

  • Cashier

    • Payment Service

  • Advertiser

  • Identity Provider

Use Cases represent an action of value to an Actor. The Actors represent roles, but they can also represent departments if that helps to develop the Use Cases.

The Actors can extend others when they are very similar. For instance, both Registered Customer and Guest can extend the Customer Actor.

Registered Customer -extends-> Customer

Guest -extends-> Customer

The difference between Registered Customer and Guest can show up as Main Flows and Alternate Flows in the Use Cases. They can also show up as separate Use Cases with an extends clause.

Determine Use Cases per Actor

In the diagram above, the Registered Customer and Guest both share many of the Use Cases, but they have differences on how they check out. Identifying variations like this will produce a better application.

For a Customer, some Use Cases may be

• Customer

  • View Products

  • Add Product to Cart

  • Checkout

  • View Order Confirmation

Above are the base customer Use Cases. They are inherited for all derived Actors.

• Guest (extends Customer)

  • Checkout as Guest

The Guest will follow the normal Customer flows except for the Checkout case.

• Registered Customer (extends Customer)

  • View Suggested Products

  • Checkout as Registered Customer

  • View Order History

  • Receive Bonus Points

The Registered Customers have more Use Cases since the application can identify them.

Create Context Diagrams

Context Diagrams show relationships between Actors. The artifacts may consist of a few diagrams with many Actors and Use Cases. Alternatively, the artifacts may consist of many diagrams with few Actors and Use Cases. The goal is to produce the best variation of diagrams to identify the major Use Cases.

Create the Activity Diagrams

The Activity Diagrams demonstrate the interactions of Actors and Use Cases in various scenarios. It is a version of a Process Flow Diagram. Each path discovered will lead to design and coding solutions. For traceability, the Use Cases should be reflected in a Project Plan or User Story.

Create the Use Case Descriptions

Use Cases can be represented as Business Use Cases or System Use Cases.

System Use Cases

System Use Cases describe the application from a detailed point of view that can be directly used to build the application. They have a similar goals as Functional Specs (a.k.a. Functional Specifications).

These type of Use Cases introduce application decisions too early in the development process. If the technique to produce the application changes then most of the Use Cases have to be thrown out.

The Use Case description above can be used to build a feature of the application. The problem occurs when that development decision has to change. In that case, the Use Case becomes obsolete.

An additional problem occurs if a non-developer is making development decisions while creating the Use Case. The influence can limit the user experience and might produce a less than optimal coding solution.

The content of these types of Use Cases can be specified in User Stories. They are unnecessary in the Architecture-First technique.

Business Use Cases

Business Use Cases represent the business interactions without regard to the software solution. They should not change unless the business operations change. They can be implemented in various ways. If the Use Cases are done well and the business operations have not changed then the new project team can use the current Use Cases to build the new application.

The Use Case above represents the business interactions regardless of the technical solution. The technical team is free to design an optimal coding solution after understanding the business requirements.

To help produce a quality application, the Wireframes and Mockups should support the identified Use Cases. The process of developing the Use Cases should lead to hard questions and decisions. This is desired because hard questions during development lead to undesired decisions based on how much code is affected. The lack of hard questions during the requirements phase is a warning sign for the project.

Effective Use Cases

General rules for effective Use Cases are:

• Use Cases

  • should use the Business Use Case style

    • These are the most reusable and business valuable types of Use Cases

  • should not assume whether the technology supports them or not

    • This prevents the stakeholders from limiting the solutions based on technology doubts or misunderstandings

  • should identify as many paths as possible through the Use Case

    • Each path will lead to code and test cases to handle it

  • should account for Exceptional conditions

    • Unhandled Exceptional conditions lead to bad user experiences

  • should define the preconditions

    • such as, roles and security

  • should define the postconditions

    • such as, resulting outputs and system state

Finally

• Use Cases should be created thoroughly to define paths through the application

• Missing paths found later are costly and may cause significant code changes

  • if too costly then the requirement might have to be descoped, which is never a desirable outcome

• In the Architecture-First approach, the missing or unidentified scenario should be considered a requirements bug and treated like a coding error

• The effective Use Cases should lead to corresponding effective Test Cases.

Further reading

• Architect-First Strategy

• Use Case to Data Scenarios

• Functional and Non-Functional Requirements