Five traps in Software Requirement Analysis

Use case has become a widely used development technology. Focusing on users and their goals, rather than product functions, this greatly improves the possibility of developing software products that truly meet customer needs. However, since we know little about the use cases, the mystery of the use cases is increasing, and many development teams are trying to use the use case technology successfully. This article will focus on analysts who have started to use case technology, and specifically point out the five Use Case application traps to be avoided.

Trap 1: Use Cases that even users do not understand

Use Cases are a way to express user needs. They describe the specific functions that the user needs to accomplish by the product. Use Cases should focus on the tasks that users need to complete through the product system, so the use cases are closely related to the user's business process. Use Cases should allow users to easily read and check for possible problems, such as missed alternative processes or incorrect exception handling. If you cannot participate in the use case, there will be many problems. It may be because these use cases focus too much on technology, rather than business and forward-looking.

Trap 2: Too Many Use Cases

Analysts are busy creating dozens or hundreds of use cases, and they are not aware that this may be wrong. Too many use cases usually mean that the Abstraction Level of the use case is too low. Each use case should be abstract to cover multiple related scenarios with a common topic. The parts of these cases will be successful, while others will not succeed in some special cases. If you are in such a case explosion, try to improve the Abstraction Level, combine similar cases into groups, and use them as a single, more abstract branch process of the case.

Trap 3: Overly Complex Use Cases

The general idea of case application is that a normal case process should contain no more than 12 steps. In fact, the useful examples include nearly 50 steps in a normal process. The problem is that the so-called "normal process" also contains many possible branches, including incorrect abnormal flows and how to deal with them. Therefore, in fact, a normal process also includes alternative processes and exceptions. A better way is to select a simple path that can successfully complete the entire use case process by default. This is the real normal process. Write Other branch process cases to include other branches and exceptions of the process, especially the case cases that describe the process errors. In this way, we provide a set of Use Case packages that contain multiple small branch flows. Compared with a large use case that provides users with an attempt to process each possibility in a single process description, it will undoubtedly be much easier to understand and manage.

Trap 4: Use Cases that describe specific user interface elements and Behaviors

What we need is to write "necessary" Use Cases to describe the interaction between users and the system at an abstract level, rather than adding the details of the user interface. The use case description should not include the interface design, although a simple user interface prototype is helpful to conveniently check the use case. I do not even like to hear the terms that are implicitly controlled by a specific user interface in the use case. Let's say "Click OK", which means that the GUI uses the mouse and button. But can I still use a touch screen or a speech recognition interface? Adding immature design limitations to use cases may lead to a poor design, unless you prefer existing applications on existing interfaces.ProgramAdding new features.

Trap 5: no longer use other demand Models

After using the use case method, analysts seem to have forgotten other demand models and acquisition methods they know. For interactive systems and websites, use cases are quite helpful for capturing user needs. However, the use case method is not suitable for event-driven real-time systems, data warehouses, or batch processing.

we should avoid the temptation to use case methods to impose use case methods on all functional requirements. We can use a detailed list of functional requirements, non-functional requirements, graphic analysis models, prototypes, data dictionaries, and other required information to supplement the use case description. In many cases, use cases are useful, but add them to your demand analysis toolbox instead of replacing all your current tools.