Requirements Engineering - University of Groningen · 2011-02-22 · 2009 Fall | 17 Peng Liang...

10/13/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 6:Use case approach for requirements management

2009 Fall

| 2

Peng Liang Requirements Engineering

10/13/2009

Course outlineRequirements Engineering

Requirements Engineering process

Requirements elicitation

Requirement analysis

Requirement validation

Requirements documentationRequirement

negotiation Requirements management

2009 Fall

| 3


10/13/2009

Last UnitRequirements specification & validation

This UnitRequirements management

Next UnitAgile requirements

2009 Fall

| 4


10/13/2009

Contents

› From use cases to implementation

› From use cases to test cases

› Tracing requirements

› Managing requirements change

2009 Fall

| 5


10/13/2009

From use cases to implementation

2009 Fall

| 6


10/13/2009

Use case centric requirements management

design

2009 Fall

| 7


10/13/2009


› Simple requirements can be directly mapped to design and code

Display the progress bar

2009 Fall

| 8


10/13/2009


› BUT most of requirements are orthogonal with design and implementation• UC-01 : “edit field”

• FR-01: “user shall edit fields in accordance with the user privileges established by system administrator”

• NFR-01: “the system shall handle up to 100,000 users simultaneously”

2009 Fall

| 9


10/13/2009

So how to map complex use case to implementation?

2009 Fall

| 10


10/13/2009

Object orientation

traceability

UML diagram series

2009 Fall

| 11


10/13/2009

Object orientation example

› FR-01: “user shall edit fields in accordance with the user privileges established by system administrator”

File Administration System

2009 Fall

| 12


10/13/2009

From use case to interaction diagram

2009 Fall

| 13


10/13/2009

Identify classes from interaction diagram

2009 Fall

| 14


10/13/2009

Architectural views

Water Engineer

Electrical Engineer

Security engineer

Structural Engineers

2009 Fall

| 15


10/13/2009

4+1 architectural view stakeholders

Class, subsystems

statechart deployment

component

Use case

› P. Kruchten. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software, 12(6):42-50, 1995.

2009 Fall

| 16


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 representthe 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 definitionsand metadata

Deployment on .Net and/or J2EE – emphasis on reliability,availability and security.

2009 Fall

| 17


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


10/13/2009

From use cases to test cases

2009 Fall

| 19


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


10/13/2009

Scenarios in a use case

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

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

2009 Fall

| 21


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


10/13/2009

Step1: Identify the use case scenarios

Alternate flow 4Alternate flow 3Basic flowSN8

Alternate flow 4Basic flowSN7

Alternate flow 2Alternate flow 1Alternate flow 3Basic flowSN6





Basic flowSN1

Next AlternateNext AlternateAlternate FlowOriginating FlowSN

2009 Fall

| 23


10/13/2009

Step2: Identify the test cases

Scenario 2TC3Scenario 2TC2Scenario 1TC1

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 week up to a maximum of seven different daily settings. The system confirms acceptance of each daily entry with a beep.

Lighting Control System

TC2: correct number of daily settings is entered, Sequence saved with a beep

TC3: invalid number of daily setting is entered, Error message

2009 Fall

| 24


10/13/2009

Step3: Identify the test conditionsspecific 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

2009 Fall

| 25


10/13/2009

Tracing requirements to software artifacts

2009 Fall

| 26


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

implementation

testing

2009 Fall

| 27


10/13/2009

Generalized traceability model based on UCbusiness goals

High level requirement

NFRs, Design

Constrains

2009 Fall

| 28


10/13/2009

Tracing requirement to requirement

› Traceability Matrix: Tracing Features to Use cases

XXFeature mFeature n

XXFeature 2XFeature 1

Use Case kUse Case iUse Case 2Use Case 1

Use case 1 is a gratuitous use case

Feature n needs to be defined by some use case

2009 Fall

| 29


10/13/2009

Tracing requirement to requirement

XGoal-04XXGoal-03

XXGoal-02XGoal-01

Feature kFeature i. . .Feature 1

XRequirement mXXXRequirement nXXRequirement 2XXRequirement 1

…NFR-0p. . .NFR-01System wide NFR

