Requirements Engineering Onno de Graaf Unit 2: o.de.graaf at - - PowerPoint PPT Presentation

9/ 8/ 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 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/ R

E2009Fall/ 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 (docum entation) › How to manage requirements traceability (m anagem ent)

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

Course outline

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

Requirem ents docum entation

Requirem ents negotiation

Requirem ents m anagem ent

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

Last Unit

Basic of Requirem ents Engineering

This Unit

Requirem ents Engineering process

Next Unit

Requirem ents 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

• utput

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 Qua lity of p rocess Qua lity of p rod uct

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. Requirem ents 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 Docum entation Managem ent

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

Spiral process

Start

Dom ain understanding & elicitation Analysis & negotiation

Alternative proposals Agreed requirem ents Docum ented requirem ents Consolidated requirem ents

Specification & docum entation Validation & Quality assurance

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

General RE process model

› Iterative process [Sommerville, 2005]

›

• I. Sommerville. Integrated Requirem ents 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 Requirem ents 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 Developm ent world

contra ct

System

b uild

Environm ent

intera ct

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

develop m ent

developer nestor vendor lecturer student teaching assistant university board university financial departm ent nestor adm inistrators

environ m ent

disorder m aker

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

Scoping - elicitation difficulties

› Lack of domain knowledge

• Public transportation system

› Tacit knowledge

• Incom e 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 departm ent 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

w hat operators actually do

• Conflict information
• Different m em ber of departm ents have different ideas

about the loan rules

• Bias
• The loan approval officers fear that com puter system w ill

take their job out of existence, so they deliberately em phasize 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

custom er 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 tim e for the start of classes” › But that’s just a symptom. (So you ask the m anager “why?”) › “ Because w e 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 w e never know w ho’s available to teach until the last m inute” › Is that just a symptom of some other problem? (… so ask the dept chair “why?”) › “ Because there’s alw ays uncertainty about w ho gets hired, sabbaticals, etc.” › Is that just a symptom of some other problem? (… so ask the dept chair “why?”) › “ Because instructors w e w ant 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 departm ent a long tim e to reach consensus on hiring” › Is that just a……

• h wait……

maybe we can develop a decision support system for faculty 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
• r assisted by softw are? If no, ask next question
• Is this a problem that the stakeholders w ant 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 com puterize the subm ission of textbook forms from instructors” › but w hen w e do that: › “it would help if we also com puterized the subm ission of orders to the publishers” › …and of course: › “we ought to com puterize the m anagem ent of book inventories, so we can quickly check stock levels before ordering new books” › …and in that case: › “we might as well com puterize 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. report
• Req. 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 docum ent › 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 Fall Peng Liang Requirements Engineering

Reading

• I. Sommerville. Integrated requirem ents engineering: a tutorial. IEEE Software, 22(1):16-23,

2005.

9/ 8/ 2009 | 61 2009 Fall Peng 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

• ne of them you are interested in details, deadline: 14.09.2009

Submission method

(1) should be sent to instructor by email