Software System Requirement Specification (zt)

Software Engineering clearly defines the most Software Requirement Specification task. It is a bond between customers and programmers and a detailed description of what the system is going to do. Therefore, this document must contain a lot of content. In the last few days, I have been reading a very strange demand specification and design specification. In these two documents, not only does the system flow Description exist, but there is no concept definition. The requirement specification first writes the relationship between the system and other systems, then the system menu, then the menu content, and finally the table structure, I haven't figured out a few of the entities corresponding to the software. In the Design Manual, first write the system purpose and cause, then write the defined data and functional interface design, and what tables I connect to the design are defined by other systems, you do not know which data is generated by yourself and how the data is related. I have a headache reading these two files to design the program code!

The following is my experience in analyzing and designing management software systems based on my previous experiences. I hope to help you.

A requirement statement must contain the following:

1. The background information, purpose and reference index created by the system, and the reference documents attached to the system must be included. This part of the information seems to have no direct relationship with software development, but it is as much as we must have a plate to eat. It first tells the reader what the manual is based on.

2. A brief introduction to the system is required. For a brief introduction, it is best to describe images or up to 200 words. Just like the keyword in the article, a brief introduction of the system allows people to quickly grasp the key content of the system and give readers a concept. This is just like the name/Description of a dish, which is simple and easy to understand.

3. What is the scope of the system, what is the main task, and what is the relationship with existing or known systems being built? There are two ways to describe the relationship: one is to describe the system in which the operator is doing the business operation, and the other is doing the same thing. There is another clue: From the Perspective of program development, what a system provides to another system, what the content is, or how the system communicates. Based on the reader's existing consensus and knowledge system.

4. The plan or developer arrangement must be included. This content is critical. Also very subtle. Because developers have strong abilities, some functions can be done, some are weak, and some are not required. I have done some systems and have also written requirement manuals. Many times, changes to developers often affect system planning and quality. Therefore, the developer's configuration must be obtained in advance. Generally, this information is not available at the beginning of the requirement statement. Only after the requirement is basically determined can the development team plan a person to work out a pre-arrangement based on the function scope, according to this manpower arrangement and schedule, the system development scope and extent are determined. This part of content, if placed in the outline design, is somewhat late. Because the demand should not be just what the user wants to do. In many cases, the demand goal should be determined based on multiple factors. If we put it on the outline design, it will make a system say what is done, but in fact it is divided into several stages to achieve, or the requirements are all discussed to achieve this, the development staff will not do the result, you have to change the target or even process. Therefore, in writing the requirement specification, developers must confirm and pre-arrange the requirements based on the basic definition of the requirement framework. The pre-arranged results should be written in the document as a reference.

5. The description of the business/operation process must be included. Can use the E-R diagram, Write clear all involve what department, how to operate each role/entity. You can also use a business flow chart or a table or text description. But it must be clearly stated. In addition, it is the main part of requirement analysis, especially a new system. This part may be changed frequently! This is my experience in analyzing and designing 10 management information systems (including several large management software. The changes to this part of content are terrible, especially when a new system is created. Each department decides to do so first, and the discussion will lead to a problem, and another idea will be made. The establishment of a management information system will lead to business process restructuring, business relationship changes, individual operations simplified, and functional restructuring, which directly lead to the establishment of a new process. Therefore, if you want to make the system better, you must not elaborate on this part of the content, but make it clearer. At the same time, we also need to endure the need to constantly overwrite and modify data during discussions with users and group analysis. We must be able to withstand all kinds of scrutiny.

6. concepts must be included. Do not underestimate the concept definition. It is a key problem to solve communication barriers, just like the plain text. If you are too lazy to give a noun explanation, you will pay for it. The cost is that many questions may be raised, and several seminars will be held to extend the implementation time of the entire software project. Even if a program is developed, a function is not required by the user. The definition must be accurate, rigorous, and repeated, so as to avoid ambiguity and be understood by users and developers at the same time. It is best to locate the reader with a primary school culture.

7. The description of the system data stream must be included. This part of content looks like a Summary of the design. In fact, in the demand report, we should not simply describe what lists and what lists are there. It must be clear who generates the information, what is in the information, how it passes, and where it is. At the same time, if the process is reorganized, do not describe the old process and start with the new process. This part not only allows readers to understand the detailed system requirements, but also provides the requirement report writers with a way of organizing their ideas. It can make the demand analysis more accurate and rigorous, avoid errors, omissions, or avoid unclear key points.

8. A description of the interface or other requirements must be included. For example, data precision, UI color, and layout style. Many people try to do this part in the outline design. In fact, sometimes, in the demand report, they also need to reflect the user's requirements. Nowadays, many users already have strong computer understanding and usage capabilities. They sometimes take the initiative to tell you what he wants, what is below, what is left, and what is right, where is it. This is very valuable information. Collection and user confirmation can reduce a lot of resistance during system promotion.

9. The future thinking of the system must be included. This part of content is mainly used as a requirement investigator. After requirement analysis, I think the system is doing this now, What are the limitations or shortcomings, and what can be developed in the future. This part of writing provides a valuable reference for system summary designers to define the system lifecycle and design data structures. Therefore, if you have the ability, you must let yourself play the role. Do not forget to write it.

 

Several Problems and misunderstandings that need to be paid attention to during the writing of the Requirement Specification:

1. Do not be afraid of writing too much. Make sure to establish a reasonable directory structure so that people can read according to their concerns. Do not be afraid of length, but the statement must be accurate and refined. Sometimes, the reader may not have to read the entire file for the first time. First, he has a concept, and then carefully checks and finds some parts. The more detailed the requirement statement is, the more accurate it is.

2. There must be no ambiguity. In the requirement specification, ambiguous statements may have disastrous consequences! Therefore, as a writer, we must avoid ambiguity as much as possible. At the same time, when reviewing and reviewing the demand report, we should also take the ambiguity as the key goal for elimination.

3. Define readers before writing a report. This work can be written in the requirement manual so that every reader can know it, or the development team can confirm it internally. Because the actual situation is different, the requirement specification may not be read to users, users and developers, or users, developers and some special departments. Different readers may influence the content and writing angle of our manual. Look at the mobile phone manual, if it is for the user, a way of writing, if it is for the maintenance staff, a way of writing, if it is for the testing staff, it must be another way of writing, so, before writing the requirement manual, check the reader scope.

4. You must keep a writing record while writing the requirement statement. This work seems nothing. In fact, it can help you clean up your ideas, even guide the demand analysts, ask what, find who, and make the system plan reasonable. My record content is a table, from when to when, what has been done, who is the participant, and content Introduction. For example, I first wrote a System Framework Based on my personal experience and used it as the first draft. After obtaining some electronic documents, I will add a line in the writing record, and at what time, who will get the electronic materials, what is, and in which directory. Then, according to this electronic material, I wrote a change file, defined as the second draft. I also wrote the time and wrote the second draft, the main difference from the first draft is what content is added/modified. I personally think this document is very useful for analyzing a large management system, and the owner and project progress are clear.

5. Before discussing the meeting and confirming the process, you must write the plan and execution results. Which of the following questions are answered. This document makes the requirement statement more rigorous and error-prone, and avoids some misunderstanding and repeated discussions. You can also make plans based on the results.

6. Personal positioning should be low-key. To do demand research and report writing, we must write in the spirit of materialism, objectivity, and calm. At the same time, we have to pay for it. We are not tired of making repeated changes. We have always been patient, meticulous, and earnest. This attitude determines how high the specification availability is.