Requirements Engineering Requirem ents Engineering Unit 3: - - PowerPoint PPT Presentation

9/ 22/ 2009 | 1 2009 Fall Peng Liang Requirements Engineering

› Department of Computer Science / Peng Liang › Rijksuniversiteit Groningen (RUG)

› http:/ / www.cs.rug.nl/ ~liangp/ teaching/ courses/ RE2009Fall/

Requirements Engineering

Unit 3: Requirements elicitation

2009 Fall | 2 Peng Liang Requirements Engineering 9/ 22/ 2009

Course outline

Requirem ents Engineering Requirem ents Engineering process Requirem ents elicitation Requirem ents analysis Requirem ent validation

Requirem ents docum entation

Requirem ents negotiation

Requirem ents m anagem ent

2009 Fall | 3 Peng Liang Requirements Engineering 9/ 22/ 2009

Last Unit

Requirem ents Engineering process

This Unit

Requirem ents elicitation

Next Unit

Requirem ents m odeling

2009 Fall | 4 Peng Liang Requirements Engineering 9/ 22/ 2009

Course project

› The progress of the REWiki documentation will be along with the progress of the course content. › Recommended schedule

• identify project scope, feasibility issues, risks, stakeholders

(Week 38)

• decompose goals into sub-goals, and elicit scenarios,

document major functional and non-functional requirements (Week 39)

• analyse requirements, prioritize requirements (Week 40)
• negotiate, validate requirements and RE iterations (Week 41,

42, and 43)

2009 Fall | 5 Peng Liang Requirements Engineering 9/ 22/ 2009

Course project

› Every group can also proceed with your own speed › Evaluation of the course project will be determined by the final quality of the deliverables

2009 Fall | 6 Peng Liang Requirements Engineering 9/ 22/ 2009

Course project (Group 4 recruiting)

› [Group 1]: Ruurd Krekt, Pim van der Waak, Henk van Ramshorst, Ralph van Brederode, Johan van der Geest (5) › [Group 2]: Erwin Vast, Fernand Geertsema, Marco Hak, Jop Verhagen, Mattijs Meiboom, Zaki Juma (6) › [Group 3]: Anton Jongsma, Dirk Nederveen, Karsten Westra, Thomas Edward Spanjaard, Mark Scheeve, Edwin-Jan Harmsma (6) › [Group 4]: Eelco Hooghiem, Gertjan Dalstra, Samuel Esposito, Artemios Kontogogos, Abarajithan Parameswaran (5) › [Group 5]: Gerhard Boer, Jeroen de Groot, Tim van Elteren, Rudy Schoenmaker, Wilrik Mook, Pieter Stavast (6) › [Group 6]: Jochem Pastoor, Stef van Grieken, Jan Wijma, Wilco Wijbrandi, Joris de Keijse (5)

2009 Fall | 7 Peng Liang Requirements Engineering 9/ 22/ 2009

Assignment for a good understanding

› Hundreds of methods are collected

• Interviews (requirem ents elicitation m ethod)
• Questionnaires
• Storyboard
• Prototyping
• Use cases (requirem ents representation m ethod)
• Workshop (organization m ethod)
• Joint application design
• …

2009 Fall | 8 Peng Liang Requirements Engineering 9/ 22/ 2009

Contents

› Why requirement elicitation? › Requirements elicitation activities › Requirements elicitation techniques

2009 Fall | 9 Peng Liang Requirements Engineering 9/ 22/ 2009

Why requirement elicitation?

› Typical requirement syndromes

• “Yes, but …

”

• “Undiscovered requirements”
• “Customer/ user and developer”

›

• D. Leffingwell and D. Widrig. Managing Softw are Requirem ents: A Use Case Approach. Addison-Wesley, 2003.

2009 Fall | 10 Peng Liang Requirements Engineering 9/ 22/ 2009

“Yes, but … ” syndrome

› “Wow, this is so cool and nice; we really want to use this.” › “Yes, but, hmmm,

• What about this part …

?

• Wouldn’t it be nice if …

?

• …

?

Intangible nature of software system

