Requirements Engineering

1

• Requirements Engineering
• with Use Misuse Cases
• Ian Alexander
• Independent Consultant
• http//www.scenarioplus.org.uk

2
Why Requirements?

• Its easy to build a Dome (1 Bn) instead of
  something useful
• Its hard to add quality later (rifles that dont
  fire cars that turn over mobiles whose
  batteries self-disconnect)
• Its terribly embarrassing (recalling 100,000
  cars to replace a 10 component in the gearbox)
  reputation
• Its hugely expensive to fix unexpected trouble
• late (JLE 5 Bn, 3x budget, on time but with
  slashed specifications capacity, braking
  control) ...
• or never (Nimrod AEW 1.5 Bn cancelled - AWACS
  bought instead Mobile army cellphone radio
  network halted (400m) and re-tendered)

3
Why does it keep on happening?

• It isn't that they can't see the solution.
• It is that they can't see the problem.
• G.K.Chesterton

4
How can we do better?

• Specify the System you want
• Specify how you will Test / Accept it
• is that enough?

5
Questions to Ask

• Whats it for? ... but still focusing on systems!
• Who wants it? users, stakeholders
• Why? objectives, goals
• What will they do? When? How? scenarios
• What if something goes wrong? exceptions
• What quality? How fast? How reliably? How safely?
  How many? qualities, constraints

6
Roles in the System Hierarchy
The Wider Environment
The Containing System
Our
The SYSTEM being developed
Our Customers
Regulators
Operators
The Equipment
Constraints -ilities (standards, regulations)
What they want the SYSTEM to do for
them (desired results)
Scenarios (how to use the equipment)
Neighbouring Systems
Interfaces (how they use the equipment)
7
Viewpoints of System Roles
Regulators care about safe and effective running
of system, from outside, on behalf of the public
Operators of the Equipment we make it work, on
behalf of our customers
Our Customers
Operators
Regulators
The Equipment
Direct Beneficiaries of the system its for them
Owners of neighbouring systems care about the
results they can get through their interfaces to
our system
Neighbouring Systems
Incidentally, which of these would you call
Users?
8
Roles Military Radar
Army
(No Financial Beneficiary)
Intelligence
President, Government
Radar Operator
Military Commanders
RadioRegulator
Radar
(Normal Operator)
(Political Beneficiary)
(Functional Beneficiary)
(Regulator) Surrogate - on behalf of The Public
Fitter
Military Procurement
(MaintenanceOperator)
The Public (Negative)
(Purchaser) Surrogate - on behalf of Operators,
etc
(Developer) has a stake in the process do you
need to ensure he has a continuing stake in the
product?
9
The Job a Scenario Does

• A Scenario says
• who does what (when operating a system)
• when
• and usually, in what order (but choosing an order
  of activities means designing system
  interactions)
• Better than asking what dyou want? as people
  are good at saying what they actually do, or
  envisage doing and more realistic

10
Elicitation mainly from Operational Roles
NeighbouringSystems
(Interfaces)
System under design
(Benefits)
(Operations)

• Interviews
• Working as an Operator
• Scenario Workshops

(Maintenance)
11
Elicitation mainly from Non-Operational Roles
(Political Impact)

• Lobbying
• Legislation

• Safety Cases
• Standards
• Negotiations

Government
Mass Market
(Safety, Quality)
(Effectiveness, Ease of Use, Cost)
Regulator

• Market Surveys
• Prototypes
• Trials
• Analogous Products
• Competitors
• Observation Fieldwork

(Negative Impact)
The Public

• Public Meetings
• Focus Workshops
• Questionnaires

12
Scenario Workshop

• A workshop can represent a sequence of tasks
  directly by role-play
• Users often understand processes for the first
  time

next user states
role, activity
user states role activity,
identifies next user(s),
throws token(s)
13
Use Cases ...

• Ivar Jacobson 1992 brought Scenarios to the
  world's attention (Bravo!)
• BUT Taking a Functional Approach, which ...
• can ignore Non-Functional Requirements
• can mean never getting around to Exceptions
• can even avoid thinking out essential Stories
• which you might have thought the essence of
  searching out behaviour with scenarios.

