1. Chapter 6 유스케이스를 이용한 서비스 요구명세 Specification with Use Cases
박 수 용
서강대학교
컴퓨터공학과

2. An Outline of Specifying SRS Using Use Case
Use case driven requirements specification is composed of as follows:
1. Create Use Case Specification
2. Create Non-functional
Requirements Specification
3. Organize SRS using
UC Spec and Supplementary Spec

3. 1. Create Use Case Specification

4. 1.1 Step 1 for Creating Use Case Specification
1.1. Identify actors and use cases
1.2. Outline each use case
Brief Description
Basic Flow of Events
Identify Alternative Flows of Events
1.3. Detail each use case
Add detail
Pre and post-conditions, special requirements, relationships, use-case diagrams, and so on
1.4. Structure each use case 1 2 3

5. 1.2. Outline Each Use Case Use case name Structure the flow into steps
Brief description
Basic Flow
1. First step
2. Second step
3. Third step
A1 Alternative flow 1
A2 Alternative flow 2
A3 Alternative flow 3
Use case name
Structure the flow into steps
Number the steps

6. 1.2. Why Outline Use Cases? Use Case Size ?
DRAFT
Too Small?
Use Case Size
Too Big?
Is it more than one use case? ?
Help find ALL alternate flows
Use Case

7. 1.2. Flow of Events (Basic and Alternative)
One Basic Flow
Happy day scenario
Successful scenarios from start to finish
Many alternative flows
Regular variant
Odd cases
Exceptional (error) flows

8. 1.2. Outline the Flow of Events
Basic
What event starts the use case?
How does the use case end?
How does the use case repeat some behavior?
Alternative
Are there optional situations in the use case?
What odd cases might happen?
What variants might happen?
What may go wrong?
What may not happen?
What kind of resources can be blocked?

9. 1.2. Example of Alternative Flow
Are there optional situations in the use case?
해외계좌 송금의 경우
What odd cases might happen?
0원을 송금하는 경우
What variants might happen?
예약송금의 경우
What may go wrong?
비밀번호 입력이 틀린 경우
What may not happen?
대상 계좌번호를 입력하지 않은 경우
What kind of resources can be blocked?
송금한도를 초과한 경우

10. 1.2. Using Activity Diagram
It is flow charts that are used to show the workflow of a system
Show the flow of control from activity to activity in the system
Flow of event in use case can be represented by activity diagram
Activity
Transition
Decision point
Synchronization Bars
Swimlances
Performance
of some behavior
Used to partition an activity diagram
according to responsibility
(person or organization)
The passing of
The flow of control
Branch according to
Some condition
Used to Show
concurrent activities

11. 1.2. Using Activity Diagram (Course Register Example)
Swimlances
Activity
Decision point
Synchronization
Bars
Transition

12. 1.2. Step-by-Step Outline: Withdraw Cash
What are other alternatives?

13. 1.2. Exercise 2: Write a Step-by-Step Outline
Select use cases from previous exercise
Write a brief description
Write a step-by-step outline
Identify basic flows
Identify alternative flows

14. 1.2. Packages: Organizing the Use Case Model
Use-Case Packages
Top-Level Package
Use Cases
Actors

15. 1.2. Checkpoints for Use Cases
Is each use case independent of the others?
Do any use cases have very similar behaviors or flows of events?
Has part of the flow of events already been modeled as another use case?
Create use-case packages when the model is large and/or the responsibilities for parts of the model are distributed
Packaging is intuitive and makes the model easier to understand

16. 1.3. Step 2 for Creating Use Case Specification
1.1. Identify actors and use cases
1.2. Outline each use case
Brief Description
Basic Flow of Events
Identify Alternative Flows of Events
1.3. Detail each use case
Add detail
Pre and post-conditions, special requirements, relationships, use-case diagrams, and so on
1.4. Structure each use case 1 2 3

17. 1.3. Why Detail Use Cases? Specify the software requirements
Clarify important details in flow of events
What the actor does
What the system does in response
What information is exchanged
Describe additional information
Preconditions
Postconditions

