The requirements document is a common communication method and medium in development. It carries the expectations of the demand side and marks the life cycle of a series of events.
Demand documents of different departments and audiences are different, such as activity requirements proposed by operation personnel to product personnel, functional requirements proposed by product personnel to developers, service support requirements proposed by developers to operation and maintenance personnel, and requirements proposed by colleagues within each team.
Why do I need a requirements document?
In most scenarios, there is a large information difference between the demand proposer and the demand undertaker. The demand proposer often uses statements such as “I need to do this”, “the sooner the better”, “you don’t care how to use it, just give it to me”, “this is not what I want”, and “what I want is actually that”.
There is a phenomenon where one often negates one’s choices and words, whether intentionally or unintentionally, but it undoubtedly takes time and energy on both sides. The requirements document can not only serve as a list in the communication process, but also as a log of the selection and execution of both parties. With the requirements document, the problem of empty space caused by inconsistency can be avoided. At the same time, the demand document can clearly reflect the labor achievements and labor value of participants, which is a good basis for self-summary.
Requirements document Common template reference
There are a thousand ways of describing a hundred needs, but the items in the requirements are the same. Here is a template of requirements documents that you can use at work as a communication medium between different people.
It is important to note that requirements and execution go hand in hand, so the following reference document here is more of a task execution record than a requirements document, as it records the complete life cycle of the task from generation to completion.
For your convenience, the document uses different colors to help us distinguish the stages, where:
🔲 The light pink blocks present the basic information of the document;
🔲 the light blue block shows the requirements subject and the requirements life cycle subject;
🔲 the light green block shows the end of the requirements life cycle and is about to achieve the goal;
Why do they do that?
I’m sure you’ve seen quite a few requirements documents, so you might have a different view of the above reference, and you might ask:
- Why is it designed like this?
- Why not use an online requirements document management tool?
- How to reflect mandatory and non-mandatory items?
- Does this reference not cover all development scenarios?
Why is it designed like this?
Requirements document shall cover from the demand to demand delivery of the entire process, such as the demand is in what kind of scenario, what to do, when to finish, in the form of what demand delivery, whether can realize are doing, requirements, implementation process, delivery, whether the result of the desired, etc. * *. 支那
We can break the whole process down into the following stages to make it work better:
🔲 Requirement Description
🔲 Demand research
🔲 Requirements Review
🔲 Development/implementation
🔲 Stage acceptance
🔲 Test/data validation
🔲 online
With this structure, we can imagine the workflow as follows:
First of all, the demand proposer provides the background of the demand, the description of specific items and other information to help the demand receiver to better understand, and at the same time puts forward the expectation of delivery time and delivery method. After receiving the demand information, the demand receiver needs to do a preliminary survey to understand the key items in the process of demand realization and record unclear matters.
Then, after initial contact, the two parties will set a time to review the requirements. The discussion between the two parties will be carried out based on the information obtained during the research. After the review discussion, whether the requirements can be realized, the requirements change items, the delivery method, the delivery time and the final participants will be determined.
The review is then approved and the requirements recipient begins development/implementation. The requirements taker records who did what, when, what results, and whether any changes occurred during the process.
The demand-proposing party may follow up the progress of the event periodically, and help the demand-receiving party to confirm that there is no deviation in the work and work results, and the two parties may exchange some information.
When the development/implementation is nearing the end or completion, the demander shall organize personnel to inspect the results. If the results pass the inspection, the demander shall be notified to deliver/release the results online. If the results fail to pass the inspection, corresponding adjustments shall be made.
Copyright watermarking – wechat public number Python programming reference
In addition to requirements background, development/implementation related information, the requirements document itself also needs to provide some basic attributes for sorting, classification, traceability and summary of requirements, so some important information bars are set at the beginning of the requirements document, such as:
🔲 Requirement importance level;
🔲 request initiation date;
🔲 Requirements end date;
🔲 Demand sponsors and corresponding departments;
🔲 Demand acceptor and corresponding department;
🔲 Service type of the requirement.
🔲 demand keywords;
🔲 also seek the name of the business;
🔲 demand follower;
🔲 Demand Number;
🔲 requirement name;
Can be defined within the team uniform level of demand, such as urgent and important to A, urgent but not important to B1, important but not urgent to B2, important or urgent to C, etc., so everyone at the time of participation requirements to reasonably allocate time and resources to give priority to solve those high level requirements.
Why not use an online requirements document management tool?
There are a variety of requirements document management tools on the market. Python programming Reference wants to introduce requirements documents without relying on specific tools. You will be more efficient when you understand requirements documents and then combine them with the management tools you use in your work.
In fact, there are all kinds of management tools in our work all the time. Tools can help us to correlate documents and aggregate information. For example, after the completion of a TK2020120101 requirement, the maintenance requirement TK2021010103 can be associated with TK2020120101. In this way, relationships and changes between requirements can be visually seen when managing requirements documents, as shown in the figure below.
Management tools are very likely to be used in the actual work. Tools can improve our efficiency and facilitate us to manage events. Using tools is a very good choice
How to reflect mandatory and non-mandatory items?
The document actually contains blocks of essential information, but the subitems in the blocks can be omitted as necessary.
First of all, the basic information section of the requirements document in the light pink block is mandatory. The content here is a microcosm of the overall requirements, so no space is missing.
Secondly, the main part of the light blue block can be omitted. For example, sometimes demand survey and demand review can be launched at the same time, which can be divided into demand review. For example, items such as notes and delivery requirements in the detailed description of sub-items can also be omitted according to the actual situation. If the requirements are not complex, or the time cycle is not long, then the sub-item acceptance can be omitted, and the verification can be done in the data verification stage. If there is no pre-live, or if the requirement does not need to be live, the items in the light green block can be omitted.
Finally, if you feel that the above phases are not sufficient to document the complete requirements life cycle, you can add phases or subitems as required;
Does this reference not cover all development scenarios?
Of course, there are thousands of development scenarios. The Requirements document provided by the Python programming Reference is the basis for your specific use. You can adjust the document items according to the team situation and business situation.
Requirements document example reference
Although a basic template is provided above, some readers may not understand how to write it in practice. The following is an example reference to the actual work requirements.
After reading and absorbing the above knowledge, you should be smart enough to have a good understanding of the structure, design considerations, and specific practices of the requirements document. Now you can organize the requirements document well. Here the authors help you sort out some of the details of the requirements document.
What does demand research study?
Demand research is based on the actual situation of demand exploration, the main appeal is to draw a definite conclusion whether or not; As mentioned in the reference example:
🔲 Whether the current Nginx configuration file needs to be modified;
🔲 whether the caller should switch the calling address after the new Nginx is replaced;
🔲 online service address permissions can be successfully obtained;
What does the requirements review discuss?
Demand review is carried out based on research results and demand background. The main appeal is to draw definite conclusions about the implementation mode, results and presentation mode, and give results for those unstable matters, including whether or not to draw definite conclusions, such as:
🔲 Review items: Check whether monitoring items match visual panels
🔲 Review result: The monitoring items match the visual panel, but the panel needs to be set separately to set the alarm, which does not affect the display;
What is the development implementation record?
There is no need to document details in development/implementation items, only phases. Usually who did what, and at what time, in the format of [time][person][event], as recorded in the reference example:
🔲 [2020-12-01][Data collection][Zhang SAN] – Provide Nginx configuration files;
🔲 [2020-12-05][O&M][Wang Wu] – Import Prometheus data source and configure visual panel in Grafana;
🔲 [2020-12-07][Operations][Wang Wu] – change domain name resolution;
Phase acceptance write what?
Phase acceptance focuses on event outcomes, in the form of [time][people][results], similar to development/implementation records, such as those recorded in the reference example:
🔲 [2020-12-08][Data acquisition][Zhang SAN] – Everything is normal after service switchover;
🔲 [2020-12-06][Data acquisition][Zhang SAN] – Grafna visualization panel data;
🔲 [2020-12-03] – Nginx logs have been synchronized to ElasticSearch;
What do live items focus on?
The on-line item is concerned with the on-line result and the state of the business itself, and is in the format of **[time][person][state], ** as recorded in the reference example:
🔲 [2020-12-09][Operation and Maintenance][Wang Wu] – normal service;
🔲 [2020-12-09][Data collection][Zhang SAN] – Normal data;
🔲 [2020-12-09][Test][Li Si] – normal data;
The state here can also be understood as the result, but if you think about it more closely, the state is more appropriate.
This is the wechat official account Python programming reference. If you find this article helpful, please follow me. Go to wei Shidong’s technology column at www.weishidong.com for more useful information. Top articles at a glance:
How to Effectively Cope with the 35-year-old Crisis
A Practical Guide to Drawing and Design for Engineers
Continuous Delivery Practices – GitHub Actions Deploying Node applications to cloud Servers
Practices for Logging In to the Cloud Server Without Password, Username, or IP Address over SSH
ElasticSearch Delete Data on specified days