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. The software crisis was due to using the
same workforce, same methods, same tools even though rapidly
increasing in software demand, the complexity of software, and
software challenges. With the increase in the complexity of software,
many software problems arise because existing methods were
insufficient. If we will 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 problems
like software budget problems, software efficiency problems, software
quality problems, software managing and delivering problem, etc. This
condition is called a 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 over-time
 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.
 Difficult to alter, debug, and enhance.
 The software complexity is harder to change.
Let’s now understand which factors are contributing to the 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 software must be high.
 Less time is needed for a software project.
 Experienced and skilled people working over the software project.
 Software must be delivered.
 Software must meet user requirements.
Q. What do you mean by software?
Software: Software is defined as a collection of computer programs,
procedures, rules, and data. Software Characteristics are classified
into six major components:
Software engineering is the process of designing, developing, testing,
and maintaining software. The characteristics of software include:
1. It is intangible, meaning it cannot be seen or touched.
2. It is non-perishable, meaning it does not degrade over time.
3. It is easy to replicate, meaning it can be copied and distributed
easily.
4. It can be complex, meaning it can have many interrelated parts and
features.
5. It can be difficult to understand and modify, especially for large and
complex systems.
6. It can be affected by changing requirements, meaning it may need
to be updated or modified as the needs of users change.
7. It can be affected by bugs and other issues, meaning it may need to
be tested and debugged to ensure it works as intended.
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.

characteristics of software in software engineering:

 Software is developed or engineered; it is not manufactured in

the classical sense:
 Although some similarities exist between software
development and hardware manufacturing, few activities
are fundamentally different.
 In both activities, high quality is achieved through good
design, but the manufacturing phase for hardware can
introduce quality problems than software.
 The software doesn’t “wear out.”:
 Hardware components suffer from the growing effects of
many other environmental factors. Stated simply, the
hardware begins to wear out.
  Software is not susceptible to the environmental maladies
that cause hardware to wear out.
 When a hardware component wears out, it is replaced by a
spare part.
 There are no software spare parts.
 Every software failure indicates an error in design or in the
process through which design was translated into machine-
executable code. Therefore, the software maintenance
tasks that accommodate requests for change involve
considerably more complexity than hardware maintenance.
However, the implication is clear—the software doesn’t
wear out. But it does deteriorate.
 The software continues to be custom-built:
 A software part should be planned and carried out with the
goal that it tends to be reused in various projects.
 Current reusable segments encapsulate the two information
and the preparation that is applied to the information,
empowering the programmer to make new applications
from reusable parts.
 In the hardware world, component reuse is a natural part of
the engineering process.

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.o

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.

After the software is deployed, then its maintenance begins.

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

There are Two variations of Waterfall model:

1)Original Waterfall Lifecycle Model
2)Modified Waterfall Lifecycle Model

1)Original Waterfall Lifecycle Model:-

This model is also known by other names such as Classic or conventional
or Traditional software Lifecycle Model.
It emphasizes that software is developed in sequential phases.

In this model, there are different phases the software goes through.
The phases are requirement analysis phase, design phase,
implementation phase, testing phase, and the maintenance phase. The
phases are sequential, which means that only after the completion of
the previous stage, does the development move to the next phase.
However, once the software has progressed from one phase to the
next stage, there is no way the software can go back to the previous
stage. There are many advantages and disadvantages. However, since
the software cannot go back to the previous stage is the deterrent,
due to which this model is not used often, which necessitated the
development of modified waterfall model.
Phases of waterfall model is:

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.

Play Video

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.

The drawback of Classic waterfall Model

The classic waterfall model is not the actual model because the main
disadvantage of it is that we cannot jump back from one phase to another, and
we cannot apply it to real projects. For developing software there may be some
changes from a customer or may some points remain from the previous team
and we cannot go back in this model so, here this phase is not comfortable for
projects as this is only for very small projects, and nowadays such small projects
 are not implemented. Companies develop only high-level projects or medium-
level projects.

Disadvantages to be pointed for the waterfall model.

 Freezing the requirements

 No option for the backward phase.
 Very high risk of failure of software.
 Not made for high-quality software.
 Cannot effort long-duration projects.

Modified Waterfall Model :

This model is the updated version of the classic waterfall model as in classic we
cannot go backward step, and in modified model this feature is given, we can go
back to an earlier stage and solve the problems.

Hence, to overcome the waterfall model, the modified waterfall model was
developed. The main feature of it’s adding the feedback system in every stage,
so the current phase gets the clearance of any error.

