Introduction to Software Engineering

1. Introduction: FAQs about Software Engineering

Software Engineering is a systematic, disciplined, and quantifiable approach to the

design, development, operation, and maintenance of software.
It applies engineering principles to software development to ensure reliability, efficiency,
and scalability.

Software failures are a consequence of two factors:

1. Increasing system complexity As new software engineering techniques help us to build
larger, more complex systems, the demands change. Systems have to be built and
delivered more quickly; larger, even more complex systems are required; and systems
have to have new capabilities that were previously thought to be impossible. New
software engineering techniques have to be developed to meet new the challenges of
delivering more complex software.

2. Failure to use software engineering methods It is fairly easy to write computer

programs without using software engineering methods and techniques. Many companies
have drifted into software development as their products and services have evolved. They
do not use software engineering methods in their every- day work. Consequently, their
software is often more expensive and less reliable than it should be. We need better
software engineering education and training to address this problem.

Frequently Asked Questions (FAQs):

• What is Software Engineering? → It is the application of engineering practices to software

development.
• Why is Software Engineering important? → It ensures the development of reliable,
efficient, and maintainable software.
• Difference between Software Engineering and Programming? → Programming focuses
only on coding, whereas Software Engineering covers the entire lifecycle of software
(requirements, design, implementation, testing, maintenance).
• What are software process models? → They are structured approaches to software
development (e.g., Waterfall, Agile, Spiral).
• What are common challenges? → Managing complexity, cost, quality, and time.

Software engineers are concerned with developing software products, that

is, software that can be sold to a customer. There are two kinds of software
product:
1. Generic products These are stand-alone systems that are produced by a development organization and
sold on the open market to any customer who is able to buy them. Examples of this type of product
 include apps for mobile devices, software for PCs such as databases, word processors, drawing packages,
and project management tools. This kind of software also includes “vertical” applications designed
for a specific market such as library information systems, accounting systems, or systems for
maintaining dental records.
2. Customized (or bespoke) software These are systems that are commissioned by and developed for a
particular customer. A software contractor designs and implements the software especially for that
customer. Examples of this type of software include control systems for electronic devices, systems
written to support a particular business process, and air traffic control systems.

Attributes of Product

Product characteristic Description

Acceptability Software must be acceptable to the type of users for which it is designed.
This means that it must be understandable, usable, and compatible with
other systems that they use.
Dependability and security Software dependability includes a range of characteristics including
reliability, security, and safety. Dependable software should not cause
physical or economic damage in the event of system failure. Software has
to be secure so that malicious users cannot access or damage the system.

Efficiency Software should not make wasteful use of system resources such as
memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, resource utilization, etc.
Maintainability Software should be written in such a way that it can evolve to meet the
changing needs of customers. This is a critical attribute because software
change is an inevitable requirement of a changing business environment.

Software engineering is important for two reasons:

1. More and more, individuals and society rely on advanced software systems. We need
to be able to produce reliable and trustworthy systems economically and quickly.
2. It is usually cheaper, in the long run, to use software engineering methods and
techniques for professional software systems rather than just write programs as
a personal programming project. Failure to use software engineering
method leads to higher costs for testing, quality assurance, and long-term
maintenance

3. IEEE / ACM Code of Software Engineering Ethics

The IEEE/ACM Code of Ethics provides guidelines for professional conduct in software
engineering. Key principles include:
• Public: Act consistently in the public interest.

• Client and Employer: Act in the best interests of the client and employer, consistent with
public interest.

• Product: Ensure software meets the highest professional standards.

• Judgment: Maintain integrity and independence in professional judgment.

• Management: Promote ethical approaches in software management.

• Profession: Advance the integrity and reputation of the profession.

• Colleagues: Be fair and supportive to colleagues.

• Self: Lifelong learning and ethical practice.

CASE STUDY: Insulin pump control system

Mental Health care system

Weather stations

Refer:
[Link]
ng(Page No. 33-38)

3. Process Activities
The systematic approach that is used in software engineering is sometimes
called a software process. A software process is a sequence of activities that leads
to the production of a software product. Four fundamental activities are common
to all software processes.

The software process includes the following activities:

1. Software Specification – Defining software functionality and constraints.

2. Software Development – Designing and coding the software.

3. Software Validation – Ensuring the software meets requirements.

4. Software Evolution – Modifying software to adapt to changes in requirements or

environment.

Software Specification
Issues of professional responsibility

 Confidentiality
Engineers should normally respect the confidentiality of their employers or clients
irrespective of whether or not a formal confidentiality agreement has been signed.

 Competence
Engineers should not misrepresent their level of competence. They should not
knowingly accept work which is outwith their competence.

 Intellectual property rights

Engineers should be aware of local laws governing the use of intellectual property
such as patents, copyright, etc. They should be careful to ensure that the intellectual
property of employers and clients is protected.

 Computer misuse
Software engineers should not use their technical skills to misuse other people’s
computers. Computer misuse ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious (dissemination of viruses)

4. Requirements Gathering and Analysis

Requirements gathering and analysis is the process of understanding what the stakeholders
need from the software and documenting it properly.
This ensures the system meets user expectations.

4.1 Software Requirements Specification (SRS)

An SRS is a formal document that describes software requirements. It acts as a contract
between the client and developer.

4.2 Functional Requirements

These describe what the system should do. Example: 'The system shall allow users to log in
using a username and password.'

i. Describe functionality or system services.