14
Structured Requirements as Use Cases
If these or other parts of the story are
complicated, we can treat them as included Use
Cases in their own right
The basic functional requirements form the
steps of the story here
Supporting requirements are added here
End result the behaviour of the system is
described in a clear, readable, well-organised way
15
A Use Case Diagram
Requirements (Use Cases) Train Operations Prepare
the Train Operate the Train Take Train into
Service Check Start Conditions Calibrate Tacho
Wheel Slow Speed Manual Coded Manual ADB
Operations ADB Maintenance ADB Development
16
Swimlanes Diagram
Actor/Role

• easy to understand
• actors/roles get full weight
• single or multiple threads

17
Requirements Document Aim is to achieve

• Readability (requirements in narrative scenarios)
• Simplicity in use
• Traceability to individual items
• Accuracy of representing relationships between
  items
• Freedom to work in style appropriate to situation
• Compliance with industry standard tools methods

18
Use Case Document Structure

• Introduction
• Business Objectives
• Stakeholders (Operational/Non-operational)
• References
• Conventions Used
• Use Cases
• Group1 (Cases in Use Case Diagram1)
• Use Case1
• Primary Scenario (steps 1, 2, 3)
• Alternative Paths
• Exceptions
• Local NFRs
• Next Use Case...
• Next Use Case Group
• Global NFRs

19
Use Case Example

• Normal Day
• Primary Scenario
• HH Activates Alarm.
• HH closes door.
• Alarm listens out on all its sensors for
  possible Detected Intrusion.
• includes Detected Intrusion
• HH opens door.
• HH deactivates alarm.
• Alternative Paths
• HH activates Alarm from outside the house
  (deluxe system only).
• Exceptions
• Alarm cannot be activated HH contacts Control
  Centre.
• Local NFRs
• Usable with 5 minutes training.

Each step is a possible functional requirement
(this example is at whole-system level)
Non-functional requirements and other conditions
that apply in this specific case
20
What Happens if You Always Look on the Positive
Side?

• At least you relax and are happy
• But you aren't ready for problems when they come
  up
• In business, there are people who want you to
  fail
• On projects, there are many types of cockup
• In systems, there are threats and hazards all
  round
• In software, there's a bug in every module
• "If anything can go wrong, it will"
• (The REAL Captain Murphy, USAAF)

21
So, It Pays to Think Out 'Negative Scenarios'

• 1 Either you think out what could happen
• and what you mean to do about it
• 2 Or you wait until it happens
• and you find out whether it's too late to do
  anything about it.
• Here are some techniques for approach 1.

22
Understanding Negative Scenarios

• A Scenario is a sequence of actions leading to
  a Goal desired by a person or organisation
• A Negative Scenario is a scenario whose Goal is
• desired Not to occur by the organisation in
  question
• desired by a hostile agent (not necessarily
  human)
• This is a different usage from 'four possible
  future business scenarios'

23
Negative Scenarios are Not New
Montignac Caves, Dordogne, France
'Suppose it turns and charges us before it falls
into the pit'
24
Misuse Cases

• Guttorm Sindre and Andreas Opdahl, 2000
• Actor is a Hostile Agent
• Bubble is drawn in inverted colours
• Goal is a Threat to 'Our System'
• Obvious Security Applications

25
Related Ideas

• Most similar to McDermott Fox 'Abuse Cases'
• for security requirements 1999
• Maybe not far from Allenby Kelly 'Use Cases'
• failure cases in Aero-Engine design 2001
• Something like van Lamsweerde 'Goal/Obstacle'
• passive, non-sentient obstacles to Use Cases 1998
• Intention not unlike Antón Potts 'Goal
  Surfacing'
• using goals to 'surface' requirements 1998
• Possibly like Yu, Mylopoulos, Chung 'I-Star' (i)
• 'soft goals' for NFRs, beliefs, contributes to (
  or -) 1992

26
A MiniMax Approach to Security

• White's Best Move is to find out Black's Best
  Move, and counter it
• Seems natural to me to introduce 'threatens',
  'mitigates'
• Economical use of types of relationship (UML
  stereotypes)

27
Anthropomorphize for Safety

• UML's stick-man looks like 'human agent' but can
  be of any type (robot, system)
• Anthropomorphizing Forces of Nature is useful it
  enables us to use our Social/Soap Opera Brain to
  reason about threats to our systems
• Misuse Case helps to Elicit Subsystem Functions

28
Misuse Cases Identify NFRs

• Use Cases are weak on NFRs
• Misuse Cases naturally focus on NFRs, e.g. Safety
• Response is often a SubSystem Function, possibly
  to handle an Exception

