You are currently browsing the archives for the Context tag.

The Baker’s Dozen of Use Cases

November 15th, 2010

RULE 6: If it’s not on the Context or Domain models, you can’t talk about it

(If you haven’t already read it, I’d suggest having a quick look over Part 1 of the Baker’s Dozen to familiarise yourself with the fundamentals of use case descriptions.)

Engineers love to solve problems. It’s what they do. A use case model though is not a design model – it’s an analysis model. Use cases describe what the system should do, and in what order. What use cases shouldn’t do is say how the system should achieve these things. That’s what design is for.

Stopping analysts (particularly if they’re developers) from writing implementation details in the use case descriptions is difficult.   One safe way of doing this is to limit the concepts written in the use case descriptions to only those defined on the Context or Domain models.

Both the Context model and Domain model describe things beyond the scope of software implementation. That is, they describe the problem domain, not the solution (software) domain.

The Context model defines the physical parts of the system – external systems, users, interfaces, communication channels, etc.

The Domain model describes the informational context of the system – what artefacts exist, are produced, are inputs or outputs; and how these elements relate to each other.

(See Rule 4 for more on these models; and more.)

All the data in these two models will exist irrespective of what software solution is developed. If they change then our understanding of the problem has changed.

When reviewing use cases look for concepts that are not defined on the Domain or Context models. These concepts are very likely to be implementation details. Look for items like ‘database’, ‘Hardware Abstraction Layer’, ‘Observer’, ‘RTOS’, etc. These are an indication your requirements are actually describing the solution rather than the problem.




<<Prev     Next>>

The Baker’s Dozen of Use Cases

October 21st, 2010

RULE 4 : The “Famous Five” of requirements modelling

As I discussed in Rule 1, a common misunderstanding of use cases is that they are the software requirements. Unfortunately, this isn’t the situation. Use cases are merely an analysis tool – albeit a very powerful tool (when used in the right situation).

Use cases are just one technique for understanding and analysing the requirements. In order to fully understand the requirements our use cases are going to need some support. Use cases are just one of my “Famous Five” of requirements analysis models.

The Requirements models are:

  • The Use Case model
  • The System Modes model
  • The Context model
  • The Domain model
  • The Behaviour model

Why five models? Well, each one tells me about a different aspect of the system. No one point of view can tell me everything I need to know in order to ensure my requirements are coherent, consistent and unambiguous.


The Use Case model is focussed on interaction behaviour: the who, how, what and when of interaction between the stakeholders and the system.
Use cases focus on operational scenarios. For some systems (especially a lot of application software) the (transactional) exchange of information between the users, or other direct interactors, and the system forms the bulk of the software functional requirements.
However, many embedded systems are not user-centric, or transactional in their behaviour (for example, a closed-loop control mechanism). Anyone who has attempted use case analysis on such systems tends to find the use case model is non-intuitive to construct; and tends not to yield very much information about the behaviour of the software.

The Use Case Model




The System Modes model defines the temporal behaviour of the system. That is, how the behaviour of the system changes of time, in response to external (and internal) stimuli.
The System Modes model allows the analyst to capture when and how the system functionality is available. The System Modes model is a declarative diagram, showing the behavioural modes of the system (without saying how the behaviour will be enacted) and the signals or events that cause the behaviour to change.
Application software may not be modal: it’s either running or it’s not. Embedded systems tend to have more complex dynamics (I see the system dynamics as one of the big differentiators between embedded software and application software). There are typically states where the system’s primary functionality is available, and other states where it is not. For example, most embedded systems cannot provide their primary functionality when they are starting up, or shutting down, or in a maintenance mode.

The Modes Model




The Context model defines the physical scope of the system: what is part of the system (under your control) and what is external to the system.
When creating requirements it is vital to separate the Problem Domain (the part of the real world where the computer is to exert effects) from the Solution Domain (the computer and its software). In fact, requirements should be describe in terms of the effects the system should exert in the Problem Domain (rather than how it should be designed). In addition there must be specifications for what are called Connecting Domains – that is, how the system’s input/output devices must behave (interface specifications).
The Context model gives a clear visual delineation of the Problem Domain (the environment), the Solution Domain and the Connecting Domains. The software is treated as a single black-box entity. The environment consists of the Direct Interactor stakeholders. Each Stakeholder interacts with the system via one or more interfaces (often called Terminators). For each element on the Context model there should be a set of requirements. In this example I have simulated a Context Model using a SysML Internal Block diagram.

The Context Model




The Domain model focuses on the information (that is, data) in the system and, more importantly, the relationship between the information.
The domain model aids with building a project ‘glossary’. In any project there is a huge amount of tacit information about how the problem domain operates, and the language that is used to describe it.
The focus of the Domain model is understanding the problem and describing it, rather than specifying the problem’s solution. Typically, a form of entity-relationship diagram is used. With UML, a class diagram is used (or a Block Definition Diagram in SysML).
It is tempting for development teams to skip this stage; the argument being “well, everybody knows this!” By actively and coherently modelling this information you may well avoid implicit misunderstandings; that can cost a project dear, if found too late.

The Domain Model




The Behavioural model captures the transformational aspects of the problem. The Behavioural model focuses on sources and sinks of information, and what transformations are performed by the system in between.
Although ultimately all software behaviour comes down to executing imperative code, this should be avoided for requirements analysis. Rather, focus on declarative statements of behaviour and where the data comes from (and goes to) rather than how the algorithms will be implemented.




The great strength of producing multiple models of the same system is that they are self-validating. Building a consistent set of models gives confidence that the analyst has truly understood the problem.
Concepts defined in one model must not conflict with the same concept in another model. For example, stakeholders defined in the Use Case model (its actors) must also appear on the Context model (otherwise, how are they interfacing to the system?!); similarly, the Use Case model should not mention any data or information that is not captured on the Domain model.
As I wrote in Rule 1, systems tend to have a predominant characteristic – that is, they will either be a Modal problem, a Transactional problem, a Flow-of-materials problem or a Data-Driven problem. When you are building your models of the system one or two diagrams will tend to give you more information than any of the others. For example, in a data-driven problem the Domain model will probably give you more information about the behaviour of the system than, say, the Modes model or Use Case model. The table below gives an indication of the relative value of each of the models.

Different models will have different value, depending on the type of problem.





<<Prev     Next>>

%d bloggers like this: