Requirements Engineering Requirem ents Engineering Unit 6: - - PowerPoint PPT Presentation

▶
requirements engineering
SMART_READER_LITE
LIVE PREVIEW

Requirements Engineering Requirem ents Engineering Unit 6: - - PowerPoint PPT Presentation

Jul 21, 2023 361 likes •626 views

10/ 13/ 2009 | 1 10/ 13/ 2009 | 2 Course outline Requirements Engineering Requirem ents Engineering Unit 6: Requirem ents Engineering process Use case approach for requirements management Requirem ents elicitation Department of

slide-1
SLIDE 1

10/ 13/ 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 6:

Use case approach for requirements management

2009 Fall | 2 Peng Liang Requirements Engineering 10/ 13/ 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 | 3 Peng Liang Requirements Engineering 10/ 13/ 2009

Last Unit

Requirem ents specification & validation

This Unit

Requirem ents m anagem ent

Next Unit

Agile requirem ents

2009 Fall | 4 Peng Liang Requirements Engineering 10/ 13/ 2009

Contents

› From use cases to implementation › From use cases to test cases › Tracing requirements › Managing requirements change

slide-2
SLIDE 2

2009 Fall | 5 Peng Liang Requirements Engineering 10/ 13/ 2009

From use cases to implementation

2009 Fall | 6 Peng Liang Requirements Engineering 10/ 13/ 2009

Use case centric requirements management

design

2009 Fall | 7 Peng Liang Requirements Engineering 10/ 13/ 2009

From use cases to implementation

› Simple requirements can be directly mapped to design and code

Disp la y the p rogress ba r

2009 Fall | 8 Peng Liang Requirements Engineering 10/ 13/ 2009

From use cases to implementation

› BUT most of requirements are orthogonal with design and implementation

  • UC-01 : “edit field”
  • FR-01: “user shall edit fields in accordance w ith the

user privileges established by system adm inistrator”

  • NFR-01: “

the system shall handle up to 100,000 users sim ultaneously”

slide-3
SLIDE 3

2009 Fall | 9 Peng Liang Requirements Engineering 10/ 13/ 2009

So how to map complex use case to implementation?

2009 Fall | 10 Peng Liang Requirements Engineering 10/ 13/ 2009

Object orientation

traceability UML diagram series

2009 Fall | 11 Peng Liang Requirements Engineering 10/ 13/ 2009

Object orientation example

› FR-01: “user shall edit fields in accordance w ith the user privileges established by system adm inistrator”

File Adm inistration System

2009 Fall | 12 Peng Liang Requirements Engineering 10/ 13/ 2009

From use case to interaction diagram

slide-4
SLIDE 4

2009 Fall | 13 Peng Liang Requirements Engineering 10/ 13/ 2009

Identify classes from interaction diagram

2009 Fall | 14 Peng Liang Requirements Engineering 10/ 13/ 2009

Architectural views

Water Engineer Electrical Engineer Security engineer Structural Engineers

2009 Fall | 15 Peng Liang Requirements Engineering 10/ 13/ 2009

4+1 architectural view

sta kehold ers Cla ss, sub sy stem s sta techa rt d ep loy m ent com p onent Use ca se

›

  • P. Kruchten. Architectural Blueprints—The “

4+1”View Model of Softw are Architecture. IEEE Software, 12(6):42-50, 1995. 2009 Fall | 16 Peng Liang Requirements Engineering 10/ 13/ 2009

The “newer” 4+1 view and SOA (web service)

Structural Packaging/Implementation Behavioral Infrastructure/ Environment

Use cases, Test case/ Validation Criteria

Service Contract(s)

Classes and Components (EJB) that physically represent the service Workflows showing how the service fulfils a logical business-unit-of- work (BPEL). Also includes intra- service behavioral models Service interface (WSDL) and usage semantics. Includes service policy definitions and metadata Deployment on .Net and/or J2EE – emphasis on reliability, availability and security.

