Concepts in design Functionality and beyond. work organization/ practice Client users’ knowledge/ behavior/needs Technology Task Model 1 Task Model 2.

Slides:



Advertisements
Similar presentations
DASUM Panel. Peter Brusilovsky It is all about architectures! It doesnt matter if it is centralized or decentralized Some form of standardization is essential:
Advertisements

User Interface Design Main issues: What is the user interface How to design a user interface.
Using the Semantic Web to Construct an Ontology- Based Repository for Software Patterns Scott Henninger Computer Science and Engineering University of.
Goal-Oriented Requirements Engineering (GORE) “Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring,
Part 2d: Requirements Chapter 2: How to Gather Requirements: Some Techniques to Use Chapter 3: Finding Out about the Users and the Domain Chapter 4: Finding.
6. Envisioning the future system: Task model 2 Envisioning the future task world, not available for observation but modeling will allow: comparison to.
Background of Assignment A large international Telecom company is looking for possible new mobile communication services for the European and North-American.
Evaluation Through Expert Analysis U U U
GTA GroupWare Task Analysis n Task analysis concepts n GTA -Task analysis in design of complex systems n Methods of task knowledge collection n GTA conceptual.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
Introduction to Software Engineering Dr. Basem Alkazemi
4. Interaction Design Overview 4.1. Ergonomics 4.2. Designing complex interactive systems Situated design Collaborative design: a multidisciplinary.
Analysis Concepts and Principle.
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
Day 2 Prior to today Participated in the one day class on Cognitive Ergonomics, read all material of that class studied the reader for today read the paper.
Starting a project 1 Starting a Project Where do we now start? Where are we going? Will we know when we arrive?
4. Interaction Design Overview 4.1. Ergonomics 4.2. Designing complex interactive systems Situated design Collaborative design: a multidisciplinary.
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
Database System Development Lifecycle
1 CMPT 275 Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams.
User Interface Design Part 1.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
RUP Requirements RUP Artifacts and Deliverables
Groupware DESIGN Lecture 10.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
S556 SYSTEMS ANALYSIS & DESIGN Week 11. Creating a Vision (Solution) SLIS S556 2  Visioning:  Encourages you to think more systemically about your redesign.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
School of Computing FACULTY OF ENGINEERING Developing a methodology for building small scale domain ontologies: HISO case study Ilaria Corda PhD student.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Object-Oriented Analysis and Design An Introduction.
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.
User Interface Design Main issues: What is the user interface How to design a user interface ©2008 John Wiley & Sons Ltd.
1 USC INFORMATION SCIENCES INSTITUTE CALO, 8/8/03 Acquiring advice (that may use complex expressions) and action specifications Acquiring planning advice,
Lecture 7: Requirements Engineering
Chapter 9 Project Management. Introduction Effective project management requires a well-structured project and diligent oversight A well-structured project.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Task-based user interface principles Fraser Hamilton Brighton University
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Chapter 15: Analytical evaluation. Inspections Heuristic evaluation Walkthroughs.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 1 what is systems analysis? preparation of the system’s requirements/definition,
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
THE SUPPORTING ROLE OF ONTOLOGY IN A SIMULATION SYSTEM FOR COUNTERMEASURE EVALUATION Nelia Lombard DPSS, CSIR.
Gerhard Dueck -- CS3013Requirements Capture 1  From Vision to Requirements  Why it is difficult?  Developers are not users  Inadequate requirements.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Requirement Discipline Spring 2006/1385 Semester 1.
William H. Bowers – Requirements Torres 9.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
William H. Bowers – Specification Techniques Torres 17.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
1 Design and evaluation methods: Objectives n Design life cycle: HF input and neglect n Levels of system design: Going beyond the interface n Sources of.
Digital Media & Interaction Design LECTURE 4+5. Lecture 4+5 Draw requirement + Prototyping.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Group Y Presenters: (indicate roles)
The Next Stage in Analysis: Systems Use Case Diagrams
Modelling rich interaction
Requirements Elicitation – 1
BASICS OF SOFTWARE TESTING Chapter 1. Topics to be covered 1. Humans and errors, 2. Testing and Debugging, 3. Software Quality- Correctness Reliability.
Chapter 1 (pages 4-9); Overview of SDLC
Methontology: From Ontological art to Ontological Engineering
Usability Techniques Lecture 13.
Event Scheduling System
Requirement Engineer Terms and Conditions
Presentation transcript:

Concepts in design Functionality and beyond

work organization/ practice Client users’ knowledge/ behavior/needs Technology Task Model 1 Task Model 2 Scenario Simulation Prototype Functionality Dialog Representation Implementation usability measuring ethnography psychological knowledge acquisition/ hermeneutics problem analysis/ specification specification/ negotiation constraints/ opportunities feedback specification early evaluation early evaluation UVM maintaining consistency Documents/ artifacts validity analysis As soon as the system is implemented

Task World Ontology (Martijn van Welie) Task Agent Role Event Object name(string) goal(string) start_condition(string) stop_condition(string) initial_state(string) final_state(string) duration(integer) frequency(string) type(enum) user_actions(string) system_operations(string) name(string) skills(string) attitude(string) miscellaneous(string) name(string) goal(string) name(string) attribute(Name,Value)* action(Name)* name(string) description(string) Contains Responsible Performed_by PlaysTriggers Subtask Uses Triggers Used_by Subrole Is Performed_by

EUTERPE GTA representations

Task models Pretend to describe the whole domain of design: All … Tasks Roles actors Objects Events

The UVM One for each role, But include relations to other roles (as a note to relate)

functionality From task model 2: For each relevant role (i.e. when new technology is envisioned) As far as relevant for the design (i.e., what is new in our envisioning) Unit (or basic) tasks Related objects Object attributes Object – role relations Events

Unit tasks From task model 2: For each relevant role (i.e. when new technology is envisioned) Tasks that are different from task model 1 and not trivial

Objects “things” that feature in any new unit task: As conditions As triggers Being created, changed, transferred That help to manage new technology Competences of all involved roles to the object: Allowance to create, change, transfer, inspect

Events Trigger start or end of tasks Conditions for start or end As far as not effect of modeled tasks