Requirements Engineering by yaosaigeng




Southern Methodist University
         CSE 7316
 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
Describing Requirements
Requirements usually written as
 natural language
Supplemented with diagrams and
Only notation generally
 understandable by all potential
But everyone can read natural
       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
         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
  Do not assume knowledge/background
This is hard! Allow time to get it
 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
 Define standard templates
Example template
Include fields to support the
  Uniquely identify each requirement
  Records requirements sources
  Record requirements rationale
 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
         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
          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
          Language use
3. Avoid the use of jargon,
 abbreviations, and acronyms unless
 you are completely confident that
 they will be understood by ALL
  Same acronyms may have different
    ATM (banking system and transfer mode)
          Language use
4. Keep paragraphs short
  No paragraph should be more than 7
  Limitation in our short term memory
5. Use tables and lists wherever
  Much easier to understand than
   sentences in a paragraph
          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
  Use a data dictionary
          Language use
7. Use words such as “shall”,
 “should”, “will”, and “must” in a
 consistent way
  “shall” indicates the requirement is
  “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”
          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
          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
  Difficult to change a personal style
          Language use
10. Do not try to express complex
 relationships in a natural language
  Diagram are much more effective for
   this purpose
          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
         Language use
12. Pay attention to spelling and
  Poor spelling and grammar can obscure
   your meaning
  Spelling checkers should always be
         Language use
• 13. Use visual emphasis (such as
  bold, underline, and italics, and
  different fonts) consistently and
• 14. Avoid vague, subjective terms
  such as “user-friendly”, easy,
  simple, rapid, efficient, support,
  several, state-of-the-art,
  superior, acceptable, robust, etc
          Language use
• 15. Avoid comparative words such
  as improve, maximize, minimize, and
  • Quantify the degree of improvement
    that is needed, or state the maximum
    and minimum acceptable values of some
  • Ambiguous language leads to
    unverifiable requirements
          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)
          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
          Language use
Style guide should be included as
 part of the standard for specifying
Ask reviewers to comment on the
 writing style
  Ask them to highlight requirements that
   are hard to understand
        Language use
Pay attention to spelling and
 grammar. Poor spelling and
 grammar can obscure your meaning.
 Spelling checkers should always be
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
Diagrams from a requirements
 document may be reused when
 making requirements presentations
 to customers
    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
  Using a block diagram to illustrate the
   overall structure of a system
    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
   When to use diagrams
4. Where you wish to show some
 decomposition structure such as an
 organization chart
   General rules for using
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
   General rules for using
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!
   General rules for using
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
     Supplement natural
     language with other
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
     Supplement natural
     language with other
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
     Supplement natural
     language with other
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
    Specify requirements
1. Decide on the appropriate metric
 which may be used to express the
  Should depend on the type of attribute
  Should depend on the possibility of
   measuring that value in the developed
  No point specifying something that
   cannot be measured!
      Specify requirements
System attribute   Metric which can be
Reliability        Mean time to failure

Reliability        Rate of occurrence of
Availability       Probability of failure
                   on demand
Performance        Response time to
                   user input
     Specify requirements
System attribute    Metric which can be
Performance         Number of
                    processed per
Store utilization   Maximum size of
                    system in Kbytes
Usability           Time taken to learn
                    75% of user facilities
     Specify requirements
System attribute   Metric which can be
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
The map is not the territory
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
Map created by three processes
  Deletion; information is filtered out
  Distortion; information is modified by
   the related mechanisms creation and
  Generalization; the creation of rules,
   beliefs, and principles about truth and
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
“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.
“Borrowers can‟t 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?
Response; Actually, there are two
 circumstances under which a
 borrower‟s 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.
“Everyone must have a ticket to
 borrow books” – generalization
  Challenge; is there any user of the
   system who might not need to have a
  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
      Universal quantifiers
 All
 Everyone
 Always
 Never
 Nobody
 None
 Indication that you have encountered a
  deletion, distortion, or generalization
   Reached the limits of one‟s mental map
   Challenge these!!!!
Structured language
         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
   try to be precise, but generous about syntactic
   Structured English and
 requirements specification
Example: Consider the following
 statement (same as in example for
 decision tree)
Rewritten in Structured
 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,
   encapsulation (modules)
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)
 Informal use of High Level
      Languages (HLL)
 clear and unambiguous
   "ideal" for communication with
 potential for automation of analysis and
 Informal use of High Level
      Languages (HLL)
 more difficult to communicate with the
 forms prejudice for design and
 more difficult to keep requirements
  apart from design.
      Structured language
 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
 Often best supported using a forms-based
 Form-based specifications
 Definition of the function or entity
 Description of inputs and where they
  come from
 Description of outputs and where they go
 Indication of other entities required
 Pre and post conditions (if appropriate)
 The side effects (if any)
                            Form-based node
ECLIPSE/Wo rk st at io n/Tools/DE/FS/3 .5 .1

Fu nctio n          Add node
Des cripti on      Adds a no de t o an exist in g design. The user select s t he t ype o f node, and it s position.
When added t o th e design, th e node becomes he curren t select ion. T he user cho oses t he no de po sit ion by
mov in g th e cursor t o the area where the n ode is added.
Inputs Node ty pe, Node position, Design iden tifier.
So urce             Node ty pe and Node po sition are inp ut by the user, Design iden tifier from th e database.
O utputs            Design identifier.
Des ti nati on      The design dat abase. T he design is committ ed t o th e dat abase on complet io n of t he
op erat io n.
Requires            Design graph ro ot ed at in put design identifier.
Pre-conditio n               The design is open an d disp layed o n th e user's screen.
Po st-co ndi ti on           The design is un changed ap art from th eaddition o f a no de of th e specified ty pe
at the given p osit io n.
Si de-effe cts      Non e
Definition : ECLIPS E/Workstation/To ols/DE/RD/3.5.1
     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
           Procedural interface
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 ;
       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 ;
        Size representation

   Representation interface

type STATE is (Halted, Waiting, Ready, Running);
for STATE use (Halted => 1, Waiting => 4, Ready => 16,
                                 Running => 256);
 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
        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) >= (2 months after ship date))
             AND ((Current month) <= (14 months after ship date))
      THEN Sum(X)=Sum(X) + (amount customer paid)/12
 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
Decision Trees and
 Decision Tables
         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
         Decision Tables
 Must enumerate all of the combinations of
  inputs and describe each one explicitly in
  a table
 Five input system leads to 2**5 = 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)
             Graphical decision tree
                                                     Did                            Do nothing
                                                     Remote            yes
                                     Emergency                                 no
                                     message                                          Activate siren
                     Is remote
                     Notification yes
                                 no                yes        Activate siren
Has emergency
                                        Is local