slide-5
SLIDE 5

2009 Fall | 17 Peng Liang Requirements Engineering 10/ 13/ 2009

Role of use case in software architecture

› Use cases

  • Drive the design
  • Link all architectural view
  • Check the implementation
  • Project control (baseline/ iteration)

2009 Fall | 18 Peng Liang Requirements Engineering 10/ 13/ 2009

From use cases to test cases

2009 Fall | 19 Peng Liang Requirements Engineering 10/ 13/ 2009

From use cases to test cases

› Use case is a natural assets for testing process

  • actor, interactions, steps
  • black-box

› Use cases provide template for writing test cases

2009 Fall | 20 Peng Liang Requirements Engineering 10/ 13/ 2009

Scenarios in a use case

› A use case execution wherein a user executes the use case in a specific way

Scenario-0 1: Basic flow, Alternate flow 1, Alternate flow 2

slide-6
SLIDE 6

2009 Fall | 21 Peng Liang Requirements Engineering 10/ 13/ 2009

Deriving test case from use case

› Step1: Identify the use case scenarios › Step2: For each scenario, identify one or more test cases › Step3: For each test case, identify the conditions that will cause it to execute › Step4: Complete the test case by adding data values

2009 Fall | 22 Peng Liang Requirements Engineering 10/ 13/ 2009

Step1: Identify the use case scenarios

Alternate flow 4 Alternate flow 3 Basic flow SN8 Alternate flow 4 Basic flow SN7 Alternate flow 2 Alternate flow 1 Alternate flow 3 Basic flow SN6 Alternate flow 1 Alternate flow 3 Basic flow SN5 Alternate flow 3 Basic flow SN4 Alternate flow 2 Alternate flow 1 Basic flow SN3 Alternate flow 1 Basic flow SN2 Basic flow SN1 Next Alternate Next Alternate Alternate Flow Originating Flow SN

2009 Fall | 23 Peng Liang Requirements Engineering 10/ 13/ 2009

Step2: Identify the test cases

Scenario 2 TC3 Scenario 2 TC2 Scenario 1 TC1 Actual Result Expected Result Data Value N Data Value 2 Data Value 1 Scenario/ Condition Test Case ID Scenario2: The user enters the desired lighting sequence for each day of the w eek up to a m a xim um of sev en different daily settings. The system confirm s acceptance of each daily entry w ith a beep.

Lighting Control System

TC2: correct num ber of daily settings is entered, Sequence saved w ith a beep TC3: invalid num ber of daily setting is entered, Error m essage

2009 Fall | 24 Peng Liang Requirements Engineering 10/ 13/ 2009

Step3: Identify the test conditions

specific conditions that cause the test case to execute Valid Test conditions Invalid N/ A Step4: Add data values to test case

TC2: 0 -7 TC3: >8

slide-7
SLIDE 7

2009 Fall | 25 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirements to software artifacts

2009 Fall | 26 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirements

› Benefit

  • high-assurance software process
  • improving the software quality

and reliability › Shortage

  • High cost for producing and

maintaining traceability (value vs. cost)

specification architecture design im plem entation testing

2009 Fall | 27 Peng Liang Requirements Engineering 10/ 13/ 2009

Generalized traceability model based on UC

business goals High level requirem ent NFRs, Design Constrains

2009 Fall | 28 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirement to requirement

› Traceability Matrix: Tracing Features to Use cases

X X Feature m Feature n X X Feature 2 X Feature 1 Use Case k Use Case i Use Case 2 Use Case 1

Use case 1 is a gratuitous use case Feature n needs to be defined by som e use case

slide-8
SLIDE 8

2009 Fall | 29 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirement to requirement

X Goal-04 X X Goal-03 X X Goal-02 X Goal-01 Feature k Feature i . . . Feature 1 X Requirement m X X X Requirement n X X Requirement 2 X X Requirement 1

…

NFR-0p . . . NFR-01

