1. Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #9 Contextual Design IV

2. Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Announcements Classes have been rescheduled Classes have been rescheduled 11/8 & 11/11: No fall recession, regular classes will be held 11/8 & 11/11: No fall recession, regular classes will be held 11/15: No class 11/15: No class 11/18: Special session: Software Engineering Economics 11/18: Special session: Software Engineering Economics

3. Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: Engineering & Science Library at CMU

4. Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Class The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. Managing the risk of work redesign (ctd.) Managing the risk of work redesign (ctd.) User environment design User environment design Contextual design and requirements engineering Contextual design and requirements engineering Generating solutions Generating solutions Is software engineering really different from other kinds of engineering? Is software engineering really different from other kinds of engineering?

5. Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Recognize the Risks Risk is inevitable Risk is inevitable No change  fall behind, set inefficiencies in concrete No change  fall behind, set inefficiencies in concrete Large change  will new process really work? Large change  will new process really work? Risk/reward tradeoff Risk/reward tradeoff Reward Risk Breakeven The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

6. Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Reducing the Risk -- Collect More Data First, make sure you use all the data you have First, make sure you use all the data you have Triangulation Triangulation External reviewers who do similar work External reviewers who do similar work Identify what parts of work have changed most Identify what parts of work have changed most Identify assumptions in the new design, e.g., Identify assumptions in the new design, e.g., Will the new flow work? Will the new flow work? Parts of artifacts that aren ’ t needed? Parts of artifacts that aren ’ t needed? Think about “ political ” implications Think about “ political ” implications Who will be more important? Less important? Who will be more important? Less important? Collect more data to test your assumptions and interpretations Collect more data to test your assumptions and interpretations The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

7. Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Reducing the Risk -- Feedback on Vision Get reactions from people who do the jobs Get reactions from people who do the jobs Get reactions from managers Get reactions from managers Use storyboards, prototypes for feedback Use storyboards, prototypes for feedback Small investment, large harvest of information Small investment, large harvest of information The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

8. Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Reducing the Risk -- Is Management Prepared? Do they understand the training and documentation costs? Do they understand the training and documentation costs? Are they prepared to migrate to the new system? Are they prepared to migrate to the new system? Can the old system function in parallel for a while as backup? Can the old system function in parallel for a while as backup? Can the new system be introduced gradually? Can the new system be introduced gradually? Does management understand and accept the risks? Does management understand and accept the risks? The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

9. Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Leap from Data to Design Move from describing work to creating a solution Move from describing work to creating a solution Begins with vision Begins with vision How to do it? How to do it? Review all data... Review all data... Then what? Then what? Involves creativity, skill, experience, judgment Involves creativity, skill, experience, judgment The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

10. Fall 2005 10 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University What is a Good System Design? The source of the pictures: http://www.peterme.com/archives/000073.html

11. Fall 2005 11 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University A Coherent System Design The source of the pictures: http://www.peterme.com/archives/000073.html

12. Fall 2005 12 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University User Environment Design Software “ floorplan ” Software “ floorplan ” Functions that “ belong together ” Functions that “ belong together ” Role Role Task Task Helps resist tendency to jump into UI details too early Helps resist tendency to jump into UI details too early Helps to partition the work Helps to partition the work Pulls vision storyboards together in a single structure Pulls vision storyboards together in a single structure Sets the stage for use cases Sets the stage for use cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

13. Fall 2005 13 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Contextual Design and Requirements Engineering Software Development Group Procurers Hardware Engineering Technical Support Management Systems Engineering Marketing Users Legal Department Business requirements, project parameters, request changes High-level requirements, request changes Assists users, provide input from bug reports, feature requests User requirements quality attributes Licensing tools and components Hardware interfaces Allocate system requirements to software, request changes Business, functional, performance needs, request changes After Karl Wiegers, Software Requirements, p. 59 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University IEEE-STD-830-1998 IEEE Recommended Practice for Software Requirements Specifications Table of Contents Table of Contents 1. Introduction 1. Introduction 1.1 Purpose 1.1 Purpose 1.2 Scope 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.4 References 1.5 Overview 1.5 Overview 2. Overall description 2. Overall description 2.1 Product perspective 2.1 Product perspective 2.2 Product functions 2.2 Product functions 2.3 User characteristics 2.3 User characteristics 2.4 Constraints 2.4 Constraints 2.5 Assumptions and dependencies 2.5 Assumptions and dependencies 3. Specific requirements 3. Specific requirements Appendixes Appendixes Index Index The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

15. Fall 2005 15 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University A.3 Template of SRS Section 3 organized by user class 3. Specific requirements 3. Specific requirements 3.1 External interface requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2 Functional requirements 3.2.1 User class 1 3.2.1 User class 1 3.2.1.1 Functional requirement 1.1 3.2.1.1 Functional requirement 1.1 … 3.2.1.n Functional requirement 1.n 3.2.1.n Functional requirement 1.n 3.2.2 User class 2 3.2.2 User class 2...... 3.2.m User class m 3.2.m User class m 3.2.m.1 Functional requirement m.1 3.2.m.1 Functional requirement m.1 … 3.2.m.n Functional requirement m.n 3.2.m.n Functional requirement m.n 3.3 Performance requirements 3.3 Performance requirements 3.4 Design constraints 3.4 Design constraints 3.5 Software system attributes 3.5 Software system attributes 3.6 Other requirements 3.6 Other requirements The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

