Use use cases to get requirements

Introduction：

Research and development often use a typical scenario (scenarios) to understand what the needs of a system are and how the system works. Unfortunately, while research and development have done so, he rarely archives in an effective form. The use case (use-cases) is a formal, formalized technique for capturing these scenarios.

The use case is Jacobson in the software engineering of the image object, but he is actually independent of the surface object. Use cases are an effective way to gain business process and system requirements. And the technology itself is very simple and easy to learn.

Enable requirements to be browsed

Formal scene acquisition is intended to enable both users and developers to view these scenarios. All functional requirement symbols must meet the following two guidelines:

It should be easy for the source of the requirements and the viewer to understand, and

Should not contain all the details of the form and content of the system

Functional requirements are external requirements that are used to assess the design and eventual implementation of the system.

The needs and expectations of buyers (stakeholders) should be obtained in a system-independent manner.

Use cases to enable requirements to be browsed

Use cases are being used widely. Use cases have been successful compared to other requirements analysis techniques because:

Use cases treat systems as black boxes

Use cases make it easy to understand the implementation precision of requirements

The latter comes from the former. Use cases should not involve all of the internal structure of the requirement-related system, so if the use case points to "submitting changes to the order database" or "displaying results on a Web page", the internal structure is obvious and can be identified as a potential design constraint.

Requirements should not involve all internal structures because: describing the internal structure brings additional constraints to the designer. Without these limitations designers will have greater freedom to establish appropriate systems for the implementation of externally observable behavior and possibly provide breakthrough solutions.

Industry acceptance of Use cases

The use cases were officially released about six years ago and have since been absorbed by most major object methods. Use cases have also been absorbed by the Business Process Engineering Association (business process Reenginerring community) as an effective way to describe existing and future mode business operations.

The use case itself has recently been highlighted by its position and position in UML. UML has been accepted by the OMG as the standard modeling language for object systems.

What is a use case

The use case itself refers to an interaction between a user or other system and the system to be designed, and this interaction is achieved to a certain target (goal). A term performer (Actor) used to describe a person or system that has that goal. The term emphasizes the fact that everyone or the system has a goal. The target itself is a verb phrase, such as "Customer: Place Order", "Clerk: Record Inventory".

As part of a use case, it is necessary to document the meaning of the target's success and failure for the activists and the system. In an instance of placing an order, the target may include the goods to the activists and the company to receive the corresponding payment. Careful definition of goals or failures is the basis for defining system scope (SCOPE). Because for a simple order-entry system, the goal may simply mean that the order has been validated and delivery is scheduled.

Tasks in a scenario

A different scenario in a use case shows how a goal is achieved or failed: the goal in a successful scenario is reached and the goal in the failed scenario is not achieved. Here is the wonderful place: The goal summarizes many of the system's use intentions, and users can see that they are expected to use the stench system. Of course, the system does not support all of their goals, users can immediately detect without waiting for the first prototype to develop, or even bad enough to wait until the whole system developed to discover.

How big should use cases be?

An interesting topic is trying to determine the size of a use case. One approach is to associate size with the scope and intent of the use case. For a really large scope, a use case not only describes a single system, but describes all the systems that a business uses. This business use case (business) uses the entire system as a black box and describes the target of the activity and the company. The scenario of a business use case does not make all assumptions about the company's internal structure. This means that the user should place an order with the company, not the customer service department.

For system development, the scope of a use case is limited to a single system. This is a more common form of use cases, called system use cases, which use the system as a black box. These use cases cannot describe all internal structures and can only use the language of the problem domain.

Another scope of the use case is the design of subsystems or components within the system. These implementation-level use cases (Implementation uses case) treat the widget as a black box, and the active is the component with the interface. For example, you might use an implementation-level use case to illustrate the need for an application to use an email widget.

It is easy to discuss the use case size in this hierarchy. The total size (patterns size) of the design project (item) is defined. To help system designers, each use case should only describe a single activity thread (thread) without a Oita branch. The violation of this constraint, which is often seen in imprecise or ambiguous criteria, makes it very difficult to describe the use case as a test of the source material.

As an example of a system use case, "asking if database inventory is low" is too small to mix implementation details and requirements. In contrast, as a system use case, "management warehouse" is too large, because it is not possible to be a single activity leads without large branches, and from the system, it is very difficult to describe the goal success. But he is a very good parts department business use case. For the Sub-department, it is possible to define the success of the "Manage warehouse" goal (possibly using terms such as inventory changes, departmental capacity, or operating costs).

The advantage of a business use case is that it can be used to categorize other use cases. The Manage warehouse can be used to combine all the use cases related to warehouse management.

