Unit 1 Introduction to software engineering

 Introduction to software engineering

1. Software is nothing but a set of instruction to acquire input and to manipulate them to produce a desired output.
2. A software is a set of instructions that when executed provide desired output is called software.
 Following are the different types of software:
1. Application Software
2. System Software
3. Network Software

 Engineering :
Engineering is all about developing products using user defined scientific principles and methods is called as
engineering.
 Types of Engineering:
1. Software Engineering
2. Civil Engineering
3. Chemical Engineering
4. Electrical Engineering
5. Mechanical Engineering
6. Computer Engineering
7. Euro space Engineering
8. Auto Mobile Engineering
9. Bio-Medical Engineering
10. Textile Engineering

 Characteristics of Software engineering:

1. Software develop and engineered:
There are similarities between software development and hardware manufacture that is high quality is
achieve through design.
2. Software does not “wear out:
Software is not open to the invar mental component due to the hardware “wear out”.
3. Functionality:
The software meets requirement and specification that it was designed for.
4. Useability:
The software is easy to use and understandable and it provides a positive user experience.
5. Reliability:
The software is free of defect and it perform accurately as per the user requirements.
6. Performance:
The software runs efficiently and accurately .
7. Security:
Software is protected against an outside access and it keeps safe data.
8. Maintainability:
The software is easy to change and update when it is documented.
So, it can be easily understood, installed and modified by other developer or customer.
9. Reusability:
The software can be reuse in other products and applications.
10. Scalability:
The software can handle increasing workload and it can be easily extended to meet the changing
environment.
11. Testability:
The software is design in the way that it meets easy to test and validate.

 Definition of software Engineering:

1. Software engineering is the branch of computer science that deals with the design, development, testing, and
maintenance of software applications.
2. Software engineers apply engineering principles and knowledge of programming languages to build software
solutions for end users.
 3. Software Engineering can design and develop games, entertainment applications, Business applications,
Operating system.
4. SE is consent with development and maintenance of technical products and software solving techniques.
 Need of Software Engineering : (Purpose):
There are following needs that comes under the SE.
1. Handling Big Project:
SE is used to handle big projects like Carbonation.
2. To manage the cost:
SE programs plan everything and reduce all thousand things that are not required.
3. To decrease the time:
It will save the lot of time if you are developing a software using se Technique.
4. Reliable software: It have responsibility to deliver a software product on schedule.
5. Effective ness :
6. Effectiveness results from thing being created with standard.

Requirement engineering and analysis are critical phases in the software development lifecycle. They involve
identifying, documenting, and managing the requirements of a software system to ensure that the final product meets the
needs and expectations of its stakeholders. Here's an overview of the key concepts and processes involved:

Requirements Engineering is the process of identifying, eliciting, analyzing, specifying, validating, and managing
the needs and expectations of stakeholders for a software system.
What is Requirements Engineering?
A systematic and strict approach to the definition, creation, and verification of requirements for a software system is
known as requirements engineering. To guarantee the effective creation of a software product, the requirements
engineering process entails several tasks that help in understanding, recording, and managing the demands of
stakeholders.
Requirements Engineering Process

Requirements Engineering Process

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
1. Feasibility Study
The feasibility study mainly concentrates on below three mentioned areas below. Among these Economic Feasibility
Study is the most important part of the feasibility analysis and the Legal Feasibility Study is less considered feasibility
analysis.
1. Technical Feasibility: In Technical Feasibility current resources both hardware software along required
technology are analyzed/assessed to develop the project. This technical feasibility study reports whether
there are correct required resources and technologies that will be used for project development. Along with
this, the feasibility study also analyzes the technical skills and capabilities of the technical team, whether
existing technology can be used or not, whether maintenance and up-gradation are easy or not for the
chosen technology, etc.
2. Operational Feasibility: In Operational Feasibility degree of providing service to requirements is
analyzed along with how easy the product will be to operate and maintain after deployment. Along with
 this other operational scopes are determining the usability of the product, Determining suggested solution
