[PPT] - Requirements Engineering Lecturer: Peng Liang Unit 1: Office: PowerPoint Presentation

SLIDE 1

9/ 1/ 2009 | 1/ 66 2009 Fall Peng Liang Requirements Engineering

Requirements Engineering

Unit 1: Basic of requirements engineering

› Department of Computer Science / Peng Liang › Rijksuniversiteit Groningen (RUG)

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

2009 Fall | 2/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course information

› Lecturer: Peng Liang › Office: Bernoulliborg V 5161.576 › Phone: 050-363 7480 › E-mail: p.liang at rug.nl › Contact: by email or appointment › Course website:

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

(slides, assignm ent deadlines, schedule, resources, reading list, etc.)

2009 Fall | 3/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course schedule

Tennishal X 5113.0201 13:00-16:00 09:00-12:00 Course project presentation by group (Week 43, 20.10.2009)

* Lab session

Thu (Week 36-43) X 5118.-149 13:15-15:00

Exam (30.10.2009)

2nd Exam (05-02-2010)

Sem inar days

(using lecture session) V 5161.0208 15:15-16:00

* Tutorial session

Thu (Week 36-43) V 5161.0253 (Week 42@X 5118.-156) 11:15-14:00

Lecture session

Tue (Week 36-43)

2009 Fall | 4/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course schedule every week

Mon Tue Wed Thu Fri tutorial

11:15

lecture

14 :0 0 13:15 15:0 0 * Tutorial sessions is used for group project discussion and meetings.

lab

15:15 16:0 0 * Lab sessions are is used for requirements documentation in REWiki.

SLIDE 2

2009 Fall | 5/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course rules

› Team work more important than written exam › Take a pen(cil) and paper for the course › Pose questions whenever you want

2009 Fall | 6/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course bibliography

› No single textbook covers the field well

A. van Lamsweerde. Requirem ents engineering: from sy stem goa ls to

UML m od els to softw a re sp ecifica tions. John Wiley & Sons, 2009

L.A. Maciaszek. Requirem ents a na ly sis a nd sy stem d esign (3rd edition).

Pearson Addison-Wesley, 2007

D. Leffingwell and D. Widrig. Ma na ging softw a re requirem ents: A Use

Ca se Ap p roa ch. Addison-Wesley, 2003.

G. Kotonya and I. Sommerville. Requirem ents Engineering: Processes

a nd Techniques. John Wiley & Sons, 1998.

I. Sommerville and P. Sawyer. Requirem ents Engineering: A Good

Pra ctice Guid e. John Wiley & Sons, 1997.

R.J. Wieringa. Requirem ents Engineering: Fra m ew orks for

Und ersta nd ing. Wiley, 1996.

› This course is practice-oriented

All papers and book links are available on the course website

2009 Fall | 7/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course objectives

› Explore the state-of-the-art practice in Requirements Engineering

Techniques, notations, methods, processes, and tools

› Gain practical experience in mature Requirements Engineering techniques

Elicit, analyze, document, validate, and manage

requirements

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

Fundamental skills

› Interviewing and teamwork skills for requirements elicitation and validation › Analysis and modelling skill for problem solving › Writing skill for requirements specification

SLIDE 3

2009 Fall | 9/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course outline

Requirem ents engineering Requirem ents engineering process Requirem ents elicitation Requirem ent analysis Requirem ent validation

Requirem ents docum entation

Requirem ent negotiation

Requirem ents m anagem ent

2009 Fall | 10/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course content explanation

› Expectations from RE course 2008 › Software engineering and RE course › Zooming in requirements engineering › Course limitations

2009 Fall | 11/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Expectations from RE course 2008

› Show us the step-by-step method to examine and document the needs of customers; › Apply the methods in practices with a project; › New information other than content already introduced in SE, SDP courses;

2009 Fall | 12/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

SE course and RE course

› RE as a subset of SE RE SE

