Ch 5 Specification page 1CS 368 Context Specification one of the most commonly cited reasons for an IT project failure is unclear objectives and requirements.

Slides:



Advertisements
Similar presentations
A Systems Approach To Training
Advertisements

Chapter 12 User Interface Design
Ch.6: Requirements Gathering, Storyboarding and Prototyping
Task Analysis Summer Introduction In the last chapter we looked through the UCSD process. We identified TA as an important part of the system.
Elisati Hulu. Definition  “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project.
CT1404 Lecture 2 Requirement Engineering and Use Cases 1.
Ch 4 The Process page 1CS 368 Building Software is Difficult often delivered late often over budget always with errors must be a custom solution complexity.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
Paper Title Your Name CMSC 838 Presentation. CMSC 838T – Presentation Motivation u Problem paper is trying to solve  Characteristics of problem  … u.
CS351 © 2003 Ray S. Babcock Requirements What not How “The Pizza Experiment” 1994, 350 companies, 8000 software projects. 31% were canceled before they.
Identifying needs and establishing requirements Chapter 7a.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Term Project User Interface Specifications in a Usability Engineering Course: Challenges and Suggestions Laura Leventhal Julie Barnes Joe Chao Bowling.
Ch 3 Usability page 1CS 368 Usability Models the authors compare three usability models and introduce their own “the extent to which a product can be used.
CS 235: User Interface Design August 27 Class Meeting Department of Computer Science San Jose State University Spring 2015 Instructor: Ron Mak
CS 235: User Interface Design August 27 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak
Modeling Systems Requirements: Events and Things.
Chapter 10 Systems Planning, Analysis, and Design.
This Lesson Introduction to the ADDIE model Needs Analysis
Beyond Usability: Measuring Speech Application Success Silke Witt-Ehsani, PhD VP, VUI Design Center TuVox.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
William H. Bowers – Modeling Users: Personas and Goals Cooper 5.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Requirements Gathering. Why are requirements important? To understand what we are going to be doing We build systems for others, not for ourselves Requirements.
Output and User Interface Design
Software engineering lec4 Requirements. Developing requirements Start thinking about particular problem Understand the problem  Domain analysis Gather.
CSCD 487/587 Human Computer Interface Winter 2013 Lecture 3 HCI and Interactive Design.
Feasibility Study.
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
22C:082:001 Human-Computer Interaction. Fall Copyright © 2013 Juan Pablo Hourcade. 1 Group Project Phase 1.
Requirements Engineering Requirements Elicitation Process Lecture-8.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 7: Focusing on Users and Their Tasks.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
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.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive.
SBD: Activity Design CS HCI Chris North Usability Engineering - Chapter 3.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.
William H. Bowers – Users, Their Work Environment and Tasks Torres 10.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
Observing Users (finishing up) CS352. Announcements, Activity Notice upcoming due dates (web page) Discussion: –Did your observations have enough detail.
CS 4850: Senior Project - Spring 2009 CS 4850: Senior Project Spring 2009 Scope Statement and Project Plan.
1 Object-Oriented Modeling Using UML CS 3331 Section 2.4 Modeling Requirements with Use Cases.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
Lecture 2 Developing Requirements
Software Life Cycle The software life cycle is the sequence of activities that occur during software development and maintenance.
Carnegie Mellon Qatar © Robert T. Monroe Course Stage 2: Understanding The Opportunity Ethnography and The IDEO Design Process Robert.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Personas & Scenario Mapping This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.Creative Commons Attribution-NonCommercial-ShareAlike.
Ch 4: Discovery Yonglei Tao School of Computing & Info Systems GVSU.
By Godwin Alemoh. What is usability testing Usability testing: is the process of carrying out experiments to find out specific information about a design.
Copyright Robert W. Hasker. Requirements-based Development  System specification: series of “shalls”  The registration system shall support.
PRESENTATION ON USE CASE. Use Case Modeling Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Writing Use Cases: Requirements in Context.
Task Analysis Lecture # 8 Gabriel Spitz 1. Key Points  Task Analysis is a critical element of UI Design  It describes what is a user doing or will.
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.
Your Interactive Guide to the Digital World Discovering Computers 2012 Chapter 12 Exploring Information System Development.
User-Centered Design (UCD) Overview
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
Software Engineering Developing Requirements. © Lethbridge/Laganière 2001 Chapter 4: Developing requirements2 4.1 Domain Analysis The process by which.
Observing Users (finishing up)
Pepper modifying Sommerville's Book slides
Scope Planning.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Recall The Team Skills Analyzing the Problem (with 5 steps)
Software Testing.
Use Case Model Use case diagram.
Software Requirements
Use Case Modeling Part of the unified modeling language (U M L)
Use cases Dr. X.
Presentation transcript:

Ch 5 Specification page 1CS 368 Context Specification one of the most commonly cited reasons for an IT project failure is unclear objectives and requirements analysis is the activity of understanding and identifying a problem specification is the documentation of the analysis previously done by your instructor identify the stakeholders self service kiosk at Meijer identify usability expectations easy to use quick to learn highly secure enjoyable needs / functionality a rationale one sentence problem statement feature list feasibility target platform cost time

Ch 5 Specification page 2CS 368 Problem Definition identify the situation of concern finding an item at Target long lines a ticket counters there is too much litter on campus students need to pay for printing on campus One Sentence Problem Statement the activity to be supported the user the level of support a form of solution / platform Design a cash operated machine for quick and easy purchase of train tickets by passengers. Find a way to help delivery drivers reach their destinations without getting lost so often. Design an interactive system for genealogical researchers. Design a system to support concert pianists in giving recitals. Group Activity write problem statements

Ch 5 Specification page 3CS 368 User Scenarios collect problem scenarios from the stakeholders informal but detailed stories that describe typical users and their goals multiple scenarios can reveal characteristics of the environment and user expectations. Group Activity multiple scenarios for someone who needs to book travel arrangements find information on the Allendale campus

Ch 5 Specification page 4CS 368 Task Analysis (5.3) collect information from a number of stakeholders or existing systems surveys observations interviews review existing documentation include a stakeholder on the design team meticulously define all user tasks and sub-tasks as a hierarchy avoid descriptions of UI look and feel task descriptions should begin with a verb perhaps supplement an outline with a detailed description of each task consider the following is the sequence important? what is the necessary user input? what are the results / outputs? how can the tasks fail and what will be the result? error handling? specific usability expectations?

Ch 5 Specification page 5CS 368 Task Analysis (continued) use case models are popular with some professionals stick figure agents and oval tasks not a fan myself other experiences? failure to spend sufficient time and resources on this phase will cost you later! Group Activity make a PBJ sandwich document a task analysis for course registration

Ch 5 Specification page 6CS 368 User Profiles describe the intended users age gender physical characteristics frequency of use motivation required for work fun game optional for a customer computer experience novice occasional expert (power user) Poll workers average age is 72 limited computer experience

Ch 5 Specification page 7CS 368 Specification Document title page rationale one sentence problem statement functionality list user profiles usability expectations high level goals user scenarios (at least three) detailed task hierarchy (numbered outline)