Based on D. Galin, and R. Patton

 According to D. Galin  Software quality assurance is:  A systematic, planned set of actions necessary to provide sufficient assurance that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines  According to the IEEE  Software quality assurance is:  1. A planned and systematic pattern of all actions  necessary to provide sufficient confidence that an item  or product conforms to established technical  requirements.  2. A set of activities designed to evaluate the process by  which the products are developed or manufactured.

 (1) Assuring an acceptable level of confidence that the software will conform to functional technical requirements. A function is described as a set of inputs, the behavior (use case) and outputs. Functional requirements may be calculations, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish Functional requirements are supported by non-functional requirements, which enforce constraints on the design or implementation (such as performance requirements, security, or reliability).on-functional requirements Functional requirements are expressed in the form "system must do ", while non-functional requirements are "system shall be ". The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.  (2) Assuring an acceptable level of confidence that the software will conform to managerial scheduling and budgetary requirements.

 The logical design of a system relates to an abstract representation of the data flows, inputs and outputs of the system  Often conducted via modelling, using an over-abstract (and sometimes graphical) model of the actual system. Logical design includes ER Diagrams

 The physical design relate to the actual input and output processes of the system.  In terms of how data is input into a system, how it is verified/authenticated, how it is processed, and how it is displayed as In Physical design, the following requirements about the system are decided.  Input requirement,  Output requirements,  Storage requirements,  Processing Requirements,  System control and backup or recovery.

 (1) Assuring an acceptable level of confidence that the software  maintenance activities will conform to the functional  technical requirements.  (2) Assuring an acceptable level of confidence that the software  maintenance activities will conform to managerial  scheduling and budgetary requirements.  The importance of software maintenance  A study by Lientz and Swanson, categorized maintenance activities into four classes:  Adaptive – modifying the system to cope with changes in the software environment (Ex. DBMS, OS)  Perfective – implementing new or changed user requirements which concern functional enhancements to the software  Corrective – diagnosing and fixing errors, possibly ones found by users  Preventive – increasing software maintainability or reliability to prevent problems in the future

● Know what you are doing ● Know what you should be doing ● Know how to measure the difference

1.Know what you are doing – understand what is being built, how it is being built and what it currently does  suppose a software development process with management structure (milestones, scheduling) reporting policies, tracking

2. Know what you should be doing – having explicit requirements and specifications – presume a software development process with requirements analysis, acceptance tests, frequent user feedback

3. Know how to measure the difference – having explicit measures comparing what is being done from what should be done Complementary methods: ● formal methods – verify mathematically specified properties ● testing – explicit input to exercise software and check for expected output ● inspections – human examination of requirements, design, code,... based on checklists

SQA includes ● Verification – are we building the product right ? – performed at the end of a phase to ensure that requirements established during previous phase have been met ● Validation – are we building the right product ? – performed at the end of the development process to ensure compliance with product requirements

REQUIREMENT ARCHITECTING LOW DESIGN CODING Verification

 Reliability Requirements  Reliability is to have your system available in the worst possible scenario. To achieve these goals exist redundancy that provides data reliability, and fault tolerance that provides disk reliability.fault tolerance  Portability Requirements  System can be easily and quickly docked to a new specified environment when necessary.  Usability Requirements  Usability involves satisfaction and learnability, because if the common user can not learn naturally what the system can and can not do then he will not use it.  Note : without usability the whole system has no meaning because no one will use it  Efficiency Requirements  It comprises two type: ◦ Space Requirements, it involves the space the system or application could fill in its life, for example the amount of disk space the database will occupy in the first year, or maybe the minimun available memory space need it to correctly perform. ◦ Performance Requirements, it includes the application reponse time, for example some applications would need to have a minimum response time of 0.5 seconds. With this requirement you have to consider how the system will change overtime.  Nietho,J, Nietho,J,