MASTER OF COMPUTER APPLICATION

UNIT I
Overview of Software Engineering
✓ Overview of Software ✓ Software requirement
Engineering Specification (SRS)
✓ SDLC models ✓ Structure and contents of
✓ Requirement Engineering SRS
✓ Types of Requirements: - ✓ IEEE SRS Format
Functional and Nonfunctional
✓ Four Phases of Requirement Presenting by
Engineering Prof. Kalyansing Patil
1
 Unit Objective

I. To learn the fundamentals of software Engineering

II. To learn the advantages & disadvantages of SDLC .
III. To learn the different approaches and models of system
development
IV. To learn the fundamentals of Requirement Engineering
V. To understand the basic concept of SRS
VI. To learn the different types of requirements in Software
development .

2
 Introduction to Software Engineering
❖ What is Software Engineering?
The term software engineering is the product of two words, software,
and engineering.
The software is a collection of integrated programs.
Software is an organized instructions and code written by developers
on any of various particular computer languages.
Software Engineering is an engineering branch related to the
evolution of software product using well-defined scientific principles,
techniques, and procedures.

3
 Introduction to Software Engineering
❖ Why is Software Engineering required?
Software Engineering is required due to the following reasons:
To manage Large software
For more Scalability
Cost Management
To manage the dynamic nature of software
For better quality Management

4
 Introduction to Software Engineering
❖ Importance of Software Engineering
Reduces complexity:
To minimize software cost:
To decrease time:
Handling big projects:
Reliable software:
Effectiveness:

5
 Software Development Life Cycle (SDLC)
❖ What is software Life Cycle?
A software life cycle model is a pictorial and diagrammatic
representation of the software life cycle.
A life cycle model maps the various activities performed on a
software product from its beginning to retirement.
Different life cycle models may plan the necessary development
activities to phases in different ways.
A software life cycle model describes entry and exit criteria for each
phase.

6
 Software Development Life Cycle (SDLC)
There are various software development life cycle models specify
and designed which are followed during the software development
process.
Each process model follows a sequence of steps unique to its type to
ensure success in the process of software development.
❖SDLC
❖Waterfall Model
❖Spiral Model
❖ Prototyping Model
❖ RAD
❖ Rational Unified Process

7
 Software Development Life Cycle (SDLC)
❖ What is Software Development Life Cycle (SDLC) ?
SDLC Cycle represents the process of developing software.
SDLC framework includes the following steps:
Planning and requirement analysis
Defining Requirements
Designing the Software
Developing the project
Testing
Deployment
Maintenance

8
 Software Development Life Cycle (SDLC)
❖ What is Software Development Life Cycle (SDLC) ?
Planning and requirement analysis:
Requirement Analysis is the most important and necessary stage in
SDLC.
The senior members of the team perform it.
They will take inputs from all the stakeholders and domain experts.
Planning for the quality assurance requirements and identifications of
the risks associated with the projects.
Once the requirement is understood, the SRS (Software Requirement
Specification) document is created.

9
 Software Development Life Cycle (SDLC)
❖ What is Software Development Life Cycle (SDLC) ?
❖ Defining Requirements:
Requirement Analysis is the most important and necessary stage in
SDLC.
The senior members of the team perform it with inputs from all the
stakeholders and domain experts in the industry.
SRS document which contains all the product requirements to be
constructed and developed during the project life cycle.
❖ Designing the Software
This phase is to bring down all the knowledge of requirements,
analysis, and design of the software project.
This phase is the product of the last two, like inputs from the
customer and requirement gathering.

10
 Software Development Life Cycle (SDLC)
❖ What is Software Development Life Cycle (SDLC) ?
❖ Developing the project(Coding):
In this phase of SDLC, the actual development begins, and the
programming is built.
The Developers have to follow the coding guidelines described by their
management and programming tools like compilers, interpreters,
debuggers, etc. are used to develop and implement the code.
❖ Testing:
After coding phase it is tested against the requirements to make sure that
the products are solving the needs addressed and gathered during the
requirements stage.
During this stage, unit testing, integration testing, system testing,
acceptance testing are done.

11
 Software Development Life Cycle (SDLC)
❖ What is Software Development Life Cycle (SDLC) ?
❖ Deployment :
Once the software is certified, and no bugs or errors are stated, then it
is deployed.
Then based on the assessment, the software may be released as it is
or with suggested enhancement in the object segment.
After the software is deployed, then its maintenance begins.
❖ Maintenance:
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.

12
 Waterfall model