2009 Fall

| 30


10/13/2009

Tracing requirements to implementation

2009 Fall

| 31


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


10/13/2009

Tracing use cases to test case scenariosUC: Control

light

TS: verifying that a user is able to open the light

TC1: user can push the open light button TC2: pushing the button, the

electricity will be current

TC3: current electricity will turn on the light

2009 Fall

| 33


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


10/13/2009

REWiki

Traceability from stakeholders to requirements

2009 Fall

| 35


10/13/2009

Telelogic DOORS

traceability

Architectural Design

System Requirements

User Requirements

2009 Fall

| 36


10/13/2009

IBM Rational RequisitePro

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

Features

Traceability Matrix

Use cases

2009 Fall

| 37


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


10/13/2009

How to manage requirements change

2009 Fall

| 39


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


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

2009 Fall

| 41


10/13/2009

Step1: Baseline the requirements

› Baseline for the development team

› Compare new requirements against the baseline

› Version controlBusiness goals,

Features, Use cases, FRs, NFRs

V1

V2

V3

V4

2009 Fall

| 42


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)

Requirement Change rate = (NB-PB)/(PB)%

2009 Fall

| 43


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


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 employee into my payroll system, but whenever I have an employee whose first name is more than 16 characters, the program crashes."

Is this a coding bug or new requirement (allow employee

names of up to 16 chars)?

End-user

2009 Fall

| 45


10/13/2009

Step3: Change control system to capture changes

CCB

1

2

3

2009 Fall

| 46


10/13/2009

Step4: Manage change hierarchically

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

2009 Fall

| 47


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


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.

10/13/2009 | 49


› Department of Computer Science / Peng Liang

› Rijksuniversiteit Groningen (RUG)

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

Requirements EngineeringUnit 7:Agile requirements

2009 Fall

| 50


10/13/2009

Course outlineRequirements Engineering

Requirements Engineering process

Requirement elicitation

Requirement analysis

Requirement validation

Requirement documentationRequirement

negotiation Requirement management

Agile?

2009 Fall

| 51


10/13/2009

Last UnitRequirements management

This UnitAgile

requirements method

In the future2009 Fall

| 52


10/13/2009

Contents

› Why agile RE?

› Guidelines of agile RE

2009 Fall

| 53


10/13/2009

Agility

› A definition• “the ability to both create and respond to

change in order to profit in a changingbusiness environment”

Jim Highsmith, 2002

2009 Fall

| 54


10/13/2009

Agile manifesto (values)

› Individuals and interactions over process and tools

› Working software over comprehensive documents

› Customer collaboration over contract negotiation

› Responding to a change over following a plan

Adaptation

Anticipation

over

2009 Fall

| 55


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


10/13/2009

Why agile RE?

Changing world

Changing requirements

2009 Fall

| 57


10/13/2009

Traditional RE vs. Agile RE

› Traditional RE• Up-front requirements

• Massive documentation

• “system should be clearly specified before its design and implementation can start”

› Agile RE

• Latest Responsible Moment decision making

• “put off decision (documentation) as long as you can till the latest responsible moment”

2009 Fall

| 58


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


10/13/2009

Example: Up-front vs. Agile requirements

Customer Developer

Scene 1

“Hi, Developer, I want the toaster can automatically pop

up the toast when it’s done.”

2009 Fall

| 60


10/13/2009


Developer

hard thinking “Use the optical

sensor to detect the color of toast”

“Use the custom brownness detecting software to detect the toasting status”

“Use the spring to pop up the toast”

Scene 2

2009 Fall

| 61


10/13/2009


Developer Customer

“Hi, Dear Customer, is that what you want?”

Scene 3

2009 Fall

| 62


10/13/2009


Customer

Scene 4

Developer

“Hmm, it looks nice, but how much dose these

components cost?”

2009 Fall

| 63


10/13/2009


Scene 5

Developer Customer

“Hmm, about 50 Euro for the optical sensor, 50 Euro for

the software, and other cost, totally about 200 Euro?”

2009 Fall

| 64


10/13/2009


Customer Developer

Scene 5

“Oh, NO, 200 Euro is too expensive for a simple

