Requirements Engineering Unit 4: Business process first, and then - - PowerPoint PPT Presentation

▶
requirements engineering
SMART_READER_LITE
LIVE PREVIEW

Requirements Engineering Unit 4: Business process first, and then - - PowerPoint PPT Presentation

Jul 05, 2023 350 likes •584 views

9/ 29/ 2009 | 1 9/ 29/ 2009 | 2 What we can do when stakeholders are busy Requirements Engineering Unit 4: Business process first, and then system and user requirements Requirements modeling, specification & Observation method

slide-1
SLIDE 1

9/ 29/ 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 4: Requirements modeling, specification & prioritization

2009 Fall | 2 Peng Liang Requirements Engineering 9/ 29/ 2009

What we can do when stakeholders are busy

› Business process first, and then system and user requirements › Observation method › Individual meetings rather than joint workshops › Meet “keenest” people first › Corridor conversations, lunches, office dropins … › Talk to them about their day to day work

2009 Fall | 3 Peng Liang Requirements Engineering 9/ 29/ 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 | 4 Peng Liang Requirements Engineering 9/ 29/ 2009

Last Unit

Requirem ent elicitation

This Unit

Requirem ent m odeling & specification

Next Unit

Requirem ent specification & validation

slide-2
SLIDE 2

2009 Fall | 5 Peng Liang Requirements Engineering 9/ 29/ 2009

Contents

› RE modeling methods (use case modeling) › How to write good use case › How to write good requirements specification › How to do requirements prioritization

2009 Fall | 6 Peng Liang Requirements Engineering 9/ 29/ 2009

Requirements modeling

2009 Fall | 7 Peng Liang Requirements Engineering 9/ 29/ 2009

Modeling is important for understanding

Application dom ain Model dom ain Withdraw cash: Usecase Dog: Actor ATM: System boundary Withdraw cash

ATM system

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

Modeling purpose in RE

› Easy understanding and communication

  • Checking the understanding (sequence diagram)
  • Uncovering problems (scope, terminology)

› Efficient requirement management

  • Guiding the requirement elicitation (actors from

stakeholders)

  • Measure of development progress (package based)
slide-3
SLIDE 3

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

RE modeling methods

› Goal-oriented › Scenario-based › Aspect-oriented › Stakeholder-oriented › Commonality and variability based › Requirement reuse-driven › Use case modeling

  • 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. 2009 Fall | 10 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case and requirement specification

User requirements Use cases modeling Detailed requirements specification FR NFR Software Requirem ents Specification

trace back

2009 Fall | 11 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling Use Case

2009 Fall | 12 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling: overview

› What is use case modeling? › Core concepts › Diagram tour › Modeling tips

slide-4
SLIDE 4

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

What is use case modeling?

› A view of a system that emphasizes the behavior as it appears to external users › System functionality partition into transactions (‘use cases’) that yields an observable result of value to a particular users (‘actors’).

2009 Fall | 14 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling: core elements

Represent the boundary between the system and the actors who interact with the system

System boundary

A set of roles that the users of use cases play when interacting with the use cases

Actor

A sequence of actions, including variants, a system performs that yields an observable result of value to a particular actor.

Use case Syntax Description Construct

2009 Fall | 15 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling: core relationships

A taxonomic relationship between a general actor and a more specific actor

generalization «include»

A relationship from an base use case to a inclusion use case

include «extend»

A relationship from an extension use case to a base use case

extend

The participation of an actor in a use case

association Syntax Description Construct

2009 Fall | 16 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case diagram tour

› By examples

  • use cases, actor and their relationships

› Use case description

  • text or interaction diagrams (sequence or

collaboration diagram)

slide-5
SLIDE 5

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

Customer Supervisor Salesperson Place Establish credit Check Telephone Catalog Fill orders Shipping Clerk status

  • rder

Use case diagram

Actor Use case Association System boundary

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

Use case relationships

additional requests :

Order Product Supply Arrange «include» «include» «include» Request Catalog «extend»

Extension points

Payment Customer Data

after creation of the order

Place Order

1 *

the salesperson asks for the catalog

Salesperson

back