System wide NFR

2009 Fall | 30 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirements to implementation

2009 Fall | 31 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing requirements to testing

› Tracing use cases to test cases

  • Scenario are thread of concrete operations

to get valuable result

  • Test cases are set of input and output given

to the system

2009 Fall | 32 Peng Liang Requirements Engineering 10/ 13/ 2009

Tracing use cases to test case scenarios

UC: Control light TS: v erify ing tha t a user is a ble to op en the light TC1: user can push the open light button TC2: pushing the button, the electricity w ill be current TC3: current electricity w ill turn

  • n the light
slide-9
SLIDE 9

2009 Fall | 33 Peng Liang Requirements Engineering 10/ 13/ 2009

Using requirements traceability tools

› Traceability matrix generation and maintenance › Conflict and completeness analysis › For a small project (1-10 person.year, KLOC)

  • Spreadsheet, database, REWiki

› For larger project (above 100 person.year, MLOC)

  • Specialized requirements management tools

2009 Fall | 34 Peng Liang Requirements Engineering 10/ 13/ 2009

REWiki

Traceability from stakeholders to requirements

2009 Fall | 35 Peng Liang Requirements Engineering 10/ 13/ 2009

Telelogic DOORS

traceability

Architectura l Design Sy stem Requirem ents User Requirem ents

2009 Fall | 36 Peng Liang Requirements Engineering 10/ 13/ 2009

IBM Rational RequisitePro

http:/ / www.ibm .com / developerworks/ downloads/ r/ rrp/

Fea tures Tra cea bility Ma trix Use ca ses

slide-10
SLIDE 10

2009 Fall | 37 Peng Liang Requirements Engineering 10/ 13/ 2009

Just right amount of traceability

› Identify the right traceability critical for your project

  • business goals vary frequently
  • requirement to requirement traceability is critical
  • Architecture will be used for a long time
  • Requirement to architecture views traceability is

important

2009 Fall | 38 Peng Liang Requirements Engineering 10/ 13/ 2009

How to manage requirements change

2009 Fall | 39 Peng Liang Requirements Engineering 10/ 13/ 2009

Managing requirements change

› Requirement change

  • External factors
  • Business change (market, business strategy)
  • Problem change (regulations, technology)
  • Environment change (hardware and software)
  • User change their mind
  • Internal factors
  • Incomplete requirements elicitation
  • Iterating from requirements to design causes new

requirements (two peak model)

2009 Fall | 40 Peng Liang Requirements Engineering 10/ 13/ 2009

Process for managing requirements change

› Baseline the requirements › Establish a single channel to control change › Change control system to capture changes › Manage change hierarchically

slide-11
SLIDE 11

2009 Fall | 41 Peng Liang Requirements Engineering 10/ 13/ 2009

Step1: Baseline the requirements

› Baseline for the development team › Compare new requirements against the baseline › Version control

Business goals, Features, Use cases, FRs, NFRs V1 V2 V3 V4

2009 Fall | 42 Peng Liang Requirements Engineering 10/ 13/ 2009

Step1: Baseline the requirements

› Requirements change rate of 1-4% each month during the course of development is appropriate › Requirements change rate over 6% each month is a very serious risk to the project

Previous baseline (PB) New baseline (NB)

Requirem ent Change rate = (NB-PB)/ (PB)%

2009 Fall | 43 Peng Liang Requirements Engineering 10/ 13/ 2009

Step2: Establish single channel to control change

› Who are responsible to make official decision about whether the change is going to be made › For small projects

  • Product manager/ Team leader

› For larger systems

  • CCB (change control board, key stakeholders)

2009 Fall | 44 Peng Liang Requirements Engineering 10/ 13/ 2009

Step3: Use change control system to capture changes › Change can take place at any level from requirements to coding and testing

“ I'm trying to enter a new em ployee into m y payroll system , but w henever I have an em ployee w hose first nam e is m ore than 16 characters, the program crashes."