2009 Fall | 11 Peng Liang Requirements Engineering 9/ 22/ 2009

“Yes, but … ” solution

› Get the “buts” out AE(earlier)AP › Elicit the “buts” response early

To shows users the prototypes or demos earlier and regularly

2009 Fall | 12 Peng Liang Requirements Engineering 9/ 22/ 2009

“Undiscovered requirements” syndrome

› “The more you find, the more you need to know” › When have we found enough requirements?

Requirements elicitation, never completed task

Oh, I found it, but w here should I go next?

2009 Fall | 13 Peng Liang Requirements Engineering 9/ 22/ 2009

“Undiscovered requirements” solution

› Scoping your system › Identify the stakeholders in three worlds

2009 Fall | 14 Peng Liang Requirements Engineering 9/ 22/ 2009

“User and developer” syndrome

› Communication gap between user and developer

• From different world
• Speak different language
• Different background, motivations, objectives

Living in different world

2009 Fall | 15 Peng Liang Requirements Engineering 9/ 22/ 2009

“User and developer” solution

› Better communication to mitigate the risk

• Role playing
• User observation
• Storyboarding
• Prototypes
• Teach/ echo back
• …

2009 Fall | 16 Peng Liang Requirements Engineering 9/ 22/ 2009

Embrace the users

2009 Fall | 17 Peng Liang Requirements Engineering 9/ 22/ 2009

Steps of requirements elicitation

Application domain Problems to be solved Business context Stakeholder needs and constraints

1 2 3 4

2009 Fall | 18 Peng Liang Requirements Engineering 9/ 22/ 2009

Example › HAS (home automation system)

2009 Fall | 19 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicitation activities

› (Step1) Application domain understanding

• The trend in HAS (home automation system)
• The state-of-art technology used in HAS
• Domain concepts in HAS
• …

Sensor Climate control Safeguard HAS Human Intervention Controller

2009 Fall | 20 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicitation activities

› (Step2) Problem understanding

• For the easy life at home
• Security at home
• Heating, air conditioning control
• Household management
• …

2009 Fall | 21 Peng Liang Requirements Engineering 9/ 22/ 2009

“satisfy the user”

Elicitation activities

› (Step3) Business understanding

• Target market of HAS
• Profit strategy of HAS
• Selling points of HAS
• …

The ultimate goal of RE

“minimize risk” “add business value”

2009 Fall | 22 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicitation activities

› (Step4) Understanding the specific needs and constraints of system stakeholders

Stakeholders

any person or organization who can be positively or negatively impacted by, or cause an impact

• n the actions of a system.

2009 Fall | 23 Peng Liang Requirements Engineering 9/ 22/ 2009

Who are they?

2009 Fall | 24 Peng Liang Requirements Engineering 9/ 22/ 2009

Stakeholders identification

› Who they are?

• From three world
• usage, development, environment

›

• M. Glinz and R.J. Wieringa. Stakeholders in Requirem ents Engineering. IEEE Software, 24(2):18-20, 2007.

2009 Fall | 25 Peng Liang Requirements Engineering 9/ 22/ 2009

Stakeholders identification

› How important they are? (HAS)

• Critical: decide the project (Custom er)
• Major: significant negative impact on the system

(Thief)

• Minor: marginal impact on the system

(Neighborhood)

2009 Fall | 26 Peng Liang Requirements Engineering 9/ 22/ 2009

Eliciting requirements from stakeholders

2009 Fall | 27 Peng Liang Requirements Engineering 9/ 22/ 2009

Good requirements is not readily available from users

2009 Fall | 28 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicitation techniques

› Traditional techniques › Collaborative techniques › Contextual approaches › Representation-based approaches

2009 Fall | 29 Peng Liang Requirements Engineering 9/ 22/ 2009

Traditional techniques

› Reading existing documents › Analyzing “hard data” › Interviews › Introspection › Surveys & questionnaires

2009 Fall | 30 Peng Liang Requirements Engineering 9/ 22/ 2009

Reading existing documents

› Sources of project information

• Company reports (business context)
• Organization charts (potential stakeholders)
• Policy manuals (regulations)
• Job descriptions (potential requirem ents,

problem s, and business process)