18. 1.3. Detail a Use Case 1. Find the actors and use cases
2. Detail the use cases
<Use-Case Name>*
1. Brief Description*
2. Flow of Events*
Basic Flow of Events
Alternative Flows of Events
3. Special Requirements
4. Preconditions
5. Postconditions
6. Extension Points
7. Relationships*
8. Use-Case Diagrams
9. Other Diagrams/Enclosures
Brief Outline
Add Detail

19. 1.3. Detail the Basic Flow of Events
Structure the flow into steps
Number and
title each step
Describe steps
(1-3 sentences)
Make each step a roundtrip of
events

20. 1.3. Detail General Alternative Flows
Occurs anywhere in another flow

21. 1.3. Detail Specific Alternative Flows
Describe what happens
Start
Condition
Actions
Resume

22. 1.3. Preconditions Constraint on when use case can start
Not the event that starts the use case
Optional: Use only if needed for clarification
withdraw cash

23. 1.3. Postconditions Guaranteed true when use case ends
May contain variants
Optional: Use only if needed for clarification
withdraw cash

24. 1.3. Other Use Case Properties
Special requirements
Related to this use case, not covered in flow of events
Usually nonfunctional requirements
Extension points
Places in the flow of events to attach extensions
Relationships (same as in Use-Case-Model Survey)
Associations with actors and other use cases
Use-case diagrams
Visual model of all relationships involving this use case
Other diagrams or enclosures
Interaction, activity, or other diagrams
Pictures of the user interface

25. 1.3. Use Case Checkpoints
Are the actor interactions and exchanged information clear?
Does the communication sequence between actor and use case conform to the user's expectations?
Is it clear how and when the use case's flow of events starts and ends?
Is the subflow in a use case modeled accurately?

26. 1.3. Exercise 3: Detail the Use Case
Add detail to the step-by-step outline
Basic flow
Alternative flows
Identify preconditions
Identify postconditions

27. 1.4. Step 3 for Creating Use Case Specification
1.1. Identify actors and use cases
1.2. Outline each use case
Brief Description
Basic Flow of Events
Identify Alternative Flows of Events
1.3. Detail each use case
Add detail
Pre and post-conditions, special requirements, relationships, use-case diagrams, and so on
1.4. Structure each use case 1 2 3

28. 1.4. Structure the Use Case Model
What is structuring?
Factoring out parts of use cases to make new use cases
Why structure the use case model?
Simplify the original use cases
Make easier to understand
Make easier to maintain
Reuse behavior
Share among many use cases

29. 1.4. Relationships between Use Cases
Include
Extend
<<include>>
<<extend>>

30. 1.4. What is an Include Relationship?
A relationship from a base use case to an inclusion use case
The behavior defined in the inclusion use case is explicitly inserted into the base use case
Inclusion
<<include>>
Base

31. 1.4. Include Relationship: ATM Example
Withdraw Cash
Deposit Funds
Transfer Funds
Inquiry Account
Identify customer
Report
Bank
Consorium
Customer
Identify Customer Use Case
1. ATM은 카드의 유효성을 확인한다.
2. 사용자 선택 기능이 비밀번호가 필요한 것인지를 확인한다.
3. ATM은 사용자에게 비밀번호 입력화면을 출력한다
4. 사용자는 ATM에 비밀번호를 입력한다.. …
A1: 잘못된 카드일 경우
A2: 비밀번호가 틀린 경우
A3:
withdraw Use Case
1. ATM은 고객의 유효성을 확인하기 위해 ‘Identify customer’ 유스케이스를 포함한다..
2. ATM은 사용자에게 인출금액 입력화면을 출력한다.
3. ...

32. 1.4. Execution of an Include
Fully executed when the inclusion point is reached
Use Case Instance
Base Use Case
Included Use Case

