Requirements Engineering

1
RequirementsEngineering

• Southern Methodist University
• CSE 7316

2
Agenda

• Describing requirements
• Structured language
• Decision trees and decision tables
• Specifying timing requirements
• Use cases and storyboards
• State transition diagrams
• Entity Relationship Diagram
• Data flow diagrams
• Prototyping

3
Describing Requirements
4
Introduction

• Requirements usually written as natural language
• Supplemented with diagrams and equations
• Only notation generally understandable by all
  potential readers

5
Introduction

• However
• Ambiguous
• Opaque
• Misunderstood
• But everyone can read natural language

6
Common problems

• Requirements are written using complex
  conditional clauses (if A then if B then if C..)
  which are confusing
• Terminology is used in a sloppy and inconsistent
  way
• The writers of requirements assume that the
  reader has specific knowledge of the domain of
  the system and they leave essential information
  out of the requirements document

7
How to improve

• Requirements are read more often than they are
  written
• Investing in writing requirements is almost
  always cost effective
• Readers come from diverse backgrounds
• Do not assume knowledge/background
• This is hard! Allow time to get it right

8
Define standard templates

• Should include fields to collect the detailed
  information necessary to completely specify
• Standards make the requirements easy to read
• Standards make requirements easier to collect
• Make requirements easier to write

9
Define standard templates

• Example template
• Inputs
• Processing
• Outputs
• Include fields to support the requirement
• Uniquely identify each requirement
• Records requirements sources
• Record requirements rationale

10
Define standard templates

• Provide word processor templates
• Do not force analysts to fill in all fields in
  these forms
• Do not use special purpose S/W
• Have links to more complete description and
  information

11
Language use

• Use language simply, consistently and concisely
• 1. Keep sentences short
• Limitations on short term memory
• Must read long sentences more than once to
  understand

12
Language use

• 2. Never express more than one requirement in a
  single sentence
• Avoid the use of and in sentences
• Implies more than one requirement is being
  described

13
Language use

• 3. Avoid the use of jargon, abbreviations, and
  acronyms unless you are completely confident that
  they will be understood by ALL readers
• Same acronyms may have different meanings
• ATM (banking system and transfer mode)

14
Language use

• 4. Keep paragraphs short
• No paragraph should be more than 7 sentences
• Limitation in our short term memory
• 5. Use tables and lists wherever possible
• Much easier to understand than sentences in a
  paragraph

15
Language use

• 6. Use terminology consistently
• Do not use a term to mean one thing in one place
  in the document and something different somewhere
  else
• Difficult, especially when many people are
  contributing to the requirements process
• Use a data dictionary

16
Language use

• 7. Use words such as shall, should, will,
  and must in a consistent way
• shall indicates the requirement is mandatory
• should indicates that the requirement is
  desirable but not mandatory
• will indicated something that will be
  externally provided
• must is best avoided. If used, it should be
  synonymous with shall

17
Language use

• 8. Do not express requirements used nested
  conditional clauses (I.e. if X then if Y then R1a
  else if Z then R1b else R1c
• Easy to misunderstand
• If unavoidable, use a decision table

18
Language use

• 9. Use the active rather than the passive voice,
  particularly when describing actions taken by
  people or the system
• Most technical writing is written impersonally
• Difficult to change a personal style

19
Language use

• 10. Do not try to express complex relationships
  in a natural language description
• Diagram are much more effective for this purpose

20
Language use

• 11. Never use anonymous references
• When referring to other requirements tables or
  diagrams, give a brief description of what you
  are referring to
• Give the reference number

21
Language use

• 12. Pay attention to spelling and grammar
• Poor spelling and grammar can obscure your
  meaning
• Spelling checkers should always be used

22
Language use

• 13. Use visual emphasis (such as bold, underline,
  and italics, and different fonts) consistently
  and judiciously
• 14. Avoid vague, subjective terms such as
  user-friendly, easy, simple, rapid, efficient,
  support, several, state-of-the-art, superior,
  acceptable, robust, etc

23
Language use

• 15. Avoid comparative words such as improve,
  maximize, minimize, and optimize
• Quantify the degree of improvement that is
  needed, or state the maximum and minimum
  acceptable values of some parameter
• Ambiguous language leads to unverifiable
  requirements

24
Language use

• 16. Never use anonymous references. When
  referring to other requirements tables or
  diagrams, give a brief description of what you
  are referring to (Give the reference number
  this is why requirements should also be tagged)

25
Language use

• Use a hierarchical strategy if necessary and
  decompose a high-level requirement into smaller
  more detailed requirements to clarify and remove
  ambiguity
• Write requirements at a consistent level of
  detail

26
Language use

• Style guide should be included as part of the
  standard for specifying requirements
• Ask reviewers to comment on the writing style
• Ask them to highlight requirements that are hard
  to understand

27
Language use

• Pay attention to spelling and grammar. Poor
  spelling and grammar can obscure your meaning.
  Spelling checkers should always be used

28
Use diagrams appropriately

• Diagrams are far more effective than test for
  presenting relationships between items of
  information
• Diagrams break up sections of text into smaller,
  more readable fragments
• Diagrams from a requirements document may be
  reused when making requirements presentations to
  customers

29
When to use diagrams

• 1. Where something (a system, a document, etc) is
  made up of a number of modules or components and
  you wish to illustrate relationships between
  these components
• Using a block diagram to illustrate the overall
  structure of a system

30
When to use diagrams

• 2. Where you need to show a set of activities
  where each activity has a number of inputs and
  outputs
• Diagrams can be used to show the activity
  sequence and where activities can be carried out
  in parallel
• 3. Where you need to illustrate spatial
  organization
• Control panels

31
When to use diagrams

• 4. Where you wish to show some decomposition
  structure such as an organization chart

32
General rules for using diagrams

• Keep them as simple as possible
• Simple labeled boxes and lines to show structure
  and relationships
• Should fit onto a single page
• No connectors to other pages
• Should always be labeled with a figure number and
  title

33
General rules for using diagrams

• Avoid the use of icons which do not have obvious
  meaning
• If color shading is used, it should be used to
  distinguish different parts of the diagram or for
  emphasis
• Color should be used sparingly
• People from different backgrounds associate color
  differently
• 10 of men are color blind!

34
General rules for using diagrams

• Do not introduce diagrams unless they provide
  meaningful information about structure or
  relationships
• Should not be over-used or used to present
  information which could be more clearly expressed
  in some other way

35
Supplement natural language with other
descriptions

• 1. Decision tables where actions have to be taken
  depending on a complex set of conditions
• 2. Programming languages or program design
  languages which may be used where you wish to
  describe a number of actions which must tale
  place in sequence and where some of the actions
  are conditional or may be repeated

36
Supplement natural language with other
descriptions

• 3. Algebra when you wish to describe how
  particular numeric values must be transformed by
  an operation or particular values must be
  computed
• 4. Data flow diagrams where you need to define a
  sequence of transformations which take place
  during some end to end processing of data

37
Supplement natural language with other
descriptions

• 5. Timing diagrams to illustrate time critical
  system actions
• 6. System models such as object models, ER
  models, FSMs are helpful where you need to
  describe detailed system requirements

38
Specify requirements quantitatively

• 1. Decide on the appropriate metric which may be
  used to express the attribute
• Should depend on the type of attribute
• Should depend on the possibility of measuring
  that value in the developed system
• No point specifying something that cannot be
  measured!

39
Specify requirements quantitatively
System attribute Metric which can be used
Reliability Mean time to failure
Reliability Rate of occurrence of failure
Availability Probability of failure on demand
Performance Response time to user input
40
Specify requirements quantitatively
System attribute Metric which can be used
Performance Number of transactions processed per second
Store utilization Maximum size of system in Kbytes
Usability Time taken to learn 75 of user facilities
41
Specify requirements quantitatively
System attribute Metric which can be used
Usability Average number of errors made by users in a given time period
Robustness Time to re-start the system after failure
Integrity Maximum permitted data loss after system failure
42
The map is not the territory
43
Elicitation

• When you work with people to capture the
  requirements for a software system, you are
  trying to elicit from them an accurate picture,
  or map, of their model of the world

44
Elicitation

• Map created by three processes
• Deletion information is filtered out
• Distortion information is modified by the
  related mechanisms creation and hallucination
• Generalization the creation of rules, beliefs,
  and principles about truth and falsehood

45
Elicitation

• This is necessary
• We do not have the cognitive equipment to capture
  every nuance and detail of the world in an
  infinitely detailed mental map
• Must be selective !!
• These filters shape natural language
• May need to actively identify and challenge to
  recover information

46
Example

• They use the system to borrow books deletion
• Challenge Who specifically uses the system to
  borrow books? All users of the system or just
  some?
• Response Some users just use the system for
  stock control.

47
Example

• Borrowers cant borrow another book until all
  overdue books have been returned distortion
• Challenge Are there any circumstances under
  which someone could borrow a new book before all
  overdue books had been returned?

48
Example

• Response Actually, there are two circumstances
  under which a borrowers right to borrow books
  may be restored. Firstly, all borrowed books are
  returned secondly, any borrowed book that has
  not been returned has been paid for.

49
Example

• Everyone must have a ticket to borrow books
  generalization
• Challenge is there any user of the system who
  might not need to have a ticket?
• Response some users of the system, such as other
  libraries, may not need a ticket or may have a
  special type of ticket with different terms and
  conditions

50
Universal quantifiers

• All
• Everyone
• Always
• Never
• Nobody
• None
• Indication that you have encountered a deletion,
  distortion, or generalization
• Reached the limits of ones mental map
• Challenge these!!!!

51
Structured language
52
Structured English

• How to write Structured English
• Elements
• keywords if, then, else, for, ...
• some symbols ( )
• some standard functions GET, SEND, COPY, ...
• Write English sentences interspersed with the
  above elements
• Difficulty Balance between precision and
  understandability
• try to be precise, but generous about syntactic
  details.

53
Structured English and requirements specification

• Example Consider the following statement (same
  as in example for decision tree)

54
Rewritten in Structured English
55
Informal use of High Level Languages (HLL)

• Basic idea
• relax strictness of syntactic rules
• add systematic commenting procedures
• Typical constructs required
• structured description of abstract data items
  (simple and compound types)
• external description of routines (procedures,
  functions)
• encapsulation (modules)

56
Informal use of High Level Languages (HLL)

• import / export of program objects (structures,
  data, routines, modules)
• abstract data type (data type with its associated
  operations)
• exception handling
• input and output characterization
• functional description (structured control
  constructs)

57
Informal use of High Level Languages (HLL)

• Advantages
• clear and unambiguous
• "ideal" for communication with programmers
• potential for automation of analysis and
  validation

58
Informal use of High Level Languages (HLL)

• Disadvantages
• more difficult to communicate with the user
• forms prejudice for design and implementation
• more difficult to keep requirements apart from
  design.

59
Structured language specifications

• A limited form of natural language may be used to
  express requirements
• This removes some of the problems resulting from
  ambiguity and flexibility and imposes a degree of
  uniformity on a specification
• Often best supported using a forms-based approach

60
Form-based specifications

• Definition of the function or entity
• Description of inputs and where they come from
• Description of outputs and where they go to
• Indication of other entities required
• Pre and post conditions (if appropriate)
• The side effects (if any)

61
Form-based node specification
62
Interface specification

• Almost all software systems operate in an
  environment where there are other systems. They
  may be interfaces to these systems in different
  ways
• Three types of interface may have to be defined
  in a requirements specification
• Procedural interfaces. Sub-systems offer a range
  of services
• Data interfaces. Data structures are exchanged
• Representation interfaces. Specific data
  representation patterns may have to be used

63
Procedural interface example
package Print_server is procedure Initialize
(P PRINTER) procedure Print (P PRINTER F
PRINT_FILE ) procedure Display_print_queue
(P PRINTER ) procedure Cancel_print_job (P
PRINTER N PRINT_ID) procedure Switch_printer
(P1, P2 PRINTER N PRINT_ID) end Print_server

64
Data interface example
type MESSAGE is record Sender
SYSTEM_ID Receiver SYSTEM_ID Dispatch_time
DATE Length MESSAGE_LENGTH Terminator
CHARACTER Message TEXT end record type
SYSTEM_ID is range 20_000..30_000 type
YEAR_TYPE is range 1980..2080 type DATE is
record Seconds NATURAL Year YEAR_TYPE end
record type MESSAGE_LENGTH is range 0..10_000
type TEXT is array (MESSAGE_LENGTH) of
CHARACTER
65
Size representation
for SYSTEM_IDSIZE use 2BYTE for
YEAR_TYPESIZE use 2BYTE for
MESSAGE_LENGTHSIZE use 2BYTE
66
Representation interface example
type STATE is (Halted, Waiting, Ready,
Running) for STATE use (Halted gt 1, Waiting gt
4, Ready gt 16, Running gt 256)
67
Pseudocode
68
Pseudocode

• A quasi programming language
• Combinations of
• Imperative sentences with a single verb and a
  single object
• A limited set, typically not more than 40-50, or
  action oriented verbs from which the sentences
  must be constructed
• Decisions represented with a formal IF-THEN-ELSE
  structure
• Iterative activities represented with DO-WHILE or
  FOR-NEXT structures

69
Algorithm for calculating deferred service
revenue earned for any month
Set SUM(x) 0 FOR each customer X IF customer
purchased paid support AND ((Current month) gt
(2 months after ship date)) AND ((Current
month) lt (14 months after ship date)) THEN
Sum(X)Sum(X) (amount customer paid)/12
70
Summary

• Summarize your present understanding of the
  problem and all your findings in a concise,
  complete, well-organized and polished statement
  (processing narrative )
• Important that this step is well done, since this
  first informal document will serve as anchor for
  your further work

71
Decision Trees and Decision Tables
72
Decision Tables

• Many requirements deal with combinations of
  inputs
• Different combinations lead to different
  behaviors and outputs
• Nested IFs are a particular problem to describe
  with natural language
• Hard for non-technical users to understand if
  everything has been covered

73
Decision Tables

• Must enumerate all of the combinations of inputs
  and describe each one explicitly in a table
• Five input system leads to 25 32 combinations
  if the only permissible input values are TRUE and
  FALSE
• Represent in a table of 5 rows and 32 columns
  (00000, 00001, 00010, 00011, etc)

74
Graphical decision tree
Do nothing
Did Remote Security Respond?
yes
Initiate Emergency message
no
Activate siren
Is remote Notification Enabled?
yes
Activate siren
yes
no
yes
Has emergency sequence occurred?
Is local Alarm Enabled?
no
no
Do nothing
Do nothing
75
Activity diagram

• New UML incarnation of the flow chart
• Visual representation that is easy to understand
• Same basis information as what you can get with
  other methods

76
Activity diagram
Get req ref from doc
no more
Remove req from DB
more
Get req text from doc
empty
not empty
Remove req from doc
77
Timing Constraints
78
Timing Constraints

• Define response time requirements for software
  and/or the environment
• Many simple cases
• key press response time lt 10 msec
• Four basic types of timing constraints
• stimulus-response
• response-response
• stimulus-stimulus
• response-stimulus

79
Timing Constraints

• Stimulus is an action performed by the user or
  environment on the system
• Response is an action by the system on the user
  or environment

80
Stimulus-Response

• Stimulus-response constraint that the system
  must produce a response in accordance with a
  specified timing relationship to an earlier user
  stimulus to the system

81
Stimulus-Response

• Examples
• The system shall generate a dial tone within 15
  seconds of a user taking the phone off the hook
  (maximum constraint)
• The system shall arm the door no sooner than 1
  minute after the alarm on button is pressed
  (minimum constraint)
• Stimulus and response do not need to be adjacent
  in time

82
Response-Response

• Response-response used to specify a temporal
  relationship that must exist between two
  arbitrary system responses in the environment
• Examples
• The system shall initiate the door closing
  operation within 20 seconds of locking the
  landing gear in the retracted state (maximum)

83
Response-Response

• Examples
• The system shall generate a launch missile
  command no sooner than 5 seconds after generating
  a start battery warm up command (minimum)

84
Stimulus-Stimulus

• Stimulus-stimulus enables us to specify
  expected behavior of a user or environment of a
  system in terms of maximum or minimum timing
  constraints between two stimuli
• Examples
• Users must type their password within 15 seconds
  of typing their identification or they will be
  denied access to the database (maximum)

85
Stimulus-Stimulus

• Examples
• Pilots must not press the launch weapon button
  sooner than 10 seconds after pressing the fire
  ready button (minimum)

86
Response-Stimulus

• Response-stimulus enables us to specify a
  temporal relationship that must exist between a
  system response and a subsequent user stimulus
• Examples
• The user must dial the complete phone number
  within 1 minute of hearing the dial tone
  (maximum)

87
Response-Stimulus

• Examples
• The user may not make a menu selection sooner
  than 5 seconds after completion of the menu
  display (minimum)

88
System vs user ??

• S-R and R-R define timing requirements on the
  system being specified
• Function must be implemented in such a way as to
  be fast enough (or slow enough) to meet the
  timing requirement

89
Timing Constraints

• S-S and R-S constraints imply the system must be
  able to detect a violation of timing constraints
  by the user or environment
• Do not imply the software must be rapid or slow
  but there must be additional software
• detect inappropriate timed user stimuli
• generate alternative response to the user
• warning
• error message

90
Use cases
91
Use cases

• Formal definition a use case describes a
  sequence of actions a system performs that yields
  a result of value to a particular actor
• Describes the interactions between a user and a
  system
• Focus on what the system does for the user

92
Use case modeling steps

• Find the system boundary
• Find the actors
• Find the use cases
• Specify the use case
• Create scenarios

93
Use case model components

• Actors roles played by people or things that use
  the system
• Use cases things that the actors do with the
  system
• Relationships meaningful relationships between
  actors and use cases
• System boundary a box drawn around the use cases
  to denote the edge or the boundary of the system
  being modeled

94
The system boundary

• What is part of the system and what is external
  to the system
• Positioning of boundary has big impact on
  functional and non-functional requirements
• Defined by who or what used the system
• Drawn as a box

95
Actors

• Specifies a role that some external entity adopts
  when interacting with the system directly
• Represents a user role or a role played by
  another system
• Always external to the system
• Outside our control

96
Finding actors

• Who or what uses the system?
• Who installs the system?
• Who starts and shuts down the system?
• Who maintains the system?
• Who gets and provides information to the system?

97
Time as an actor

• For modeling things that happen to your system at
  a specific point in time but which dont seem to
  be triggered by an actor
• Automatic system backup that runs every morning

98
Building the use case model

• Consists of all the actors of the system
• All the use cases by which the actors interact
  with the system
• Describe totality of functional behavior of the
  system (not really!)

99
Use cases

• Use cases are always started by an actor
• Use cases are always written from the point of
  view of an actor

PlaceOrder
GetStatus OnOrder
100
Identifying use cases

• Consider how each actor is going to use the
  system
• Give the use case a short descriptive name that
  is a verb phrase
• May also discover new actors
• Iterative process of stepwise refinement
• Start with a name, fill in details, refine to
  complete spec

101
Identifying use cases

• What functions will a specific actor want from
  the system?
• Are any actors notified when the system changes
  state?
• Are there any external events that affect the
  system? What notifies the system about those
  events?
• Does the system store and retrieve information?
  Which actors trigger this behavior?

102
Use case diagram
PlaceOrder
Mail order system
CancelOrder
Shipping company
Send Catalog
customer
CheckOrder Status
Send Catalog
dispatcher
103
Detail a use case

• Each use case has a name and a specification
• Preconditions these are things that must be
  true before the use case execute they are
  constraints on the state of the system
• Flow of events the steps in the use case
• Postconditions things that must be true at the
  end of the use case

104
Pre and post conditions

• Preconditions constrain the state of the system
  before the use case can start. Think of them as
  gatekeepers that prevent the actor from
  triggering the use case until all their
  conditions are met
• Postconditions constrain the state of the system
  after the use case has executed

105
Use case PayVAT
ID UC1
Actors Time Government
Preconditions 1. It is the end of a business
quarter
Flow of events 1. The use case starts when it is
the end of the business quarter 2. The system
determines the amount of VAT owed to the
government 3. The system sends an electronic
payment to the government

• Postconditions
• The government receives the correct
• Amount of VAT

106
Flow of events

• The use case starts when an ltactorgt ltfunctiongt
• ltnumbergt the ltsomethinggtltsome actiongt
• Can also use prose but this can be too imprecise
• Simple declarative statement of some thing
  performing some action

107
Ill formed use case

• Customer details are entered
• Three important deletions
• Who is it that enters the customer details? Who
  triggers the use case?
• Into what are the details entered?
• What

108
When encountering vagueness

• Who specifically..?
• What specifically..?
• When specifically..?
• Where specifically..?

109
Branching within a flow

• Alternative flows must be represented
• Can be argued that a branch indicates a new use
  case
• But also leads to more use cases
• Keyword If

110
Use case ManageBasket
ID UC10
Actors customer
Preconditions 1. The shopping basket contents
are visible

• Flow of events
• The use case starts when the customer
• selects an item in the basket
• 2. If the customer selects delete item
• 2.1 The system removes the item from
• the basket
• 3. If the customer types in a new quantity
• 3.1 The system updates the quantity
• of the item in the basket

• Postconditions
• The basket contents have been
• updated

111
Alternative flows

• Sometimes its hard to express branching
• Things that can happen at any point in time
• Where in the main flow would the If go?
• Express as one or more alternative flows

112
Alternative flows

• 1. Specify the preconditions for the use case
  these must be true for all possible paths through
  the use case
• 2. Specify the normal flow of events
• 3. Specify the postconditions of the normal flow
  of events
• Append a new section to the end of the use case
  for each alternative flow

113
Alternative flows

• 1. Specify the flow of events for the alternative
  flow
• Must always begin with a boolean condition
• Specify postconditions for the flow of events

114
Use case DisplayBasket
ID UC11
Actors customer
Preconditions 1. The customer is logged on to
the system

• Flow of events
• The use case starts when the customer
• selects Display basket
• 2. If there are no items in the basket
• 2.1 The system informs the customer
• that there are no items in the
• basket yet
• 2.2 The use case terminates
• 3. The system displays a list of all items
• in the Customers shopping basket
• including product ID, name, quantity, and
• item price

115
Postconditions

• Alternative flow 1
• At any time the customer may leave
• the shopping basket screen

Postconditions

• Alternative flow 2
• At any time the customer may leave
• the system

Postconditions
116
Repetition within a flow For

• May have to repeat an action several times within
  a flow of events
• Iterates a positive whole number of iterations

n. For (iteration expression) n.1 Do
something n.2 Do something else n.3 . n1
117
Use case FindProduct
ID UC12
Actors customer
Preconditions 1. The customer is logged on to
the system
Flow of events 1. The customer selects find
product 2. The system asks the customer for
search criteria 3. The customer enters the
required criteria 4. The system searches for
products that match the customers
criteria 5. If the system finds matching products
then 5.1 For each product found 5.1.1 The
system displays a thumbnail sketch of
the product 5.1.2 The system
displays a summary of the
product details 5.1.3 The system
displays the product price 6. Else 6.1 The
system tells the customer that no matching
products could be found
118
Postconditions

• Alternative flow 1
• At any time the customer may move
• to a different page

Postconditions
119
Repetition within a flow While

• Use the keyword While to model a sequence of
  actions in the flow of events that is performed
  while some boolean condition is true

n. While (Boolean condition) n.1 Do something
n.2 Do something else n.3 . n1
120
Use case ShowCompnyDetails
ID UC13
Actors customer
Preconditions 1. The customer is logged on to
the system

• Flow of events
• The use case starts when the customer selects
• show company details
• The system displays a web page showing the
  company
• details
• While the customer is browsing the company
  details
• 3.1 The system plays some background music
• 3.2 The system displays special offers in a
  banner ad

Postconditions
121
Requirements tracing

• Important to understand if anything in SRS is not
  in a use case
• Many to many relationship between individual
  functional requirements in the SRS and use cases
• CASE tools help
• Manually create a requirements traceability matrix

122
Traceability matrix
Use case Use case Use case
UC1 UC2 UC3
R1 X
R2 X X
R3 X
R4 X
R5 X
123
Complex use cases

• Use cases should be as simple as possible
• May encounter irreducible complexity that will
  lead to complex use cases
• In this cases model the main flows through
  through this branching network as separate
  scenarios

124
Scenarios

• A scenario is one specific path through a use
  case
• Scenarios do not branch
• Each possible branch in a use case is a possible
  scenario
• Each use case has one and only one primary
  scenario
• perfect world path through complex flow

125
Scenarios

• Each use case has many secondary scenarios
• Alternative paths through the flow of events
• Exception scenarios (capture errors)

126
Use case CheckOut
ID UC14
Actors customer
Preconditions 1. The customer is logged on to
the system

• Flow of events
• The use case starts when the customer selects
• go to checkout
• The system displays the customer order
• The system asks for customer identifier
• 4. The customer enters a valid customer
  identifier
• The system retrieves and displays the Customers
  details
• The system asks for credit card information
  (name,
• expiry date, number)
• The customer enters credit card information
• The system asks for confirmation of the order
• The customer confirms the order
• The system debits the credit card
• The system displays an invoice

127
Secondary scenarios InvalidCustomerIdentifier Inv
alidCreditCardDetails CreditCardLimitExceeded Cred
itCardExpired
Postconditions
128
Specifying secondary scenarios

• Specify in the same way as a primary use case
• Secondary scenarios should be traceable back to
  its use case
• Can also reference the primary scenario

129
Use case CheckOut Secondary scenario
InvalidCustomerIdentifier
ID UC14
Actors customer
Preconditions

• Secondary scenario
• The use begins in step 3 of the use case Checkout
  when the
• customer enters an invalid customer
  identifier
• For three invalid entries
• 2.1 The system asks the customer to enter
  the
• customer identifier again
• The system informs the customer that their
  customer
• identifier was not recognized

Postconditions
130
Finding secondary use cases

• Identified by inspection to the primary use cases
• For each step in the primary use case look for
• Possible alternative paths
• Errors that might be raised
• Interrupts that might occur to the flow things
  that might happen at any time

131
How many scenarios?

• Should limit the number of secondary use cases to
  the necessary minimum
• Pick the most important ones and document those
• Where there are groups of secondary scenarios
  that are similar, document one as an exemplar and
  add notes explaining how the others differ

132
How many scenarios?

• Basic principle in use case modeling is to keep
  the amount of information captured to a necessary
  minimum
• Used to understand the desired behavior of the
  system
• Because of the iterative process, can always go
  back and add more

133
Top 10 Mistakes to Avoid When Writing Use Cases
10. Write functional requirements instead of
usage scenario text. 9. Describe attributes and
methods rather than usage. 8. Write use cases
too tersely. 7. Divorce yourself completely
from the user interface. 6. Avoid explicit
names for your boundary objects. 5. Write using
a perspective other than the users, in a passive
voice. 4. Describe only user interactions
ignore system responses. 3. Omit text for
alternative courses of action. 2. Focus on
something other than whats inside a user case,
such as how you get there or what happens
afterwards. 1. Spends a month deciding whether
to use include or extends. Rosenburg p. 60
134
Summary

• Use case modeling is part of the requirements
  flow
• Find the system boundary, find the actors, find
  use cases
• Time is often an actor
• Find use cases by considering how each actor
  interacts with the system

135
More on Use Cases
136
(No Transcript)
137
Architecture of requirements artifacts
138
Iterative process

• Requirements process is iterative and incremental
• Learning leads to modification
• Iteration through the process results in
  increasingly more correct requirements
• Makes for quicker accumulation of knowledge

139
Process overview
140
Process flow

• If starting from scratch, the gathering process
  includes
• Study, study, study
• Interview the customer and the user
• Develop a use case model and the use case
  scenarios

141
User and software requirements
142
Standard collection of information

• Description of the use case
• State of the system at the start of the use case
• State of the system at the end of the use case
• Normal sequence of events describing the
  interaction of actor and system
• Alternative courses to normal sequence of events
• System reactions to exceptions the system
  encounters

143
Defining the boundaries of the system

• Use context diagramming to understand the system
  boundaries
• Describe interactions between the system and the
  environment
• Begin with system, then add users and other
  systems
• Actor can represent one or more users

144
Potential change management actors
145
Change management context
146
Change management actors
147
Moving from steady state to steady state

• Use case begins in a steady state, receives input
  or stimulus, responds to the actor, transitions
  through one or more intermediate states, and then
  transitions to the final steady state

148
Use case states
149
Identifying use cases

• Examine each actor with the purpose of
  identifying each interaction
• For each user, identify a discrete use of the
  system
• Examine all incoming and outgoing messages for
  each system that interacts with your system
• Examine periodic and timed events

150
Change management system example
151
(No Transcript)
152
(No Transcript)
153
(No Transcript)
154
Modeling use cases
155
Multiple actors
156
Generalizing use cases

• Look for repeating actions and extract common
  behavior
• Generalization is the modularization of use cases
• Simplified maintenance, reuse, etc
• Strive to minimize complexity of multiple use
  cases (concrete use case)

157
Relationships among use cases

• INCLUDES one use case is included in another use
  case
• Included use case required to complete behavior
  necessary for the including use case to
  accomplish its work
• No option by the including use case must
  perform the actions in the included use case

158
Relationships among use cases

• EXTENDS use case extends another use case
• May be required by the extending use case to
  accomplish its goal
• Extends relationship is conditional
• When specifying the extending use case, must
  specify conditions under which you will include
  the additional sequences of actions

159
Includes and extends
160
Change management use case
161
Use case packages
162
(No Transcript)
163
Activity diagrams

• Five elements
• Activity
• Transition
• Decision
• Synchronization bars
• Swim lanes
• Activities are tasks that must be performed

164
(No Transcript)
165
(No Transcript)
166
Activity diagrams

• Transitions represent movement from one element
  in the activity to another (the flow)
• Can include events and guards
• Redirection and alternative paths allowed

167
Decision elements
168
Synchronization bars for concurrent tasks
169
Swim lanes for multiple entities
170
(No Transcript)
171
(No Transcript)
172
(No Transcript)
173
Writing use cases
174
(No Transcript)
175
Alternative courses
176
(No Transcript)
177
Using storyboards to validate use cases
178
Storyboards

• Simply a series of pictures from which a story is
  told
• Arrange pictures in a way that coincides with the
  sequence of events of the activity
• Usually follows a timeline
• More effective and accurate communication

179
Storyboards

• User screens, in whatever form (screen shots,
  drawings) are an excellent way to help users
  visualize how the system will behave under a set
  of circumstances
• Other pictures that can be used include flow
  charts, interaction diagrams, reports, record
  layouts

180
Storyboards

• Hard to just look at a set of screens and know
  whether it has the right information, context is
  lost
• Throwaway and evolutionary prototyping
• Throwaway communications vehicle
• Evolutionary goes into production

181
Other diagrams and pictures

• Some systems do not have user interfaces
• Other helpful pictures
• Activity diagrams
• Flow charts

182
(No Transcript)
183
(No Transcript)
184
(No Transcript)
185
State Transition Diagrams
186
Finite State Machines(FSMs)

• Widely used specification technique
• Used to specify system behavior in response to
  events
• Both output and next state can be determined
  solely on the basis of understanding the current
  state and the event that caused the transition
• H/W engineers have been using FSM for years

187
(No Transcript)
188
(No Transcript)
189
(No Transcript)
190
(No Transcript)
191
Same stimulus event
Different response
192
State Machines

• Models how a system responds differently to
  events over time

193
State Machines

• Models how a system responds differently to
  events over time

button switch
194
States
OFF
ON
195
States
Press
OFF
ON
Press
196
Finite State Machines

• State
• the memory of previous events
• Events
• inputs to a system
• Actions
• output in some form
• mechanical, electrical or software event

197
Finite State Machines

• State
• the memory of previous events
• Events
• inputs to a system
• Actions
• output in some form
• mechanical, electrical or software event

198
Coke Machine

• Events
• coin insertion
• Actions
• coke delivery
• coins returned
• State
• the memory of how much money has been deposited

199
FSM Diagram
Event-1
State 1
State 2
Action-k
200
FSM
Event-1
State 1
State 2
Action-k
Event-1
Not all state transitions have actions associated
with them
201
ScenarioQuarters Only, 75 cents

• Customer
• enter quarter
• Customer
• enter quarter
• Customer
• enter quarter
• Coke Machine
• deliver coke

202
Enumerate Events Actions
EventsE1 Deposit 25 cents Actions A1 Deliver
coke
203
Define States
Start State
E1
A
B
E1
E1/A1
C
EventsE1 Deposit 25 cents Actions A1 Deliver
coke
States A No money B 25 cents entered C 50
cents entered
204
State Transition Table
205
Coke Machine Scenario 2Coin Return

• Customer
• enter quarter
• Customer
• enter quarter
• Customer
• press coin return (CR)
• Coke Machine
• return coins

206
Enumerate Events Actions
EventsE1 Deposit 25 centsE2 Coin Return
(CR) Actions A1 Deliver coke A2 Return coins
207
Define States
Start State
E1
A
B
E1
E1/A1
E2/A2
C
EventsE1 Deposit 25 centsE2 Coin Return
(CR) Actions A1 Deliver coke A2 Return coins
States A No money B 25 cents entered C 50
cents entered
208
Define States
E2/A2
Start State
E1
A
B
E1
E1/A1
E2/A2
C
EventsE1 Deposit 25 centsE2 Coin Return
(CR) Actions A1 Deliver coke A2 Return coins
States A No money B 25 cents entered C 50
cents entered
209
Transition Table

• State E1 E2
• A B
• B C A/coin return
• C A/coke A/coin return

210
Transition Table
No BlanksAllowed !!

• State E1 E2
• A B
• B C A/coin return
• C A/coke A/coin return

211
Transition Table

• State E1 E2
• A B A
• B C A/coin return
• C A/coke A/coin return

212
Telephone System FSMLocal 4-digit exchange
Events d digit dialed h hang up Actions c1 con
nect to caller
213
Telephone System FSMLocal 4-digit exchange
d
d
d
d/c1
A
B
C
D
E
Events d digit dialed h hang up Actions c1 con
nect to caller
StatesA start B 1 digit dialed C 2 digits
dialed D 3 digits dialed E call in progress
214
Telephone System FSMLocal 4-digit exchange
h
d
d
d
d/c1
A
B
C
D
E
Events d digit dialed h hang up Actions c1 con
nect to caller
StatesA start B 1 digit dialed C 2 digits
dialed D 3 digits dialed E call in progress
215
Telephone System FSMLocal 4-digit exchange
h
d
d
d
d/c1
A
B
C
D
E
Events d digit dialed h hang up Actions c1 con
nect to caller
StatesA start B 1 digit dialed C 2 digits
dialed D 3 digits dialed E call in progress
216
Problems with FSMs

• The state explosion problem
• Confusing when too many states
• Requirements
• in all airborne states, when the yellow handle
  is pulled, the seat will be ejected
• maps event to large collection of states
• when the selection button is pressed, enter the
  selected mode
• implies a clustering or grouping of states

217
Harels State Charts

• Allows grouping or clustering of states

D
a
A
b
B
c
C
c
Clustering into new superstate D - reallyan
abstraction. To be in D really means to be
ineither A or C
218
Coke Machine
10/coke
10
5
D
5
5/coke
219
Coke Machine
CR
10/coke
ouch!
CR
10
10
5
A
D
5
5
5
5/coke
B
CR
220
Money Entered
No Money (A)
221
Money Entered
5
No Money (A)
10
CR
222
Money Entered
5
10
5
B
5
No Money (A)
10
CR
223
First an Example

• Safe with a combination
• positions 1, 2, 3
• movements L(eft), R(ight)
• combinations 1L, 2L, 3L, 1R, 2R, 3R
• Combo is 1L, 3R, 2L
• any other combo will set off alarm

224
Finite State Machine representation of
combination safe
225
Transition Table for FSM
226
Simple behavior
sin(x)
simple behavior does not depend on the state or
history of the object
State driven behavior can be divided into several
disjoint sets A television can be in one of
many different states (channels)
227
State machines in software design

• Ease of development by decomposing the system
  into a finite number of states the problem is
  also decomposed.
• Ease of testing state machine representation of
  software systems allows testing to be done at the
  state level or at the system level by expanding
  the state machine concept.
• Simple to understand the behavior is easily
  decomposed into non-overlapping behavior.
• Predictable behavior each state is easier to
  understand than the whole system or object.

228
Definition of a state
A state is a distinguishable, disjoint,
orthogonal, ontological condition that persists
for a significant period of time - Bruce Powell
Douglass, I-Logix distinguishable a state
accepts its own set of inputs and has its own
set of actions disjoint object can only be in
one state at a time orthogonal states cannot
overlap with one another ontological condition
of existence
229
Meely and Moore Models
input x/output y
Mealy model - outputs associated with transitions
input x
output y
Moore model - outputs associated with states
230
FSM in summary

• FSM consists of
• set of states, J
• set of inputs, K
• transition function, T
• specifies next state given the current state and
  the current input
• initial state, S
• set of final states, F

231
Back to the Safe example

• Set of states J is Safe Locked, A, B, Safe
  Unlocked, Sound Alarm
• Set of inputs K 1L, 1R, 2L, 2R, 3L, 3R
• Transition function T is the transition function
• Initial state S is Safe Locked
• Set of final states F Safe Unlocked, Sound Alarm

232
More formally..

• A FSM is a 5-tuple (J, K, T, S, F)
• J is a finite, nonempty set of state
• K is a finite, nonempty set of inputs
• T is a function from (J F) X K into J called
  the transition function
• S J in the initial state
• F is the set of final states F J

Î
Í
233
Transitions for a User Interface
current statemenu and eventoption selected
gt next state
Add a 6th component set of predicates, P, where
each predicate is a function of the global state
of the product
current state and event and predicate gt next
state
234
Elevator Example

• Review elevator example in the Schach book (p
  346-351)
• EB(e,f) represents the button in elevator e that
  is pressed to request floor, f
• Two states possible ON or OFF
• EBON(e,f) Elevator Button (e,f) ON
• EBOFF(e,f) Elevator Button (e,f) OFF

235
Elevator Example

• Two events involved
• EBP(e,f) Elevator Button (e,f) Pressed
• EBF(e,f) Elevator e arrives at Floor f

236
STD for Elevator Button
237
State Transition Rules

• V(e,f) Elevator e is visiting (stopped at) floor
  f
• No the rule becomes
• EBOFF(e,f) and EBP(e,f) and not V(e,f) gt
  EBON(e,f)
• If the elevator button is off (current state)
  and the button is pressed (event) and the
  elevator e is not visiting the floor (predicate),
  then the button is turned on

238
Floor Buttons

• ddirection, ffloor
• FBON(d,f) Floor Button(d,f) ON
• FBOFF(d,f) Floor Button(d,f) OFF
• FBP(d,f) Floor Button(d,f) Pressed
• EAF(1..n,f) Elevator 1 or .. or n Arrives at
  Floor f
• 1..n notes disjunction
• P(a, 1..n, b) P(a,1,b) or P(a,2,b) ..or P(a,n,b)

239
Floor Button Predicate

• S(d,e,f) Elevator e is visiting floor f and the
  direction in which it is about to move is either
  up (d U), down (D D), or no requests are
  pending (d N)
• this predicate is actually a state
• events and states can both be represented as
  predicates

240
Floor Button Transition Rules

• FBOFF(d,f) and FBP(d,f) and not S(D, 1..n, f) gt
  FBON(d,f)
• FBON(d,f) and EAF(1..n, f) and S(d, 1..n, f) gt
  FBOFF(d,f), d U or D
• If the floor button at floor f for motion in
  direction d is off and the button is pushed and
  none of the elevators are currently visiting
  floor f about to move in direction d, then the
  floor button is turned on

241
Floor Button Transition Rules

• Conversely,
• If the button is on and at least one of the
  elevators arrives at floor f, and the elevator is
  about to move in direction d, then the button is
  turned off

242
STD for floor button
243
States for the Elevator

• More complicated behavior
• Consists of many sub-states
• elevator slowing and stopping
• door opening
• door open with timer running
• door closing after timeout

244
States for the Elevator

• States to consider
• M(d,e,f) Elevator e is moving in direct