Software Engineering Fundamentals: Models, SRS, Metrics

Posted on Jun 28, 2025 in Software Engineering

What is Software Engineering? Aim and Principles

Software Engineering is a disciplined approach to designing, developing, testing, and maintaining software systems. It applies engineering principles, methodologies, and best practices to ensure that software is reliable, efficient, scalable, and cost-effective.

Aim of Software Engineering

The main aim of Software Engineering is to develop high-quality software that meets user requirements while ensuring:

1. Reliability – The software should function correctly under specified conditions.
2. Maintainability – It should be easy to modify, update, and improve.
3. Scalability – The software should handle increasing workloads efficiently.
4. Efficiency – It should use system resources optimally.
5. Security – Protection against vulnerabilities and cyber threats.
6. Cost-effectiveness – Development and maintenance should be economically viable.
7. User Satisfaction – The software should be user-friendly and meet customer expectations.

The Waterfall Model Explained

The Waterfall Model is a linear and sequential software development process where each phase must be completed before the next begins.

Phases

1. Requirement Gathering – Collect and document software requirements.
2. System Design – Plan architecture, UI, and database structure.
3. Implementation – Write and develop the actual code.
4. Testing – Identify and fix errors before deployment.
5. Deployment – Release the software for users.
6. Maintenance – Fix issues and update as needed.

Pros

• ✔ Simple and well-structured
• ✔ Clear documentation
• ✔ Best for small, well-defined projects

Cons

• ❌ Hard to make changes after a phase is done
• ❌ Late error detection (testing happens late)
• ❌ Not ideal for complex, evolving projects

Example

Used in military, construction, and medical software where strict planning is required.

The Prototype Model Explained

The Prototype Model is an iterative software development approach where an early version (prototype) is built, tested, and refined based on user feedback before full development.

Phases

1. Requirement Gathering – Collect initial requirements.
2. Quick Design – Create a simple prototype.
3. Prototype Development – Build a basic working model.
4. User Evaluation – Get feedback from users.
5. Refinement – Improve the prototype based on feedback.
6. Final Development – Develop the full software.

Prototype vs. Waterfall: Key Differences

Example

• Prototype Model: Used in gaming, UI/UX design, and AI applications.
• Waterfall Model: Used in military and construction projects.

University Result Management System Design

Consider the problem of a University Result Management System (URMS) to design the following:

1. Problem Statement

A University Result Management System (URMS) is required to efficiently manage student results. The system should allow students, faculty, and administrators to access, update, and analyze results. It must ensure accuracy, security, and easy access to student performance records.

2. Software Requirement Specification (SRS)

2.1 Functional Requirements

• Student Module: View results, request re-evaluation.
• Faculty Module: Upload/edit results, approve modifications.
• Admin Module: Manage users, generate reports, maintain security.
• Authentication & Security: Role-based access control.

2.2 Non-Functional Requirements

• Performance: Fast result retrieval.
• Scalability: Support large student data.
• Security: Encrypted storage, access control.

3. Use Case Diagram

• Actors: Student, Faculty, Admin
• Use Cases:
  • Student: View result, request re-evaluation.
  • Faculty: Upload/edit results, approve requests.
  • Admin: Manage users, generate reports.

(Diagram shows interactions between actors and system functionalities.)

4. Level-1 Data Flow Diagram (DFD)

• Processes: Manage Student, Manage Faculty, Manage Results
• Data Stores: Student DB, Faculty DB, Results DB
• Entities: Student, Faculty, Admin
• Flows: Student requests results → System fetches from Results DB

5. ER Diagram (Entity-Relationship Diagram)

• Entities: Student, Faculty, Admin, Course, Result
• Relationships:
  • Student-Result (1:M) (One student has multiple results)
  • Faculty-Course (M:N) (Faculty teaches multiple courses)
  • Course-Result (1:M) (One course has many results)

(Graphically represents relationships between entities.)

6. Context Diagram

• System: University Result Management System
• External Entities: Student, Faculty, Admin
• Interactions:
  • Student → System (View result)
  • Faculty → System (Enter/edit result)
  • Admin → System (Manage users)

Characteristics of a Good SRS

A well-defined SRS (Software Requirement Specification) ensures the development of high-quality software. The key characteristics of a good SRS include:

1. Correctness

• Every requirement stated in the SRS should be accurate and meet user needs.
• Example: If students need to view results, the system must allow secure result access.

2. Completeness

• The SRS must include all functional and non-functional requirements.
• Example: It should specify how results are calculated, displayed, and stored.

3. Unambiguity

• Requirements should be clearly defined without multiple interpretations.
• Example: Instead of “fast response time,” specify “Response time should be ≤ 2 seconds”.

4. Consistency

• No conflicting requirements should exist within the document.
• Example: One section shouldn’t say “results are stored permanently”, while another states “results are deleted yearly”.

5. Verifiability

• Requirements should be measurable and testable.
• Example: “The system should support 500 concurrent users” is verifiable, while “The system should be user-friendly” is not.

6. Modifiability

• The SRS should be easy to update when requirements change.
• Example: Using a structured format helps developers update sections without affecting the entire document.