So, we can say that the main difference between the waterfall and the modified
waterfall model is a feedback system, and we can go to the previous stage for
correcting it.

The modified waterfall model is also known as the iterative waterfall

model.

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

Evolutionary Process Model :

Evolutionary process model resembles the iterative enhancement model. The
same phases are defined for the waterfall model occurs here in a cyclical
fashion. This model differs from the iterative enhancement model in the sense
that this does not require a useful product at the end of each cycle. In
evolutionary development, requirements are implemented by category rather
than by priority.

For example, in a simple database application, one cycle might implement the
graphical user Interface (GUI), another file manipulation, another queries and
another updates. All four cycles must complete before there is a working
product available. GUI allows the users to interact with the system, file
manipulation allow the data to be saved and retrieved, queries allow user to
get out of the system, and updates allows users to put data into the system.

Benefits of Evolutionary Process Model

Use of EVO brings a significant reduction in risk for software projects. Play Video

EVO can reduce costs by providing a structured, disciplined avenue for

experimentation.
EVO allows the marketing department access to early deliveries, facilitating the
development of documentation and demonstration.

Better fit the product to user needs and market requirements.

Manage project risk with the definition of early cycle content.

Uncover key issues early and focus attention appropriately.

Increase the opportunity to hit market windows.

Accelerate sales cycles with early customer exposure.

Increase management visibility of project progress.

Increase product team productivity and motivations.

Spiral model:
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 Spiral Model is a software development life cycle (SDLC) model
that provides a systematic and iterative approach to software
development. It is based on the idea of a spiral, with each iteration of
the spiral representing a complete software development cycle, from
requirements gathering and analysis to design, implementation,
testing, and maintenance.
The Spiral Model is a risk-driven model, meaning that the focus is on
managing risk through multiple iterations of the software development
process. It consists of the following phases:
1. Planning: The first phase of the Spiral Model is the planning phase,
where the scope of the project is determined and a plan is created
for the next iteration of the spiral.
2. Risk Analysis: In the risk analysis phase, the risks associated with
the project are identified and evaluated.
3. Engineering: In the engineering phase, the software is developed
based on the requirements gathered in the previous iteration.
4. Evaluation: In the evaluation phase, the software is evaluated to
determine if it meets the customer’s requirements and if it is of high
quality.
5. Planning: The next iteration of the spiral begins with a new planning
phase, based on the results of the evaluation.
6. The Spiral Model is often used for complex and large software
development projects, as it allows for a more flexible and adaptable
approach to software development. It is also well-suited to projects
with significant uncertainty or high levels of risk.
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-
1. 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.
2. 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.
 3. 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.
4. 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.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
1. 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.
2. Good for large projects: It is recommended to use the Spiral
Model in large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements
at later phase can be incorporated accurately by using this model.
4. 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.
5. Iterative and Incremental Approach: The Spiral Model provides an
iterative and incremental approach to software development,
allowing for flexibility and adaptability in response to changing
requirements or unexpected events.
6. Emphasis on Risk Management: The Spiral Model places a strong
emphasis on risk management, which helps to minimize the impact
of uncertainty and risk on the software development process.
7. Improved Communication: The Spiral Model provides for regular
evaluations and reviews, which can improve communication
between the customer and the development team.
8. Improved Quality: The Spiral Model allows for multiple iterations of
the software development process, which can result in improved
software quality and reliability
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other
SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is
expensive.
3. 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.
4. Difficulty in time management: As the number of phases is
unknown at the start of the project, so time estimation is very
difficult.
5. Complexity: The Spiral Model can be complex, as it involves
multiple iterations of the software development process.
6. Time-Consuming: The Spiral Model can be time-consuming, as it
requires multiple evaluations and reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as
it requires a significant investment in planning, risk analysis, and
evaluations.
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:

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

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 –

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:Learn more

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.
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they are
going to get.

A team oriented approach is developed for requirements gathering.

Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, team is divided into smaller sub-teams to
develop mini-specifications and finally a draft of specifications is written down
using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes
on the requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements –
In this the objective and goals of the proposed software are discussed with
the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
 Expected requirements –
These requirements are so obvious that the customer need not explicitly
state them. Example – protection from unauthorized access.
 Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be
very satisfying when present. Example – when unauthorized access is
detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
 DFD:- A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system. A neat and clear DFD can depict the right amount