❖ What is Waterfall model ?
Waterfall Model is diagrammatic
representation resembles a cascade of
waterfalls.
❖ This model has five phases:
❖ Requirements analysis and
specification
❖ Design
❖ Implementation & unit testing
❖ Integration and system testing)
❖ Operation and maintenance.
The steps always follow in this order
and do not overlap.

13
 Waterfall model
❖ When to use Waterfall Model?
The use of the Waterfall model is most suited are:
When the requirements are constant and not changed regularly.
A project is short
The situation is calm
Where the tools and technology used is consistent and is not
changing
The resources are well prepared and are available to use.

14
 Waterfall model
❖ Requirements analysis and specification:
The aim of this phase is to understand the exact requirements of the
customer and to document them properly.
Both the customer and the software developer work together to
document all the functions, performance, and interfacing requirement
of the software.
In this phase, a large document called SRS document is created which
contained a detailed description of what the system will do.
❖ Design Phase:
This phase aims to transform the requirements gathered in the SRS
into a suitable form which permits further coding in a programming
language.
It defines the overall software architecture together with high level and
detailed design.
 Waterfall model
❖ Implementation and unit testing:
Software Design Document (SDD) is documented in design phase.
During this phase, design is implemented.
If the SDD is complete, the implementation or coding phase proceeds
smoothly.
During testing, the code is thoroughly examined and modified. Small
modules are tested in isolation initially.
❖ Integration and System Testing:
This phase is highly crucial as the quality of the end product is determined
by the effectiveness of the testing carried out.
The better output will lead to satisfied customers, lower maintenance costs,
and accurate results.
❖ Operation and maintenance phase:
Maintenance is the task performed by every user once the software has been
delivered to the customer, installed, and operational.
16
 Waterfall model
❖ Disadvantages of Waterfall model
▪ The risk factor is very high so that it not suitable for significant and
complex projects.
▪ This model cannot accept the changes in requirements during
development.
▪ It becomes tough to go back to the phase.
▪ The testing done at a later stage, so that it does not allow identifying
the challenges and risks in the earlier phase.
▪ The risk reduction strategy is difficult to prepare.

17
 Spiral Model
❖ What is Spiral Model?
▪ It is a combination of prototype and sequential or waterfall model.
▪ This model was developed by Boehm.
▪ It is used for generating the software projects.
▪ This model is a risk driven process model.
▪ Every phase in the Spiral model is start with a design goal and ends
with the client review.
▪ The development team in this model begins with a small set of
requirements and for the set of requirements team goes through each
development phase.
▪ The development team adds the functionality in every spiral till the
application is ready.
 Spiral Model
Following are the steps involved in spiral model:
 Spiral Model
❖ Planning:
This phase, studies and collects the requirements for continuous
communication between the customer and system analyst.
It involves estimating the cost and resources for the iteration.
❖ Risk Analysis
This phase, identifies the risk and provides the alternate solutions if the
risk is found.
❖ Engineering:
In this phase, actual development i.e coding of the software is completed.
Testing is completed at the end of the phase.
❖ Evaluation
Get the software evaluated by the customers.
They provide the feedback before the project continues to the next spiral.
 Spiral Model
❖ Advantages and Disadvantages of Spiral Model
❖ Advantages of Spiral Model
▪ It reduces high amount of risk.
▪ It is good for large and critical projects.
▪ It gives strong approval and documentation control.
▪ In spiral model, the software is produced early in the life cycle
process.

❖ Disadvantages of Spiral Model

▪ It can be costly to develop a software model.

▪ It is not used for small projects.
 Prototyping Model
❖ What is Prototyping Model?
▪ Prototype methodology is defined as a Software Development model
in which a prototype is built, test, and then reworked when needed
until an acceptable prototype is achieved.
▪ Software prototyping model works best in scenarios where the
project's requirement are not known. It is an iterative.
▪ Prototype model is a set of general objectives for software.
▪ It does not identify the requirements like detailed input, output.
▪ It is software working model of limited functionality.
▪ In this model, working programs are quickly produced.

22
 Prototyping Model
❖ What is Prototyping Model?
▪ Steps of Prototype Model
▪ Requirement Gathering and Analyst
▪ Quick Decision
▪ Build a Prototype
▪ Assessment or User Evaluation
▪ Prototype Refinement
▪ Engineer Product
▪ Requirement Gathering and Analyst:
▪ A prototyping model starts with requirement
analysis.
▪ In this process, the users of the system are
interviewed to know what is their expectation
from the system.

23
 Prototyping Model
