Requirements Engineering Southern Methodist University CSE 7316.

Requirements Engineering Southern Methodist University CSE 7316

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

Describing Requirements

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

Introduction  However  Ambiguous  Opaque  Misunderstood  But everyone can read natural language

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 backgrounds  Do not assume knowledge/background  This is hard! Allow time to get it right

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  Inputs  Processing  Outputs  Include fields to support the requirement  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 readers  Same acronyms may have different meanings  ATM (banking system and transfer mode)

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

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

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

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 impersonally  Difficult to change a personal style

Language use  10. Do not try to express complex relationships in a natural language description  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 grammar  Poor spelling and grammar can obscure your meaning  Spelling checkers should always be used

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

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

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 requirements  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 used

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

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

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 diagrams  Keep them as simple as possible  Simple labeled boxes and lines to show structure and relationships  Should fit onto a single page  No connectors to other pages  Should always be labeled with a figure number and title

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

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

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

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

Supplement natural language with other descriptions  5. Timing diagrams to illustrate time critical system actions  6. System models such as object models, ER models, FSMs are helpful where you need to describe detailed system requirements

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

Specify requirements quantitatively System attributeMetric which can be used ReliabilityMean time to failure ReliabilityRate of occurrence of failure AvailabilityProbability of failure on demand PerformanceResponse time to user input

Specify requirements quantitatively System attributeMetric which can be used PerformanceNumber of transactions processed per second Store utilizationMaximum size of system in Kbytes UsabilityTime taken to learn 75% of user facilities

Specify requirements quantitatively System attributeMetric which can be used UsabilityAverage number of errors made by users in a given time period RobustnessTime to re-start the system after failure IntegrityMaximum permitted data loss after system failure

The map is not the territory

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

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

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

Example  “They use the system to borrow books” – deletion  Challenge; Who specifically uses the system to borrow books? All users of the system or just some?  Response; Some users just use the system for stock control.

Example  “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?

Example  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.

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

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 understandability  try to be precise, but generous about syntactic details.

Structured English and requirements specification  Example: Consider the following statement (same as in example for decision tree)

Rewritten in Structured English

Informal use of High Level Languages (HLL)  Basic idea  relax strictness of syntactic rules  add systematic commenting procedures  Typical constructs required  structured description of abstract data items (simple and compound types)  external description of routines (procedures, functions)  encapsulation (modules)

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)  Advantages  clear and unambiguous  "ideal" for communication with programmers  potential for automation of analysis and validation

Informal use of High Level Languages (HLL)  Disadvantages  more difficult to communicate with the user  forms prejudice for design and implementation  more difficult to keep requirements apart from design.

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

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

Form-based node specification

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 example package Print_server is procedure Initialize (P: PRINTER) ; procedure Print (P: PRINTER ; F: PRINT_FILE ) ; procedure Display_print_queue (P: PRINTER ) ; procedure Cancel_print_job (P: PRINTER; N: PRINT_ID) ; procedure Switch_printer (P1, P2: PRINTER; N: PRINT_ID) ; end Print_server ;

Data interface example type MESSAGE is record Sender : SYSTEM_ID; Receiver : SYSTEM_ID; Dispatch_time : DATE; Length: MESSAGE_LENGTH ; Terminator: CHARACTER ; Message : TEXT; end record; type SYSTEM_ID is range 20_000..30_000 ; type YEAR_TYPE is range 1980..2080 ; type DATE is record Seconds: NATURAL ; Year: YEAR_TYPE ; end record ; type MESSAGE_LENGTH is range 0..10_000 ; type TEXT is array (MESSAGE_LENGTH) of CHARACTER ;

Size representation for SYSTEM_ID’SIZE use 2*BYTE ; for YEAR_TYPE’SIZE use 2*BYTE ; for MESSAGE_LENGTH’SIZE use 2*BYTE ;

Representation interface example type STATE is (Halted, Waiting, Ready, Running); for STATE use (Halted => 1, Waiting => 4, Ready => 16, Running => 256);

