1. Use Case Internals -- Compare to example in Larman text (p. 68 ff. )
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
Section 3 – organized by stimulus/response

2. Fully Dressed Example: Process Sale, Larman text, p. 68 ff.
Primary Actor: Cashier
Stakeholders 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.
One way to think about component design (later) will be to organize the use cases by Primary Actor.

3. 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.
The precondition is not the first step of the use case. It is what has taken place before the first step.

4. Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued
Main Success Scenario (of Basic Flow):
Extensions (Alternative Flows):
*a.
*b. 1a
2-4a
3a.
3b.
3c.
3-6a-c 4a
5a-c 6a
7a-f
9a-c

5. Fully Dressed Example: Process Sale, Larman text, p. 68 ff. – cont.
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?

6. Now what -- after development of use case(s)
Look for consistency, correctness, completeness
Most important for core requirements likely to be implemented soon
By 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
Develop use cases using product features
Apply to Vision Document
Eventually, we will look at these other representations –
Cannot insert a use case into the SW Req Spec that has not been analyzed and verified.

7. Requirements Verification & Requirements Management
Originally developed by Michael Madigan, StorageTek
Software Engineering of Standalone Programs
University of Colorado, Boulder

8. Requirements Engineering
These are the five activities involved in sw req engineering.

9. Requirements Verification & Management Definitions
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

10. Software Requirements Verification Methods
Review of Concept/Vision documentation
Traceability Analysis
Software Requirements Evaluation
Interface Analysis
Initial Testing Planning
Reporting

11. Nine Quality Measures3 Correct Unambiguous Complete Consistent
Ranked for Importance
Verifiable
Modifiable
Understandable

12. Software Requirements Evaluations (Tools)
Formal Inspection
Review with Multi-functional teams
Prototype to “animate” requirements
Write a draft User Manual
Create 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

13. Related to your Larman text
System Sequence diagrams
Domain Model
State diagrams
State tables
Additional tools
Event tables
Condition tables

14. Sample domain model

15. Sample System Sequence Diagram

16. Sample (incomplete) state transition diagram

17. State transition table
Current state
Input or event
Action
Output
Next state

18. Decision table

19. Decision table example

20. Event table A3;A6 – sequential; A3, A6 – concurrent; dash – no action
There is no standard notation. Suppose you decide ...
semicolon – sequential
comma – concurrent actions
-- denotes “no action required”
X – impossible situation
Must include a legend in your table
A3;A6 – sequential; A3, A6 – concurrent; dash – no action
X -- impossible situation, cannot occur

21. Requirements Management

22. 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

23. 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.

24. Requirements Metrics Requirement Status vs Plan
Vision/Concept/Feature
SRS/Use Case/Use Case Path
Requirements Volatility
External Interface Status vs Plan

25. Requirements Metrics Examples

26. Requirements Metrics Examples

27. Requirements Metrics Examples

28. Requirements Metrics Examples

29. Requirements Metrics Examples

30. 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
4 “Mission Critical Computer Resources Management Guide”, Technical Management, Defense Systems Management College, Sept 1988.

31. The Requirements Management Plan
See this document and section 4 of Vision Document
Req 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.

32. Attributes for a feature
Status
Benefit
Effort
Risk
Stability
Target Release
Target Iteration
Assigned to
Reason
Priority

33. Status of a feature Proposed Approved Incorporated 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

34. Benefit of the feature Critical Important Useful 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

35. Effort expected to implement this feature
Set by development team
Person-weeks, lines of code, function points, something
Helps when deciding which features to put into which increment – development sequencing
Helps when managing scope

36. 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

37. 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

38. 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.

39. Assigned To May assign to “feature team”
Further elicitation
Writing software requirements
Implementation
Clarifies team member responsibilities

40. Reason for this feature
Used to track the source of this feature’s request
WHY 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

41. Priority of this feature
High, Medium, Low
Allows 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.

42. Attributes for Use Cases
Status
Effort
Risk
Stability
Target Iteration
Assigned To
Frequency/Duration
Criticality
Priority
Unit Test Case

43. Attributes for Use Cases
Status
Effort
Risk
Stability
Target Iteration
Assigned To
Frequency/Duration
Criticality
Priority
Unit Test Case

44. Frequency of this use case
See Operational Profiles later in the course
High, Medium, Low
When 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

45. 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 users
Low
System not only would be viewed as having reduced capability by most users, but system would be considered incomplete by most users

46. Unit Test Case that executes this use case
The ID of the unit test that satisfies this use case.
This identifies the test itself

47. Section 4: Traceability Criteria
Each use case should trace to a feature in the Vision document
Vision document also states non-functional requirements
Non-functional requirements should be exemplified in use cases
The use case should trace back to the associated non-functional requirements that it demonstrates