Role of qa in requirements engineering

Editor's Notes

• #3: Assumptions Being CS Students aware about the jargons like SDLC, Quality Assurance, Processes, Software etc If you don’t understand please stop and ask question
• #4: Quality is hard to define as it is a complex concept, dependent on organizational viewpoints and context characteristics
• #5: There are following six phases in every Software development life cycle model: Initial phase / Requirement Gathering. Analysis phase. Design phase. Coding phase. Testing phase. Delivery and maintenance phase. Initial Phase:Business prerequisites are accumulated in this phase. This stage is the primary center of the venture supervisors and partners. Gatherings with supervisors, partners and clients are held keeping in mind the end goal to decide the prerequisites like; Who is going to utilize the framework? In what manner will they utilize the framework? What information ought to be a contribution to the framework? What information ought to be yield by the framework? These are general inquiries that get replied amid prerequisites gathering stage. After prerequisite assembling these necessities are investigated for their legitimacy and the likelihood of consolidating the prerequisites in the framework to be advancement is additionally concentrated on. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.The document consist of the following: Functional Requirement Specification Business Requirement Specification Client/Customer Requirement Specification User Requirement Specification Business Design Document Business Document NOTE: It is not necessary that every company uses all these phases some have their own ways to providing a specification. Analysis Phase:The feasibility study, Tentative planning, Technology selection, Requirement Analysis are part of the analysis phase.People who work in this field are: System Analyst (SA),Project Manager (PM),Team Manager (TM) How Analysis phase work? (I) Feasibility study: It is a detailed study of the requirements in order to check whether all the requirements are possible are not.(II) Tentative planning: The resource planning and time planning is temporarily done in this section. (III) Technology selection: The lists of all the technologies that are to be used to accomplish the project successfully will be analysed and listed out here. (IV) Requirement analysisThe list of all the requirements like human resources, hardware, software required to accomplish this project successfully will be clearly analysed and listed out here. Design Phase:Design phase has two major task to follow :HLD (High-Level Designing),LLD (Low-Level Designing) How Design phase works? The chief architect will divide the whole project into modules by drawing some diagrams and technical lead will divide each module into submodules by drawing some diagrams using UML (Unified Modelling Language).The technical lead will also prepare the PSEUDO Code. The Pseudo Code is defined as “A set of English instructions used for guiding the developer to develop the actual code easily”. Coding Phase: Coder has now task to do Programming / Coding. Developers will develop the actual source code by using the PSUEDO Code and following the coding standards like proper indentation, color-coding, proper commenting and etc. The proof of this phase is SCD (Source Code Document). Testing Phase: First of all the Test Engineer will receive the requirement documents and review it for understudying the requirements. If they have any doubts while understanding the requirements they will prepare the Review Report (RR) with all the list of doubts. Once the clarifications are given and after understanding the requirements clearly they will take the test case template and write the test cases. Once the build is released they will execute the test cases. After executions, if they find any defects then they will list out them in a defect profile document. Post that they will send defect profile to the developers and wait for the next build. Once the next build is released they will once again execute the test cases. If they find any defects they will follow the above procedure again and again till the product is defect free. Once they feel the product is defect free they will stop the process. Delivery and Maintenance Phase:Delivery:The senior test engineers who are deployment engineers,then install the application into the client environment with the help of guidelines provided in the deployment document. Maintenance:After the delivery if any problem occurs then that will become a task based problem and the corresponding rolls will be appointed for each problem. Based on the problem, roles will be defined and the process and thus the there solutions.
• #7: There are following six phases in every Software development life cycle model: Initial phase / Requirement Gathering. Analysis phase. Design phase. Coding phase. Testing phase. Delivery and maintenance phase. Initial Phase:Business prerequisites are accumulated in this phase. This stage is the primary center of the venture supervisors and partners. Gatherings with supervisors, partners and clients are held keeping in mind the end goal to decide the prerequisites like; Who is going to utilize the framework? In what manner will they utilize the framework? What information ought to be a contribution to the framework? What information ought to be yield by the framework? These are general inquiries that get replied amid prerequisites gathering stage. After prerequisite assembling these necessities are investigated for their legitimacy and the likelihood of consolidating the prerequisites in the framework to be advancement is additionally concentrated on. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.The document consist of the following: Functional Requirement Specification Business Requirement Specification Client/Customer Requirement Specification User Requirement Specification Business Design Document Business Document NOTE: It is not necessary that every company uses all these phases some have their own ways to providing a specification. Analysis Phase:The feasibility study, Tentative planning, Technology selection, Requirement Analysis are part of the analysis phase.People who work in this field are: System Analyst (SA),Project Manager (PM),Team Manager (TM) How Analysis phase work? (I) Feasibility study: It is a detailed study of the requirements in order to check whether all the requirements are possible are not.(II) Tentative planning: The resource planning and time planning is temporarily done in this section. (III) Technology selection: The lists of all the technologies that are to be used to accomplish the project successfully will be analysed and listed out here. (IV) Requirement analysisThe list of all the requirements like human resources, hardware, software required to accomplish this project successfully will be clearly analysed and listed out here. Design Phase:Design phase has two major task to follow :HLD (High-Level Designing),LLD (Low-Level Designing) How Design phase works? The chief architect will divide the whole project into modules by drawing some diagrams and technical lead will divide each module into submodules by drawing some diagrams using UML (Unified Modelling Language).The technical lead will also prepare the PSEUDO Code. The Pseudo Code is defined as “A set of English instructions used for guiding the developer to develop the actual code easily”. Coding Phase: Coder has now task to do Programming / Coding. Developers will develop the actual source code by using the PSUEDO Code and following the coding standards like proper indentation, color-coding, proper commenting and etc. The proof of this phase is SCD (Source Code Document). Testing Phase: First of all the Test Engineer will receive the requirement documents and review it for understudying the requirements. If they have any doubts while understanding the requirements they will prepare the Review Report (RR) with all the list of doubts. Once the clarifications are given and after understanding the requirements clearly they will take the test case template and write the test cases. Once the build is released they will execute the test cases. After executions, if they find any defects then they will list out them in a defect profile document. Post that they will send defect profile to the developers and wait for the next build. Once the next build is released they will once again execute the test cases. If they find any defects they will follow the above procedure again and again till the product is defect free. Once they feel the product is defect free they will stop the process. Delivery and Maintenance Phase:Delivery:The senior test engineers who are deployment engineers,then install the application into the client environment with the help of guidelines provided in the deployment document. Maintenance:After the delivery if any problem occurs then that will become a task based problem and the corresponding rolls will be appointed for each problem. Based on the problem, roles will be defined and the process and thus the there solutions.
• #9: The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.
• #10: Continuously increasing complexity, ever-increasing market pressure, and customers’ demands for higher quality require a combination of carefully selected validation and verification techniques to deliver a software product on time, within budget and with the desired quality. Requirements engineering is the initial part of a software development process, and all later steps of the development are influenced by the requirements, making the quality of the requirements an important factor for the overall quality of the developed system. Having no intermediate QA, i.e. a quality gate for the intermediate work products, it is most likely that the design and implementation are based on the wrong requirements. This, in consequence, leads to high rework effort as not only the code but most often the overall system architecture and design have to be revised due to requirements defects. Nevertheless, it seems to be quite common to do QA only by means of testing (and maintenance approaches), which, therefore, is an opportunistic approach.
• #13: The goal of this viewpoint is to express the complexity of the concept quality in general. Second, the user view evaluates the quality of a software product with respect to its fitness of purpose to fulfill certain user tasks. The third view, the manufacturing view, focuses on the product view during production and after delivery. It is focused on the adherence of standards and evaluates whether the product was build right the first time. The fourth view is the product view. The focus for this view is on internal quality aspects of the product that can be measured. It is assumed that ensuring certain internal quality aspects has an impact on the external quality and the quality in use of the product. Finally, the value-based view relates quality to cost. It considers quality as something the customer is willing to pay for [32].
• #15: The quality of requirements specifies the quality criteria for good requirements, as described in the previous section. These criteria can vary from company to company and from project to project. They impact the strategy in that they specify what should be achieved with the quality strategy. It is important to define optimal and minimal sets of quality characteristics of requirements [32]. 2. The available resources describe the available effort, budget, hardware, and personnel to perform QA during the requirements activities. In addition, the availability of additional experts has to be considered, as for certain quality assurance approaches, certain stakeholders beyond the requirements engineering processes might be essential (e.g. lead architect during requirements reviews). The available resources have also a direct impact on the applicable QA approaches. For example, if only a small effort is available to perform requirements reviews it is not possible to fulfill a full Fagan inspection with many participants but only a peer review or desk-checking approach [49]. 3. Risks related to certain requirements, especially risks of not realizing a requirement or implementing a requirement in the wrong way, are an additional factor influencing the quality strategy. Risk is defined as not being able to live up to the quality goals and is an important factor for deciding on which part of the requirements which QA approach should focus. For example, not meeting a requirement important to protect human lives bears a high risk and should therefore be checked extra carefully. Moreover, risks can be used to plan the limited quality assurance resources. For example, with the help of risk analysis, it is possible to identify the most critical requirements in the sense of loss of lives or loss of money. The QA approaches should then be focused exactly on these aspects (see also Chap. 5 for related approaches). 4. The overall time schedule is related to the available resources and defines the time available for QA in general and within the requirements phase in particular. Time resources are especially important as they relate the requirements QA activities with other development activities. 5. Finally, the organizational aspects, such as development process, e.g., plandriven or agile development, or product domain, (e.g., desktop software or airplane control system) influence the decision on which QA approaches to use. Moreover, it is important to take the various stakeholders into account. Dependent on the domain, different sets of stakeholders are varying importance (see also Chaps. 2 and 3). These aspects impact the quality strategy in that certain QA approaches might not be applicable due to the organizational constraints. For example, in an agile process, requirements reviews are almost impossible to perform as in the most agile processes requirements are not documented in a way that would allow an inspection (e.g. user stories in extreme- programming often are not longer than one sentence that specifies a general feature [5]). The context elements are important to consider as they define in which way the QA approaches can be applied and which restrictions and constraints must be adhered to. Beside the context in which the quality strategy is embedded, it is also important to consider technical aspects of quality assurance: 1. The basic strategies represent those strategies in place in a company or a project that define how to perform QA in the requirements phase. In that sense they represent the current state of the practice in a certain context. Due to the lack of sophisticated quality strategies, ad-hoc approaches are most frequently applied. For example, the simplest but also the least systematic strategy is to state that everything in the requirements specification should be verified or that all quality issues should be tackled in later development phases. Experience based strategies give hints on what to address in the requirements based on the experience of earlier projects. Such basic strategies should be considered when creating a more sophisticated quality strategy. They provide valuable input on where to start from and what has paid of in the past. 2. The coverage criteria define which aspects of the requirements should be covered by the QA approach. One example of a coverage criterion is that all requirements are covered by at least one test case. An aspect related to coverage that should be considered is the depth of the QA approach [35]. Depth defines the level of detail to which the requirements are verified or validated or, in other words, the quality level to be achieved. The greater the depth, the more resources are required for QA and the more sophisticated QA approaches are required. 3. The most important element of a requirements quality strategy is the potential quality assurance approaches and methods that can be used to ensure the different quality characteristics of the requirements. As discussed, the context elements and the technical elements impact the applicability of QA approaches. The QA approaches are the technical core element of the quality strategy as they represent the means of achieving good requirements quality.