Pseudocode

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

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

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

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 covered

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 Has emergency sequence occurred? Do nothing Is remote Notification Enabled? Is local Alarm Enabled? Activate siren Do nothing Initiate Emergency message Did Remote Security Respond? Do nothing Activate siren yes no

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

Activity diagram Get req ref from doc Remove req from DB Remove req from doc Get req text from doc [not empty] [empty] [more] [no more]

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 constraints  stimulus-response  response-response  stimulus-stimulus  response-stimulus

Timing Constraints  Stimulus is an action performed by the user or environment on the system  Response is an action by the system on the user or environment

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

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

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

Response-Response  Examples  “The system shall generate a “launch missile” command no sooner than 5 seconds after generating a “start battery warm up” command” (minimum)

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

Stimulus-Stimulus  Examples  “Pilots must not press the “launch weapon” button sooner than 10 seconds after pressing the “fire ready” button” (minimum)

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

Response-Stimulus  Examples  “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 user  warning  error message

Use cases

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

Use case modeling steps  Find the system boundary  Find the actors  Find the use cases  Specify the use case  Create scenarios

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

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

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

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

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 system  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 actor  Use cases are always written from the point of view of an actor PlaceOrder GetStatus OnOrder

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

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

Use case diagram customer PlaceOrder CancelOrder CheckOrder Status Send Catalog Send Catalog Shipping company dispatcher Mail order system actor Communication relationship Use case System name System boundary

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

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