16. Fall 2005 16 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University A.5 Template of SRS Section 3 organized by feature 3. Specific requirements 3. Specific requirements 3.1 External interface requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.1.4 Communications interfaces 3.2 System features 3.2 System features 3.2.1 System Feature 1 3.2.1 System Feature 1 3.2.1.1 Introduction/Purpose of feature 3.2.1.1 Introduction/Purpose of feature 3.2.1.2 Stimulus/Response sequence 3.2.1.2 Stimulus/Response sequence 3.2.1.3 Associated functional requirements 3.2.1.3 Associated functional requirements 3.2.1.3.1 Functional requirement 1 3.2.1.3.1 Functional requirement 1 … 3.2.1.3.n Functional requirement n 3.2.1.3.n Functional requirement n 3.2.2 System feature 2 3.2.2 System feature 2...... 3.2.m System feature m 3.2.m System feature m...... 3.3 Performance requirements 3.3 Performance requirements 3.4 Design constraints 3.4 Design constraints 3.5 Software system attributes 3.5 Software system attributes 3.6 Other requirements 3.6 Other requirements The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

17. Fall 2005 17 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Requirements Issues and CD: Ambiguity “ The product shall provide status messages at regular intervals not less than every 60 seconds. ” “ The product shall provide status messages at regular intervals not less than every 60 seconds. ” Issues? Issues? What are the messages? What are the messages? Is 60 seconds important, i.e., is 1 second bad? Is 60 seconds important, i.e., is 1 second bad? How long should status message remain visible? How long should status message remain visible? What status attributes should be displayed? What status attributes should be displayed? What happens when the task is completed? What happens when the task is completed? What happens if the task stalls? What happens if the task stalls? Does CD help avoid or resolve ambiguity? Does CD help avoid or resolve ambiguity? If so, how? If so, how? The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

18. Fall 2005 18 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Requirements Issues and CD: Volatility Fluctuating requirements is nearly universally agreed to be one of the biggest problems in large-scale software development. Fluctuating requirements is nearly universally agreed to be one of the biggest problems in large-scale software development. Does CD help? Does CD help? Focuses on avoiding big changes Focuses on avoiding big changes Does little to help manage changes Does little to help manage changes The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

19. Fall 2005 19 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Generate-and-Test Very general problem-solving strategy Very general problem-solving strategy If impossible to generate solution immediately: If impossible to generate solution immediately: Generate a space where solution must (or at least may) reside Generate a space where solution must (or at least may) reside Everything up through vision Everything up through vision Search Search Storyboards, UED Storyboards, UED Evaluate the possible solutions encountered Evaluate the possible solutions encountered Prototyping Prototyping How to do better... How to do better... Tune the generator Tune the generator Search more intelligently Search more intelligently Test more precisely and/or efficiently Test more precisely and/or efficiently The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

20. Fall 2005 20 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Distribution of Effort GenerateSearchEvaluate Traditional Requirements Methods Contextual Design The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

21. Fall 2005 21 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Trend 1: More Effort Earlier in Process GenerateSearchEvaluate Traditional Requirements Methods Contextual Design The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

22. Fall 2005 22 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Trend 2: Shorter Iterations GenerateSearchEvaluate Traditional Requirements Methods Contextual Design Waterfall The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

23. Fall 2005 23 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University From Barry Boehm, USC, Spiral Experience Workshop

24. Fall 2005 24 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Contextual Design and Agile Methods Agile (e.g., XP) also focuses on user needs Agile (e.g., XP) also focuses on user needs Users participate on design team Users participate on design team User stories User stories Staged deliveries, short cycles Staged deliveries, short cycles Contextual design Contextual design Data collection Data collection Work modeling Work modeling Staged deliveries based on UED Staged deliveries based on UED Emphasis on user feedback from prototypes Emphasis on user feedback from prototypes The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

25. Fall 2005 25 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Is Software Engineering Really Different? Is engineering software different from engineering hardware, bridges, buildings? Is engineering software different from engineering hardware, bridges, buildings? No, of course not! No, of course not! Routine design, innovative design Routine design, innovative design Moving the work from innovative to routine Moving the work from innovative to routine Building up things like architectural styles, patterns, problem frames Building up things like architectural styles, patterns, problem frames Recognized types of problems Recognized types of problems Known characteristics Known characteristics Overconstrained problems -- tradeoffs Overconstrained problems -- tradeoffs Yes, of course! Yes, of course! Brooks: the software must conform! Brooks: the software must conform! Intimate relation with people, institutions, things Intimate relation with people, institutions, things “ Code is Law ” - Lawrence Lessig “ Code is Law ” - Lawrence Lessig The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

26. Fall 2005 26 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??