Software Crisis is a term used in computer science for the difficulty of writing

useful and efficient computer programs in the required time. The software crisis
was due to using the same workforce, same methods, and same tools even
though rapidly increasing software demand, the complexity of software,
and software challenges. With the increase in software complexity, many
software problems arise because existing methods were insufficient.
If we use the same workforce, same methods, and same tools after the fast
increase in software demand, software complexity, and software challenges,
then there arise some issues like software budget problems, software efficiency
problems, software quality problems, software management, and delivery
problems, etc. This condition is called a Software Crisis.

Software Crisis

Causes of Software Crisis:

 The cost of owning and maintaining software was as expensive as
developing the software.
 At that time Projects were running overtime.
 At that time Software was very inefficient.
 The quality of the software was low quality.
 Software often did not meet user requirements.
 The average software project overshoots its schedule by half.
 At that time Software was never delivered.
 Non-optimal resource utilization.
 Challenging to alter, debug, and enhance.
 The software complexity is harder to change.

Factors Contributing to Software Crisis:

 Poor project management.
 Lack of adequate training in software engineering.
 Less skilled project members.
 Low productivity improvements.

Solution of Software Crisis:

There is no single solution to the crisis. One possible solution to a software
crisis is Software Engineering because software engineering is a systematic,
disciplined, and quantifiable approach. For preventing software crises, there are
some guidelines:
 Reduction in software over budget.
 The quality of the software must be high.
 Less time is needed for a software project.
 Experienced and skilled people working on the software project.
 Software must be delivered.
 Software must meet user requirements.

SOFTWARE PROCESSES AND CHARACTERISTICS:

Software processes in software engineering refer to the methods and

techniques used to develop and maintain software. Some examples of software
processes include:
 Waterfall: a linear, sequential approach to software development, with
distinct phases such as requirements gathering, design, implementation,
testing, and maintenance.
 Agile: a flexible, iterative approach to software development, with an
emphasis on rapid prototyping and continuous delivery.
 Scrum: a popular Agile methodology that emphasizes teamwork, iterative
development, and a flexible, adaptive approach to planning and
management.
 DevOps: a set of practices that aims to improve collaboration and
communication between development and operations teams, with an
emphasis on automating the software delivery process.
Each process has its own set of advantages and disadvantages, and the choice
of which one to use depends on the specific project and organization.
Software is the set of instructions in the form of programs to govern the
computer system and to process the hardware components. To produce a
software product the set of activities is used. This set is called a software
process.

Software Development : In this process, designing, programming,

documenting, testing, and bug fixing is done.
Components of Software :
There are three components of the software: These are : Program,
Documentation, and Operating Procedures.
1. Program –
A computer program is a list of instructions that tell a computer what to do.

2. Documentation –
Source information about the product contained in design documents,
detailed code comments, etc.

3. Operating Procedures –
Set of step-by-step instructions compiled by an organization to help workers
carry out complex routine operations.
4. Code: the instructions that a computer executes in order to perform a
specific task or set of tasks.
5. Data: the information that the software uses or manipulates.
6. User interface: the means by which the user interacts with the software,
such as buttons, menus, and text fields.
7. Libraries: pre-written code that can be reused by the software to perform
common tasks.
8. Documentation: information that explains how to use and maintain the
software, such as user manuals and technical guides.
9. Test cases: a set of inputs, execution conditions, and expected outputs that
are used to test the software for correctness and reliability.
10. Configuration files: files that contain settings and parameters that are
used to configure the software to run in a specific environment.
11. Build and deployment scripts: scripts or tools that are used to build,
package, and deploy the software to different environments.
12. Metadata: information about the software, such as version numbers,
authors, and copyright information.
All these components are important for software development, testing and
deployment.
There are four basic key process activities:
1. Software Specifications –
In this process, detailed description of a software system to be developed
with its functional and non-functional requirements.

2. Software Development –
In this process, designing, programming, documenting, testing, and bug
fixing is done.

3. Software Validation –
In this process, evaluation software product is done to ensure that the
software meets the business requirements as well as the end users needs.

4. Software Evolution –
It is a process of developing software initially, then timely updating it for
various reasons.
Software Crisis :
1. Size and Cost –
Day to day growing complexity and expectation out of software. Software are
more expensive and more complex.

2. Quality –
Software products must have good quality.