❖ What is Prototyping Model?
❖ Quick design :
A simple design of the system is created But it is not a complete design.
It gives a brief idea of the system to the user.
The quick design helps in developing the prototype.
❖ Build a Prototype
An actual prototype is designed based on the information gathered from quick
design.
It is a small working model of the required system.
❖ Initial user evaluation
The proposed system is presented to the client for an initial evaluation.
It helps to find out the strength and weakness of the working model.
Comment and suggestion are collected from the customer and provided to the
developer.

24
 Prototyping Model
❖ What is Prototyping Model?
❖ Refining prototype
If the user is not happy with the current prototype, you need to refine the
prototype according to the user's feedback and suggestions.
This phase will not over until all the requirements specified by the user are
met.
❖ Implement Product and Maintain
Once the final system is developed based on the final prototype, it is
thoroughly tested and deployed to production.

25
 Prototyping Model
❖ Advantages of Prototyping Model:
▪ In the development process of this model users are actively involved.
▪ The development process is the best platform to understand the system
by the user.
▪ Earlier error detection takes place in this model.
▪ It gives quick user feedback for better solutions.
▪ It identifies the missing functionality easily. It also identifies the
confusing or difficult functions.
❖ Disadvantages of Prototyping Model:
▪ The client involvement is more and it is not always considered by the
developer.
▪ It is a slow process because it takes more time for development.
▪ Many changes can disturb the rhythm of the development team.
▪ It is a throw away prototype when the users are confused with it.

26
 Rapid Application Development(RAD)
❖ What is Rapid Application Development (RAD Model)?
Rapid Application Development process(RAD) is an adoption of the
waterfall model.
It targets is developing the software in a short span of time.
RAD follow the iterative.

❖ RAD model has following phases

❖ Business Modeling
❖ Data Modeling
❖ Process Modeling
❖ Application Generation
❖ Testing and Turnover

27
 Rapid Application Development(RAD) What is RAD (Rapid Software Development) Model? Advantages Disadvantages

❖ What is RAD?
▪ It focuses on input-output source and
destination of the information.
▪ It emphasizes on delivering projects in
small pieces.
▪ The larger projects are divided into a
series of smaller projects.
▪ The main features of RAD model are
that it focuses on the reuse of templates,
tools, processes, and code.

28
 Rapid Application Development(RAD)
❖ What are Different phases of RAD model?
❖ Business Modeling:
On basis of the flow of information and distribution between various
business channels, the product is designed
❖ Data Modelling:
The information collected from business modelling is refined into a set of
data objects that are significant for the business
❖ Process Modelling:
The data object that is declared in the data modelling phase is transformed
to achieve the information flow necessary to implement a business
function.
❖ Application Generation:
Automated tools are used for the construction of the software, to convert
process and data models into prototypes.

29
 Rapid Application Development(RAD)
❖ Testing and Turnover
As prototypes are individually tested during every iteration, the overall
testing time is reduced in RAD.
❖ When to use RAD Methodology?
When a system needs to be produced in a short span of time (2-3 months)
When the requirements are known
When the user will be involved all through the life cycle
When technical risk is less
When there is a necessity to create a system that can be modularized in 2-
3 months of time
When a budget is high enough to afford designers for modeling along with
the cost of automated tools for code generation

30
 Rational Unified Process(RUP)
❖ RUP is a software development process.
RUP is inventor is Rational Software Corporation.
It divides the development process into four distinct phases that each
involve business modeling, analysis and design, implementation,
testing, and deployment.
❖ Inception
❖ Elaboration
❖ Construction
❖ Transition
 Rational Unified Process(RUP)
The four phases are:
❖ Inception:
▪ This phase involves following activities….
▪ Requirements understanding & requirements description
▪ Understand the business case of the system being developed
▪ Describes the scope of the system & goals of the system.
❖ Elaboration:
▪ The project's architecture and required resources are further
evaluated.
▪ Refine the requirements
▪ It ensures the constrictions phases like standards, guidelines,
processes & Tools.
▪ Understands of high priority risks.
▪ Elimination of high-quality risks.

32
 Rational Unified Process(RUP)
❖ Construction:
▪ The project is developed and completed.
▪ The software is designed, written, and tested.
▪ Prepare design of the system.
▪ To ensure the successful validation of the customer.
▪ To optimize the resources
▪ To minimize the cost
❖ Transition:
▪ Delivery of the overall system to the customer
▪ Defects findings
▪ System modifications
▪ Product installation & release.
▪ The software is released to the public.
▪ Final adjustments or updates are made based on feedback from
end users.
33
 Rational Unified Process(RUP)
