What the use-case model does: notice what

Before we talk about how to build a use case model, what should be paid attention to when building a use case model?

Problems to be noticed in building use case model

To give you a few common problems in building use case models and principles to follow:

A How to discover Use cases

After the above explanation, I believe you have a whole concept of building use case model, and then start to practice drawing use case model. At this point, a very serious problem arises: how to discover use cases. The master once gave the answer, the general meaning is: first select the system boundary, and then identify the main participants, define the use case to meet the user's goal, name it. However, I have proved in practice that this set of methods is too theoretical and impractical. Perhaps it would be more realistic for us to move on to a different line of thinking.

When we start a requirement analysis for a project, we must listen to the customer talk about their needs, or look at the business requirements documents submitted by the customer. In this case, the customer will certainly come up with one or another function or requirements, each of them becomes our original use cases. Analyzing these use cases, focusing on each of their participants, and their relationships with each other, forms the first use case model. In particular, we should be reminded that when we use use case analysis to communicate with our customers, we should focus on the participants and their goals, i.e. who are the participants of each feature, what is the goal of accomplishing this function, and how to accomplish this goal. The use case illustrates the overview, which is a description of the main success scenario (the basic process).

Since then, we continue to communicate with customers, on the one hand, continue to refine the use cases, the replacement of each use case (branch process) is gradually sorted out, use cases in a step-by-step refinement. At the same time, our understanding of some needs may be biased at first, so we are constantly correcting our use-case descriptions. On the other hand, some new features are proposed by the user to form some new use cases.

After so many rounds, the overall framework for project requirements became clearer, and we began to discuss system boundaries. This is that we need to make an adjustment to our use case model. We began to consider which systems are related to our systems, while others are excluded because they are not within the system boundaries.

It takes so many iterations to finally form the use-case model that we need.

Two What is a valid use case

In the process of communicating with your customers, customers will ask a lot of needs, that is to put forward many of the system you want to achieve the expectations. However, not all of these are effective in forming use cases. which are valid use cases, there is still a standard of evaluation, we usually use three kinds of test methods to judge: Boss Test, EBP test, scale test.

1. Boss Test. If your boss asks you "what you're doing all day," and your answer is: "Login system," This obviously doesn't make the boss happy because your answer is not quantifiable. A value that is not quantifiable is an operation that does not increase productivity and results in value, that is, the operation is of no value to the boss. If you write a use case that does not have quantifiable value, you cannot pass the boss test and it is not a valid use case. Boss test is the lowest level of use case effectiveness test.

2. The EBP Test (elementary Business Process) is defined as follows:

A person at a certain point in time, the task performed in response to a business event, can be tested by EBP if it increases quantifiable business value and retains the data in a persistent state.

EBP tests quantify the effectiveness of use cases in a more precise way. In addition to requiring valuable business operations, it must generate valuable, persisted data. At the same time, it requires the timeliness of accomplishing this task, that must be done in one session. A use case that lasts a few days or spans multiple sessions cannot pass this test.

3. Scale testing, that is, a use case must reach a certain scale to be effective. What size must be achieved? It is usually necessary to include multiple steps, and the description of the use case in the detailed form usually lasts several pages. One typical error that cannot be tested by scale is that one of the system steps is used as a use case.

In general, you must pass the above three tests to be a valid use case, but there are exceptions. For example, some child cases or extension cases that are extracted from use cases to improve reusability may not pass EBP tests or scale tests, but they are still valid use cases. Another exception is the "authenticated user" use case, which may not be tested by the boss, but is still valid.

Three The core of the use case model is text, not graphics

As the title, the use-case model focuses on use-case descriptions rather than use case diagrams. When you build a use case model, it can take only dozens of minutes to draw a use case diagram, but it takes hours or days to write a use case description. A use case diagram is just the most intuitive presentation, and a use case description is the most detailed description of the business requirements.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

Four Write a use case in black box

Black box Use cases, which describe use cases as responsibilities, do not describe the work, build, or design within the system Black-box. It embodies an important thought of ood/a-encapsulation, metaphor of a ood/a theme-software elements have responsibilities. Therefore, the black box use case is one of the most recommended use case writing methods.

Five Writing use cases as participants and participants ' goals

The creator of the use case, Ivar Jacobson, defines the use case: the execution of the use case should produce "observable results of value to a particular participant". An important message conveyed in the definition of Jacobson is what is valuable to the participant. Therefore, two important viewpoints of use case analysis are to focus on the goals that the participants expect to achieve and to focus on the results that the participants deem valuable. When we write use case descriptions, we should write them in these two viewpoints.