ii. Depend on the type of software, expected users and the type of system where the
software is used.
iii. Functional user requirements may be high-level statements of what the system should
do.
iii. Functional system requirements should describe the system services in detail.
4.3 Non-Functional Requirements
These define system qualities (performance, security, usability). Example: 'The system shall
respond within 2 seconds.'

4.4 User Requirements

High-level, natural language descriptions of services required by the system,
understandable to end-users.

Definition:
User requirements describe what the user expects the system to do. They are written in
natural language and are understandable by non-technical stakeholders.

Characteristics:

1. Written for end-users, customers, and stakeholders.

2. Focus on goals, tasks, and outcomes rather than technical details.
3 .Non-technical language, avoiding programming or design jargon.
4. Provides the basis for acceptance testing.

Examples

i. The system shall allow users to log in with a username and password.

ii. The system shall allow users to reset their password via email or SMS.

iii. The system shall provide real-time notifications when a new message is received.

iv. The mobile app shall be easy to use and work on both Android and iOS devices.
v. The website shall load within 3 seconds on a standard broadband connection.

4.5 System Requirements

Detailed descriptions of system functions, constraints, and interfaces, written for
developers.

Definition:
System requirements describe what the system must do and how it should perform to meet
user requirements. These can be functional or non-functional.
Characteristics:

 Written for developers, testers, and designers

 Include detailed technical specifications.

 Can be functional (behavior, features) or non-functional (performance, reliability,

security).

 Basis for system design, implementation, and verification

4.6 Interface Specification

Defines how the software interacts with other systems, users, and hardware (APIs, GUI, data
exchange).

Interface specification describes how the software system interacts with external entities,
including users, hardware, other software systems, and communication networks. It defines
the inputs, outputs, and communication methods to ensure proper integration and usability.

5. Characteristics and Components of SRS

Characteristics of a good SRS:

• Correct – All requirements accurately stated.

• Unambiguous – Clear and precise.

• Complete – Covers all requirements.

• Consistent – No conflicting requirements.

• Verifiable – Requirements can be tested.

• Traceable – Each requirement is identifiable.

• Modifiable – Easy to change.

• Feasible – Can be implemented with available resources.

Users of SRS
Ways of writing a system requirements specification

Components of SRS:

1. Introduction

2. Overall description

3. Specific requirements (functional, non-functional)

4. External interface requirements

5. Appendices and glossary

6. Structure of SRS (IEEE Format)

According to IEEE 830 standard, the SRS should contain:

The IEEE standard 830-1998 provides the following structure:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
 2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific Requirements
3.1 Functional requirements
3.2 External interface requirements
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.6 Software system attributes (reliability, availability, security, maintainability,
etc.)
4. Appendices
o Glossary
o Supporting information

Explaination

1. Introduction
 1.1 Purpose: State the purpose of the software and the SRS. Identify intended
audience.
 1.2 Document Conventions: Define notations, symbols, acronyms, formatting
used in the document.
 1.3 Intended Audience and Reading Suggestions: Identify stakeholders like
developers, testers, users, managers.
 1.4 Project Scope: High-level overview of the software, its objectives, benefits,
and business goals.
 1.5 References: List relevant documents, standards, manuals, websites, or papers
used as references.

2. Overall Description

 2.1 Product Perspective: How the system fits in a larger system or environment
(standalone, subsystem, replacement).
 2.2 Product Functions: Summary of main features and functions.
 2.3 User Classes and Characteristics: Types of users and their expertise/needs.
 2.4 Operating Environment: Hardware, software, network, and OS
requirements.
 2.5 Design and Implementation Constraints: Restrictions like programming
language, standards, or regulatory requirements.
  2.6 User Documentation: Manuals, help guides, online resources for users.
 2.7 Assumptions and Dependencies: Factors that affect requirements (e.g.,
availability of third-party APIs, internet, hardware)

3. Specific Requirements

 3.1 Functional Requirements: Detailed, numbered requirements describing

exactly what the system must do.
 3.2 External Interface Requirements:
o User Interface (GUI layouts, screens, menus)
o Hardware Interface (devices, sensors, ports)
o Software Interface (APIs, databases)
o Communication Interface (network protocols, messaging)
 3.3 Performance Requirements: Response times, throughput, concurrency,
efficiency.
 3.4 Security Requirements: Authentication, encryption, authorization, data
integrity.
 3.5 Reliability & Availability Requirements: Uptime, backup, fault tolerance.
 3.6 Maintainability & Portability: Ease of updates, modularity, ability to run on
multiple platforms.

4. Appendices

 Glossary of terms and acronyms

 Supporting diagrams (use case diagrams, data flow diagrams, ER diagrams)
 References to standards, manuals, and external documentation

7. Case Study: SRS for Online Food Ordering System (IEEE Format)

1. Introduction
• Purpose: To develop a system for online food ordering.

• Scope: Customers can browse menus, place orders, make payments, and track delivery.

2. Overall Description
• User classes: Customers, Admin, Delivery staff.

• Assumptions: Users have internet access and smartphones.

3. System Features
• User registration and login.

• Browse restaurant menus.

 • Place, modify, and cancel orders.

• Payment gateway integration.

• Delivery tracking.

4. External Interface Requirements

• Mobile and web-based user interface.

• Integration with payment gateways.

• Delivery staff app integration.

5. Non-Functional Requirements
• Security: Encrypted payment.

• Performance: System should handle 10,000 concurrent users.

• Availability: 24/7 uptime.

6. Other Requirements
• Scalability for adding new restaurants and users.