3. Delayed Delivery –
Software takes longer than the estimated time to develop, which in turn
leads to cost shooting up.
4. The term “software crisis” refers to a set of problems that were faced by the
software industry in the 1960s and 1970s, such as:
5. High costs and long development times: software projects were taking much
longer and costing much more than expected.
6. Low quality: software was often delivered late, with bugs and other defects
that made it difficult to use.
7. Lack of standardization: there were no established best practices or
standards for software development, making it difficult to compare and
improve different approaches.
8. Lack of tools and methodologies: there were few tools and methodologies
available to help with software development, making it a difficult and time-
consuming process.
9. These problems led to a growing realization that the traditional approaches
to software development were not effective and needed to be improved. This
led to the development of new software development methodologies, such
as the Waterfall and Agile methodologies, as well as the creation of new
tools and technologies to support software development.
However, even today, software crisis could be seen in some form or the other,
like for example software projects going over budget, schedule and not meeting
the requirement.

Software Process Model:

A software process model is an abstraction of the actual process, which is
being described. It can also be defined as a simplified representation of a
software process. Each model represents a process from a specific perspective.
Basic software process models on which different type of software process
models can be implemented:
1. A workflow Model –
It is the sequential series of tasks and decisions that make up a business
process.

2. The Waterfall Model –

It is a sequential design process in which progress is seen as flowing
steadily downwards. Phases in waterfall model:
 (i) Requirements Specification
 (ii) Software Design
 (iii) Implementation
 (iv) Testing

3. Dataflow Model –
It is diagrammatic representation of the flow and exchange of information
within a system.

4. Evolutionary Development Model –

Following activities are considered in this method:
 (i) Specification
 (ii) Development
 (iii) Validation

5. Role / Action Model –

Roles of the people involved in the software process and the activities.

Need for Process Model:

The software development team must decide the process model that is to be
used for software product development and then the entire team must adhere to
it. This is necessary because the software product development can then be
done systematically. Each team member will understand what is the next
activity and how to do it. Thus process model will bring the definiteness and
discipline in overall development process. Every process model consists of
definite entry and exit criteria for each phase. Hence the transition of the
product through various phases is definite.
If the process model is not followed for software development then any team
member can perform any software development activity, this will ultimately
cause a chaos and software project will definitely fail without using process
model, it is difficult to monitor the progress of software product. Thus process
model plays an important rule in software engineering.

Software Processes
The term software specifies to the set of computer programs, procedures
and associated documents (Flowcharts, manuals, etc.) that describe the
program and how they are to be used.

A software process is the set of activities and associated outcome that

produce a software product. Software engineers mostly carry out these
activities. These are four key process activities, which are common to all
software processes. These activities are:

1. Software specifications: The functionality of the software and constraints

on its operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing client
needs.

The Software Process Model

A software process model is a specified definition of a software process,
which is presented from a particular perspective. Models, by their nature, are
a simplification, so a software process model is an abstraction of the actual
process, which is being described. Process models may contain activities,
which are part of the software process, software product, and the roles of
people involved in software engineering. Some examples of the types of
software process models that may be produced are:
 1. A workflow model: This shows the series of activities in the process along
with their inputs, outputs and dependencies. The activities in this model
perform human actions.
2. 2. A dataflow or activity model: This represents the process as a set of
activities, each of which carries out some data transformations. It shows how
the input to the process, such as a specification is converted to an output
such as a design. The activities here may be at a lower level than activities in
a workflow model. They may perform transformations carried out by people
or by computers.
3. 3. A role/action model: This means the roles of the people involved in the
software process and the activities for which they are responsible.

There are several various general models or paradigms of software

development:

1. The waterfall approach: This takes the above activities and produces them
as separate process phases such as requirements specification, software
design, implementation, testing, and so on. After each stage is defined, it is
"signed off" and development goes onto the following stage.
2. Evolutionary development: This method interleaves the activities of
specification, development, and validation. An initial system is rapidly
developed from a very abstract specification.
3. Formal transformation: This method is based on producing a formal
mathematical system specification and transforming this specification, using
mathematical methods to a program. These transformations are 'correctness
preserving.' This means that you can be sure that the developed programs
meet its specification.
4. System assembly from reusable components: This method assumes the
parts of the system already exist. The system development process target on
integrating these parts rather than developing them from scratch.

Software Crisis
 1. Size: Software is becoming more expensive and more complex with the
growing complexity and expectation out of software. For example, the code
in the consumer product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software
products defects after putting into use due to ineffective testing technique.
For example, Software testing typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop
and the money involved. For example, Development of the FAA's Advanced
Automation System cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the
software takes longer than the estimated time to develop, which in turn leads
to cost shooting up. For example, one in four large-scale development
projects is never completed.

