First, the demand contradictions according to the authority of Chao, although since the "Software Crisis" has been made, the software engineering method has achieved great development and progress, but the success rate of software project last year is still less than 30%, and most software projects are still Super progress, 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 the software demand, analyzes the practice of this phenomenon is the root cause of this phenomenon lies between customers and developers. Communication has obstacles, both parties communicate with their own perspectives, which makes everyone reach a consensus on 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, the practice of modern demand is for these phenomena. Many of the sages began practical, and summed up a series of excellent demand practices: 1) USE Case: Use case analysis technology Ding Ting's RUP is this summary: use case drive, to system The structure is a central, iterative, and 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 Material User Story is one of the best practices recommended in Kent Beck in Extreme Programming (XP) Methodology. 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 feature driving development (FDD) methodology. One feature is a small, capable of customer value, usually expressed as
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 use example (scene) is a series of actions executed in the system, which will generate a specific participant visible value result, one use case definition (scenario). An example should provide a participant (implementation) a value. 3.3 The event stream is like a class, and an instance of a use case is the use scenario. The use case is a summary of the use of scenes: 1) Pre-condition: Refers to the participant (actor) and system In what state, this state should be that the system can detect, observable; 2) post-case: The system should be in what state, this state should also be the system can detect, observable; 3) Basic event stream: Basic event stream is a description of the conventional and expected paths in the use case, also known as the Happy Day scene, and the scene encountered most of the time; it will reflect the core value of the system; 4) Expansion The event stream: It is mainly to describe some abnormal conditions and select branch. It is recommended that you pay attention to the following points: 1) Use simple grammar: the subject is clear, the semantic is easy to understand; 2) Explicitly write "Who Control Ball": That is, in the event stream description, let readers intuitively It is understood that participants are controlled or the system is controlled; 3) Write from the perspective of top view: pointing out the participants' movements, and the system's response, the third party's angle; 4) Display process forward: That is One step is a sense of progress (for example, the user presses the Tab key as an event); 5) Show participants' intentions instead of action (light action, people are not easy to directly understand from the event stream Use case); 6) includes "reasonable activity set" (request, system confirmation, change inside, return results); 7) Use "confirmation" rather than "check": (if the system confirms the user's password correctly, Non-system checking the user password is correct); 8) Selective reference to time limit; 9) Adopting the "User Let System A Interaction" habitual term; 10) Use "loop to perform step x to y, until the condition is satisfied "The habit language. Fourth, the use case analysis technology in Alistair Cockburn Eye In terms of 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 rule in the case, and even the feeling of appearance.
Just as Cockburn, the three phases of learning use case analysis technology: 1) Guard: practice basic kung fu, follow the rules, take an obstacle; 2) Broken: Broken through the tradition, and flexibly applied for local conditions; 3离 离:: 脱 脱 招 招 式 则 则 则 则 则 则 脱. 脱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 has made some additions to Ivar Jacobson: 1) The use case is the contract, which is a contract that the system and the crowd. That is, the use case is developed in a formal direction; 2) Divide the use case into three levels: ◆ Summary level: including multiple user objectives (display the context of user target operation, showing the life cycle of the related target, providing one for low-level use case Catalog table); ◆ User target level ◆ Subfunction 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. V. V. How to analyze the application case analysis technology during the development process, the status of the technique in the demand process is shown in the figure below: Two largest misunderstandings on the use case analysis technology understand: 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. It is not possible to replace these technologies; 2) Use case analysis technology is an decomposition technology: A real use case analysis technology is a synthetic technology, which will be in demand capture Collecting Zerasatics Synthesis: 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, the representative, characteristics, Ability); 2) Determine the representative (naming, brief description, responsibility, participation); 3) Join the representative (interview, questionnaire, consultant, review, role play) in the project; 4) Creating a common idea (problem Definition, system range, user objectivity, non-functional demand à foreground document); 5) Adopt traditional demand capture technology capture requirements; 6) Set up the use case analysis team (small, problem domain knowledge). 5.2 Precautions for use cases During use, the process of use case analysis is shown in the figure below: Want to pay attention to: 1) Use an example to be in the case of the public, please do not write a use case; 2) During the writing of the exemption flow, it should Fully join the participation of the team;