Formal definition of Use case

A use case is the submitter of the result, and the result is measurable for a particular activity.

As mentioned earlier, an activity can be a person or an external system that interacts with the system to be designed. The need for measurable results for a use case is derived from a single clue requirement. As an aspect of measurable results, goals either succeed or fail without intermediate results. (Note: If present, you need to further decompose the refinement use case until a single clue.) )

Write a file to a use case

A good place for use cases is to write various forms of documents to the scene. Each scenario refers to a single path through a use case, which is a set of conditions from a certain point of view.

You can use unformatted text descriptions, but it is difficult to track when multiple conditions or possible failures occur. The unformatted narrative style is useful in trying to understand the initial phase of the requirement. However, in the next use case development, it is useful to use a more formal mechanism to write use case files.

Customer's rough frame (rough sketch): The use case for placing an order may be:

"Identify customers, check the required goods in the library and not exceed their credit limit".

The structure narrative (structured narrative) format provides a more efficient rate. This format describes an active person: the sequence of goals. The first thing to write down in this way is a simple success scenario, so the activists: the target statement assumes that the previous goal has been successful, and this is the simplest success scenario.

The use case holds that the system we are designing is a black box that does not record all of the internal structure and can be viewed as an independent performer of the intention to write the scene. (And it can be considered to being a single actor for the purposes of writing out of the scenario.) Use cases do not describe all the situations within the system, only what the system has and what goals are the use cases should handle.

—————————-

1. Clerk:identify Customer

2. System:identify Item

3. System:confirm Ship Quantity

4. System:confirm Credit

5:customer:authorize Payment

6. System:dispatch Order

Extensions

1a. Customer not Found

1a1. Clerk:add New Customer

3a. Partial Stock

3A1 clerk:negotiate Quantity

—————————-

Failed to process target-extended

The next step should be to note that each of the steps noted above may fail. The condition that causes the failure can be acquired as an extension of the scene. These extensions are written by writing down the part of the scene after the failure condition, following this part of the scene until it returns to the subject or fails.

Detached failure conditions facilitate a more readable scenario. The basic success scenario is through the simplest path of the use case, where the target of the activity is achieved in every step of the way. Independent listing of all failure conditions can provide better quality assurance. It is very easy for the viewer to check whether all the conditions have been specified or more likely that the conditions have been ignored. Failure scenarios can be recoverable or unrecoverable. The recoverable scene eventually succeeds, and the unrecoverable scene fails directly.

Failure in failure

Another complication to note is that there may be other failures in the failure scenario. This means that the extension area may have a further failure, and he can use a slightly longer prefix digital ID: 1a1b. Customer is a bad credit disorientated. This can be recovered in 1a1b1.

Why use a structured narrative format?

The value of a structured narrative is that he is irrefutable (refutable). The meaning of a rebuttal description is that he is accurate enough to argue or agree:

"He doesn't work like that. ”

"We don't check availability when we accept orders." ”

"You've lost some steps. ”

In contrast, the unformatted description provided by the rough frame is difficult to debate, but his early understanding of the problem domain is useful.

Another advantage of the rebuttal description is that when you write a file to a use case, you want to get feedback from the user and the developer (expect to). This is very valuable because he means the problem will be corrected early in the development process. Typical user feedback is to indicate different sequences, possible parallelism, or missing steps. The typical feedback from the developer is related to the definition of a particular failure condition and how to detect his needs.

Image symbols for use cases

An image symbol useful to describe a use case. Use a simple hockey hand symbol in UML to represent the active person, and the ellipse represents the use case, as shown in Figure 1 below. These graphs are great when you want to look at the interrelationships between a set of use cases and the general diagram of the system.

The use case diagram does not show a different scene, and he uses the relationship between the active and the use cases to show. Therefore, use case diagrams need to be accompanied by structured narrative text. UML has some diagrams to represent different scenes instead of narratives, and the common diagrams are interactive and activity diagrams. The main disadvantage of these graphs is that they are not as concise as text, but are useful for giving a general sense of the use case. Instructions for interaction diagrams and activities refer to "UML distilled", Martin Fowler (AW 1997).

Get demand Reuse

The value of writing a use case description in the "Active Person: Target" format is that he breaks a use case into many factors (steps) that transform a common factor into a child case. The common part can then be used by the main use cases. For example, the identification of an order to the customer this step can be used by many other use cases.

(Note: This is one of the common generalization relationships among use cases in UML: using.) This explains how the formatted text can effectively analyze the parts that can be used by other use cases during the requirements analysis process. )