toaster?”

Redesign it

2009 Fall

| 65


10/13/2009


Scene 6

Developer

“Oh, waste of my time. I should have designed the toaster after asking this

guy how much they really want to pay for the toaster, and how good quality the toaster should be. Then I can just

use a timer to pop up the toast”

2009 Fall

| 66


10/13/2009

Latest Responsible Moment decision making

Waste of effort

Waste of effort

2009 Fall

| 67


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


10/13/2009

Minimum Useful Feature Set (MUFS)› Smallest amount of features that provides the most

new market value

Satisfy the most valued part first, and remaining market in

increments

Satisfy everyone in a market all at once by including all possible

features

Pairwise method

2009 Fall

| 69


10/13/2009

iPhone example

Most valuable features

Polished functions

2009 Fall

| 70


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


10/13/2009

Capture features by user stories

user stories

2009 Fall

| 72


10/13/2009

Start with user stories› What stories are

› Users and user roles

› Gathering stories

2009 Fall

| 73


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


10/13/2009

Ron Jeffries’s three Cs for user stories

Card

Conversation

Confirmation

* User stories are written on note cards.

* Cards can be annotated with time estimates.

* Details behind the story come out during conversations with users.

* Acceptance tests confirm the story was implemented correctly.

2009 Fall

| 75


10/13/2009

Samples from a travel website

As a user, I want to

reserve a hotel room.As a vacation planner,

I want to see the

photos of the hotels.

As a user, I want to cancel a reservation.

As a frequent flyer, I want to rebook a past trip, so that I save time booking trips.

2009 Fall

| 76


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?

2009 Fall

| 77


10/13/2009

Details added in smaller sub-stories


As a premium user, I can cancel a reservation up to the last minute, and get full refund.

As a normal user, I can cancel a reservation up to 24 hours in advance, and get 90% refund.

2009 Fall

| 78


10/13/2009

Details as conditions of satisfaction

› Acceptance tests by users (or product owner)


* Verify that a premium user can cancel the reservation the last day without a fee.

* Verify that a normal user is charged 10% for a cancellation before the reserved date.

2009 Fall

| 79


10/13/2009

Users and user roles

› Users’ stories

Who are the users?

2009 Fall

| 80


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

2009 Fall

| 81


10/13/2009

User roles brainstorming (high school website)

Brainstorm the user roles who

will interact with this website?

2009 Fall

| 82


10/13/2009

Organize/consolidate the initial set of roles

› Any arrangement rules all participants agree

graduate

geographic searcher

alumni

current student

potential student

job seeker

job poster

recruiter

resume reviewer

sys admin

recruiter

2009 Fall

| 83


10/13/2009

Advantages of using roles

Users become 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


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: Requirements elicitation

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

2009 Fall

| 85


10/13/2009

Agile requirements engineering process

User stories

collaboration

Agile Requirements Best Practices

2009 Fall

| 86


10/13/2009

Miracle of collaboration

› Exploration of customer involvement• On-site customer

• Off-site customer

Experience it with a very simple experiment

2009 Fall

| 87


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”

MetaphorReality

2009 Fall

| 88


10/13/2009

A metaphor of software product

Straight-line

Curved-line

Diamond

2009 Fall

| 89


10/13/2009

Off-site customer

Customer developer

A start-up company

SRSProduct5 minutes

5 minutes

2009 Fall

| 90


10/13/2009

On-site customer

A start-up company

Customer developer Product

Verbal communication

10 minutes

2009 Fall

| 91


10/13/2009

Compare the experiment results

“on-site customer”

vs.

“off-site customer”

2009 Fall

| 92


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 Requirements: opportunity or Oxymoron. IEEE Software, 21(3):71-73, 2004.

2009 Fall

| 93


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


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


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


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

10/13/2009 | 97


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


10/13/2009

Presentation of group project

› The content each group needs to present• Scope of the system (with reasons why your group makes 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


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)





2009 Fall

| 100


10/13/2009

Submissions

› Each group should record the questions/commentsposed 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)

Date post:	15-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Requirements Engineering - University of Groningen · 2011-02-22 · 2009 Fall | 17 Peng Liang...

Documents