3CS4-05: Software Engineering

Introduction

The term software engineering is composed of two words, software and

engineering.

Software is more than just a program code. A program is an executable code, which
serves some computational purpose. Software is considered to be a collection of
executable programming code, associated libraries and documentations. Software, when
made for a specific requirement is called software product.
Software is defined as:
Instructions + Data Structures + Documents

Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods. Engineering is the branch of science and technology
concerned with the design, building, and use of engines, machines, and structures. It is
the application of science, tools and methods to find cost effective solution to simple
and complex problems.
So, we can define software engineering as an engineering branch associated with
the development of software product using well-defined scientific principles, methods
and procedures. The outcome of software engineering is an efficient and reliable
software product.
OR

Software Engineering is a framework for building software and is an engineering

approach to software development. Software programs can be developed without S/E
principles and methodologies but they are indispensable if we want to achieve good
quality software in a cost effective manner.
IEEE defines software engineering as:
The application of a systematic, disciplined, quantifiable approach to the development,
operation and maintenance of software.

Software Crisis
Software Crisis is a term used in computer science for the difficulty of writing useful
and efficient computer programs in the required time .software crisis was due to using
same workforce, same methods, same tools even though rapidly increasing in software
demand, complexity of software and software challenges. With increase in the
complexity of software, many software problems arise because existing methods were
insufficient.
If we will use same workforce, same methods and same tools after fast increasing in
software demand, software complexity and software challenges, then there arose some
problems like software budget problem, software efficiency problem, software quality
problem, software managing and delivering problem etc. This condition is called software
crisis.
Causes of Software Crisis:

 The cost of owning and maintaining software was as expensive as developing the
software
 At that time Projects was running over-time
 At that time Software was very inefficient
 The quality of software was low quality
 Software often did not meet requirements
 The average software project overshoots its schedule by half
 At that time Software was never delivered

Solution of Software Crisis:

There is no single solution to the crisis.one possible solution of software crisis is Software
Engineering because software engineering is a systematic, disciplined and quantifiable
approach. For preventing software crisis, there are some guidelines:

 Reduction in software over-budget

 The quality of software must be high
 Less time needed for software project
 Experience working team member on software project
 Software must be delivered

Need of Software Engineering

The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working.

 Large software - It is easier to build a wall than to a house or building, likewise,

as the size of software become large engineering has to step to give it a scientific
process.
  Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing
one.

 Cost- As hardware industry has shown its skills and huge manufacturing has
lower down the price of computer and electronic hardware. But the cost of
software remains high if proper process is not adapted.

 Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which the user works. If the nature of software
is always changing, new enhancements need to be done in the existing one. This
is where software engineering plays a good role.

 Quality Management- Better process of software development provides better

and quality software product.

In short, Software engineering is a branch of computer science, which uses well-defined

engineering concepts required to produce efficient, durable, scalable, in-budget and on-
time software products.

SOFTWARE Development LIFE-CYCLE

Software Development Life Cycle (SDLC)

Software development life cycle is a process that produce software with the highest
quality and lowest costs in the shortest time possible.
Proper planning and execution are the key components of a successful software
development process. The entire software development process includes 6
stages. Software Development Life Cycle (SDLC) is the common term to summarize
these 6 stages.
SDLC specifies the task(s) to be performed at various stages by a software
engineer/developer. It ensures that the end product is able to meet the customer’s
expectations and fits in the overall budget. Hence, it’s vital for a software developer to
have prior knowledge of this software development process.

These 6 stages are discussed below.

Stage-1: Planning and Requirement Analysis:

Planning is the crucial step in everything and so as in software development. In this

same stage, requirement analysis is also performed by the developers of the
organization. This is attained from the inputs from the customers, sales
department/market surveys. The information from this analysis forms the building block
of a basic project. The quality proof of the project is a result of planning.
Stage-2: Defining Requirements:

In this stage, all the requirements for the target software are specified. These
requirements get approval from the customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a
sort of a document that specifies all those things that need to be defined and created
during the entire project cycle.

Stage-3: Designing Architecture:

SRS is a reference for software designers to come out with the best architecture for the
software. Hence, with the requirements defined in SRS, multiple designs for the product
architecture are present in the Design Document Specification (DDS).
This DDS is assessed by market analysts and stakeholders. After evaluating all the
possible factors, the most practical and logical design is chosen for the development.
Stage-4: Developing Product:

At this stage, the fundamental development of the product starts. For this, developers
use a specific programming code as per the design in the DDS. Hence, it is important
for the coders to follow the protocols set by the association. Conventional programming
tools like compilers, interpreters, debuggers, etc. are also put into use at this stage.
Some popular languages like C/C++, Python, Java, etc. are put into use as per the
software regulations.

Stage-5: Product Testing and Integration:

After the development of the product, testing of the software is necessary to ensure its
smooth execution. Although, minimal testing is conducted at every stage of SDLC.
Therefore at this stage, all the probable flaws are tracked, fixed, and retested. This
ensures that the product confronts the quality requirements of SRS.

Stage 6: Deployment and Maintenance of Product:

After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. Because it is
important to ensure its smooth performance. If it performs well, the organization sends
out the product as a whole. After retrieving beneficial feedback, the company releases
it as it is or with auxiliary improvements to make it further helpful for the customers.
However, this alone is not enough. Therefore, along with the deployment, the product’s
supervision.
 Life Cycle Model:

 A software life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle.
 A life cycle model represents all the activities required to make a software product
transit through its life cycle phases. It also captures the order in which these
activities are to be undertaken.
 In other words, a life cycle model maps the different activities performed on a
software product from its inception to retirement.
 Different life cycle models may map the basic development activities to phases in
different ways. Thus, no matter which life cycle model is followed, the basic
activities are included in all life cycle models, carried out in different orders in
different life cycle models. During any life cycle phase, more than one activity may
also be carried out.

The Need for a Software Life Cycle Model

 The development team must identify a suitable life cycle model for the particular
project and then adhere to it. Without using of a particular life cycle model the
development of a software product would not be in a systematic and disciplined
manner.
 When a software product is being developed by a team there must be a clear