Complexity and risk of application cases

No connection between basic activists and use cases (connection)

Sometimes there is no clear link between the activist who wants to benefit from the use case and the active parameter and the activity of the use case. For example, the hosting accountant (figuratively accountant) may be the "research invoice" activity, but they will not necessarily be active in the initial invoice operation (actually initiate the invoice run). This is a problem, and the use case is still valid, except that the link between the activists is valuable (getting the value) and the use case's initial situation is just beyond the scope of the system design. Basic activists are still useful because the person who plays the role is the person you write the use case file to talk to.

Scene steps do not have to be serialized

When sequential steps in a scene are not valid, there are several mechanisms that can highlight possible parallelism. Activity diagrams are the best choice in UML, but informally, you can find parallelism by looking at the use case scenario, looking at the same activists and the steps that are next to each other in the use case. In our previous example, there is the possibility of parallel confirm the ship quantity and confirm credit. Sometimes it is useful to note this possible parallelism in a use case file.

Determining use Case Size

The absolute risk of starting using use cases is that there are many steps or too few steps. If there are more than 15 steps in the use case, some implementation details may be included. If the steps are too few, check to see if the target can be reached by independent activity leads without the branches.

Very few (if any) human activists

If very few human activists, most use cases come from other systems, the mechanism used to identify the use cases should be changed. Communicate with the activists (using machines to do a little:-), instead of finding external events that the system must respond to or identify.

Requirements analysis and system complexity

Overall, scenario acquisition is associated with system complexity, but even large systems use "activists: Goals" to write relatively concise files. The value of the use case format is that, unlike a large number of unreadable feature descriptions, use cases enable users and developers to identify the activists and then confirm that the listed targets meet (or do not conform to) the job responsibilities of the activists.

But the system is not just a functional requirement

Use cases do not capture all external requirements of the system. Use cases have very little access to the functional requirements of how the system will be used. There are many other aspects of demand that need to be captured and addressed. However, some non-functional requirements are relevant so that they can be attached to a use case. An example is such as yield (throughput) and performance (configured). Other requirements that do not use the association need to be obtained separately. This example may be:

System Range

The user's goal to the system

User Interface Prototypes

Common rules

Limit

Algorithm

Run-time Requirements for construction-time requirements

An important factor to be credited when acquiring requirements is that the members of the system (constituency) are much larger than the user community. There are different customers in the system, and the use case takes only part of the requirement. In essence, a use case takes only the run-time requirements of a system and ignores a major customer: the system development Organization. The System development organization is interested in describing the structure of the system.

Runtime requirements include: System scope, goals, and user organization expectations of the product, use cases, and other non-functional requirements.

Construction-time requirements include: Easy research and development, robustness in the face of change, reuse of existing artifacts.

Construction-time requirements can be handled separately using use case diagrams, but research and development organizations also need to address many other aspects:

Project scope and Objectives: what the project must provide (as opposed to system-wide, the system scope is usually provided in multiple projects).

Examples of growth and change: This can be used as a "change" in the usual use case format to get

Research and development Hosting constraints: This includes the concepts and practices of standards, practices, tools, quality measurement (measure) and Quality assurance (assurance)

Applicability of Use Cases

Use cases are primarily for systems that need to respond to external events. They can also be used in other systems that have clear and understandable targets.

Use cases cannot be used when external results are defined or ambiguous.

This means that if the goal cannot be defined, the use case cannot be used to obtain that requirement.

It should be noted that most modern object methods use use cases because the use case has been proven to be a very effective mechanism for demand acquisition.

Summary

Use cases obtain requirements in a readable, rebuttal format. A use case is a rebuttal description of the system's functional external requirements.

It can be argued that when you write a file for a use case, you expect to get feedback from users and developers about the quality of the use case.

Use cases do not need to be precisely defined from the outset, and the typical development sequence is as follows:

1, identification activities are

2. Identify the target of the active person

3. Identify the meaning of each "activity: Goal" to success or failure

4. Identify the basic success scenarios for these use cases

5, in the refinement process, identify failure conditions and recoverable/unrecoverable scene

It is only necessary to enter the fourth step when determining which release of the product a particular use case will be developed.

In general, use cases are an effective demand-acquisition technology that enables demand to be browsed, avoiding all the biases in the requirements.

Thank

This article is greatly affected by Alistair Cockburn's "structuring use cases with Goals", please refer to the original text and a set of case file templates in Http://member.aol.com/acockburn.

The original is: Using use Cases for requirements capture Pete McBreen (C) 1998 mcbreen.consulting

Can be found in http://21newtimes.yeah.net/.