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.
SQA Management Plans
In the planning and requirements phase, there will be four plans that will be created. These plans will be used in the next stage of software development which is the architectural phase. The Software Quality Assurance Plan (SQAP) for architectural design (AD) is basically the following list of activities to ensure that the preparation of the architectural plan is a success. If any tool or application will be used, the SQA team should point this out in this phase.
• Software Project Management Plans (SPMP) for Architecture Design
The SQA team should ensure that this management plan will have the specific budget for developing the software. Aside from being specific, the SQA team should also ensure that the estimate should be obtained using scientific methods.
• Software Configuration Management Plans (SCMP) for Architectural Design
SCMP is the plan on how the software will be eventually configured. In this phase, the SQA team should ensure that the configuration should have been established at the start.
• Software Verification Management Plan (SVMP) for Architectural Design
Like most of the management plans, this one has already been established. But extra information should be sought after by the SQA team. Since this document will be used in the architectural design phase more detailed information is needed. A test plan should be made to ensure that the Architectural Design phase is a success. Also, the SQA team should ensure a general testing system should be established.
Output and Principles
At the end of the planning phase, developers should be able to produce a document that has the details needed for the Architectural Design phase. The SQA team should check if the document has the following characteristics:
• Consistency – This is especially applicable if the output does not use any CASE tools. Case tools should easily figure out inconsistencies and it is up to the SQA team to determine this consistency if no CASE tools was used in this phase.
• Verifiable – Each specific requirement in this phase should be tested either by a popular tool or verifiable facts from the past.
• Complete – The SR or software requirements is the end of the requirement phase. To declare that this phase is complete, the SQA team should check with the UR (user requirements) and see to it that all the things needed by the user are answered. If possible, a matrix should be created to track each answer of the SR to the UR built by the users.
In the end, the SQA team, the developers and representatives of the users will come together for a formal review of the documents. By sitting together, everyone will know if the things needed in the software are covered or will come together with the application.