33. 1.4. Why Use an Include Relationship?
Factor out behavior common to two or more use cases
Avoid describing same behavior multiple times
Assure common behavior remains consistent
Factor out and encapsulate behavior from a base use case
Simplify complex flow of events
Factor out behavior not part of primary purpose
Inclusion
<<include>>
Base

34. 1.4. What is an Extended Relationship?
Connects from an extension use case to a base use case
Insert extension use case’s behavior into base use case
Insert only if the extending condition is true
Insert into base use case at named extension point
Base
<<extend>>
Extension

35. 1.4. Extended Relationship: Order Processing Systems Example
Insert ‘Backorder item’ use case if the item is sold out
Adding new orders
Backorder the item
Modifying existing orders
Accounting
System
Accounting Manager
<<extend>>
Partial use case diagram for order processing system

36. 1.4. Extended Relationship: Order Processing Systems Example
Adding order Use Case
Basic Flow:
1. The system requests that the accounting manager enter the order information .
2. Once the accounting manager provides the requested information, the system generates and assigns a unique order number to new order. New order is added to the system.
3. The system checks if there are enough inventories of the ordered items. …
Extension Points:
The “Sell out”
extension point occurs at Step 3 in the Basic Flow.
Backorder Use Case
This use case extends adding order and modifying order usecase, at extension point “sellout”
Basic Flow:
1. The system prompts that it is impossible to order due to out of stock and asks the accounting manager if he/she wants to backorder the item .
2. The accounting manager informs to the system that he/she wants to backorder the item..
3. The system sets the status of order as “backordered” and pre-occupies the amount which has been ordered in the inventory information.. …

37. 1.4. Execution of an Extend
Executed when the extension point is reached and the extending condition is true
Base Use Case
Use Case Instance
Extension Point
Extension Use Case

38. 1.4. Why Use an Extended Relationship?
Factor out optional or exceptional behavior
Executed only under certain conditions
Factoring out simplifies flow of events in base use case
Example: Triggering an alarm
Add extending behavior
Behavior developed separately, possibly in later version
Example: Get News UC
Base
<<extend>>
Extension

39. 1.4. How to Describe User Interfaces
Enclose sketches of proposed screen appearance with the use-case descriptions
Be careful not to specify too much of the design in the use-case documents

40. 1.4. Use Case Modeling Guidelines
Notations to use and not use
For example, whether to use generalization relationships
Rules, recommendations and style issues, and how to describe each use case
Recommendations for when to start structuring the use cases (not too early)

41. 1.4. Discussion: Structuring the Use Case Model
How should we structure the use case model for our class project?
Include relationships?
Extend relationships?

42. 1.4. Discussion: Structuring the Use Case Model
For specifying SRS (Software Requirements Specification), we should write not only use case specification, but also non-functional specification (supplementary specification)

43. 2. Create Non-Functional Use Case Specification

44. 2.1. What About Non-Functional Requirements?
Quality requirements
Usability
Reliability
Performance
Maintainability
Compliance with Legal and Regulatory requirements
FCC
FDA
DOD
ISO
Design Constraints
Operating Systems
Environments
Compatibility
Application Standards

45. 2.2. Specifying Usability Requirements
Definition of “usability”
The ease with which software can be learned and operated by the intended users
Usability requirements
Training time requirements, measurable task times
User abilities (beginner/advanced)
Comparison to other systems that users know and like
Online help systems, tool tips, documentation needs
Conformity with standards
Examples: Windows, style guides, GUI Standards

46. 2.3. Specifying Reliability Requirements
Definition of “reliability”
The ability for the software to behave consistently in a user-acceptable manner
Reliability requirements
Availability (xx.xx%)
Accuracy
Mean time between failures (xx hrs)
Max. bugs per/KLOC (0-x)
Bugs by class - critical, significant, minor

47. 2.4. Specifying Performance Requirements
Definition of “performance”
A measure of speed or efficiency of the running system
Performance requirements
Capacity
Throughput
Response time
Memory
Degradation modes
Efficient use of scarce resources
Processor, memory, disk, network bandwidth