Program vs. Software

Software is more than programs. Any program is a subset of software, and it
becomes software only if documentation & operating procedures manuals
are prepared.

There are three components of the software as shown in fig:

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals.

Examples of documentation manuals are: Data Flow Diagram, Flow Charts,
ER diagrams, etc.
3. Operating Procedures: Operating Procedures consist of instructions to
set up and use the software system and instructions on how react to the
system failure. Example of operating system procedures manuals is:
installation guide, Beginner's guide, reference guide, system administration
guide, etc.

Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle model
represents all the methods required to make a software product transit
through its life cycle stages. It also captures the structure in which these
methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a
software product from its inception to retirement. Different life cycle models
may plan the necessary development activities to phases in different ways.
Thus, no element which life cycle model is followed, the essential activities
are contained in all life cycle models though the action may be carried out in
distinct orders in different life cycle models. During any life cycle stage, more
than one activity may also be carried out.
Need of SDLC
The development team must determine a suitable life cycle model for a
particular plan and then observe to it.

Without using an exact life cycle model, the development of a software

product would not be in a systematic and disciplined manner. When a team
is developing a software product, there must be a clear understanding
among team representative about when and what to do. Otherwise, it would
point to chaos and project failure. This problem can be defined by using an
example. Suppose a software development issue is divided into various parts
and the parts are assigned to the team members. From then on, suppose the
team representative is allowed the freedom to develop the roles assigned to
them in whatever way they like. It is possible that one representative might
start writing the code for his part, another might choose to prepare the test
documents first, and some other engineer might begin with the design phase
of the roles assigned to him. This would be one of the perfect methods for
project failure.

A software life cycle model describes entry and exit criteria for each phase.
A phase can begin only if its stage-entry criteria have been fulfilled. So
without a software life cycle model, the entry and exit criteria for a stage
cannot be recognized. Without software life cycle models, it becomes tough
for software project managers to monitor the progress of the project.

SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework
includes the following steps:
The stages of SDLC are as follows:
Stage1: Planning and requirement analysis

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 or SMEs in the industry.

Planning for the quality assurance requirements and identifications of the

risks associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to
gather all the data like what the customer wants to build, who will be the end
user, what is the objective of the product. Before creating a product, a core
understanding or knowledge of the product is very necessary.
For Example, A client wants to have an application which concerns money
transactions. In this method, the requirement has to be precise like what
kind of operations will be done, how it will be done, in which currency it will
be done, etc.

Once the required function is done, an analysis is complete with auditing the
feasibility of the growth of a product. In case of any ambiguity, a signal is set
up for further discussion.

Once the requirement is understood, the SRS (Software Requirement

Specification) document is created. The developers should thoroughly follow
this document and also should be reviewed by the customer for future
reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly

represent and document the software requirements and get them accepted
from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification

document which contains all the product requirements to be constructed and
developed during the project life cycle.

Stage3: Designing the Software

The next phase is about 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.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming
is built. The implementation of design begins concerning writing code.
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.

Stage5: Testing

After the code is generated, 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.
Stage6: 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.

Stage7: 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.

SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management that
defines the stages include in an information system development project, from an initial
feasibility study to the maintenance of the completed application.

There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique
to its type to ensure success in the step of software development.

Here, are some important phases of SDLC life cycle:

Waterfall Model
The waterfall is a universally accepted SDLC model. In this method, the whole process of
software development is divided into various phases.

The waterfall model is a continuous software development model in which development is seen
as flowing steadily downwards (like a waterfall) through the steps of requirements analysis,
design, implementation, testing (validation), integration, and maintenance.

Linear ordering of activities has some significant consequences. First, to identify the end of a
phase and the beginning of the next, some certification techniques have to be employed at the
end of each step. Some verification and validation usually do this mean that will ensure that the
output of the stage is consistent with its input (which is the output of the previous step), and that
the output of the stage is consistent with the overall requirements of the system.

RAD Model
RAD or Rapid Application Development process is an adoption of the waterfall model; it targets
developing software in a short period. The RAD model is based on the concept that a better
system can be developed in lesser time by using focus groups to gather system requirements.
 o Business Modeling
o Data Modeling
o Process Modeling
o Application Generation
o Testing and Turnover

Spiral Model
The spiral model is a risk-driven process model. This SDLC model helps the group to
adopt elements of one or more process models like a waterfall, incremental, waterfall, etc. The
spiral technique is a combination of rapid prototyping and concurrency in design and
development activities.

