Software Crisis, Software Processes and

Characteristics, Software Life Cycle

Models
1. Software Crisis
Definition

The software crisis refers to the difficulties and challenges faced in software development,
maintenance, and management due to increasing complexity, changing requirements, and lack
of standard development methodologies.

Causes of Software Crisis

1.​ Increasing Complexity: Software systems have become more complex, making it
difficult to design, develop, and maintain them efficiently.
2.​ Poor Quality Assurance: The absence of standard quality control techniques often
results in unreliable and error-prone software.
3.​ Budget Overruns: Many software projects exceed their estimated budget due to
improper planning and scope creep.
4.​ Schedule Slippage: Delays in software development are common due to inadequate
project management and changing user requirements.
5.​ Maintenance Difficulties: Updating and modifying software after deployment is difficult
due to poor documentation and rigid architecture.
6.​ Lack of Skilled Manpower: The demand for skilled software engineers often exceeds
supply, leading to low-quality software development.
7.​ Failure to Meet User Expectations: Software often does not meet the actual needs of
end-users due to inadequate requirement analysis.

Solutions to Software Crisis

●​ Adoption of software engineering principles

●​ Implementation of structured software development life cycle (SDLC) models
●​ Proper requirement gathering and documentation
●​ Use of automated software development and testing tools
●​ Implementation of agile and iterative development methodologies
2. Software Processes and Characteristics
Software Process

A software process is a structured set of activities required to develop a software system. It

includes various stages such as requirement analysis, design, coding, testing, deployment, and
maintenance.

Phases of Software Process

1.​ Requirement Analysis - Understanding user needs and documenting system

requirements.
2.​ System Design - Defining architecture, data flow, and components.
3.​ Implementation (Coding) - Writing the actual code using programming languages.
4.​ Testing - Identifying and fixing defects in the software.
5.​ Deployment - Delivering the software to end-users.
6.​ Maintenance & Updates - Providing support and making necessary improvements.

Characteristics of a Good Software Process

●​ Predictability: The process should produce reliable outcomes.

●​ Efficiency: It should minimize time and resource wastage.
●​ Scalability: It should handle increasing software complexity.
●​ Adaptability: It should accommodate changing requirements.
●​ Quality-Oriented: It should ensure high software quality and user satisfaction.

3. Software Life Cycle Models

A software life cycle model defines the process followed in software development, from
inception to retirement.

3.1 Waterfall Model

Definition:

The Waterfall Model is a linear sequential approach where each phase is completed before the
next phase begins.

Phases:

1.​ Requirement Analysis - Gathering and documenting requirements.

2.​ System Design - Creating architecture and technical specifications.
 3.​ Implementation - Developing the actual software.
4.​ Integration & Testing - Testing the software for defects and fixing them.
5.​ Deployment - Delivering the software to users.
6.​ Maintenance - Updating and fixing issues after deployment.

Advantages:

●​ Simple and easy to understand.

●​ Well-structured documentation.
●​ Suitable for small projects with clear requirements.

Disadvantages:

●​ Rigid and inflexible to changes.

●​ Late discovery of defects.
●​ Not suitable for complex and evolving projects.

3.2 Prototype Model

Definition:

A software prototype is developed to understand user requirements better before building the
final system.

Phases:

1.​ Requirement Gathering & Analysis - Initial requirements are collected.

2.​ Quick Design - A rough design of the system is created.
3.​ Prototype Development - A working prototype is built.
4.​ User Evaluation - Users test and provide feedback.
5.​ Refinement - Modifications are made based on feedback.
6.​ Final Development - The actual system is developed.

Advantages:

●​ Helps in understanding unclear requirements.

●​ Enhances user involvement.
●​ Reduces risk of project failure.

Disadvantages:

●​ Time-consuming due to repeated modifications.

●​ May increase development cost.
3.3 Spiral Model

Definition:

The Spiral Model combines iterative development with risk management.

Phases:

1.​ Planning - Define objectives, constraints, and risks.

2.​ Risk Analysis - Identify and evaluate potential risks.
3.​ Engineering - Develop and test a prototype.
4.​ Evaluation - Review and decide on the next iteration.

Advantages:

●​ Effective risk management.

●​ Flexible to changing requirements.
●​ Suitable for large and complex projects.

Disadvantages:

●​ Expensive due to continuous risk evaluation.

●​ Complex to manage and implement.

3.4 Rapid Application Development (RAD) Model

Definition:

The RAD model focuses on rapid development using iterative prototyping and user feedback.

Phases:

1.​ Business Modeling - Define business goals and process flow.

2.​ Data Modeling - Identify and structure required data.
3.​ Process Modeling - Define business logic and workflow.
4.​ Application Generation - Develop software prototypes rapidly.
5.​ Testing & Deployment - Test and deploy the system iteratively.

Advantages:

●​ Fast development and delivery.

●​ Encourages user involvement.
●​ Reduces development time and cost.
Disadvantages:

●​ Requires skilled developers.

●​ Not suitable for large, complex projects.
●​ Poor documentation due to rapid iterations.

​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​

​
​
​
Chapter 2 -

Requirement Engineering
Requirement Engineering (RE) is the process of defining, documenting, and maintaining
requirements in the software development process. It involves identifying user needs and
ensuring they are accurately documented and implemented.

Phases of Requirement Engineering

1.​ Requirement Elicitation – Collecting and gathering requirements from stakeholders.

