Modelling Information Systems

1
Modelling Information Systems

• OOSAD booklet Chapter 3

2
Objectives

• At the end of this session you should
• Explain some difficulties in requirements
  analysis
• Explain in outline some strategies for obtaining
  requirements
• Explain the purpose of the following UML models
  in the process
• Use Case
• Class Association Diagram
• Sequence Diagram

3
System Requirements
The Requirements specification must provide
sufficient information to enable the system to be
constructed successfully.

• Functional requirements
• What the system must do (tasks)
• Non-Functional Requirements
• Eg constraints, such as hardware to be used,
• Eg interface, documentation, training, management
  standards to be used.

4
The Difficulty with Requirements

• System Requirements are normally written in
  English
• According to the Oxford English Dictionary, the
  500 words used most in the English language each
  have an average of 23 different meanings.

5
Examples
The Duchess handled the launching beautifully,
confidently smashing the champagne against the
prow. The crowd cheered as she majestically slid
down the greasy runway into the sea.
Anti-nuclear protestors released live cockroaches
inside the White House Friday, and these were
arrested when they left and blocked a security
gate.
6
Whats wrong with these?

• The system shall list all the details of the
  members.
• Instructions to make tea
• Fill kettle with water
• Put tea bag in cup
• Pour water from kettle into cup
• Add milk
• Drink

7
From a British Airways Memorandum, quoted in
Pilot Magazine, December 1996
The Landing Pilot is the Non-Handling Pilot until
the decision altitude call, when the Handling
Non-Landing Pilot hands the handling to the
Non-Handling Landing Pilot, unless the latter
"calls go around," in which case the Handling
Non-Landing Pilot continues handling and the
Non-Handling Landing Pilot continues non-handling
until the next call of "land" or "go around" as
appropriate. In view of recent confusions over
these rules, it was deemed necessary to restate
them clearly.
8
Requirements should be ..

• Complete
• Unambiguous
• Correct ( does what the user wants)
• . Whatever that is.

9
A checklist for fuzzy requirements
1988, the MITRE Corporation, prepared a for the
U.S. Air Force.

• Incomplete lists ending with "etc.," "and/or,"
  and "TBD.
• Vague words and phrases such as "generally,"
  "normally," "to the greatest extent," and
  "where practicable.
• Imprecise verbs such as "supported," "handled,"
  "processed," or "rejected.
• Implied certainty, flagged by words such as
  "always," "never," "all," or "every.
• Passive voice, such as "the counter is set." (By
  whom or what?)
• Every pronoun, particularly "it" or "its." Each
  should have an explicit and unmistakable
  reference.
• Comparatives, such as "earliest," "latest,"
  "highest." Words ending in "or" or "est"
  should be suspect.

10
A checklist for fuzzy requirements

• Words and phrases whose meaning can be disputed
  between developer and customer, such as
  instantaneous, simultaneous, achievable, minimum,
• Contractually troublesome phrases
• "Design goal." The developer will spend money and
  other resources with no guarantee of goal
  accomplishment.
• "To the extent practicable." A decision in the
  eyes of the developer.
• "Where applicable." There are no criteria for
  judgment.
• "Shall be considered." The developer will think
  about.
• "A minimum of X." The developer will provide
  exactly X.

11
Gathering requirements How?
Background Reading
Interviewing
Document Sampling
Questionnaires
Observation
12
Your Coursework

• Think about how this applies to your feasibility
  study (coursework 3)

13
Modelling for Clarity

• Models represent the key features
• An abstraction of reality
• The Meaning of the model elements and rules for
  combining must be understood and clear
• Unambiguous syntax and semantics
• Used to communicate with
• Developers, Clients, (and any passing aliens)

14
Example Mountain bike hire company

• Extract from Statement of Requirements
• Only members can hire bikes. A member can
  reserve bikes in advance (the system records
  details of the bike, member, date and time
  reserved).
• Leaders (who must be members) take groups of
  members on particular rides. A leader has to
  hold a leadership certificate.
• Members can ride by themselves or can book
  specific rides

15
Use Case Modelling

• This shows the tasks and what or who will
  initiate them.
• What tasks can you identify?

16
Use Case
Static Model
17
Class Modelling

• The system is composed of objects that
  communicate to perform the systems tasks.
• Objects represent real-world things, events or
  roles (e.g. a particular Member or Bike)
• Objects have Attributes and Behaviour
• A Class is a template for objects of the same
  type (eg Bike is a Class)

18
Class Association Model

• A Class-Association Diagram shows the structure
  of the system eg

19
Generalisation
Class
Association
20
Generalisation

• A Leader is-a-kind-of Member
• Therefore
• The Leader Inherits all the characteristics of a
  Member and adds extra (specialised) behaviour or
  attributes
• Member is a generalisation of leader
• Leader is a specialisation (or Sub-class) of
  Member

21
Association

• A Ride is led by 1 Leader

A Leader Leads many Rides
22
How many reservations can a member make?
23
Dynamic Models

• Use Case and Class diagrams do not show how a
  system behaves over Time
• Dynamic models can show this
• UML has several Dynamic models, you will study
  only Sequence Diagrams
• These show details of how a Use Case is
  implemented, corresponding to program code.

24
Possible Book Bike Ride Use Case
Object
Time
Message
25
Summary

• Systems are complex, Models help to represent key
  features clearly and reduce ambiguity.
• Requirements should be
• Unambiguous
• Complete
• Correct
• Use Case models show tasks
• Class Diagram models show structure
• Sequence Diagram models show behaviour of a
  single use case over time.