understanding among team members about when and what to do. Otherwise it
would lead to chaos and project failure. This problem can be illustrated by
using an example.
 Suppose a software development problem is divided into several parts
and the parts are assigned to the team members. From then on, suppose the team
members are allowed the freedom to develop the parts assigned to them in
whatever way they like. It is possible that one member might start writing the
code for his part, another might decide to prepare the test documents first, and
 some other engineer might begin with the design phase of the parts assigned to
him.
 This would be one of the perfect recipes for project failure. A software life
cycle model defines entry and exit criteria for every phase. A phase can start only
if its phase-entry criteria have been satisfied.
 So without software life cycle model the entry and exit criteria for a phase cannot
be recognized.
 Without software life cycle models it becomes difficult for software project
managers to monitor the progress of the project.

Different Software Life Cycle Models

Many life cycle models have been proposed so far. Each of them has some advantages
as well as some disadvantages.
 Classical Waterfall Model
 Iterative Waterfall Model
 Incremental process model
 Prototyping Model
 Evolutionary Model
 Rapid Application Development Model
 Unified Model
 Spiral Model
 Agile Model

1. Classical Waterfall Model

 Classical waterfall model is the basic software development life cycle model.
It is very simple but idealistic.
 Earlier this model was very popular but nowadays it is not used. But it is very
important because all the other software development life cycle models are based
on the classical waterfall model.
 Classical waterfall model divides the life cycle into a set of phases. This model
considers that one phase can be started after completion of the previous phase.
That is the output of one phase will be the input to the next phase.
 Thus the development process can be considered as a sequential flow in the
waterfall.
 Here the phases do not overlap with each other. The different sequential
phases of the classical waterfall model are shown in the below figure:
Feasibility study –

 The main aim of feasibility study is to determine whether it would be

financially and technically feasible to develop the product.
 At first project managers or team leaders try to have a rough understanding of
what is required to be done by visiting the client side. They study different input
data to the system and output data to be produced by the system. They study
what kind of processing is needed to be done on these data and they look at the
various constraints on the behavior of the system.
 After they have an overall understanding of the problem they investigate the
different solutions that are possible. Then they examine each of the solutions in
terms of what kind of resources required, what would be the cost of development
and what would be the development time for each solution.

 Based on this analysis they pick the best solution and determine whether the
solution is feasible financially and technically.

 They check whether the customer budget would meet the cost of the product and
whether they have sufficient technical expertise in the area of development.

Requirements analysis and specification: -

 The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely
- Requirements gathering and analysis
- Requirements specification

- The goal of the requirements gathering activity is to collect all relevant

information from the customer regarding the product to be developed. This is
 done to clearly understand the customer requirements so that incompleteness
and inconsistencies are removed.
 The requirements analysis activity is begun by collecting all relevant data
regarding the product to be developed from the users of the product and from the
customer through interviews and discussions.
- For example, to perform the requirements analysis of a business accounting
software required by an organization, the analyst might interview all the
accountants of the organization to ascertain their requirements. The data
collected from such a group of users usually contain several contradictions and
ambiguities, since each user typically has only a partial and incomplete view of
the system. Therefore it is necessary to identify all ambiguities and
contradictions in the requirements and resolve them through further
discussions with the customer.
 After all ambiguities, inconsistencies, and incompleteness have been
resolved and all the requirements properly understood, the requirements
specification activity can start.
 During this activity, the user requirements are systematically organized into a
Software Requirements Specification (SRS) document.
 The customer requirements identified during the requirements gathering and
analysis activity are organized into a SRS document. The important components
of this document are functional requirements, the nonfunctional requirements, and
the goals of implementation.

Design: -
 The goal of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementation in some
programming language.
  In technical terms, during the design phase the software architecture is derived
from the SRS document. Two distinctly different approaches are available:
the traditional design approach and the object-oriented design approach.
- Traditional design approach -Traditional design consists of two different
activities; first a structured analysis of the requirements specification is carried
out where the detailed structure of the problem is examined. This is followed
by a structured design activity. During structured design, the results of
structured analysis are transformed into the software design.
- Object-oriented design approach -In this technique, various objects that
occur in the problem domain and the solution domain are first identified, and
the different relationships that exist among these objects are identified. The
object structure is further refined to obtain the detailed design.

Coding and unit testing:-

 The purpose of the coding phase (sometimes called the implementation
phase) of software development is to translate the software design into source
code.
 Each component of the design is implemented as a program module. The
end-product of this phase is a set of program modules that have been individually
tested.
 During this phase, each module is unit tested to determine the correct working of
all the individual modules. It involves testing each module in isolation as this is the
most efficient way to debug the errors identified at this stage.

Integration and system testing: -

 Integration of different modules is undertaken once they have been coded and
unit tested.
  During the integration and system testing phase, the modules are integrated in a
planned manner. The different modules making up a software product are almost
never integrated in one shot.
 Integration is normally carried out incrementally over a number of steps. During
each integration step, the partially integrated system is tested and a set of
previously planned modules are added to it. Finally, when all the modules have
been successfully integrated and tested, system testing is carried out.
 The goal of system testing is to ensure that the developed system conforms to
its requirements laid out in the SRS document. System testing usually consists
of three different kinds of testing activities:
 α – testing: It is the system testing performed by the development team.
 β –testing: It is the system testing performed by a friendly set of customers.
 Acceptance testing: It is the system testing performed by the customer himself
after the product delivery to determine whether to accept or reject the delivered
product.

 System testing is normally carried out in a planned manner according to the

system test plan document.
 The system test plan identifies all testing-related activities that must be
performed, specifies the schedule of testing, and allocates resources. It also lists
all the test cases and the expected outputs for each test case.

Maintenance: -
 Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself.
 Many studies carried out in the past confirm this and indicate that the relative
effort of development of a typical software product to its maintenance effort is
 roughly in the 40:60 ratios. Maintenance involves performing any one or more of
the following three kinds of activities:

There are basically three types of maintenance:

 Corrective Maintenance: This type of maintenance is carried out to correct errors
that were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as work on a new computer platform
or with a new operating system.

Advantages of Classical Waterfall Model

Classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered as the basis for other software development life cycle
models. Below are some of the major advantages of this SDLC model:
 This model is very simple and is easy to understand.
 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well understood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before- design, design-before-code.
 This model works well for smaller projects and projects where requirements are
well understood.

Disadvantage of Classical Waterfall Model

Classical waterfall model suffers from various shortcomings, basically we can’t use it in
real projects, but we use other software development lifecycle models which are based
on the classical waterfall model. Below are some major drawbacks of this model:
  No feedback path: In classical waterfall model evolution of a software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed
by developers during any phases. Therefore, it does not incorporate any mechanism
for error correction.
 Difficult to accommodate change requests: This model assumes that all the
customer requirements can be completely and correctly defined at the beginning of
the project, but actually customers’ requirements keep on changing with time. It is
difficult to accommodate any change requests after the requirements specification
phase is complete.
 No overlapping of phases: This model recommends that new phase can start
only after the completion of the previous phase. But in real projects, this can’t be
maintained. To increase the efficiency and reduce the cost, phases may overlap.

2. Iterative Waterfall Model

To overcome the major shortcomings of the classical waterfall model, we

come up with the iterative waterfall model.

 In a practical software development project, the classical waterfall model is hard

to use. So, Iterative waterfall model can be thought of as incorporating the
necessary changes to the classical waterfall model to make it usable in practical
software development projects.
 It is almost same as the classical waterfall model except some changes are made
to increase the efficiency of the software development.
 The iterative waterfall model provides feedback paths from every phase to
its preceding phases, which is the main difference from the classical waterfall
model.
 Feedback paths introduced by the iterative waterfall model are shown
in the figure below.
 Iterative Waterfall Model

 When errors are detected at some later phase, these feedback paths allow
correcting errors committed by programmers during some phase.
 The feedback paths allow the phase to be reworked in which errors are committed
and these changes are reflected in the later phases.
 But, there is no feedback path to the stage – feasibility study, because
once a project has been taken, does not give up the project easily.
It is good to detect errors in the same phase in which they are committed. It
reduces the effort and time required to correct the errors.
Phase Containment of Errors: The principle of detecting errors as close to their
points of commitment as possible is known as Phase containment of errors.

Advantages of Iterative Waterfall Model

 Feedback Path: In the classical waterfall model, there are no feedback paths, so
there is no mechanism for error correction. But in iterative waterfall model feedback
 path from one phase to its preceding phase allows correcting the errors that are
committed and these changes are reflected in the later phases.
 Simple: Iterative waterfall model is very simple to understand and use. That’s why
it is one of the most widely used software development models.

Disadvantage of Iterative Waterfall Model

 Difficult to incorporate change requests: The major drawback of the iterative

waterfall model is that all the requirements must be clearly stated before starting of
the development phase. Customer may change requirements after some time but
the iterative waterfall model does not leave any scope to incorporate change
requests that are made after development phase starts.

 Incremental delivery not supported: In the iterative waterfall model, the full
software is completely developed and tested before delivery to the customer. There
is no scope for any intermediate delivery. So, customers have to wait long for getting
the software.
 Overlapping of phases not supported: Iterative waterfall model assumes that
one phase can start after completion of the previous phase, but in real projects,
phases may overlap to reduce the effort and time needed to complete the project.

 Risk handling not supported: Projects may suffer from various types of risks.
But, Iterative waterfall model has no mechanism for risk handling.

 Limited customer interactions: Customer interaction occurs at the start of the

project at the time of requirement gathering and at project completion at the time
of software delivery. These fewer interactions with the customers may lead to many
problems as the finally developed software may differ from the customers’ actual
requirements.
3.Incremental process model
Incremental process model is also know as Successive version model.
 First, a simple working system implementing only a few basic features is built and
then that is delivered to the customer.
 Then thereafter many successive iterations/ versions are implemented and
delivered to the customer until the desired system is released.

A, B, C are modules of Software Product that are incrementally developed and delivered.

Life cycle activities –

 Requirements of Software are first broken down into several modules that can be
incrementally constructed and delivered.
 At any time, the plan is made just for the next increment and not for any kind of
long term plans. Therefore, it is easier to modify the version as per the need of
the customer.
 Development Team first undertakes to develop core features (these do not need
services from other features) of the system.
 Once the core features are fully developed, then these are refined to increase
levels of capabilities by adding new functions in Successive versions.
 Each incremental version is usually developed using an iterative waterfall model of
development.
 As each successive version of the software is constructed and delivered, now the
feedback of the Customer is to be taken and these were then incorporated in the
next version. Each version of the software have more additional features over the
previous ones.
  After Requirements gathering and specification, requirements are then spitted into
several different versions starting with version-1, in each successive increment,
next version is constructed and then deployed at the customer site. After the last
version (version n), it is now deployed at the client site.
Types of Incremental model –

1. Staged Delivery Model – Construction of only one part of the project at a time.
 2. Parallel Development Model – Different subsystems are developed at the same
time. It can decrease the calendar time needed for the development, i.e. TTM
(Time to Market), if enough Resources are available.

When to use this –

1. Funding Schedule, Risk, Program Complexity, or need for early realization of

benefits.
2. When Requirements are known up-front.
3. When Projects having lengthy developments schedules.
4. Projects with new Technology.

Advantages –

 Error Reduction (core modules are used by the customer from the beginning of
the phase and then these are tested thoroughly)
 Uses divide and conquer for breakdown of tasks.
 Lowers initial delivery cost.
 Incremental Resource Deployment.
Disadvantages –
 Requires good planning and design.

 Total cost is not lower.

 Well defined module interfaces are required.

4. PRTOTYPING MODEL

Prototype

 A prototype is a toy implementation of the system. A prototype usually exhibits

limited functional capabilities, low reliability, and inefficient performance compared
to the actual software.
 A prototype is usually built using several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy functions.
 The shortcut implementation of a function, for example, may produce the desired
results by using a table look-up instead of performing the actual computations. A
prototype usually turns out to be a very crude version of the actual system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input
data formats, messages, reports, and the interactive dialogues to the customer. This is
a valuable mechanism for gaining better understanding of the customer’s
needs:

 how the screens might look like

 how the user interface would behave
 how the system would produce outputs

 Another reason for developing a prototype is that it is impossible to get the

