Requirements Engineering · Why requirement elicitation? › Typical requirement syndromes • “Yes, but …” • “Undiscovered requirements” • “Customer/user and developer”

9/22/2009 | 1

2009 FallPeng Liang Requirements Engineering

› Department of Computer Science / Peng Liang

› Rijksuniversiteit Groningen (RUG)

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

Requirements EngineeringUnit 3:

Requirements elicitation

2009 Fall

| 2

Peng Liang Requirements Engineering

9/22/2009

Course outlineRequirements Engineering

Requirements Engineering process


Requirements analysis

Requirement validation

Requirements documentationRequirements

negotiation Requirements management

2009 Fall

| 3


9/22/2009

Last UnitRequirements

Engineering process This Unit


Next UnitRequirements

modeling

2009 Fall

| 4


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


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


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, WilcoWijbrandi, Joris de Keijse (5)

2009 Fall

| 7


9/22/2009

Assignment for a good understanding

› Hundreds of methods are collected• Interviews (requirements elicitation method)• Questionnaires• Storyboard• Prototyping• Use cases (requirements representation method)• Workshop (organization method)• Joint application design• …

2009 Fall

| 8


9/22/2009

Contents

› Why requirement elicitation?

› Requirements elicitation activities

› Requirements elicitation techniques

2009 Fall

| 9


9/22/2009

Why requirement elicitation?

› Typical requirement syndromes

• “Yes, but …”

• “Undiscovered requirements”

• “Customer/user and developer”

› D. Leffingwell and D. Widrig. Managing Software Requirements: A Use Case Approach. Addison-Wesley, 2003.

2009 Fall

| 10


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


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


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 where should I go

next?

2009 Fall

| 13


9/22/2009

“Undiscovered requirements” solution

› Scoping your system

› Identify the stakeholders in three worlds

2009 Fall

| 14


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


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


9/22/2009

Embrace the users

2009 Fall

| 17


9/22/2009

Steps of requirements elicitation

Application domain

Problems to be solved

Business context

Stakeholder needs and constraints

1 2

34

2009 Fall

| 18


9/22/2009

Example

› HAS (home automation system)

2009 Fall

| 19


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

HASHuman

InterventionController

2009 Fall

| 20


9/22/2009


› (Step2) Problem understanding

• For the easy life at home

• Security at home

• Heating, air conditioning control

• Household management

• …

2009 Fall

| 21


9/22/2009

“satisfy the user”


› (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


9/22/2009


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

Stakeholdersany person or organization who can be positively or negatively

impacted by, or cause an impact on the actions of a system.

2009 Fall

| 23


9/22/2009

Who are they?

2009 Fall

| 24


9/22/2009

Stakeholders identification

› Who they are?• From three world

• usage, development, environment

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

2009 Fall

| 25


9/22/2009

Stakeholders identification

› How important they are? (HAS)

• Critical: decide the project (Customer)

• Major: significant negative impact on the system (Thief)

• Minor: marginal impact on the system (Neighborhood)

2009 Fall

| 26


9/22/2009

Eliciting requirements from stakeholders

2009 Fall

| 27


9/22/2009

Good requirements is not readily available from users

2009 Fall

| 28


9/22/2009

Elicitation techniques

› Traditional techniques

› Collaborative techniques

› Contextual approaches

› Representation-based approaches

2009 Fall

| 29


9/22/2009

Traditional techniques

› Reading existing documents

› Analyzing “hard data”

› Interviews

› Introspection

› Surveys & questionnaires

2009 Fall

| 30


9/22/2009

Reading existing documents

› Sources of project information• Company reports (business context)

• Organization charts (potential stakeholders)

• Policy manuals (regulations)

• Job descriptions (potential requirements, problems, and business process)

• Existing systems documentation (reusable requirements)

2009 Fall

| 31


9/22/2009

Business context example

› “Intellibuild wants to offer a pioneering productthat will revolutionize the market of infotainment. These services will replace the existing model, 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-time notification of schedule changes.”

2009 Fall

| 32


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


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


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


9/22/2009

“Hard data” example› What dose this

data tell you?

› What would the system do with this data?

2009 Fall

| 36


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


9/22/2009

“Hard data” collection

› Advantage• Intuitive understanding about requirements

› Disadvantage• Data sampling is difficult

› Appropriate for• Information systems

2009 Fall

| 38


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


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


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? (requirement 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


9/22/2009

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

2009 Fall

| 42


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


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


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


9/22/2009

NFR Surveys example

2009 Fall

| 46


9/22/2009

Collaborative techniques

› Group techniques

› Focus Groups

› Brainstorming

› JAD/RAD workshops

› Prototyping

› Participatory Design

2009 Fall

| 47


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


9/22/2009

JAD/RAD process

› Confirm schedule (phase and timing)

› Open issues (assumptions, purpose, scope and objective)

› Research background (current system introduction)

› Workshop (equal participation, recording)

› Document refinement for participants review

2009 Fall

| 49


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


9/22/2009

Contextual approaches

› Participant observation

› Role-playing

› Conversation analysis

› Speech act analysis

2009 Fall

| 51


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


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


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


9/22/2009

Representation-based approaches

› Goal-based

› Scenario-based

› Use cases

2009 Fall

| 55


9/22/2009

Goal-based

› Focus on “why” systems are constructed

› Express the “why” as a set of stakeholder goals

› Use goal refinement to arrive at specific requirements

› Goal hierarchies: show refinement and obstacle relationships between goals

2009 Fall

| 56


9/22/2009

Goal statement

› To <active verb phrase> <target object>› e.g., to maintain market share

2009 Fall

| 57


9/22/2009

Example

› J. Mylopoulos, L. Chung, S. Liao, H. Wang and E. Yu. Exploring Alternatives during Requirements Analysis. IEEE Software, 18(1):92-96, 2001.

AND

OR

Meeting manager

2009 Fall

| 58


9/22/2009

Goal Structuring Notation (GSN)

2009 Fall

| 59


9/22/2009

GSN example

2009 Fall

| 60


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


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


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


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 automatic machine communication

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

2009 Fall

| 64


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


9/22/2009

Use cases

› A description of a set of possible concrete scenariosthat 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


9/22/2009

Example

Phone user

Control environmental

volume

Turn down Turn offScenarios

2009 Fall

| 67


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


9/22/2009

When to use these elicitation methods to elicit different

requirements?

2009 Fall

| 69


9/22/2009

Business requirements

User requirements

Business goals and scope

Requirements

Documents

Use case

Software requirement specification (SRS)

LEGEND

FROther NFR

Quality attribute

“Easy registration”

“Register online”

“Register by providing name and email address”

availability

security

Levels of Software Requirements

2009 Fall

| 70


9/22/2009

Business requirements

User requirements

FR NFR

Hard data collection, Scenario-based

Read

ing existin

g docu

men

ts

Surveys & Questionnaires, Participant observation, Use cases

Interviews, Goal-based

JAD

/RA

D w

orkshop

sElicitation methods application

2009 Fall

| 71


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


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


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