# UNIT 1: Introduction, Software Life-Cycle Models, Software Requirements Specification (SRS), Formal Requirements Specification, Verification & Validation ## 1.1 Introduction to Software Engineering & Crisis Software Engineering is defined by IEEE as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." ### The Software Crisis During the 1960s and 1970s, computer hardware evolved rapidly while software development remained an unstructured, informal craft. This led to severe issues collectively termed the **Software Crisis**: - Projects running significantly over budget and past deadlines. - Software being unreliable, unmaintainable, and exhibiting low quality. - Unmet user expectations due to poor requirement elicitation. - High software maintenance costs (often exceeding 70-80% of total lifecycle cost). ### Software Engineering Principles To overcome the software crisis, fundamental principles were established: 1. **Modularity**: Dividing a large complex system into smaller, independent, manageable units. 2. **Abstraction**: Hiding internal implementation details while exposing essential interface capabilities. 3. **Information Hiding (Parnas Principle)**: Restricting access to internal data structures and module logic. 4. **Localization**: Grouping related code and data elements together in single modules. 5. **Uniformity**: Standardized coding styles, documentation, and design notations. 6. **Completeness & Confirmability**: Ensuring all requirements are met and verifiable through formal testing. --- ## 1.2 Software Development Life Cycle (SDLC) Models ### 1. Classical Waterfall Model Introduced by Winston Royce (1970), the Waterfall Model is a linear-sequential software process model divided into distinct non-overlapping phases: 1. **Feasibility Study**: Technical, economic, and operational viability analysis. 2. **Requirement Analysis & Specification**: Gathering user requirements and producing the SRS. 3. **Design**: System Architecture, High-Level Design (HLD), and Low-Level Design (LLD). 4. **Coding & Unit Testing**: Translating design into executable source code modules. 5. **Integration & System Testing**: Combining modules and verifying system functionality. 6. **Maintenance**: Corrective, adaptive, perfective, and preventive maintenance. #### Advantages & Disadvantages - *Advantages*: Simple, easy to manage, clear milestones, well-documented phases. - *Disadvantages*: High risk and uncertainty; rigid phase boundaries; no working software until late in the lifecycle; unsuitable for long or complex projects with evolving requirements. --- ### 2. Prototyping Model When user requirements are vague or ill-defined, the Prototyping Model builds a working mock-up (prototype) early in the development lifecycle. #### Workflow 1. Quick Requirement Gathering. 2. Quick Design & Prototype Construction. 3. Customer Prototype Evaluation & Feedback. 4. Prototype Refinement (Iterative loop until requirements stabilize). 5. Final Product Engineering (Building full system based on approved prototype). #### Types of Prototypes - **Throwaway Prototyping**: The prototype is discarded after requirements are finalized, and system code is rebuilt cleanly. - **Evolutionary Prototyping**: The prototype is continuously refined and expanded into the final production system. --- ### 3. Rapid Application Development (RAD) Model The RAD model is a high-speed adaptation of the linear-sequential model, prioritizing component-based construction. - Requires system modularization into independent sub-components. - Multiple parallel development teams build sub-modules within tight 60–90 day timeframes. - Heavy reliance on reusable software components, automated GUI builders, and CASE tools. --- ### 4. Spiral Model (Boehm) Proposed by Barry Boehm in 1988, the Spiral Model is an iterative, risk-driven process model. It combines the structured rigidity of the Waterfall Model with the iterative nature of Prototyping. #### The 4 Spiral Quadrants 1. **Objective Setting & Identification**: Define phase objectives, alternative solutions, and constraints. 2. **Risk Assessment & Reduction**: Evaluate technical and operational risks; build prototypes to mitigate risks. 3. **Development & Validation**: Develop code, perform unit/integration/system testing, and build the product release. 4. **Planning**: Review phase progress and plan the next spiral iteration. #### Key Strength The Spiral Model is unique because it explicitly incorporates **Risk Analysis** as a primary phase activity. It is the model of choice for large, expensive, high-risk systems (e.g., defense aerospace systems). --- ### 5. Agile Methodology & Scrum Framework Agile software development values individuals and interactions over processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan (Agile Manifesto). #### Scrum Framework Key Elements - **Sprints**: Fixed-duration iterative development cycles lasting 2 to 4 weeks. - **Product Backlog**: Prioritized master list of user stories and functional requirements. - **Sprint Backlog**: Subset of product backlog items selected for execution in the current sprint. - **Scrum Roles**: - *Product Owner*: Defines user stories and prioritizes backlog. - *Scrum Master*: Facilitates team process and eliminates operational blockers. - *Development Team*: Cross-functional self-organizing engineering group. - **Ceremonies**: Daily Standup (15-min sync), Sprint Planning, Sprint Review (demo), Sprint Retrospective. --- ## 1.3 Software Requirements Specification (SRS) ### Definition & Purpose An SRS is a formal document that describes the intended behavior, constraints, interfaces, and quality attributes of a software system. It forms the binding legal contract between software customers and developers. ### IEEE 830 Standard Structure 1. **Introduction**: Purpose, Scope, Definitions, References, Overview. 2. **Overall Description**: Product perspective, Product functions, User characteristics, Constraints, Assumptions. 3. **Specific Requirements**: - **Functional Requirements**: Statements detailing input processing, output generation, and business rules. - **Non-Functional Requirements**: Performance, Reliability, Security, Usability, Maintainability, Availability. - **External Interface Requirements**: User interfaces, Hardware interfaces, Software interfaces, Communications interfaces. ### Characteristics of a Good SRS (IEEE 830) - **Correct**: Every requirement accurately states a feature to be delivered. - **Unambiguous**: Every requirement has exactly ONE interpretation. - **Complete**: Includes all significant functional and non-functional requirements. - **Consistent**: No requirements conflict with one another. - **Ranked for Importance & Stability**: Requirements labeled as essential, conditional, or optional. - **Verifiable**: There exists a cost-effective finite process to verify that the software meets the requirement. - **Modifiable**: Structure permits easy structural changes without breaking consistency. - **Traceable**: Origin of each requirement is clear, and forward/backward tracing to design/code is possible. - **Implementation Independent**: Specifies WHAT system does, not HOW it is coded. --- ## 1.4 Formal Requirements Specification Formal methods use mathematical notations—derived from set theory, predicate logic, algebraic structures, and state machines—to specify software behavior without natural language ambiguity. ### Key Specification Languages - **Z Notation**: Model-based specification language based on Zermelo-Fraenkel set theory and first-order predicate logic. Uses *Schemas* to define state spaces and state transitions. - **VDM (Vienna Development Method)**: Model-oriented language featuring explicit pre-conditions and post-conditions for data operations. - **Larch**: Two-tiered specification approach separating interface specification from underlying logic. ### Benefits & Drawbacks - *Benefits*: Eliminates ambiguity, enables mathematical proof of correctness, catches design flaws early. - *Drawbacks*: Requires specialized mathematical background; steep learning curve; high initial cost; difficult for non-technical stakeholders to review. --- ## 1.5 Software Verification & Validation (V&V) ### Verification vs Validation Core Distinction - **Verification**: *"Are we building the product right?"* - Static evaluation process. - Checks if software artifacts conform to specifications defined in preceding phases. - Involves Reviews, Inspections, Walkthroughs, static code analysis without executing software. - **Validation**: *"Are we building the right product?"* - Dynamic evaluation process. - Checks if the built software satisfies actual customer operational needs. - Involves running functional tests, performance tests, and acceptance tests on executable code. ### Levels of Software Testing 1. **Unit Testing**: Testing individual functions, classes, or modules in isolation (White-Box testing). 2. **Integration Testing**: Testing module interfaces and combined sub-assemblies (Top-down, Bottom-up, Big-Bang, Sandwich). 3. **System Testing**: Testing complete integrated system against functional and non-functional SRS specs (Black-Box testing). 4. **Acceptance Testing**: Final testing by end-users before production deployment. - **Alpha Testing**: Conducted at developer's site by internal users in a controlled environment. - **Beta Testing**: Conducted at customer's site by end-users in a real operational environment. --- ---