perfect product in the first attempt.
  Many researchers and engineers advocate that if you want to develop a good
product you must plan to throw away the first version. The experience gained in
developing the prototype can be used to develop the final product.
 A prototyping model can be used when technical solutions are unclear to the
development team. A developed prototype can help engineers to critically examine
the technical issues associated with the product development.
 Often, major design decisions depend on issues like the response time of a
hardware controller, or the efficiency of a sorting algorithm, etc. In such
circumstances, a prototype may be the best or the only way to resolve the
technical issues.

A prototype of the actual product is preferred in situations such as:

• User requirements are not complete

• Technical issues are not clear
Phases of Prototyping Model –
The Prototyping Model of software development is graphically shown in the figure below.
The software is developed through two major activities – one is prototype
construction and another is iterative waterfall based software development.
 Prototype Development – Prototype development starts with an initial
requirements gathering phase.
 A quick design is carried out and a prototype is built. The developed prototype
is submitted to the customer for evaluation.
 Based on the customer feedback, the requirements are refined and the
prototype is suitably modified. This cycle of obtaining customer feedback and
modifying the prototype continues till the customer approves the prototype.
  Iterative Development – Once the customer approves the prototype, the actual
software is developed using the iterative waterfall approach.

 In spite of the availability of a working prototype, the SRS document is usually

needed to be developed since the SRS Document is invaluable for carrying out
tractability analysis, verification and test case design during later phases.
 The code for the prototype is usually thrown away. However, the experience
gathered from developing the prototype helps a great deal in developing the actual
software.
 By constructing the prototype and submitting it for user evaluation, many customer
requirements get properly defined and technical issues get resolved by
experimenting with the prototype. This minimizes later change requests from the
customer and the associated redesign costs.

Prototyping: advantages
 The resulting software is usually more usable
 User needs are better accommodated
 The design is of higher quality
 The resulting software is easier to maintain
 Overall, the development incurs less cost
Prototyping: disadvantages
 For some projects, it is expensive
 Susceptible to over-engineering:
 Designers start to incorporate sophistications that they could not incorporate in
the prototype.
5. Evolutionary Model

 Evolutionary model is a combination of Iterative and Incremental

model of software development life cycle. Delivering your system in a big bang
release, delivering it in incremental process over time is the action done in this
model. Some initial requirements and architecture envisioning need to be done.

 It is better for software products that have their feature sets redefined during
development because of user feedback and other factors.

 The Evolutionary development model divides the development cycle into

smaller, incremental waterfall models in which users are able to get access to the
product at the end of each cycle.

 Feedback is provided by the users on the product for the planning stage of the
next cycle and the development team responds, often by changing the product,
plan or process. Therefore, the software product evolves with time.

 All the models have the disadvantage that the duration of time from start
of the project to the delivery time of a solution is very high. Evolutionary
model solves this problem in a different approach.
 Evolutionary model suggests breaking down of work into smaller chunks,
prioritizing them and then delivering those chunks to the customer one by one.
 The number of chunks is huge and is the number of deliveries made to the
customer.
 The main advantage is that the customer’s confidence increases as he
constantly gets quantifiable goods or services from the beginning of the project to
verify and validate his requirements.
 The model allows for changing requirements as well as all work in broken down
into maintainable work chunks.
Application of Evolutionary Model:

1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants to
start using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.

Advantages:

 In evolutionary model, a user gets a chance to experiment partially developed

system.
 It reduces the error because the core modules get tested thoroughly.
 Helps finding exact user requirements:- Software more likely to meet exact user
requirements.
 Core modules get tested thoroughly: - Reduces chances of errors in final delivered
software
 Better management of complexity by developing one increment at a time.
 Better management of changing requirements.
 Can get customer feedback and incorporate them much more efficiently

Disadvantages:

 The process is intangible: No regular, well-defined deliverables.

 The process is unpredictable: Hard to manage, e.g., scheduling, workforce
allocation, etc.
 Systems are rather poorly structured: Continual, unpredictable changes tend to
degrade the software structure.
  Systems may not even converge to a final version.
 Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and delivered.

6. Rapid Application Development (RAD) model

 The RAD (Rapid Application Development) model is based on prototyping

and iterative development with no specific planning involved.
 The process of writing the software itself involves the planning required for
developing the product. This model was first proposed by IBM in 1980.
 Rapid Application Development focuses on gathering customer requirements
through workshops or focus groups, early testing of the prototypes by the
customer using iterative concept, reuse of the existing prototypes (components),
continuous integration and rapid delivery.
What is RAD?
 Rapid application development is a software development methodology that uses
minimal planning in favor of rapid prototyping.
 A prototype is a working model that is functionally equivalent to a component of
the product.
 In the RAD model, the functional modules are developed in parallel as prototypes
and are integrated to make the complete product for faster product delivery.
 Since there is no detailed preplanning, it makes it easier to incorporate the
changes within the development process.
 The most important aspect for this model to be successful is to make sure that
the prototypes developed are reusable.

An RAD process model

• Having a short development cycle
• High-speed adoption of the waterfall model using a component based construction
approach
• Creates a fully functional system within a very short span time of 60 to 90 days
The software project which we can break into modules can use this RAD
model. Development of each module requires basics SDLC steps like waterfall steps.

RAD Model Design

RAD model distributes the analysis, design, build and test phases into a series of short,
iterative development cycles.
Following are the various phases of the RAD Model −
Business Modelling
 The business model for the product under development is designed in terms of
flow of information and the distribution of information between various business
channels.
 A complete business analysis is performed to find the vital information for
business, how it can be obtained, how and when is the information processed and
what are the factors driving successful flow of information.
Data Modelling
 The information gathered in the Business Modelling phase is reviewed and
analyzed to form sets of data objects vital for the business.
 The attributes of all data sets is identified and defined. The relation between these
data objects are established and defined in detail in relevance to the business
model.
Process Modelling
 The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.
  The process model for any changes or enhancements to the data object sets is
defined in this phase. Process descriptions for adding, deleting, retrieving or
modifying a data object are given.
Application Generation
 The actual system is built and coding is done by using automation tools to convert