2009 Fall | 19 Peng Liang Requirements Engineering 9/ 29/ 2009

Actor relationships

Establish Credit Place Order Salesperson Supervisor

1 * 1 *

2009 Fall | 20 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case description: Change Flight

Traveler

Change Flight

Client Account DB Airline Reservation System

slide-6
SLIDE 6

2009 Fall | 21 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case description: Change Flight

› Actors

  • traveler, client account database, airline reservation system

› Pre-conditions:

  • Traveler has logged on to the system and selected ‘change

flight itinerary’ option › Post-conditions:

  • Traveler gets flight itinerary modification result

2009 Fall | 22 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case description: Change Flight

› Basic course

  • System retrieves traveler’s account and flight itinerary from client

account database

  • System asks traveler to select itinerary segment she wants to

change; traveler selects itinerary segment.

  • System asks traveler for new departure and destination

information; traveler provides information.

  • If flights are available then…
  • …
  • System displays transaction summary

› Alternative courses

  • If there are no flights available…

2009 Fall | 23 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling tips (1)

› Communication purpose

  • Observable result to actor
  • Understandable by both domain experts and

developers

› Naming scheme

  • Use “verbs + nouns”, behavior and results
  • Help derive objects and messages for detailed design

(e.g., interaction diagrams)

2009 Fall | 24 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case modeling tips (2)

› Factor out common usages

  • use «include»: usage required by multiple use cases
  • use «extend»: the usage may be optional

› Use case diagram should

  • the same level of abstraction
  • include only actors required by the use case
  • organized by packages when large number of UC
slide-7
SLIDE 7

2009 Fall | 25 Peng Liang Requirements Engineering 9/ 29/ 2009

How to write good use case Use Case

2009 Fall | 26 Peng Liang Requirements Engineering 9/ 29/ 2009

Typical problems when using use case modeling

2009 Fall | 27 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 1 – mixed-up system boundary

System Business user System user System user

?

2009 Fall | 28 Peng Liang Requirements Engineering 9/ 29/ 2009

Computer system boundary

Ticket Ordering System

slide-8
SLIDE 8

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

Business boundary

Ticket Sales Business System

2009 Fall | 30 Peng Liang Requirements Engineering 9/ 29/ 2009

Use case model layout

Order Tickets Kiosk Customer Credit Card Validation System View Schedule Create Schedule Schedule Administrator 2009 Fall | 31 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 2 - Actor’s point of view

Process Tickets Order Kiosk Customer Display Schedule Order Tickets Kiosk Customer View Schedule

Sym ptom 1

2009 Fall | 32 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 2 - Actor’s point of view

› Order tickets: Use case

  • Basic course
  • Ticket machine gets the credit card;
  • Ticket machine verifies the credit card information;
  • Ticket machine gets ticket schedule info;
  • Ticket machine processes the credit card payment;
  • Ticket machine prints out the ticket.

All about the internal functionality of ticket m achine Sym ptom 2

slide-9
SLIDE 9

2009 Fall | 33 Peng Liang Requirements Engineering 9/ 29/ 2009

Revised use case specification

› Order tickets: Use case

  • Basic course
  • Kiosk customer inserts the credit card into the Ticket

machine;

  • Kiosk customer gets the verification information of the

the credit card by the Ticket machine;

  • Kiosk customer selects the ticket schedule info in the

Ticket machine;

  • Kiosk customer confirms the ticket payment;
  • Kiosk customer gets the printed out ticket from the

Ticket machine. All about the interactions between actor and system

2009 Fall | 34 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 2 - Actor’s point of view

› Use case model is not a data/ process flow

› <<include>> and <<extend>> are not for functional or

data decomposition

Sym ptom 3

Order Tickets Kiosk Customer Print Tickets <<include>> Display Tickets Deliver Tickets <<include>> <<include>>

back

2009 Fall | 35 Peng Liang Requirements Engineering 9/ 29/ 2009

Tips

› Don’t be a developer, be the actor’s role › Don’t ask how system work, but what system should provide to actor

2009 Fall | 36 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 3 - Unified actor name

View Schedule Schedule Administrator Create Schedule Schedule Manager Edit Schedule Scheduler

