software engineering of standalone programs -- week 4 use case internals -- compare to example in...

Software Engineering of Standalone Programs -- Week 4Software Engineering of Standalone Programs -- Week 4

Use Case Internals -- Compare to example in Larman text (p. 68 ff.). Terms: 73-78

Use Case Name Scope Level Primary Actor Stakeholders & interests Preconditions Success Guarantee (post-

conditions)

Basic Flow Alternate Flows (extensions) Error Flows Subflows Special requirements Technology & data variations

list Frequency of occurrence Open Issues


Fully Dressed Example: Process Sale, Larman text, p. 68 ff.

Primary Actor: CashierStakeholders and Interests:- Cashier: Wants accurate, fast entry, and no payment errors, as cash

drawer shortages are deducted from his/her salary.- Salesperson: Wants sales commissions updated.- Customer: Wants purchase and fast service with minimal effort. Wants

proof of purchase to support returns.- Company: Wants to accurately record transactions and satisfy customer

interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components are unavailable. Wants automatic and fast update of accounting and inventory.


Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued

- Government Tax Agencies: Want to collect tax from every sale. May be multiple agnecies such as national, state, and county.

- Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store.

Preconditions: Cashier is identified and authenticated.Success Guarantee (Postconditions): Sale is saved. Tax is

correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt generated. Payment authorization approvals are recorded.


Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued

Main Success Scenario (of Basic Flow):

1. - 10.Extensions (Alternative Flows):*a.*b.1a2-4a

3a.3b.3c.3-6a-c4a5a-c6a7a-f9a-c


Special Requirements:- Touch Screen UI on a large flat panel monitor. Text visible from 1

meter.- Credit auth. response within 30 seconds 90% of the time....Technology and Data Variations List:...Frequency of Occurrence: Could be nearly continuous.Open Issues:- What are the tax law variations?- Explore the remote service recovery issue.- What customization is needed for different businesses?

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. – cont.


Now what -- after development of use case(s)

Look for consistency, correctness, completeness–Most important for core requirements likely to be implemented

soonBy translation to other formats

–See Vision Document–Domain diagram (UML)–System Sequence Diagram–State diagrams and tables–Event tables–Condition tables, a.k.a. decision tables

Requirements Verification&

Requirements Management

Originally developed by Michael Madigan, StorageTek

Software Engineering of Standalone ProgramsUniversity of Colorado, Boulder


Requirements Engineering

R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring

R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring


Requirements Verification & Management Definitions

Verification–A software system engineering process employing a rigorous

methodology for evaluating the correctness and quality of software product through the complete software lifecycle.2

Requirements Management–The purpose of Requirements Management is to establish a

common understanding between the customer and the software project of the customer’s requirements that will be addressed by the software project.1


Software Requirements Verification Methods

Review of Concept/Vision documentationTraceability AnalysisSoftware Requirements Evaluation Interface Analysis Initial Testing PlanningReporting


Nine Quality Measures3

CorrectUnambiguousCompleteConsistentRanked for ImportanceVerifiableModifiableUnderstandable


Software Requirements Evaluations (Tools)

Formal InspectionReview with Multi-functional teamsPrototype to “animate” requirementsWrite a draft User ManualCreate requirements with another tool

– I.e. If team used text use cases, create the same use cases with sequence diagrams

Pre and Post conditions can sometimes be modeled with state diagrams

Checklists based on previous evaluations


Related to your Larman text–System Sequence diagrams–Domain Model–State diagrams–State tables

Additional tools–Event tables–Condition tables


Sample domain model


Sample System Sequence Diagram


Sample (incomplete) state transition diagram


State transition table

Current state

Input or event

Action Output Next state


Decision table


Decision table example


Event table

A3;A6 – sequential; A3, A6 – concurrent; dash – no action

X -- impossible situation, cannot occur

A3;A6 – sequential; A3, A6 – concurrent; dash – no action

X -- impossible situation, cannot occur

Requirements Management


Requirements Baseline

An approved list of requirements and its components at a particular point in time.

Requirements baselines are controlled and maintained by a software configuration system.

Requirements baselines must be correct and current throughout the development

Requirements baseline management differs based on software lifecycle


Rules of thumb for Managing Software Requirements4

Each requirement should have a planned completion date. Requirements growth will impact planned resources and should be

managed from the beginning. Requirements changes will most probably impact the schedule. Requirements uncertainty will lead to change requests. Requirements are baselined at the software specification review. Use incremental development to allow the requirements to be

revisited at the beginning of each phase. Software action items should not be left open beyond 60 days.


Requirements Metrics

Requirement Status vs Plan–Vision/Concept/Feature–SRS/Use Case/Use Case Path

Requirements VolatilityExternal Interface Status vs Plan


Requirements Metrics Examples

Weekly Vision Requirements Status

0

10

20

30

40

50

60

70

0

10

20

30

40

50

60 RequirementsProposed

RequirementsAccepted

RequirementsIncorporated

Target IncorpPlan


Requirements Metrics ExamplesWeekly Use Case Status

0

10

20

30

40

50

60

03/1

9/200

1

04/1

9/200

1

05/1

9/200

1

06/1

9/200

1

07/1

9/200

1

08/1

9/200

1

09/1

9/200

1

10/1

9/200

1

11/1

9/200

1

12/1

9/200

1

0

10

20