Is this a coding bug or new requirem ent (allow em ployee nam es of up to 16 chars)?

End-user

slide-12
SLIDE 12

2009 Fall | 45 Peng Liang Requirements Engineering 10/ 13/ 2009

Step3: Change control system to capture changes

CCB 1 2 3

2009 Fall | 46 Peng Liang Requirements Engineering 10/ 13/ 2009

Step4: Manage change hierarchically

› Top-down hierarchical management to make sure the traceability update

2009 Fall | 47 Peng Liang Requirements Engineering 10/ 13/ 2009

Review of today

› Manage software artifacts using use case as the core artifacts › Techniques for tracing and managing the requirements from a use case point of view

10/ 13/ 2009 | 48 2009 Fall Peng Liang Requirements Engineering

Reading

  • V. Kirova, N. Kirby, D. Kothari and G. Childress. Effective requirements traceability: models, tools,

and practices. Bell Labs Technical Journal, 12(4):143-157, 2008.

slide-13
SLIDE 13

10/ 13/ 2009 | 49 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 7: Agile requirements

2009 Fall | 50 Peng Liang Requirements Engineering 10/ 13/ 2009

Course outline

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

Requirem ent docum entation

Requirem ent negotiation

Requirem ent m anagem ent

A g i l e ?

2009 Fall | 51 Peng Liang Requirements Engineering 10/ 13/ 2009

Last Unit

Requirem ents m anagem ent

This Unit

Agile requirem ents m ethod

In the future

2009 Fall | 52 Peng Liang Requirements Engineering 10/ 13/ 2009

Contents

› Why agile RE? › Guidelines of agile RE

slide-14
SLIDE 14

2009 Fall | 53 Peng Liang Requirements Engineering 10/ 13/ 2009

Agility

› A definition

  • “the ability to both create and respond to

change in order to profit in a changing business environment” Jim Highsmith, 2002

2009 Fall | 54 Peng Liang Requirements Engineering 10/ 13/ 2009

Agile manifesto (values)

› Individuals and interactions over process and tools › Working software over comprehensive documents › Custom er collaboration over contract negotiation › Responding to a change over following a plan

Adaptation Anticipation

  • ver

2009 Fall | 55 Peng Liang Requirements Engineering 10/ 13/ 2009

Agile software development

› Agile Modeling › Agile Unified Process › Extreme programming (XP) › Feature Driven Development (FDD) › Lean Development › Scrum (Iterative incremental process)

2009 Fall | 56 Peng Liang Requirements Engineering 10/ 13/ 2009

Why agile RE?

Changing world Changing requirements

slide-15
SLIDE 15

2009 Fall | 57 Peng Liang Requirements Engineering 10/ 13/ 2009

Traditional RE vs. Agile RE

› Traditional RE

  • Up-front requirements
  • Massive documentation
  • “

system should be clearly specified before its design and im plem entation can start” › Agile RE

  • Latest Responsible Moment decision making
  • “

put off decision (docum entation) as long as you can till the latest responsible m om ent”

2009 Fall | 58 Peng Liang Requirements Engineering 10/ 13/ 2009

Decide it, and do it Any requirement decisions made ahead of the responsible moment will be waste of effort ! But deciding the latest responsible time is a trick !

2009 Fall | 59 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Custom er Developer

Scene 1

“Hi, Dev elop er, I w a nt the toa ster ca n a utom a tica lly p op up the toa st w hen it’s d one.”

2009 Fall | 60 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Developer

ha rd thinking

“Use the op tica l sensor to d etect the color of toa st” “Use the custom brow nness d etecting softw a re to d etect the toa sting sta tus” “Use the sp ring to p op up the toa st” Scene 2

slide-16
SLIDE 16

2009 Fall | 61 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Developer Custom er

“Hi, Dea r Custom er, is tha t w ha t y ou w a nt?” Scene 3

2009 Fall | 62 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Custom er