Each cycle in the spiral begins with the identification of objectives for that cycle, the different
alternatives that are possible for achieving the goals, and the constraints that exist. This is the
first quadrant of the cycle (upper-left quadrant).

The next step in the cycle is to evaluate these different alternatives based on the objectives and
constraints. The focus of evaluation in this step is based on the risk perception for the project.

ADVERTISEMENT

The next step is to develop strategies that solve uncertainties and risks. This step may involve
activities such as benchmarking, simulation, and prototyping.

V-Model
In this type of SDLC model testing and the development, the step is planned in parallel. So, there
are verification phases on the side and the validation phase on the other side. V-Model joins by
Coding phase.

Incremental Model
The incremental model is not a separate model. It is necessarily a series of waterfall cycles. The
requirements are divided into groups at the start of the project. For each group, the SDLC model
is followed to develop software. The SDLC process is repeated, with each release adding more
functionality until all requirements are met. In this method, each cycle act as the maintenance
phase for the previous software release. Modification to the incremental model allows
development cycles to overlap. After that subsequent cycle may begin before the previous cycle
is complete.
Agile Model
Agile methodology is a practice which promotes continues interaction of development and
testing during the SDLC process of any project. In the Agile method, the entire project is divided
into small incremental builds. All of these builds are provided in iterations, and each iteration
lasts from one to three weeks.

Any agile software phase is characterized in a manner that addresses several key assumptions
about the bulk of software projects:

1. It is difficult to think in advance which software requirements will persist and which will change.
It is equally difficult to predict how user priorities will change as the project proceeds.
2. For many types of software, design and development are interleaved. That is, both activities
should be performed in tandem so that design models are proven as they are created. It is
difficult to think about how much design is necessary before construction is used to test the
configuration.
3. Analysis, design, development, and testing are not as predictable (from a planning point of view)
as we might like.

Iterative Model
It is a particular implementation of a software development life cycle that focuses on an initial,
simplified implementation, which then progressively gains more complexity and a broader
feature set until the final system is complete. In short, iterative development is a way of breaking
down the software development of a large application into smaller pieces.

Big bang model

Big bang model is focusing on all types of resources in software development and coding, with
no or very little planning. The requirements are understood and implemented when they come.

This model works best for small projects with smaller size development team which are working
together. It is also useful for academic software development projects. It is an ideal model where
requirements are either unknown or final release date is not given.

Prototype Model
The prototyping model starts with the requirements gathering. The developer and the user meet
and define the purpose of the software, identify the needs, etc.

A 'quick design' is then created. This design focuses on those aspects of the
software that will be visible to the user. It then leads to the development of a
prototype. The customer then checks the prototype, and any modifications or
changes that are needed are made to the prototype.

Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five
phases: Requirements analysis and specification, design, implementation,
and unit testing, integration and system testing, and operation and
maintenance. The steps always follow in this order and do not overlap. The
developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic
representation resembles a cascade of waterfalls.

1. Requirements analysis and specification phase: 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 so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the
system to be produced and not "how."In this phase, a large document
called Software Requirement Specification (SRS) document is created
which contained a detailed description of what the system will do in the
common language.
2. 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. All this work is documented as a
Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is

implemented. If the SDD is complete, the implementation or coding phase
proceeds smoothly, because all the information needed by software
developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small

modules are tested in isolation initially. After that these modules are tested
by writing some overhead code to check the interaction between these
modules and the flow of intermediate output.
4. 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. Unit testing determines the
efficiency of individual modules. However, in this phase, the modules are
tested for their interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task

performed by every user once the software has been delivered to the
customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited
are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are
required for it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged
during the entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover
progress.
o The release date for the complete product, as well as its final cost, can be
determined before development.
o It gives easy to control and clarity for the customer due to a strict reporting
system.

Disadvantages of Waterfall model

 o In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has
now shifted to the coding phase, and there is a change in requirement, It
becomes tough to go back and change it.
o Since the testing done at a later stage, it does not allow identifying the
challenges and risks in the earlier phase, so the risk reduction strategy is
difficult to prepare.

RAD (Rapid Application Development)

Model
RAD is a linear sequential software development process model that
emphasizes a concise development cycle using an element based
construction approach. If the requirements are well understood and
described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time
period.

RAD (Rapid Application Development) is a concept that products can be

developed faster and of higher quality through:

ADVERTISEMENT

