Case-driven demand process practices

Case-driven demand process practices
--------------------------------------------------------------------------------
 
From: Computer World Network Author: Xu Feng [2004/01/05]
I. Conflict of requirements
According to Chao's authoritative statistics, although the software engineering method has been greatly developed and improved since the "Software Crisis" was proposed, the software project success rate last year was still less than 30%, the vast majority of software projects still exceed schedule and overcost. In these unsuccessful projects, the demand is unclear, the demand is incomplete, and other factors, accounting for about 60%.
Although the cartoon below is exaggerated, it can arouse our thoughts:

Based on my years of practical experience in capturing and analyzing software requirements, I believe that the root cause of this phenomenon is the barriers to communication between customers and developers, both parties communicate with each other from their own perspective and terminology, which makes it difficult for everyone to reach a consensus on software requirements.
As it is our software development team's responsibility to help customers improve their work efficiency by using information tools, we have no right to let users understand the language we use, but vice versa, we are obligated to understand the user's language and look at the problem from the user's perspective.
In fact, many development teams often complain that "our customers cannot even clarify their needs" and "our customers know little about computers ". Over the years, everyone has been accustomed to defining and analyzing problems from their own perspective. This has led the software industry to become the most untrusted industry. We need to change our habits.
Ii. Modern demand practices
Many sages have started to practice these phenomena and have summarized a series of excellent demand practices:
1) Use Case: Case Analysis Technology
The well-known RUP summarizes its own case-driven, architecture-centric, iterative, and incremental development processes. The use case is also famous along with the use case of RUP and UML.
Use Cases are used to describe the externally visible requirements of a system. They represent the contract between project-related personnel (risk owner, stakeholder) in the system regarding system behavior.
2) User story: User stories and Materials
User stories are one of the best practices that Kent Beck recommends in the extreme programming (XP) methodology. It is written by the customer to explain what the system needs to do for them. It is generally written in the customer's terminology, about three sentences.
3) feature: Feature
This is one of the core practices of feature-driven development (FDD) methodology. A feature is a small, customer-valuable function, usually expressed as <action> <result> <Object>.
From the above definition, the three modern software engineering requirements must follow two principles without exception: first, from the perspective of the user, the system and the definition system; second, it is expressed in a language that users can understand. In my practice, in view of the following two considerations, we should first apply the "Case Analysis Technology" to the team ":
1) The user story is a little rough and requires experience. There are no detailed rules for step-by-step operations. At the beginning, it is easy to get lost. The use cases are more formal and easy to get started;
2) features seem attractive, but after all, the relevant theories are incomplete, and it is difficult to introduce team practices.
Iii. Introduction to Case Analysis Technology
The case analysis technology is a demand analysis technology that originated from practice, which was summarized and published in 1967 when Mr. Ivar jacson, one of the three rational users, developed the axe switch at Ericsson in 1986. After joining rational, Mr. Ivar proposed UML in cooperation with Sanyou and improved the RUP. As a result, the use case analysis technology has been widely known and concerned.
The case analysis technology provides a basic element for software requirement normalization, which is verifiable and measurable. Use Cases can be used as the basis for project planning, progress control, and testing. In addition, use cases can make the communication between the development team and the customer smoother.
Many people are exposed to use case when learning UML, so many people misunderstand it as a chart and regard the use case diagram as the whole of case analysis. In fact, this is wrong, case description is the core of case analysis technology. The following is a simple example:

3.1 participants, actor
A participant defines the role a user plays during system interaction. It can be a person or another related system.
3.2 use case
Use Case instances (scenarios) are a series of actions performed in the system. These actions generate value results visible to specific participants. A Use Case defines a group of use case instances (scenarios ).
A use case should provide (implement) a value to the participants.

