3.2. Demand Capture Process N View original text
The third chapter on the previous page. Demand capture the next page
3.2. Demand capture process
At the beginning, we must first look at the problems we have to solve and consider the key features that should be in any solution. This is our explanation document, there may be a few pages long. For example, the ATM system (ATM) should provide the following features. 1. Customer access and account query. 2. Accept bank engineers' maintenance of equipment and management of local bank branches on their internal cash and deposits. 3. Audit all activities sent to the banking host. From this perspective we analyze the basic activities of the system and system external elements (people, equipment) involving these activities. These activities are called the use case, and the external elements are called participants. Participants may be people or machines. From a point of view, you should find those people behind the machine, because only they will pay attention to demand capture. Use cases should reflect the main activities of the system. For example, the user uses ATM is a use case and the user enters personal information code (PIN) is not. Sometimes there is some difficulties, so we see that the large use case is divided into small sub-cases is useful. For example, we may have several use cases of deposits, withdrawals and account queries. There is no strict and fast rules. Some system architects like to use a small amount of large-scale use cases associated with each other; others like to use a large number of small use cases. A useful rule for any particular item is that the number of types should not exceed 30 (if more use case is required, then the project should be opened). Next we want to display the relationship between the use case and the participant on one or more cases. For a large project, there may be more than one use case. A set of uses that have a relationship with each other are displayed on a picture. We must give a detailed description for each use case. These instructions include normal behavior, optional behavior, and post constraints and post constraints. All of this is included in a document called a use example or with an example policy. 3.2.1 Process Step Demand Capture Process The steps can be summarized as follows: 1. Describe the profile of the problem in the documentation, describe the features of its solutions. 2. Find out use cases and participants and display the relationship between them in the case. 3. Detailed description of the use cases, including normal behavior, optional behavior, front constraints, and post constraints. 4. Describe all non-functional needs in a demand supplement specification. During progressive development, we will select the order of processing cases based on the importance of the use case. Early processes focus on capturing key behaviors of important use cases. Most of the modern theories about demand capture agree that what is important in the demand capture process.
Previous Chapter 3. Requirements Capture Return to this section directory Return to the user manual directory Next page 3.3. Demand capture process results