use case m odeling RE process FR & NFR project m anagem ent Software architecture patterns bug tracking strategy Software evolution Software process

SLIDE 4

2009 Fall | 13/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

all these topics based

n concrete examples

and projects.

Zooming in requirements engineering

RE

Requirem ents triage Goals decom position Resolving conflicting requirem ents Requirem ents prioritization Techniques on Requirem ents validation How to write good requirem ents Requirem ents tractability RE tools, DOORS, IRqA, RequisitPro

2009 Fall | 14/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Example - detail topics on RE

› How to start a RE process, and proceed step by step? What specific information should we collect and acquire? (handbook) › How to identify the stakeholders in a large project? (experience) › How to perform specific requirement elicitation methods, and use them in a real project? (practices) › How to model the requirements using different modeling approaches? (practices)

2009 Fall | 15/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course limitations

› We have not real industrial projects, but we can try some projects smaller › We are not working on a real project environment, but we can simulate it › We learn RE knowledge, but still you have to apply them into large and complex industrial projects

2009 Fall | 16/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Course grading

› 50%: Group project

Requirement report (in English) based on a

practical software project

Project presentation per group

› 20%: Individual assignment › 30%: Final written exam

SLIDE 5

2009 Fall | 17/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Group project

› Learning by role playing › interviewing, soft skill, communication styles

2009 Fall | 18/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Group project

› Each team consists of 5-6 students

to simulate a real small project team

› Each team propose an appropriate project

to simulate a real customer

› Instructor coordinates the assignment of projects

to choose the project your group likes

› To complete this project by role playing

to simulate a real environment of a project

2009 Fall | 19/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Role playing

› Roles played by team

As Developer team & Customer team

› Roles played by individual student

Developer team: team leader, administrative

assistant, requirements engineer

Customer team: domain expert, end-user

2009 Fall | 20/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Team composition

Team Leader Adm inistrative Assistant Requirem ents Engineer Dom ain Expert End-user

Team A

As Developer team As Custom er team

SLIDE 6

2009 Fall | 21/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Role’s responsibility

› Team leader: allocate responsibilities, prepare the agenda for w eekly m eeting w ith custom er team › Administrative assistant: in charge of m inutes taking during m eetings › Requirements engineer: to elicit, analyze, specify, validate, and m anage requirem ents › Domain expert: person w ith special know ledge or skills in a particular area (e.g., expert on library m anagem ent ) › End-user: person w ho w ill directly use the system being developed (e.g., librarian)

2009 Fall | 22/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Team interaction

Team A

Developer

Team A

Custom er

Team B

Custom er

Team D

Developer

Team B

Developer

Team C

Developer

Team C

Custom er

Team D

Custom er

2009 Fall | 23/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Meeting schedule every week

Team Leader

prepare an agenda for the meeting and points to be discussed, and distribute it to all stakeholders

1

2009 Fall | 24/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Meeting schedule every week

Team A

Developer

Team B

Custom er

<45 min

Team Leader

1 2

External meeting between developer and customer teams should be short and productive (less than 45 minutes).

SLIDE 7

2009 Fall | 25/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Meeting schedule every week

Team A

Developer

Team B

Custom er

<45 min

Team A

Developer

30~45 min

Team Leader

1 2 3

Internal discussion to solve the issues posed by customer team

2009 Fall | 26/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Meeting schedule every week

Team A

Developer

Team B

Custom er

<45 min

Team A

Developer

30~45 min

Team Leader

Team A

Developer

30~45 min

1 2 3 4

Document the requirements using REWiki

2009 Fall | 27/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Meeting schedule every week

Team A

Developer

Team B

Custom er

<45 min Thu tutorial lab 45 min * 2 45 min

Team A

Developer

30~45 min

Team Leader

Team A

Developer

30~45 min

1 2 3 4

2009 Fall | 28/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Submissions every week

› Meeting agenda (by Team leader) › Meeting minutes (by Adm inistrative assistant) › I will check your online work on REWiki based on these two documents