by the software development team is acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. This
means under this feasibility study a detailed analysis is carried out will be cost of the project for
development which includes all required costs for final development hardware and software resources
required, design and development costs operational costs, and so on. After that, it is analyzed whether the
project will be beneficial in terms of finance for the organization or not.
2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the project domain and requirements. The various
sources of domain knowledge include customers, business manuals, the existing software of the same type, standards,
and other stakeholders of the project. The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does not
produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and
thus helps in providing input to the next stage.
Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a
software system. This is the first step in the requirements engineering process and it is critical to the success of the
software development project. The goal of this step is to understand the problem that the software system is intended
to solve and the needs and expectations of the stakeholders who will use the system.
Several techniques can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather information about their needs
and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather information about their
needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to discuss their needs and
expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work environment to gather
information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system, which can be used
to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize, and prioritize the requirements obtained from all these techniques to ensure that
they are complete, consistent, and accurate.
3. Requirements Specification
This activity is used to produce formal software requirement models. All the requirements including the functional as
well as the non-functional requirements and the constraints are specified by these models in totality. During
specification, more knowledge about the problem may be required which can again trigger the elicitation process. The
models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs),
data dictionaries, etc.
Requirements specification is the process of documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into
manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the requirements for the software
system. This document should be understandable by both the development team and the stakeholders.
Several types of requirements are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user interface.
2. Non-Functional Requirements : These describe how well the software system should do it. They specify
the quality attributes of the system, such as performance, reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered when developing the
software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.
To make the requirements specification clear, the requirements should be written in a natural language and use simple
terms, avoiding technical jargon, and using a consistent format throughout the document. It is also important to use
diagrams, models, and other visual aids to help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders and development team
to ensure that they are complete, consistent, and accurate.
4. Requirements Verification and Validation
Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to
customer requirements. If requirements are not validated, errors in the requirement definitions would propagate to the
successive stages resulting in a lot of modification and rework. The main steps for this process include:
1. The requirements should be consistent with all the other requirements i.e. no two requirements should
conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements verification and validation (V&V) is the process of checking that the requirements for a software
system are complete, consistent, and accurate and that they meet the needs and expectations of the stakeholders. The
goal of V&V is to ensure that the software system being developed meets the requirements and that it is developed on
time, within budget, and to the required quality.
1. Verification is checking that the requirements are complete, consistent, and accurate. It involves reviewing
the requirements to ensure that they are clear, testable, and free of errors and inconsistencies. This can
include reviewing the requirements document, models, and diagrams, and holding meetings and
walkthroughs with stakeholders.
2. Validation is the process of checking that the requirements meet the needs and expectations of the
stakeholders. It involves testing the requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders. This can include testing the software system
through simulation, testing with prototypes, and testing with the final version of the software.
3. Verification and Validation is an iterative process that occurs throughout the software development life
cycle. It is important to involve stakeholders and the development team in the V&V process to ensure that
the requirements are thoroughly reviewed and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and continue throughout the
software development process and even in the maintenance stage.
5. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant stakeholders. This stage takes care of the changing
nature of requirements. It should be ensured that the SRS is as modifiable as possible to incorporate changes in
requirements specified by the end users at later stages too. Modifying the software as per requirements in a systematic
and controlled manner is an extremely important part of the requirements engineering process.
Requirements management is the process of managing the requirements throughout the software development life
cycle, including tracking and controlling changes, and ensuring that the requirements are still valid and relevant. The
goal of requirements management is to ensure that the software system being developed meets the needs and
expectations of the stakeholders and that it is developed on time, within budget, and to the required quality.
Several key activities are involved in requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling changes to the requirements
throughout the development process, including identifying the source of the change, assessing the impact
of the change, and approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the requirements document and other
related artifacts.
3. Traceability: This involves linking the requirements to other elements of the development process, such as
design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated effectively to all
stakeholders and that any changes or issues are addressed promptly.
5. Monitoring and reporting: This involves monitoring the progress of the development process and
reporting on the status of the requirements.
Requirements management is a critical step in the software development life cycle as it helps to ensure that the
software system being developed meets the needs and expectations of stakeholders and that it is developed on time,
within budget, and to the required quality. It also helps to prevent scope creep and to ensure that the requirements are
aligned with the project goals.
Tools Involved in Requirement Engineering
 Observation report
 Questionnaire ( survey, poll )
 Use cases
 User stories
 Requirement workshop
 Mind mapping
  Roleplaying
 Prototyping
Advantages of Requirements Engineering Process
 Helps ensure that the software being developed meets the needs and expectations of the stakeholders
 Can help identify potential issues or problems early in the development process, allowing for adjustments
to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides an unambiguous description of the requirements, which helps to reduce misunderstandings and
errors.
 Helps to identify potential conflicts and contradictions in the requirements, which can be resolved before
the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to the required quality
standards.
 Provides a solid foundation for the development process, which helps to reduce the risk of failure.
Disadvantages of Requirements Engineering Process
 Can be time-consuming and costly, particularly if the requirements-gathering process is not well-managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account
 It Can be challenging to ensure that the requirements are clear, consistent, and complete
 Changes in requirements can lead to delays and increased costs in the development process.
 As a best practice, Requirements engineering should be flexible, adaptable, and should be aligned with the
overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs and priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the requirements.
Activities involved in Software Requirement Analysis



