Unit 2: Software Requirement Specifications (SRS)
Software Requirement Specification (SRS)
SRS (Software Requirement Specification) is a formal document that clearly describes what the software should do, how it should behave, and constraints under which it must operate.
In simple words: SRS = Written agreement between user and developer
Software Requirement Specification (SRS) is a detailed description of the functional and non-functional requirements of a software system.
Objectives of SRS
- Clearly understand user requirements
- Avoid misunderstanding between client and developer
- Provide a base for design, coding, and testing
- Act as a legal reference document
- Reduce development cost and errors
Characteristics of a Good SRS (Very Important)
| Characteristic | Explanation |
|---|---|
| Correct | Matches user needs |
| Complete | No missing requirements |
| Clear & Unambiguous | Easy to understand |
| Consistent | No conflicting requirements |
| Verifiable | Can be tested |
| Modifiable | Easy to update |
| Traceable | Easy to track changes |
Requirement Engineering Process
Requirement Engineering is a systematic process of identifying, analyzing, documenting, validating, and managing user requirements.
Main Phases of Requirement Engineering
- Requirement Elicitation
- Requirement Analysis
- Requirement Documentation
- Requirement Review / Validation
- Requirement Management
Requirement Elicitation
Requirement Elicitation is the process of collecting requirements from users and stakeholders.
Sources of Requirements
- End users
- Clients
- Managers
- Existing systems
Techniques of Elicitation
| Technique | Explanation |
|---|---|
| Interviews | Direct discussion with users |
| Questionnaires | Written questions |
| Observation | Watching users work |
| Brainstorming | Group discussion |
| Prototyping | Early model of software |
Problems in Elicitation
- Users unclear about needs
- Communication gap
- Changing requirements
Requirement Analysis
Requirement Analysis involves studying, refining, and organizing collected requirements.
Activities
- Remove ambiguity
- Identify conflicts
- Prioritize requirements
- Check feasibility
Types of Requirements
| Type | Description |
|---|---|
| Functional | What system should do |
| Non-Functional | Performance, security, reliability |
| User Requirements | High-level needs |
| System Requirements | Detailed technical needs |
Requirement Documentation
This phase converts analyzed requirements into a formal SRS document.
Contents of SRS
| Section | Description |
|---|---|
| Introduction | Purpose and scope |
| Overall Description | System overview |
| Functional Requirements | System functions |
| Non-Functional Requirements | Performance, security |
| Constraints | Hardware, software limits |
| Assumptions | Expected conditions |
Requirement Review (Validation)
Requirement Review ensures that the documented requirements are correct, complete, and acceptable to users.
Validation Techniques
| Technique | Explanation |
|---|---|
| Reviews | Formal checking |
| Walkthroughs | Step-by-step explanation |
| Prototyping | User feedback |
| Test case generation | Check testability |
Purpose
- Detect errors early
- Ensure user satisfaction
- Avoid rework
Requirement Management
Requirement Management deals with handling changes in requirements throughout the software lifecycle.
Activities
- Change control
- Version management
- Requirement tracing
- Impact analysis
Why Requirement Management is Important?
- Requirements change frequently
- Avoid scope creep
- Maintain project schedule
Quick Comparison Table (Exam-Friendly)
| Phase | Objective |
|---|---|
| Elicitation | Gather requirements |
| Analysis | Understand and refine |
| Documentation | Write SRS |
| Review | Validate correctness |
| Management | Control changes |
Frequently Asked Exam Questions
- What is SRS? Explain its characteristics
- Explain Requirement Engineering Process
- Describe requirement elicitation techniques
- Difference between functional and non-functional requirements
- Importance of requirement management
Conclusion
SRS is a crucial document in software engineering that acts as a foundation for software development. Requirement Engineering ensures that user needs are properly understood, documented, validated, and managed, leading to high-quality software and reduced project risk.
Feasibility Study
A Feasibility Study is an early analysis to check whether a software project is possible, practical, and worth developing.
In simple words: Feasibility Study = “Should we build this software or not?”
Types of Feasibility (TELOS Model)
| Type | Explanation |
|---|---|
| Technical | Required technology and skills available |
| Economic | Cost–benefit analysis |
| Legal | Legal and regulatory issues |
| Operational | Will users accept it? |
| Schedule | Can it be completed on time? |
Importance of Feasibility Study
- Reduces risk
- Saves time and money
- Helps management decision
- Avoids project failure
Information Modelling
Information Modelling represents data, relationships, and constraints of a system in a structured form.
Purpose
- Understand data flow
- Improve system design
- Reduce complexity
Common Information Models
- Data Flow Diagram (DFD)
- Entity Relationship Diagram (ERD)
- Decision Tables
Data Flow Diagrams (DFD)
DFD is a graphical representation of how data flows within a system.
Components of DFD
| Symbol | Component | Description |
|---|---|---|
| Circle | Process | Data processing |
| Arrow | Data Flow | Movement of data |
| Rectangle | External Entity | Source/Destination |
| Open Rectangle | Data Store | Storage of data |
Levels of DFD
- Context Diagram – Entire system as one process
- Level-1 DFD – Major processes
- Level-2 DFD – Detailed processes
Advantages of DFD
- Easy to understand
- Shows system logic clearly
- Useful for requirement analysis
Entity Relationship Diagram (ERD)
ERD represents entities, attributes, and relationships between data objects.
Components of ERD
| Component | Description |
|---|---|
| Entity | Real-world object |
| Attribute | Properties of entity |
| Relationship | Connection between entities |
| Cardinality | One-to-one, One-to-many |
Types of Relationships
- One-to-One (1:1)
- One-to-Many (1:M)
- Many-to-Many (M:M)
Importance of ERD
- Helps database design
- Reduces redundancy
- Improves data consistency
Decision Tables
A Decision Table is a tabular method to represent complex logic and decision rules.
Structure of Decision Table
| Section | Description |
|---|---|
| Conditions | Input conditions |
| Actions | Output actions |
| Rules | Condition-action combinations |
Advantages of Decision Tables
- Removes ambiguity
- Easy to understand logic
- Useful in testing
Software Requirement Specification (SRS) Document
SRS Document is a formal written description of all functional and non-functional requirements of the software.
Main Contents of SRS
| Section | Description |
|---|---|
| Introduction | Purpose, scope |
| Overall Description | System overview |
| Functional Requirements | System functions |
| Non-Functional Requirements | Performance, security |
| Constraints | Limitations |
| Assumptions | Expected conditions |
Benefits of SRS
- Clear understanding
- Reduces errors
- Basis for testing
- Controls scope creep
IEEE Standards for SRS (IEEE 830 / IEEE 29148)
IEEE provides a standard format and guidelines for writing SRS documents to ensure quality and consistency.
Standard Structure of IEEE SRS
- Purpose
- Scope
- Definitions
Overall Description
- Product perspective
- User characteristics
- Operating environment
Specific Requirements
- Functional requirements
- Performance requirements
- Design constraints
- Security requirements
Appendices
-
Supporting information
Characteristics of IEEE-Standard SRS
| Feature | Meaning |
|---|---|
| Correct | Matches user needs |
| Complete | No missing info |
| Unambiguous | Clear meaning |
| Verifiable | Testable |
| Traceable | Easy to track |
Quick Revision Table
| Topic | Key Point |
|---|---|
| Feasibility Study | Project viability check |
| Information Modelling | Data representation |
| DFD | Data movement |
| ERD | Data relationships |
| Decision Table | Logic representation |
| SRS | Requirement document |
| IEEE SRS | Standard format |
Important Exam Questions
- Explain types of feasibility study
- Draw and explain DFD
- Explain ERD with example
- What is a decision table?
- Explain IEEE standards for SRS
Conclusion
Feasibility study ensures project success, information modelling simplifies system understanding, and IEEE-standard SRS provides a strong foundation for high-quality software development.
Software Quality Assurance (SQA)
Software Quality Assurance (SQA) is a set of planned and systematic activities used to ensure that software meets specified quality standards and user requirements.
In simple words: SQA = Preventing defects, not just finding them
Objectives of SQA
- Ensure high-quality software
- Reduce errors and rework
- Improve customer satisfaction
- Follow standards and procedures
- Control development process
Verification and Validation (V & V)
Verification checks whether the software is being built correctly according to specifications.
“Are we building the product right?”
Examples
- Reviews
- Inspections
- Walkthroughs
- Static analysis
Validation checks whether the final software meets user needs.
“Are we building the right product?”
Examples
- System testing
- Acceptance testing
- User testing
Difference between Verification and Validation (Very Important)
| Basis | Verification | Validation |
|---|---|---|
| Focus | Process correctness | Product correctness |
| Type | Static testing | Dynamic testing |
| Timing | During development | After development |
| Question | Built right? | Built right product? |
SQA Plans
An SQA Plan is a document that defines how quality assurance activities will be carried out in a project.
Contents of SQA Plan
| Section | Description |
|---|---|
| Purpose | Objective of SQA |
| Standards | Rules and guidelines |
| Reviews & Audits | Quality checks |
| Testing Strategy | Testing approach |
| Tools | QA tools used |
| Responsibilities | QA team roles |
| Reporting | Defect reporting |
| Risk Management | Quality risks |
Importance of SQA Plan
- Clear quality goals
- Controlled development
- Reduced project risk
- Consistent quality
Software Quality Frameworks
A Software Quality Framework provides guidelines, standards, and best practices to improve software quality.
Common Software Quality Frameworks
| Framework | Description |
|---|---|
| ISO 9000 | Quality management standard |
| CMM / CMMI | Process maturity model |
| Six Sigma | Defect reduction |
| TQM | Total Quality Management |
ISO 9000 Models
ISO 9000 is a set of international standards for quality management systems (QMS) developed by ISO (International Organization for Standardization).
ISO 9000 Series (Important for Exams)
| Standard | Purpose |
|---|---|
| ISO 9001 | Quality management system |
| ISO 9000 | Concepts and terminology |
| ISO 9004 | Performance improvement |
Key Principles of ISO 9000
- Customer focus
- Leadership
- Process approach
- Continuous improvement
- Evidence-based decisions
Benefits of ISO 9000
- Improved quality
- International recognition
- Customer satisfaction
- Better documentation
SEI–CMM Model (Capability Maturity Model)
SEI-CMM is a process improvement model developed by Software Engineering Institute (SEI) to assess the maturity of software development processes.
Levels of SEI-CMM (Very Important)
| Level | Name | Description |
|---|---|---|
| Level 1 | Initial | Ad-hoc and chaotic |
| Level 2 | Repeatable | Basic project management |
| Level 3 | Defined | Standard processes |
| Level 4 | Managed | Quantitative control |
| Level 5 | Optimizing | Continuous improvement |
Advantages of CMM
- Predictable development
- Improved quality
- Reduced cost
- Better risk management
Quick Comparison Table
| Concept | Focus |
|---|---|
| SQA | Prevent defects |
| Verification | Process check |
| Validation | Product check |
| ISO 9000 | Quality management |
| SEI-CMM | Process maturity |
Frequently Asked Exam Questions
- Explain Software Quality Assurance
- Differentiate Verification and Validation
- Explain SQA Plan
- Describe ISO 9000 standards
- Explain SEI-CMM levels
Conclusion
Software Quality Assurance ensures reliable and high-quality software by applying systematic processes, standards, and continuous improvement models like ISO 9000 and SEI-CMM.