Schedule Administrator

slide-10
SLIDE 10

2009 Fall | 37 Peng Liang Requirements Engineering 9/ 29/ 2009

Glossary

Schedule Manager Scheduler The role to manage the ticket schedule information in the “Ticket Ordering System”. Schedule Administrator Alias Meaning Actor nam e

2009 Fall | 38 Peng Liang Requirements Engineering 9/ 29/ 2009

Select Ticket Date Kiosk Customer Select Seat Preference Input Credit Card Info Get Ticket

Top 4 - Too many use cases

› Pseudo user interface use case

Sym ptom 1 Ticket Ordering System

2009 Fall | 39 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 4 - Too many use cases

Sym ptom 2

Actor A Package 1 Package 2 Package 3 Package 4 Package 5 Package 1

Actor A Actor B Actor C Actor D Actor E

› Package them

2009 Fall | 40 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 5 - A spider web

› An actor interacts with every use case

Sym ptom 1

Order Tickets View Schedule Emplyee Create Schedule Order Tickets Phone Clerk View Schedule Schedule Administrator Create Schedule

Ticket Ordering System Ticket Ordering System

slide-11
SLIDE 11

2009 Fall | 41 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 5 - A spider web

› An use case interacts with every actor

Sym ptom 2

Ticket Ordering System

View Schedule Kiosk Customer Order Ticket Phone Clerk View Daily Sales Report View Schedule Ticketer Order Ticket Phone Clerk View Daily Sales Report Kiosk Customer

2009 Fall | 42 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 6 - Too long use case specification & vague name › Use case specification goes on for pages

  • Coarse use case
  • “use”, “maintain”, “process”, “manage”, etc.
  • Too much internal processing description details

Use Schedule

2009 Fall | 43 Peng Liang Requirements Engineering 9/ 29/ 2009

Top 7 – customers don’t understand/ like use case

› Put short explanation (1-2 page) of use cases with a simple example (better from the domain which customers are familiar with) › Adding a “context” section in use case specification template › Organize the use case packages by customer’s advice › Avoid using <<include>> and <<extend>> relationships › Use SRS in natural language if user don’t like use case

  • Use case for the analysis and semi-finished product

2009 Fall | 44 Peng Liang Requirements Engineering 9/ 29/ 2009

Infotainment system (SA course 2008)

slide-12
SLIDE 12

2009 Fall | 45 Peng Liang Requirements Engineering 9/ 29/ 2009

Requirements specification

2009 Fall | 46 Peng Liang Requirements Engineering 9/ 29/ 2009

How to write good specification SRS

2009 Fall | 47 Peng Liang Requirements Engineering 9/ 29/ 2009

A good requirement specification

› Complete › Traceable › Testable › Consistent › Uniquely identified › Design free

2009 Fall | 48 Peng Liang Requirements Engineering 9/ 29/ 2009

Using right auxiliary verbs

› “Shall … ”

  • Must be implemented

› “Should … , may … ”

  • Can be implemented

› “Will … ”

  • Future requirements
slide-13
SLIDE 13

2009 Fall | 49 Peng Liang Requirements Engineering 9/ 29/ 2009

Examples: refining requirements specification

2009 Fall | 50 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 1

› “ Softw are w ill not be loaded from unknow n sources

  • nto the system w ithout having the softw are tested

and approved.” › Problem

  • Two constraints are specified simultaneously
  • Unclear about the relationship between them
  • No unique identifier

2009 Fall | 51 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 1: Re-specification

› “ 3.2.5.2 Softw are sha ll be loaded onto the

  • perational system only a fter it has been tested and

approved.”

2009 Fall | 52 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 2

› “ 3.4.6.3 The system sha ll prevent the processing of duplicate electronic files by checking a SDATE record. An em ail m essage sha ll be sent.” › Problem

  • Two “shall” under one requirement identifier
  • What’s the content of email message? For what

purpose?

  • What is SDATE?
slide-14
SLIDE 14

2009 Fall | 53 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 2: Re-specification

› “ 3.4.6.3 The system sha ll:

  • a. Prevent processing of duplicate electronic files by

