Use Case capture requirements

This article is from my PPT that provides case training. This article includes
1. Basic concepts of Use Cases
2. Functions of Use Cases
3. Where to find use case clues
4. How to discover Use Cases
5. Guidelines for writing Use Cases
6. How to determine whether the system use case is valid

1. Basic concepts of Use Cases
(1)Requirement Analysis (Case Technology), system analysis (OOA), system design (OOD), system implementation (OOP)
(2)The main function of use cases is to captureHigh-level (High Level) UserFunctionalityRequirement
(3)The use case describes a logically complete functional process from the user's perspective. Use cases demonstrate how people use the system.
(4)Use Case vs function list.
(5)The main value of a use case is:Users' goals and opinions.
(6)Use Case Representation: use case diagram and use case text
Example: POS system sales examples:

Use Case text for the POS system to process sales:
1. The customer carries the purchased item to the cashier.
2. the cashier starts a new sales transaction.
3. the cashier enters the product barcode.
4. The system records the sold items one by one and displays the descriptions, prices, and accumulated amount of the items. The price is calculated based on a set of price rules.
Cashier repeated 3 ~ Step 4 until the input is complete.
5. The total amount is displayed.
6. the cashier informs the customer of the total amount and asks the customer to make the payment.
7. The customer pays and the system processes the payment.
8. The system records the complete sales information and notifies the accounting system and inventory system of the information.
9. The system prints the ticket.
10. The customer leaves with the goods and bills.

(7)Scenario.
A scenario is a path of case execution.
Active (successful) and alternate (extended) Scenarios
Generally, a use case contains one home scene and multiple (or zero) Scaling scenarios.
The main scenario of the use case should not exceed 10 steps.
The greatest value of use cases is not in the main scenario, but in alternative actions.. The main scenario may only occupy 1/4 to of the Instance length.

2. Functions of Use Cases
During the entire software development process using UML, use cases are in a central position.
(1) Workload estimation must be based on the currently discovered use cases.
(2) The UI is designed with the help of use cases.
(3) many classes are discovered based on use cases.
(4) The Scenario Description of the use case is the basis for creating a sequence chart and collaborative drawing.
(6) test instances are generated based on use cases.
(7) the entire development management and task allocation should be organized based on use cases.

3. Where to find use case clues
(1) blueprint document.
(2) pre-arranged documents.
(3) domain glossary.
(4) talk with domain experts and end users.
(5) functional specifications and work statement.

4. How to discover Use Cases
(1) determine who will use the system directly. These are participants.
(2) select one of the participants
(3) define what the participant wants the system to do. Everything the participant wants the system to do is a use case.
(4) for each case, when a participant uses the system and what usually happens during use, this is the basic process of the use case (main success scenario)
(5) describes the basic process of the case. (More participants may be found at this time)
(6) Consider some variable situations and create them as extension scenarios.
(7) Repeat Step 2 ~ 6. Find out each use case.

5. Guidelines for writing Use Cases
(1) criterion 1: use cases are not graphs but texts
The main activity of case modeling is to write text instead of creating images. Only the text can fully describe a use case.
Text and graphics are complementary. We can use graphs to quickly browse and view all use cases. If you need to go deep into the details of a use case, you can read the corresponding use case text.
(2) Criterion 2: Use Cases Written in an essential Style
Example: cashier Login
Specific style: for example, textbox and button on the Interface
Essential style:
A. the cashier signs his identity
B. The system authenticates this identity.
When writing use cases, You Need To screen the user interface and focus on the intent of the participants. Compiling regular meetings in a specific style creates potential constraints for future design. Without these constraints, the designer can establish a system that correctly achieves objective and visible behaviors more freely, it also provides a possibility for the emergence of breakthrough solutions.
(3) Criterion 3: Compile black box Use Cases
Black box use cases do not describe the internal work, components, or design of the system. On the contrary, they describe the system through duties.
The Use Case specifies what the system must do (behavior and functional requirements) without deciding how the system should do (design ). In case modeling, we should avoid making "how" decisions.
(4) Criterion 4: Define use cases from the perspective of participants
The most significant difference between case-oriented requirements and Traditional functional requirements lies in actor. The reason why the system exists is that actors need to interact with the system to achieve certain goals.
System Viewpoint = actor Viewpoint
(5) criterion 5: Compile simple Use Cases

6. How to determine whether the system use case is valid
If the system use case can pass the following three tests, the system use case is valid.
(1) test by the boss (avoid the use case level being too low)
(2) EBP (Basic Business Process) test (avoid too long or too short, avoid too many or too few steps)
(3) scale test (avoid being too small or too large)
 

From: http://www.cnblogs.com/zhuweisky/archive/2006/12/23/601196.html