process and data models into actual prototypes.
Testing and Turnover
 The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration.
 However, the data flow and the interfaces between all the components need to
be thoroughly tested with complete test coverage.
 Since most of the programming components have already been tested, it reduces
the risk of any major issues.

The following illustration describes the RAD Model in detail.

RAD Model - Application
RAD model can be applied successfully to the projects in which clear modularization is
possible. If the project cannot be broken into modules, RAD may fail.

The following pointers describe the typical scenarios where RAD can be used
 RAD should be used only when a system can be modularized to be delivered in an
incremental manner.
 It should be used if there is a high availability of designers for Modelling.
 It should be used only if the budget permits use of automated code generating
tools.
 RAD SDLC model should be chosen only if domain experts are available with
relevant business knowledge.
 Should be used where the requirements change during the project and working
prototypes are to be presented to customer in small iterations of 2-3 months.

The advantages of the RAD Model are as follows −

 Changing requirements can be accommodated.
 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of integration issues.
The disadvantages of the RAD Model are as follows −
 Dependency on technically strong team members for identifying business
requirements.
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modelling skills.
 Inapplicable to cheaper projects as cost of Modelling and automated code
generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

7. The Unified Process

 Evolved by Rumbaugh, Booch, and Jacobson. Combines the best features their OO
models. Adopts additional features proposed by other experts. Resulted in Unified
Modeling Language (UML). A framework for Object-Oriented Software
Engineering using UML.

Phases Of Unified Process

• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase
Inception:
The primary goal of the Inception phase is to establish the case for the viability of the
proposed system.

The tasks that a project team performs during Inception include the
following:

 Defining the scope of the system (that is, what's in and what's out)

 Outlining a candidate architecture, which is made up of initial versions of six

different models

 Identifying critical risks and determining when and how the project will address
them

 Starting to make the business case that the project is worth doing, based on initial
estimates of cost, effort, schedule, and product quality

The major milestone associated with the Inception phase is called Life-Cycle
Objectives. The indications that the project has reached this milestone
include the following:
  The major stakeholders agree on the scope of the proposed system.

 The candidate architecture clearly addresses a set of critical high-level

requirements.

 The business case for the project is strong enough to justify a green light for
continued development.

Elaboration:

The primary goal of the Elaboration phase is to establish the ability to build the new
system given the financial constraints, schedule constraints, and other kinds of
constraints that the development project faces.
The tasks that a project team performs during Elaboration include the
following:

 Capturing a healthy majority of the remaining functional requirements

 Expanding the candidate architecture into a full architectural baseline, which is

an internal release of the system focused on describing the architecture

 Addressing significant risks on an ongoing basis

 Finalizing the business case for the project and preparing a project plan that
contains sufficient detail to guide the next phase of the project (Construction)

The architectural baseline contains expanded versions of the six models initialized during
the Inception phase.

The major milestone associated with the Elaboration phase is called Life-Cycle
Architecture. The indications that the project has reached this milestone include the
following:

 Most of the functional requirements for the new system have been captured in the
use case model.

 The architectural baseline is a small, skinny system that will serve as a solid
foundation for ongoing development.

 The business case has received a green light, and the project team has an initial
project plan that describes how the Construction phase will proceed.
Construction:

The primary goal of the Construction phase is to build a system capable of operating
successfully in beta customer environments.

During Construction, the project team performs tasks that involve building the system
iteratively and incrementally, making sure that the viability of the system is always
evident in executable form.

The major milestone associated with the Construction phase is called Initial
Operational Capability. The project has reached this milestone if a set of beta
customers has a more or less fully operational system in their hands.

Transition:

The primary goal of the Transition phase is to roll out the fully functional system to
customers.

During Transition, the project team focuses on correcting defects and modifying the
system to correct previously unidentified problems.

The major milestone associated with the Transition phase is called Product Release.

8. Spiral Model

 Proposed by Boehm in 1988. Spiral model is one of the most important

Software Development Life Cycle models, which provides support for
Risk Handling.
 In its diagrammatic representation, it looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to project.
 Each loop of the spiral is called a Phase of the software development process. The
exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks.
 As the project manager dynamically determines the number of phases, so the
project manager has an important role to develop a product using the spiral model.
  The Radius of the spiral at any point represents the expenses (cost) of the project
so far, and the angular dimension represents the progress made so far in the
current phase.

The below diagram shows the different phases of the Spiral Model: –

 Each phase of the Spiral Model is divided into four quadrants as shown in the
above figure. The functions of these four quadrants are discussed below-

Objectives determination and identify alternative solutions:

 Requirements are gathered from the customers and the objectives are identified,
elaborated, and analyzed at the start of every phase.
 Then alternative solutions possible for the phase are proposed in this quadrant.
Identify and resolve Risks:

 During the second quadrant, all the possible solutions are evaluated to select the
best possible solution.
 Then the risks associated with that solution are identified and the risks are resolved
using the best possible strategy.
 At the end of this quadrant, the Prototype is built for the best possible solution.

Develop next version of the Product:

 During the third quadrant, the identified features are developed and verified
through testing.
 At the end of the third quadrant, the next version of the software is available.

Review and plan for the next Phase:

 In the fourth quadrant, the Customers evaluate the so far developed version of
the software. In the end, planning for the next phase is started.

Risk Handling in Spiral Model

 A risk is any adverse situation that might affect the successful completion of a
software project.
 The most important feature of the spiral model is handling these unknown risks
after the project has started.
 Such risk resolutions are easier done by developing a prototype. The spiral model
supports coping up with risks by providing the scope to build a prototype at every
phase of the software development.
 The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project.
 But in real life project risk may occur after the development work starts, in that
case, we cannot use the Prototyping Model.
  In each phase of the Spiral Model, the features of the product dated and analyzed,
and the risks at that point in time are identified and are resolved through
prototyping. Thus, this model is much more flexible compared to other SDLC
models.

Why Spiral Model is called Meta Model?

 The Spiral model is called a Meta-Model because it subsumes all the other
SDLC models.
 For example, a single loop spiral actually represents the Iterative
Waterfall Model.
 The spiral model incorporates the stepwise approach of the Classical
Waterfall Model.
 The spiral model uses the approach of the Prototyping Model by building a