Scene 4

Developer

“Hm m , it looks nice, but how m uch d ose these com p onents cost?”

2009 Fall | 63 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Scene 5

Developer Custom er

“Hm m , a bout 50 Euro for the

  • p tica l sensor, 50 Euro for

the softw a re, a nd other cost, tota lly a bout 20 0 Euro?”

2009 Fall | 64 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Custom er Developer

Scene 5

“Oh, NO, 20 0 Euro is too exp ensiv e for a sim p le toa ster?” Red esign it

slide-17
SLIDE 17

2009 Fall | 65 Peng Liang Requirements Engineering 10/ 13/ 2009

Example: Up-front vs. Agile requirements

Scene 6

Developer

“Oh, w a ste of m y tim e. I should ha v e d esigned the toa ster a fter a sking this guy how m uch they rea lly w a nt to p a y for the toa ster, a nd how good qua lity the toa ster should be. Then I ca n just use a tim er to p op up the toa st”

2009 Fall | 66 Peng Liang Requirements Engineering 10/ 13/ 2009

Latest Responsible Moment decision making

Waste of effort Waste of effort

2009 Fall | 67 Peng Liang Requirements Engineering 10/ 13/ 2009

Guidelines of agile RE

› Minimum Useful Feature Set (MUFS) › Start with user stories › Agile RE process › Miracle of collaboration

2009 Fall | 68 Peng Liang Requirements Engineering 10/ 13/ 2009

Minimum Useful Feature Set (MUFS)

› Smallest amount of features that provides the most new market value

Satisfy the m ost valued part first, and rem aining m arket in increm ents Satisfy everyone in a m arket all at once by including all possible features Pairwise m ethod

slide-18
SLIDE 18

2009 Fall | 69 Peng Liang Requirements Engineering 10/ 13/ 2009

iPhone example

Most valuable features Polished functions

2009 Fall | 70 Peng Liang Requirements Engineering 10/ 13/ 2009

Minimum Useful Feature Set (MUFS)

› How to define a “feature” in agile requirements?

  • The smallest set of functionality that has most value

to the market

› Send/ receive message 90% › Calendar 84% › Take photo 76% › Manage photo 71% › Watch video 69% › Map navigation 65% …

2009 Fall | 71 Peng Liang Requirements Engineering 10/ 13/ 2009

Capture features by user stories

user stories

2009 Fall | 72 Peng Liang Requirements Engineering 10/ 13/ 2009

Start with user stories

› What stories are › Users and user roles › Gathering stories

slide-19
SLIDE 19

2009 Fall | 73 Peng Liang Requirements Engineering 10/ 13/ 2009

What the stories are

› Same purpose as use case, but not the same

  • Written by users, not the requirements analyst
  • 1~3 sentences in the plain English of the user
  • Can be implemented in code up to 3 person.weeks
  • Don’t using database to manage stories

2009 Fall | 74 Peng Liang Requirements Engineering 10/ 13/ 2009

Ron Jeffries’s three Cs for user stories

Card Conversation Confirm ation

* User stories are written on note cards. * Cards can be annotated with tim e estim ates. * Details behind the story com e out during conversations with users. * Acceptance tests confirm the story was im plem ented correctly.

2009 Fall | 75 Peng Liang Requirements Engineering 10/ 13/ 2009

Samples from a travel website

A s a u s e r , I w a n t t

  • r

e s e r v e a h

  • t

e l r

  • m

. A s a v a c a t i

  • n

p l a n n e r , I w a n t t

  • s

e e t h e p h

  • t
  • s
  • f

t h e h

  • t

e l s . A s a u s e r , I w a n t t

  • c

a n c e l a r e s e r v a t i

  • n

. A s a f r e q u e n t f l y e r , I w a n t t

  • r

e b

  • k

a p a s t t r i p , s

  • t

h a t I s a v e t i m e b

  • k

i n g t r i p s .