• Existing systems documentation (reusable

requirem ents)

2009 Fall | 31 Peng Liang Requirements Engineering 9/ 22/ 2009

Business context example

› “Intellibuild wants to offer a pioneering product that will revolutionize the market of infotainm ent. These services will replace the existing m odel, e.g. going to the information desk or getting the information before reaching the location. Furthermore, it will implement new services that have not been offered before, e.g., real-tim e notification of schedule changes.”

2009 Fall | 32 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicited requirement info from business context › Business goal

› To provide infotainment product

› Risk

› To be a pioneering product is a risk in market

› Problem

› To replace the existing information broadcasting model

› Requirement

› To provide real-time notification of schedule change

2009 Fall | 33 Peng Liang Requirements Engineering 9/ 22/ 2009

Reading existing documents

› Advantage

• Get understanding before real meeting
• More resource for fact finding
• Discover reusable requirements

› Disadvantage

• Document is always not up-do-date
• Much irrelevant data results in wasting effort

› Appropriate for

• When you are unfamiliar with the system background

2009 Fall | 34 Peng Liang Requirements Engineering 9/ 22/ 2009

“Hard data” collection

› Marketing data

• What the users most want

› Survey result

• What the users are satisfied with

› Business forms

• What business data the users need

2009 Fall | 35 Peng Liang Requirements Engineering 9/ 22/ 2009

“Hard data” example

› What dose this data tell you? › What would the system do with this data?

2009 Fall | 36 Peng Liang Requirements Engineering 9/ 22/ 2009

Elicited requirements from “hard data”

› R1: The system should provide all the data concerning a flight ticket

• SR1: The system should provide the passenger

information which can be used to uniquely identify a passenger (e.g., passport No.)

• SR2: The system should provide the departure

and arrival time and airport information

• SR3: The system should provide fight number

information.

• …

2009 Fall | 37 Peng Liang Requirements Engineering 9/ 22/ 2009

“Hard data” collection

› Advantage

• Intuitive understanding about requirements

› Disadvantage

• Data sampling is difficult

› Appropriate for

• Information systems

2009 Fall | 38 Peng Liang Requirements Engineering 9/ 22/ 2009

Interviews

› Not simply asking questions

• Social skills
• Ability to listen
• Ability to control

› phases

• Identify the interview candidates (starting from high-

level person)

• Prepare questions
• Conduct the interview and follow up

2009 Fall | 39 Peng Liang Requirements Engineering 9/ 22/ 2009

Interviews

› Advantage

• Rich collection of information
• Probe in depth & change questions interactively

› Disadvantage

• Qualitative data is hard to analyze (like, prefers,

maybe)

• Hard to compare different answers (conflict)

› Appropriate for

• Small projects without many stakeholders

2009 Fall | 40 Peng Liang Requirements Engineering 9/ 22/ 2009

Example interview questions

› What’s the strategic goals of this project? (business goals) › How is this project expected to support our strategic goals? (business rationale) › Are there potential constraints on the project? (business context) › Is my understanding is correct that ... (reinterpretation) › Is there another way to restate the requirement that might make it more specific? (clarification) › What is the rationale for the constraint? (requirem ent rationale) › What is the risk or possible cost of not acknowledging the constraint? (business risk) › Who has a concern about these constraints? (stakeholders)

2009 Fall | 41 Peng Liang Requirements Engineering 9/ 22/ 2009

Try to ask those questions to yourself based on the course project (Introspection elicitation methods)

2009 Fall | 42 Peng Liang Requirements Engineering 9/ 22/ 2009

Interview tips

› Start the interview in a comfortable atmosphere

• don’t be a judge, or too serious

› Ask easy questions first

• How long have you been worked in your present position?

(credibility)

› Follow up interesting topics

• Could we pursue what you just said a litter further?

› End the interview with open questions

• Is there anything else you would like to add?

2009 Fall | 43 Peng Liang Requirements Engineering 9/ 22/ 2009

Surveys and questionnaires

› To select your target audience › To prepare questions with domain experts › To distribute the survey form as widely as possible › To collect and analyze the data