prototype at the start of each phase as a risk-handling technique.
 Also, the spiral model can be considered as supporting the Evolutionary model
– the iterations along the spiral can be considered as evolutionary levels through
which the complete system is built.

Advantages of Spiral Model:

Below are some advantages of the Spiral Model.

Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the
risk analysis and risk handling at every phase.

Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
Flexibility in Requirements: Change requests in the Requirements at later phase can
be incorporated accurately by using this model.

Customer Satisfaction: Customer can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using
it before completion of the total product.

Disadvantages of Spiral Model:

Below are some main disadvantages of the spiral model.

Complex: The Spiral Model is much more complex than other SDLC models.

Expensive: Spiral Model is not suitable for small projects as it is expensive.

Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts, it is
going to be a failure to develop a project using this model.

Difficulty in time management: As the number of phases is unknown at the start of

the project, so time estimation is very difficult.

9. Agile Model

 Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by rapid
delivery of working software product.
 Agile Methods break the product into small incremental builds. These
builds are provided in iterations. Each iteration typically lasts from about one to
three weeks.
 Customer Interaction is the backbone of this Agile methodology, and open
communication with minimum documentation are the typical features of Agile
 development environment. The agile teams work in close collaboration with each
other and are most often located in the same geographical location.
 Agile uses an adaptive approach where there is no detailed planning and there
is clarity on future tasks only in respect of what features need to be developed.
 There is feature driven development and the team adapts to the changing
product requirements dynamically.
 The product is tested very frequently, through the release iterations, minimizing
the risk of any major failures in future.

 Every iteration involves cross functional teams working simultaneously

on various areas like −

 Planning
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important
stakeholders.

What is Agile?

 Agile model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements.

 In Agile, the tasks are divided to time boxes (small time frames) to deliver
specific features for a release.

 Iterative approach is taken and working software build is delivered after each
iteration.
  Each build is incremental in terms of features; the final build holds all the
features required by the customer.

Here is a graphical illustration of the Agile Model –

 The Agile thought process had started early in the software development and
started becoming popular with time due to its flexibility and adaptability.
 The most popular Agile methods include Rational Unified Process (1994),
Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software
Development, Feature Driven Development, and Dynamic Systems Development
Method (DSDM) (1995).
 These are now collectively referred to as Agile Methodologies, after the Agile
Manifesto was published in 2001.
Following are the Agile Manifesto principles −
 Individuals and interactions − In Agile development, self-organization and
motivation are important, as are interactions like co-location and pair
programming.
 Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of
just depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely
in the beginning of the project due to various factors, continuous customer
interaction is very important to get proper product requirements.
 Responding to change − Agile Development is focused on quick responses to
change and continuous development.

The advantages of the Agile Model are as follows −

 It is a very realistic approach to software development.
 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and extensibility.
 An overall plan, an agile leader and agile PM practice is a must without which it
will not work.
 Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
 Depends heavily on customer interaction, so if customer is not clear, team can be
driven in the wrong direction.
 There is a very high individual dependency, since there is minimum documentation
generated.
 Transfer of technology to new team members may be quite challenging due to
lack of documentation.

V-Model

 V-Model also referred to as the Verification and Validation Model. In this,

each phase of SDLC must complete before the next phase starts.
 It follows a sequential design process same as the waterfall model. Testing of the
device is planned in parallel with a corresponding stage of development.
Verification:
It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified
requirements meet.
Validation:
 It involves dynamic analysis method (functional, non-functional), testing is done
by executing code.
 Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer
expectations and requirements.
 So V-Model contains Verification phases on one side of the Validation phases on
the other side.
 Verification and Validation process is joined by coding phase in V-
shape. Thus it is known as V-Model.

There are the various phases of Verification Phase of V-model:
1. Business requirement analysis: This is the first step where product
requirements understood from the customer's side. This phase contains detailed
communication to understand customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements document.
3. Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief functionality of
each module, their interface relationships, dependencies, database tables,
architecture diagrams, technology detail, etc. The integration testing model is
carried out in a particular phase.
 4. Module Design: In the module design phase, the system breaks down into small
modules. The detailed design of the modules is specified, which is known as Low-
Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the
requirements, a suitable programming language is decided. There are some
guidelines and standards for coding. Before checking in the repository, the final
build is optimized for better performance, and the code goes through many code
reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the
module design phase. These UTPs are executed to eliminate errors at code level
or unit level. A unit is the smallest entity which can independently exist, e.g., a
program module. Unit testing verifies that the smallest entity can function correctly
when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and tested
independently can coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase.
Unlike Unit and Integration Test Plans, System Tests Plans are composed by the
client?s business team. System Test ensures that expectations from an application
developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement
analysis part. It includes testing the software product in user atmosphere.
Acceptance tests reveal the compatibility problems with the different systems,
which is available within the user atmosphere. It conjointly discovers the non-
 functional problems like load and performance defects within the real user
atmosphere.
When to use V-Model?
o When the requirement is well defined and not ambiguous.
o The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are
available with essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall
model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes
of the software are produced.
4. If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.
5. Does not support overlapping of phases
6. Does not easily accommodate later changes to requirements
7. Does not provide support for effective risk handling

Verification and Validation

Verification and Validation is the process of investigating that a software system satisfies
specifications and standards and it fulfills the required purpose. Barry
Boehm described verification and validation as the following:

Verification: Are we building the product right?

Validation: Are we building the right product?
Verification:

Verification is the process of checking that a software achieves its goal without any bugs.
It is the process to ensure whether the product that is developed is right or not.
It verifies whether the developed product fulfills the requirements that we have.
Verification is Static Testing.

Activities involved in verification:

1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking

Validation:
Validation is the process of checking whether the software product is up to the mark or
in other words product has high level requirements. It is the process of checking the
validation of product i.e. it checks what we are developing is the right product.
It is validation of actual and expected product. Validation is the Dynamic Testing.
Activities involved in validation:

1. Black box testing

2. White box testing
3. Unit testing
4. Integration testing

Verification and Validation Differences:

 Verification Validation

Are we building the system right? Are we building the right system?

Verification is the process of evaluating Validation is the process of evaluating