SLIDE 8

2009 Fall | 29/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Team tasks as developer team

› Elicit requirements from the customers › Analyse those requirements › Specify and document the requirements › Validate requirements, and › Manage the artefacts and the process of requirements engineering throughout all the these activities

2009 Fall | 30/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Team tasks as customer team

› Provide their needs to the developer team › Provide their preferences on how they want to use the system › Provide the domain knowledge about their needs › Answer questions from developer team

2009 Fall | 31/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Candidate project proposed by each group

› Think about the system in a customer's view › A particular problem/ area that needs a computer- based solution › The requirements for such system should be able to specify in 5-6 weeks of two and half-hours sessions › Examples

Travelling planning system
Internet banking system
Education feedback system

2009 Fall | 32/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Role playing rules

Team Leader Adm inistrative Assistant Requirem ents Engineer Dom ain Expert End-user

SLIDE 9

2009 Fall | 33/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Role playing rules

› Each group member should play all the roles at least

nce throughout the course period.

› In order to get a full exposure to the range of requirements engineering issues

2009 Fall | 34/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

REWiki

2009 Fall | 35/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Tell me your idea

› Write down in 10 minutes

3~5 requirements based on the software

development projects (e.g., tools, computer programs) you have implemented.

Think about (write down) the rationale of these

requirements (if possible).

e.g., “The system shall be able to com pare and sort the

prices of sam e product. (ra tiona l: Users alw ays w ant to know the cheapest product.) ”

2009 Fall | 36/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Why this course?

› Requirements engineering everywhere IRqA Custom ers

Transport & Utilities, Autom otive & Electronics, Pharm aceutical, Services, etc.

SLIDE 10

2009 Fall | 37/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Why this course?

It is more important to understand the p roblem than the solution.

Albert Einstein

problem solution

2009 Fall | 38/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

The importance of requirements

2009 Fall | 39/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

RE: A Process to satisfy your customer

2009 Fall | 40/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

RE is not only software techniques

› Social effect › Business strategy › Human communication › …

RE Iceberg

Social Business Human software

Project Ship

SLIDE 11

2009 Fall | 41/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Starting This Unit

Basic of Requirem ents Engineering

Next Unit

Requirem ents Engineering process

2009 Fall | 42/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

You may have heard about this …

Requirem ents Design Code Other

Source: Dean Leffingwell & Jam es Martin, An Inform ation System s Manifesto

The source of software errors

2009 Fall | 44/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

You may have heard about this …cont’d

10 20 30 4 0 50 6 0 70 Requirem ents Design Code Developm ent Testing Acceptance Testing Operation Relative Cost to Correct a Defect Source: Barry W. Boehm , Software Engineering Econom ics

SLIDE 12

2009 Fall | 45/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

You may have heard about this …cont’d

% Requirem ents Managem ent Cost com pared to total project cost

0 - 5% invested in R eq. Management r esults in 80 – 200%

ver

cost 8 - 14% invested in R eq. Management r esults in 0 – 60%

ver

cost Pr

ject Analyzed

5 10 15 20 25 200 180 160 140 120 100 80 60 40 20 % Overcost

Source: Ivy Hooks

2009 Fall | 46/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Software lifecycle and Error propagation

Requirement Specification Design Implementation Testing Evolution The real problem

Correct spec. Erroneous spec. Correct Design Erroneous design Design based on

erroneous spec.

Correct prog. Erroneous prog.

Prog. based on

erroneous design

Correct functions Correctable errors Uncorrectable errors Untraceable errors

Prog. based on

erroneous spec.

2009 Fall | 47/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Example of failed requirements engineering

› Office Clippy (assistant)

included in MS Office 97 to 2003

› Removed due to widespread dissatisfaction …

2009 Fall | 48/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Example of failed requirements engineering

› Microsoft Bob

released in March 1995 for Windows 95, provided

a new, non-technical interface to desktop computing operations › Project stopped due to ambitious features …