2009 Fall | 76 Peng Liang Requirements Engineering 10/ 13/ 2009

Adding barely enough details users care

› As a user, I can cancel a reservation

  • How far ahead must the reservation be cancelled?
  • Dose the user get a full or partial refund?
  • Is the cancellation condition the same for all users?
slide-20
SLIDE 20

2009 Fall | 77 Peng Liang Requirements Engineering 10/ 13/ 2009

Details added in smaller sub-stories

A s a u s e r , I w a n t t

  • c

a n c e l a r e s e r v a t i

  • n

.

A s a p r e m i u m u s e r , I c a n c a n c e l a r e s e r v a t i

  • n

u p t

  • t

h e l a s t m i n u t e , a n d g e t f u l l r e f u n d . A s a n

  • r

m a l u s e r , I c a n c a n c e l a r e s e r v a t i

  • n

u p t

  • 2

4 h

  • u

r s i n a d v a n c e , a n d g e t 9 % r e f u n d .

2009 Fall | 78 Peng Liang Requirements Engineering 10/ 13/ 2009

Details as conditions of satisfaction

› Acceptance tests by users (or product owner)

A s a u s e r , I w a n t t

  • c

a n c e l a r e s e r v a t i

  • n

.

* Verify that a prem ium user can cancel the reservation the last day without a fee. * Verify that a norm al user is charged 10 % for a cancellation before the reserved date.

2009 Fall | 79 Peng Liang Requirements Engineering 10/ 13/ 2009

Users and user roles

› Users’stories

Who are the users?

2009 Fall | 80 Peng Liang Requirements Engineering 10/ 13/ 2009

User role modeling steps

› Brainstorming an initial set of user roles › Organize the initial set (similar, related roles) › Consolidate roles › Refine roles

slide-21
SLIDE 21

2009 Fall | 81 Peng Liang Requirements Engineering 10/ 13/ 2009

User roles brainstorming (high school website)

Bra instorm the user roles w ho w ill intera ct w ith this w eb site?

2009 Fall | 82 Peng Liang Requirements Engineering 10/ 13/ 2009

Organize/ consolidate the initial set of roles

› Any arrangement rules all participants agree

graduate geographic searcher alum ni current student potential student job seeker job poster recruiter resum e reviewer sys adm in recruiter

2009 Fall | 83 Peng Liang Requirements Engineering 10/ 13/ 2009

Advantages of using roles

Users becom e tangible Incorporate roles into stories Start thinking of software solving the needs of real people.

“As a <user role>, I want to <goal> so that <benefit>.”

job seeker Tom As a job seeker, I want to find job information, so that I can apply for it.

2009 Fall | 84 Peng Liang Requirements Engineering 10/ 13/ 2009

Gathering stories

› Techniques for gathering stories

  • Questionnaires
  • Observation
  • User interviews
  • Story-writing workshops (similar to JAD, using

template) Refer to the Unit 3: Requirem ents elicitation

“As a <user role>, I want to <goal> so that <benefit>.”

slide-22
SLIDE 22

2009 Fall | 85 Peng Liang Requirements Engineering 10/ 13/ 2009

Agile requirements engineering process

User stories colla bora tion

Agile Requirem ents Best Practices

2009 Fall | 86 Peng Liang Requirements Engineering 10/ 13/ 2009

Miracle of collaboration

› Exploration of customer involvement

  • On-site customer
  • Off-site customer

Exp erience it w ith a v ery sim p le exp erim ent

2009 Fall | 87 Peng Liang Requirements Engineering 10/ 13/ 2009

Metaphors

Release the product to market and see what happens Presenter compares the “implemented product” to “product vision” The “programmer” implement the product Hand-drawn copy of the product vision by “developer” The “customer” knows the product vision Diagram that only “customer” is allowed to look at A start-up company trying to bring a new product to market Team with “customer” and “developer” Metaphor Reality

2009 Fall | 88 Peng Liang Requirements Engineering 10/ 13/ 2009