products of a development phase to find out software at the end of the development
whether they meet the specified process to determine whether software meets
requirements. the customer expectations and requirements.

The objective of Verification is to make sure The objective of Validation is to make sure
that the product being develop is as per the that the product actually meet up the user’s
requirements and design specifications. requirements, and check whether the
specifications were correct in the first place.

Following activities are involved Following activities are involved in Validation:

in Verification: Reviews, Meetings and Testing like black box testing, white box
Inspections. testing, gray box testing etc.

Verification is carried out by QA team to Validation is carried out by testing team.

check whether implementation software is as
per specification document or not.

Execution of code is not comes Execution of code is comes under Validation.

under Verification.

Verification process explains whether the Validation process describes whether the
outputs are according to inputs or not. software is accepted by the user or not.

Verification is carried out before the Validation activity is carried out just after the
Validation. Verification.

Following items are evaluated Following item is evaluated during Validation:

during Verification: Plans, Requirement Actual product or Software under test.
Specifications, Design Specifications, Code,
Test Cases etc,

Cost of errors caught in Verification is less Cost of errors caught in Validation is more
than errors found in Validation. than errors found in Verification.

It is basically manually checking the of It is basically checking of developed program

documents and files like requirement based on the requirement specifications
specifications etc. documents & files.

Verification is also known as static testing. Validation is also known as dynamic testing.

Quality assurance comes under verification Quality control comes under validation
testing. testing.

Verification is done before the validation After verification testing, validation testing
testing. takes place.
 Software requirements specification

 Before we start to develop our software, it becomes quite essential for us to

understand and document the exact requirement of the customer.
 Experienced members of the development team carry out this job. They are called
as system analysts.
 The analyst starts requirements gathering and analysis activity by collecting
all information from the customer which could be used to develop the requirements
of the system.
 He then analyzes the collected information to obtain a clear and thorough
understanding of the product to be developed, with a view to remove all
ambiguities and inconsistencies from the initial customer perception of the
problem.
The following basic questions pertaining to the project should be clearly
understood by the analyst in order to obtain a good grasp of the problem:
• What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what exactly are the data output
by the system?
• What are the likely complexities that might arise while solving the problem?
• If there are external software or hardware with which the developed software has to
interface, then what exactly would the data interchange formats with the external
system be?

After the analyst has understood the exact customer requirements, he

proceeds to identify and resolve the various requirements problems.
  The most important requirements problems that the analyst has to identify
and eliminate are the problems of anomalies, inconsistencies, and incompleteness.
 When the analyst detects any inconsistencies, anomalies or incompleteness in the
gathered requirements, he resolves them by carrying out further discussions with
the end-users and the customers.
 The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called
a requirements document).
 This report lays a foundation for software engineering activities and is constructing
when entire requirements are elicited and analyzed.
 SRS is a formal report, which acts as a representation of software that enables
the customers to review whether it (SRS) is according to their requirements.
 Also, it comprises user requirements for a system as well as detailed specifications
of the system requirements.
 The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment.
 It serves several goals depending on who is writing it. First, the SRS could be
written by the client of a system. Second, the SRS could be written by a developer
of the system.
 The two methods create entirely various situations and establish different purposes
for the document altogether.
 The first case, SRS, is used to define the needs and expectation of the users.
 The second case, SRS, is written for various purposes and serves as a
contract document between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:
1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system.
2. Completeness: The SRS is complete if, and only if, it includes the following
elements:
(1). All essential requirements, whether relating to functionality, performance, design,
constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data
in all available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.

For example, consider a software to be developed for ATM.

If a customer enters an amount greater than the maximum permissible withdrawal

amount, the ATM should display an error message, and it should not dispense any cash.
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:
(1). the specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but
in another as textual.
(b) One condition may state that all lights shall be green while another states that all
lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified actions.
For example,
(a) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that
"A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use different
terms for that object. For example, a program's request for user input may be called a
"prompt" in one requirement's and a "cue" in another. The use of standard terminology
and descriptions promotes consistency.

4.Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted.
For example, consider you are developing a web application for your client. The
client requires that enough number of people should be able to access the application
simultaneously. What's the "enough number of people"? That could mean 10 to you,
but, perhaps, 100 to the client. There's an ambiguity.
5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance or
stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable.
Each element should be identified to make these differences clear and explicit. Another
way to rank requirements is to distinguish classes of items as essential, conditional, and
optional.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear
and if it facilitates the referencing of each condition in future development or
enhancement documentation.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing
its source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.

9. Design Independence: There should be an option to select from multiple design

alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate
test cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her

explicit domain but might not be trained in computer science. Hence, the purpose of
formal notations and symbols should be avoided too as much extent as possible. The
language should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage,
the details should be explained explicitly. Whereas, for a feasibility study, fewer analysis
can be used. Hence, the level of abstraction modifies according to the objective of the
SRS.
Properties of a good SRS document
The essential properties of a good SRS document are the following:
Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Irrelevant descriptions decrease readability and also increase
error possibilities.
Structured: It should be well-structured. A well-structured document is simple to
understand and modify. In practice, the SRS document undergoes several revisions to
cope up with the user requirements. Often, user requirements evolve over a period of
time. Therefore, to make the modifications to the SRS document easy, it is vital to make
the report well-structured.
Black-box view: It should only define what the system should do and refrain from
stating how to do these.
This means that the SRS document should define the external behavior of the
system and not discuss the implementation issues. The SRS report should view the
system to be developed as a black box and should define the externally visible behavior
of the system. For this reason, the SRS report is also known as the black-box
specification of a system.
Conceptual integrity: It should show conceptual integrity so that the reader can
merely understand it. Response to undesired events: It should characterize
acceptable responses to unwanted events. These are called system response to
exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should
be correct. This means that it should be possible to decide whether or not requirements
have been met in an implementation.

Parts of a SRS document

The important parts of SRS document are:
- Functional requirements of the system
- Non-functional requirements of the system, and
- Goals of implementation

Functional requirements:-
 The functional requirements part discusses the functionalities required from the
system. The system is considered to perform a set of high-level functions {fi }.
 The functional view of the system is shown in fig. Each function fi of the
system can be considered as a transformation of a set of input data (ii) to the

