Software development and online application are inseparable from the process of software testing, which is a process used by analysts to find software defects. No software is completely defect-free. The tester’s goal is to reduce the defects found in the project and to instill quality into the software application.
Software testing has a very direct relationship with user experience, because software testers need to analyze the software to know whether the software meets the user's expectations. Software testing is a quality activity designed to properly ensure that the software meets the needs of users.
What the user needs is what the software needs, so software requirements are the most critical part of ensuring the quality of the final software and the basis of software testing. High-quality software requirements have laid a solid foundation for the final quality of the product.
So, what are the factors that affect the quality of high-quality software requirements?
1. Comprehension
The requirements must be understandable, and the understandable requirements are organized in a way that is easy to read and review. Here are some ways to improve comprehensibility:
1. Organize requirements based on objects (such as users, orders, and invoices).
2. User needs should be organized according to business processes or scenarios, so that industry experts can quickly determine whether there are missing needs.
3. Separate functional requirements from non-functional requirements, for example, separate functional requirements and performance requirements.
4. Organize requirements according to the level of detail. It is determined by the impact of demand on the system. For example, "the system should be able to receive orders" and "the system should be able to receive retail orders at the point of sale" have different effects on the system.
5. The written requirements should conform to the grammatical rules, and the style should be easy to read and review. If the requirement is written in a word document, you should enable the spell check option and pay attention to the context, because word does not check whether the following is appropriate.
6. The requirements should be clear. The word "should" should be used appropriately in the requirements, instead of "will" or "should be", because the latter two words are about goals, not requirements. If you use non-imperative terms to indicate that the requirement is optional, it may cause the requirement to be misunderstood, may increase the project cost, may increase the time period, reduce the quality, or cause contract disputes.
2. Necessity
Demand should be required. Give an example of non-essential requirements. Suppose the following requirement has been included in the requirements specification: "If 100 test cases pass, the system should be acceptable." This is actually a project process, not a requirement, and should not be recorded in the requirements specification. The requirements must be related to the target application or system being built.
Three, can be modified
The requirements and related information must be modifiable. The technology that selects storage requirements affects the modifiability of requirements. For example, requirements in a word processor are more difficult to modify than requirements management tools (such as CaliberRM). However, for very small projects, word processors are the best choice because of the relationship between the cost of demand management tools and the learning curve.
Consistency also has an impact on modifiability. The structure of the requirements writing template should make the requirements well presented and facilitate modification. Best practice should mark each requirement with a unique identifier. The dependencies of any requirement should be marked, for example, requirement X should depend on requirement Y.
Fourth, non-redundant
There should be no duplicate requirements, otherwise it will cause problems. Repeated requirements will increase maintenance work. For example, every time a requirement is modified, the duplicated requirement must also be modified. Duplicate requirements also increase the possibility of injection requirements errors.
Five, simplicity
A good requirement must eliminate redundant words or redundant information. A succinct expression of demand should be in one phrase, and words such as "on the other hand", "but", and "in retrospect" should be eliminated.
6. Testable
The measurable requirement must be able to be verified and confirmed. It can also be said that the intent of the requirement should be able to be proved. Untestable requirements are suitable when testers want to explain objectively. It is best to bring the question: Can I test this requirement to see if it works?
Seven, traceability
The requirements must be traceable, which is the key to verifying whether the requirements are met. Complex requirements are difficult to track and may cause product testing to fail. For example, "the system should calculate pensions and survivors' pensions" is a compound demand. The list method can avoid misunderstandings when reviewing the tracking capabilities of each requirement.
8. Scope definition
All requirements must be defined within the specified scope. The scope of the project is based on all the requirements established for the project. The scope of the project is defined and refined according to the identification, analysis and baseline of requirements. The "tracking capability matrix" helps to ensure that the requirements are within the specified range.