A metaphor of software product

Straight-line Curved-line Diam ond

slide-23
SLIDE 23

2009 Fall | 89 Peng Liang Requirements Engineering 10/ 13/ 2009

Off-site customer

Custom er developer

A start-up com pany

SRS Product

5 m inutes 5 m inutes

2009 Fall | 90 Peng Liang Requirements Engineering 10/ 13/ 2009

On-site customer

A start-up com pany

Custom er developer Product

Verba l com m unica tion 10 m inutes

2009 Fall | 91 Peng Liang Requirements Engineering 10/ 13/ 2009

Compare the experiment results “on-site customer”

vs.

“off-site customer”

2009 Fall | 92 Peng Liang Requirements Engineering 10/ 13/ 2009

Is Agile RE a replacement to traditional RE?

› Agile is just a way of life (many other ways)

  • more iteration, user interaction, latest decisions
  • appropriate for constant changing business

environment › The traditional RE techniques still apply

  • elicitation, validation, management

›

  • K. Orr. Agile Requirem ents: opportunity or Oxym oron. IEEE Software, 21(3):71-73, 2004.
slide-24
SLIDE 24

2009 Fall | 93 Peng Liang Requirements Engineering 10/ 13/ 2009

In the future of RE

› Adapt the requirement techniques into practical context › Most important

  • RE is mostly a social skill (communication,

coordination, negotiation)

  • Business value first

2009 Fall | 94 Peng Liang Requirements Engineering 10/ 13/ 2009

Review of today

› The techniques to make your RE process agile to embrace the changing/ uncertain world › How to use user stories to effectively document agile requirements

10/ 13/ 2009 | 95 2009 Fall Peng Liang Requirements Engineering

Reading

  • K. Orr. Agile requirements opportunity or oxymoron. IEEE Software, 21(3):71-73, 2004.
  • D. Leffingwell. Agile requirements methods. Rational Edge, 8(7):11-23, 2002.

10/ 13/ 2009 | 96 2009 Fall Peng 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 and minutes (finishing the remaining requirement tasks that you didn’t perform) of Week 42

slide-25
SLIDE 25

10/ 13/ 2009 | 97 2009 Fall Peng Liang Requirements Engineering

Course assignment

  • (2) presentation of group project, 20-10-2009, 11:15-14:00, V 5161.0253

http:/ / www.cs.rug.nl/ search/ Teaching/ RE2009FallDeadlines

2009 Fall | 98 Peng Liang Requirements Engineering 10/ 13/ 2009

Presentation of group project

› The content each group needs to present

  • Scope of the system (w ith reasons w hy your group m akes such

scope)

  • Stakeholders of the system (with how you identify these

stakeholders)

  • Selected requirements (e.g., business goals, scenarios, FRs,

NFRs, etc.) and their rationale

  • Forward traceability from stakeholders to requirements
  • The problems identified by your peer reviewer
  • The feedbacks (improvements) to these problems

2009 Fall | 99 Peng Liang Requirements Engineering 10/ 13/ 2009

Presentation rules

› Each group can choose 1~n (n is the number of group members) presenters to give the presentation › 15-20 minutes for the presentation › 5 minutes for questions by your customer group (other groups can also post questions with extra grading bonus)

  • Group 1 (developer) vs. Group 2 (customer)
  • Group 2 (developer) vs. Group 3 (customer)
  • Group 3 (developer) vs. Group 1 (customer)
  • Group 4 (developer) vs. Group 5 (customer)
  • Group 5 (developer) vs. Group 6 (customer)
  • Group 6 (developer) vs. Group 4 (customer)

2009 Fall | 100 Peng Liang Requirements Engineering 10/ 13/ 2009

Submissions

› Each group should record the questions/ comments posed to your presentation, and your feedbacks to these questions using the template provided in the course website › Submit your group presentation slides with comments

& feedbacks before the deadline (week 43)