Heim, Chapters 4.3 - 4.4 and Dix et al, Chapter 15 Lecture 3 Modeling and Documenting Requirements.

Slides:



Advertisements
Similar presentations
Information technology solutions development Fundamentals of Information Technology Session 3.
Advertisements

Task Analysis Material from Authors of Human Computer Interaction Alan Dix, et al.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Chapter 16 dialogue notations and design. Dialogue Notations and Design Dialogue Notations –Diagrammatic state transition networks, JSD diagrams, flow.
1 CS2341 Lecture 5: Task Analysis Robert Stevens
Systems Analysis and Design in a Changing World, Fourth Edition
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Requirements Analysis 8. 1 Storyboarding b508.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Human.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Documenting Requirements using Use Case Diagrams
Task Analysis Analyzing and representing the activities of your users.
Analysis Concepts and Principles
Requirements Gathering and Task analysis. Requirements gathering and task analysis 4 Requirements gathering is a central part of systems development understanding.
Task Analysis (TA). 2 TA & GOMS Both members of the same family of analysis techniques. TA covers a wide area of study. Actual distinction between TA,
6 Systems Analysis and Design in a Changing World, Fourth Edition.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Chapter 7: The Object-Oriented Approach to Requirements
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
USE Case Model.
Software Engineering 8. System Models.
Lecture Outline 11 The Development of Information Systems Chapter 8 page 390+
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
CISB213 Human Computer Interaction Understanding Task Analysis 1.
COMPSCI 345 S1 C and SOFTENG 350 S1 C Discovery: Interpretation and Documentation Lecture 20 Lecturer: Jim Warren Based on Heim Chapter
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
ITEC224 Database Programming
Gary MarsdenSlide 1University of Cape Town Human-Computer Interaction - 5 Requirements Gary Marsden ( ) July 2002.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Interpretation Documentation Heim, Chapters and Dix et al, Chapter.
Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Systems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, 6th Edition
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
1 chapter 16 dialogue notations and design (pt 1).
Dialogue notation focus on STNs extract from chap 8 slides for Human Computer Interaction
Understanding Task Analysis
Task analysis Chapter 5. By the end of this chapter you should be able to... Describe HTA and its features Explain the purpose of task analysis and modelling.
Task Analysis TECM 4250 Dr. Lam. What is Task Analysis? Task analysis is typically a method used in usability testing and user-centered design for the.
Systems Analysis and Design in a Changing World, Fourth Edition
COMPSCI 345 S1 C and SoftEng 350 S1 C Discovery: Interpretation and Documentation Lecture 7 Chapter (Heim)
Task Analysis Lecture # 8 Gabriel Spitz 1. Key Points  Task Analysis is a critical element of UI Design  It specifies what functions the user will need.
DISCOVERY Textbook: S. Heim, The Resonant Interface: HCI Foundations for Interaction Design [Chapter 4, continued] Addison-Wesley, 2007 March 9, 2011 CS.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
UML Activity and Sequence Diagrams David Millard
Pepper modifying Sommerville's Book slides
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 5 System modeling
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Unified Modeling Language
EKT 421 SOFTWARE ENGINEERING
The Development of Information Systems Chapter 8 page 348+
COMP444 Human Computer Interaction Understanding Task Analysis
“In the midst of chaos, there is also opportunity” - Sun Tzu
task analysis focus on HTA
Dialogue Notations and Design
Human Computer Interaction Universitas Gunadarma
“In the midst of chaos, there is also opportunity” - Sun Tzu
Presentation transcript:

Heim, Chapters and Dix et al, Chapter 15 Lecture 3 Modeling and Documenting Requirements

1-2 Modeling and documenting By the end of this lecture you will be able to describe each of the following. 1.Task Analysis –Hierarchical task analysis (HTA) –State transition networks (STNs) Assignment 1 Requirement 2.Storyboarding 3.Use Cases

1-3 Interpretation - Task Analysis Task analysis is a way of documenting how people perform tasks A task analysis includes all aspects of the work flow It is used to explore the requirements of the proposed system and structure the results of the data collection phase or document an existing system

1-4 Interpretation - Task Analysis Hierarchical task analysis (HTA) –HTA provides a top-down, structured approach to documenting processes. State transition network (STN) –Provides a description what actions/events are available at what point and what state the system will be in after each action

HTA decomposition elements Goal – top-level goal of the task being analysed Plans – the order and conditions for proceeding with the sub-tasks Information – all the information needed to undertake the task Objects – all the physical objects involved Methods – the various ways of doing the sub- tasks 1-5

6 Textual HTA description (from Dix et al.) Note this section of Dix is on the Piazza pages for the course Hierarchy description in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 3.1. clean the hall 3.2. clean the living rooms 3.3. clean the bedrooms 4. empty the dust bag 5. put vacuum cleaner and attachments away... and plans Plan 0: do in that order. when the dust bag gets full do 4 Plan 3: do any of 3.1, 3.2 or 3.3 in any order depending on which rooms need cleaning N.B. only the plans denote order or selection (ifs)

7 Diagrammatic HTA (from Dix et al.) Note this section of Dix is on Piazza

8 Refined HTA for making tea

9 Types of plan fixed sequence then 1.2 then 1.3 optional tasks - if the pot is full 2 wait for events - when kettle boils 1.4 cycles - do while there are still empty cups time-sharing - do 1; at the same time... discretionary - do any of 3.1, 3.2 or 3.3 in any order mixtures - most plans involve several of the above