7. Traceability

• Each requirement should be uniquely labeled for tracking.
• Example: Using IDs like FR-001 (Functional Requirement 1) ensures clear tracking.

8. Feasibility

• The requirements should be practical and implementable.
• Example: Instead of “The system should predict student performance with 100% accuracy,” define achievable AI-based predictions.

9. Prioritization

• Essential and optional requirements should be categorized.
• Example: “Must-have” (Result display) vs. “Nice-to-have” (Graphical performance analysis).

10. Security & Performance Requirements

• The SRS should address security (e.g., encryption, access control) and performance (e.g., speed, uptime).
• Example: “Data should be encrypted using AES-256 for security.”

Organization of SRS with Case Study (URMS)

A well-structured Software Requirement Specification (SRS) ensures clarity and completeness. Below is its organization with an example of a University Result Management System (URMS).

1. Introduction

• Purpose: Automate student result management for accuracy and efficiency.
• Scope: Allows students to view results, faculty to update them, and admins to manage users.
• Definitions: URMS (University Result Management System), DBMS (Database Management System).
• Constraints: Must handle 10,000+ users, follow university grading rules.

2. Overall Description

• Product Perspective: Replaces manual result processing, integrates with university databases.
• Users:
  • Students – View results.
  • Faculty – Enter/edit results.
  • Admin – Manage database/security.
• Dependencies: Requires stable internet, secure database integration.

3. Specific Requirements

• Functional:
  • FR1: Students can log in to view results.
  • FR2: Faculty can enter/update results.
• Non-Functional:
  • NFR1: Response time ≤ 2 seconds.
  • NFR2: Uses AES-256 encryption for data security.
• Interfaces: Must connect with university database & email system.

4. Appendices

Includes grading policies, report formats, and system diagrams.

Requirement Analysis: Principles & Techniques

Requirement analysis is the process of gathering, understanding, and documenting user needs to ensure the software meets business objectives.

Principles of Requirement Analysis

1. Understand Needs – Identify clear user requirements.
2. Clarity & Completeness – Avoid ambiguity and cover all needs.
3. Feasibility & Prioritization – Ensure requirements are achievable.
4. Consistency – Avoid conflicting requirements.
5. Modifiability – Allow for future changes.
6. Traceability – Link requirements to system functions.
7. Validation – Confirm correctness with stakeholders.

Techniques of Requirement Analysis

1. FAST (Facilitated Application Specification Technique)

• Group-based technique for rapid requirement gathering using brainstorming and workshops.

2. OFD (Object-Oriented Factoring & Decomposition)

• Breaks down requirements into objects and relationships, often using UML diagrams.

COCOMO Model and Data Structure Metrics

The COCOMO (Constructive Cost Model) is used to estimate software development effort, cost, and time based on project size (in KLOC) and other factors.

Types of COCOMO

1. Basic COCOMO: Estimates effort using size (KLOC) with constants for different project types.

   • Formula: Effort (person-months)=a×(KLOC)b ext{Effort (person-months)} = a imes ( ext{KLOC})^b

2. Intermediate COCOMO: Adds cost drivers like complexity, tools, and team experience.

   • Formula: Includes effort multipliers.

3. Detailed COCOMO: Considers phases of software development, giving more granular estimates.

Example (Basic COCOMO)

For a project with 50,000 lines of code (KLOC = 50) and organic project type (a = 2.4, b = 1.05):

• Effort = 2.4 × (50)^1.05 ≈ 126 person-months

Data Structure Metrics

Data structure metrics evaluate the quality of data structures in terms of performance, efficiency, and scalability.

1. Size Metrics: Number of elements or nodes.
2. Complexity Metrics: Operations like search or insert (e.g., O(log n) for a binary search tree).
3. Efficiency Metrics: Memory usage and operation speed (e.g., O(1) for hash tables).
4. Connectivity Metrics: Number of relationships (e.g., vertex degree in a graph).
5. Modularity Metrics: Code reuse and maintainability (e.g., stack or queue).

Information Flow Metrics Explained

Information Flow Metrics measure how data moves between system components, helping analyze system performance, maintainability, and complexity.

Key Metrics

1. Coupling Between Modules (CBM)

   • Measures the interdependence between modules. High coupling can lead to difficult maintenance.
   • Example: If Module A frequently communicates with Module B, they are tightly coupled.

2. Fan-in and Fan-out

   • Fan-in: Number of modules calling a module.
   • Fan-out: Number of modules a module calls.
   • Example: If Module X is called by 5 modules, fan-in = 5; if it calls 3 modules, fan-out = 3.

3. Data Flow

   • Tracks how data moves between components.
   • Example: Data flowing from Module A → Module B → Module C.

4. Data Encapsulation

   • Refers to how data is hidden within modules. High encapsulation improves security and reduces complexity.
   • Example: Using private/public accessors in OOP.

5. Path Length and Complexity

   • Measures how many steps data takes between modules. Shorter paths are more efficient.
   • Example: Direct connection between Module A and Module B is more efficient than a multi-step process.