Organize requirements through Use Cases

[Sina Vivi] [poco network Abstract] [365key] [bo cai] [Yi You Xiang] [you abstract] [younote] [Tianji network Abstract] [Hexun network Abstract]

Organize requirements through Use Cases
First, the most important thing is that we must have a vision: a company's vision is a milestone strategic goal (Microsoft: Let every desktop have a computer). Similarly, the vision of developing a software system is also its strategic goal. When identifying the vision, you can ask three questions:
1. Why should we develop this system?
2. Who pays for the system?
3. How can I feel the value?
These questions should not only be raised to themselves, but also to customers in various ways to verify the value of the software they expect. This does not mean what customers say. What they say is often different from what they want in their subconscious. For example, people who want to make information electronic may want fast query and reliable storage. Therefore, do not blind the false vision. Note that the true vision goal must be measurable (otherwise, how can we determine whether this goal has been achieved ?)
After the vision is established, we can start to identify and organize the needs. Use Cases are an effective means of expressing requirements. They help or even force us to think about problems from the user's perspective, so that the needs truly reflect the value to users. The use case itself provides a formal expression specification, which reflects the organizational level of the requirement:
In this form, all requirements are organized around use cases. In this form, all requirements are organized around use cases.

The following steps can be taken to organize requirements using use cases:
1. recognition executor: the Key to this step is to confirm the "boundary"-the executor must be out of the boundary, and the boundary is divided from responsibility, not physically; another point to note is to avoid the "Unwilling" mentality-because the executors interact directly with the system, they are often some migrant workers or agents, such as bank employees, direct customers or bosses are not Executors (note the difference between them and business modeling). This is a normal phenomenon.
2. identify use cases: the Key to this step is "value", which has been repeatedly emphasized. It can be extracted as a use case only when a complete value action is provided for the performer, this value must be provided by the software system, not just what the user requires. The common mistake in identifying use cases is to consider the operation steps as use cases, especially the "add, delete, modify, and query" operations as use cases. In fact, these crud operations are likely to be insufficient to form use cases (not to provide value to executors). Even if they can form use cases, it is sufficient to use a "manage ××" Use Case.
3. Write the case document: the case document is not equal to the use case diagram, And the use case diagram is only the overall organizational structure. A standard use case document should contain the following:
When describing a case, you must consider the interests of the stakeholders and balance the interests of the stakeholders. Classic definition: "Cockburn: A use case is a contract concluded between the stakeholders and interpreted as an operator to achieve a specific goal and interact with the system." -- this sentence is really amazing!
"4. Sort use cases through relationships: pay special attention not to abuse the relationship between use cases. The simpler it is, the better it can be understood.
5. sort and subcontract Use Cases: Sort use cases to determine the order of future iterative development.