checking the date and tim e of the subm ission.

  • b. Send the follow ing em ail m essage:
  • b.1 Request updated subm ission of date and tim e, if

necessary, or

  • b.2. That the processing w as successful, if successful.”

2009 Fall | 54 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 3

› “ 3.2.5.7 The system shall process tw o new fields inform ation at the end of state record.” › Problem

  • What are the two new fields information?
  • Can not be implemented and tested

2009 Fall | 55 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 3: Re-specification

› “ 3.2.5.7 The system shall provide the follow ing data item s at the end of state record:

  • a. Subm ission date and tim e.
  • b. production count to that date in total.”

2009 Fall | 56 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 4

› “ 3.2.5.9 All sensitiv e com puter-resident inform ation shall have system access controls to ensure that it is not im properly disclosed, m odified, deleted, or rendered unavailable.” › Problem

  • What is sensitive information?
slide-15
SLIDE 15

2009 Fall | 57 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 4: Re-specification

› “3.2.5.9 All sensitiv e com puter-resident … (Reference Sensitive Inform ation Table 5.4.1 and Levels of Protection for Sensitive Inform ation Table 5.4.2.)”

2009 Fall | 58 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 5

› “ 3.3.2.1 The system shall have no single point failures.” › Problem

  • Unclear application scope of this requirement

2009 Fall | 59 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 5: Re-specification

› “3.3.2.1 The follow ing system com ponents shall have no single point failure:

  • a. Host servers.
  • c. Netw ork routers.
  • d. Access servers.
  • e. Hubs.
  • f. Sw itches.
  • …”

2009 Fall | 60 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 6

› “ 3.2.6.3 The system shall receive and p rocess state data from the State Processing Subsystem .” › Problem

  • Vague words “process”, “state data”
slide-16
SLIDE 16

2009 Fall | 61 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 6: Re-specification

› “ 3.2.6.3 The system shall receive:

  • a. Production data that contain data from m ultiple

states.

  • b. Financial state data for one or m ore states, extracted

by the State Processing Subsystem .

› 3.2.6.4 The system shall parse m ulti-state data to respective state files.”

2009 Fall | 62 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 7

› “ 3.2.8.2 The enrollm ent process shall take 1 to 10 ca lend a r d a y s to com plete for all enrollm ent types. (STH: system administrator) › 3.2.8.3 The enrollm ent process shall take no m ore tha n 3 d a y s to com plete for Credit enrollm ent (STH: financial administrator) › Problem

  • Inconsistent requirements

2009 Fall | 63 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 8: Re-specification

› “ 3.2.8.2 The enrollm ent process shall take:

  • a. 1 to 3 calendar days to com plete for Credit

enrollm ent.

  • b. 1 to 10 calendar days to com plete for all other

enrollm ent types.”

2009 Fall | 64 Peng Liang Requirements Engineering 9/ 29/ 2009

Example 9

› “ 3.2.8.6 When doing calculations, the softw are shall produce correct results.” › Problem

  • This is not a requirement
  • Something obvious

› Remove it

slide-17
SLIDE 17

2009 Fall | 65 Peng Liang Requirements Engineering 9/ 29/ 2009

Specification checkpoints

› Vague words?

  • Info, fields, …
  • Process, maintenance, …
  • Good functions, well documented, clear

specified, …

  • Correct result, shall run …

› Specific terms?

  • SDATE, CODE131, …

› Obvious and redundant requirements

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

Define “shall not” requirements

What the system shall do What the system shall not do?

System boundary

2009 Fall | 67 Peng Liang Requirements Engineering 9/ 29/ 2009

Examples of “shall not” requirements

› The system shall not allow users to modify access permissions on any files that they have not created. (security) › The system shall not allow the simultaneous activation of more than three alarm signals. (safety)

2009 Fall | 68 Peng Liang Requirements Engineering 9/ 29/ 2009

Define “shall not” requirements

› Think about them in a positive way What the system shall do What shall the system do to achieve X?

slide-18
SLIDE 18

2009 Fall | 69 Peng Liang Requirements Engineering 9/ 29/ 2009

Revision of “shall not” requirements

› The system shall not all users to modify access permissions on any files that they have not created. (security)

  • The system shall allow access permissions

