SQA Planning and Requirements

SQA Planning and Requirements

The scope of Software Quality Assurance or SQA starts from the planning of the application until it is being distributed for the actual operations. To successfully monitor the application build up process, the SQA team also has their written plan. In a regular SQA plan, the team will have enumerated all the possible functions, tools and metrics that will be expected from the application. SQA planning will be the basis of everything once the actual SQA starts.

Without SQA planning, the team will never know what the scope of their function is. Through planning, the client’s expectations are detailed and from that point, the SQA team will know how to build metrics and the development team could start working on the application.

When the SQA team starts working, one of the first things they will have to tackle is to determine the developer team’s initial output. The intended users or at least part of them will be forwarding information which tells of their expectations of the new software called UR (User Requirements), this document will be the bases.

What is left is to determine the software requirements in the intended application. In business or in any intended application, software requirements are very important since these requirements will tell how an application would work. This will also be the ground work for developers. From these requirements they will know what language, SDLC program and other protocols that will be used to build the applications.

While the developers work on determining the requirements, the SQA team will be monitoring their work to ensure the requirements are according to the expectations.

Technical Activities

One of the responsibilities of the SQA team from the developers is the required user requirements document. The UR document is produced by the intended users who are tapped for this project. This document will inform the developers what the users are expecting from the application.

The SQA team will ensure that the document exists before they actually work on the software requirements. The UR document will be the bases for the SR document so it will never make sense if the SR document is produced without consulting the user requirements document first. The SQA team should also ensure that the UR document should be of quality.

To develop an efficient software requirement document, the developers should use a known method to determine this type requirement for software development. There are lots of software requirements analysis methods that could be used but developers do not just pick one they prefer. The SQA team should ensure that the analysis method should be reputable or recognized. As much as possible the analysis method should have been published.

Aside from a published analysis method for software requirements, it is also ideal that the analysis method will be supported by different Computer-Aided Software Engineering (CASE) tools. CASE tools are used to develop models for software development and software requirements could easily be determined by with this application. Although it is not required for financial and time frame reasons, CASE tools should be highly considered by developers.

The intended metrics for performance is also detailed in software requirements. Above all, metrics should be emphasized since it will tell how fast or how efficient the application should perform. Based on this metrics, the SQA team should be able to determine their testing tools. These documents should reflect the principles and the metrics of the clients and the intended users are looking for.