Requirements Elicitation Requirements Engineering (CI 2323) Daniel Siahaan.

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

© 2005 Prentice Hall13-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Data Gathering Purpose: –To collect sufficient, relevant and appropriate data to develop a set of stable requirements Data: –Tasks performed –Goals –Context.
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
Process Improvement.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
Requirements Engineering: A Roadmap Vahid Jalali Fall 2007 Amirkabir university of technology, Department of computer engineering and information technology,
Requirements Analysis Concepts & Principles
Knowledge Acquisition. Knowledge Aquisition Definition – The process of acquiring, organising, & studying knowledge. Identified by many researchers and.
Requirement Engineering – A Roadmap
4. Interaction Design Overview 4.1. Ergonomics 4.2. Designing complex interactive systems Situated design Collaborative design: a multidisciplinary.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
4. Interaction Design Overview 4.1. Ergonomics 4.2. Designing complex interactive systems Situated design Collaborative design: a multidisciplinary.
5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Towards an activity-oriented and context-aware collaborative working environments Presented by: Ince T Wangsa Supervised by:
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Requirements Engineering
Chapter 6 Supplement Knowledge Engineering and Acquisition Chapter 6 Supplement.
Interaction Design Process COMPSCI 345 S1 C and SoftEng 350 S1 C Lecture 5 Chapter 3 (Heim)
1 © Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
 To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 Requirements Engineering Processes Objectives l To describe the principal requirements engineering activities and their relationships l To.