29
Design Trade-Offs

• Conflict Analysis builds upon Use/Misuse Case
  Modelling with additional relationships
  'aggravates' and 'conflicts with'

30
Tube Seat Trade-Offs
The seat designers in the workshop quickly came
up with 3 candidate solutions, once the
conflicts were understood
31
Benefits of Misuse Cases

• Open a new avenue of exploration
• Contribute to searching systematically for
  exceptions, directed by the structure of the
  scenarios
• Offer immediate justification for the search and
  indicate the priority of the requirements
  discovered
• By personifying and anthropomorphizing the
  threats, add the force of metaphor to
  requirements elicitation
• Make the search enjoyable and provide an
  algorithm for the search. Obvious parallel here
  with Cost/Benefit analysis
• Make the reasoning behind affected requirements
  immediately comprehensible

32
Applications of Misuse Cases

• Eliciting Security Requirements (see Sindre
  Opdahl)
• Eliciting Safety Requirements (see Allenby
  Kelly)
• and possibly other kinds of NFRs ( ? )
• Identifying Exceptions (not unlike Anton
  Potts)
• Identifying Test Cases (seems obvious, future
  scope)
• Design Trade-offs (see Alexander)

33
Tool Support

• Free Scenario Plus toolkit for DOORS
• Graphical and Textual Output (and HTML)
• Automatic Linking, Metrics, etc
• Automatic Creation of Referenced Use/Misuse Cases
  (if user confirms)

Automatic Creation of links between Misuse and
Use Cases, by searching for underlined use case
names with simple fuzzy matching.
34
Rule-Based Linking

• Links can be specified (by underlining) from any
  (Mis)Use Case to any other
• Type of Link is determined by (Source, Target)
  Case Type, assuming you want to analyse
  threats/mitigations
• Other Types of Link (extends, etc) can be
  specified manually

35
Finally, a worked example ...
36
Example "TürSteuerGerät" Diagram
37
Example "TürSteuerGerät" Text

• 2.1.2 Light the Cabin (Innenraum-beleuchtung)
• 2.1.2.1 Primary Scenario
• a) The Driver opens a door, causing the Door
  Control Unit to switch the cabin lighting on.
• b) The cabin lights continue to shine while
  any of the car doors is open.
• c) The Door Control Unit lights the Entry/Exit
  Lamp for each door while it is open.
• d) The Door Control Unit switches off the
  cabin lights 30 seconds after the last door is
  closed.
• 2.1.2.2 Alternative Paths
• a-i) A Frontseat or Rearseat Passenger opens
  their door.
• d-i)The Door Control Unit switches off the
  cabin lights as soon as the ignition is
  activated.
• 2.1.2.3 Exceptions
• b1) No door opened/closed for 10 minutes Door
  Control Unit switches cabin lights off.
• c1) Battery Tension fallen below 10V The Door
  Control Unit does not light any Entry/Exit Lamp,
  until the Battery Tension is again above 10.5V.
• 2.1.2.4 Constraints
• ---
• 2.1.2.5 Trigger
• A door is opened.
• 2.1.2.6 Preconditions
• The Door Control Unit is active.
• 2.1.2.7 Stakeholders and Interests

38
Tool Output Hypertext Index
Hierarchical Index
Graphical Index (point and click)
39
Hypertext Export - Actors
40
Hypertext Export - Use Case
41
Summary

• Use/Misuse Cases new forms of old techniques
• Planning has always been 'what-if'
• Systems that don't plan to handle Exceptions are
  planning to fail at once
• Powr of Visual Metaphor
• threats (black)
• roles (stick-men) anthropomorphism
• Use/Misuse Cases throughout System Life-Cycle

42
About...

• Ian Alexander is an independent consultant and
  trainer specialising in Requirements Engineering,
  often using DOORS. He is well-known as a speaker
  and writer on requirements matters.
• He is the author of the JBA 3-Day Requirements
  Engineering Course, and co-author of its 3-Day
  Systems Engineering Course. His new book 'Writing
  Better Requirements' is published by
  Addison-Wesley 2002.
• He is currently collaborating with
  DaimlerChrysler Research and Technology on the
  reuse of requirements between different series of
  cars. He created the Scenario Plus for Use Cases
  toolkit.
• He helps to run the BCS Requirements Engineering
  Specialist Group and the IEE Professional Network
  for Systems Engineers. He is a Chartered Engineer.