Essential Software Engineering Concepts: SQA, Agile, Testing, and Design Principles

Posted on Nov 21, 2025 in Computer Engineering in Computer Engineering

Software Quality Assurance (SQA) and Its Types

What is SQA?

Software Quality Assurance (SQA) is a systematic process designed to prevent defects from happening in the first place, ensuring the final software meets required quality standards and user expectations. It covers activities like audits, reviews, and monitoring throughout the entire Software Development Life Cycle (SDLC). The main goal is to deliver reliable, efficient, and maintainable software.

Types of SQA

• Process Assurance: Ensures the team follows the defined organizational standards, guidelines, and proper SDLC models.
• Product Assurance: Focuses on the final product itself to verify it meets all functional and quality requirements through testing and validation.
• Project Assurance: Checks if project management activities (like scheduling, resource, and risk management) follow quality standards and the project is progressing as planned.
• Security Assurance: Ensures the software is protected against unauthorized access, data breaches, and vulnerabilities.
• Safety Assurance: Used in critical domains (like aviation) to ensure the system operates safely without causing harm or failure.
• Configuration Assurance: Maintains control over all software versions, documents, and code changes to ensure consistency (integrity).

Coupling and Cohesion in Software Design

Coupling

Coupling refers to the degree of interdependence between software modules.

• High Coupling (Bad): Modules are closely connected, so a change in one module is likely to affect other modules (difficult to maintain).
• Low Coupling (Good): Modules are independent, so changes in one have little impact on others (easier to maintain and test).

Types of Coupling (Worst to Best)

1. Content Coupling (Worst): One module directly modifies the data or control flow of another module.
2. Common Coupling: Modules share global data structures (making it hard to trace effects of changes).
3. External Coupling: Modules depend on external modules (like a protocol or hardware).
4. Control Coupling: Modules pass control information (like a flag) to each other.
5. Stamp Coupling: A complete data structure (like an entire record) is passed, even if only part of it is needed (involves “tramp data”).
6. Data Coupling (Best): Modules communicate by passing only the necessary data.

Cohesion

Cohesion refers to the degree to which elements within a single module work together to fulfill a single, well-defined purpose.

• High Cohesion (Good): Elements are closely related and focused on one task (easy to understand and reuse).
• Low Cohesion (Bad): Elements are loosely related and serve multiple purposes (difficult to modify).

Types of Cohesion (Low to High)

1. Coincidental Cohesion (Lowest): Elements are completely unrelated (accidental grouping).
2. Logical Cohesion: Elements are logically related but not functionally (e.g., one module handling all inputs from disk, tape, and network).
3. Temporal Cohesion: Elements are related only by their timing (executed in the same time span, like initialization tasks).
4. Procedural Cohesion: Elements are grouped based on their sequence of execution (ensuring order).
5. Communicational Cohesion: Elements operate on the same input data or contribute to the same output data (e.g., update record and print it).
6. Sequential Cohesion: The output of one element becomes the input for the next element within the same module (data flow).
7. Functional Cohesion (Highest): Every element is essential for a single computation or task (the ideal situation).

Types and Principles of Software Testing

Main Types of Testing

• Manual Testing: Testing the software by using its functions and features manually to check for defects.
  • Advantage: Fast visual feedback, effective for dynamically changing GUI, less expensive.
• Automation Testing: Using scripts and software tools to automatically execute test cases.
  • Advantage: Simplifies execution, improves reliability, increases test coverage, minimizes human error.

The Seven Principles of Software Testing

1. Testing Shows the Presence of Defects: Testing can only prove that defects exist, not that the software is completely error-free.
2. Exhaustive Testing is Not Possible: You can’t test every input or scenario; testing must focus on the most critical and risk-prone areas.
3. Early Testing Saves Time and Cost: Finding and fixing issues early in the SDLC is cheaper.
4. Defect Clustering: Most defects are usually concentrated in a small number of modules (high-risk areas).
5. Pesticide Paradox: Running the same tests repeatedly will stop finding new bugs; tests must be regularly updated and improved.
6. Testing is Context-Dependent: The testing approach must vary based on the type of application (web, mobile, embedded, etc.).
7. Absence of Errors Fallacy: Even if the software has no bugs, it’s still a failure if it doesn’t meet the user’s needs or expectations.

Capability Maturity Model (CMM)

What is CMM?

The Capability Maturity Model (CMM) is a framework used to analyze and improve the processes and techniques an organization follows to develop software products. It is not a development model itself, but a strategy for process improvement, moving the organization through five different levels of maturity.

