Software

Engineering
Unit-1
Introduction to S/w Engineering
Table of Content
• Feasibility Study

• Functional & Non- Functional Requirements

• Requirement Gathering

• Requirement Analysis & Specification

• SRS
Feasibility Study in Software
Engineering
Definition
• Analyzes the practicality and viability of a software project.
• Determines whether the project is worth pursuing.

Purpose
• Identifies potential challenges and risks early in the process.
• Ensures that the software project is technically, financially, and
operationally feasible.
• Helps stakeholders make informed decisions about project
initiation.
 Contd.
Importance

• Identifies potential risks and provides a clear roadmap.

• Ensures that resources are used efficiently and effectively.
• Helps to avoid costly project failures.

Types of Feasibility

• Technical Feasibility
• Assesses if the required technology and resources exist.
• Economic Feasibility
• Evaluates cost-benefit analysis and return on investment.
• Legal Feasibility
• Checks compliance with laws, regulations, and contractual obligations.
• Operational Feasibility
• Determines if the project meets user needs and expectations.
• Scheduling Feasibility
• Assesses if the project can be completed on time.
Functional and Non-Functional
Requirements
Importance
• Functional requirements guide system capabilities and scope.
• Non-functional requirements ensure system meets quality standards .

Functional Requirements
• Define the core features and behaviors of the system.

• Focus on what the system should do.

• Examples:
• User login and authentication.
• Data processing and calculations.
• Reporting and data export.
• Interaction with external systems.
 Non-Functional Requirements

• Define system attributes and quality criteria.

• Focus on how the system should perform.

• Examples:
• Performance (e.g. response time, throughput)
• Security (e.g. encryption, user access controls)
• Scalability (e.g. ability to handle growing user base)
• Usability (e.g. user-friendly interface)
• Reliability (e.g. system uptime, fault tolerance)
• Compliance (e.g. legal or regulatory standards)
Difference
Functional Requirements Non-Functional Requirements
• Describes what the system should do i.e. • Describes how the system should perform i.e.
specific functionality or tasks system attribute or quality
• Focuses on the behaviour and features of the • Focuses on the performance, usability, and
system other quality attributes
• Defines the actions and operations of the • Defines constraints or conditions under which
system the system must operate
• User authentication data input/output, • Scalability security, response time, reliability,
transaction processing maintainability
 Requirement Gathering
• Critical phase in the Software Development Life Cycle (SDLC).

• Involves collecting, documenting and managing system

requirements.

• Defines features and functionalities of the system or application.

• Ensures project goals align with stakeholder expectations.

• Accurate requirements are key to project success.

• Completeness of requirements impacts overall software quality.

• Provides a foundation for design and development phases.

 Contd.

Why Requirement Gathering is Important

• Clarity of Project Objectives

• Customer Satisfaction

• Scope Definition

• Reduced Misunderstandings

• Risk Mitigation
 Contd.
Requirement Gathering Process
Step 1: Assigning Roles
• Identify and engage with all relevant project stakeholders.
• Include end-users, clients, and subject matter experts.
• Understand diverse perspectives for comprehensive
requirement gathering.

Step 2: Define Project Scope

• Outline project objectives, boundaries, and limitations
clearly.
• Establish a shared understanding of project goals and
functionalities.
 Contd.
Step 3: Conduct Stakeholder Interviews
• Schedule interviews with key stakeholders for insights.
• Use open-ended questions to uncover explicit and implicit needs.
Step 4: Document Requirements
• Record requirements as user stories, use cases, or specifications.
• Include functional and non-functional requirements in documentation.
Step 5: Verify and Validate Requirements
• Ensure requirements align with stakeholder intentions.
• Validate that requirements meet project goals and objectives.
Step 6: Prioritize Requirements
• Rank requirements by importance and project constraints.
• Create a development roadmap focusing on critical features.
 Contd.

Requirement Gathering Techniques

 Contd.

Requirement Gathering Benefits

• Improved Communication

• Efficient Resource Utilization

• Enhanced Quality

• Risk Management

• Accurate Planning
 Requirement Analysis and specification
Overview of Requirements Analysis and Specification
• Begins after completing the feasibility study phase.
• Ensures project is financially and technically feasible.
• Ends with a reviewed Software Requirements Specification (SRS) document.
• Users often have incomplete system views
• Organizes customer requirements systematically into the SRS document.
• Engineers performing analysis are called analysts
• Goal: Clearly define and document all customer requirements.
 Contd.

Who Performs Requirements Analysis?

• Conducted by experienced development team members.

• Engineers spend time at the customer site.
• System analysts handle requirements gathering and documentation.
• Two main activities:
• Requirements gathering and analysis.
• Requirements specification.

• Requirements Analysis - Problem Identification

• Purpose of Requirements Analysis
Clarify customer requirements and resolve gathered problems.
 Contd.

Problems of Requirement Analysis

• Unclear Stakeholder Needs:
Stakeholders often struggle to define their actual requirements.
• Vague Communication:
Requirements are expressed using ambiguous, domain-specific language.
• Conflicting Requirements:
Different stakeholders may provide contradictory expectations.
• Organizational Influence:
Political and organizational factors can impact requirements.
• Changing Requirements:
Requirements tend to evolve during the analysis phase.
 Requirement Specification
• SRS Document
Requirement collected gets transformed into structure SRS document.
• Define Requirements
It defines the requirements of the proposed system.
• Analysis to Documentation
Analyzed requirement must be clearly documented.
• Clarity for Development
Essential to clarify project development needs.
 Contd.

Software Requirements Specification (SRS)

• Organizes requirements into a structured SRS document

• Serves as a contract between customer and team

• Ensures product meets documented requirements

• Acts as a reference for development

• Specifies external behavior of the system

• Written using end-user terminology

• SRS is designed before going to the design phase.

 Contd.

Properties of a Good SRS

• Concise and free from ambiguity

• Focuses on "what," not "how"

• Easy to modify and well-structured

• Must be consistent and complete

• Should be traceable and verifiable

 Contd.
SRS Document Parts

• Functional Requirements:
Describes system functions and data transformation.
• Non-Functional Requirements:
Reliability, performance, and interface constraints.
• System Constraints:
Standards, hardware, OS, and data compliance.
IEEE format for SRS Document