1. 1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Prototyping

2. 2 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Software Prototyping Animating and demonstrating system requirements

3. 3 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

4. 4 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Types of prototypes

5. 5 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Continuum of understanding user’s needs Well knownFuzzyUnknown Fuzzy needs become more understood Yes, but… responses from the user – unknown needs become known

6. 6 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

7. 7 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

8. 8 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

9. 9 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Prototyping process

10. 10 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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.

11. 11 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

12. 12 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Approaches to prototyping

13. 13 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

14. 14 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Evolutionary prototyping

15. 15 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

16. 16 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

17. 17 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Throw-away prototyping

18. 18 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

19. 19 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

20. 20 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Incremental development process

21. 21 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

22. 22 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Reusable component composition

23. 23 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

24. 24 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

25. 25 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Prototyping Pitfalls Applicability –application domain has an impact on selecting a prototyping technique —i.e. need real-time support features for a process control system –techniques for specific application domains —business —computer aided design —distributed —flight control —user interface —software engineering environments

26. 26 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

27. 27 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

28. 28 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

29. 29 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

30. 30 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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)

31. 31 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

32. 32 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Vertical Prototyping –Under realistic circumstances –with real user tasks —actually accessing a DB with some real data

33. 33 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Two Dimensions of Prototyping Different Features Functionality Vertical Prototype Full System ScenarioHorizontal Prototype

34. 34 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

35. 35 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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”

36. 36 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Two Dimensions of Prototyping Different Features Functionality Vertical Prototype Full System ScenarioHorizontal Prototype

37. 37 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

38. 38 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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)

39. 39 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

40. 40 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

41. 41 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Two Dimensions of Prototyping Different Features Functionality Vertical Prototype Full System ScenarioHorizontal Prototype

42. 42 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

43. 43 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

44. 44 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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.

45. 45 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Example Scenario - ATM 5. The machine returns the bank card to the user

46. 46 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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?

47. 47 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

48. 48 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

49. 49 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

50. 50 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

51. 51 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

52. 52 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

53. 53 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

54. 54 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

55. 55 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

56. 56 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Producing Fast Prototypes –Can be shown to large audiences on an overhead projector –used when computers are not available (some conference rooms)

57. 57 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

58. 58 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

59. 59 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

60. 60 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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?

61. 61 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

62. 62 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

63. 63 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

64. 64 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

65. 65 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Paper Prototyping Tips But be careful to not disrupt the entire screen with a hand drawn annotation

66. 66 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

67. 67 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Rapid prototyping 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

68. 68 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Artillery approach to rapid prototyping Ready Fire Aim design/ redesign prototyping/ implementation evaluation and analysis

69. 69 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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.

70. 70 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

71. 71 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

72. 72 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

73. 73 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

74. 74 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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.

75. 75 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Maturation Revolutionary processes useful in conjunction with very early prototyping Evolutionary allows code to be re-used

76. 76 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

77. 77 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Local prototyping Should arc line selection require precise picking with a mouse? Should “grab handle” be used to aid arc selection

78. 78 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Local prototyping OR

79. 79 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Weighing Prototypes Advantages –Promotes iterative design, leading to overall shorter development, better products, etc. –Begins the paradigm shift in the user

80. 80 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

81. 81 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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).

82. 82 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

83. 83 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering

84. 84 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Quickly Sketch this...

85. 85 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Add Behavior...

86. 86 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Transform it to this...