Sticky Bits

RULE 2: Understand your stakeholders

A Stakeholder is a person, or group of people, with a vested interest in your system. Vested means they want something out of it – a return on their investment. That may be money; it may be an easier life.


One of the keys to requirements analysis is understanding your stakeholders – who they are, what they are responsible for, why they want to use your system and how it will benefit them.

It’s important to understand (and difficult for many software engineers to accept!) your stakeholders have responsibilities above and beyond just using your product. In fact, the only reason they are using your product is because it (should!) help them fulfil their larger responsibilities. If your product doesn’t help your stakeholder then why should they use it?


The first step in requirements analysis is to define your stakeholders. That definition must include:

1. A named individual responsible for the stakeholder group
2. The stakeholder’s responsibilities. That is, a description of the roles, jobs, and tasks the stakeholders have to perform everyday. If you understand a stakeholder’s problems and needs you can define solutions that help them
3. Success criteria. That is: what is a good result for this stakeholder? The success criteria are a list of features and qualities that, if implemented, would bring maximum benefit to the stakeholder group.

Not all stakeholders are the same. For analysis, I divide stakeholders into three groups using my ‘stakeholder onion’ model:

Users.
Users are the most obvious group of stakeholders. Users directly interact with the system under development (sometimes I call them ‘Direct Interactors’).  A system’s users are concerned with how things work – what buttons to press, what order events happen, etc.  Their focus is therefore primarily functional behaviour and human-centred system qualities-of-service such as usability.

Beneficiaries.
The beneficiaries have some need that the system fulfils (or some pain that needs to be taken away!). The beneficiaries therefore benefit (often financially) by having the system in place. Typically, these stakeholders will be paying for the system. Beneficiaries are less interested in function and more interested in quality-of-service – reliability, maintainability, etc. since if these requirements are not fulfilled it will cost them money!

Constrainers.

The Users and Beneficiaries of a system are concerned with the problem they need to solve.   The Constrainers are focused not on the problem domain but on the solution domain.  The constrainers place negative requirements – or design constraints – on the system.  They place limits on how the system can work, how it will be developed, or what technologies or methodologies may be used. Constrainers come in many forms – Legislation, Standards, The Laws of physics, to name a few.

Most engineers intuitively understand they are, in some way, a stakeholder in the system they are designing, but they often do not know how to express this.  The development team itself is a Constrainer stakeholder, since it places limits on the technologies that can be implemented (lack of skills) or timescales (lack of resource).




Not only do the different stakeholders have different viewpoints, they also have different priorities on your project:

Beneficiaries’ concerns typically (but not always) outweigh user concerns.  For example, in the conflict between usability (a user concern) and low cost (a beneficiary concern) who will win? Remember: He who pays the piper calls the tune…

Constrainers should over-ride beneficiaries. Legal requirements, standards requirements, skills shortages, etc. will always supersede the desires of the other stakeholders.

The core difference between Beneficiaries and Constrainers is that Constrainers CANNOT be influenced – that is, you can negotiate on functional behaviours or qualities of service, but you cannot negotiate away legal requirements or the laws of physics!  A Constrainer either exists, in which case their criteria must be met; or they are not a Constrainer.   The skill, therefore, is to reduce the number of Constrainers on a project to open up as many different design options as possible.




Where does all this fit into Use Case analysis?  The answer is two-fold:

• Actors on a use case diagram are all stakeholders
• Stakeholder analysis gives context to the Use Case.

An Actor is an “external entity that interacts with the system under development”.  In the simplest case, that means they’re a User stakeholder.  The Beneficiaries and Constrainers also influence and affect the system behaviour, albeit in a very different way to the Users.  

Actors, Stakeholder types and Use Cases is a potential source of problems; and we’ll discuss this in a later article.


The most important reason for performing stakeholder analysis is it gives context to the Use Case model.  The Use Case System Boundary element defines the functional scope of the system – that is, what behaviours the system is required to provide – but it doesn’t give any reasons why the system has to provides those features.   There is nothing on the Use Case diagram that gives any help in validating the Use Case model.   We can add any behaviour we like to the Use Case diagram, provided we can link it to an actor.

By providing a stakeholder analysis we can validate the Use Cases by asking questions such as: Does the Use Case behaviour help the stakeholder (actor) fulfil their responsibilities?  If the behaviour does not help any stakeholder fulfil their responsibilities, should we be implementing it, or have we missed a stakeholder?  Are there other (additional) behaviours the stakeholder may need in order to fulfil their responsibilities?

<<Prev     Next>>

RULE 1: Use Cases Aren’t Silver Bullets

There are a couple of popular misconceptions around use cases:

Misconception 1: The use cases are the requirements of the system

Contrary to what many engineers believe (and many authors have written) the complete set of use cases do NOT constitute its full set of requirements for the system.


A use case model is an analysis tool. They are a mechanism for organising the functional behaviour of the system and reflecting it back to the stakeholders. This is sometimes referred to as ‘Problem Reframing’. By re-framing the requirements to are aiming to achieve three things:

• Demonstrate you have understood the problem, as the customer perceives it.
• Capture information exchange and sequencing requirements.
• Identify any missing behaviours

In order to achieve this effectively you need to generalise and abstract the customer requirements into something more manageable. Thus the use cases ‘reflect’ the system requirements without actually being the system requirements.

In embedded systems design the functional behaviour is but a small part of the requirements of the system. System developers must comply with a vast number of other requirements, including performance, reliability, security, environmental, useability, etc. Many of these are system qualities – that is, they apply to the system as a whole, not just the software. Use Cases are simply not an effective tool for capturing this information, despite attempts by several authors to incorporate them.