Levels of CMM

• Level 1: Initial (Unstable)
  • Characteristics: No key processes (KPAs) are defined. The process is ad-hoc and chaotic, depending on individual skill rather than standardized processes. Project success is highly reliant on a specific person.
• Level 2: Repeatable
  • Characteristics: Focuses on establishing basic project management policies. Success on similar projects is repeated because the organization can track costs, schedule, and requirements. Processes include Project Planning, Configuration Management, and SQA.
• Level 3: Defined
  • Characteristics: The organization has a well-defined, integrated set of standard software engineering and management processes. These processes are documented, standardized, and applied consistently across all projects. Focus includes Peer Reviews, Organization Process Definition, and Training Programs.
• Level 4: Managed
  • Characteristics: Quantitative management is introduced. The organization sets quantitative quality goals for software and processes. Measurements are made to predict product and process quality within limits (statistically). Focus includes Quantitative Quality Management and Software Quality Management.
• Level 5: Optimizing (Highest)
  • Characteristics: Focuses on continuous process improvement. Defects are prevented by identifying and removing their causes. New processes and technologies are evaluated and deployed to improve quality and productivity. Focus includes Defect Prevention, Technology Change Management, and Process Change Management.

Software Quality Assurance (SQA) and Formal Technical Review (FTR)

SQA Recap

Software Quality Assurance (SQA) is a simple way to assure quality in the software by setting processes, procedures, and standards that are suitable for the project and correctly implemented. It focuses on improving the process of development so that problems can be prevented before they become major issues. SQA is an umbrella activity applied throughout the software process.

Formal Technical Review (FTR)

An FTR is a structured, formal quality control activity performed by a team of technical experts (software engineers) to evaluate the quality, design, and analysis of any technical work product (like code, designs, or requirements) against standards.

• Goal: The main objective is to find errors, ensure standards are followed, and improve the product or document.
• Process: FTRs involve reviews, walkthroughs, inspections, and small-group technical assessments. Each FTR is conducted as a properly planned, controlled, and attended meeting. FTRs also help to promote communication, consistency, and familiarity with parts of the software the team might not be working on otherwise.

Function Point (FP) Estimation

What is FP Estimation?

Function Point (FP) Estimation is a software sizing technique developed by Alan J. Albrecht to measure the size of a software system based on its functionalities (what the user asks for), rather than the lines of code. It helps in estimating the total effort, cost, and time required for software development.

Objectives

• Provide a standardized method to measure software size.
• Assist in project estimation in terms of cost, time, and resources.
• Provide a user-oriented measurement rather than a developer-oriented one.

Steps in FP Estimation

1. Identify the Type of Functions: Categorize functions into five types: External Inputs (EI), External Outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF), and External Interface Files (EIF).
2. Assign Weights: Each function type is classified as Low, Average, or High complexity, and weights are assigned accordingly to calculate the Unadjusted Function Points (UFP).
3. Determine the Value Adjustment Factor (VAF): VAF is determined based on 14 General System Characteristics (GSCs) (like performance, reliability, complexity, etc.), which are rated on a scale of 0 to 5.
4. Calculate Adjusted Function Points (AFP): AFP represents the overall functional size of the software.
5. Effort Estimation: Total effort (Person-Hours) is calculated using the relevant formula.

Agile Process Model

What is Agile?

The Agile Process Model is an iterative and incremental approach to software development that emphasizes flexibility, collaboration, and customer satisfaction. It is primarily designed to help projects adapt quickly to changing requirements and deliver working software in short cycles (iterations).

Core Principles (Main Aim)

• Working software is the key measure of progress.
• Delivering software in small, frequent increments.
• Continuous feedback and involvement of customers.
• The team values rapid, adaptive response to change over rigid planning.

Phases in the Agile Model

1. Requirement Gathering: Requirements are gathered continuously through interaction with the customer. The focus is on understanding user needs rather than preparing lengthy documents.
2. Design the Requirements: The system is designed using wireframes and high-level UML diagrams. Prototypes may be used to get early user feedback.
3. Construction/Iteration: The software is developed in small cycles known as iterations, which typically last 1–4 weeks. New features are coded, tested, and integrated during each iteration.
4. Testing/Quality Assurance: Testing (Unit, Integration, System) is performed continuously throughout the development process, often within each iteration.
5. Deployment: After testing, the working software is deployed to the end users incrementally.
6. Feedback: Feedback from customers and stakeholders is collected after each release and immediately incorporated into the next iteration. Continuous improvement based on feedback is a key aspect.

