Requirements Engineering · Why requirement elicitation? › Typical requirement syndromes •...
Transcript of Requirements Engineering · Why requirement elicitation? › Typical requirement syndromes •...
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 elicitation
Requirements analysis
Requirement validation
Requirements documentationRequirements
negotiation Requirements management
2009 Fall
| 3
Peng Liang Requirements Engineering
9/22/2009
Last UnitRequirements
Engineering process This Unit
Requirements elicitation
Next UnitRequirements
modeling
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, WilcoWijbrandi, 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 (requirements elicitation method)• Questionnaires• Storyboard• Prototyping• Use cases (requirements representation method)• Workshop (organization method)• 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 Software Requirements: 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 where 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
34
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
HASHuman
InterventionController
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
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
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 Requirements 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 (Customer)
• 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 requirements, problems, and business process)
• Existing systems documentation (reusable requirements)
2009 Fall
| 31
Peng Liang Requirements Engineering
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
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? (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
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 objective)
› 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 refinement 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 maintain market 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 Requirements 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 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
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 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
Peng Liang Requirements Engineering
9/22/2009
Example
Phone user
Control environmental
volume
Turn down Turn offScenarios
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
FROther NFR
Quality attribute
“Easy registration”
“Register online”
“Register by providing name and email address”
availability
security
Levels of Software Requirements
2009 Fall
| 70
Peng Liang Requirements Engineering
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
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 FallPeng 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 FallPeng 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