requirements engineering - university of · pdf file› no “ideal” or...
Post on 22-Mar-2018
215 Views
Preview:
TRANSCRIPT
9/8/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 2:
Requirements engineering process
2009 Fall
| 2
Peng Liang Requirements Engineering
9/8/2009
Student assistant of RE 2009 fall
› Onno de Graaf
› o.de.graaf at gmail.com• coordinate the external and internal meeting
during the tutorial session
• answer the questions and requests posed by students, and
• forward unsolved questions to me
2009 Fall
| 3
Peng Liang Requirements Engineering
9/8/2009
Grouping› [Group 1]: Ruurd Krekt, Pim van der Waak, Henk van Ramshorst,
Ralph van Brederode, Johan van der Geest, Mark Ettema › [Group 2]: Erwin Vast, Fernand Geertsema, Marco Hak, Jop
Verhagen, Mattijs Meiboom› [Group 3]: Anton Jongsma, Dirk Nederveen, Karsten Westra,
Tom Spanjaard, Mark Scheeve, Edwin-Jan Harmsma› [Group 4]: Chris de Wit, Eelco Hooghiem, Gertjan Dalstra,
Samuel Esposito, Artemios Kontogogos› [Group 5]: Gerhard Boer, Jeroen de Groot, Tim van Elteren, Rudy
Schoenmaker, Wilrik Mook, Pieter Stavast› [Group 6]: Jochem Pastoor, Stef van Grieken, Jan Wijma, Wilco
Wijbrandi, Joris de Keijser
2009 Fall
| 4
Peng Liang Requirements Engineering
9/8/2009
Course project deadlines
› Deadlines
› Start working as group
• Propose projects
• Select projects
› REWiki instances created for each group
2009 Fall
| 5
Peng Liang Requirements Engineering
9/8/2009
Cancel of the course next week
› I am away for WICSA 2009 conference
› Course schedule will be postponed
2009 Fall
| 6
Peng Liang Requirements Engineering
9/8/2009
Assignment of Week 36
› SRS from small tools, plug-ins to very complex system
› Requirements range from functional, non-functional, to all kinds of requirements
› I put some of best SRSs online for your reference
• http://www.cs.rug.nl/~liangp/teaching/courses/RE2009Fall/assignment/Week36-SRS.zip
2009 Fall
| 7
Peng Liang Requirements Engineering
9/8/2009
Your expectations / requirements
› How to elicit correct user requirements (elicitation)› How to communicate with non-technical customers
(elicitation)› How to deal with conflicting requirements (analysis,
negotiation)› How to prioritize requirements (analysis)› How to write understandable and testable SRS for
both developers and customers (documentation)› How to manage requirements traceability
(management)
2009 Fall
| 8
Peng Liang Requirements Engineering
9/8/2009
Course outlineRequirements Engineering
Requirements Engineering process
Requirements elicitation
Requirements analysis
Requirements validation
Requirements documentationRequirements
negotiation Requirements management
2009 Fall
| 9
Peng Liang Requirements Engineering
9/8/2009
Last UnitBasic of
Requirements Engineering This Unit
Requirements Engineering
process
Next UnitRequirements
elicitation
2009 Fall
| 10
Peng Liang Requirements Engineering
9/8/2009
Contents
› What is a Process?
› Why RE process?
› General RE process model
› Initiating an RE process
2009 Fall
| 11
Peng Liang Requirements Engineering
9/8/2009
What is a Process?
› An organized set of activities which transforms inputs to outputs
› Examples of process descriptions
• SCRUM process … activity
input output
2009 Fall
| 12
Peng Liang Requirements Engineering
9/8/2009
Why RE process?
› Control of quality, schedule, and cost
› Complexity: human, social and organizational factors
Quality of process Quality of product
2009 Fall
| 13
Peng Liang Requirements Engineering
9/8/2009
RE process: input and output
Existing system information
Stakeholders concerns
Organizational standards
Regulations and laws
Domain information
› G. Kotonya and I. Sommerville. Requirements Engineering: A Good Practice Guide. John Wiley & Sons, 1997.
RE process SRS
2009 Fall
| 14
Peng Liang Requirements Engineering
9/8/2009
RE process variability
› RE processes vary from one organization to another
• Project scale
• Organisational culture (XP, UP, SCRUM ...)
• Application domain
• ...
› No “ideal” or “uniform” Requirements Engineering process
2009 Fall
| 15
Peng Liang Requirements Engineering
9/8/2009
Buzz words on RE process
› Activities: identification, elicitation, derivation, analysis, definition, modeling, specification, documentation, communication, validation, negotiation, management, implementation, capturing, discovering, structuring, representing, formulating …
› Methods, means, tools, …
What steps should I follow?
2009 Fall
| 16
Peng Liang Requirements Engineering
9/8/2009
Waterfall process
Elicitation
Analysis
Validation
Negotiation
Documentation
Management
2009 Fall
| 17
Peng Liang Requirements Engineering
9/8/2009
Spiral process
Start
Domain understanding& elicitation
Analysis& negotiation
Alternative proposals
Agreed requirements
Documented requirements
Consolidated requirements
Specification& documentation
Validation& Quality assurance
2009 Fall
| 18
Peng Liang Requirements Engineering
9/8/2009
General RE process model
› Iterative process [Sommerville, 2005]
› I. Sommerville. Integrated Requirements Engineering: A Tutorial. IEEE Software, 22(1):16-23, 2005.
waterfall
spiral
2009 Fall
| 19
Peng Liang Requirements Engineering
9/8/2009
Requirements elicitation
› Obtain the requirements of a system from users, customers and other stakeholders
› Good requirements is not readily available from customers
2009 Fall
| 20
Peng Liang Requirements Engineering
9/8/2009
Requirements analysis and negotiation
› Discover the bounds of the software
› Detect and resolve conflicts between requirements
› Requirements prioritization & triage
2009 Fall
| 21
Peng Liang Requirements Engineering
9/8/2009
Requirements validation
› Ensure SRS define the right system
• SRS reviews
• Prototyping (GUI)
• Model validation (Z lang)
2009 Fall
| 22
Peng Liang Requirements Engineering
9/8/2009
Requirements documentation
› Production of a document that can be systematically reviewed, evaluated, and approved
• See our SRS examples
2009 Fall
| 23
Peng Liang Requirements Engineering
9/8/2009
Requirements management
› Manage the requirements when evolves
• change control
• Traceability management
2009 Fall
| 24
Peng Liang Requirements Engineering
9/8/2009
Initiate an RE process
How to start with elicitation?
2009 Fall
| 25
Peng Liang Requirements Engineering
9/8/2009
Starting a project
Stakeholders
Scope
2009 Fall
| 26
Peng Liang Requirements Engineering
9/8/2009
Starting points
› Who are my Stakeholders ?
› What is the Scope ?
› Is this project Feasible ?
› Any Risks ?
Starting a project in a right direction, then we can go step by step
2009 Fall
| 27
Peng Liang Requirements Engineering
9/8/2009
Stakeholders
› M. Glinz and R.J. Wieringa. Stakeholders in Requirements Engineering. IEEE Software, 24(2):18-20, 2005. page 2
Project world
2009 Fall
| 28
Peng Liang Requirements Engineering
9/8/2009
Project world
Usage world
Development world
contract
System
build
Environment
interact
2009 Fall
| 29
Peng Liang Requirements Engineering
9/8/2009
Stakeholders analysis
› Look for stakeholders associated with the project world• Usage, development, and environment
› Example stakeholders• End-users (usage)• Customers (usage)• User support staff (development)• Project manager (development)• Negative stakeholders (environment)
2009 Fall
| 30
Peng Liang Requirements Engineering
9/8/2009
Example of stakeholder identification
Nestor system
usage
development
developer
nestorvendor
lecturer
student
teaching assistant
university board
university financial
department
nestoradministrators
environment
disorder maker
2009 Fall
| 31
Peng Liang Requirements Engineering
9/8/2009
Scoping - elicitation difficulties
› Lack of domain knowledge
• Public transportation system
› Tacit knowledge
• Income for credit card
› Personal bias
• Political, personal, background
2009 Fall
| 32
Peng Liang Requirements Engineering
9/8/2009
Examples - Automatic loan approval system
› The problem area• Context: Loan approval department in a large bank
• Objective: The analyst tries to elicit the rules and procedures for approving a loan
2009 Fall
| 33
Peng Liang Requirements Engineering
9/8/2009
Examples - Automatic loan approval system
› Why difficult• Tacit knowledge
• The loan approval process described is quite different from what operators actually do
• Conflict information• Different member of departments have different ideas
about the loan rules
• Bias• The loan approval officers fear that computer system will
take their job out of existence, so they deliberately emphasize the need for case-by-case discretion
2009 Fall
| 34
Peng Liang Requirements Engineering
9/8/2009
How to mitigate these difficulties?
Tacit knowledge
Bias
2009 Fall
| 35
Peng Liang Requirements Engineering
9/8/2009
Bias is unavoidable with human beings
› How to mitigate
• Fear to the computer systems• try to specify clearly that computer system will assist their
work but not replacing their job
• Misinterpretation • Reiterate the requirements in your understanding and get
confirmation
• Political & organizational factors• try to talk the high level officials with key requirements (e.g.,
importance of system reliability, cost of system failure/day)
2009 Fall
| 36
Peng Liang Requirements Engineering
9/8/2009
Beat tacit knowledge out
customer developer
2009 Fall
| 37
Peng Liang Requirements Engineering
9/8/2009
Key tacit knowledge
› Scope of problem• to be solved by software
• refinement process
› Scope of solution• to be co-extended by
user and developer
• exploration process
User problems
solved by software
software solutions
Extended solutions
Problem space
Solution space
2009 Fall
| 38
Peng Liang Requirements Engineering
9/8/2009
Extended solutions
solved by software
User problems
software solutions
Scoping process
2009 Fall
| 39
Peng Liang Requirements Engineering
9/8/2009
Scope of problem - Textbook ordering example
› “Textbooks are often not ordered in time for the start of classes”› But that’s just a symptom. (So you ask the manager “why?”)› “Because we don’t receive the booklists from instructors early enough”› Is that just a symptom of some other problem? (…so ask the instructors “why?”)› “Because the instructors aren’t allocated to courses early enough”› Is that just a symptom of some other problem? (…so ask the general office “why?”)› “Because we never know who’s available to teach until the last minute”› Is that just a symptom of some other problem? (…so ask the dept chair “why?”)› “Because there’s always uncertainty about who gets hired, sabbaticals, etc.”› Is that just a symptom of some other problem? (…so ask the dept chair “why?”)› “Because instructors we want to hire don’t accept our offers early enough”› Is that just a symptom of some other problem? (…so ask the new recruits “why?”)› “Because it takes our department a long time to reach consensus on hiring”› Is that just a… …oh wait… …maybe we can develop a decision support system forfaculty hiring at university, and that will help us get our textbooks for the start of class…
2009 Fall
| 40
Peng Liang Requirements Engineering
9/8/2009
solved by software
User problems
Scoping of problems
2009 Fall
| 41
Peng Liang Requirements Engineering
9/8/2009
How to scope the problem space
› Keep on tracking the root cause till we can find possible solution using software
› Approach (ask yourself two questions)• Is there a expectation that this problem can be solved
or assisted by software? If no, ask next question
• Is this a problem that the stakeholders want solved?
2009 Fall
| 42
Peng Liang Requirements Engineering
9/8/2009
Scope of solution - Textbook ordering example
› delay in processing booklists from instructors is the right problem› “So, let’s computerize the submission of textbook forms from instructors”› but when we do that:› “it would help if we also computerized the submission of orders to the
publishers”› …and of course:› “we ought to computerize the management of book inventories, so we can
quickly check stock levels before ordering new books”› …and in that case:› “we might as well computerize the archives of past years booklists so that
we can predict demand better”› …and then of course there’s … oh, wait, this is going to cost millions! › Stop when users don’t want more
2009 Fall
| 43
Peng Liang Requirements Engineering
9/8/2009
Extended solutions
software solutions
Scoping of solutions
2009 Fall
| 44
Peng Liang Requirements Engineering
9/8/2009
How to scope the solution
› Decide when to stop adding extra “solutions”
› Approach (select among available solutions)• Is there a reasonable expectation that this solution
can be implemented?
• Is this a solution that someone will pay you to build?
2009 Fall
| 45
Peng Liang Requirements Engineering
9/8/2009
Feasibility studies
› Management-level activity (go/not go)
› Objective• Whether this project can be done (3 basic aspects)
• What the alternatives are (by redo scoping)
2009 Fall
| 46
Peng Liang Requirements Engineering
9/8/2009
Three aspects of feasibility
› Economic
› Technical
› Schedule
2009 Fall
| 47
Peng Liang Requirements Engineering
9/8/2009
Economic feasibility
› Benefit • Tangible (sales)
• Intangible (customer stickness)
› Cost• Development
• Operational
• Marketing
2009 Fall
| 48
Peng Liang Requirements Engineering
9/8/2009
Risks in RE
› Possible situation of suffering loss• Uncover new requirements (e.g. security risk)
• Uncover feasibility concern (e.g. cost, schedule risk)
• Assist in management action (mitigate risks ASAP)
2009 Fall
| 49
Peng Liang Requirements Engineering
9/8/2009
Risk assessment and control
› Techniques for risk assessment• Fault tree analysis
Logic relationships
Risk of A
Risk of 1
2009 Fall
| 50
Peng Liang Requirements Engineering
9/8/2009
Risk assessment and control
› Risk Assessment Matrix
2009 Fall
| 51
Peng Liang Requirements Engineering
9/8/2009
Sample risk assessment
› Risk(r) = p(r)*loss(r)• p = possibility of r• loss = weight of loss of r
2009 Fall
| 52
Peng Liang Requirements Engineering
9/8/2009
Risk management
› To identify them ahead and manage them in the whole project lifecycle
• Update risks status (p, r)
• Risk traceability (risk to sub-risks, risk to requirements)
• New risks when new requirements emerge
2009 Fall
| 53
Peng Liang Requirements Engineering
9/8/2009
Tool support for RE process
2009 Fall
| 54
Peng Liang Requirements Engineering
9/8/2009
CASE tools for RE
› Requirement management tools
• Telelogic DOORS
• Rational Requisitepro
• IRqA
• Many others (over 100) …
2009 Fall
| 55
Peng Liang Requirements Engineering
9/8/2009
Sample requirement management system
Requirement database
Req. browsers Req. query
Req. tractability support
Req. report generator
Req. tractability report
Req. reportReq. change
control
Req. converter
Req. document in NL
2009 Fall
| 56
Peng Liang Requirements Engineering
9/8/2009
Demo of RE tools
› GatheSpace (web-based RE tool)
› IRqA (desktop-based RE tool)
› REWiki (wiki-based RE tool)
2009 Fall
| 57
Peng Liang Requirements Engineering
9/8/2009
Tools with best practices in RE process
› Define a standard document structure (template)
› Uniquely identify each requirement (Req-ID)
› Use scenarios to elicit requirements (communication)
› Use checklists for requirements analysis (review)
› Specify requirements quantitatively (testable)
› Use prototyping to animate requirements (communication)
› Reuse requirements if possible (maximum reusablity)
2009 Fall
| 58
Peng Liang Requirements Engineering
9/8/2009
Review of today
› RE process
• A structured set of activities leading to the production of a requirements document
› Inputs to the RE process
• Information about existing systems
• Stakeholder needs
• Domain information
2009 Fall
| 59
Peng Liang Requirements Engineering
9/8/2009
Review of today
› RE processes vary from one to another, mostly
• Elicitation, analysis and negotiation, documentation, validation, management.
› Steps to initiate a RE process
• Stakeholder identification
• Scoping problems and solutions
› Best practices in RE
9/8/2009 | 60
2009 FallPeng Liang Requirements Engineering
Reading- I. Sommerville. Integrated requirements engineering: a tutorial. IEEE Software, 22(1):16-23, 2005.
9/8/2009 | 61
2009 FallPeng Liang Requirements Engineering
Course assignment - (1) Individual assignment, try to find out the different requirements elicitation methods (e.g., workshop, interview, storyboard, etc.) as many as you can, and describe one of them you are interested in details, deadline: 14.09.2009
Submission method(1) should be sent to instructor by email
top related