Requirements survey steps and methods

Chapter 2 Preface 
Purpose

Demand research is to do the preliminary work for the manual. It can be said that the Manual is obtained or extracted from the requirement survey table.

Demand research is to understand what kind of procedures are really needed by people who do practical work in the real world, and then organize the requirements into details for development by the design department, and then sell them to users by the Sales Department.

User: System Analyst

2ndChapterPreparations

2.1. Confirm the tool

There are no good or bad tools, and the key is how to use them. No matter what tool is, it is just a helper tool, not a generate tool.
You must select a tool that you are familiar with (in this group). Instead of the latest and fashionable tool, you have little knowledge about it, and most of the results are made on learning tools, instead of using it to work for you.
Tools are also recommended to be common, because communication needs to be considered.

2.2. What to do first

If the project is an industry (professional) group you do not know, it is best to have an expert. The end user is the best expert. At least you know this major, you don't want to be an expert, but you need to know at least a certain degree of professional knowledge (you need to know at least a specialized vocabulary). Otherwise, you don't even know what to ask or how to ask them, you don't even know what people are talking about.
The corresponding professional materials are required. At least professional introductory books and materials are required, and more in-depth information is required. Of course, the input of experts is another matter.
If the industry is not very difficult, you can access the Analyst's self-learning to learn about the industry in a short time, maybe you don't need experts, otherwise experts are required.

2.3. Establish a design environment
A special design environment must be set up to serve this project, allocate certain resources, and perform necessary file management.

2.4. truly understand yourself and your users

Those are what the user may be clear about
You must know what you can do and what you cannot do.
Handling Methods that cannot be implemented, such as rejection and packet forwarding
What the user wants to do

2.5. List the personnel assignment table and all tools

Clarify Project Personnel Division
Unify the tools used by the Project
Unified project file template
List of other resources (materials, related websites, enquiry phone number ...)

3rdChapterSurvey process

3.1. Collect requirements and obtain the requirement statement

Note:
Although it is ultimately necessary to compile a description of a computer-based solution, so far, the focus of our documents is on the relevant areas.
Remember that there is no computer talk here. If you are writing an accounting software, an accountant should understand the accounting statement written by the programmer clearly.
The requirement statement should not be too formal. You just need to describe what you want to do, just like talking to someone else.
You must take notes when you are familiar with the customer or related personnel. You may not be able to remember many details during the last few hours.

3.2. Sort out, check and refine the requirement statement

Organize and classify customer needs
There will be a lot of information from the user, and no reasonable analysis can be carried out if necessary.
Distinguish between useful functions, optional functions, useless and unfeasible Functions
For the user, he can say that he wants many functions, but the relationship between these functions is sometimes clear, however, many users want to use computers or new systems to implement functions that they did not previously have. At this time, the feasibility of the new requirements and the relationship with other modules are unclear, therefore, analysts need to distinguish between useful and optional functions from user needs. For example, if the functions are not implemented, they should give up.
Do not ignore obvious errors
The user does not often mention what he needs, and these things are very basic for the problem. You must pay attention to this issue in detail.
What you think may not be right
System analysts should pay attention to the situations they think of as demand analysis. For an industry, some rules may not be the most reasonable, but they exist and use such rules, therefore, professionals should examine and approve each non-clearly defined requirement. Unless you are an expert.

3.3. Improvement
In the first analysis of the demand, there must be some unclear and uncertain details. In this case, we will sort out a detailed inquiry table to sort out the problems found and list the unclear points, the following formats can be used as root partitions:
Inquired:
Problem:
List of unclear business issues (unclear business description ):
1 .... What does it mean?
2 ..... What is the relationship with xx?

Multiple options can be listed (Please select ):
1 ...... There are multiple possibilities, so now we use
A ...... B ....... C ........ D ......

Submit the inquiry form to the user and analyze the requirement based on the feedback. This step can be repeated multiple times to finally understand the requirement and determine the requirement statement.

3.4. Review requirements

Self-Audit
Consider yourself from the user's perspective
Is it reasonable, whether it can improve efficiency, whether it can achieve the goal, and whether it is complete?
Evaluated by users
The end user will evaluate whether the requirements listed in you meet the user requirements (the number of users is 1-3, and there is no benefit if there are more users ).
Repeat the process to complete the requirement statement