❖ Advantages of RUP:
▪ It is an iterative approach that is better in some situations than a
pure Waterfall approach.
▪ The RUP development methodology provides a structured way for
companies to envision create software programs.
▪ It provides a specific plan for each step of the development
process.
▪ It helps prevent resources from being wasted and reduces
unexpected development costs.
▪ Disadvantages of RUP:
▪ It has a fair amount of overhead and isn’t quite as flexible and
adaptive as Agile
▪ The implementation of RUP is dependent on the Rational tool-set
which is very expensive.
 Introduction to Requirement Engineering

❖ What is Requirement Engineering?

▪ The process to gather the software requirements from client,
analyze and document them is known as Requirement engineering.
▪ The goal of requirement engineering is to develop and maintain
descriptive ‘System Requirements Specification’ document.
❖ Requirement Engineering Process:
▪ It is a four step process, which includes –
▪ Feasibility Study
▪ Requirement Gathering
▪ Software Requirement Specification
▪ Software Requirement Validation

35
Introduction to Requirement Engineering

36
 Introduction to Requirement Engineering
❖ What is Feasibility study?
Feasibility study comes up with rough idea about what all functions
the software must perform and which all features are expected from
the software.
The analysts can do a detailed study about whether the desired
system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization.
This study analyzes whether the software product can be practically
materialized in terms of implementation, contribution of project to
organization, cost constraints and as per values and objectives of the
organization.

37
 Introduction to Requirement Engineering

❖ What is Requirement Gathering?

▪ After feasibility report requirement gathering phase will starts with
gathering requirements from the user.
▪ Analysts and engineers communicate with the client and end-users to
know their ideas on what the software should provide and which
features they want the software to include.

38
 Types of Requirements
❖ What are Types of Requirements ?
According to IEEE standard a requirement is defined as follows:
A condition or capability needed by a user to solve a problem or
achieve an objective.
A condition or capability that must be met or controlled by a system
or system component to satisfy a contract, standard, specification.
▪ Software requirement can be of 3 types:
▪ Functional requirements
▪ Non-functional requirements
▪ Domain requirements

39
 Types of Requirements
❖ What are Types of Requirements ?
▪ Functional Requirements:
These are the requirements that the end user specifically demands as
basic facilities that the system should offer.
All these functionalities need to be necessarily incorporated into the
system as a part of the contract.
They are basically the requirements stated by the user which one can
see directly in the final product, unlike the non-functional
requirements.
Requirements, which are related to functional aspect of software fall
into this category.
They define functions and functionality within and from the software
system.

40
 Types of Requirements

❖ What are Types of Requirements ?

▪ Functional Requirements:
Functional requirements define a function that a system or system
element must be qualified to perform and must be documented in
different forms.
The functional requirements are describing the behavior of the system
as it correlates to the system's functionality.

41
 Types of Requirements
❖ What are Types of Requirements ?
▪ Non-functional requirements:
Requirements which are not related to functional aspect of software,
fall into this category.
They are implicit or expected characteristics of software, which users
make assumption of it
Non-functional requirements include -
Security Cost
Logging Interoperability
Storage Flexibility
Configuration Disaster recovery
Performance Accessibility

42
 Types of Requirements
❖ Non-functional requirements:
Non-functional requirements are divided into two main categories:
Execution qualities:
Execution qualities like security and usability, which are observable at
run time.
Evolution qualities:
Evolution qualities like testability, maintainability, extensibility, and
scalability that alive in the static structure of the software system.

43
 Requirement Elicitation Process
❖ What is Requirements Elicitation ?
▪ Requirements Elicitation is the process to find out the requirements for
software system by communicating with client, end users.
▪ Requirements gathering :
▪ The developers discuss with the client and end users and know their
expectations from the software.
▪ Organizing Requirements :
▪ The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.
 Requirement Elicitation Process
❖ Negotiation & discussion :
▪ If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and
discussed with stakeholders.
▪ Requirements may then be prioritized and reasonably compromised.
▪ The requirements come from various stakeholders.
▪ To remove the ambiguity and conflicts, they are discussed for clarity and
correctness.
▪ Unrealistic requirements are compromised reasonably.
❖ Documentation :
▪ All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.
 Requirement Elicitation Techniques
❖ What are Requirement Elicitation Techniques?
Requirements Elicitation is the process to find out the requirements
for an intended software system by communicating with client, end
users, system users and others in the software system development.
There are various ways to discover requirements
❖ Interviews
Interviews are strong medium to collect requirements. Organization
may conduct several types of interviews such as:
Structured (closed) interviews, where every single
information to gather is decided in advance, they follow
pattern and matter of discussion firmly.
 Requirement Elicitation Techniques
