requirements engineering - university of · pdf file› no “ideal” or...

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


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


9/8/2009

Course project deadlines

› Deadlines

› Start working as group

• Propose projects

• Select projects

› REWiki instances created for each group

2009 Fall

| 5


9/8/2009

Cancel of the course next week

› I am away for WICSA 2009 conference

› Course schedule will be postponed

2009 Fall

| 6


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


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


9/8/2009

Course outlineRequirements Engineering

Requirements Engineering process

Requirements elicitation

Requirements analysis

Requirements validation

Requirements documentationRequirements

negotiation Requirements management

2009 Fall

| 9


9/8/2009

Last UnitBasic of

Requirements Engineering This Unit

Requirements Engineering

process

Next UnitRequirements

elicitation

2009 Fall

| 10


9/8/2009

Contents

› What is a Process?

› Why RE process?

› General RE process model

› Initiating an RE process

2009 Fall

| 11


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


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


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


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


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


9/8/2009

Waterfall process

Elicitation

Analysis

Validation

Negotiation

Documentation

Management

2009 Fall

| 17


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


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


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


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


9/8/2009

Requirements validation

› Ensure SRS define the right system

• SRS reviews

• Prototyping (GUI)

• Model validation (Z lang)

2009 Fall

| 22


9/8/2009

Requirements documentation

› Production of a document that can be systematically reviewed, evaluated, and approved

• See our SRS examples

2009 Fall

| 23


9/8/2009

Requirements management

› Manage the requirements when evolves

• change control

• Traceability management

2009 Fall

| 24


9/8/2009

Initiate an RE process

How to start with elicitation?

2009 Fall

| 25


9/8/2009

Starting a project

Stakeholders

Scope

2009 Fall

| 26


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


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


9/8/2009

Project world

Usage world

Development world

contract

System

build

Environment

interact

2009 Fall

| 29


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


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


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


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


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


9/8/2009

How to mitigate these difficulties?

Tacit knowledge

Bias

2009 Fall

| 35


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


9/8/2009

Beat tacit knowledge out

customer developer

2009 Fall

| 37


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


9/8/2009

Extended solutions

solved by software

User problems

software solutions

Scoping process

2009 Fall

| 39


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


9/8/2009

solved by software

User problems

Scoping of problems

2009 Fall

| 41


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


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


9/8/2009

Extended solutions

software solutions

Scoping of solutions

2009 Fall

| 44


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


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


9/8/2009

Three aspects of feasibility

› Economic

› Technical

› Schedule

2009 Fall

| 47


9/8/2009

Economic feasibility

› Benefit • Tangible (sales)

• Intangible (customer stickness)

› Cost• Development

• Operational

• Marketing

2009 Fall

| 48


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


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


9/8/2009

Risk assessment and control

› Risk Assessment Matrix

2009 Fall

| 51


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


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


9/8/2009

Tool support for RE process

2009 Fall

| 54


9/8/2009

CASE tools for RE

› Requirement management tools

• Telelogic DOORS

• Rational Requisitepro

• IRqA

• Many others (over 100) …

2009 Fall

| 55


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


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


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


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


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


Reading- I. Sommerville. Integrated requirements engineering: a tutorial. IEEE Software, 22(1):16-23, 2005.

9/8/2009 | 61


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

requirements engineering - university of · pdf file› no “ideal” or...

Documents