Requirements should be complete. When tester writes test cases, what exactly is required from the application, is the first thing which needs to be clear. For e. Consistent requirements. The SRS should be consistent within itself and consistent to its reference documents. This sets the standard and should be followed throughout the testing phase. Testing environment: some applications need specific conditions to test and also a particular environment for accurate result.
SRS should have clear documentation on what type of environment is needed to set up. Pre-conditions defined clearly: one of the most important part of test cases is pre-conditions. If they are not met properly then actual result will always be different expected result.
Verify that in SRS, all the pre-conditions are mentioned clearly. Requirements ID: these are the base of test case template. Based on requirement Ids, test case ids are written. Also, requirements ids make it easy to categorize modules so just by looking at them, tester will know which module to refer.
SRS must have them such as id defines a particular module. Security and Performance criteria: security is priority when a software is tested especially when it is built in such a way that it contains some crucial information when leaked can cause harm to business. Tester should check that all the security related requirements are properly defined and are clear to him.
Also, when we talk about performance of a software, it plays a very important role in business so all the requirements related to performance must be clear to the tester and he must also know when and how much stress or load testing should be done to test the performance.
Assumption should be avoided: sometimes when requirement is not cleared to tester, he tends to make some assumptions related to it, which is not a right way to do testing as assumptions could go wrong and hence, test results may vary.
Deletion of irrelevant requirements: there are more than one team who work on SRS so it might be possible that some irrelevant requirements are included in SRS. Based on the understanding of the software, tester can find out which are these requirements and remove them to avoid confusions and reduce work load.
Freeze requirements: when an ambiguous or incomplete requirement is sent to client to analyze and tester gets a reply, that requirement result will be updated in the next SRS version and client will freeze that requirement. Freezing here means that result will not change again until and unless some major addition or modification is introduced in the software.
Most of the defects which we find during testing are because of either incomplete requirements or ambiguity in SRS. To avoid such defects it is very important to test software requirements specification before writing the test cases. Software requirements specification should be accurate, complete, efficient, and of high quality, so that it does not affect the entire project plan.
An SRS is said to be of high quality when the developer and user easily understand the prepared document. Other characteristics of SRS are discussed below. The requirements document is devised in a manner that is easier to write, review, and maintain. It is organized into independent sections and each section is organized into modules or units.
Note that the level of detail to be included in the SRS depends on the type of the system to be developed and the process model chosen for its development.
For example, if a system is to be developed by an external contractor, then critical system specifications need to be precise and detailed. Similarly, when flexibility is required in the requirements and where an in-house development takes place, requirements documents can be less detailed. Since the requirements document serves as a foundation for subsequent software development phases, it is important to develop the document in the prescribed manner.
For this, certain guidelines are followed while preparing SRS. These guidelines are listed below. The information to be included in SRS depends on a number of factors, for example, the type of software being developed and the approach used in its development.
If software is developed using the iterative development process, the requirements document will be less detailed as compared to that of the software developed for critical systems.
This is because specifications need to be very detailed and accurate in these systems. A number of standards have been suggested to develop a requirements document.
For example,. There may be a reasonable or temporal conflict between the two specified actions. Two or more requirements may define the same real-world object but use different terms for that object. For example, a program's request for user input may be called a "prompt" in one requirement's and a "cue" in another.
The use of standard terminology and descriptions promotes consistency. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the requirements report should determine the implications in the SRS so that it is clear and simple to understand.
Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement in it has an identifier to indicate either the significance or stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be essential, especially for life-critical applications, while others may be desirable. Each element should be identified to make these differences clear and explicit. Another way to rank requirements is to distinguish classes of items as essential, conditional, and optional. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements. The requirements are verified with the help of reviews. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation.
Backward Traceability: This depends upon each requirement explicitly referencing its source in earlier documents. Forward Traceability: This depends upon each element in the SRS having a unique name or reference number.
The forward traceability of the SRS is especially crucial when the software product enters the operation and maintenance phase. As code and design document is modified, it is necessary to be able to ascertain the complete set of requirements that may be concerned by those modifications.
Design Independence: There should be an option to select from multiple design alternatives for the final system. More specifically, the SRS should not contain any implementation details. Testability: An SRS should be written in such a method that it is simple to generate test cases and test plans from the report. Hence, the purpose of formal notations and symbols should be avoided too as much extent as possible.
The language should be kept simple and clear. The right level of abstraction: If the SRS is written for the requirements stage, the details should be explained explicitly.
Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of abstraction modifies according to the objective of the SRS. Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and complete.
Verbose and irrelevant descriptions decrease readability and also increase error possibilities. Structured: It should be well-structured. A well-structured document is simple to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the user requirements.
0コメント