Software Architecture: Use cases and requirements

  • 12 September 2017
  • RedSign

Use cases form a technique for specifying functional requirements: use cases are helpful to specify what the system should do. A use case captures a contract with the stakeholders of a system about its behavior. A use case describes the system’s behavior under various conditions, as the system responds to a request from one of the stakeholders, called the primary actor. Use cases are fundamentally a description of usage scenarios in textual form.

An example of a use case is the following:

Use case:
    Withdraw cash from ATM
    User goal
Primary actor:
    Account holder
    Customer enters ATM card
        reads the bank ID,
            account number,
            encrypted PIN from the card,
        validates the bank ID and account number with the main banking system
    Customer enters PIN.
    ATM validates it against the encrypted PIN from the card.
    Customer selects ‘Withdraw cash’ and withdrawal amount
    ATM notifies main banking system of customer account and amount, and receives bank acknowledgment
    ATM delivers cash, card, and a receipt
    ATM logs the transaction

As you can see, the basic format for a use case is the following:

Use case: 
    <use case goal>
    <one of: summary level, user-goal level, subfunction>
Primary actor: 
    <a role name for the actor who initiates the use case> 
    <the steps of the main success scenario from trigger to goal delivery and any cleanup after>

Several use cases may be combined in a use case diagram. Figure 1 shows an example.

The line drawn between an actor and a use case is an association: the participation of  an actor in a use case. Instances of the actor and instances of the use case communicate with each other. This is the only relationship between actors and use cases.

An actor can be thought of as a role. In Figure 1 we see two actors: the customer and the main banking system. Both actors are associated with two use cases: withdraw cash and check balance.

Figure 2: Different levels in use cases

Use cases can be described at different levels:

  • A use case of summary level involves multiple user goals, shows the context of user goals, the life-cycle of user goals, or a table-of-contents. An example is a use case such as Handle an insurance claim (see Figure 2).
  • A use case of user goal level shows the goal a primary actor has in trying to get work done. An example of a use case on the use level is Register a loss.
  • A subfunction is a step needed to carry out a user goal. An example is Find policy holder’s file.

In Figure 2 we see three annotations on the relationships between the different levels. These are:

  • An extend relationship from a use case A to a use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B, which is referenced by the extend relationship.
  • A generalization from a use case C to a use case D indicates that C is a specialization of D.
  • An include relationship from a use case E to a use case F indicates that an instance of the use case E will also contain the behavior as specified by F. The behavior is included at the location which defined in E.

Some advice on how to write use cases:

  • A use case is a prose essay. Make the use cases easy to read using active voice, present tense, describing an actor successfully achieving a goal.
  • Include sub-use cases where appropriate.
  • Do not assume or describe specifics of the user interface.
  • An actor is not the same as an organizational role: an actor is a person, organization, or external system that plays a role in one or more interactions with the system.
  • Use UML use case diagrams to visualize relations between actors and use cases or among use cases. Use text to specify use cases themselves!
  • It is hard, and important, to keep track of the various use cases

Three types of requirements

Functional requirements

Pitfalls with respect to functional requirements are:
Having an undefined or inconsistent system boundary. The system boundary defines the scope of the system: what does and what does not belong to the system. The system boundary, therefore, determines which problems the system should solve (and which problems belong to the world outside the system). Within the system, the boundary between the responsibilities of the software and of actors within the system should be clear.

  • Describing use cases from the point of view of the system instead of describing them from the actor: the correct point of view is that from the actor.
  • Using inconsistent actor names: actors names should be consistent throughout.
  • Creating spiderwebs of actor-to-use case relations: relations between actors and use cases should be clear.
  • Writing long, excessive, or confusing use case specifications, incomprehensible to the stakeholders: use case descriptions should be clearly understandable (and understood) by the stakeholders.

Beware of:

  • A ‘shopping cart’ mentality. Stakeholders often have the tendency to treat requirements as items that can be put into a shopping cart. You should always make clear that every requirement comes at a price.
  • The ‘all requirements are equal’ fallacy: architectural requirements must be prioritized to indicate to the architect, or anyone else, which requirements are most important to the finished system. No design trade-offs can be made if all requirements are assigned the same priority. 
  • Stakeholders who will not read use case descriptions because they find them too technical or too complicated. It is important to assure that your stakeholders understand the value of taking time to understand the descriptions.

Quality requirements

Quality requirements are the main category of non-functional requirements. Quality requirements are important parameters for defining or assessing an architecture. For example, the architecture of a safety critical system will differ from the architecture of a computer game. Quality requirements may be specified using a software quality model. A software quality model serves as a discussion framework, a scheme for users and developers to talk about different kinds of quality, to prioritize different kinds of quality, and to check the completeness of quality requirements.

ISO 9126 quality model

ISO 9126 [25] is the international standard quality model. The model classifies software quality in a structured set of factors:

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

Every factor is divided into a set of sub-characteristics. For example, 

Maintainability = {Stability, Analyzability, Changeability, Testability}

Every sub-characteristic is divided into a set of attributes, an entity which can be measured or verified. The attributes are not defined in the standard quality mode.

Quint2 quality model

Quint2 (Quality in Information Technology) is a Dutch framework for software quality, extending ISO 9126 [45]. It has been introduced in the previous learning unit: see Figure 3 It adds new sub-characteristics, for example:

Maintainability = ISO9126.Maintainability + {Manageability, Reusability}

It also adds attributes to ISO 9126: e.g. Reusability has the attributes Ratio-reused-parts and Ratio-reusable-parts, where a part is a module, a component or a sub-system. It also provides metrics to measure quality; Ratio-reused-parts, for example, is measured as the size of the reused parts divided by the size of the entire software product. 

When using Quint2 as a software quality model, keep in mind that not all 32 quality attributes are equally important. A requirements engineer should prioritize the requirements.

Quality requirements should be measurable. For example, the requirement ‘The system should perform well’ is not measurable, but the requirement ‘The response time in  interactive use is less than 200 ms’ is measurable.

Change scenarios

Some quality requirements do not concern functionality but other aspects of the system. These quality requirements are mainly attributes from the Maintainability and Portability group, such as Changeability and Adaptability. These requirements cannot be linked to use cases.

Such quality requirements should be linked to specific change scenarios. By doing that, you avoid being vague. For instance, instead of writing ‘The system should be very portable’, you should write ‘The software can be installed on the Windows, Mac, and Unix platforms without changing the source code’. Instead of writing ‘The system should be changeable’, you should write ‘Functionality that makes it possible for users to transfer money from savings to checking account can be added to the ATM within one month’.


Although functional and quality requirements specify the goal, constraints limit the (architectural) solution space. Stakeholders should therefore not only specify requirements, but also constraints.

Possible constraint categories are the following:

  • Technical constraints, such as platform, reuse of existing systems and components, use of standards;
  • Financial constraints, such as budgets;
  • Organizational constraints, such as processes, skill (or lack of skill) of employees, formal rules and policies;
  • Time constraints, such as deadlines.

Source: Free Technology Academy, Software Architecture Course book