How to let customers write high-quality demand documents
Source: Shangpin China |
Type: website encyclopedia |
Date: March 22, 2012
Beijing website construction Shangpin China: It is very common in the field of embedded development to write requirements documents. Requirements documents are used to define development tasks and coordinate large-scale R&D plans. For the final product, the requirements document acts as a link between developer behavior and consumer behavior. When the requirements document is written correctly, it can play a huge role. However, if you work long enough in the field of embedded development, you will soon find that there are too many unqualified requirements documents in this field. When you try to repair these unqualified documents, you will soon find that it is not easy to write correct requirements documents. Here, we put forward some suggestions to make it clearer to write correct requirements documents.
From a higher level, the purpose of writing requirements documents is to provide an effective description of the required behavior. This required behavior can be described by a black box system, and the following details should be noted:
• The engineer can implement according to the system.
• Testers can use equipment that meets hardware requirements to verify requirements without communicating with developers.
• The final results meet the requirements of end users.
Black box testing writes high-quality requirements documents:
The basic principle is that the requirements document should be as concise as possible, and use the most understandable description to constrain the expected behavior of the system. If you follow this principle, the remaining important factors (testability, avoiding over design, etc.) will become logical.
It is usually more helpful to list more detailed rules. Here are the steps to follow in writing a quality requirements document:
1. Define the boundary of the system. This is also necessary for black box systems.
2. Define inputs and outputs. This should also be the only way you look at internal systems.
3. Describe the expected behavior of the system in the most understandable way.
4. Do your requirements involve other parts of the system besides input and output? If so, your requirements are over designed. Reconstruct the requirement and make it concise.
5. Are your needs too ambiguous? Add more qualifying specifications. Note: It is not a bad thing to have some ambiguous descriptions. If all the situations contained in the description are acceptable and no additional information is needed to explain during the test, then it is OK. You don't need (and shouldn't) limit the behavior of the system too much.
6. Are your requirements testable? (This means black box test) If not, you'd better go back to step 4. If this rework happens many times, it means that your black box cannot describe the system correctly, or your testing tools are not good enough. In either case, untested requirements documents are almost worthless.
7. Is your requirement document easy to understand? If your requirements document is very difficult to read, it means that you are not good at writing, which can only bring endless pain to those who are responsible for implementing your requirements. If so, go back to step 3.
8. Did you really achieve step 4? Are you sure? Check again.
Example: In the following example, let's describe the requirements of a self-made embedded device that can read the bending frequency from the bending sensor and make an LED flash according to different frequency values.
Obviously, we have completed steps 2 and 3!
• Input: read data from the bending sensor.
• Output: LED.
But we skipped step 1:
• In this example, we will draw the black box onto the microprocessor of the device.
Let's move on,
Step 4: In addition to input and output, do we also involve other system boundaries?
• The microprocessor does not care what data is read from the bending sensor. From the perspective of the processor, all it needs to do is measure the voltage of the ADC pin.
• LED is controlled by digital output pin only.
Next, let's fix this problem:
Requirements for Version 0:
1. The device shall switch the status of digital output terminal according to the voltage of different frequencies of ADC pin.
Step 5: Are requirements ambiguous?
Well, our description is too ambiguous. How fast is the output switching speed? What is the relationship with voltage? What is the input voltage range? Let's add some more details:
Version 0.1
1. The output shall be controlled by a free timer
2. The maximum frequency of free running timer shall not be higher than 10 times per second and not lower than 1 time per second.
3. The trigger frequency of the free running timer shall vary linearly between the highest and lowest values, and be proportional to the input voltage at the ADC terminal.
4. The input voltage of ADC terminal should be read once every 100 milliseconds
5. When the input voltage terminal of ADC terminal is read in, the registration value controlling the cycle time of free running timer shall also be updated.
6. The effective voltage range of ADC input terminal shall be controlled between 0 and 1 V.
Step 6: Are your needs easy to understand?
Compared with our original description of "controlling LED flicker according to the output frequency of the bending sensor", the above description of requirements seems difficult to read and understand.
I found that the easiest way to make the requirements document easy to understand is to extract the details and define them separately in the form of items.
Step 7: Are your requirements testable?
• First of all, there is no need to mention the free running timer here. Because it is basically impossible to perform black box testing, it is neither input nor output, and has nothing to do with the two.
Let's replace the test standard of free running timer with "the frequency of digital output changes should be controlled between 10 times per second and 1 time per second".
• For the fourth requirement above, some minor modifications may be required to be used as the test standard. Let's use "the input voltage at the ADC terminal should be read at least once every 100 milliseconds" to describe it. This description can make our expected test behavior more understandable.
• Article 5 of the requirements also needs some minor modifications. How can we detect that the voltage output range is between 0 and 1 volt? Can't give a voltage of 2 volts, and then see if the components have been burned?
It is easier to check if the system works normally when the input voltage of ADC terminal is between 1 and 2 volts. The requirement description should be "positive" and should describe the behavior of the equipment "should" rather than the behavior of the equipment "should not". Otherwise, the test will fail.
Version 0.2
1. The switching frequency of the digital output terminal should be controlled between 10 times per second and 1 time per second
2. The switching frequency of the digital output terminal shall vary linearly between the maximum and minimum values, and be proportional to the input voltage of the ADC terminal
3. The input voltage of ADC terminal shall be read at least once every 100 milliseconds
4. Check whether the system works normally when the input voltage of ADC terminal is between 0 and 1 V
Version 1
1. The bending sensor shall ensure that the data can be read at least once within 100 milliseconds (listed separately in the note)
2. Switch the status of LED to make it consistent with the reading of bending sensor
3. When the reading of the bending sensor is 1 volt, the number of LED state switches should be kept at an average of ten times per second; When the sensor reads 0 volts, the number of LED switches should be maintained at 1 time per second.
definition:
• Bending sensor: the input voltage is located at the X end of ADC. The safe voltage range is 0 to 1 volt (listed separately in the note)
• LED status: digital status is output from Y end
This is much better (although not perfect). These requirements are easy to understand, do not involve the internal implementation of the system, and are easy to test. The limitation of system behavior is only limited to what needs to be done. (For example, the sampling frequency of the bending sensor can also be higher in implementation, as long as there is no unexpected behavior, everything can be).
Writing requirements is like building software in your brain. Therefore, the operation is more important than execution.
This article was published on Beijing website production Company Shangpin China //ihucc.com/
Source Statement: This article is original or edited by Shangpin China's editors. If it needs to be reproduced, please indicate that it is from Shangpin China. The above contents (including pictures and words) are from the Internet. If there is any infringement, please contact us in time (010-60259772).