Software Reverse Engineering

What is Reverse Engineering?

Software Reverse Engineering is the process of recovering the design, requirement specifications, and functions of a software product by analyzing its code. It involves building a program database and generating information about the system. It is used to extract design information from source code, moving from the abstraction level of the source code upwards to higher levels of design.

Objectives

• Reducing Costs: Finding replacements or effective alternatives for system components.
• Analysis of Security: Examining software to expose exploits, vulnerabilities, and malware.
• Integration and Customization: Helping developers incorporate or modify hardware/software into existing systems.
• Recovering Lost Source Code: Recovering the source code of a software application when it has been lost or is inaccessible.
• Fixing Bugs and Maintenance: Reverse engineering helps find and repair flaws or provide updates for systems where the original source code is unavailable.

Reverse Engineering to Understand Processing (Abstraction)

To understand the system, the code is analyzed at various levels of abstraction, from the lowest (source code) to the highest (system, program, component, pattern). Each level represents an abstraction:

• High Level: Functional abstraction (what the system does).
• Low Level: Processing narrative (how the code works).

LOC Model for Cost Estimation

What is Cost Estimation?

Cost estimation is a technique used to predict the financial spend (cost and effort) required to develop and test software. Models like COCOMO use mathematical algorithms or parametric equations to estimate the cost.

LOC (Lines of Code) Model

The LOC (Lines of Code) Model is one of the earliest and simplest software cost estimation techniques.

• Metric: It is a size-oriented metric that estimates the effort and cost of a software project based on the total number of lines of source code to be written.
• Definition: LOC includes any line in the source code that is not a comment or blank line. This includes header lines, variable declarations, and all executable and non-executable statements.

Features and Advantages of LOC

• Change Tracking: It can track the growth or reduction of a codebase over time, helping to analyze project progress and estimating development effort.
• Ease of Computation: It is a simple and quick measure to calculate, as it only involves counting the non-comment lines.
• Ease of Understanding: LOC is an intuitive measure that can be easily understood by both technical and non-technical stakeholders.
• Simple Representation: Expressing code size in terms of lines provides a clear and simple representation.

Steps in LOC-Based Cost Estimation

1. Estimate KLOC: Estimate the total number of lines of code expected (KLOC = 1000 lines of code).
2. Determine Productivity Rate: Determine the average number of lines of code produced per person-month from past data.
3. Compute Effort: Compute the effort (Person-Months) using the empirical formula: Effort (Person-Months) = a + b × (KLOC)
4. Estimate Total Cost: Total Cost = Effort × Cost per Person-Month.

Version Control and Change Control

Version Control (Revision Control/Source Control)

Version control is a set of procedures and tools (like an SCM repository) used for managing the creation, evolution, and use of multiple versions (revisions) of configuration objects (code, files, documentation).

• Purpose: It enables the team to keep a history of all changes, support parallel work, revert to previous versions, and build specific versions of the product.
• Key Capabilities: Stores all relevant configuration objects, tracks all revisions, and allows the team to record and manage outstanding issues.

Typical Workflow

1. Check-out/Update: Obtaining the latest version.
2. Modify: Making changes.
3. Commit/Check-in: Recording the changes back to the repository.
4. Build/Merge: Integrating multiple changes/branches.
5. Tag/Label: Setting a baseline.
6. Revert/Rollback: Reverting to a stable version.

Change Control (Change Management)

Change control is the process within configuration management that identifies, evaluates, approves, implements, and monitors changes to configuration items.

• Purpose: The objective is to maintain the integrity of the product configuration, ensuring that changes are reviewed and approved before implementation, and that the documentation and plan remain consistent.

Steps in the Change Control Process

1. Change Request / Identification: A need for change is recognized (new requirement or defect) and a formal Request for Change (RFC) is submitted.
2. Review & Assessment: The change control board reviews the RFC, checking feasibility, impact, cost, schedule, etc., and prioritizes the change.
3. Planning the Change: A detailed implementation plan is prepared (who, when, fallback plan).
4. Approval / Authorization: The change is formally approved (or rejected) by the authority (Change Control Board) based on the evaluation.
5. Implementation / Execution: The change is executed: code modified, tests run, documentation updated.
6. Verification / Testing: The implemented change is validated and verified to meet the requirements.
7. Closure: After successful verification, the change request is closed, and records are updated (change logs, lessons learned).

Principles of Software Design

What is Software Design?

Software design is the process of creating a plan to show the look, functions, and working of the software. It converts the software requirements into a step that can be carried out to develop the system.