Diagram Notation 1-10 Element to be decomposed Bottom of the hierarchy denoted by underline Plans sits beside vertical Numbering 1 – 1.1 – …. Different style of plan Notice – no vertical line here

State transition networks (STN) circles - states arcs - actions/events

State transition networks - events arc labels a bit cramped because: –notation is ‘state heavy’ –the events require most detail

State transition networks - states labels in circles a bit uninformative: –Sometimes states are hard to name (but do try) –but easier to visualise

Hierarchical STNs managing complex dialogues named sub-dialogues Graphics Submenu Text Submenu Paint Submenu Main Menu select ‘graphics’ select ‘paint’ select ‘text’

Concurrent dialogues - I simple dialogue box Text Style bold italic underline example

Concurrent dialogues - II three toggles - individual STNs bolditalicunderline NO bold click on ‘bold’ NO italic click on ‘italic’ NO u’line click on ‘underline’

Concurrent dialogues - III bold and italic combined Text Style bold italic underline example NO style bold only click on ‘bold’ click on ‘italic’ italic only bold italic click on ‘bold’ click on ‘italic’

Concurrent dialogues - IV all together - combinatorial explosion ‘italic’ NO style bold only ‘bold’ italic only bold italic ‘bold’ ‘italic’ u’line only bold u’line ‘bold’ italic u’line bold italic u’line ‘bold’ ‘italic’ ‘underline’ Text Style bold italic underline example

escapes ‘back’ in web, escape/cancel keys –similar behaviour everywhere –end up with spaghetti of identical behaviours try to avoid this e.g. on high level diagram ‘normal’ exit for each submenu plus separate escape arc active ‘everywhere’ in submenu Graphics Submenu Text Submenu Paint Submenu Main Menu select ‘graphics’ select ‘paint’ select ‘text’ normal finish ESC normal finish ESC normal finish ESC

help menus similar problems –nearly the same everywhere –but return to same point in dialogue –could specify on STN … but very messy –usually best added at a ‘meta’ level Finish Help Subsystem Circle 1 click on circumference Circle 2 from Menu press HELP button draw circlerubber band click on centre Help Subsystem press HELP button

Example 3 Button Timer -Min -Sec -Stop/Start Process Pressing the min or sec increments the appropriate section of the display Pressing the min and sec together resets the timer Pressing the stop/start –When the display is 00:00 starts a count up (display updates each second) –When the display is not 00:00 starts a count down (updates each second) When stop/start pressed, count-down suspended When the time == 0 alarm sounds –When stop/start pressed »Alarm stops »Time reset to starting value

Solution Worked in class

Solution 2

When to use? Small discrete systems or subsystems –Shopping basket –Smart watch –Internet of things

Interpretation - Storyboarding Storyboarding involves using a series of pictures that describes a particular process or work flow –Can be used to study existing work flows or generate requirements. –Can facilitate the process of task decomposition –Used to brainstorm alternative ways of completing tasks.

Storyboard Example of a method for people who don’t own a cell phone handset to buy access for voice, SMS, etc. -

Interpretation – Use Cases Use cases represent a formal, structured approach to interpreting work flows and processes –Designed to describe a particular goal and explore the interaction between users and the actual system components. Jacobson et al. (1992) Incorporated into the Unified Modeling Language (UML) standard.

Interpretation – Use Cases The two main components of use cases are the actors and the use cases that represent their goals and tasks. –Actors: similar to stakeholders, but can also include other systems, networks, or software that interacts with the proposed system. –Use Cases: Each actor has a unique use case, which involves a task or goal the actor is engaged in. Describe discrete goals that are accomplished in a short time period Describe the various ways the system will be used and cover all of the potential functionality being built into the design

Interpretation – Use Cases Use case diagram of “schedule a meeting” process. Notice we use a stickman symbol for the equipment!

Use cases The diagram provides an overview of the entities and their relationships through activities This can be used to develop and explore scenarios –Basic path – the steps proceed without diversions from error conditions –Alternative paths – branches related to premature termination, choosing a different method of accomplishing a task, etc. E.g., what if the equipment isn’t available?

Documentation Collating all the data and intermediate documents from the Discovery Phase Working documents include –Human centred interviews, focus groups, surveys, primary stakeholder profiles –System centred task analysis, use case diagramming Collate into –Mission statement –Requirements document –Project management document –Usability guidelines

Documentation Mission Statement –Project goals: What is the value proposition? What needs will the new system address? How will it address these needs? –Project scope What does the proposed design include or exclude? What are the external constraints such as time and finances? How will you decide when it satisfies the design proposal?

Documentation Requirements Document –Requirements Functional – what features must be present? Information – what information is needed to carry out the functions? And what outputs are required by the stakeholders? Physical – what’s it run on? And where will it be used? (may need to accommodate organisation’s ‘legacy’ systems). –Inputs/outputs – data format / translation issues? –Constraints – physical, financial, time, data storage, networking, etc.

Documentation Project Management Document –Definition of the tasks involved in the project –Risk – what could go wrong? –Evaluation criteria and methods – what will constitute ‘success’? –Implementation – e.g. phased in one department at a time –Training –Maintenance –Future needs – anticipated requirements beyond the bounds of the ‘project’ per se

Summary Crucial to identify all stakeholders in a project Utilize a wide range of collection techniques to understand the needs of a project Task analysis, storyboarding and use case techniques allow for interpretation of collated data