Software requirement means requirement that is needed by software to increase quality of software product. These
requirements are generally a type of expectation of user from software product that is important and need to be
fulfilled by software. Analysis means to examine something in an organized and specific manner to know complete
details about it.
Therefore, Software requirement analysis simply means complete study, analyzing, describing software
requirements so that requirements that are genuine and needed can be fulfilled to solve problem. There are
several activities involved in analyzing Software requirements. Some of them are given below :

1. Problem Recognition :
The main aim of requirement analysis is to fully understand main objective of requirement that includes
why it is needed, does it add value to product, will it be beneficial, does it increase quality of the project,
does it will have any other effect. All these points are fully recognized in problem recognition so that
requirements that are essential can be fulfilled to solve business problems.

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not and synthesis means to create or
form something. Here are some tasks are given that is important in the evaluation and synthesis of software
requirement :
 To define all functions of software that necessary.
  To define all data objects that are present externally and are easily observable.
 To evaluate that flow of data is worth or not.
 To fully understand overall behavior of system that means overall working of system.
 To identify and discover constraints that are designed.
 To define and establish character of system interface to fully understand how system interacts
with two or more components or with one another.
3. Modeling :
After complete gathering of information from above tasks, functional and behavioral models are
established after checking function and behavior of system using a domain model that also known as the
conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the requirement whether it is
functional or non-functional should be developed.

5. Review :
After developing the SRS, it must be reviewed to check whether it can be improved or not and must be
refined to make it better and increase the quality.

SDLC:
The Software Development Life Cycle (SDLC) can be broken down into seven distinct phases, each with its specific
tasks and deliverables. These phases ensure a systematic approach to software development, improving the chances of
delivering a high-quality product that meets customer requirements.
Seven Phases of SDLC

1. Planning
2. Requirement Analysis
3. System Design
4. Implementation (Coding)
5. Integration and Testing
6. Deployment
7. Maintenance

Detailed Description of Each Phase

1. Planning
o Objective: Define the project scope and objectives, estimate costs, and plan resources.
o Activities:
 Feasibility study.
 Project plan creation.
 Resource allocation.
 Risk management.
o Output: Project Plan, Feasibility Study Report.
2. Requirement Analysis
o Objective: Gather and analyze the requirements of the system from stakeholders.
o Activities:
 Stakeholder interviews.
 Requirements gathering through techniques like surveys, observations, and workshops.
 Creating use cases and user stories.
 Documenting requirements.
o Output: Requirements Specification Document (SRS).
3. System Design
o Objective: Design the system architecture and detailed system components.
o Activities:
 High-level design (HLD) and low-level design (LLD).
 Database design.
  User interface design.
 System modeling using UML diagrams.
o Output: System Design Documents, including architecture diagrams, data models, and UI prototypes.
4. Implementation (Coding)
o Objective: Translate the design into code.
o Activities:
 Coding according to the design specifications.
 Code reviews and walkthroughs.
 Unit testing of individual components.
o Output: Source Code, Unit Test Reports.
5. Integration and Testing
o Objective: Integrate the individual components and test the system to ensure it meets the requirements.
o Activities:
 Integrating modules.
 System testing, including functional testing, performance testing, and security testing.
 User acceptance testing (UAT).
 Defect tracking and resolution.
o Output: Test Plans, Test Cases, Test Reports, Defect Logs.
6. Deployment
o Objective: Deploy the system to the production environment for use by end-users.
o Activities:
 Preparing the deployment environment.
 Installing the software.
 Migrating data.
 Conducting user training.
 Preparing deployment documentation.
o Output: Deployed System, User Manuals, Training Materials.
7. Maintenance
o Objective: Provide ongoing support and enhancements to the system after deployment.
o Activities:
 Monitoring system performance.
 Fixing bugs and issues.
 Implementing updates and enhancements.
 Providing user support and training.
o Output: Updated System, Maintenance Reports, Issue Logs.

SDLC Diagram

The steps/phases or activities involved in SDLC are explained below.

#1) Primary Investigation and Feasibility study
Primary investigation which is also termed as preliminary system study is the first stage of system development life
cycle.
During this phase, all the relevant information is collected from the customer to develop a product as per their
expectation. During feasibility study, user determines the overall project scope, including economic, operational and
human factors(technical), identify key personnel, and develop timelines.

#2) Analysis or Requirement Gathering

System Analysis is the process of studying a procedure or business in order to identify its goals and purposes and create
systems and procedures that will achieve them in an efficient way.
Business analyst and Project Manager set up a meeting with the customer to gather all the information like what the
customer wants to build, who will be the end-user, what is the purpose of the product. Before building a product a core
understanding or knowledge of the product is very important.
For Example, A customer wants to have an application which involves money transactions in this case, the requirement
has to be clear like what kind of transactions will be done, how it will be done, in which currency it will be done, etc
Once the requirement is clearly understood, the SRS (Software Requirement Specification) document is created. This
document should be thoroughly understood by the developers and also should be reviewed by the customer for future
reference.