Principles of Software Design

These principles help organize and arrange the structural components of the software design:

• Avoid “Tunnel Vision”: The designer should not focus only on completing or achieving the design goal, ignoring the potential effects on other parts of the software.
• Traceable to the Analysis Model: The design should be traceable back to the analysis model (requirements) to ensure it satisfies all requirements and leads to a high-quality product.
• Do Not “Reinvent The Wheel”: The design process should not waste time and effort creating things that already exist. Reuse existing elements whenever possible.
• Minimize “Intellectual Distance”: The design should reduce the gap between the real-world problem and the software solution, meaning it should be intuitively understandable.
• Exhibit Uniformity and Integration: The design should display uniformity (consistency) and allow all parts of the software (subsystems) to be easily integrated into one system.
• Accommodate Change: The design must be flexible enough to accommodate the changing implications that the software should adjust to, as per the user’s need.
• Degrade Gently: The software should be designed in such a way that it degrades gracefully, meaning it should work properly even if an error occurs during execution.
• Assessed for Quality: The design should be assessed for quality throughout the evaluation, to ensure the quality needs are checked and focused on.
• Review to Discover Errors: The design should be reviewed to check if there is an error present or if it can be minimized.
• Design is Not Coding: Design means describing the logic of the program, while coding is the implementation of the design.

Tracking, Scheduling, and Software Maintenance

1. Scheduling

Scheduling is the process of planning when and how maintenance tasks will be performed. It involves estimating time, effort, and deciding the sequence of operations. Proper scheduling ensures all maintenance activities (debugging, testing, updates) are completed within a defined time frame.

• Key Points: It defines when maintenance activities occur, allocates resources (developers, tools), helps set milestones, prevents delays, and helps balance workload.

2. Tracking

Tracking is the process of monitoring and controlling maintenance activities against the schedule. It involves comparing the planned progress with the actual progress to identify any deviations or delays.

• Key Points: Tracks actual progress against targets, detects delays, helps maintain transparency, and provides early warning signals for potential risks or failures.

3. Types of Software Maintenance

• Corrective Maintenance: Carried out to correct errors or faults found after the software has been delivered (fixing bugs, logic errors). It is reactive in nature.
• Adaptive Maintenance: Modifies the software so that it continues to operate correctly in a changing environment (new operating systems, hardware upgrades, new business rules, or regulatory updates).
• Perfective Maintenance: Performed to improve overall performance, efficiency, and usability of the software (enhancing existing features, adding new functionalities, or improving structure).
• Preventive Maintenance: Aims to prevent future problems by making changes that increase the software’s maintainability and reliability (code restructuring, documentation updates).
• Patching (Emergency Maintenance): Refers to emergency fixes or quick updates made to resolve urgent issues or security vulnerabilities.

User Interface (UI) Design in Web Technology

Role of UI Design

User Interface (UI) Design plays a vital role in the success of web technology as it determines how effectively a user can interact with a website or web application. A well-designed UI enhances the user experience (UX), increases user satisfaction, and ensures smooth communication.

Importance of UI/UX Design in Web Technology

• Improves User Experience (UX): The primary purpose is to make the interaction between the users and the website smooth and enjoyable. A good UI provides clear layouts, meaningful visuals, and organized content.
• Enhances Accessibility: A properly designed interface ensures that websites are accessible to all kinds of users, including those with disabilities or limited technical knowledge.
• Increases Efficiency and Usability: A simple and well-organized interface helps users perform actions faster without confusion, saving time and reducing frustration.
• Builds Brand Identity and Trust: A visually appealing and consistent UI design reflects professionalism and builds trust in the brand image.
• Supports Multi-Platform Compatibility: A responsive UI ensures the website adjusts itself automatically to different screen sizes (desktops, laptops, tablets, and smartphones).
• Reduces Errors and Confusion: A clear interface helps users understand what actions they can take, reducing user mistakes and improving task completion rates.
• Boosts User Engagement: Attractive and visually appealing designs attract users’ attention, making them spend more time on the site.
• Follows Design Principles and Process: The UI design process includes stages like User Analysis (study target audience), Interface Design (layouts, controls), and Implementation/Validation.

Extreme Programming (XP) and Use Case Modeling

Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology that focuses on delivering high-quality software through frequent and continuous feedback, collaboration, and adaptation.

Key Principles

• Working software is the key measure of progress.
• Deliver working software in small, rapid increments.
• Continuous feedback and involvement of customers.
• Face-to-face communication is preferred over documentation.
• The delivery dates are decided by empowered teams of talented individuals.