30

40

50

60

Use CasesProposed

Use CasesAccepted

Use CasesIncorporated

UC IncorpPlan


Requirements Metrics ExamplesWeekly Use Case Path Status

0

20

40

60

80

100

120

03/1

9/20

01

04/1

9/20

01

05/1

9/20

01

06/1

9/20

01

07/1

9/20

01

08/1

9/20

01

09/1

9/20

01

10/1

9/20

01

11/1

9/20

01

12/1

9/20

01

0

20

40

60

80

100

120 Use CasePathsProposed

Use CasePathsAccepted

Use CasePathsIncorporated

UCP IncorpPlan


Requirements Metrics Examples

Vision Requirements Volatility

020406080

100120140160180200

03/1

9/20

01

04/1

9/20

01

05/1

9/20

01

06/1

9/20

01

07/1

9/20

01

08/1

9/20

01

09/1

9/20

01

10/1

9/20

01

11/1

9/20

01

12/1

9/20

01

Total Requirements Amount Changed Since Last Total Changed


Requirements Metrics ExamplesWeekly SRS Use Case Volatility

020406080

100120140160

03/1

9/20

01

04/1

9/20

01

05/1

9/20

01

06/1

9/20

01

07/1

9/20

01

08/1

9/20

01

09/1

9/20

01

10/1

9/20

01

11/1

9/20

01

12/1

9/20

01

Total Use Cases Amount UC Changed Since Last

Total Use Cases Changed


References

1 “Requirements Management,” Richard Thayer, SMC 10/97 Version 2, 1997

2 “Software Verification and Validation”Its role in Computer Assurance and its Relationship with Software Project Management Standards,” Wallace and Fujii, NIST Special Publication, 1989

3 “IEEE Guide for Software Requirements Specification,” IEEE 830-1984

4 “Mission Critical Computer Resources Management Guide”, Technical Management, Defense Systems Management College, Sept 1988.


The Requirements Management Plan

See this document and section 4 of Vision DocumentReq Management Plan, Section 3, Requirement Attributes

–This document explains the attributes–They will first be given values for a feature in the Vision

Document proposing that feature.– If the feature makes it into the requirements data base, these

attributes will come along with it.


Attributes for a feature

Status BenefitEffortRiskStabilityTarget ReleaseTarget IterationAssigned toReasonPriority


Status of a feature

Proposed–Under discussion–Not yet reviewed by working group of reps from project,

product management, and customer–The “official review group” may have some other composition

but one should exist to make formal decisions.Approved

–Reviewed and approved for implementation because the feature is deemed useful and feasible

Incorporated–Feature is incorporated into product baseline in requirements

data base


Benefit of the feature

Critical–Essential–Must delay next release in order to have this feature.

Important– Important to effectiveness and efficiency for most applications–Lack of inclusion may affect customer satisfaction–Do not delay release if unable to implement in time.

Useful–Less typical applications, less frequent (careful), workarounds

exist–No significant customer satisfaction impact if not included


Effort expected to implement this feature

Set by development teamPerson-weeks, lines of code, function points, somethingHelps when deciding which features to put into which

increment – development sequencingHelps when managing scope


Risk re implementation of the feature

Set by development team.Probability the project will experience undesirable events

– that is, there is a loss associated–High, medium, low is probably sufficient

Assess indirectly by the range of uncertainty associated with the team’s schedule estimate


Stability of the feature

Set by analyst (marketing representative) and development team

Probability – the feature will change–The team’s understanding will change

Indicates additional elicitation is needed prior to implementation in an increment


Target Release for this feature

Intended product version in which the feature will first appear

When combined with status–Can propose, record, and discuss it without commitment to

development– If Status = incorporated and Target Release is defined, then this

feature will be implemented. If scope management requires it, the Target Release

version number can be increased so the feature remains in the Vision but is scheduled for a later release.


Assigned To

May assign to “feature team” –Further elicitation–Writing software requirements– Implementation

Clarifies team member responsibilities


Reason for this feature

Used to track the source of this feature’s requestWHY are we doing this feature?Record an explanation or a reference to an explanation

–Page and line number of a product requirement specification–The minute marker on a video of an important customer

interview–other


Priority of this feature

High, Medium, LowAllows you to give high priority to something that does

not get there based on other attribute values.Allows low priority when warranted for unobvious

reasons despite values of other attributes.


Attributes for Use Cases

StatusEffortRiskStabilityTarget IterationAssigned ToFrequency/DurationCriticalityPriorityUnit Test Case


Frequency of this use case

See Operational Profiles later in the courseHigh, Medium, LowWhen the most frequently executed use cases work well

–Customer satisfaction is high–Customer’s view of the product is that it is reliable–Airplane engine metaphor


Criticality of this use case to the system

High–System could not run without this use case

Medium–System could run but would be viewed as having reduced

capability by most usersLow

–System not only would be viewed as having reduced capability by most users, but system would be considered incomplete by most users


Unit Test Case that executes this use case

The ID of the unit test that satisfies this use case.This identifies the test itself


Section 4: Traceability Criteria

Each use case should trace to a feature in the Vision document

Vision document also states non-functional requirementsNon-functional requirements should be exemplified in

use casesThe use case should trace back to the associated non-

functional requirements that it demonstrates

software engineering of standalone programs -- week 4 use case internals -- compare to example in...

Documents