48. 2.5. Specifying Maintainability Requirements
Definition of “maintainability”
The ability of the software to be easily modified to accommodate enhancements and repairs
Supportability requirements
Languages, DBMS, tools, etc.
Programming standards
Error handling and reporting standards
Often difficult to specify
If not measurable or observable, it is not a requirement
Is it a design constraint?
Is it an intent or goal?

49. 2.6. How to Describe Communication Protocols
Specify a communication protocol if the actor is another system or external hardware
The description of the use case should state if some existing protocol is to be used
If the protocol is new, it will be fully described during object-model development

50. 2.7. What about Design Constraints?
A requirement allows more than 1 design option
A design is a choice among options
A requirement that leaves no options is a design constraint
Distinguish it from other requirements
Place in a special section of your software requirements
Identify the source of each
Document the rationale for each
Examples
An algorithm that is required to be used
A database system that is required to be used

51. 2.8. Identify Non-functional Requirements using DOORS
Determine where nonfunctional requirements should be specified
NF specification
Hand out

52. Non-Functional Req. Spec.
3. Organize SRS
using Use Case Spec.
and
Non-Functional Req. Spec.

53. 3.1. What do Software Requirements Specify?
Inputs
Outputs
System
Environments
Functions
Performance

54. 3.2. Specifying the Software Requirements
Initial Req. Spec.
Needs
Features
SRS
SRS Package
Use-Case Model
Supplementary Specifications
Software Requirements
The Software Requirements Specification (SRS) package defines complete external behavior and characteristics of the system to be built.

55. 3.3. Role of the SRS Package
Basis of communication between all parties
Contractual agreement between parties
Basis for development: design, implement, test
SRS
SRS Package
Use-Case Model
Supplementary Specifications

56. 3.4. What is an SRS Package? Overview of entire SRS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 Use-Case Model Survey
2.2 Assumptions and Dependencies
3. Specific Requirements
3.1 Use-Case
3.2 NF requirements
4. Supporting Information
Appendixes
Index
Overview of entire SRS
General factors affecting the product and its requirements
All of the SW requirements

57. 3.5. Where to Document Items In the SRS Package?
Project Database
Documents
Where to maintain information depends on:
Available tools
Developer environment and preferences
Client environment and preferences
Size of the project

58. 3.6. How to Specify Functional Requirements?
Use both use cases and declarative statements
Both are necessary to understand any system of significant complexity
Give preference to use cases, where appropriate
Use Cases
The system shall …
The system must …
The system shall ...
Declarative Statements + ?
Which one to choose?

59. 3.7. What about Requirements Not in Use Cases?
Write a declarative statement to describe the software requirement
Number and title each requirement
Group related requirements
Use language the team easily understands
Use simple sentence structure
Subject + active verb
Consider using a keyword, for example “shall”
Keep it short
State the requirement in 1 to 3 sentences
Use terms from the glossary

60. 3.8. Where are Declarative Requirements Specified?
Does the requirement apply to a use case?
Specify in the Use-Case Report
In “Special Requirements” property
Does the requirement apply to the whole system?
Specify in the “Non-functional Req. Specifications”

61. 3.9. Writing SRS using DOORS
Using DOORS, we can writing SRS based on Use Case Spec and NF Requirements Spec.

62. Summary (1/2) Specifying SRS is consisted of as followings
Create use case specification
Create non-functional specification
Writing SRS
Step of Creating use case specification
Identify actors and use cases
Outline each use case
Brief Description
Basic Flow of Events
Identify Alternative Flows of Events
Detail each use case
Add detail
Pre and postconditions, special requirements, relationships, use-case diagrams, and so on
Structure each use case’s flows of events

63. Summary (2/2) Non-functional requirements specification describe
Quality requirements
Compliance with Legal and Regulatory requirements
Design
The Software Requirements Specification (SRS) package defines complete external behavior and characteristics of the system to be built
It is consisted of use case specification and non- functional requirements specification