modification only to the creators of the files (to protect files). › The system shall not allow the simultaneous activation of more than three alarm signals. (safety)

  • The system shall allow the simultaneous activation of

at most three alarm signals (to reduce noise).

2009 Fall | 70 Peng Liang Requirements Engineering 9/ 29/ 2009

Requirements prioritization

2009 Fall | 71 Peng Liang Requirements Engineering 9/ 29/ 2009

Requirements prioritization

› Time and resource limitations › RE goal is to add business value

2009 Fall | 72 Peng Liang Requirements Engineering 9/ 29/ 2009

Dilemma of project manager

› How to select a subset of requirements › How to produce a subset of system that still meets customers’needs

slide-19
SLIDE 19

2009 Fall | 73 Peng Liang Requirements Engineering 9/ 29/ 2009

Pairwise and cost-value comparison approach

› Simple › Reasonable › Repeatable › Verifiable › Tool support › Industrial proven

2009 Fall | 74 Peng Liang Requirements Engineering 9/ 29/ 2009

Cost-value of requirements

› Estimated cost of the implementation of a requirement › Value to customers and users of a requirement

2009 Fall | 75 Peng Liang Requirements Engineering 9/ 29/ 2009

Why pairwise?

› Traditional method calculate the cost by money spent

  • slow, vague, and various in many factors

› Prioritization based on relative value rather than absolute assignments

  • Fast, accurate, and trustworthy

You can easily tell A is taller than B, but it is difficult to tell what A’s height is. A B A

2009 Fall | 76 Peng Liang Requirements Engineering 9/ 29/ 2009

Results of method

slide-20
SLIDE 20

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

Steps of method

› Requirements engineers review the candidate requirements for completeness › All (selective) stakeholders make pairwise comparison

  • f all requirements

› Requirements engineers make estimation of the relative cost › Requirements engineers normalize the requirement's relative value and cost, and plot these on a cost-value diagram

2009 Fall | 78 Peng Liang Requirements Engineering 9/ 29/ 2009

Pairwise comparison (value and cost)

Req1/ Req2

r e c i p r

  • c

a l s

2009 Fall | 79 Peng Liang Requirements Engineering 9/ 29/ 2009

Results normalization

5 2+5+1+3 Value_ Req2= 1.98 / 4 = 0 .5

2009 Fall | 80 Peng Liang Requirements Engineering 9/ 29/ 2009

Results in percent

Value_ Req13=0 .21

slide-21
SLIDE 21

2009 Fall | 81 Peng Liang Requirements Engineering 9/ 29/ 2009

Plot the results

Value_ Req13=0 .21 Cost_ Req13 = 0 .23

2009 Fall | 82 Peng Liang Requirements Engineering 9/ 29/ 2009

Known issues

› Consistency

  • Value_Req1 > Value_Req2;
  • Value_Req2 > Value_Req3;
  • Value_Req3 > Value_Req1;
  • Consistency index calculation

› Interdependency of requirements

  • e.g., a high-cost and low-value requirement should be

implemented first › Number of pairwise comparison is O(n2)

  • Tool support (calculation, rationale documentation)

Req1 Req2 Req3

  • J. Karlsson and K. Ryan. A cost-value approach for prioritizing requirements. IEEE Software, 1997.

2009 Fall | 83 Peng Liang Requirements Engineering 9/ 29/ 2009

Review of today

› How to write good use cases › Top problems in writing good specifications › Cost-value approach for prioritizing requirements

9/ 29/ 2009 | 84 2009 Fall Peng Liang Requirements Engineering

Reading

  • L. Probasco and D. Leffingwell. Combining software requirements specifications with use-case
  • modeling. Rational Software, 1999.
  • IEEE. IEEE Recommended Practice for Software Requirements Specifications. IEEE Standard

Committee, IEEE Std 830-1998, 1998.

  • J. Karlsson and K. Ryan. A cost-value approach for prioritizing requirements. IEEE Software,

14(5):67-74, 1997.

slide-22
SLIDE 22

9/ 29/ 2009 | 85 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 (requirements modelling, specification, and prioritization) of Week 40