SLIDE 13

2009 Fall | 49/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

What is RE, roughly …

› Analyze problems with an existing system (system-as-is) › Identify objectives & opportunities for new system (system-to-be) › Define functionalities of, constraints on, responsibilities in system-to-be › Specify all of these in a requirement document

System = Software + Environment

(humans, hardware, and other software)

2009 Fall | 51/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

how a nd w here the sy stem w ill be used

Definition of RE

not a single p ha se or sta ge com m unica tion is a s im p orta nt a s a na ly sis

RE is a set of activities concerned with identifying and com m unicating the purpose of a software-intensive system, and the context in which it will be used. Hence, RE acts as the bridge between the real world need of users, customers, and other stakeholders affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies

p a rtly a bout w ha t is need ed p a rtly a bout w ha t is p ossible a ll the sta kehold ers

2009 Fall | 52/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

What is a Requirement?

› A requirement is a singular docum ented need of what a particular product or service should be or do. [Wikipedia, 2007] › Requirements are specifications of the services that the system should provide, the constraints on the system and the background inform ation that is necessary to developing the system [Zave, 1997] › Requirements are …a specification of what should be

implemented. They are descriptions of how the system should

behave, or of a system property or attribute. They may be a constraint on the development process of the system [Sommerville & Sawyer, 1997]

›

Wikipedia. Requirem ent. http:/ / en.w ikipedia.org/ w iki/ Requirem ent, 2007.

›

P. Zave. Classification of Research Efforts in Requirem ents Engineering. ACM Computing Surveys, 29(4):315-321, 1997.

›

I. Sommerville and P. Sawyer. Requirem ents Engineering: A Good Practice Guide. John Wiley & Sons, 1997.

2009 Fall | 54/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Forget those tedious definitions, see some examples

2009 Fall | 55/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Your examples

› Text editor, Compiler, Debugging tools? › Ask for conformation before delete › The program should always respond within 5 seconds › The software should be able to measure the usage of electricity 50 times per second.

2009 Fall | 56/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Requirement example 1

› Assignment for Programming Language Course

“Write a program that will read in a list of 100 positive

integers, sort them in ascending order, display the sorted list and display the average of the numbers” 90 23 12 .. .. 78 45 Rea d Disp la y Sort .. 90 78 45 23 12 .. 48

Av era ge v a lue

Disp la y

SLIDE 15

2009 Fall | 57/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Requirement example 1

› Requirements list

Read in a list of 100 positive integers
Sort the list of integers in ascending order
Display the sorted list and average of the numbers

Software-requirement specification User-requirement specification

vs.

› C.A. Gunter, E.L. Gunter, M. Jackson and P. Zave. A Reference Model for Requirem ents and Specifications. IEEE Software, 22(1):16-23, 2005. 2009 Fall | 58/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Requirement example 2

› Security requirements for a Home Automation System (HAS)

R2: The alarm signal shall start

immediately after the detection of the

pen window or door. (refer to R78)
R2.1: The alarm signal shall be

deactivated by the police, by the

wner, or automatically after 20 min.
R78: The time period between motion

detection and start of alarm signal shall be less than 0.5 seconds.

2009 Fall | 59/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Types of requirements

› Functional (FRs) and Non-functional (NFRs) requirements

FRs describe the functionality of the system (e.g.,

use cases)

NFRs describe system properties (e.g.,

performance, usability, security, maintainability… )

›

L. Chung, B.A. Nixon, E. Yu and J. Mylopoulos. Non-functional Requirem ents in Softw are Engineering. Kluwer Academic Publishers,

2000. 2009 Fall | 60/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Functional requirements (FRs)

› Describes WHAT, not HOW

Functions captured in use cases (UML)
Behaviors can be analyzed by sequence diagram,

state chart diagram (UML)

FRs trace to individual chunks of a program

SLIDE 16

2009 Fall | 61/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Non-functional requirements (NFRs)