sequence occurred?      no                               no
                        Do nothing                            Do nothing
        Activity diagram
New UML incarnation of the flow
Visual representation that is easy to
Same basis information as what you
 can get with other methods
           Activity diagram

                             Get req ref from doc

                                        [no more]
Remove req from DB
                            Get req text from doc

                      [not empty]
Remove req from doc
Timing Constraints
      Timing Constraints
Define response time requirements
 for software and/or the environment
Many simple cases
  key press response time < 10 msec
Four basic types of timing
     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
Stimulus-response; constraint
 that the system must produce a
 response in accordance with a
 specified timing relationship to
 an earlier user stimulus to the
  “The system shall generate a dial tone
   within 15 seconds of a user taking the
   phone off the hook” (maximum
  “The system shall arm the door no
   sooner than 1 minute after the “alarm
   on” button is pressed” (minimum
Stimulus and response do not need
 to be adjacent in time
Response-response; used to specify
 a temporal relationship that must
 exist between two arbitrary system
 responses in the environment
  “The system shall initiate the door
   closing operation within 20 seconds of
   locking the landing gear in the retracted
   state” (maximum)
 “The system shall generate a
  “launch missile” command no
  sooner than 5 seconds after
  generating a “start battery warm
  up” command” (minimum)
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
  “Users must type their password within
   15 seconds of typing their identification
   or they will be denied access to the
   database” (maximum)
 “Pilots must not press the “launch
  weapon” button sooner than 10
  seconds after pressing the “fire
  ready” button” (minimum)
Response-stimulus; enables us to
 specify a temporal relationship that
 must exist between a system
 response and a subsequent user
  “The user must dial the complete phone
   number within 1 minute of hearing the
   dial tone” (maximum)
 “The user may not make a menu
  selection sooner than 5 seconds
  after completion of the menu
  display” (minimum)
     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
      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
    error message
Use cases
            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
  Use case modeling steps
Find the system boundary
Find the actors
Find the use cases
  Specify the use case
  Create scenarios
         Use case model
 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
    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
Drawn as a box
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
        Finding actors
Who or what uses the system?
Who installs the system?
Who starts and shuts down the
Who maintains the system?
Who gets and provides information
 to the system?
        Time as an actor
For modeling things that happen to
 your system at a specific point in
 time but which don‟t seem to be
 triggered by an actor
  Automatic system backup that runs
   every morning
Building the use case model
Consists of all the actors of the
All the use cases by which the actors
 interact with the system
Describe totality of functional
 behavior of the system (not really!)
                Use cases
Use cases are always started by an
Use cases are always written from
 the point of view of an actor

     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
  Start with a name, fill in details, refine to
   complete spec
     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
                Use case diagram
                                             System name

 relationship                   Mail order
                   PlaceOrder    system

                  CancelOrder                         company

 actor                          Use case
                     Send                            dispatcher
        Detail a use case
Each use case has a name and a
  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
  Postconditions; things that must be true
   at the end of the use case
   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
 Use case name    {            Use case: PayVAT
Unique identifier {    ID: UC1
Actors involved
in the use case   {   Time
                      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

                      1. The government receives the correct
                      Amount of VAT
         Flow of events
The use case starts when an <actor>
<number> the <something><some
Can also use prose but this can be
 too imprecise
Simple declarative statement of
 some thing performing some action
      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?
     When encountering
Who specifically…..?
What specifically…..?
When specifically…..?
Where specifically…..?
   Branching within a flow
Alternative flows must be
Can be argued that a branch
 indicates a new use case
But also leads to more use cases
Keyword If
      Use case: ManageBasket
  ID: UC10
1. The shopping basket contents are visible

Flow of events:
1. 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

1. The basket contents have been
        Alternative flows
Sometimes its hard to express
  Things that can happen at any point in
  Where in the main flow would the If go?
Express as one or more alternative
        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
        Alternative flows
1. Specify the flow of events for the
 alternative flow
  Must always begin with a boolean
Specify postconditions for the flow
 of events
      Use case: DisplayBasket
 ID: UC11
1. The customer is logged on to the system

Flow of events:
1. 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

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


Alternative flow 2:
1. At any time the customer may leave
the system

Repetition within a flow: For
May have to repeat an action several
 times within a flow of events
Iterates a positive whole number of
            n. For (iteration expression)
               n.1 Do something
               n.2 Do something else
               n.3 ….
      Use case: FindProduct
 ID: UC12
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
   customer’s 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

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

  Repetition within a flow:
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 ….
      Use case: ShowCompnyDetails
 ID: UC13
1. The customer is logged on to the system

Flow of events:
1. The use case starts when the customer selects
“show company details”
2. The system displays a web page showing the company
2. 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

    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
     Traceability matrix
               Use case
         UC1     UC2       UC3
R1        X
R2                X        X
R3                X
R4                         X
R5        X
      Complex use cases
Use cases should be as simple as
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
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
Each use case has many secondary
  Alternative paths through the flow of
  Exception scenarios (capture errors)
            Use case: CheckOut

 ID: UC14
1. The customer is logged on to the system

Flow of events:
1. The use case starts when the customer selects
“go to checkout”
2. The system displays the customer order
3. The system asks for customer identifier
4. The customer enters a valid customer identifier
5. The system retrieves and displays the Customer’s details
6. The system asks for credit card information (name,
     expiry date, number)
7. The customer enters credit card information
8. The system asks for confirmation of the order
9. The customer confirms the order
10. The system debits the credit card
11. The system displays an invoice
Secondary scenarios:

    Specifying secondary
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
                  Use case: CheckOut
      Secondary scenario: InvalidCustomerIdentifier

 ID: UC14


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

   Finding secondary use
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
    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
    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
         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 user’s, in a passive
 4. Describe only user interactions; ignore system responses.
 3. Omit text for alternative courses of action.
 2. Focus on something other than what’s “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]
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
More on Use Cases
Architecture of requirements
        Iterative process
Requirements process is iterative
 and incremental
Learning leads to modification
Iteration through the process results
 in increasingly more correct
Makes for quicker accumulation of
Process overview
          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
User and software
       Standard collection of
 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
Defining the boundaries of the
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
Potential change management
Change management context
Change management actors
  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
Use case states
     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
Change management
  system example
Modeling use cases
Multiple actors
   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
   Relationships among use
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
   Relationships among use
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
Includes and extends
Change management use case
Use case packages
       Activity diagrams
Five elements
  Synchronization bars
  Swim lanes
Activities are tasks that must be
       Activity diagrams
Transitions represent movement
 from one element in the activity to
 another (the flow)
Can include events and guards
Redirection and alternative paths
Decision elements
Synchronization bars for
   concurrent tasks
Swim lanes for multiple
Writing use cases
Alternative courses
Using storyboards to
 validate use cases
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
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
Hard to just look at a set of screens
 and know whether it has the right
 information, context is lost
Throwaway and evolutionary
  Throwaway – communications vehicle
  Evolutionary – goes into production
 Other diagrams and pictures

Some systems do not have user
Other helpful pictures
  Activity diagrams
  Flow charts
State Transition Diagrams
     Finite State Machines
 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
Can I interest you
in our new long
distance service?
             Can I interest you
             in our new long
             distance service?
No thanks.
Can I interest you
in our new long
distance service?
             Can I interest you
             in our new long
             distance service?
Get Lost!!
                     Can I interest you
                     in our new long
                     distance service?
Get Lost!!

                    Same stimulus
        State Machines
Models how a system responds
 differently to events over time
         State Machines
• Models how a system responds
  differently to events over time

 button switch

ON            OFF


ON      Press   OFF
    Finite State Machines
  the memory of previous events
  inputs to a system
  output in some form
    mechanical, electrical or software event
    Finite State Machines
  the memory of previous events
  inputs to a system
  output in some form
    mechanical, electrical or software event
           Coke Machine
  coin insertion
  coke delivery
   coins returned
  the memory of how much money has
    been deposited
          FSM Diagram

State 1                State 2

State 1                      State 2


          Not all state transitions have
          actions associated with them
  Quarters Only, 75 cents
 enter quarter
 enter quarter
 enter quarter
Coke Machine
 deliver coke
Enumerate Events &

           E1:    Deposit 25 cents

           A1:    Deliver coke
                        Define States
  Start                 E1
  State     A                         B

                             C    Events:
                                  E1:    Deposit 25 cents
A:      No money                  Actions:
B:      25 cents entered          A1:    Deliver coke
C:      50 cents entered
    State Transition Table
Current   Event
State     E1
A         B

B         C

C         A/deliver coke
 Coke Machine Scenario 2
       Coin Return
• Customer
  – enter quarter
• Customer
  – enter quarter
• Customer
  – press coin return (CR)
• Coke Machine
  – return coins
Enumerate Events &

           E1: Deposit 25 cents
           E2: Coin Return (CR)
           A1: Deliver coke
           A2: Return coins
                Define States
 Start            E1
 State    A                       B

    E2/A2 E1/A1
                         C   Events:
                             E1: Deposit 25 cents
States:                      E2: Coin Return (CR)
A:    No money               Actions:
B:    25 cents entered       A1: Deliver coke
C:    50 cents entered       A2: Return coins
                Define States
 Start            E1
 State    A                       B

    E2/A2 E1/A1
                         C   Events:
                             E1: Deposit 25 cents
States:                      E2: Coin Return (CR)
A:    No money               Actions:
B:    25 cents entered       A1: Deliver coke
C:    50 cents entered       A2: Return coins
         Transition Table
State       E1       E2
A           B
B           C        A/coin return
C           A/coke   A/coin return
            Transition Table       No Blanks
                                   Allowed !!
   State      E1       E2
   A          B
   B          C        A/coin return
   C          A/coke   A/coin return
            Transition Table
•   State      E1       E2
•   A          B        A
•   B          C        A/coin return
•   C          A/coke   A/coin return
Telephone System FSM
Local 4-digit exchange

            d:     digit dialed
            h:     hang up

            c1:    connect to caller
    Telephone System FSM
    Local 4-digit exchange
       d       d       d        d/c1
   A       B       C       D           E

States                         Events
A:    start                    d:    digit dialed
B:    1 digit dialed           h:    hang up
C:    2 digits dialed
D:    3 digits dialed          Actions
E:    call in progress         c1:   connect to caller
    Telephone System FSM
    Local 4-digit exchange
       d       d           d        d/c1
   A       B       C           D           E

States                             Events
A:    start                        d:    digit dialed
B:    1 digit dialed               h:    hang up
C:    2 digits dialed
D:    3 digits dialed              Actions
E:    call in progress             c1:   connect to caller
    Telephone System FSM
    Local 4-digit exchange
       d       d           d        d/c1
   A       B       C           D           E

States                             Events
A:    start                        d:    digit dialed
B:    1 digit dialed               h:    hang up
C:    2 digits dialed
D:    3 digits dialed              Actions
E:    call in progress             c1:   connect to caller
          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
      Harel‟s State Charts
 Allows grouping or clustering of states

          a                              A              a
                                                    b       B
 c            B                         c

 C        c                              C              c

                  Clustering into new superstate D - really
                  an abstraction. To be in D really means to be in
                  either A or C
                    Coke Machine

     10             10           5
A               C            D       F
    5       5        5               5/coke
        B                E
                         Coke Machine
                     CR                             ouch!
          10              10           5
     A               C             D       F
         5       5         5               5/coke
             B                 E


Money    10
 (A)    CR
              5       10

        5     B 5 C
Money    10
 (A)    CR
        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
Finite State Machine
  representation of
 combination safe
Transition Table for FSM
               Simple behavior
           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)
 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.
            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
Meely and Moore Models
               input x/output y

Mealy model - outputs associated with transitions

           input x            output y

Moore model - outputs associated with states
         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
  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
 Initial state S is “Safe Locked”
 Set of final states F {Safe Unlocked,
  Sound Alarm}
          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
            Transitions for a User
current state[menu] and event[option selected] ==> 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 ==> next state
        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
       Elevator Example
Two events involved
  EBP(e,f):   Elevator Button (e,f)
  EBF(e,f):   Elevator e arrives at Floor f
STD for Elevator Button
     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) =>
 “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”
             Floor Buttons
 d=direction, f=floor
 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)
    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
    Floor Button Transition
 FBOFF(d,f) and FBP(d,f) and not S(D, 1..n,
  f) => FBON(d,f)
 FBON(d,f) and EAF(1..n, f) and S(d, 1..n, f)
  => 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”
   Floor Button Transition
• 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
STD for floor button
    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
     States for the Elevator
 States to consider
 M(d,e,f): Elevator e is moving in direction
  d (floor f is next)
 S(d,e,f): Elevator e is stopped (at floor f
 W(e,f): Elevator e is waiting at door f
  (door closed)
 Three stop states (S(U,e,f), S(N,e,f),
  S(D,e,f) grouped into one large state
       States that trigger
DC(e,f): Door Closed for elevator e at
 floor f
ST(e,f): Sensor Triggered as elevator
 e nears floor f (controller must
 decide whether to stop or not at that
RL: Request Logged (button
     State Transition Rules
 Used to make the STD deterministic
 Elevator moves up, down, or enters a wait
  state, depending on the current state
 S(U,e,f) and DC(e,f) => M(U,e,f+1)
   “If the elevator e is stopped at floor f about to go up, and the
    doors close, then the elevator will move up toward the next
 S(D,e,f) and DC(e,f) => M(D,e,f-1)
   same going down
 S(N,e,f) and DC(e,f) => W(e,f)
   same with no requests pending
STD for Elevator
   Specification of timing
     constraint models
Finite state machines
  response-stimulus timing constraints
   where the stimulus immediately
   following the response (with no
   intervening stimuli or response) are the
   easiest to represent
  state transition diagram can be used
   (see next page)
Response time timing
 constraint in a FSM
    Specification of timing
      constraint models
Timers (alarms) used when response
 and stimulus are separated by other
 responses and stimuli
  turn on at specific points and transition
   later based on time elapsed in the timer
  works for response-stimulus and
   stimulus-stimulus constraints
Another response-stimulus
timing constraint in a FSM
    Specification of timing
      constraint models
Stimulus-response timing
 constraints with no other intervening
 stimuli or responses are
If more than one timer is needed give
 them names
Stimulus-Response timing
   constraint in a FSM
Another response-stimulus
timing constraint in a FSM
   Specification of timing
     constraint models
• A special type of event called a
  timeout can be used to model timing
  – timeout(event,number of time units)
  – occurs when the given number of time
    units has transpired since the event
Response-stimulus timing
 constraint in Finite State
Entity relationship diagrams
         What is an ERD?
 Abstractions of the real world which
  simplify the problem to be solved while
  retaining its essential features
 Used to;
   Identify the data that must be captured, stored,
    and retrieved in order to support the business
    activities performed by the organization
   Identify the data required to derive and report
    on the performance measures that an
    organization should be monitoring
         What is an ERD?
 Must be clearly defined so that all
  understand exactly what is being
 Relationships are evaluated in both
  directions to determine what type of
  relationship exists
   One friend may have many telephones
   One telephone belongs to a single friend
     Components of ERD
       What‟s in an ERD?
 Entities are drawn in boxes
 Entities should be expressed in plural
 Relationship is a line connecting the
 Arrows represent different types of
 List of attributes developed as you go
 Verbs placed on relationship lines that
  describe relationship
People, places, things, events,
 concepts of interest to an
Anything the organization needs to
 store data about
Represented by labeled boxes
Collections of things

Aircraft         Wedding

Customer          Sale
 EMPLOYEE; collection of employees that
  work at an organization
 Individual members (employees) of the
  collection are called occurrences of the
  EMPLOYEE entity
 Entities should have detailed descriptions
  (space limited inside the box)
Further described by attributes or
 data elements
Smallest units of data that can be
 described in a meaningful manner
             Employee #
             Given name
             Date of birth
             Telephone #
Frequently, a meaningful relationship
 exists between two different types of
  EQUIPMENT is allocated to PROJECTS
  TRUCK is a type of VEHICLE
   Types of Relationships
One-to-One relationships
One-to-Many relationships
Many-to-Many relationships
  One-to-One relationships
Takes place when a single
 occurrence of an entity is related to
 just one occurrence of a second
  A ROOF covers one BUILDING
  A BUILDING is covered by one ROOF
One-to-One relationships



         Covered by

 One-to-Many relationships
Takes place when a single
 occurrence of an entity is related to
 many occurrences of a second entity
  A DEPARTMENT has many
One-to-Many relationships


       Works in

Many-to-Many relationships
Takes place when many occurrences
 of an entity are related to many
 occurrences of a second entity
  EQUIPMENT is allocated to many
  PROJECT is related to many items of
Many-to-Many relationships



 Eliminating many-to-many
Many-to-many relationships in an
 ERD tend to conceal poor areas of
Almost always, many-to-many
 relationships conceal a hidden entity
Should identify these and add the
 hidden identity to the model
                 Hidden Identities
                       Hidden entities

Allocated to


       Project                           Component use
        Choosing the right
 Type of relationship can change
   Purpose of the model
   Length of time involved
   Definition of the entities participating in the
 If the definition of a ROOF entity is an
  apex or flat surface covering a building,
  then a BUILDING is covered by many
     Choosing the right
Likewise, over time an EMPLOYEE
 works in many DEPARTMENTS
    Tips on building ERDs
Nouns are clues to the entities of a
Start by describing the work that is
 done in the project or department or
 area of interest
  Pull put nouns in the sentences as
   potential candidates for entities
   Tips on building ERDs
“My address book contains
 addresses and telephone numbers
 for both friends and businesses”
    Tips on building ERDs
Verbs and adjectives sometimes help
 to get at relationships between
  Friends have addresses
Many-to-many relationships will
 cause you lots of trouble!
  Get rid of them by defining an
   intermediate third entity
    Friends/kids between “Kids” and “Friends”
    Tips on building ERDs
Spend the time to accurately define
 your entities so that everyone clearly
 understands what they represent
  You will save yourself a lot of time and
   headaches later in the process
A step by step worksheet can also be
Data flow analysis
      Data Flow Analysis
DFA used for achieving modules with
 high cohesion
Usually used with structured system
Input is the DFD
At some point data transforms from
 input to “internal” and then to output
  point of highest abstraction of input is
   where the input loses the quality of
DFD showing flow of data
 and actions of product
   Points of highest
abstraction of input and
     Points of highest
  abstraction of input and
Product decomposed into three
  input module
  transform module
  output module
Procedure is continued stepwise
 (stepwise refinement)
High cohesion and low coupling
         DFA Example
Product inputs a file name and
 returns the number of words in the
Decompose problem using two
 points of highest abstraction
DFD: First refinement
          Structure Chart
DFD does not show logical flow
  status flag returned if file does not exist
  invalid name ignored and error report
Whenever there is conditional data
 flow, there needs to be
 corresponding control flow
Two modules with communication
  read and validate filename
  format and display word count
Structure chart: First
Structure chart: Second
         Detailed Design
After architectural design has
Data structures chosen
Algorithms selected
Handed off to programmers for
  done by teams for time reasons
  each module must be understood
   without having to rely on other modules
Detailed Design
Detailed Design
     Program Description
PDL is an attractive alternative when
 the programming language has
 already been decided
  used to represent detailed design
Consists of comments connected by
 the control statements of the
 selected language
Generally clear and concise
Implementation is translation step
  tendency for designers to go too far and
   show too much detail
Multiple input and output streams
 handled by finding highest point of
 abstraction for each input and output
DFD with multiple input and
     output streams
     Transaction Analysis
Transaction; operation from the
 viewpoint of the user of the product
DFA is inappropriate for these
Break the problem into two pieces
  analyzer; determines transaction type
  dispatcher; performs the transaction
Typical transaction
processing system
            Bad design
Logical cohesion
  edit any transaction
  update any file
Wasted effort to duplicate five times
Software reuse
  basic module developed and
   instantiated five times
Poor design of transaction
   processing system
Data Flow Models
       Data-flow models
Show the processing steps as data
 flows through a system
Intrinsic part of many analysis
Simple and intuitive notation that
 customers can understand
Show end-to-end processing of data
             Order processing DFD
                                                                                                 Checked and
                     Completed                  Signed        Signed         Send to             signed order
                     order form               order form    order form       supplier               + order
  Or der
 details +   Complete             Valida te                Record
  blank      order form            order                    order
order form                                                                    Adjust
                                                     Order                   available
                                                                  Signed      budget
                                                     details    order form
                                                                                         + account
                                                           Orders            Budget
                                                            file              file
       Data-flow diagrams
 May be used to show processing at
  different levels of abstraction from fairly
  abstract to fairly detailed
 May also be used for architectural
  description showing data interchange
  between the sub-systems making up the
 Not a good way to describe system
               Equipment procurement
                       DFD                                              Delivery
              Equipment                   Checked                                            Delivery
 Specify        spec.                      spec.                                 Accept       note       Check
                            Validate                 Get cost
equipment                                                                      delivery of              delivered
                          specification                     s
 requir ed                                                                     equipment                  items
                                          Supplier          Spec. +
  Equipment                                 list           supplier +                   Order                  Installation
    spec.                                                   estimate                  notification             instructions

 Supplier                    Find                     Choose                   equipment                  Install
 database                  suppliers                  supplier                                          equipment
                                                                  details +                                    Installation
                                                                 Blank order                                   acceptance
                                                                            Checked and
                                                                         signed or der form


                      CASE toolset DFD
Input                 Valid                    Checked               Design                  User
design                design                    design               analysis               report
           Design                 Design                  Design                 Report
           editor              cross checker             analyser               generator
         Referenced            Checked
          designs               design                              Output
          Design                               Code skeleton         code       Design
          database                               generator                      database
    Semantic data models
Used to describe the logical
 structure of data processed by the
Entity-relation model sets out the
 entities in the system, the
 relationships between these entities
 and the entity attributes
Widely used in database design. Can
 readily be implemented using
     Notation for semantic data
            < name >                                         < name >

            An entity                                   An entity or relation

                    < input cardinality >

            < name >

                     < output cardinality >

     A relation between entities.                      An inheritance r elation.
The number of input entity instances            An entity inherits the a ttributes of its
is the input cardinality. The number          related entity. The sub-type is referenced
  of output instances is the output                           by the arrow.
Software design semantic
                          Owner                                   M-date
                          Desc.                                   C-date

                 1                                                            1
              has                                                           has
             nodes                                         has             links
                 N                                                             N
 name        Node                          links                           Link     name
                                   2                1
                     1                                                        1
 type                                                                               type
                  has                                                       has
                                  name             type
                 labels                                                    labels
                     N                                                         N
         is_a                             Label

        Design            text                     Icon           bitmap
Benefits of prototyping
Evolutionary prototyping
Throw away prototyping
Vertical prototyping
Horizontal prototyping
Scenario prototyping
   Software Prototyping

• Animating and
  demonstrating system
      What is a Prototype?
 A prototype is a concrete executable
  model of selected aspects of a proposed
 Rapid prototyping is the process of
  quickly building and evaluating a series of
 Usually only a partial representation of the
  system and serves as an aid in analysis
  and design
                 Types of prototypes
                                            Breadth of risk
             Investment                                         broad
                                                                  narrow       vertical
requirements              evolutionary      Breadth of risk
 Risk?                                          narrow         vertical


               Investment          Breadth of risk
               Strategy?                             broad        horizontal

                                              narrow         vertical

       Continuum of
 understanding user‟s needs

Well known            Fuzzy             Unknown

      Fuzzy needs become more understood

     Yes, but… responses from the user – unknown
     needs become known
 Uses of system prototypes
• The principal use is to help
  customers and developers
  understand the requirements for the
• The prototype may be used for user
  training before a final system is
• The prototype may be used for back-
  to-back testing
     Prototyping benefits
• Misunderstandings between
  software users and developers are
• Missing services may be detected
• Confusing services may be
• A working system is available early
  in the process
• The prototype may serve as a basis
  for deriving a system specification
 Prototyping Opportunities
 Not to prototype at all should simply not
  be an option in software development
 End user cannot throw the S/W needs
  (stated in natural language) over the wall
  and expect the development team to
  return the finished S/WE with no problems
 Must be some interaction between the end
  user and the development team
              Prototyping process

Establish           Define
                                 Develop      Evaluate
prototype         prototype
                                 prototype    prototype
objectives       functionality

Prototyping        Outline       Executable   Evaluation
   plan           definition      prototype     report
    Prototyping objectives
• The objective of evolutionary
  prototyping is to deliver a working
  system to end-users. The
  development starts with those
  requirements which are best
   Prototyping objectives
• The objective of throw-away
  prototyping is to validate or
  derive the system requirements.
  The prototyping process starts
  with those requirements which
  are poorly understood
    Approaches to prototyping

               Evolutionary         Delivered
               prototyping           system
               Throw-away     Executable Prototype +
               Prototyping     System Specification
  Evolutionary prototyping
• Must be used for systems where the
  specification cannot be developed in
  advance e.g. AI systems and user
  interface systems
• Based on techniques which allow
  rapid system iterations
• Verification is impossible as there is
  no specification. Validation means
  demonstrating the adequacy of the
    Evolutionary prototyping

Develop abstract    Build prototype    Use prototype
 specification          system           system


         Deliver   YES      System
         system            adequate?
Evol. prototyping problems
• Existing management processes assume
  a waterfall model of development
• Continual change tends to corrupt
  system structure so long-term
  maintenance is expensive
• Specialist skills are required which may
  not be available in all development teams
• Organizations must accept that the
  lifetime of systems developed this way
  will inevitably be short
   Throw-away prototyping
• Used to reduce requirements risk
• The prototype is developed from an initial
  specification, delivered for experiment
  then discarded
• The throw-away prototype should NOT be
  considered as a final system
   – Some system characteristics may have been
     left out
   – There is no specification for long-term
   – The system will be poorly structured
     and difficult to maintain
       Throw-away prototyping

   Outline         Develop                Evaluate                Specify
requirements       prototype              prototype               system


  Develop                      Validate               software
  software                     system                  system
Prototypes as specifications
• Some parts of the requirements (e.g.
  safety-critical functions) may be
  impossible to prototype and so don‟t
  appear in the specification
• An implementation has no legal
  standing as a contract
• Non-functional requirements cannot
  be adequately tested in a system
  Incremental development
• System is developed and delivered in
  increments after establishing an overall
• Users may experiment with delivered
  increments while others are being
  developed. therefore, these serve as a
  form of prototype system
• Intended to combine some of the
  advantages of prototyping but with a
  more manageable process and better
  system structure
      Incremental development
Define system

Design system          Specify system   Build system    Validate
 architectur e           increment       increment     increment


Deliver final             System          Validate      Integrate
  system                 complete?        system       increment
   Prototyping with reuse
• The system is prototyped by „gluing‟
  together existing components
• Likely to become more widely used
  as libraries of objects become
• Needs a composition language such
  as a Unix shell language
• Visual Basic is largely based on this
         Reusable component
  Reusable     Component
component      composition
 repository      system

Component        System
 catalogue     Specification
 User interface prototyping
• It is impossible to pre-specify the look
  and feel of a user interface in an effective
  way. prototyping is essential
• UI development consumes an increasing
  part of overall system development costs
• Prototyping may use very high level
  languages such as Smalltalk or Lisp
• User interface generators may be used to
  „draw‟ the interface and simulate its
       Prototyping Pitfalls
Learning curve
   high expectations for productivity with
    insufficient effort behind the learning curve
      training for the use of a prototyping technique
      need to develop corporate and project specific
       underlying structure to support the technology (or
       lower productivity may result)
Tool efficiency
   execution efficiencies associated with tools
    outside the domain of conventional
    programming languages
       Prototyping Pitfalls
   application domain has an impact on selecting
    a prototyping technique
      i.e. need real-time support features for a proces
       control system
   techniques for specific application domains
      business
      computer aided design
      distributed
      flight control
      user interface
      software engineering environments
     Prototyping Pitfalls
Undefined Role Models for
 approach to providing feedback to end
  users has resulted in a problem related
  to the behavior of the end user and
   end users can be biased in interactions with
    development team based on past
 Prototyping Opportunities
 Existing investment in maintained
   prototyping can be used on critical portions of
    existing software systems
 Adding investment in fully exploiting the
   s/w prototyping must be integrated via
    training, case studies, library development
 Developer to end user pass off
   end user involvement becomes enhanced
    when changes in requirements can first be
 One should not start full-scale
  implementation efforts based on early
  user interface designs
 Early usability evaluations based on
  prototypes faster and cheaper
 Traditional S/W engineering focused on
  refinement of various intermediate work
   executable programs at the last moment
 No user interface til the last possible
  moment is high risk
 Not possible to involve users in the design
  process by having them look at abstract
 Main idea behind prototyping is to save
  time and cost and to develop something
  that can be used with real users
Savings can only be achieved by
 somehow reducing the prototype
 compared with the full system
  cutting down the number of features
  reducing the level of functionality of the
   features (they seem to work but do not
   actually do anything)
      Vertical Prototyping
Cutting down on the number of
 features is called vertical prototyping
Result is a narrow system that does
 include in-depth functionality but
 only for a few selected features
Can only test a limited part of the full
  but it will be tested in depth
   Vertical Prototyping
Under realistic circumstances
with real user tasks
  actually accessing a DB with some real data
     Two Dimensions of Prototyping
                 Different Features
Scenario                   Horizontal Prototype

Vertical Prototype                 Full System
    Horizontal Prototyping
Reducing the level of functionality
Result is a surface layer that
 includes the entire user interface to a
 full featured system but with no
 underlying functionality
Horizontal prototype is a simulation
 of interface where no real work can
 be performed
    Horizontal Prototyping
 Makes it possible to test the entire user
  interface even though the test is
  somewhat less realistic
   users cannot perform any real tasks on a
    system with no functionality
 Advantages are fast implementation with
  various prototyping and screen design
 Can be used to assess how well the entire
  interface “hangs together”
     Two Dimensions of Prototyping
                 Different Features
Scenario                   Horizontal Prototype

Vertical Prototype                 Full System
 Reducing both the number of features and
  the level of functionality is a scenario
 Scenarios are only able to simulate the
  user interface as long as the test user
  follows a previously planned path
 Easy and cheap to build
 Not particularly realistic
Ultimate minimalist prototype
Describe a single interaction session
 without any flexibility for the user
Combines the limitations of
 horizontal (users cannot interact with
 real data) and vertical (users cannot
 move freely through the system)
Scenarios are encapsulated the
 following way
  an individual user
  using a specific set of computer
  to achieve a specific outcome
  user specified circumstances
  over a certain time interval
 Two main uses
   used during the design of a user interface as a
    way of expressing and and understanding the
    way users will eventually interact with the
    future system
   can be used during user evaluation of a user
    interface design to get user feedback without
    the expense of constructing a running
     Two Dimensions of Prototyping
                 Different Features
Scenario                   Horizontal Prototype

Vertical Prototype                 Full System
  Example Scenario - ATM
1. The user approaches the machine
 and inserts a bank card. No matter
 what side is up, the machine reads
 the card correctly
2. The machine asks the user to enter
 a four-digit personal identification
 number, and the user does so using
 the numeric keypad
  Example Scenario - ATM
3. The machine presents the user
 with a menu of four options,
 “withdraw $100”, “withdraw other
 amounts”, “make a deposit”, and
 “other transactions”. There is a
 button next to each of the menu
  Example Scenario - ATM
4. The user presses the button for
 “withdraw $100”, and the machine
 pays out that amount, deducting it
 from the user‟s account. If the user
 has more than one account tied to
 the bank card, the amount is
 deducted from the account with the
 largest balance.
  Example Scenario - ATM
5. The machine returns the bank card
 to the user
  Example Scenario - ATM
This scenario raises some questions;
  is $100 the best amount to have
   available as a single-button choice?
  Is it a good idea to have this accelerated
   option for a pay out at the single push
   of a button, or should the user always
   be asked to specify the amount, in case
   there are several possibilities?
 Good tools in early design stages
   Can be generated and edited before the user
    interface has been fully designed
 Helpful for early participatory design
   users will find it easier to relate to the task-
    oriented nature of the scenarios than to the
    abstract, and often function-oriented, nature of
    system specifications
 Scenarios are also good for testing
 Mockup drawings to supplement narrative
 Elaborate scenarios are sometimes
  produced in the form of “day in the life”
   enactments of users (actors) interacting with a
    simulated system in the course of their daily
   good special effects
   can be shown to users for discussion
 Producing Fast Prototypes
 1. Place less emphasis on the efficiency of
  the implementation
   does not matter how much disk space the
    prototype uses because it will only be used for
    a short period of time
   slow response times for test users may be ok
    (too slow may cause errors!)
      efficiency measures will be invalid
      better for early evaluation than measurement
 Producing Fast Prototypes
2. Accept less reliable or poorer
 quality code
  but try to reduce bugs and crashes
3. Use simplified algorithms that
 cannot handle all the special cases
 (such as leap years)
  normally require a disproportionate
   amount of effort to get right
 Producing Fast Prototypes
4. Use a human expert operating
 behind the scenes to take over
 certain computer operations that will
 be too difficult to program
  wizard of oz
  User interacts normally with the
  Input goes to the “wizard” instead of the
Producing Fast Prototypes
Wizard transforms the user input into
 appropriate format
“listening typewriter”
experience with previously implemented
 systems is helpful in order to place
 realistic bounds on the wizards abilities
 Producing Fast Prototypes
 5. Use a different computer system than
  the eventual target platform
   faster, more advanced computer can be used
    to supports more flexible prototyping tools
 6. Use low fidelity media
   not as elaborate as the final system
   still represent the essential nature of the
      scanned images instead of live video
 Producing Fast Prototypes
7. Use fake data and other content
  prototype of a hypermedia system using
   video can use exiting video material,
   even if it is not an exact match
  ripomatics in the advertising industry
    used to demonstrate concepts to clients
     before they commit to pay for the shooting
     of new footage
 Producing Fast Prototypes
 8. Use paper mock-ups instead of running
  a computer program
   based on printouts of screen designs, dialog
    boxes, pop ups, etc
   drawn using some standard package
   user indicates the action
   human plays the computer
      needs to be an expert in the way the system is going
       to work in order to keep the state of the system in
Producing Fast Prototypes
Can be shown to large audiences on an
 overhead projector
used when computers are not available
 (some conference rooms)
 Producing Fast Prototypes
9. Rely on a completely imaginary
  experimenter describes a possible
   interface to the user orally
  pose a set of “what-if” questions as the
   user steps through an example task
  called “forward scenario simulation”
    more like interviewing and brainstorming
     rather than prototyping
   Combining Techniques
Several techniques could be
 combined to explore different
 aspects of usability of the total
  still images to test the integration of text
   and images to support learning
  live video to test interaction
   mechanisms for controlling the data
   Paper Prototyping Tips
Prototyping is a quick way to
 incorporate direct feedback from real
 users into a design
Bypasses times to create a working
 coded user interface
Paper, scissors, and stickies
Maximum speed and flexibility
    Paper Prototyping Tips
 Everyone on the development team can
  stay closely involved and productive
 Even if you can create a prototype fairly
  quickly in HTML or VB, must consider if
  the right people have the proficiency in
  the tool
 How well can the design team stay
    Paper Prototyping Tips
 Many usability problems come from
  someone on the design team with key
  information not being involved at the right
 With paper, all can gather around the
  same table and contribute
 Changes can also be made on the fly
  without waiting for more development
   Paper Prototyping Tips
Users feel more comfortable being
 critical of paper prototypes because
 it doesn‟t have a polished look
  with a polished prototype users are
   more likely to blame themselves or their
   lack of experience
Remember goal is to measure the
 function and flow of the interface,
 NOT the look
    Paper Prototyping Tips
 After doing several iteration with paper,
  then transfer to a more polished look
 Sometimes the inability to create a fancy
  effect on paper may be a warning that the
  effect is not usable
   example - a rollover
   some designers will use new technologies
    only because it looks cool
   Paper Prototyping Tips
Paper mock ups are intended to
 capture the site‟s functionality, not to
 demonstrate technology
For existing products, create screen
 shots and annotate with stickies,
 whiteout, or other supplies
Screen shots with hand drawn
 annotations is fine
   Paper Prototyping Tips
But be careful to not disrupt the
 entire screen with a hand drawn
 More on Rapid Prototyping
 Rapid Prototyping facilitates iterative
  design and formative evaluation
 Defined as "a form of simple, rapidly
  produced prototyping in which the
  prototype is used to collect information
  about both requirements and the
  adequacy of possible designs..”
 Not developed into the final product
 Traditional techniques push evaluation to
  late in the cycle
 Prototyping involves building a system
  early that simulates the final system
 Rapid prototyping accelerates the
  construction, allowing for multiple
  iterations and more substantial changes
      Artillery approach to rapid
   redesign      Ready

implementation   Fire

and analysis
Prototypes also encourage user
 participation and buy-in
Early evaluation helps solve problem
 of how one tests a design without
 investing a large amount of effort
 into its construction.
 Prototyping as Technique
Prototyping is a technique, not a tool
Effective very early in the process
A process of synthesis, working
 towards the abstract
Provides perspective and insight for
 both developers and interaction
 Dimensions of Prototyping
  How interaction designs are
   represented (e.g. UAN)
  More visual and user-task oriented are
   easier to translate
  Tend to avoid programming language
Dimensions of Prototyping
 The amount of the system included in
  the prototype
 Prototypes that do not include the
  underlying system limit the functionality
  that can be tested, making integration
  more difficult
 As system gets implemented, add to
 When can the prototype be run?
 When compiled as part of the
  implementation, turnaround is slow
 In addition, it may only be available
 Continuously available prototypes are not
  tied to the implementation
 Typically interpreted, they allow fast
  update for quick iteration cycles
 How the prototype transitions to product.
 System usually moves from prototype to
  implementation to final product
 If prototypes are discarded the process is
 If prototypes grow into final product it is
Revolutionary processes useful in
 conjunction with very early
Evolutionary allows code to be re-
 Characterizing Prototypes
Global vs. Local
  A global prototype is representative of
   the whole system. It has breadth, and
   maybe depth.
  A local prototype concentrates on one
  Local prototypes are most useful in
   answering specific questions or
        Local prototyping

Should arc line selection require precise
picking with a mouse?

Should “grab handle” be used to aid arc selection
Local prototyping

    Weighing Prototypes
 Promotes iterative design, leading to
  overall shorter development, better
  products, etc.
 Begins the paradigm shift in the user
      Weighing Prototypes
 Pitfalls
    Might not fit in with established procedures
    May lead to reduction in discipline
    Perception that prototype means project is
    Accuracy in the prototype
    Need to ensure prototype is indeed like final
    Overdesign
  Styles and approaches to
Horizontal Prototyping
   Very broad in number of features, but
   shallow in the implementation of each
Vertical Prototyping
   Few features, but each feature is done
   in detail/depth.
  Styles and approaches to
High Fidelity Prototyping
   Uses media which resembles the final
   interface (ex: using hypercard to
   prototype a computer interface)
  Styles and approaches to
 Low Fidelity Prototyping
   Uses materials further away from the actual
    product interface (ex: using pencil & paper to
    prototype a computer interface).
 Chauffered Prototyping
   A third party walks the user through the
    prototype. This may be used with vertical
    prototyping, when only a select few paths have
    been implemented.
 Styles and approaches to
Wizard of Oz Prototyping
  A third party behind the scenes is
   running things & responding to user
   actions without the user knowing about
   This may be used in conjunction with
   low fidelity prototyping or horizontal
   prototyping (cases where the prototype
   has low executability).
Wizard of Oz Prototyping
 Wizard of OZ - Advantages
 Allows users to help design an
 interface even when they themselves
 are very good designers
Elicit knowledge from experts that
 later may be incorporated into the
Find out how people are likely to
 interact with a system
    Wizard of Oz - Issues

The actual response of the system
 can be slow as there is now a human
 in the loop.
   Allowing the wizard to observe the
   subject and to second guess the user's
  Have prepared responses that can be at
  Wizard of Oz - Issues
More than one wizard (assuming that
 the wizards don't discuss much)
Warning the user that it is an
 experimental system and can be a bit
 slow at times
     Wizard of Oz - Issues
 Setting up a Wizard of Oz experiment can
  be difficult, especially on some platforms
  where it would be difficult to hide the
 Some time must spent training the wizard,
  ensuring that he/she
   is consistent, responds quickly
   responds effectively to the users inputs
   limits the chances that they are unmasked
        Prototype Content
 Early Prototypes
   Testing conceptual model, broader scope
   Accuracy to final product can be lower
   Should provide depth on most common user
 Late Prototypes
   Accuracy to final product is more more critical
   More detail oriented
  Rapid Prototyping Tools
  Tools not required by useful for dealing
   with complexity
  Also good for configuration
  Aid in the fast iterative cycle
   Rapid Prototyping Tools
 Desired Features
   Easy to develop and modify screens
   Supports the type of interface you are
   Supports a variety of I/O devices
   Easy to link screens and modify links
   Allows calling external procedures and
   Allows importing of text, graphics, etc
   Easy to learn and use
   Good support from the vendor
Low-fidelity Prototyping

       James Landay
       Cal Berkeley
UI Design Cycle



           Rapid Prototyping
 Build a mock-up of design
 Low fidelity techniques
    –   paper sketches
    –   cut, copy, paste
    –   video segments
   Interactive prototyping tools
    –   Visual Basic, HyperCard, Director, etc.
   UI builders
    –   NeXT
       The Model Human
                       Working Memory
        Visual Image

        ?                    ?          ?

                        Fingers, etc.
        The Model Human
                          Long-term Memory
                           Working Memory
           Visual Image     Auditory Image
              Store             Store

       Perceptual             Motor          Cognitive
       Processor             Processor       Processor

                            Fingers, etc.
             MHP Basics
 Based on empirical data
 Three interacting subsystems
   perceptual, motor, cognitive
 Sometimes serial, sometimes parallel
 Parameters
   processors have cycle time (T)
   memories have capacity, decay time, and type
 Ten principles of operation
      Why We Prototype
Get feedback on our design faster
  saves money
Experiment with alternative designs
Fix problems before code is written
Keep the design centered on the user
    Fidelity in Prototyping
Fidelity refers to the level of detail
High fidelity
  prototypes look like the final product
Low fidelity
  artists renditions with
  many details missing
Why Use Low-fi Prototypes?
 Traditional methods take too long
   sketches -> prototype -> evaluate -> iterate
 Can simulate the prototype
   sketches -> evaluate -> iterate
   sketches act as prototypes
      designer “plays computer”
      other design team members observe & record
 Kindergarten implementation skills
   allows non-programmers to participate
     Hi-fi Prototypes Warp
 Perceptions of the tester/reviewer
   formal representation indicates “finished”
      comments on color, fonts, and alignment
 Time
   encourage precision
      specifying details takes more time
 Creativity
   lose track of the big picture
      The Basic Materials
Large, heavy, white paper (11 x 17)
5x8 in. index cards
Tape, stick glue, correction tape
Pens & markers (many colors &
Overhead transparencies
Scissors, X-acto knives, etc.
   Constructing the Model
 Set a deadline
   don‟t think too long - build it!
 Draw a window frame on large paper
 Put different screen regions on cards
   anything that moves, changes,
 Ready response for any user action
   e.g., have those pull-down menus already made
 Use photocopier to make many versions
      Preparing for a Test
 Select your users
   understand background of intended users
   use a questionnaire to get the people you need
   don‟t use friends or family
      I think customers are OK (Rettig disagrees)
 Prepare scenarios
   describe the product during actual use
   make prototype support these (small, yet
 Practice to avoid “bugs”
       Conducting a Test

 Four testers
   greeter - puts users at ease & gets data
   facilitator - only team member who speaks
      gives instructions & encourages thoughts, opinions
   computer - knows application logic & controls
      always simulates the response, w/o explanation
       Conducting a Test
  observers - take notes and
Typically session is 1 hour
  preparation, the test, debriefing
  Conduction a Test (cont.)

 Greet
   get forms filled, assure confidentiality, etc.
 Test
   facilitator hands written tasks to the user
      must be clear & detailed
      “What are you thinking right now?”, “Think aloud”
   observe -> no “a-ha”, laugh, gape, etc.
 Conduction a Test (cont.)
  ask questions, gather impressions, give
      Evaluating Results
Sort & prioritize observations
  what was important?
  lots of problems in the same area?
Create a written report on findings
  gives agenda for meeting on design
Make changes & iterate
     Advantages of Low-fi
Take only a few hours
  no expensive equipment needed
Can test multiple alternatives
  fast iterations
    number of iterations is tied to final quality
Almost all interaction can be faked
   Wizard of Oz Technique
 Faking the interaction
   from the film “The Wizard of OZ”
      “the man behind the curtain”
 Long tradition in computer industry
   prototype of a PC w/ a VAX behind the curtain
 Much more important for hard to
  implement features
   Speech & handwriting recognition
     The Note Transcriber
low fidelity prototyping works well
I hope my chi paper gets in
I‟m very tired today
Love James
Informal Uis for Early Stage
         UI Design
  put designs in a tangible form
  consider different ideas rapidly
Incomplete designs
  do not need to cover all cases
  illustrate important examples
Present several designs to client
       Goal of Research
Allow designers to
  quickly sketch interface ideas
  test these ideas with users
  transform to a more finished design
   without reprogramming
Quickly Sketch this...
Add Behavior...
Transform it to this...
Drawbacks of Current Tools
 Require specification of lots of detail
   must give specific instance of a general idea
      e.g., exact widgets, fonts, alignments, colors
   designers led to focus on unimportant details
   evaluators focus on wrong issues
 Take too much time to use
   poor support for iterative design
      sketched interface took 5 times longer with
       traditional tool (no icons)
          Paper Sketches
 Advantages
   support brainstorming
   do not require specification of details
   designers feel comfortable sketching
 Drawbacks
   do not evolve easily
   lack support for “design memory”
   force manual translation to electronic format
   do not allow end-user interaction

To top