Use case: PayVAT ID: UC1 Actors: Time Government Preconditions: 1. It is the end of a business quarter Flow of events: 1. The use case starts when it is the end of the business quarter 2. The system determines the amount of VAT owed to the government 3. The system sends an electronic payment to the government Postconditions: 1.The government receives the correct Amount of VAT { Use case name { Unique identifier Actors involved in the use case {

Flow of events  The use case starts when an  the  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?  What

When encountering vagueness  Who specifically…..?  What specifically…..?  When specifically…..?  Where specifically…..?

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

Use case: ManageBasket ID: UC10 Actors: customer Preconditions: 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 Postconditions: 1.The basket contents have been updated

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

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 condition  Specify postconditions for the flow of events

Use case: DisplayBasket ID: UC11 Actors: customer Preconditions: 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

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

Repetition within a flow: For  May have to repeat an action several times within a flow of events  Iterates a positive whole number of iterations n. For (iteration expression) n.1 Do something n.2 Do something else n.3 …. n+1

Use case: FindProduct ID: UC12 Actors: customer Preconditions: 1. The customer is logged on to the system Flow of events: 1. The customer selects “find product” 2. The system asks the customer for search criteria 3. The customer enters the required criteria 4. The system searches for products that match the 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

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

Repetition within a flow: While  Use the keyword While to model a sequence of actions in the flow of events that is performed while some boolean condition is true n. While (Boolean condition) n.1 Do something n.2 Do something else n.3 …. n+1

Use case: ShowCompnyDetails ID: UC13 Actors: customer Preconditions: 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 details 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 Postconditions:

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 UC1UC2UC3 R1X R2XX R3X R4X R5X

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

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

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

Use case: CheckOut ID: UC14 Actors: customer Preconditions: 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: InvalidCustomerIdentifier InvalidCreditCardDetails CreditCardLimitExceeded CreditCardExpired Postconditions:

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

Use case: CheckOut Secondary scenario: InvalidCustomerIdentifier ID: UC14 Actors: customer Preconditions: 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 Postconditions:

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

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 voice. 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]

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

More on Use Cases

Architecture of requirements artifacts

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

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 requirements

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

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

Potential change management actors

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 case)

Relationships among use cases  INCLUDES; one use case is included in another use case  Included use case required to complete behavior necessary for the including use case to accomplish its work  No option by the including use case – must perform the actions in the included use case

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

Includes and extends

Change management use case

Use case packages

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

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

Decision elements

Synchronization bars for concurrent tasks

Swim lanes for multiple entities

Writing use cases

Alternative courses

Using storyboards to validate use cases

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

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

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

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

State Transition Diagrams

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

Can I interest you in our new long distance service?

No thanks.

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 event Different response

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

States ON OFF

States ON OFF Press

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

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

FSM Diagram State 1 State 2 Event-1 Action-k

FSM State 1 State 2 Event-1 Action-k Event-1 Not all state transitions have actions associated with them

Scenario Quarters Only, 75 cents  Customer  enter quarter  Customer  enter quarter  Customer  enter quarter  Coke Machine  deliver coke

Enumerate Events & Actions Events: E1:Deposit 25 cents Actions: A1:Deliver coke

Define States A B C Start State E1 E1/A1 States: A:No money B:25 cents entered C:50 cents entered Events: E1:Deposit 25 cents Actions: A1:Deliver coke

State Transition Table

Coke Machine Scenario 2 Coin Return Customer –enter quarter Customer –enter quarter Customer –press coin return (CR) Coke Machine –return coins

Enumerate Events & Actions Events: E1:Deposit 25 cents E2:Coin Return (CR) Actions: A1:Deliver coke A2: Return coins

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

Transition Table  StateE1E2  AB  BCA/coin return  CA/cokeA/coin return

Transition Table l StateE1E2 l AB l BCA/coin return l CA/cokeA/coin return No Blanks Allowed !!

Transition Table StateE1E2 ABA BCA/coin return CA/cokeA/coin return

Telephone System FSM Local 4-digit exchange Events d:digit dialed h:hang up Actions c1:connect to caller

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

Telephone System FSM Local 4-digit exchange ABCDE dddd/c1 h States A:start B:1 digit dialed C:2 digits dialed D:3 digits dialed E:call in progress Events d:digit dialed h:hang up Actions 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 b c b c A C B a b c c A C B D Clustering into new superstate D - really an abstraction. To be in D really means to be in either A or C

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

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

No Money (A) Money Entered

No Money (A) Money Entered 5 10 CR

No Money (A) Money Entered 5 10 CR B 510 C 5

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

sin(x) 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  Ease of development; by decomposing the system into a finite number of states the problem is also decomposed.  Ease of testing  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  Simple to understand; the behavior is easily decomposed into non-overlapping behavior.  Predictable 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

Mealy model - outputs associated with transitions Moore model - outputs associated with states Meely and Moore Models input x/output y input xoutput y

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 function  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 Interface 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) Pressed  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) => EBON(e,f)  “If the elevator button is off (current state) and the button is pressed (event) and the elevator e is not visiting the floor (predicate), then the button is turned on”

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 Rules  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 Rules Conversely, “If the button is on and at least one of the elevators arrives at floor f, and the elevator is about to move in direction d, then the button is turned off”

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 transitions  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 floor)  RL: Request Logged (button pressed)

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 floor”  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 straightforward  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 constraints –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 Machine

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 represented  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  Entities  Attributes  Relationships

What’s in an ERD?  Entities are drawn in boxes  Entities should be expressed in plural  Relationship is a line connecting the entities  Arrows represent different types of relationships  List of attributes developed as you go  Verbs placed on relationship lines that describe relationship

Entities  People, places, things, events, concepts of interest to an organization  Anything the organization needs to store data about  Represented by labeled boxes  Collections of things

Entities AircraftWedding CustomerSale

Entities  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)

Entities  Further described by attributes or data elements  Smallest units of data that can be described in a meaningful manner Employee Employee # Surname Given name Date of birth Telephone # Department

Relationship  Frequently, a meaningful relationship exists between two different types of entity  EMPLOYEE works in a DEPARTMENT  LAWYER advises CLIENTS  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 entity  A ROOF covers one BUILDING  A BUILDING is covered by one ROOF

One-to-One relationships Roof Building Covered by Covers

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

One-to-Many relationships Department Employee Works in has

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 PROJECTS  PROJECT is related to many items of EQUIPMENT