2009 Fall | 44 Peng Liang Requirements Engineering 9/ 22/ 2009

Surveys and questionnaires

› Advantage

• Quick collect info from large number of people
• Administrated remotely and effort propagation

› Disadvantage

• No interactive communication

› Appropriate for

• Project with large number of stakeholders (e.g., web

applications)

2009 Fall | 45 Peng Liang Requirements Engineering 9/ 22/ 2009

NFR Surveys example

2009 Fall | 46 Peng Liang Requirements Engineering 9/ 22/ 2009

Collaborative techniques

› Group techniques › Focus Groups › Brainstorming › JAD/ RAD workshops › Prototyping › Participatory Design

2009 Fall | 47 Peng Liang Requirements Engineering 9/ 22/ 2009

Joint/ Rapid application development

› Bring user and developer together › Organized workshop with both-confirmed schedule › Results in a document › Visual communication assistant (e.g., large monitor) › Important role: facilitator (team-leader) and recorder (administrative assistant)

2009 Fall | 48 Peng Liang Requirements Engineering 9/ 22/ 2009

JAD/ RAD process

› Confirm schedule (phase and timing) › Open issues (assumptions, purpose, scope and

• bjective)

› Research background (current system introduction) › Workshop (equal participation, recording) › Document refinement for participants review

2009 Fall | 49 Peng Liang Requirements Engineering 9/ 22/ 2009

JAD/ RAD

› Advantage

• Systematic user participation and involvement
• Solve target requirement problem in a sudden

› Disadvantage

• Lot of preparation work/ cost before the workshop

› Appropriate for

• Conflicting interests, new project

2009 Fall | 50 Peng Liang Requirements Engineering 9/ 22/ 2009

Contextual approaches

› Participant observation › Role-playing › Conversation analysis › Speech act analysis

2009 Fall | 51 Peng Liang Requirements Engineering 9/ 22/ 2009

Participant observation

› Become a member of the user group › Individual activity › To observe the working process › To find out the real problem and how best to solve it

2009 Fall | 52 Peng Liang Requirements Engineering 9/ 22/ 2009

Example

› Loan approval system

• To find out how people in a bank to approve the

loan › Aircraft flight control systems

• To observe how administrator in an airport control

center to manage the flight

2009 Fall | 53 Peng Liang Requirements Engineering 9/ 22/ 2009

Participant observation

› Advantage

• Contextualized info
• Reveal details that other method can not

› Disadvantage

• Extremely time-consuming
• Resulting “rich picture” is hard to analyze

› Appropriate for

• Customized software system, tacit knowledge

2009 Fall | 54 Peng Liang Requirements Engineering 9/ 22/ 2009

Representation-based approaches

› Goal-based › Scenario-based › Use cases

2009 Fall | 55 Peng Liang Requirements Engineering 9/ 22/ 2009

Goal-based

› Focus on “why” systems are constructed › Express the “why” as a set of stakeholder goals › Use goal refinem ent to arrive at specific requirements › Goal hierarchies: show refinement and obstacle relationships between goals

2009 Fall | 56 Peng Liang Requirements Engineering 9/ 22/ 2009

Goal statement

› To <active verb phrase> <target object> › e.g., to m aintain m arket share

2009 Fall | 57 Peng Liang Requirements Engineering 9/ 22/ 2009

Example

›

• J. Mylopoulos, L. Chung, S. Liao, H. Wang and E. Yu. Exploring Alternatives during Requirem ents Analysis. IEEE Software, 18(1):92-

96, 2001.

AND OR

Meeting manager

2009 Fall | 58 Peng Liang Requirements Engineering 9/ 22/ 2009

Goal Structuring Notation (GSN)

2009 Fall | 59 Peng Liang Requirements Engineering 9/ 22/ 2009

GSN example

2009 Fall | 60 Peng Liang Requirements Engineering 9/ 22/ 2009

Goal-based

› Advantage

• Reasonable intuitive
• Easy for business goal identification and

decomposition

› Disadvantage

• Hard to cope with goals evolution
• Either very complex goal hierarchy or lack of details