› Define overall qualities, attributes and constrains of the resulting system

e.g., safety, security, usability, reliability and

performance requirements › The system is useless when NFRs are not met.

2009 Fall | 62/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

NFR examples

› NFR1: The time period between motion detection and start of alarm signal shall be less than 0.5 seconds. › NFR2: The signal power line transmission shall use the standard X10.

2009 Fall | 63/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Example (NFR to FR)

› NFR1: The system shall ensure that data is protected from unauthorized access.

Conventionally, this would be considered as a NFR because

it does not specify specific system functionality which must be provided. However, it could have been specified in slightly more detail as follows:

FR1: The system shall include a user authorization

procedure where users m ust identify them selves using a login nam e and password. Only users who are authorized in this way may access the system data.

2009 Fall | 64/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

NFR types defined by IEEE-Std 830-1998

› Interface › Standards compliance › Performance › Reliability › Availability › Security › Maintainability › Portability

›

IEEE. IEEE Recom m ended Practice for Softw are Requirem ents Specification (IEEE-Std 830-1998). IEEE, 1998.

SLIDE 17

2009 Fall | 65/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Boehm’s NFR list

NFR Process Requirement Product Requirement External Requirement Delivery Implementation Standard Usability Reliability Safety Efficiency Performance Capacity Legal constraints Economic constraints Interoperability

› B.I. Blum. Softw are Engineering:A Holistic View . Oxford University Press, 1992. P176 2009 Fall | 66/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Levels of requirements

› Business goals › User requirements (FRs and NFRs) › System and Software requirements

› C.A. Gunter, E.L. Gunter, M. Jackson and P. Zave. A Reference Model for Requirem ents and Specifications. IEEE Software, 22(1):16-23, 2005. 2009 Fall | 67/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Metaphor: building a house

› Business goals

I want a cheap house.

› User requirements

The cost of this house can not be higher than my total income

in the future 10 years.

› System requirements

The land cost can not be higher than 50% of the whole cost of

the house.

› Software requirements

Use the cheap but safe building material to build the house.

2009 Fall | 68/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Examples: home security requirements in HAS

› Business goals

I want a safety house.

› User Requirements

The HAS shall protect again burglary.
The HAS shall react quite fast.

› System Requirements

SR1: Video surveillance; SR2: Alarm activation

› Software Requirements

R2: The alarm signal shall start im m ediately after the detection of

the open window or door.

R2.1: The alarm signal shall be deactivated by the police, by the
wner, or automatically after 20 min.

SLIDE 18

2009 Fall | 69/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Next week

› How to do with RE with

different source of requirements,
different stakeholders
different software types

› RE process

The RE Process

2009 Fall | 70/ 77 Peng Liang Requirements Engineering 9/ 1/ 2009

Review of today

› Importance of requirement for project success › Requirements are not only functional › Requirements are not in the same level

9/ 1/ 2009 | 71/ 66 2009 Fall Peng Liang Requirements Engineering

Reading

B. Cheng and J. Atlee. Research directions in requirem ents engineering. Proceedings of the 29th

International Conference on Future of Software Engineering (FOSE), pages 285-303, 2007.

B. Nuseibeh and S. Easterbrook. Requirem ents engineering: a roadm ap. Proceedings of the 22nd

International Conference on Future of Software Engineering (FOSE), pages 35-46, 2000.

A. van Lamsweerde. Requirem ents engineering in the year 00: a research perspective.

Proceedings of the 22nd International Conference on Software Engineering (ICSE), pages 5-19, 2000.

9/ 1/ 2009 | 72/ 66 2009 Fall Peng Liang Requirements Engineering

Course assignment

(1) Find a sample requirements specification document, and read it, deadline:

07.09.2009

(2) What’s your expectations for this course? deadline: 07.09.2009
(3) Project group composition (members info), deadline: 07.09.2009

Submission method

(1), (2): should be sent to instructor by email (3): send e-mail to instructor with group members info by team leader