Misconception 2: You must always build a use case model

Engineering problems can be classified into four basic categories:

Data-oriented
In a data-oriented problem it is the information, and its relationship to other information, that is important.

Modal
Modal problems are characterised by having separate, distinct behaviours at different times. Trigger events from the environment will cause the system to change its behaviour.

Transactional
Transactional problems tend to be event-driven: A behaviour is (externally) invoked, which either produces a result or a change in the environment.

Flow-of-materials
Problems tend to be control-oriented: data/materiel moves from ‘sources’ to ‘sinks’. Algorithms and rules control how the information is moved and transformed.

While it’s perfectly correct to say that almost all systems have all these elements to some extent, in most cases one of the categories tends to dominate the requirements of the system.


Use cases are most effective when used to describe Transactional problems. Using Use Case analysis on other types of system often yields less-useful information about the system. In some cases Use Cases actually obfuscate the problem by attempting to re-frame one type of problem into a Transactional problem. For example, attempting to describe a flow-of-materials problem with use cases tends to yield trivial Use Cases and obscures the fundamental nature of the problem by trying to re-frame ‘flows’ as descrete ‘events’.


Use cases are a very powerful analysis tool – when used in the right way and under the right circumstances. But they aren’t a silver bullet. Use cases don’t solve every requirements analysis problem and they don’t necessarily suit every type of problem.

In order to use Use Cases effectively you must understand what type of problem you are trying to solve and whether use cases are the right tool for the job.

<<Prev     Next>>

Since Jacobson defined use cases back in 1992 they have been subject to a vast range of interpretations.   Alistair Cockburn, author of Writing Effective Use Cases states:

“I have personally encountered over 18 different definitions of use case, given by different, each expert, teachers and consultants”

I am no different: this is my personal interpretation of use case modelling and analysis.  To qualify this statement though, this methodology is based on nearly a decade of requirements definition work on a number high integrity projects, including military and aerospace.   That said, techniques that work in one environment may be less effective in another.  I haven’t been fortunate enough to work in every industry sector.   It may be, then, that you disagree with some of my techniques.  This is fine; I won’t think of you as a bad person.

In a series of articles I will present a set of guidelines, or rules-of-thumb.  Each of the ‘rules’ defines a good practice that I recommend when creating use cases.  Each rule forms a quality control on the requirements analysis process.  Ignoring a rule means there is an(other) opportunity for mistakes to creep into your requirements.

There’s no way I could capture every possible method or practice needed to create, analyse, review and maintain your use cases (well, short of writing a book on the subject).  I have decided to focus on a manageable number.  Ten would have been ideal; but that was too few and left out some important points.  Twelve still fell short, so I decided on a “baker’s dozen” – 13 rules.

To start, though, let’s have a quick review of Use Cases.

A brief overview of use cases

Use cases are a requirements analysis technique based on the conceit that (software) systems exist to fulfil the needs and desires of their stakeholders.  Stakeholders don’t use systems for the sake of it - they want to achieve something with the system that is of worth to them.  That is, the system must do something useful for the stakeholder, and in a fashion they expect or desire.

A use case is partial definition of a system’s behaviour, described in terms of a goal that a stakeholder of the system (called an ‘Actor’) wants to achieve, and how they achieve it.  A use case is described in terms of the interaction between the Actor and the system; specifically, it is defined in terms of the information that is exchanged between the actor and the system.

Fig 1.1 – The Basic Use Case Diagram

It is useful to think of a use case in terms of scenarios.  A scenario is a particular instance of interactions.  A scenario describes one possible way of interacting with the system (whilst trying to achieve that particular goal). When trying to achieve their goal, the Actor may have to make choices.  Also, things have a habit of going wrong.  Each variation is a different scenario.  The use case, therefore, is described by every possible scenario.  Obviously, attempting to document a use case by writing every scenario would be ludicrous for anything but the most trivial system.  The way round this is via a Use Case Description.

A Use Case Description is a structured English definition of all the use case steps.  It can be thought of as a’ blueprint’ for generating use case scenarios.  It should be possible to re-create any scenario from the use case specification.  In its basic form, a use case description is a series of steps showing how information is exchanged between the Actor(s) and the system until the Actor’s goal is met.  This flow is always initiated by an Actor (we don’t really want software doing stuff of its own accord!)  This basic form is called the Basic flow, or Main Success Scenario.  In the Basic flow nothing goes wrong and the Actor does the most normal, obvious things (this is sometimes called the “Sunny Day” scenario!)

However, when the Actor must make a choice, the use case description must fork – one path for each option the Actor can make.  Each of these descriptions is described in an Optional flow (sometimes called a Sub flow).

Similarly, not everything always goes right.  If something can go wrong in a scenario, chances are it will at some point (probably when the Actor least expects or wants it to!).  Typically, these conditions are not resolved by giving the Actor an option; they happen beyond the Actor’s control.  We have to record what happens when that ‘something’ goes wrong.  These descriptions are called the Exceptional flows.

Another very useful way of looking at a use case specification is in terms of its start and end conditions.  We can record all the possible start conditions that the system could be in; similarly, we can identify what state we expect the world to be in after we’ve finished.  The use case steps, then, map the initial conditions to the appropriate final conditions.

Finally, we throw in constraints.  A constraint is a requirement on not what the system does, but how it does it.  A constraint may define a performance requirement, a reliability requirement, a safety requirement, etc.  Each step in the use case specification can have one or more constraints applied to it.  It is difficult to document how the constraint manifests itself in the use case but it is easier to document what happens when a constraint is not met.  In this case the failure is treated as an exceptional condition.

<<Prev     Next>>