2.​ Requirement Analysis – Analyzing collected requirements to ensure feasibility and
clarity.
3.​ Requirement Specification – Documenting the requirements formally (SRS).
4.​ Requirement Validation – Ensuring that the gathered requirements meet the user’s
needs.
5.​ Requirement Management – Handling changes and maintaining traceability of
requirements.

Requirement Elicitation Techniques

Elicitation is the process of discovering requirements from stakeholders. Different techniques
are used to gather requirements efficiently.

1. FAST (Facilitated Application Specification Techniques)

●​ A structured meeting technique used for requirement gathering.

●​ Conducted in a joint meeting with stakeholders, developers, and analysts.
●​ Encourages discussion, brainstorming, and consensus-building.
●​ Reduces ambiguity and improves clarity of requirements.

2. QFD (Quality Function Deployment)

●​ A customer-driven approach to translating user requirements into product specifications.

●​ Uses a matrix-based tool called the House of Quality to map customer needs to
technical requirements.
 ●​ Ensures that user expectations align with the product design.

3. Interviews

●​ Stakeholders are interviewed to gather functional and non-functional requirements.

●​ Can be structured (predefined questions) or unstructured (open discussion).

4. Questionnaires & Surveys

●​ Used to collect requirements from a large number of stakeholders.

●​ Provides quantitative data for analysis.

5. Prototyping

●​ A sample or model of the system is created to gather user feedback.

●​ Helps in refining unclear requirements.

6. Observations

●​ Analysts observe users in their working environment to understand their needs.

●​ Useful for identifying implicit requirements.

7. Brainstorming

●​ Stakeholders generate new ideas and refine existing ones collaboratively.

●​ Helps in identifying innovative solutions.

8. JAD (Joint Application Development)

●​ A structured workshop where users and developers collaborate to define system

requirements.
●​ Reduces conflicts and enhances mutual understanding.

Requirement Analysis
Requirement Analysis ensures the correctness, consistency, and completeness of gathered
requirements.

1. Data Flow Diagram (DFD)

 ●​ Represents the flow of data within a system.​

●​ Uses symbols like:​

○​ Processes (circles/ovals)
○​ Data Stores (parallel lines)
○​ External Entities (rectangles)
○​ Data Flow Arrows
●​ Levels of DFD:​

○​ Level 0 (Context Diagram) – Shows the system as a single process.

○​ Level 1 – Breaks down the system into major processes.
○​ Level 2+ – Further decomposes each process.

2. Data Dictionaries

●​ A centralized repository of data definitions.

●​ Contains:
○​ Data types, format, and constraints.
○​ Relationships between data items.
○​ Default values and allowed operations.

3. Entity-Relationship (ER) Diagram

●​ Represents entities, attributes, and relationships between entities.

●​ Symbols:
○​ Entities (Rectangles)
○​ Attributes (Ellipses)
○​ Relationships (Diamonds)
○​ Lines to represent associations.

4. UML (Unified Modeling Language)

●​ A set of diagrams used to model software systems.

●​ Types include:
○​ Use Case Diagram – Shows actors and system interactions.
○​ Sequence Diagram – Represents interactions between objects over time.
○​ Class Diagram – Defines the structure of classes and relationships.

5. Sequence Diagram

●​ Represents interactions between objects in sequential order.

●​ Components:
○​ Actors – Users or systems.
 ○​ Objects – Represented as rectangles.
○​ Lifelines – Dotted lines showing object existence.
○​ Messages – Arrows indicating communication.

6. Class Diagram

●​ Represents the structure of a system in terms of classes and relationships.

●​ Components:
○​ Classes (Rectangles with attributes & methods).
○​ Associations (Lines connecting classes).
○​ Multiplicity (1:1, 1:M, M:N relationships).

Software Requirement Specification (SRS)

Need for SRS

●​ Acts as a formal agreement between stakeholders and developers.

●​ Prevents misunderstandings and scope creep.
●​ Ensures clarity, consistency, and completeness of requirements.

Characteristics of a Good SRS

1.​ Correctness – Must accurately define system behavior.

2.​ Unambiguous – Requirements should have a single interpretation.
3.​ Complete – No missing requirements.
4.​ Consistent – No contradictions within requirements.
5.​ Ranked – Prioritization of requirements.
6.​ Modifiable – Should accommodate future changes easily.
7.​ Traceable – Each requirement should be linked to a source.
8.​ Verifiable – Testable and measurable requirements.

Organization of SRS

An SRS document is typically structured as follows:

1.​ Introduction – Overview, purpose, and scope of the system.

2.​ Overall Description – Product perspective, user characteristics.
3.​ Specific Requirements – Functional and non-functional requirements.
4.​ External Interface Requirements – UI, hardware, software interfaces.
5.​ Performance Requirements – Speed, scalability, reliability.
6.​ Design Constraints – Regulatory, legal, and standards compliance.
Requirement Documentation
●​ Captures and records all requirements systematically.
●​ Includes:
○​ Business requirements.
○​ User requirements.
○​ Functional & non-functional requirements.
○​ Use cases and scenarios.
○​ Acceptance criteria and constraints.
●​ Formats:
○​ Natural Language Documentation
○​ Structured Text Documentation
○​ Graphical Representation (UML, DFDs, ER diagrams, etc.)

Summary
●​ Requirement Engineering involves gathering, analyzing, and documenting software
requirements.
●​ Requirement Elicitation Techniques include FAST, QFD, Interviews, Prototyping, JAD,
and Observations.
●​ Requirement Analysis uses tools like DFDs, ER diagrams, UML, and Data Dictionaries.
●​ SRS is a structured document defining all system requirements.
●​ Requirement Documentation ensures all requirements are recorded and maintained