› Appropriate for

• Initial business goal modeling

2009 Fall | 61 Peng Liang Requirements Engineering 9/ 22/ 2009

Scenario-based

› Sequence of interaction between actor and system in 3-7 steps (not too complex) › A first step when writing use case

2009 Fall | 62 Peng Liang Requirements Engineering 9/ 22/ 2009

Scenario vs. specification

› Specifications are

• Abstract
• General situ.
• Exhaustive in

coverage of situations

• Authoritative
• Boring for users

› Scenarios are

• Concrete
• Specific situ.
• Selective with

respect to key situations

• Illustrative
• Compelling

2009 Fall | 63 Peng Liang Requirements Engineering 9/ 22/ 2009

Scenario Example

› One of the “Semantic Web” scenarios › The entertainment system was belting out the Beatles' "We Can Work It Out" when the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control. › What goal this scenario is going to achieve?

• To achieve autom atic m achine com m unication

›

• T. B. Lee, J. Hendler, O. Lassila et al. The Sem antic Web. Scientific American, 284(5):28-37, 2001.

2009 Fall | 64 Peng Liang Requirements Engineering 9/ 22/ 2009

Scenario-based

› Advantage

• Natural: stakeholders tend to use them

spontaneously

• Short scenarios are good for specific interactions

(tacit knowledge)

› Disadvantage

• Lack of structure: need use case to provide high level

view

› Appropriate for

• Interactive systems, e.g. telecom system

2009 Fall | 65 Peng Liang Requirements Engineering 9/ 22/ 2009

Use cases

› A description of a set of possible concrete scenarios that have a common purpose to a actor › Specified from the actor’s point of view › Described in both modeling notation and natural language

2009 Fall | 66 Peng Liang Requirements Engineering 9/ 22/ 2009

Example

Phone user

Control environmental volume Turn down Turn off

Scenarios

2009 Fall | 67 Peng Liang Requirements Engineering 9/ 22/ 2009

Use cases

› Advantage

• Easy to write and understand (natural

representation)

• Helps in drawing system boundary and

management the requirements

› Disadvantage

• do not represent NFR and domain knowledge
• Writing good use case takes skill and practices

› Appropriate for

• User requirements when business goals confirmed

2009 Fall | 68 Peng Liang Requirements Engineering 9/ 22/ 2009

When to use these elicitation methods to elicit different requirements?

2009 Fall | 69 Peng Liang Requirements Engineering 9/ 22/ 2009

Business requirements User requirements Business goals and scope Requirements Documents Use case Software requirement specification (SRS) LEGEND FR Other NFR Quality attribute

“Ea sy registra tion” “Register

• nline”

“Register by p rov id ing na m e a nd em a il a d d ress” a v a ila bility security

Levels of Software Requirem ents

2009 Fall | 70 Peng Liang Requirements Engineering 9/ 22/ 2009

Business requirements User requirements FR NFR Hard data collection, Scenario-based Reading existing documents Surveys & Questionnaires, Participant observation, Use cases Interviews, Goal-based JAD/ RAD workshops

Elicitation methods application

2009 Fall | 71 Peng Liang Requirements Engineering 9/ 22/ 2009

Review of today

› Embrace the user/ customer › Requirements elicitation is difficult › Various elicitation methods are suitable for the elicitation of different levels of requirements

9/ 22/ 2009 | 72 2009 Fall Peng Liang Requirements Engineering

Reading

• M. Glinz and R.J. Wieringa. Stakeholders in requirements engineering. IEEE Software, 24(2):18-

20, 2007.

• J.A. Goguen and C. Linde. Techniques for requirements elicitation. Proceedings of the 1st IEEE

International Symposium on Requirements Engineering (RE), pages 152-164, 1993.

9/ 22/ 2009 | 73 2009 Fall Peng Liang Requirements Engineering

Course assignment

• (1) course project meeting submissions, see deadlines

http:/ / www.cs.rug.nl/ search/ Teaching/ RE2009FallDeadlines

Submission method

(1) should be submitted in the meeting agenda (what elicitation method does your group choose) and minutes (detailed elicitation process) of Week 39