#3) Design
System design refers to the process of planning for a new system or for replacing the existing system.
In simple words, systems analysis describes what the system should do whereas systems design focuses on how to
achieve the objectives.
In this phase, the requirement gathered in the SRS document is used as an input and software architecture that is used for
implementing system development is derived.
All the technical details such as programming languages and environments, machines, packages, application
architecture, distributed architecture layering. memory size, platform, algorithms, data structures, global type definitions.
interfaces, and many other engineering details are established in this design phase.
The output of software design process is design documentation, pseudo codes, detailed logic diagrams, process
diagrams, and detailed description of all functional or non-functional requirements of the software. The system design
specifications serve as input for the next phase of the model.
#4) Implementation or Coding
Implementation/Coding starts once the developer gets the Design document. The Software design is translated into
source code. All the components of the software are implemented in this phase.
#5) Testing
Testing starts once the coding is complete and the modules are released for testing. In this phase, the developed software
is tested thoroughly and any defects found are assigned to developers to get them fixed.
Retesting, regression testing is done until the point at which the software is as per the customer's expectation. Testers
refer SRS document to make sure that the software is as per the customer's standard.

#6) Deployment
Once the product is tested, it is deployed in the production environment or first UAT (User Acceptance testing) is done
depending on the customer expectation.
In the case of UAT, a replica of the production environment is created and the customer along with the developers does
the testing. If the customer finds the application as expected, then sign off is provided by the customer to go live.
#7) Maintenance
After the software is deployed, then its maintenance begins.
Once when the client starts using the developed systems, then the real issues come up
and requirements to be solved from time to time. This procedure where the care is taken for the developed product is
known as maintenance.

System Evaluation: Evaluation is the final check point of the SDLC, it is nothing but feedback of system. There are
three categories of this evaluation:
(1) Developmental Evaluation: This evaluation verifies the development methods and tools used. Also the system is
developed on time and within budget.
(2) Operational Evaluation: This evaluation mainly focused on Response Time of system, user friendliness, Reliability
of computation and adequacy of storage capacity.
(3) User Management Assessment Evaluation: In this evaluation, check how frequently management use the system
and how far they are satisfied with the system.

3.2.2 Advantages of SDLC

A formally defined method for software development in the form of the SDLC achieves a number of benefits:
 Defined communication channels between development teams and stakeholders.
 Clear roles and responsibilities among developers, designers, business analysts, and project managers.
 Clearly-defined inputs and outputs from one step to the next.

Mc Call’s Quality Factor Process

McCall’s Software Quality Model was introduced in 1977. This model is incorporated with many attributes, termed
software factors, which influence software. The model distinguishes between two levels of quality attributes:
 Quality Factors
 Quality Criteria
Quality Factors: The higher-level quality attributes that can be accessed directly are called quality factors. These
attributes are external. The attributes at this level are given more importance by the users and managers.
Quality Criteria: The lower or second-level quality attributes that can be accessed either subjectively or objectively are
called Quality Criteria. These attributes are internal. Each quality factor has many second-level quality attributes or
quality criteria.
Example: The usability quality factor is divided into operability, training, communicativeness, input/output volume, and
input/output rate. This model classifies all software requirements into 11 software quality factors. The 11 factors are
organized into three product quality factors:
Product Operation, Product Revision, and Product Transition.
Factors of Product Quality Diagram:

Product Operation
Product Operation includes five software quality factors, which are related to the requirements that directly affect the
operation of the software such as operational performance, convenience, ease of usage, and correctness. These factors
help in providing a better user experience.
 Correctness: The extent to which software meets its requirements specification.
 Efficiency: The number of hardware resources and code the software, needs to perform a function.
 Integrity: The extent to which the software can control an unauthorized person from accessing the data or
software.
 Reliability: The extent to which software performs its intended functions without failure.
 Usability: The extent of effort required to learn, operate, and understand the functions of the software.
Product Revision
Product Revision includes three software quality factors, which are required for testing and maintenance of the software.
They provide ease of maintenance, flexibility, and testing efforts to support the software to be functional according to
the needs and requirements of the user in the future.
 Maintainability: The effort required to detect and correct an error during maintenance.
 Flexibility: The effort needed to improve an operational software program.
 Testability: The effort required to verify software to ensure that it meets the specified requirements.
Product Transition
Product Transition includes three software quality factors, that allow the software to adapt to the change of environments
in the new platform or technology from the previous.
 Portability: The effort required to transfer a program from one platform to another.
 Re-usability: The extent to which the program’s code can be reused in other applications.
 Interoperability: The effort required to integrate two systems.