Process: XP projects start with user stories, which are short descriptions of what scenarios the customer would like the system to support. Each story is written on a separate card and can be flexibly grouped.

Use Case

A use case is a technique used to capture the functional requirements of a system. It describes how a user (known as an actor) interacts with the system to achieve a specific goal.

• Purpose: The development of use cases helps in understanding system behavior from a user’s perspective.

Steps Involved in Use Case Development

1. Identify Actors: Identify all the users or external systems that will interact with the system.
2. Identify Use Cases: Determine what each actor wants to achieve with the system (e.g., login, register, place order).
3. Establish Relationships: Define how actors and use cases are connected (e.g., Include, Extend, Generalization).
4. Describe the Use Case: Write a detailed description for each use case, including the use case name, actors, preconditions (what must be true before it starts), main flow (step-by-step description), and postconditions (the result after execution).
5. Draw the Use Case Diagram: Represent all use cases and actors visually using ovals for use cases and stick figures for actors, connected with lines to show their interactions.
6. Review and Validate: Review the use cases with stakeholders to ensure they correctly represent the required system behavior.

System Process Framework

What is a Software Process Framework?

A Software Process Framework is a structured approach that defines the steps, tasks, and activities involved in software development. It divides the entire development process into organized stages to ensure clarity and order. This framework is the foundation for software engineering.

• Purpose: It guides the development team through various stages, ensures a systematic and efficient process, and helps teams follow a consistent development pattern.

Components and Activities of a Process Framework

A process framework includes five main activity categories, often summarized by the acronym “Task Sets, Umbrella Activities, and Process Framework Activities”:

• Process Framework Activities (High-Level Stages): These are high-level tasks that define the flow and structure of the process, typically including phases like “Requirement Analysis,” “Design,” “Implementation,” and “Testing”. Each activity includes several smaller actions and tasks.
• Task Sets (Work Products): A task set is a related group of tasks that produce a major work product (e.g., “Designing a database” involves tasks like creating tables, defining relationships).
• Umbrella Activities (Ongoing Activities): These are recurring activities applied throughout the entire development process. They ensure quality and control. Examples include:
  • Documentation
  • Quality Assurance (SQA)
  • Risk Management
  • Project Tracking and Control.

Benefits

• Enhances productivity, consistency, and the overall quality of the software product.
• Minimizes confusion, reduces errors, and helps deliver the product within budget and schedule.
• It acts as the foundation for software development methodologies like Waterfall, Spiral, and Agile.

Requirement Model

What is a Requirement Model?

A Requirement Model is a collection of different representations (like diagrams, text, and tables) used to define what a computer-based system should do and how it should perform under various conditions.

• Purpose: It helps stakeholders (users, developers, managers) understand the system’s needs and behavior from different perspectives.

Elements of the Requirement Model

The requirements model elements are dedicated to the analysis modeling method being used and typically include:

• Scenario-based elements (User View): These describe the system from the user’s point of view. They include basic use cases and their corresponding descriptions, which evolve into more elaborate template-based use cases and activity diagrams for elaboration.
• Class-based elements (Data View): A collection of things that have similar attributes and common behaviors (i.e., objects categorized into classes). This element uses UML class diagrams (like the Class diagram for a sensor) to depict the data structure and relationships between classes.
• Behavioral elements (System State View): These show the effect of behavior on the computer-based system (e.g., how the system reacts to events). Modeling elements that depict behavior must be provided by the requirements model. The UML state diagram is often used here to represent how the system changes state based on events or input (UML state diagram notation).
• Flow-oriented elements (Information Flow View): These illustrate how information flows through the computer-based system. The system accepts input, applies functions to transform it, and produces output. Data flow diagrams are often used to represent this view.

White Box Testing Techniques

What is White Box Testing?

The main benefit of white box testing is that it allows for testing every part of an application to achieve complete code coverage. Testers use their knowledge of the internal code structure, logic, and flow to design tests.

Techniques Used for Code Coverage