corresponding set of output data (oi ).

 The user can get some meaningful piece of work done using a high-level function.

View of a system performing a set of functions

Nonfunctional requirements:-

Nonfunctional requirements deal with the characteristics of the system which cannot be
expressed as functions - such as the maintainability of the system, portability of the
system, usability of the system, etc.

Goals of implementation:-

 The goals of implementation part documents some general suggestions

regarding development. These suggestions guide trade-off among design goals.
 The goals of implementation section might document issues such as revisions to
the system functionalities that may be required in the future, new devices to be
supported in the future, reusability issues, etc.
 These are the items which the developers might keep in their mind during
development so that the developed system may meet some aspects that are not
required immediately.

Identifying functional requirements from a problem description

 The high-level functional requirements often need to be identified either from an

informal problem description document or from a conceptual understanding of the
problem.
 Each high-level requirement characterizes a way of system usage by some user to
perform some meaningful piece of work.
 There can be many types of users of a system and their requirements from the
system may be very different.
 So, it is often useful to identify the different types of users who might use the
system and then try to identify the requirements from each user’s perspective.
Example: - Consider the case of the library system, where –
F1: Search Book function
Input: an author’s name
Output: details of the author’s books and the location of these books in the library
So the function Search Book (F1) takes the author's name and transforms it into book
details.
Functional requirements actually describe a set of high-level requirements,
where each high-level requirement takes some data from the user and provides some
data to the user as an output. Also each high-level requirement might consist of several
other functions.

Documenting functional requirements

 For documenting the functional requirements, we need to specify the set of

functionalities supported by the system.
 A function can be specified by identifying the state at which the data is to be input
to the system, its input data domain, the output data domain, and the type of
processing to be carried on the input data to obtain the output data.
 Let us first try to document the withdraw-cash function of an ATM
(Automated Teller Machine) system. The withdraw-cash is a high-level
requirement. It has several sub-requirements corresponding to the different user
interactions. These different interaction sequences capture the different scenarios.

Example: - Withdraw Cash from ATM

1: withdraw cash
Description: The withdraw cash function first determines the type of account that the
user has and the account number from which the user wishes to withdraw cash. It
checks the balance to determine whether the requested amount is available in the
account. If enough balance is available, it outputs the required cash; otherwise it
generates an error message.

R1.1 select withdraw amount option

Input: “withdraw amount” option
Output: user prompted to enter the account type

R1.2: select account type

Input: user option
Output: prompt to enter amount

R1.3: get required amount

Input: amount to be withdrawn in integer values greater than 100 and less than
10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.

Processing: the amount is debited from the user’s account if sufficient balance is
available, otherwise an error message displayed

Problems without a SRS document

The important problems that an organization would face if it does not develop
a SRS document are as follows:

 Without developing the SRS document, the system would not be implemented
according to customer needs.

 Software developers would not know whether what they are developing is what
exactly required by the customer.

 Without SRS document, it will be very much difficult for the maintenance engineers
to understand the functionality of the system.

 It will be very much difficult for user document writers to write the users’ manuals
properly without understanding the SRS document.

Problems with an unstructured specification

• It would be very much difficult to understand that document.

• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be unambiguous and inconsistent.

Formal Requirement Specification

 A formal software specification is a statement expressed in a language whose

vocabulary, syntax, and semantics are formally defined.
 The need for a formal semantic definition means that the specification languages
cannot be based on natural language; it must be based on mathematics.
 It is mathematical method used to specify a hardware or software system
requirement.

Goal: Describe external behavior without describing or constraining implementation.

Advantages of Formal Specification:

 The development of a formal specification provides insights and understanding of

the software requirements and the software design.
• Given a formal system specification and a complete formal programming language
definition, it may be possible to prove that a program conforms to its specifications.
• Formal specification may be automatically processed. Software tools can be built
To assist with their development, understanding, and debugging.
 Formal specifications are mathematical entities and may be studied and analyzed
using mathematical methods.
 Formal specifications may be used as a guide to the tester of a component in
identifying appropriate test cases.
Disadvantages of Formal Specification:

 All the requirement cannot be specified by formal specification.

 Use of mathematical sound to represent requirement.
  Difficult to learn and use.
 Cannot specify very complex problem.

Types of Formal Specification

1. Property Oriented:

- State desired properties in purely declarative way.

- System behavior is defined indirectly by stating its properties, usually in the form
of a set of axioms that system must satisfy.
- Suitable for requirement specification because they can be easily changed. They
specify a system as a conjunction of axioms and you can easily replace one axioms
with another one.
- They are classified as: 1) Axiomatic
2) Algebraic

2. Model Oriented:

- Provide direct way of describing system behavior by constructing a model of the

system in terms of mathematical structures such as tuple, relation, functions, sets,
sequences etc.
- More suited to use in later phases of life cycle because here even minor changes
to a specification may lead to drastic changes to the entire specification. They do
not support logical conjunction (AND) and disjunction (OR).

Axiomatic Specification

- Uses a set of stateless functions; each function has a set of pre and post condition.
- Pre and Post conditions are the predicate over the inputs and outputs of a function.
- A predicate is a Boolean expression which is true or false and whose variables are
the parameters of the function being specified.
- Pre-condition: Must satisfied before operation invoked.
 - Post – condition: Must satisfied after operation invoked.

The following are the sequence of steps that can be followed to systematically
develop the axiomatic specifications of a function:

 Establish the range of input values over which the function should behave
correctly. Also find out other constraints on the input parameters and write it in
the form of a predicate.

 Specify a predicate defining the conditions which must hold on the output of the
function if it behaved properly.

 Establish the changes made to the function’s input parameters after execution of
the function. Pure mathematical functions do not change their input and therefore
this type of assertion is not necessary for pure functions.

 Combine all of the above into pre and post conditions of the function.

Algebraic Specification

- In the algebraic specification technique, an object class or type is specified in

terms of relationship existing between the operations defined on that type.

- It contains 4 parts:

1) Type section- Type (Datatypes) used by specification.

2) Exception handling- Exception condition occurs during operation.
3) Syntax section- Procedure signature( operation, name, argument, return
type)
4) Equation section- Rules for equations