Many-to-Many relationships Equipment Project allocated

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

Hidden Identities Equipment Project allocated Allocated to Allocation Component Component use Hidden entities

Choosing the right relationship  Type of relationship can change  Purpose of the model  Length of time involved  Definition of the entities participating in the relationship  If the definition of a ROOF entity is an apex or flat surface covering a building, then a BUILDING is covered by many ROOFS

Choosing the right relationship  Likewise, over time an EMPLOYEE works in many DEPARTMENTS

Tips on building ERDs  Nouns are clues to the entities of a business  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 entities  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 helpful

Data flow analysis

Data Flow Analysis  DFA used for achieving modules with high cohesion  Usually used with structured system analysis  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 being input

DFD showing flow of data and actions of product

Points of highest abstraction of input and output

 Product decomposed into three modules  input module  transform module  output module  Procedure is continued stepwise (stepwise refinement)  High cohesion and low coupling achieved

DFA Example  Product inputs a file name and returns the number of words in the file  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 sent  Whenever there is conditional data flow, there needs to be corresponding control flow  Two modules with communication cohesion  read and validate filename  format and display word count  must be decomposed further

Structure chart: First refinement

Structure chart: Second refinement

Detailed Design  After architectural design has completed  Data structures chosen  Algorithms selected  Handed off to programmers for implementation  done by teams for time reasons  each module must be understood without having to rely on other modules  Programming language independent

Detailed Design

Program Description Language  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

Extensions  Disadvantages  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 stream

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 systems  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 methods  Simple and intuitive notation that customers can understand  Show end-to-end processing of data

Order processing DFD

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 system  Not a good way to describe system interfaces

Equipment procurement DFD

CASE toolset DFD

Semantic data models  Used to describe the logical structure of data processed by the system  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 relational databases

Notation for semantic data models

Software design semantic model

Prototyping

Agenda  Benefits of prototyping  Evolutionary prototyping  Throw away prototyping  Vertical prototyping  Horizontal prototyping  Scenario prototyping

Software Prototyping Animating and demonstrating system requirements

What is a Prototype?  A prototype is a concrete executable model of selected aspects of a proposed system  Rapid prototyping is the process of quickly building and evaluating a series of prototypes  Usually only a partial representation of the system and serves as an aid in analysis and design

Types of prototypes Project Risk? technology requirements Investment Strategy? Investment Strategy? throwaway evolutionary Breadth of risk narrow broad vertical horizontal

Continuum of understanding user’s needs Well knownFuzzyUnknown 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 system The prototype may be used for user training before a final system is delivered The prototype may be used for back- to-back testing

Prototyping benefits Misunderstandings between software users and developers are exposed Missing services may be detected Confusing services may be identified 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

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 understood.

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 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 system

Evolutionary prototyping

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 maintenance –The system will be poorly structured and difficult to maintain

Throw-away prototyping

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 prototype

Incremental development System is developed and delivered in increments after establishing an overall architecture 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 process

Prototyping with reuse The system is prototyped by ‘gluing’ together existing components Likely to become more widely used as libraries of objects become available Needs a composition language such as a Unix shell language Visual Basic is largely based on this approach

Reusable component composition

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 functionality

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  Applicability  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 Personnel  approach to providing feedback to end users has resulted in a problem related to the behavior of the end user and developers  end users can be biased in interactions with development team based on past experiences

Prototyping Opportunities  Existing investment in maintained systems  prototyping can be used on critical portions of existing software systems  Adding investment in fully exploiting the technology  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 prototyped

Prototyping  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 products  executable programs at the last moment

Prototyping  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 specifications  Main idea behind prototyping is to save time and cost and to develop something that can be used with real users

Prototyping  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 system  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 Functionality Vertical Prototype Full System ScenarioHorizontal Prototype

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 tools  Can be used to assess how well the entire interface “hangs together”

Scenarios  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

Scenarios  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  Scenarios are encapsulated the following way  an individual user  using a specific set of computer facilities  to achieve a specific outcome  user specified circumstances  over a certain time interval

