Narrowing the Specification- Implementation Gap in Scenario- Based Design. A Survey on the Paper from Mary Beth Rosson and John M.

Transcription

1 Narrowing the Specification- Implementation Gap in Scenario- Based Design A Survey on the Paper from Mary Beth Rosson and John M. Carroll

2 Overview Presentation of the Paper What s the problem? How was this done the classic way? The ideas and propositions in the paper Critical Review Deficiencies of the Paper Problem #1: The Development Process Problem #2: The Decision Process

3 The Problem Domain User Software Engineer Design a software with an easy-to-use user interface and all needed features

4 Where s the Gap? User Do things What, not how Software Engineer Implement things How, not what

5 The Classic Way of Requirements Analysis User model transformation Individual Features Specific Functions Wishes, Ideas etc Model for Implementation model transformation Software Engineer

6 Drawbacks of the Classic Way Voluminous Specification Documents Large Communication Overhead Long Feature Development Cycle To avoid overhead Make designers and software engineers work on common data sets

7 The New Way of Requirements Analysis User Shared Model Software Engineer

8 Requirements Analysis (Rosson, Carroll) User Scenario Implemenation Scenario User Share Software Engineer Common Scenario Interleave analysis, design and implementation

9 User Scenarios Use claims to model pros and cons of design decisions System Specification Narrative description of a task from user s point of view and experience

10 Narrative User Scenarios I want to be reminded that I have to meet with a certain person sometime tomorrow. I schedule a new meeting in my organizer. I don t remember when I have time for the meeting tomorrow, so I let the organizer choose an appropiate time. I m not sure how to name the meeting Using the menu from the default browsing screen, I select New Meeting. A dialog pops up and I fill in the person with which I ll meet. I click on the button Choose a time for me

11 Good User Scenarios Analysis of existing practices By using categories (Rossen, Carroll) Orienting to goals Opportunistic interaction Searching for information Carrying out procedures Making sense Reflection on skills

12 Claims System Offering a feature to find calendar holidays might come in handy for the user but is not easy to implement impossible to do for certain holidays that can t be calculated

13 Claims System Offering a feature to find calendar holidays might come in handy for the user but is not easy to implement impossible to do for certain holidays that can t be calculated Regarding each single holiday occurence as an object might help to better organize reminders but might confuse some users seriously introduces significant overhead to the database

14 The Iterative Way of Requirements Analysis Usability Claims User Scenario Implemenation Scenario Software Claims

15 The Scenario Browser Scenario View Claims View Implementation View task first approach

16 The Scenario Browser B C A A B Task Scenario A B C A Software Claim SmallTalk Class

17 Scenario Benefits (as stated by the authors) Minimizes the gap between specification and implementation Avoids mismatches between user/engineer view Provides a rich view of goals, actions and experiences of users Good concepts for extending and redesigning existing systems

18 Overview Presentation of the Paper What s the problem? How was this done the classic way? The ideas and propositions in the paper Critical Review Deficiencies of the Paper Problem #1: The Development Process Problem #2: The Decision Process

19 Deficiencies of the Paper Focuses too much on the concrete SmallTalk implementation instead of describing the ideas in a more general way. Many of the described functions and advantages can t be understood from paper s description. One must probably have the described SmallTalk implemenation to really do so. Gives no feedback from individual users or engineers who actually worked with this system. It would be crucial to know these people s experiences and problems with this way of designing. Has a rather confusing structure. The authors tend to tell the reader the same thing again and again.

20 Problem #1 The Decision Process

21 Problem #1 The Decision Process Anne Dave Tim I like feature A, but I hate feature B. By the way, what is feature B? Let s assume we had feature A, then you could implement feature B, which would be really cool, man. I would like it better if the sun would orbit around the earth. Your product is very confusing, since you assume it the other way round.

22 Problem #1 The Decision Process Dave System Tim Anne Number of people making design decisions is probably large Communication between users on design topics is probably poor User s decisions are probably not always well deliberated

23 Problem #1 The Decision Process The paper s approach might easily end up in Lack of coordination between users design decisions Lack of consistent product goals Risk of large amounts of features which are basically the same or overlap in their functions (inefficient interface design) Product will be harder to use for a new user

24 Problem #1 The Decision Process Anne Dave Tim Carol Chuck Susan Filter the ideas (what s useful for all users, what s too special, deliberate pros and cons) Find abstract goals and generalize the ideas, try to make things consistent

25 Problem #1 The Decision Process Developers Users The number of people making design decisions is small Leads to a deliberated feature evaluation Makes the product consistent and easy to use by focusing on relatively few abstract goals and ideas Avoids to spoil the product with unnecessary features

26 Problem #2 The Development Process

27 Problem #2 The Development Process Direct User Influences Product Development Process Horizon of Goals and Expectations of the Development Team

28 Problem #2 The Development Process Risk of chaotic development process, since there s probably no consistent idea or plan, everybody pulls at another edge of the cake in another direction. Unnecessary reimplementations and redesigns, which is highly inefficient and a waste of efforts. Inefficient implemenation, since users will probably force introducing features that the system wasn t build for. Frustrating for users, who will see the product get unusable, and for developers who will lose the control over the software.

29 Problem #2 The Development Process Typical Topics for the Engineer A good idea of product s real world use Goals for further evolution of the product Rationale for current and future feature set Decisions on Implementation Which Database Model to Use How Complex and Flexible to Design the Underlying Architecture How Efficient to Use System Resources

30 Problem #2 The Development Process Indirect User Influences Product Development Process Horizon of Goals and Expectations of the Development Team

31 Problem #2 The Development Process Give software claims a definitely higher priority than usability claims Just a new formalisation of the classic design process

32 Scenario Problems In practice, the scenarios database will only be another form of documentation but will not automatically lead to senseful decisions. The actual process of building a good design is much more effort than with the classic way of engineering. The actual decision process is only shifted but not interleaved, as stated by the authors.

33 Summary Good tool for larger projects in. which a limited number of well-chosen designers (engineers and users) control the claims. It will definitely not work, if all users have access to this system. It may give managers a good feeling to introduce a framework which seems to guarantee objective decision making, but it s once again only as good as the contributors who build the system. The process of human decision making can t be automated or raised to an absolutely objective level. Every system in this area is just a tool and can only be as good as the people who use it.