ADVERTISEMENT

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs
o The re-use of software components
o A rigidly paced schedule that refers design improvements to the next product
version
o Less formality in reviews and other team communication
The various phases of RAD are as follows:
1.Business Modelling: The information flow among business functions is
defined by answering questions like what data drives the business process,
what data is generated, who generates it, where does the information go,
who process it and so on.

2. Data Modelling: The data collected from business modeling is refined

into a set of data objects (entities) that are needed to support the business.
The attributes (character of each entity) are identified, and the relation
between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data modeling

phase are transformed to achieve the data flow necessary to implement a
business function. Processing descriptions are created for adding, modifying,
deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate

construction of the software; even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have

already been tested since RAD emphasis reuse. This reduces the overall
testing time. But the new part must be tested, and all interfaces must be
fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a
short span time (2-3 months).
o When the requirements are well-known.
o When the technical risk is limited.
o When there's a necessity to make a system, which modularized in 2-3 months
of period.
o It should be used only if the budget allows the use of automatic code
generating tools.

Advantage of RAD Model

o This model is flexible for change.
o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the customer.
o It reduced development time.
o It increases the reusability of features.

Disadvantage of RAD Model

o It required highly skilled designers.
 o All application is not compatible with RAD.
o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software
process model that couples the iterative feature of prototyping with the
controlled and systematic aspects of the linear sequential model. It
implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release may
be a paper model or prototype. During later iterations, more and more
complete versions of the engineered system are produced.

The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of
purpose for that cycle, the various alternatives that are possible for
achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to

calculate these various alternatives based on the goals and constraints. The
focus of evaluation in this stage is located on the risk perception for the
project.

Development and validation: The next phase is to develop strategies that

resolve uncertainties and risks. This process may include activities such as
benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a
choice made whether to continue with a further period of the spiral. If it is
determined to keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if

performance or user-interface risks are treated more essential than the
program development risks, the next phase may be an evolutionary
development that includes developing a more detailed prototype for solving
the risks.

The risk-driven feature of the spiral model allows it to accommodate any

mixture of a specification-oriented, prototype-oriented, simulation-oriented,
or another type of approach. An essential element of the model is that each
period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral
model works for development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages
 o High amount of risk analysis
o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

1. If any changes happen in the midway, then the test documents along with
the required documents, has to be updated.

Prototype Model
The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built. A
prototype is a toy implementation of the system. A prototype usually turns
out to be a very crude version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and inefficient performance as
compared to actual software. In many instances, the client only has a
general view of what is expected from the software product. In such a
scenario where there is an absence of detailed information regarding the
input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.
Requirement Engineering
Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design
process. Requirement engineering provides the appropriate mechanism to
understand what the customer desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution, specifying the solution clearly,
validating the specifications and managing the requirements as they are
transformed into a working system. Thus, requirement engineering is the
disciplined application of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its associated
constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.

Types of Feasibility:

Backward Skip 10sPlay VideoForward Skip 10s

 1. Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements
are identified with the help of customers and existing systems processes, if
available.

Analysis of requirements starts with requirement elicitation. The

requirements are analyzed to identify inconsistencies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve conflicts
if any.

Problems of Elicitation and Analysis

ADVERTISEMENT

ADVERTISEMENT

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by
a software analyst after the requirements collected from the various sources
- the requirement received by the customer written in ordinary language. It
is the job of the analyst to write the requirement in technical language so
that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a system.
The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
 o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements stage,
the data dictionary should at least define customer data items, to ensure that
the customer and developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification
is the entity-relationship diagram, often called an "E-R diagram." It is a
detailed logical representation of the data for the organization and uses three
main constructs i.e. data entities, relationships, and their associated
attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in
this document are validated. The user might demand illegal, impossible
solution or experts may misinterpret the needs. Requirements can be the
check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.
o Prototyping: Using an executable model of the system to check
requirements.
o Test-case generation: Developing tests for requirements to check
testability.
o Automated consistency analysis: checking for the consistency of
structured requirements descriptions.
Software Requirement Management:
Requirement management is the process of managing changing
requirements during the requirements engineering process and system
development.

New requirements emerge during the process as business needs a change,

and a better understanding of the system is developed.

The priority of requirements from different viewpoints changes during

development process.

The business and technical environment of the system changes during the
development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software
development project. Hence they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be

categorized into two categories:
1. 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.
2. Non-functional Requirements: This can be the necessities that specify the
criteria that can be used to decide the operation instead of specific behaviors
of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable
at run time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.