R EQUIREMENTS AND SYSTEM ENGINEERING Week 4. O UTLINE System engineering Requirements elicitation Assignment.
Lecture 7: Requirements Engineering
IS2210: Systems Analysis and Systems Design and Change Twitter:
1 Introduction to Software Engineering Lecture 1.
KNOWLEDGE ACQUISITION II. Protocol Analysis Knowledge provider works through some pre-defined task, KE observes. Varieties: –Think-aloud –Critical response.
Formative Research on the Heuristic Task Analysis Process Charles M. Reigeluth Ji-Yeon Lee Bruce Peterson Mike Chavez Indiana University.
University of Sunderland Professionalism and Personal Skills Unit 9 Professionalism and Personal Skills Lecture Data Collection.
Ways of Collecting Information Interviews Questionnaires Ethnography Books and leaflets in the organization Joint Application Design Prototyping.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Software Engineering, 8th edition. Chapter 7 1 Courtesy: ©Ian Sommerville 2006 March 20 th, 2008 Lecture # 12 Requirements Engineering Processes.
Chapter 4 Requirements Engineering (3/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Identifying needs and establishing requirements Data gathering for requirements.
Requirements Validation
OTHER KNOWLEDGE CAPTURE TECHNIQUES CHAPTER 6. Chapter 6: Other Knowledge Capture Techniques 2 On-Site Observation  Process of observing, interpreting,
Requirements Engineering. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Making knowledge work harder Process Improvement.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Chapter 4 – Requirements Engineering Part 2 1Chapter 4 Requirements engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
1 Software Engineering Muhammad Fahad Khan Software Engineering Muhammad Fahad Khan University Of Engineering.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
PROCESS ASSESSMENT AND IMPROVEMENT. Process Assessment  A formal assessment did not seem financially feasible at the onset of the company’s process improvement.
User-centered approaches to interaction design By Haiying Deng Yan Zhu.
Requirements Analysis Requirements Engineering (CI 2323) Daniel Siahaan.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Requirements Engineering Processes
Techniques & Approaches for Requirement Elicitation
CIS 376 Bruce R. Maxim UM-Dearborn
SNS College of Engineering Coimbatore
EKT 421 SOFTWARE ENGINEERING
Requirements Engineering Process
User interface design.
Presentation transcript:

Requirements Elicitation Requirements Engineering (CI 2323) Daniel Siahaan

Content Introduction to Requirements Engineering Add-on: Scenario Feasibility Studies Requirements Elicitation Creativity Thinking Requirements Analysis Requirements Specification Requirements Validation

Part 2

Elicitation Techniques Traditional techniques Introspection Reading existing documents Analysing hard data (collection) Interviews – Open-ended – Structured Surveys / Questionnaires Meetings

Elicitation Techniques Collaborative techniques Group techniques – Focus Groups – Brainstorming JAD/RAD workshops Prototyping Participatory Design

Group Elicitation Techniques Types: Focus Groups Brainstorming Advantages More natural interaction between people than formal interview Can gauge reaction to stimulus materials (e.g. mock-ups, storyboards, etc) Disadvantages May create unnatural groups (uncomfortable for participants) Danger of Groupthink May only provide superficial responses to technical questions Requires a highly trained facilitator Watch for sample bias dominance and submission

Joint and Rapid Development Principles: Group Dynamics – one-to-one or group interview formats replaced with workshops Visual Aids – Use lots of visualization media, ranging from wall charts to large monitors or graphical interfaces Organized, Rational Process – Using techniques such as brainstorming and top-down analysis to structure the elicitation and analysis process WYSIWYG Documentation Approach – each JAD session results in a document which is easy to understand and is created and agreed upon during the session

Joint and Rapid Development Notes: Choose workshop participants carefully – they should be the best people possible representing various stakeholder groups Workshop should last 3-5 days. – Must turn a group of participants into a team - this takes 1-2 days. – Session leader makes sure each step has been completed thoroughly. – Session leader steps in when there are differences of opinion - “ open issues ”. – Meeting room should be well-equipped for presentations, recording etc.

Elicitation Techniques Cognitive techniques Task analysis Protocol analysis Knowledge Acquisition Techniques – Card Sorting – Laddering – Repertory Grids – Proximity Scaling Techniques

Knowledge Elicitation Techniques Background Knowledge elicitation is concerned with discovering ‘ expert ’ knowledge Grew out of Expert Systems work in the 80 ’ s Originally focussed on deriving expert ’ s “ rules ” for Rule-based Systems More recently, focussed on “ problem solving methods ” But KE is hard Separation of domain knowledge from performance knowledge Modeling problems – Brittleness – Assumption of rationality Representational Problem – epistemological inadequacy – expressiveness vs. acquirability Expert Bias

Knowledge Elicitation Techniques Kind of techniques: Eliciting domain knowledge – Card Sorting – Laddering – Proximity Scaling Techniques Eliciting performance knowledge – Protocol Analysis Using Multiple Experts – Delphi Technique – Focus Groups – Repertory Grids Automated Techniques

Knowledge Level View knowledge modelling as: Observe behaviour of an agent as black box – It acts as if it has some knowledge about its environment which it uses rationally – It takes actions to achieve ascribed goals Construct two models: – Symbol Level - descriptions for mechanising behaviour – Knowledge Level - descriptions of the agent's knowledge of the world Two-step rationality: Agent applies its knowledge in two stages: First creates a task specific model from the KL model based on features of the task. Hence, we actually need 3 models: – Domain model - a systematic way of talking about a domain, with a coherent ontology. – Task model - models goals, what it means to achieve a goal, and how goals are related. – Problem-solving method - a way of relating task and domain models to accomplish goals.

Knowledge Level

Knowledge Elicitation Techniques Protocol Analysis based on vocalising behaviour – Think aloud vs. retrospective protocols Advantages – Direct verbalisation of cognitive activities – Embedded in the work context – Good at revealing interaction problems with existing systems Disadvantages – Essentially based on introspection, hence unreliable – No social dimension

Knowledge Elicitation Techniques Proximity Scaling Techniques Given some domain objects, derive a set of dimensions for classifying them: – step 1: pairwise proximity assessment among domain elements – step 2: automated analysis to build multi-dimensional space to classify the objects Advantages – help to elicit mental models, where complex multivariate data is concerned – good for eliciting tacit knowledge Disadvantages – Requires an agreed on set of objects – Only models classification knowledge (no performance knowledge)

KE: Card Sorting Techniques For a given set of domain objects, written on cards: Expert sorts the cards into groups......then says what the criterion was for sorting, and what the groups were. Advantages simple, amenable to automation elicits classification knowledge Problems suitable entities need to be identified with suitable semantic spread across domain. No performance knowledge

KE: Laddering Techniques Uses a set of probes (types of question) to acquire structure and content of stakeholders ’ knowledge. Interview the expert. Use questions to move up and down a conceptual hierarchy Advantages deals with hierarchical knowledge, including polyhierarchies (e.g., goal trees, “ is-a ” taxonomies). knowledge is represented in standardised format can elicit structural knowledge suitable for automation. Disadvantages assumes hierarchically arranged knowledge.

KE: Laddering Techniques Delphi technique ƒ  Used where contact between experts is difficult: ÿ  Each expert submits their judgement ÿ  All judgements are circulated anonymously to all experts ÿ  Each expert then submits a revised judgement ÿ  Iterate until judgements converge ‹ Focus Groups ƒ  A technique derived from marketing: ÿ  Assemble experts together and discuss the problem ÿ  Discussion may be structured (e.g. debate) or unstructured ‹ Repertory Grids (based on Kelly ’ s Personal Construct Theory) ƒ  Used to detect terminological differences ÿ  Get the experts to agree a set of entities ÿ  Each expert provides attributes and values ÿ  For each attribute in expert A's grid, find the closest match in expert B's grid. (i.e. are there attributes which have the same discriminatory function?) ÿ  Experts then rate the entities using each other's attributes

Elicitation Techniques Contextual approaches Ethnographic techniques – Participant Observation – Enthnomethodology Discourse Analysis – Conversation Analysis – Speech Act Analysis Sociotechnical Methods – Soft Systems Analysis

Ethnography A social scientist spends a considerable time observing and analysing how people actually work People do not have to explain or articulate their work Social and organisational factors of importance may be observed Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models

Focused ethnography Developed in a project studying the air traffic control process Combines ethnography with prototyping Prototype development results in unanswered questions which focus the ethnographic analysis Problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant

Ethnography and prototyping

Scope of ethnography Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work Requirements that are derived from cooperation and awareness of other people’s activities