• Statement Coverage: The aim is to traverse all statements at least once. Hence, each line of code or every node in a flowchart must be traversed at least once.
• Branch Coverage: Focuses on testing the decision points or conditional branches (e.g., IF statements) in the code. It checks whether both possible outcomes (True and False) of each conditional statement are tested at least once. In a flowchart, all edges must be traversed at least once.
• Condition Coverage: In this technique, all individual conditions within a complex conditional statement must be covered. Example: If the statement is IF(X==0 || Y==0), the condition X==0 must be tested as True and False, and the condition Y==0 must be tested as True and False.
• Multiple Condition Coverage: All possible combinations of the outcomes of conditions are tested at least once. Example: For IF(X==0 || Y==0), the combinations (T, T), (T, F), (F, T), and (F, F) for (X==0, Y==0) must all be tested.
• Basis Path Testing: Control flow graphs are made from code/flowcharts, and Cyclomatic Complexity (V(G)) is calculated to define the minimum number of test cases needed for an independent path. Formula: V(G) = P + 1 (where P is the number of predicate nodes/decisions) OR V(G) = E – N + 2 (where E is edges, N is nodes).
• Loop Testing: Loops are highly used and fundamental to many algorithms. Testing includes Simple loops (skip loop, one pass, m passes, n+1 passes), Nested loops (start from innermost loop), and Concatenated loops (independent loops tested individually).

Differentiation of Software Engineering Concepts

i) Scrum and Kanban

ii) White Box Testing and Black Box Testing

iii) FTR and Walkthrough

iv) Alpha Testing and Beta Testing

Short Notes on Testing and Quality Methodologies

i) Boundary Value Analysis (BVA)

Boundary Value Analysis (BVA) is a software testing technique used in Black Box Testing. It is used to identify errors at the boundaries (edges) of input domains rather than within the range.

• Principle: It is based on the principle that errors often occur at extreme ends or limits of input values. The likelihood of defects is higher near the boundary values of the input rather than in the middle of the range.
• Values Used: In BVA, test cases are designed using boundary values of input ranges, such as the minimum, maximum, just below, and just above these limits.
• Goal: The goal of BVA is to detect boundary-related defects and ensure that the system behaves correctly at input limits.
• Example (Valid Age Range: 18 ≤ Age ≤ 60):
  • Just below lower boundary: 17 (Invalid)
  • Exact lower boundary: 18 (Valid)
  • Just above lower boundary: 19 (Valid)
  • Just below upper boundary: 59 (Valid)
  • Exact upper boundary: 60 (Valid)
  • Just above upper boundary: 61 (Invalid)
• Reason for Effectiveness: Boundary values are the most error-prone because programmers often make mistakes in defining limit conditions (e.g., using < instead of ≤).

ii) Six Sigma for Software Engineering

Six Sigma is a methodology for process improvement that helps organizations make their operations more efficient by identifying and removing errors and variations.

• Goal: Variations in processes cause errors, leading to defective products and poor customer satisfaction. Six Sigma aims to reduce such variations to lower costs and increase customer satisfaction.
• Concept: A Six Sigma process has only 3.4 defects per million opportunities (DPMO), which means 99.99966% defect-free, showing near-perfect performance.

Characteristics

• Statistical Quality Control: Uses σ (sigma), meaning standard deviation, which measures process variation.
• Methodical Approach: Uses DMAIC (Define, Measure, Analyze, Improve, Control) and DMADV (Define, Measure, Analyze, Design, Verify) for improvement.
• Fact and Data-Based: Decisions are made through statistical and scientific analysis.
• Objective and Process-Based: Implemented with clear goals and measurable outcomes.
• Customer Focus: Quality standards are based on customer requirements and satisfaction.
• Teamwork-Oriented: Relies on collaboration and organized efforts within the organization for quality improvement.

Characteristics of a Software Requirements Specification (SRS)

What is SRS?

A good SRS (Software Requirements Specification) document clearly defines what the system should do and how it should perform under various conditions.

Major Characteristics of a Good SRS

• Correctness: The SRS must correctly represent all the requirements of the system. Example: If a restaurant system must generate daily sales reports, this requirement must be clearly mentioned.
• Unambiguity: Every requirement should have only one clear meaning, avoiding confusion. Example: Instead of “fast response,” it should say “response time must be under 2 seconds”.
• Completeness: The document must include all functional and non-functional requirements.
• Consistency: Requirements should not conflict with each other. Example: The SRS cannot say “system must allow only admins to add patients” AND “any user can add patients”.
• Verifiability: Each requirement should be testable through inspection, analysis, or testing.
• Modifiability: The SRS should be structured so that changes can be made easily without affecting the whole document.
• Traceability: Each requirement should be uniquely identified (e.g., labeled as R1, R2, etc.) so that it can be traced during design and testing.
• Design Independence: The SRS should describe what the system should do, not how it will be implemented. Example: It should say “system shall store data securely” rather than specifying the exact database technology.