In view of this article, this article causing the content in our comments, and the following statement is made:
1) This article is the author of the subject report on the subject report on the China System Analyst Year (CSai 2003, Changsha) last year. Therefore, it is not very fine. 2) For the readers who use an example, the author has an article on the model modeling in March 2004, believes that it can meet the needs of everyone.
First, the contradiction between demand
According to the authority statistics of CHAO, although since the "Software Crisis" has been made, the software engineering method has been greatly developed and advanced, but the success rate of software projects last year is still less than 30%, and most software projects still have progress, super cost. In these unsuccessful projects, due to factors in demand, incomplete demand, accounting for about 60%.
Although this comics below are exaggerated, it is able to provoke our deep thinking:
According to the author for many years, the practice experience of software demand, analyzes the practice of work, and believes that the root cause of this phenomenon is obstacling between the communication between customers and developers, both sides communicate with their own perspectives, their own professional terms, this Make everyone unable to reach a consensus on the software demand.
Since helping customers improve productive tools, it is the responsibility of our software development team, so we have no right to let users understand the language we use, but in turn, we have obligations to understand the language of the user, stand in Look at the problem from the perspective of the user.
In fact, many development teams often complain that "our customers are unclear", "our customers know too little about the computer." For many years, everyone has used to define and analyze problems from their own perspective. This also caused the software industry to become a most lack of trusting industry. We need to change it habits.
Second, modern demand practice
In response to these phenomena, many advances have begun practical, and summed up a series of excellent demand practices:
1) USE Case: Use case analysis technology
Ding Ding's RUP is this summary: use case drive, the system structure is centered, iterative, incremental development process. Use Case is also famous with RUP, UML together.
The use case is used to depict a contractual demand for an external visible demand, which is a contract that is reached between the system's behavior between the relevant personnel (risk assuments, and stakeholders).
2) User Story: User Story, User Materials
The user story is one of the best practices recommended in the Limit Programming (XP) method. It is written by customers, indicating what they need to do for them, generally written by customers, three sentences.
3) Feature: Features
This is one of the core practices of the feature driving development (FDD) methodology. One feature is a small, capable of customer value, usually expressed as
From the above definition, these three modern software engineering demand practices have no exception to comply with two principles: First, stand at the user's perspective, define the system; second, the language expression is used by the user. In the practice of the author, in view of the following two considers, "use case analysis technology" is applied in the team:
1) The user story is slightly rough, and the experience is required. There is no detailed rule to use the class, and it is easy to lose the direction at the beginning; and use the examples more formal, easy to get started;
2) The character is very attractive, but after all, the relevant theory is not complete, and it is difficult to introduce team practices. Third, use case analysis technology
The use case analysis technology is that Ivar Jacobson, one of Rational Three Friends, started research at Ericsson Company in 1967, and summarized in 1986, issued a demand analysis technique from practice. Mr. Ivar raised the UML after joining Rational, and has proposed UML, improve RUP, and use case analysis technology and therefore widely understood and concerns.
Use case analysis technology provides a basic element for software demand specificization, and this element is verified, measurable. Use examples can be used as a basis for project planning, progress control, testing and other links. Moreover, the use case can also make the communication between the development team and our customers more smoothly.
Many people have come into contact with USE CASE when they learn UML, so many people misunderstand them as a chart, and the examples of examples are analyzed. In fact, this is wrong, and the example description is the core of use case analysis technology. Here is a simple example: 3.1 Participants, actor
Participants define the roles played in the system interaction process, which can be a person or another related system.
3.2 Use case, USE Case
Example (Scene) is a series of actions executed in the system that will generate a specific participant visible value result, one use case definition (scenario).
An example should provide a participant (implementation) a value.
3.3 Event stream
As the class corresponds to the object, an instance of a use case is the use of the scene, and the use case is an abstract summary of using the scene:
1) Front conditions: Refers to what state should be placed when the use case is started, and this state should be that the system can detect, observable;
2) Back conditions: At the end of the use case, the system should be in what state, this state should also be the system to detect, observable;
3) Basic event stream: Basic event stream is a description of the routine and expected paths in the use case, also known as the Happy Day scene, and the scene encountered in most of the time; it will reflect the core value of the system;
4) Extended event stream: Mainly for some abnormal conditions, select branching.
It is recommended that you pay attention to the following points when writing an event stream:
1) Use a simple syntax: the subject is clear, the semantics are easy to understand;
2) Explicitly writing "Who Control Ball": That is, in the event stream description, let the reader understand that participants are controlling or the system is controlled;
3) Written from the perspective of top view: pointing out the action of the participant, and the response of the system, that is, the third party;
4) Display process forward: The first step has a sense of advancement (for example, the user presses the Tab key as an event);
5) Display the participant's intent rather than action (light action, people are not easy to directly understand the use case from the event stream);
6) Includes "reasonable activity set" (request, system confirmation, change inside, return results);
7) Use "confirmation" instead of "check": (if the system confirms the user password correct, not the system checks if the user password is correct);
8) Alternatively refer to time limit; 9) adopting the habitual language using "user to interact with system B";
10) The habitual term using "loop to perform step x to y, until condition satisfaction".
Fourth, use case analysis technology in Alistair Cockburn
When using the use case analysis technology, many people think how to determine the size of the use case is a difficult point, and it feels that there is no rules in the use of examples to comply, and even if there is any feeling. Just as the three phases of the learning use case analysis technology proposed by Mr. Cockburn:
1) Guard: practice basic kung fu, follow the rules, and act as a chapter;
2) Break through the tradition, flexibly applied in terms of local conditions; 3) Leveling any movements and rules, reaching the realm of uncomfortable.
However, the use case analysis technology has made the first phase of beginners feel unable to master. And "Writing Effective Use Example" wants to analyze technical supplemental rules for use cases, so that everyone can better master.
Mr. Cockburn made some additions on the basis of Ivar Jacobson:
1) The use case is a contract, which is a contractual contract between the system and the people. That is, the use case is developed in the form of formal direction;
2) Divide the use case into three levels:
◆ Summary: Includes multiple user objectives (show the context of user target operation, showing the life cycle of the related target, providing a directory table for low-level use case);
◆ User Target Level
◆ Sub functional level
However, for Mr. Cockburn's contribution, the original ancestor Ivar did not make any response. I believe that Mr. Cockburn's ideas and philosophy is very valuable for people who analyze technologies in beginners, so that the use case analysis technology is more operability, and it is also a bit of painting in the same way, maybe Mr. Cockburn is also realized. This, so the third stage is "away", there is no rule, and it is flexible on demand.
V. How to apply use case analysis technology in the development process
The status of the use case analysis technology is shown in the figure below:
Two largest misunderstandings on the use of sample analysis techniques are:
1) Use case analysis technology includes the entire demand process: it is just a demand analysis technology, which is used on the basis of traditional demand capture technology and cannot replace these technologies;
2) Use case analysis technology is an exploded technology: a real use case analysis technology is a synthetic technology that will be synthesized by the characteristics of scattered characteristics collected in demand capture:
5.1 Work before use case analysis
Before the use case analysis, you should do the following:
1) Determine the Stakeholder and the user type (naming, brief description, involving representatives, characteristics, capabilities);
2) Determine representatives (name, brief description, responsibility, participation);
3) Join the project in the project (interview, questionnaire, consultant, review, role play);
4) Creating a common idea (problem definition, system range, user objectivity, non-functional demand à foreground document);
5) Use traditional needs to capture technology capture requirements;
6) Set up the use case analysis team (small, problem domain knowledge).
5.2 Precautions during use case analysis
The process of use case analysis is shown below:
Pay attention to:
1) Use an example to be from the crowd, please do not write a use case;
3) Although the use of the rectificial origin is from the crowd, don't try to ask them directly. "Do you have any case? Quot; this problem.