Six Do not describe any user interface

This is a common mistake made by some people (including me). "Click xx button", "Show xx list" should not appear in the use case description of the text. Interface design should be done to the prototype design or interface design phase, not the use case design phase. Use-case analysis should eliminate the user interface and focus on the intent of the participants.

Seven and talk about building use cases in an iterative way.

In this article, I have repeatedly emphasized the use of iterative methods to build use cases. Iterations are a way of developing that is strongly advocated by RUP and later agile development, and it completely breaks down the waterfall development theory of the past in theory. Iterative development includes the following ideas:

1. The gradual refinement of the process from the whole. Human cognition is always a process from whole to local refinement, and iterative development embodies this objective law. At the beginning of the requirements analysis, we always divide the system into several large use cases, and draw several of the most important use cases for each large use case. The description of each use case, using an overview, simply writes out the main success scenario. Then, with one iteration, we are enriching our use cases, and the use-case descriptions are gradually becoming informal, eventually changing to a detailed way of writing out complete use case diagrams and use case descriptions.

2. A large segment of the development process is divided into numerous small stages. A software development project often lasts months or even more than a year. Demand analysis, too, often lasts several months. Many project development team can not complete the development task on time, or can not easily complete the development task, a very important reason is that, in the project implementation process, did not always assess whether their progress is on the normal track, also did not have the time to move the deviation progress back to the normal track. Satellites and aerospace aircraft are able to correct their orbits at any time because they regularly detect whether they are off track and project management is also needed. How to regularly check the progress of the project on the normal track? The answer is iteration. The iteration divides the demand analysis that lasts several months into an iterative period of 1-2 weeks. Each iteration has a goal in the project plan, that is, how far the project should go in the iteration. During project execution, each iteration is planned, executed, and summarized in three phases (if the iteration is 1 weeks, usually the plan is Monday, and then begins execution until Friday begins to summarize). When summing up, compare the goals that should be achieved during the iteration, and determine whether the project is on track and make the necessary adjustments.

3. It emphasizes the repeated communication with the customer. According to the idea of agile development, business change is ubiquitous, as the classic phrase: I changed when I saw it (when I see the software, the requirements begin to change). The waterfall development theory fails because it rejects this communication with the customer, and arbitrarily believes that the need for confirmation can no longer be changed, there is no need to continue to communicate with customers. In accordance with the idea of agile development, every time with the customer communication, should be reflected in the customer's views in the design and development. However, after the customer's comments are reflected in the design and development, we need to find a suitable time to feedback with the customer, let the customer confirm that the design is consistent with his requirements. Failure to respond to customer feedback in a timely manner does not guarantee that the project's progress has deviated from the customer's needs. Back to the topic of use-case analysis, use-case analysis should be divided into countless iterations, each of which should include three phases with customer acknowledgement requirements, use case analysis, and customer feedback. At the same time, use case analysis will continue to the entire project development process after the requirement analysis.

Summary of Use case analysis

Again to sum up time, every time I always know how to speak. I've used so much space to explain what the use case model is, and how it differs from the requirements specification and the advantages. The use-case model represents an advanced design idea and method that he can completely replace the requirements specification, but unfortunately it is still neglected by us (which is one of the purposes of my writing this article). Of course, you might say that many customers still require us to write requirements specifications as specified documents for requirements confirmation. Many units of the quality Management manual also requires us to write requirements specifications, as a part of quality management. Indeed, demand specifications still have a large number of fans, but I have to replace the requirements specification: Don't crush brother, brother is just a legend. Persuading the customer and the supervisor to switch to use case analysis may take a certain amount of time, however, using the requirements analysis process is use case analysis, the final result is written as a requirement specification, without losing the way to save the nation by another curve.

Postscript

I grew up reading has a characteristic, is superficial understanding. A book, especially a technical one, has never been interested in reading it from beginning to end. Even the chapters of interest are never word to read. It's my main job to look over the catalogue. Because of this way of reading, my childhood results must not be good, but I always can refine, the essence of many knowledge in the chest, jump out of the book to think about many more important things. The book I read is always thinner, and then I jump out to judge the author's ideas. is: lookers-on, the spectators.

The purpose of my writing these articles is to help you read the book thin, refine, and finally leave the really important questions to discuss with you. In the process of writing, I will divide the whole article into several chapters, several sections. For each chapter, I'll explain what I'm going to say in a short language. You don't have to look in a chapter, just look at the part you're interested in, superficial understanding, that's what Mr. Liu Zongyuan has given us.