❖ What are Requirement Elicitation Techniques?
Non-structured (open) interviews, where information to gather is not
decided in advance, more flexible and less biased.
Oral interviews
▪ Written interviews
One-to-one interviews which are held between two persons across the
table.
▪ Group interviews which are held between groups of participants.
They help to uncover any missing requirement as numerous people are
involved.
▪ Surveys:
Organization may conduct surveys among various stakeholders by
querying about their expectation and requirements from the upcoming
system
 Requirement Elicitation Techniques
❖ What are Requirement Elicitation Techniques?
❖ Questionnaires:
A document with pre-defined set of objective questions and respective
options is handed over to all stakeholders to answer, which are
collected and compiled.
❖ Task analysis:
Team of engineers and developers may analyze the operation for
which the new system is required.
❖ Domain Analysis:
Every software falls into some domain category.
The expert people in the domain can be a great help to analyze
general and specific requirements.
 Requirement Elicitation Techniques
❖ What are Requirement Elicitation Techniques?
▪ Brainstorming
An informal debate is held among various stakeholders and all their
inputs are recorded for further requirements analysis.
▪ Prototyping:
Prototyping is building user interface without adding detail
functionality for user to interpret the features of intended software
product.
It helps giving better idea of requirements.
▪ Observation
Team of experts visit the client’s organization or workplace.
They observe the actual working of the existing installed systems.
They observe the workflow at client’s end and how execution
problems are distributed.
 Introduction to Requirement Engineering
❖ What is Software Requirement Specification(SRS)?
▪ SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
▪ SRS documentation is the responsibility of system analyst to
document the requirements in technical language.
▪ This is useful and understand by the software development team.
❖ SRS document have following features…….
▪ User Requirements are expressed in natural language.
▪ Technical requirements are expressed in structured language,
which is used inside the organization.
▪ Format of Forms and GUI screen prints.
▪ Conditional and mathematical notations for DFDs etc.
 Introduction to Requirement Engineering
❖ What is Software Requirement Specification(SRS)?
A software requirements specification is the basis for your entire
project.
It lays the framework that every team involved in development will
follow.
It’s used to provide critical information to multiple teams such as
development, quality assurance, operations, and maintenance. This
keeps everyone on the same page.
SRS helps to ensure requirements are fulfilled.
It can also help you make decisions about your product’s lifecycle —
for instance, when to retire a feature.
Writing an SRS can also minimize overall development time and
costs.
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Scope
1.5 Definitions and Acronyms
1.6 References
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Non-functional Requirements
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
Start With a Purpose:
It sets the expectation for the product you’re building.
Start by defining the purpose of your product.

❖ Intended Audience and Intended Use:

Define who in your organization will have access to the SRS.
How they should use it.
This may include developers, testers, and project managers.
It could also include stakeholders in other departments, including
leadership teams, sales, and marketing.
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
❖ Definitions and Abbreviations
It’s smart to include a risk definition.
Avoiding risk is top-of-mind for many developers especially those
working on safety-critical development teams.
Give an Overview of What You’ll Build
Your next step is to give a description of what you’re going to build.
Is it an update to an existing product?
Is it a new product?
Is it an add-on to a product you’ve already created?
You should also describe why you’re building it and who it’s for.
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
▪ User Needs:
User needs are critical.
You will need to define who is going to use the product and how.
Assumptions and Dependencies:
There might be factors that impact your ability to fulfil the
requirements outlined in your SRS.
▪ Detail Your Specific Requirements:
The next section is key for your development team.
This is where you detail the specific requirements for building your
product.
Functional Requirements
Functional requirements are essential to building your product.
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
▪ External Interface Requirements
External interface requirements are types of functional requirements.
They outline how your product will interface with other components.
There are several types of interfaces you may have requirements for,
including:
User
Hardware
Software
Communications
 Introduction to Requirement Engineering
❖ How to Write an SRS Document?
▪ System Features
System features are types of functional requirements.
These are features that are required in order for a system to function.
❖ Non-functional Requirements
▪ Non-functional requirements can be just as important as functional
ones.
▪ These include:
▪ Performance
▪ Safety
▪ Security
▪ Quality
 Introduction to Requirement Engineering
❖ What is Software Requirement Validation?
After SRS documents is developed, the requirements mentioned in
this document are validated.
User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly.
This results in huge increase in cost if not compressed in the bud.
Requirements can be checked against following conditions …
If they can be practically implemented
If they are valid and as per functionality and domain of software.
If there are any ambiguities
If they are complete
If they can be demonstrated