3.3 event stream
Just as a class corresponds to an object, an instance of a use case is a use case. The use case is an abstract Summary of the use case:
1) preconditions: it refers to the status in which the participant (actor) and system should be placed when the case is started. This status should be observed by the system;
2) Post condition: the state in which the system should be placed at the end of the case. This State should also be observed by the system;
3) Basic event stream: the basic event stream describes the regular and expected paths in the use case, also known as the happy day scenario, which is encountered most of the time; it will reflect the core value of the system;
4) extended event stream: Describes exceptions and branches.
We recommend that you pay attention to the following points when writing event streams:
1) use simple Syntax: the subject is clear, and the meaning is easy to understand;
2) clearly write "who controls the ball": that is, in the event stream description, let the reader intuitively understand whether the participant is controlling or the system is controlling;
3) write the code from the perspective of looking down: point out the actions of the participants and the system response, that is, the third party;
4) display process goes forward: that is, the first step has a forward feeling (for example, it is inappropriate for the user to press the tab key as an event );
5) display the intent of the participant rather than the action (actions alone make it difficult for people to understand the use case directly from the event stream );
6) include "reasonable activity set" (requests with data, system confirmation, internal change, and returned results );
7) use "Confirm" instead of "check": (if the system confirms that the user password is correct, rather than the system checks whether the user password is correct );
8) Time restrictions can be selectively mentioned;
9) use the term "user interaction between system A and system B;
10) use the idioms "Perform steps X to Y cyclically until the conditions are met.
Iv. Case Analysis Technology in Alistair Cockburn eyes
When using case analysis technology, many people think that it is difficult to determine the granularity of the case, and feel that the case has no rules to follow, or even has a sense of failure. As Mr. Cockburn proposed, the Learning case analysis technology has three stages:
1) stick to: Practice basic kung fu, follow the rules, and follow the rules;
2) breakthrough: it can break through the tradition and be flexibly applied according to local conditions; 3) Break away from any moves and rules to reach the realm of no action or no action.
However, the use case analysis technology cannot be quickly mastered by beginners in the first stage. However, in its Book "writing effective use cases", we want to add rules for the use case analysis technology, so that everyone can better master it.
Based on Ivar jacbson, Mr. Cockburn made some supplements:
1) A use case is a contract between the system and the stakeholders. That is to say, the use cases are developed in the formal direction;
2) divide the use case into three levels:
◆ Summary level: includes multiple user targets (displays the context of user targets, shows the lifecycles of related targets, and provides a directory table for low-level use cases );
◆ User target level
◆ Sub-function level
However, for Mr. Cockburn's contribution, Master Ivar, the original of the use case, did not make any response. In practice, I believe that Mr. Cockburn's ideas and ideas are of great value for beginners of case analysis technology, making the case analysis technology more operational, at the same time, Mr. Cockburn is also aware of this, so the third stage is "off", with no rules and flexible use on demand.
V. How to Apply Case Analysis Technology During Development
The status of case analysis technology in the demand process is shown in:

The two biggest mistakes in case analysis technology are:
1) case analysis technology includes the entire demand process: it is only a requirement analysis technology and is used on the basis of the traditional requirement capture technology, and cannot replace these technologies;
2) Case Analysis Technology is a decomposition technology: in fact, case analysis technology is a synthesis technology that combines the scattered features collected in requirement capture into use cases:
 

5.1 work before Case Analysis
Before using case analysis, do the following:
1) determine the stakeholder and user type (naming, brief description, stakeholder representatives, features, and capabilities );
2) determine the stakeholders (name, brief description, responsibility, and participation );
3) add stakeholder representatives (interview, questionnaire, Consultant, review, and role play) to the project );
4) create a common concept (problem definition, system scope, user objectives, and non-functional requirements à foreground document );
5) use traditional requirement capture technology to capture requirements;
6) Build A Case Analysis Team (with a small amount of problematic domain knowledge ).
5.2 precautions during Case Analysis
The process of case analysis is shown in:
 

Note:
1) Use Cases are sourced from the stakeholders. Do not write your own use cases;
2) The team should be fully involved in the preparation of case event streams;
3) Although the use cases originate from the stakeholders, do not attempt to ask them directly, "What use cases do you have? This is a problem.