the test stage that will be performed for the project. Requirement Type(s) may vary in description at different organizations; the following are some of the typical Requirement types:
- Functional–the objectives of the system: functionality, including navigation, data entry, processing and Retrieval and the proper implementation of the business rules.
- System Performance– how well a function is accomplished in quantitative terms.
- System Load/Stress– the performance of the target-of-test under the stress of many clients requesting data at the same time.
- Business Scenario– specific steps that the user(s) will perform using the system.
- Security–application level security, including access to data or business functions and system-level security.
- Usability–the ability of the end-user to utilize the system as defined.
- Conversion–the conversion of one or more characters of data between the target-of-test and a device.
3) Determining the Test Stage applicable to the Requirements
Based on the Requirement Type(s) identified, the test stage can be determined. For example, the Requirements for the project may be provided in the form of a contractual agreement between an organization and a Vendor, where the Vendor’s software is expected to perform transactions within a stipulated period ot time. The test stage in this instance would be Performance testing; the stage(s) of the Performance test can be determined based on the Requirements defined in the agreement. Some of the industry standard test stages are:
- Unit Testing
- Integration Testing
- System Testing
- System Performance
- System Load/Stress
- System Security/Access Control
- Functional Testing
- User Acceptance Testing
A definition of the test stages that will apply for the various architectures within an organization will assist in determining the appropriate test stage applicable to the Requirements gathered.
4) Building a Requirements Matrix
The Requirements Matrix is a simple form of tabling the project requirements. This is especially useful for small enhancement projects comprised of one component and bug fixes of a short test duration.
Data gathered from sources, such as, Change Control Process documents, JAD sessions, and Vendor supplied documentation can be extracted and placed in a Requirements Matrix to streamline the list of items to be tested for a project.
Requirement descriptions should be written in a modular fashion and assigned identifiers. The identifiers should be used to cross-reference test cases (scripts). This provides a means for determining when there are enough test cases (scripts) to cover all Requirements. When there is a change in Requirements or design, the identifiers and cross-reference provide the means to quickly determine which test cases (scripts) need to be changed and which are re-usable.
The list of fields to include in a Requirement matrix are listed below:
- Requirements ID (used to trace the requirement to the script id)
- Requirement Description
- Test Stage/Type
- Test Case (Script) ID
5) Reviewing the Requirements
Once the Requirements have been gathered and assessed, regardless of the sources used, documented information, including Requirement Matrix should be initially reviewed with Developers and Users or the appropriate project team personnel, so as to assure an understanding of what the feature is supposed to do. This can be accomplished by:
- Conducting formal reviews with Users and Developers or the appropriate Project Team members.
- Forwarding documented notes taken from discussions with Project Team personnel denoting understanding of the requirements as outlined in discussions. This provides the verification of the data and initiation of corrections prior to testing.
|The Common Sense Approach to Gathering Requirements||90 KB|