of the system requirement graphically. It can be manual, automated, or a combination
of both.
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or
a process is represented by DFD. It also gives insight into the inputs and
outputs of each entity and the process itself. DFD does not have control flow
and no loops or decision rules are present. Specific operations depending on
the type of data can be explained by a flowchart.
It is a graphical tool, useful for communicating with users ,managers and other
personnel. it is useful for analysing existing as well as proposed system.
It provides an overview of
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
Data Flow Diagram can be represented in several ways. The DFD belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular
because they help us to visualize the major steps and data involved in software-
system processes.
Components of DFD
The Data Flow Diagram has 4 components:
 Process Input to output transformation in a system takes place because of
process function. The symbols of a process are rectangular with rounded
corners, oval, rectangle or a circle. The process is named a short sentence,
in one word or a phrase to express its essence
 Data Flow Data flow describes the information transferring between different
parts of the systems. The arrow symbol is the symbol of data flow. A
relatable name should be given to the flow to determine the information
which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems that
are not merely informative. A given flow should only transfer a single type of
information. The direction of flow is represented by the arrow which can also
be bi-directional.
 Warehouse The data is stored in the warehouse for later use. Two
horizontal lines represent the symbol of the store. The warehouse is simply
not restricted to being a data file rather it can be anything like a folder with
documents, an optical disc, a filing cabinet. The data warehouse can be
viewed independent of its implementation. When the data flow from the
 warehouse it is considered as data reading and when data flows to the
warehouse it is called data entry or data updation.
 Terminator The Terminator is an external entity that stands outside of the
system and communicates with the system. It can be, for example,
organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the model
system and is an external entity. Modeled systems also communicate with
terminator.

Rules for creating DFD

 The name of the entity should be easy and understandable without any extra
assistance(like comments).
 The processes should be numbered or put in ordered list to be referred
easily.
 The DFD should maintain consistency across all the DFD levels.
 A single DFD can have maximum processes upto 9 and minimum 3
processes.
Symbols Used in DFD
 Square Box: A square box defines source or destination of the system. It is
also called entity. It is represented by rectangle.
 Arrow or Line: An arrow identifies the data flow i.e. it gives information to
the data that is in motion.
 Circle or bubble chart: It represents as a process that gives us information.
It is also called processing box.
 Open Rectangle: An open rectangle is a data store. In this data is store
either temporary or permanently.
Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be
created. Levels of DFD are as follows:
 0-level DFD
 1-level DFD:
 2-level DFD:
Advantages of DFD
 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it helps
visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system
components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical
person because they are very easy to understand.
Disadvantages of DFD
 At times DFD can confuse the programmers regarding the system.
 Data Flow Diagram takes long time to be generated, and many times due to
this reasons analysts are denied permission to work on it.

A Data Dictionary is a collection of names, definitions, and attributes about

data elements that are being used or captured in a database, information
system, or part of a research project.

The different types of data dictionary are −

Active Data Dictionary

If the structure of the database or its specifications change at any point of time, it
should be reflected in the data dictionary. This is the responsibility of the database
management system in which the data dictionary resides.
So, the data dictionary is automatically updated by the database management system
when any changes are made in the database. This is known as an active data
dictionary as it is self updating.

Passive Data Dictionary

This is not as useful or easy to handle as an active data dictionary. A passive data
dictionary is maintained separately to the database whose contents are stored in the
dictionary. That means that if the database is modified the database dictionary is not
automatically updated as in the case of Active Data Dictionary.
So, the passive data dictionary has to be manually updated to match the database.
This needs careful handling or else the database and data dictionary are out of sync.
In the relational database system, it maintains all information of a relation or table, from its schema
to the applied constraints. All the metadata is stored. In general, metadata refers to the data about
data. So, storing the relational schemas and other metadata about the relations in a structure is
known as Data Dictionary or System Catalog.

A data dictionary is like the A-Z dictionary of the relational database system holding all information
each relation in the database.

The types of information a system must store are:

o Name of the relations

o Name of the attributes of each relation
o Lengths and domains of attributes
o Name and definitions of the views defined on the database
o Various integrity constraints

With this, the system also keeps the following data based on users of the system: Play Video

o Name of authorized users

o Accounting and authorization information about users.
o The authentication information for users, such as passwords or other related information.

In addition to this, the system may also store some statistical and descriptive data about the
relations, such as:

o Number of tuples in each relation

o Method of storage for each relation, such as clustered or non-clustered.

A system may also store the storage organization, whether sequential, hash, or heap. It also
notes the location where each relation is stored:

o If relations are stored in the files of the operating system, the data dictionary note, and stores the
names of the file.
o If the database stores all the relations in a single file, the data dictionary notes and store the blocks
 containing records of each relation in a data structure similar to a linked list.