Scenarios  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 prototype

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 options

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?

Scenarios  Good tools in early design stages  Can be generated and edited before the user interface has been fully designed  Helpful for early participatory design exercises  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  Scenarios are also good for testing  Mockup drawings to supplement narrative  Elaborate scenarios are sometimes produced in the form of “day in the life” videotapes  enactments of users (actors) interacting with a simulated system in the course of their daily activities  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 computer  Input goes to the “wizard” instead of the computer

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 interaction  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 mind

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 prototype  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 system  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 involved?

Paper Prototyping Tips  Many usability problems come from someone on the design team with key information not being involved at the right level  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 annotation

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

Introduction  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 prototyping Ready Fire Aim design/ redesign prototyping/ implementation evaluation and analysis

Introduction  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 designers

Dimensions of Prototyping  Representation  How interaction designs are represented (e.g. UAN)  More visual and user-task oriented are easier to translate  Tend to avoid programming language styles

Dimensions of Prototyping  Scope  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 prototype

Executability  When can the prototype be run?  When compiled as part of the implementation, turnaround is slow  In addition, it may only be available intermittently  Continuously available prototypes are not tied to the implementation  Typically interpreted, they allow fast update for quick iteration cycles

Maturation  How the prototype transitions to product.  System usually moves from prototype to implementation to final product  If prototypes are discarded the process is revolutionary.  If prototypes grow into final product it is evolutionary.

Maturation  Revolutionary processes useful in conjunction with very early prototyping  Evolutionary allows code to be reused

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 aspect.  Local prototypes are most useful in answering specific questions or debates

Local prototyping Should arc line selection require precise picking with a mouse? Should “grab handle” be used to aid arc selection

Local prototyping OR

Weighing Prototypes  Advantages  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 finished  Accuracy in the prototype  Need to ensure prototype is indeed like final systems  Overdesign

Styles and approaches to prototyping  Horizontal Prototyping  Very broad in number of features, but shallow in the implementation of each feature.  Vertical Prototyping  Few features, but each feature is done in detail/depth.

Styles and approaches to prototyping  High Fidelity Prototyping  Uses media which resembles the final interface (ex: using hypercard to prototype a computer interface)

Styles and approaches to prototyping  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 prototyping  Wizard of Oz Prototyping  A third party behind the scenes is running things & responding to user actions without the user knowing about him/her  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 system  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 intention  Have prepared responses that can be at issue

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 wizard  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 functions  Late Prototypes  Accuracy to final product is more more critical  More detail oriented

Rapid Prototyping Tools  Motivation  Tools not required by useful for dealing with complexity  Also good for configuration management/history  Aid in the fast iterative cycle

Rapid Prototyping Tools  Desired Features  Easy to develop and modify screens  Supports the type of interface you are developing  Supports a variety of I/O devices  Easy to link screens and modify links  Allows calling external procedures and programs  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 Design Prototype Evaluate

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

The Model Human Processor Working Memory Visual Image Store ? Eyes Ears Fingers, etc. ? ? ? ?

The Model Human Processor Long-term Memory Working Memory Visual Image Store Auditory Image Store Perceptual Processor Cognitive Processor Motor Processor Eyes Ears 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” nature  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 & sizes)  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, appears/disappears  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 broad)  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 it  always simulates the response, w/o explanation

Conducting a Test  observers - take notes and recommendations  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.)  Debrief  ask questions, gather impressions, give thanks

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 changes  Make changes & iterate

Advantages of Low-fi Prototyping  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  Brainstorming  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

Requirements Engineering Southern Methodist University CSE 7316.

Similar presentations

Presentation on theme: "Requirements Engineering Southern Methodist University CSE 7316."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirements Engineering Southern Methodist University CSE 7316.

Similar presentations

Presentation on theme: "Requirements Engineering Southern Methodist University CSE 7316."— Presentation transcript:

Similar presentations

About project

Feedback