At last, it also stores the information regarding each index of all the relations:

o Name of the index.

o Name of the relation being indexed.
o Attributes on which the index is defined.
o The type of index formed.

All the above information or metadata is stored in a data dictionary. The data dictionary also
maintains updated information whenever they occur in the relations. Such metadata constitutes a
miniature database. Some systems store the metadata in the form of a relation in the database
itself. The system designers design the way of representation of the data dictionary. Also, a data
dictionary stores the data in a non-formalized manner. It does not use any normal form so as to
fastly access the data stored in the dictionary.

For example, in the data dictionary, it uses underline below the value to represent that the
following field contains a primary key.

So, whenever the database system requires fetching records from a relation, it firstly finds in the
relation of data dictionary about the location and storage organization of the relation. After
confirming the details, it finally retrieves the required record from the database.
Software Requirement
Specifications
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. 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. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is
clear and simple to understand.

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.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be
able to ascertain the complete set of requirements that may be concerned by those modifications.

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. Verbose and 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.

How to Write an SRS Document

Creating a clear and effective SRS document can be difficult and time-
consuming. But it is critical to the efficient development of a high
quality product that meets the needs of business users.

Here are five steps you can follow to write an effective SRS document.

1. Define the Purpose With an Outline (Or Use an SRS Template)

Your first step is to create an outline for your software requirements

specification. This may be something you create yourself, or you can
use an existing SRS template.

If you’re creating the outline yourself, here’s what it might look like:

1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Product Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirements

This is a basic outline and yours may contain more (or fewer) items.
Now that you have an outline, lets fill in the blanks.
2. Define your Product’s Purpose
This introduction is very important as it sets expectations that we will come back to throughout the SRS.
Some items to keep in mind when defining this purpose include:

Intended Audience and Intended Use

Define who in your organization will have access to the SRS and how
they should use it. This may include developers, testers, and project
managers. It could also include stakeholders in other departments,
including leadership teams, sales, and marketing. Defining this now
will lead to less work in the future.

Product Scope

What are the benefits, objectives, and goals we intend to have for this
product? This should relate to overall business goals, especially if
teams outside of development will have access to the SRS.

Definitions and Acronyms

Clearly define all key terms, acronyms, and abbreviations used in the
SRS. This will help eliminate any ambiguity and ensure that all parties
can easily understand the document.

If your project contains a large quantity of industry-specific or

ambiguous terminology or acronyms, you may want to consider
including a reference to a project glossary, to be appended to the SRS,
in this section.

3. Describe What You Will Build

Your next step is to give a description of what you’re going to

build. Why is this product needed? Who is it for? Is it a new product?
Is it an add-on to a product you’ve already created? Is this going to
integrate with another product?

Understanding and getting your team aligned on the answers to these

questions on the front end makes creating the product much easier
and more efficient for everyone involved.
User Needs

Describe who will use the product and how. Understanding the various
users of the product and their needs is a critical part of the SRS
writing process.

Who will be using the product? Are they a primary or secondary user?
What is their role within their organization? What need does the
product need to fulfill for them?

Do you need to know about the purchaser of the product as well as the
end user? For the development of medical devices and med device
software, you may also need to know the needs of the patient.

Assumptions and Dependencies

What are we assuming will be true? Understating and laying out these
assumptions ahead of time will help with headaches later. Are we
assuming current technology? Are we basing this on a Windows
framework? We need to take stock of these technical assumptions to
better understand where our product might fail or not operate
perfectly.

Finally, you should note if your project is dependent on any external

factors. Are we reusing a bit of software from a previous project? This
new project would then depend on that operating correctly and should
be included.

4. Detail Your Specific Requirements

In order for your development team to meet the requirements properly,

we must include as much detail as possible. This can feel
overwhelming but becomes easier as you break down your
requirements into categories. Some common categories are functional
requirements, interface requirements, system features, and various
types of nonfunctional requirements:

Functional Requirements

Functional requirements are essential to your product because, as the

name implies, they provide some sort of functionality.
Asking yourself questions such as “does this add to my tool’s
functionality?” or “what function does this provide?” can help with this
process. Within medical devices especially, these functional
requirements may have a subset of domain-specific requirements.

You may also have requirements that outline how your software will
interact with other tools, which brings us to external interface
requirements.

External Interface Requirements

External interface requirements are specific types of functional

requirements. These are especially important when working with
embedded systems. They outline how your product will interface with
other components.

There are several types of interfaces you may have requirements for,
including:

 User
 Hardware
 Software
 Communications