Notes for MCA-I (Semester- I)

Subject :- Object Oriented Software Engineering

(Subject Code:- IT-13)
Chapter: 1] Introduction to development approach SSAD
and OOAD

 Software Engineering: - The term software engineering is the product

of two words, software, and engineering.

The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written by

developers on any of various particular computer languages.

Computer programs and related documentation such as requirements, design

models and user manuals.

Software engineering is an engineering branch associated with development of

software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable
software product.
Software is more than just a program code. A program is an executable code,
which serves some computational purpose. Software is considered to be
collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is
called software product.
Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.

Page 1
Software engineering is an engineering branch associated with development
of software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable
software product.

Definitions
software engineering defines as:
(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is, the application of
engineering to software.
(2) The study of approaches as in the above statement.
Fritz Bauer, a German computer scientist, defines software engineering as:
Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and work
efficiently on real machines.

Page 2
Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability(a system's ability to handle changing workloads and
demands while maintaining performance and stability.)
o Cost Management
o To manage the dynamic nature of software
o For better quality Management

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of

progress in user requirements and the environment on which the program is
working.

o Huge Programming: It is simpler to manufacture a wall than to a house

or building, similarly, as the measure of programming become extensive
engineering has to step to give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and
engineering ideas, it would be simpler to re-create new software than to
scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge
manufacturing has let down the cost of computer and electronic
hardware. But the cost of programming remains high if the proper process
is not adapted.
o Dynamic Nature: The continually growing and adapting nature of
programming hugely depends upon the environment in which the client
works. If the quality of the software is continually changing, new
upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development
provides a better and quality software product.

Page 3
Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and

challenging to progress. Software engineering has a great solution to
reduce the complication of any project. Software engineering divides big
problems into various small issues. And then start solving each small
issue one by one. All these small problems are solved independently to
each other.
2. To minimize software cost: Software needs a lot of hardwork and
software engineers are highly paid experts. A lot of manpower is required
to develop software with a large number of codes. But in software
engineering, programmers project everything and decrease all those
things that are not needed. In turn, the cost for software productions
becomes less as compared to any software that does not use software
engineering method.
3. To decrease time: Anything that is not made according to the project
always wastes time. And if you are making great software, then you may
need to run many codes to get the definitive running code. This is a very
time-consuming procedure, and if it is not well handled, then this can take
a lot of time. So if you are making your software according to the
software engineering method, then it will decrease a lot of time.

Page 4
4. Handling big projects: Big projects are not done in a couple of days, and
they need lots of patience, planning, and management. And to invest six
and seven months of any company, it requires heaps of planning,
direction, testing, and maintenance. No one can say that he has given four
months of a company to the task, and the project is still in its first stage.
Because the company has provided many resources to the plan and it
should be completed. So to handle a big project without any problem, the
company has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have
delivered the software, then it should work for at least its given time or
subscription. And if any bugs come in the software, the company is
responsible for solving all these bugs. Because in software engineering,
testing and maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the
standards. Software standards are the big target of companies to make it
more effective. So Software becomes more effective in the act with the
help of software engineering.
 1.1 Overview of Software Development with SSAD :- Structured
Systems Analysis and Design (SSAD) Method ,The three most important
techniques that are used in SSAD Method are as follows :

 Logical Data Modeling

The process of identifying, modeling and documenting the data
requirements of the system being designed. The result is a data model
containing entities (things about which a business needs to record
information), attributes (facts about the entities) and relationships
(associations between the entities).

 Data Flow Modeling

The process of identifying, modeling and documenting how data moves
around an information system. Data Flow Modeling examines processes
(activities that transform data from one form to another), data stores (the
holding areas for data), external entities (what sends data into a system or
receives data from a system), and data flows (routes by which data can
flow).

Page 5
  Entity Event Modeling
A two-stranded process: Entity Behavior Modeling, identifying, modeling
and documenting the events that affect each entity and the sequence (or
life history) in which these events occur, and Event Modeling, designing
for each event the process to coordinate entity life histories.

Stages
The SSAD method involves the application of a sequence of analysis,
documentation and design tasks concerned with the following.
Stage 0 – Feasibility study
In order to determine whether or not a given project is feasible, there must be
some form of investigation into the goals and implications of the project. For
very small-scale projects this may not be necessary at all as the scope of the
project is easily understood. In larger projects, the feasibility may be done but in
an informal sense, either because there is no time for a formal study or because
the project is a “must-have” and will have to be done one way or the other. A
data flow Diagram is used to describe how the current system works and to
visualize the known problems.
When a feasibility study is carried out, there are four main areas of
consideration:
Technical – is the project technically possible?
Financial – can the business afford to carry out the project?
Organizational – will the new system be compatible with existing practices?
Ethical – is the impact of the new system socially acceptable?
To answer these questions, the feasibility study is effectively a condensed
version of a comprehensive systems analysis and design. The requirements and
usages are analyzed to some extent, some business options are drawn up and
even some details of the technical implementation. The product of this stage is a
formal feasibility study document. SSADM specifies the sections that the study
should contain including any preliminary models that have been constructed and
also details of rejected options and the reasons for their rejection.
Stage 1 – Investigation of the current environment
The developers of SSADM understood that in almost all cases there is some
form of current system even if it is entirely composed of people and paper.
Through a combination of interviewing employees, circulating questionnaires,
observations and existing documentation, the analyst comes to full
understanding of the system as it is at the start of the project. This serves many
purposes (Like examples?).

Page 6
Stage 2 – Business system options
Having investigated the current system, the analyst must decide on the overall
design of the new system. To do this, he or she, using the outputs of the
previous stage, develops a set of business system options. These are different
ways in which the new system could be produced varying from doing nothing to
throwing out the old system entirely and building an entirely new one. The
analyst may hold a brainstorming session so that as many and various ideas as
possible are generated.
The ideas are then collected to options which are presented to the user. The
options consider the following:

 the degree of automation

 the boundary between the system and the users
 the distribution of the system, for example, is it centralized to one office
or spread out across several?
 cost/benefit
 impact of the new system

Where necessary, the option will be documented with a logical data structure
and a level 1 data-flow diagram.
The users and analyst together choose a single business option. This may be one
of the ones already defined or may be a synthesis of different aspects of the
existing options. The output of this stage is the single selected business option
together with all the outputs of the feasibility stage.
Stage 3 – Requirements specification
This is probably the most complex stage in SSADM. Using the requirements
developed in stage 1 and working within the framework of the selected business
option, the analyst must develop a full logical specification of what the new
system must do. The specification must be free from error, ambiguity and
inconsistency. By logical, we mean that the specification does not say how the
system will be implemented but rather describes what the system will do.
To produce the logical specification, the analyst builds the required logical
models for both the Data-Flow Diagrams (DFDs) and the Logical Data
Model (LDM), consisting of the Logical Data Structure (referred to in other
methods as entity relationship diagrams) and full descriptions of the data and its
relationships. These are used to produce function definitions of every function
which the users will require of the system, Entity Life-Histories (ELHs) which

Page 7
describe all events through the life of an entity, and Effect Correspondence
Diagrams (ECDs) which describe how each event interacts with all relevant
entities. These are continually matched against the requirements and where
necessary, the requirements are added to and completed.
The product of this stage is a complete requirements specification document
which is made up of:

 the updated data catalogue

 the updated requirements catalogue
 the processing specification which in turn is made up of

 user role/function matrix

 function definitions
 required logical data model
 entity life-histories
 effect correspondence diagrams

Stage 4 – Technical system options

This stage is the first towards a physical implementation of the new system.
Like the Business System Options, in this stage a large number of options
for the implementation of the new system are generated. This is narrowed
down to two or three to present to the user from which the final option is
chosen or synthesized.
However, the considerations are quite different being:

 the hardware architectures

 the software to use
 the cost of the implementation
 the staffing required
 the physical limitations such as a space occupied by the system
 the distribution including any networks which that may require
 the overall format of the human computer interface

Page 8
All of these aspects must also conform to any constraints imposed by the
business such as available money and standardization of hardware and
software.
The output of this stage is a chosen technical system option.
Stage 5 – Logical design
Though the previous level specifies details of the implementation, the
outputs of this stage are implementation-independent and concentrate on the
requirements for the human computer interface. The logical design specifies
the main methods of interaction in terms of menu structures and command
structures.
One area of activity is the definition of the user dialogues. These are the
main interfaces with which the users will interact with the system. Other
activities are concerned with analyzing both the effects of events in updating
the system and the need to make inquiries about the data on the system. Both
of these use the events, function descriptions and effect correspondence
diagrams produced in stage 3 to determine precisely how to update and read
data in a consistent and secure way.
The product of this stage is the logical design which is made up of:

 Data catalogue
 Required logical data structure
 Logical process model – includes dialogues and model for the update and
inquiry processes
 Stress & Bending moment.

Stage 6 – Physical design

This is the final stage where all the logical specifications of the system are
converted to descriptions of the system in terms of real hardware and
software. This is a very technical stage and a simple overview is presented
here.
The logical data structure is converted into a physical architecture in terms
of database structures. The exact structure of the functions and how they are
implemented is specified. The physical data structure is optimized where
necessary to meet size and performance requirements.
The product is a complete Physical Design which could tell software
engineers how to build the system in specific details of hardware and
software and to the appropriate standards.

Page 9
  What is Structured Analysis?
Structured Analysis is a development method that allows the analyst to
understand the system and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine
the objectives of an existing system and develop a new system specification
which can be easily understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend
on vendor or hardware.
 It is an approach that works from high-level overviews to lower-level
details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system
development. They are −
 Data Flow Diagrams
 Data Dictionary
 Decision Trees
 Decision Tables
 Structured Query
 Pseudocode

Page 10
Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of
system in a graphical form.
 It shows the flow of data between various functions of system and
specifies how the current system is implemented.
 It is an initial stage of design phase that functionally divides the
requirement specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user
and analyst or analyst and system designer.
 It gives an overview of what data a system processes, what
transformations are performed, what data are stored, what results are
produced and where they flow.

Basic Elements of DFD:-

DFD is easy to understand and quite effective when the required design is not
clear and the user wants a notational language for communication. However, it
requires a large number of iterations for obtaining the most accurate and
complete solution.
The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Page 11
Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD:-
DFDs are of two types: Physical DFD and Logical DFD. The following table
lists the points that differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows It is implementation independent. It

which functions are performed. focuses only on the flow of data between
processes.

It provides low level details of hardware, It explains events of systems and data
software, files, and people. required by each event.

It depicts how the current system It shows how business operates; not how
operates and how a system will be the system can be implemented.
implemented.

Context Diagram:-
A context diagram helps in understanding the entire system by one DFD which
gives the overview of a system. It starts with mentioning major processes with
little details and then goes onto giving more details of the processes with the
top-down approach.
The context diagram of mess management is shown below.

Page 12
Data Dictionary:-
A data dictionary is a structured repository of data elements in the system. It
stores the descriptions of all DFD data elements that is, details and definitions
of data flows, data stores, data stored in data stores, and the processes.
A data dictionary improves the communication between the analyst and the
user. It plays an important role in building a database. Most DBMSs have a data
dictionary as a standard feature. For example, refer the following table –

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees :-
Decision trees are a method for defining complex relationships by describing
decisions and avoiding the problems in communication. A decision tree is a
diagram that shows alternative actions and conditions within horizontal tree

Page 13
framework. Thus, it depicts which conditions to consider first, second, and so
on.
Decision trees depict the relationship of each condition and their permissible
actions. A square node indicates an action and a circle indicates a condition. It
forces analysts to consider the sequence of decisions and identifies the actual
decision that must be made.

The major limitation of a decision tree is that it lacks information in its format
to describe what other combinations of conditions you can take for testing. It is
a single representation of the relationships between conditions and actions.
For example, refer the following decision tree −

Decision Tables :-
Decision tables are a method of describing the complex logical relationship in a
precise manner which is easily understandable.

Page 14
  It is useful in situations where the resulting actions depend on the
occurrence of one or several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the
actions.

Pseudocode:-
A pseudocode does not conform to any programming language and expresses
logic in plain English.
 It may specify the physical programming logic without actual coding
during and after the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

 1.1.1 Basic System Development Life Cycle with different users and
their role in SDLC :-

Software Development Life Cycle, SDLC for short, is a well-defined,

structured sequence of stages in software engineering to develop the
intended software product.

SDLC Activities
SDLC provides a series of steps to be followed to design and develop a
software product efficiently. SDLC framework includes the following steps:

Page 15
Communication: -
This is the first step where the user initiates the request for a desired software
product. He contacts the service provider and tries to negotiate the terms. He
submits his request to the service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the
project. The team holds discussions with various stakeholders from problem
domain and tries to bring out as much information as possible on their
requirements. The requirements are contemplated and segregated into user
requirements, system requirements and functional requirements. The
requirements are collected using a number of practices as given -
 studying the existing or obsolete system and software,
 conducting interviews of users and developers,
 referring to the database or
 collecting answers from the questionnaires.

Page 16
Feasibility Study:-
After requirement gathering, the team comes up with a rough plan of
software process. At this step the team analyzes if a software can be made to
fulfill all requirements of the user and if there is any possibility of software
being no more useful. It is found out, if the project is financially, practically
and technologically feasible for the organization to take up. There are many
algorithms available, which help the developers to conclude the feasibility of
a software project.

System Analysis :-
At this step the developers decide a roadmap of their plan and try to bring up
the best software model suitable for the project. System analysis includes
Understanding of software product limitations, learning system related
problems or changes to be done in existing systems beforehand, identifying
and addressing the impact of project on organization and personnel etc. The
project team analyzes the scope of the project and plans the schedule and
resources accordingly.

Software Design:-
Next step is to bring down whole knowledge of requirements and analysis on
the desk and design the software product. The inputs from users and
information gathered in requirement gathering phase are the inputs of this
step. The output of this step comes in the form of two designs; logical design
and physical design. Engineers produce meta-data and data dictionaries,
logical diagrams, data-flow diagrams and in some cases pseudo codes.

Coding:-
This step is also known as programming phase. The implementation of
software design starts in terms of writing program code in the suitable
programming language and developing error-free executable programs
efficiently.

Testing:-
An estimate says that 50% of whole software development process should be
tested. Errors may ruin the software from critical level to its own removal.
Software testing is done while coding by the developers and thorough testing

Page 17
is conducted by testing experts at various levels of code such as module
testing, program testing, product testing, in-house testing and testing the
product at user’s end. Early discovery of errors and their remedy is the key
to reliable software.

Integration:-
Software may need to be integrated with the libraries, databases and other
program(s). This stage of SDLC is involved in the integration of software
with outer world entities.

Implementation:-
This means installing the software on user machines. At times, software
needs post-installation configurations at user end. Software is tested for
portability and adaptability and integration related issues are solved during
implementation.

Operation and Maintenance:-

This phase confirms the software operation in terms of more efficiency and
less errors. If required, the users are trained on, or aided with the
documentation on how to operate the software and how to keep the software
operational. The software is maintained timely by updating the code
according to the changes taking place in user end environment or
technology. This phase may face challenges from hidden bugs and real-
world unidentified problems.

Disposition:-
As time elapses, the software may decline on the performance front. It may
go completely obsolete or may need intense up gradation. Hence a pressing
need to eliminate a major portion of the system arises. This phase includes
archiving data and required software components, closing down the system,
planning disposition activity and terminating system at appropriate end-of-
system time.

Page 18
What is SDLC?
SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the overall
development process.
The following figure is a graphical representation of the various stages of a
typical SDLC.

A typical Software Development Life Cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis:-

Requirement analysis is the most important and fundamental stage in SDLC.
It is performed by the senior members of the team with inputs from the
customer, the sales department, market surveys and domain experts in the
industry. This information is then used to plan the basic project approach and
to conduct product feasibility study in the economical, operational and
technical areas.
Planning for the quality assurance requirements and identification of the
risks associated with the project is also done in the planning stage. The

Page 19
outcome of the technical feasibility study is to define the various technical
approaches that can be followed to implement the project successfully with
minimum risks.

Stage 2: Defining Requirements :-

Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the
customer or the market analysts. This is done through an SRS (Software
Requirement Specification) document which consists of all the product
requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture:-

SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the requirements
specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.
This DDS is reviewed by all the important stakeholders and based on various
parameters as risk assessment, product robustness, design modularity, budget
and time constraints, the best design approach is selected for the product.
A design approach clearly defines all the architectural modules of the
product along with its communication and data flow representation with the
external and third party modules (if any). The internal design of all the
modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.

Stage 4: Building or Developing the Product :-

In this stage of SDLC the actual development starts and the product is built.
The programming code is generated as per DDS during this stage. If the
design is performed in a detailed and organized manner, code generation can
be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization
and programming tools like compilers, interpreters, debuggers, etc. are used
to generate the code. Different high level programming languages such as C,
C++, Pascal, Java and PHP are used for coding. The programming language
is chosen with respect to the type of software being developed.

Page 20
Stage 5: Testing the Product :-
This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of SDLC.
However, this stage refers to the testing only stage of the product where
product defects are reported, tracked, fixed and retested, until the product
reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance:-

Once the product is tested and ready to be deployed it is released formally in
the appropriate market. Sometimes product deployment happens in stages as
per the business strategy of that organization. The product may first be
released in a limited segment and tested in the real business environment
(UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with
suggested enhancements in the targeting market segment. After the product
is released in the market, its maintenance is done for the existing customer
base.

An effective System Development Life Cycle (SDLC) should result in a high

quality system that meets customer expectations, reaches completion within
time and cost evaluations, and works effectively and efficiently in the current
and planned Information Technology infrastructure.
System Development Life Cycle (SDLC) is a conceptual model which
includes policies and procedures for developing or altering systems
throughout their life cycles.
SDLC is used by analysts to develop an information system. SDLC includes
the following activities −
 requirements
 design
 implementation
 testing
 deployment
 operations
 maintenance
Phases of SDLC

Page 21
Systems Development Life Cycle is a systematic approach which explicitly
breaks down the work into phases that are required to implement either new
or modified Information System.

Feasibility Study or Planning:-

 Define the problem and scope of existing system.
 Overview the new system and determine its objectives.
 Confirm project feasibility and produce the project Schedule.
 During this phase, threats, constraints, integration and security of system
are also considered.
 A feasibility report for the entire project is created at the end of this
phase.

Analysis and Specification:-

Page 22
 Gather, analyze, and validate the information.
 Define the requirements and prototypes for new system.
 Evaluate the alternatives and prioritize the requirements.
 Examine the information needs of end-user and enhances the system goal.
 A Software Requirement Specification (SRS) document, which specifies
the software, hardware, functional, and network requirements of the
system is prepared at the end of this phase.

System Design:-
 Includes the design of application, network, databases, user interfaces,
and system interfaces.
 Transform the SRS document into logical structure, which contains
detailed and complete set of specifications that can be implemented in a
programming language.
 Create a contingency, training, maintenance, and operation plan.
 Review the proposed design. Ensure that the final design must meet the
requirements stated in SRS document.
 Finally, prepare a design document which will be used during next
phases.

Implementation:-
 Implement the design into source code through coding.
 Combine all the modules together into training environment that detects
errors and defects.
 A test report which contains errors is prepared through test plan that
includes test related tasks such as test case generation, testing criteria, and
resource allocation for testing.
 Integrate the information system into its environment and install the new
system.

Maintenance/Support:-
 Include all the activities such as phone support or physical on-site support
for users that is required once the system is installing.
 Implement the changes that software might undergo over a period of
time, or implement any new requirements after the software is deployed
at the customer location.

Page 23
 It also includes handling the residual errors and resolve any issues that
may exist in the system even after the testing phase.
 Maintenance and support may be needed for a longer time for large
systems and for a short time for smaller systems.

Life Cycle of System Analysis and Design:-

The following diagram shows the complete life cycle of the system during
analysis and design phase.

Role of System Analyst:-

The system analyst is a person who is thoroughly aware of the system and
guides the system development project by giving proper directions. He is an
expert having technical and interpersonal skills to carry out development
tasks required at each phase.
He pursues to match the objectives of information system with the
organization goal.
Main Roles
 Defining and understanding the requirement of user through various Fact
finding techniques.
 Prioritizing the requirements by obtaining user consensus.
 Gathering the facts or information and acquires the opinions of users.

Page 24
 Maintains analysis and evaluation to arrive at appropriate system which is
more user friendly.
 Suggests many flexible alternative solutions, pick the best solution, and
quantify cost and benefits.
 Draw certain specifications which are easily understood by users and
programmer in precise and detailed form.
 Implemented the logical design of system which must be modular.
 Plan the periodicity for evaluation after it has been used for some time,
and modify the system as needed.
Attributes of a Systems Analyst
The following figure shows the attributes a systems analyst should possess −

Interpersonal Skills:-
 Interface with users and programmer.
 Facilitate groups and lead smaller teams.
 Managing expectations.

Page 25
 Good understanding, communication, selling and teaching abilities.
 Motivator having the confidence to solve queries.
Analytical Skills:-
 System study and organizational knowledge
 Problem identification, problem analysis, and problem solving
 Sound commonsense
 Ability to access trade-off
 Curiosity to learn about new organization

Management Skills:-
 Understand users jargon and practices.
 Resource & project management.
 Change & risk management.
 Understand the management functions thoroughly.

Technical Skills:-
 Knowledge of computers and software.
 Keep abreast of modern development.
 Know of system design tools.
 Breadth knowledge about new technologies.

What is Requirements Determination?

A requirement is a vital feature of a new system which may include
processing or capturing of data, controlling the activities of business,
producing information and supporting the management.
Requirements determination involves studying the existing system and
gathering details to find out what are the requirements, how it works, and
where improvements should be made.
Major Activities in requirement Determination
Requirements Anticipation
 It predicts the characteristics of system based on previous experience
which include certain problems or features and requirements for a new
system.
 It can lead to analysis of areas that would otherwise go unnoticed by
inexperienced analyst. But if shortcuts are taken and bias is introduced in

Page 26
 conducting the investigation, then requirement Anticipation can be half-
baked.
Requirements Investigation
 It is studying the current system and documenting its features for further
analysis.
 It is at the heart of system analysis where analyst documenting and
describing system features using fact-finding techniques, prototyping, and
computer assisted tools.
Requirements Specifications
 It includes the analysis of data which determine the requirement
specification, description of features for new system, and specifying what
information requirements will be provided.
 It includes analysis of factual data, identification of essential
requirements, and selection of Requirement-fulfillment strategies.
Information Gathering Techniques
The main aim of fact finding techniques is to determine the information
requirements of an organization used by analysts to prepare a precise SRS
understood by user.
Ideal SRS Document should −
 be complete, Unambiguous, and Jargon-free.
 specify operational, tactical, and strategic information requirements.
 solve possible disputes between users and analyst.
 use graphical aids which simplify understanding and design.
There are various information gathering techniques −
Interviewing
Systems analyst collects information from individuals or groups by
interviewing. The analyst can be formal, legalistic, play politics, or be
informal; as the success of an interview depends on the skill of analyst as
interviewer.
It can be done in two ways −
 Unstructured Interview − The system analyst conducts question-answer
session to acquire basic information of the system.
 Structured Interview − It has standard questions which user need to
respond in either close (objective) or open (descriptive) format.
Advantages of Interviewing

Page 27
 This method is frequently the best source of gathering qualitative
information.
 It is useful for them, who do not communicate effectively in writing or
who may not have the time to complete questionnaire.
 Information can easily be validated and cross checked immediately.
 It can handle the complex subjects.
 It is easy to discover key problem by seeking opinions.
 It bridges the gaps in the areas of misunderstandings and minimizes
future problems.
Questionnaires
This method is used by analyst to gather information about various issues of
system from large number of persons.
There are two types of questionnaires −
 Open-ended Questionnaires − It consists of questions that can be easily
and correctly interpreted. They can explore a problem and lead to a
specific direction of answer.
 Closed-ended Questionnaires − It consists of questions that are used
when the systems analyst effectively lists all possible responses, which
are mutually exclusive.
Advantages of questionnaires
 It is very effective in surveying interests, attitudes, feelings, and beliefs of
users which are not co-located.
 It is useful in situation to know what proportion of a given group
approves or disapproves of a particular feature of the proposed system.
 It is useful to determine the overall opinion before giving any specific
direction to the system project.
 It is more reliable and provides high confidentiality of honest responses.
 It is appropriate for electing factual information and for statistical data
collection which can be emailed and sent by post.
Review of Records, Procedures, and Forms
Review of existing records, procedures, and forms helps to seek insight into
a system which describes the current system capabilities, its operations, or
activities.
Advantages
 It helps user to gain some knowledge about the organization or operations
by themselves before they impose upon others.

Page 28
 It helps in documenting current operations within short span of time as
the procedure manuals and forms describe the format and functions of
present system.
 It can provide a clear understanding about the transactions that are
handled in the organization, identifying input for processing, and
evaluating performance.
 It can help an analyst to understand the system in terms of the operations
that must be supported.
 It describes the problem, its affected parts, and the proposed solution.
Observation
This is a method of gathering information by noticing and observing the
people, events, and objects. The analyst visits the organization to observe the
working of current system and understands the requirements of the system.
Advantages
 It is a direct method for gleaning information.
 It is useful in situation where authenticity of data collected is in question
or when complexity of certain aspects of system prevents clear
explanation by end-users.
 It produces more accurate and reliable data.
 It produces all the aspect of documentation that are incomplete and
outdated.
Feasibility Study
Feasibility Study can be considered as preliminary investigation that helps
the management to take decision about whether study of system should be
feasible for development or not.
 It identifies the possibility of improving an existing system, developing a
new system, and produce refined estimates for further development of
system.
 It is used to obtain the outline of the problem and decide whether feasible
or appropriate solution exists or not.
 The main objective of a feasibility study is to acquire problem scope
instead of solving the problem.
 The output of a feasibility study is a formal system proposal act as
decision document which includes the complete nature and scope of the
proposed system.
Steps Involved in Feasibility Analysis

Page 29
The following steps are to be followed while performing feasibility analysis
−
 Form a project team and appoint a project leader.
 Develop system flowcharts.
 Identify the deficiencies of current system and set goals.
 Enumerate the alternative solution or potential candidate system to meet
goals.
 Determine the feasibility of each alternative such as technical feasibility,
operational feasibility, etc.
 Weight the performance and cost effectiveness of each candidate system.
 Rank the other alternatives and select the best candidate system.
 Prepare a system proposal of final project directive to management for
approval.

Types of Feasibilities

Economic Feasibility:-
 It is evaluating the effectiveness of candidate system by using cost/benefit
analysis method.
 It demonstrates the net benefit from the candidate system in terms of
benefits and costs to the organization.
 The main aim of Economic Feasibility Analysis (EFS) is to estimate the
economic requirements of candidate system before investments funds are
committed to proposal.
 It prefers the alternative which will maximize the net worth of
organization by earliest and highest return of funds along with lowest
level of risk involved in developing the candidate system.

Page 30
Technical Feasibility:-
 It investigates the technical feasibility of each implementation alternative.
 It analyzes and determines whether the solution can be supported by
existing technology or not.
 The analyst determines whether current technical resources be upgraded
or added it that fulfill the new requirements.
 It ensures that the candidate system provides appropriate responses to
what extent it can support the technical enhancement.

Operational Feasibility:-
 It determines whether the system is operating effectively once it is
developed and implemented.
 It ensures that the management should support the proposed system and
its working feasible in the current organizational environment.
 It analyzes whether the users will be affected and they accept the
modified or new business methods that affect the possible system
benefits.
 It also ensures that the computer resources and network architecture of
candidate system are workable.

Behavioral Feasibility:-
 It evaluates and estimates the user attitude or behavior towards the
development of new system.
 It helps in determining if the system requires special effort to educate,
retrain, transfer, and changes in employee’s job status on new ways of
conducting business.

Schedule Feasibility:-
 It ensures that the project should be completed within given time
constraint or schedule.
 It also verifies and validates whether the deadlines of project are
reasonable or not.

Responsibilities of the Project Manager :-

1. Determine objectives, schedule and resource budgets
2. Design a software project management plan (SPMP)

Page 31
3. Create and sustain focused and motivated teams
4. Determine the team‘s work procedures, reporting systems and
communication infrastructure.
5. Accomplish project objective within time and budget
6. Monitor performance against the plan
7. Resolve technical conflicts and interpersonal conflicts
8. Control changes in the project
9. Report on project activities to upper management
10.Keep the client informed and committed
11.Contribute to the team members performance approval

Responsibilities of the Team Leader :-

1. Run the weekly project meeting
2. Post the agenda before the meeting
3. Define and keep track of action items assigned to team members (who,
what, when)
4. Measure progress (Enforce milestones)
5. Deliver work packages for the tasks to the project manager
6. Present team status to project manager
Technical team responsibilities:
1. Perform assigned tasks within time and budget
2. Acquire technical skills and knowledge needed to perform the work
3. Identify situations and problems that might affect your team members‘s
tasks Keep your team members informed of your progress and problems
you encounter

Responsibilities of a Tester:-
The roles and responsibilities of a tester often vary from organization to
organization. In general, a testers main purpose is to design, develop, and
conduct system tests and supports acceptance testing. The roles and
responsibilities of a tester include the core activities associated with the test
effort. This usually involves identifying the most appropriate implementation
approach specific tests, performing test preparations, executing the tests,
logging outcomes, and administering the defect tracking system.
More detailed aspects of the roles and responsibilities of a tester is included
in the following:

Page 32
 1. Analyzing client requirements
2. Understand the software application being tested
3. Prepare test strategy
4. Participating in test plan preparation
5. Preparing test scenarios
6. Preparing test cases (used for module, integration, and system testing
7. Preparing test data (used for test cases)
8. Preparing test environment
9. Analyzing test cases (those prepared by others)
10.Write necessary test scripts
11.Executing the test cases
12.Defect tracking
13.Perform necessary retesting
14.Providing defect information (for developers)
15.Preparing report summaries
16.Preparing lesson learnt documents
17.Conducting review meetings within the team

The testing in this phase can involve many different types of tests, depending on
the project and the company, such as:
 Unit testing: testing individual pieces of code to ensure they work
 System testing: testing the entire system to ensure it works
 Verification testing: ensure that the system does what the requirements
say it should do
 Integration testing: ensure that the system communicates to other
systems correctly
 Regression testing: make sure that nothing else is broken when this is
implemented after making changes (Impact Analysis Testing).

 1.1.2. Different Approaches and Models for System Development:-

 1.1.2.1. Waterfall Model

Waterfall model is the simplest model of software development

paradigm. It says the all the phases of SDLC will function one after
another in linear manner. That is, when the first phase is finished then
only the second phase will start and so on.
Page 33
This model assumes that everything is carried out and taken place
perfectly as planned in the previous stage and there is no need to think
about the past issues that may arise in the next phase. This model does
not work smoothly if there are some issues left at the previous step. The
sequential nature of model does not allow us go back and undo or redo
our actions.
This model is best suited when developers already have designed and
developed similar software in the past and are aware of all its domains.

The Waterfall Model was the first Process Model to be introduced. It is

also referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for
software development.
The waterfall Model illustrates the software development process in a
linear sequential flow. This means that any phase in the development
process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall"
approach, the whole process of software development is divided into
separate phases. In this Waterfall model, typically, the outcome of one
phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the
Waterfall Model.

Page 34
The sequential phases in Waterfall model are −
Requirement Gathering and analysis − All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification document.
System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system
design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.
Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality, which is
referred to as Unit Testing.
Integration and Testing − All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post
integration the entire system is tested for any faults and failures.
Deployment of system − Once the functional and non-functional testing
is done; the product is deployed in the customer environment or released
into the market.
Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance
the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment.

Page 35
All these phases are cascaded to each other in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases. The
next phase is started only after the defined set of goals are achieved for
previous phase and it is signed off, so the name "Waterfall Model". In
this model, phases do not overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC
approach to be followed based on the internal and external factors. Some
situations where the use of Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support
the product.
 The project is short.

WATERFALL MODEL is a sequential model that divides software

development into pre-defined phases. Each phase must be completed
before the next phase can begin with no overlap between the phases. Each
phase is designed for performing specific activity during the SDLC
phase. It was introduced in 1970 by Winston Royce.

Different Phases of Waterfall Model in Software Engineering

Page 36
 Different phases Activities performed in each stage
Requirement  During this phase, detailed requirements of the
Gathering stage software system to be developed are gathered
from client
Design Stage  Plan the programming language, for
Example Java, PHP, .net
 or database like Oracle, MySQL, etc.
 Or other high-level technical details of the
project
Built Stage  After design stage, it is built stage, that is
nothing but coding the software
Test Stage  In this phase, you test the software to verify
that it is built as per the specifications given by
the client.
Deployment stage  Deploy the application in the respective
environment
Maintenance stage  Once your system is ready to use, you may
later require change the code as per customer
request

 When to use SDLC Waterfall Model :-

 Requirements are not changing frequently
 Application is not complicated and big
 Project is short
 Requirement is clear
 Environment is stable
 Technology and tools used are not dynamic and is stable
 Resources are available and trained

 Waterfall Model - Advantages

The advantages of waterfall development are that it allows for

departmentalization and control. A schedule can be set with deadlines for
each stage of development and a product can proceed through the
development process model phases one by one.

Page 37
 Development moves from concept, through design, implementation,
testing, installation, troubleshooting, and ends up at operation and
maintenance. Each phase of development proceeds in strict order.

Some of the major advantages of the Waterfall Model are as follows –

 Simple and easy to understand and use

 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

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.

 Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much

reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-documented
or thought upon in the concept stage.

The major disadvantages of the Waterfall Model are as follows −

 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
Page 38
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.

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.

Advantages and Disadvantages of Waterfall-Model :-

Advantages Dis-Advantages
 Before the next phase of  Error can be fixed only during
development, each phase must the phase
be completed
 Suited for smaller projects  It is not desirable for complex
where requirements are well project where requirement
defined changes frequently
 They should perform quality  Testing period comes quite late
assurance test (Verification and in the developmental process
Validation) before completing
each stage
 Elaborate documentation is  Documentation occupies a lot
done at every phase of the of time of developers and
software's development cycle testers
 Project is completely dependent  Clients valuable feedback
on project team with minimum cannot be included with
client intervention ongoing development phase

Page 39
 Any changes in software is  Small changes or errors that
made during the process of the arise in the completed software
development may cause a lot of problems

 Iterative Model:-
This model leads the software development process in iterations. It
projects the process of development in cyclic manner repeating every step
after every cycle of SDLC process.

The software is first developed on very small scale and all the steps are
followed which are taken into consideration. Then, on every next
iteration, more features and modules are designed, coded, tested and
added to the software. Every cycle produces a software, which is
complete in itself and has more features and capabilities than that of the
previous one.
After each iteration, the management team can do work on risk
management and prepare for the next iteration. Because a cycle includes
small portion of whole software process, it is easier to manage the
development process but it consumes more resources.

In the Iterative model, iterative process starts with a simple

implementation of a small set of the software requirements and iteratively
enhances the evolving versions until the complete system is implemented
and ready to be deployed.
An iterative life cycle model does not attempt to start with a full
specification of requirements. Instead, development begins by specifying
and implementing just part of the software, which is then reviewed to

Page 40
identify further requirements. This process is then repeated, producing a
new version of the software at the end of each iteration of the model.

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of the
software requirements and iteratively enhances the evolving versions
until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added. The
basic idea behind this method is to develop a system through repeated
cycles (iterative) and in smaller portions at a time (incremental).
The following illustration is a representation of the Iterative and
Incremental model −

Iterative and Incremental development is a combination of both iterative

design or iterative method and incremental build model for development.
"During software development, more than one iteration of the software
development cycle may be in progress at the same time." This process
may be described as an "evolutionary acquisition" or "incremental build"
approach."
In this incremental model, the whole requirement is divided into various
builds. During each iteration, the development module goes through the
requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release.
The process continues till the complete system is ready as per the
requirement.
The key to a successful use of an iterative software development lifecycle
is rigorous validation of requirements, and verification & testing of each
version of the software against those requirements within each cycle of
the model. As the software evolves through successive cycles, tests must
be repeated and extended to verify each version of the software.

Page 41
 Iterative Model - Application
Like other SDLC models, Iterative and incremental development has
some specific applications in the software industry. This model is most
often used in the following scenarios −
 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or
requested enhancements may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development
team while working on the project.
 Resources with needed skill sets are not available and are planned to be
used on contract basis for specific iterations.
 There are some high-risk features and goals which may change in the
future

What is Incremental Model?

Incremental Model is a process of software development where
requirements are broken down into multiple standalone modules of
software development cycle. Incremental development is done in steps
from analysis design, implementation, testing/verification, maintenance.

Each iteration passes through the requirements, design, coding and

testing phases. And each subsequent release of the system adds function
to the previous release until all designed functionality has been
implemented.

Page 42
 The system is put into production when the first increment is delivered.
The first increment is often a core product where the basic requirements
are addressed, and supplementary features are added in the next
increments. Once the core product is analyzed by the client, there is plan
development for the next increment.

Characteristics of an Incremental module includes

 System development is broken down into many mini development
projects
 Partial systems are successively built to produce a final total system
 Highest priority requirement is tackled first
 Once the requirement is developed, requirement for that increment are frozen

Incremental Phases Activities performed in incremental phases

Requirement  Requirement and specification of the software are

Analysis collected

Design  Some high-end function are designed during this

stage

Code  Coding of software is done during this stage

Test  Once the system is deployed, it goes through the

testing phase
When to use Incremental models?
 Requirements of the system are clearly understood
 When demand for an early release of a product arises
 When software engineering team are not very well skilled or trained
 When high-risk features and goals are involved
 Such methodology is more in use for web application and product based
companies
Page 43
  Iterative Model - Pros and Cons :-
The advantage of this model is that there is a working model of the
system at a very early stage of development, which makes it easier to find
functional or design flaws. Finding issues at an early stage of
development enables to take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to
large and bulky software development projects. This is because it is hard
to break a small software system into further small serviceable
increments/modules.

 The advantages of the Iterative and Incremental SDLC Model

are as follows −
 Some working functionality can be developed quickly and early in the
life cycle.
 Results are obtained early and periodically.
 Parallel development can be planned.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an
easily managed milestone.
 Easier to manage risk - High risk part is done first.
 With every increment, operational product is delivered.
 Issues, challenges and risks identified from each increment can be
utilized/applied to the next increment.
 Risk analysis is better.
 It supports changing requirements.
 Initial Operating time is less.
 Better suited for large and mission-critical projects.
 During the life cycle, software is produced early which facilitates
customer evaluation and feedback.

 The disadvantages of the Iterative and Incremental SDLC

Model are as follows −
 More resources may be required.
 Although cost of change is lesser, but it is not very suitable for changing
requirements.
 More management attention is required.
 System architecture or design issues may arise because not all
requirements are gathered in the beginning of the entire life cycle.
 Defining increments may require definition of the complete system.
Page 44
 Not suitable for smaller projects.
 Management complexity is more.
 End of project may not be known which is a risk.
 Highly skilled resources are required for risk analysis.
 Projects progress is highly dependent upon the risk analysis phase.

Advantages and Disadvantages of Incremental Model

Advantages Disadvantages

 The software will be generated  It requires a good planning

quickly during the software life designing
cycle

 It is flexible and less expensive  Problems might cause due to

to change requirements and system architecture as such not
scope all requirements collected up
front for the entire software
lifecycle

 Throughout the development  Each iteration phase is rigid

stages changes can be done and does not overlap each
other

 This model is less costly  Rectifying a problem in one

compared to others unit requires correction in all
the units and consumes a lot of
time

 A customer can respond to

each building

 Errors are easy to be identified

 1.1.2.2 Spiral Model :-

Spiral model is a combination of both, iterative model and one of the
SDLC model. It can be seen as if you choose one SDLC model and
combine it with cyclic process (iterative model).

Page 45
This model considers risk, which often goes un-noticed by most other
models. The model starts with determining objectives and constraints of
the software at the start of one iteration. Next phase is of prototyping the
software. This includes risk analysis. Then one standard SDLC model is
used to build the software. In the fourth phase of the plan of next iteration
is prepared.

What is Spiral Model?

Spiral Model is a risk-driven software development process model. It is
a combination of waterfall model and iterative model. Spiral Model helps
to adopt software development elements of multiple process models for
the software project based on unique risk patterns ensuring efficient
development process.
Each phase of spiral model in software engineering begins with a design
goal and ends with the client reviewing the progress. The spiral model in
software engineering was first mentioned by Barry Boehm in his 1986
paper.

Page 46
The development process in Spiral model in SDLC, starts with a small set
of requirement and goes through each development phase for those set of
requirements. The software engineering team adds functionality for the
additional requirement in every-increasing spirals until the application is
ready for the production phase. The below figure very well explain Spiral
Model:

Spiral Model
Diagram
Spiral Model Phases

Spiral Activities performed during phase

Model
Phases

Planning  It includes estimating the cost, schedule and

resources for the iteration. It also involves
understanding the system requirements for
continuous communication between the system
analyst and the customer

Risk  Identification of potential risk is done while risk

Analysis mitigation strategy is planned and finalized

Page 47
 Engineerin  It includes testing, coding and deploying software
g at the customer site

Evaluation  Evaluation of software by the customer. Also,

includes identifying and monitoring risks such as
schedule slippage and cost overrun

 1.1.2.3. Prototyping 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.

Page 48
Prototyping Model is a software development model in which prototype
is built, tested, and reworked until an acceptable prototype is achieved. It
also creates base to produce the final system or software. It works best in
scenarios where the project's requirements are not known in detail. It is an
iterative, trial and error method which takes place between developer and
client.

Page 49
Prototyping Model Phases

Prototyping Model has following six SDLC phases as follow:

Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the
requirements of the system are defined in detail. During the process, the
users of the system are interviewed to know what is their expectation
from the system.

Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage,
a simple design of the system is created. However, it is not a complete
design. It gives a brief idea of the system to the user. The quick design
helps in developing the prototype.

Step 3: Build a Prototype

In this phase, an actual prototype is designed based on the information
gathered from quick design. It is a small working model of the required
system.

Step 4: Initial user evaluation

In this stage, the proposed system is presented to the client for an initial
evaluation. It helps to find out the strength and weakness of the working
model. Comment and suggestion are collected from the customer and
provided to the developer.

Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the
prototype according to the user's feedback and suggestions.
This phase will not over until all the requirements specified by the user
are met. Once the user is satisfied with the developed prototype, a final
system is developed based on the approved final prototype.
Page 50
Step 6: Implement Product and Maintain
Once the final system is developed based on the final prototype, it is
thoroughly tested and deployed to production. The system undergoes
routine maintenance for minimizing downtime and prevent large-scale
failures.

Software Prototyping - Application

Software Prototyping is most useful in development of systems having
high level of user interactions such as online systems. Systems which
need users to fill out forms or go through various screens before data is
processed can use prototyping very effectively to give the exact look and
feel even before the actual software is developed.
Software that involves too much of data processing and most of the
functionality is internal with very little user interface does not usually
benefit from prototyping. Prototype development could be an extra
overhead in such projects and may need lot of extra efforts.

Prototyping is defined as the process of developing a working

replication of a product or system that has to be engineered. It offers a
small scale facsimile of the end product and is used for obtaining
customer feedback as described below:

The Prototyping Model is one of the most popularly used Software

Development Life Cycle Models (SDLC models).This model is used
when the customers do not know the exact project requirements
beforehand. In this model, a prototype of the end product is first
developed, tested and refined as per customer feedback repeatedly till a

Page 51
 final acceptable prototype is achieved which forms the basis for
developing the final product.
In this process model, the system is partially implemented before or
during the analysis phase thereby giving the customers an opportunity to
see the product early in the life cycle. The process starts by interviewing
the customers and developing the incomplete high-level paper model.
This document is used to build the initial prototype supporting only the
basic functionality as desired by the customer. Once the customer figures
out the problems, the prototype is further refined to eliminate them. The
process continues until the user approves the prototype and finds the
working model to be satisfactory.

Types of Prototyping Models

Four types of Prototyping models are:
1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype

Rapid Throwaway Prototype :-

Rapid throwaway is based on the preliminary requirement. It is quickly
developed to show how the requirement will look visually. The
customer's feedback helps drives changes to the requirement, and the
prototype is again created until the requirement is baselined.

In this method, a developed prototype will be discarded and will not be a

part of the ultimately accepted prototype. This technique is useful for
exploring ideas and getting instant feedback for customer requirements.

This technique offers a useful method of exploring ideas and getting

customer feedback for each of them. In this method, a developed
prototype need not necessarily be a part of the ultimately accepted
prototype. Customer feedback helps in preventing unnecessary design
faults and hence, the final prototype developed is of better quality.

Throwaway prototyping is also called as rapid or close ended

prototyping. This type of prototyping uses very little efforts with
minimum requirement analysis to build a prototype. Once the actual
requirements are understood, the prototype is discarded and the actual
system is developed with a much clear understanding of user
requirements.

Page 52
Evolutionary Prototyping :-
Here, the prototype developed is incrementally refined based on
customer's feedback until it is finally accepted. It helps you to save time
as well as effort. That's because developing a prototype from scratch for
every interaction of the process can sometimes be very frustrating.
This model is helpful for a project which uses a new technology that is
not well understood. It is also used for a complex project where every
functionality must be checked once. It is helpful when the requirement is
not stable or not understood clearly at the initial stage.

In this method, the prototype developed initially is incrementally refined

on the basis of customer feedback till it finally gets accepted. In
comparison to Rapid Throwaway Prototyping, it offers a better approach
which saves time as well as effort. This is because developing a prototype
from scratch for every iteration of the process can sometimes be very
frustrating for the developers.

Evolutionary prototyping also called as breadboard prototyping is based

on building actual functional prototypes with minimal functionality in the
beginning. The prototype developed forms the heart of the future
prototypes on top of which the entire system is built. By using
evolutionary prototyping, the well-understood requirements are included
in the prototype and the requirements are added as and when they are
understood.

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.

Incremental Prototyping :-

Page 53
 In incremental Prototyping, the final product is decimated into different
small prototypes and developed individually. Eventually, the different
prototypes are merged into a single product. This method is helpful to
reduce the feedback time between the user and the application
development team.

In this type of incremental Prototyping, the final expected product is

broken into different small pieces of prototypes and being developed
individually. In the end, when all individual pieces are properly
developed, then the different prototypes are collectively merged into a
single final product in their predefined order. It’s a very efficient
approach which reduces the complexity of the development process,
where the goal is divided into sub-parts and each sub-part is developed
individually. The time interval between the project begin and final
delivery is substantially reduced because all parts of the system are
prototyped and tested simultaneously. Of course, there might be the
possibility that the pieces just not fit together due to some lack ness in the
development phase – this can only be fixed by careful and complete
plotting of the entire system before prototyping starts.

Incremental prototyping refers to building multiple functional prototypes

of the various sub-systems and then integrating all the available
prototypes to form a complete system.

Extreme Prototyping:-

Extreme prototyping is used in the web development domain. It consists

of three sequential phases. First, a basic prototype with all the existing
pages is presented in the HTML format. Then the data processing is
simulated using a prototype services layer. Finally, the services are
implemented and integrated to the final prototype. This process is called
Extreme Prototyping used to draw attention to the second phase of the
process, where a fully functional UI is developed with very little regard to
the actual services.

Extreme prototyping method is mostly used for web development. It is

consists of three sequential phases.
1. Basic prototype with all the existing page is present in the HTML format.
2. You can simulate data process using a prototype services layer.
3. The services are implemented and integrated into the final prototype.

Page 54
This method is mainly used for web development. It is consists of three
sequential independent phases:
1) In this phase a basic prototype with all the existing static pages are
presented in the HTML format.
2) In the 2nd phase, Functional screens are made with a simulate data
process using a prototype services layer.
3) This is the final step where all the services are implemented and
associated with the final prototype.

This Extreme Prototyping method makes the project cycling and delivery
robust and fast, and keeps the entire developer team focus centralized on
products deliveries rather than discovering all possible needs and
specifications and adding un-necessitated features.

Page 55
 Best practices of Prototyping
Here, are a few things which you should watch for during the prototyping
process:
 You should use Prototyping when the requirements are unclear
 It is important to perform planned and controlled Prototyping.
 Regular meetings are vital to keep the project on time and avoid costly
delays.

Page 56
 The users and the designers should be aware of the prototyping issues and
pitfalls.
 At a very early stage, you need to approve a prototype and only then
allow the team to move to the next step.
 In software prototyping method, you should never be afraid to change
earlier decisions if new ideas need to be deployed.
 You should select the appropriate step size for each version.
 Implement important features early on so that if you run out of the time,
you still have a worthwhile system

 Advantages of the Prototyping Model

Here, are important pros/benefits of using Prototyping models:

 Users are actively involved in development. Therefore, errors can be

detected in the initial stage of the software development process.
 Missing functionality can be identified, which helps to reduce the risk of
failure as Prototyping is also considered as a risk reduction activity.
 Helps team member to communicate effectively
 Customer satisfaction exists because the customer can feel the product at
a very early stage.
 There will be hardly any chance of software rejection.
 Quicker user feedback helps you to achieve better software development
solutions.
 Allows the client to compare if the software code matches the software
specification.
 It helps you to find out the missing functionality in the system.
 It also identifies the complex or difficult functions.
 Encourages innovation and flexible designing.
 It is a straightforward model, so it is easy to understand.
 No need for specialized experts to build the model
 The prototype serves as a basis for deriving a system specification.
 The prototype helps to gain a better understanding of the customer's
needs.
 Prototypes can be changed and even discarded.
 A prototype also serves as the basis for operational specifications.
 Prototypes may offer early training for future users of the software
system.

 Reduce the risk of incorrect user requirement

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

 Increased user involvement in the product even before its

implementation.
 Since a working model of the system is displayed, the users get a better
understanding of the system being developed.
 Reduces time and cost as the defects can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily.
 Confusing or difficult functions can be identified.

 The customers get to see the partial product early in the life cycle. This
ensures a greater level of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for
refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of effort and cost,
besides enhancing the quality of the software.
 The developed prototype can be reused by the developer for more
complicated projects in the future.

 Flexibility in design.

 Disadvantages of the Prototyping Model :-

Here, are important cons/drawbacks of prototyping model:

 Prototyping is a slow and time taking process.

 The cost of developing a prototype is a total waste as the prototype is
ultimately thrown away.
 Prototyping may encourage excessive change requests.
 Some times customers may not be willing to participate in the iteration
cycle for the longer time duration.
 There may be far too many variations in software requirements when
each time the prototype is evaluated by the customer.
 Poor documentation because the requirements of the customers are
changing.

Page 58
 It is very difficult for software developers to accommodate all the
changes demanded by the clients.
 After seeing an early prototype model, the customers may think that the
actual product will be delivered to him soon.
 The client may lose interest in the final product when he or she is not
happy with the initial prototype.
 Developers who want to build prototypes quickly may end up building
sub-standard development solutions.
 An unstable/badly implemented prototype often becomes the final
product.
 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
 Difficult to know how long the project will last.
 Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.
 Prototyping tools are expensive.
 Special tools & techniques are required to build a prototype.
 It is a time-consuming process.
 Risk of insufficient requirement analysis owing to too much dependency
on the prototype.
 Users may get confused in the prototypes and actual systems.
 Practically, this methodology may increase the complexity of the system
as scope of the system may expand beyond original plans.
 Developers may try to reuse the existing prototypes to build the actual
system, even when it is not technically feasible.
 The effort invested in building prototypes may be too much if it is not
monitored properly.
 Costly with respect to time as well as money.
 There may be too much variation in requirements each time the prototype
is evaluated by the customer.
 Poor Documentation due to continuously changing customer
requirements.
 It is very difficult for developers to accommodate all the changes
demanded by the customer.
Page 59
  There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the
actual product to be delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal
solutions.
 The customer might lose interest in the product if he/she is not satisfied
with the initial prototype.

Note:- The Prototyping Model should be used when the requirements of

the product are not clearly understood or are unstable. It can also be used
if requirements are changing quickly. This model can be successfully
used for developing user interfaces, high technology software-intensive
systems, and systems with complex algorithms and interfaces. It is also a
very good choice to demonstrate the technical feasibility of the product.

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

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

and iterative development with no specific planning involved. The process of
writing the software itself involves the planning required for developing the
product.

Rapid Application Development focuses on gathering customer requirements

through workshops or focus groups, early testing of the prototypes by the
customer using iterative concept, reuse of the existing prototypes (components),
continuous integration and rapid delivery.

What is RAD?

Rapid application development is a software development methodology that

uses minimal planning in favor of rapid prototyping. A prototype is a working
model that is functionally equivalent to a component of the product.

Page 60
In the RAD model, the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for faster product
delivery. Since there is no detailed preplanning, it makes it easier to incorporate
the changes within the development process.

RAD projects follow iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and other
IT resources working progressively on their component or prototype.

The most important aspect for this model to be successful is to make sure that
the prototypes developed are reusable

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

developed faster and of higher quality through:

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

Page 61
RAD Model or Rapid Application Development model is a software
development process based on prototyping without any specific planning. In
RAD model, there is less attention paid to the planning and more priority is
given to the development tasks. It targets at developing software in a short span
of time.
SDLC RAD modeling has following phases
 Business Modeling
 Data Modeling
 Process Modeling
 Application Generation
 Testing and Turnover

Page 62
RAD Model Diagram

It focuses on input-output source and destination of the information. It

emphasizes on delivering projects in small pieces; the larger projects are
divided into a series of smaller projects. The main features of RAD modeling
are that it focuses on the reuse of templates, tools, processes, and code.

RAD Model in Software Engineering

Page 63
Different Phases of RAD Model

There are following five major phases of Rapid Application Development Model

RAD Model Phases Activities performed in RAD Modeling

Business Modeling  On basis of the flow of information and

distribution between various business channels,
the product is designed

Data Modeling  The information collected from business

modeling is refined into a set of data objects that
are significant for the business

Process Modeling  The data object that is declared in the data

modeling phase is transformed to achieve the
information flow necessary to implement a
business function

Application  Automated tools are used for the construction of

Generation the software, to convert process and data models
into prototypes

Testing and  As prototypes are individually tested during

Turnover every iteration, the overall testing time is
reduced in RAD.

Page 64
The various phases of RAD are as follows:

1.Business Modeling: 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.

The business model for the product under development is designed in terms of
flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the
information processed and what are the factors driving successful flow of
information.

2.Data Modeling: 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.

The information gathered in the Business Modelling phase is reviewed and

analyzed to form sets of data objects vital for the business. The attributes of all
data sets is identified and defined. The relation between these data objects are
established and defined in detail in relevance to the business model.

3. Process Modeling: 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.

The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process
descriptions for adding, deleting, retrieving or modifying a data object are
given.

4. Application Generation: Automated tools are used to facilitate

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

Page 65
 The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.

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.

The overall testing time is reduced in the RAD model as the prototypes
are independently tested during every iteration. However, the data flow
and the interfaces between all the components need to be thoroughly
tested with complete test coverage. Since most of the programming
components have already been tested, it reduces the risk of any major
issues.
The following illustration describes the RAD Model in detail.

Page 66
When to use RAD Methodology?

 When a system needs to be produced in a short span of time (2-3 months)

 When the requirements are known

 When the user will be involved all through the life cycle

 When technical risk is less

 When there is a necessity to create a system that can be modularized in 2-

3 months of time

 When a budget is high enough to afford designers for modeling along

with the cost of automated tools for code generation

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.

Advantages of RAD Model Disadvantages of RAD Model

 Flexible and adaptable to  It can't be used for smaller

changes projects

 It is useful when you have to  Not all application is

reduce the overall project risk compatible with RAD

 It is adaptable and flexible to  When technical risk is high, it

changes is not suitable

Page 67
  It is easier to transfer  If developers are not
deliverables as scripts, high- committed to delivering
level abstractions and software on time, RAD
intermediate codes are used projects can fail

 Due to code generators and code  Reduced features due to time

reuse, there is a reduction of boxing, where features are
manual coding pushed to a later version to
finish a release in short period

 Due to prototyping in nature,  Reduced scalability occurs

there is a possibility of lesser because a RAD developed
defects application begins as a
prototype and evolves into a
finished application

 Each phase in RAD delivers  Progress and problems

highest priority functionality to accustomed are hard to track
client as such there is no
documentation to demonstrate
what has been done

 With less people, productivity  Requires highly skilled

can be increased in short time designers or developers

 1.1.2.5 Rational Unified Process (RUP) :-

The Rational Unified Process (RUP) is an iterative software development
process framework created by the Rational Software Corporation, a division
of IBM since 2003. RUP is not a single concrete prescriptive process, but rather
an adaptable process framework, intended to be tailored by the development
organizations and software project teams that will select the elements of the
process that are appropriate for their needs. RUP is a specific implementation of
the Unified Process.

Rational Software originally developed the rational unified process as a

software process product.

RUP building blocks :-

RUP is based on a set of building blocks and content elements, describing what
is to be produced, the necessary skills required and the step-by-step explanation

Page 68
describing how specific development goals are to be achieved. The main
building blocks, or content elements, are the following:
 Roles (who) – A role defines a set of related skills, competencies and
responsibilities.
 Work products (what) – A work product represents something resulting
from a task, including all the documents and models produced while
working through the process.
 Tasks (how) – A task describes a unit of work assigned to a Role that
provides a meaningful result.
Within each iteration, the tasks are categorized into nine disciplines:

 Six "engineering disciplines"

o Business modeling
o Requirements
o Analysis and design
o Implementation
o Test
o Deployment

 Three supporting disciplines

o Configuration and change management
o Project management
o Environment

Four project life-cycle phases :-

The RUP has determined a project life-cycle consisting of four phases. These
phases allow the process to be presented at a high level in a similar way to how
a 'waterfall'-styled project might be presented, although in essence the key to the
process lies in the iterations of development that lie within all of the phases.
Also, each phase has one key objective and milestone at the end that denotes the
objective being accomplished. The visualization of RUP phases and disciplines
over time is referred to as the RUP hump chart.

Page 69
Page 70
  Inception phase :-

The primary objective is to scope the system adequately as a basis for validating
initial costing and budgets. In this phase the business case which includes
business context, success factors (expected revenue, market recognition, etc.),
and financial forecast is established. To complement the business case, a basic
use case model, project plan, initial risk assessment and project description (the
core project requirements, constraints and key features) are generated. After
these are completed, the project is checked against the following criteria:
 Stakeholder concurrence on scope definition and cost/schedule estimates.
 Requirements understanding as evidenced by the fidelity of the primary
use cases.
 Credibility of the cost/schedule estimates, priorities, risks, and
development process.
 Depth and breadth of any architectural prototype that was developed.
 Establishing a baseline by which to compare actual expenditures versus
planned expenditures.

The idea for the project is stated. The development team determines if the
project is worth pursuing and what resources will be needed.

 Communication and planning are main.

 Identifies Scope of the project using use-case model allowing managers

to estimate costs and time required.

 Customers requirements are identified and then it becomes easy to make

a plan of the project.

 Project plan, Project goal, risks, use-case model, Project description, are
made.

 Project is checked against the milestone criteria and if it couldn’t pass

these criteria then project can be either cancelled or redesigned.

If the project does not pass this milestone, called the life cycle objective
milestone, it either can be cancelled or repeated after being redesigned to better
meet the criteria.

 Elaboration phase :-
Page 71
The primary objective is to mitigate the key risk items identified by analysis up
to the end of this phase. The elaboration phase is where the project starts to take
shape. In this phase the problem domain analysis is made and the architecture of
the project gets its basic form.
The outcome of the elaboration phase is:
 A use-case model in which the use-cases and the actors have been
identified and most of the use-case descriptions are developed. The use-
case model should be 80% complete.
 A description of the software architecture in a software system
development process.
 An executable architecture that realizes architecturally significant use
cases.
 Business case and risk list which are revised.
 A development plan for the overall project.
 Prototypes that demonstrably mitigate each identified technical risk.
 A preliminary user manual (optional)
This phase must pass the lifecycle architecture milestone criteria answering the
following questions:
 Is the vision of the product stable?
 Is the architecture stable?
 Does the executable demonstration indicate that major risk elements are
addressed and resolved?
 Is the construction phase plan sufficiently detailed and accurate?
 Do all stakeholders agree that the current vision can be achieved using
current plan in the context of the current architecture?
 Is the actual vs. planned resource expenditure acceptable?

The project's architecture and required resources are further evaluated.

Developers consider possible applications of the software and costs associated
with the development

 Planning and modeling are main.

 Detailed evaluation, development plan is carried out and diminish
the risks.
 Revise or redefine use-case model (approx. 80%), business case,
risks.
 Again, checked against milestone criteria and if it couldn’t pass
these criteria then again project can be cancelled or redesigned.
 Executable architecture baseline.

Page 72
If the project cannot pass this milestone, there is still time for it to be canceled
or redesigned. However, after leaving this phase, the project transitions into a
high-risk operation where changes are much more difficult and detrimental
when made.

The key domain analysis for the elaboration is the system architecture.

 Construction phase :-

The primary objective is to build the software system. In this phase, the main
focus is on the development of components and other features of the system.
This is the phase when the bulk of the coding takes place. In larger projects,
several construction iterations may be developed in an effort to divide the use
cases into manageable segments to produce demonstrable prototypes.

The project is developed and completed. The software is designed, written, and
tested.

 Project is developed and completed.

 System or source code is created and then testing is done.
 Coding takes place.

 Transition phase :-

The primary objective is to 'transit' the system from development into

production, making it available to and understood by the end user. The activities
of this phase include training the end users and maintainers and beta testing the
system to validate it against the end users' expectations. The system also goes
through an evaluation phase, any developer which is not producing the required
work is replaced or removed. The product is also checked against the quality
level set in the Inception phase.
If all objectives are met, the product release milestone is reached and the
development cycle is finished.

The software is released to the public. Final adjustments or updates are made
based on feedback from end users.

 Final project is released to public.

 Transit the project from development into production.
Page 73
  Update project documentation.
 Beta testing is conducted.
 Defects are removed from project based on feedback from public.
 Project is maintained and updated accordingly

The RUP development methodology provides a structured way for companies to

envision create software programs. Since it provides a specific plan for each
step of the development process, it helps prevent resources from being wasted
and reduces unexpected development costs.

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.

The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated
and descriptive ‘System Requirements Specification’ document.
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

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

When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.

Referencing to this information, the analysts does a detailed study about

whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in terms
of implementation, contribution of project to organization, cost constraints and

Page 75
as per values and objectives of the organization. It explores technical aspects of
the project and product such as usability, maintainability, productivity and
integration ability.

The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or
not the project should be undertaken.

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.

Page 76
Requirement elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and

end users and know their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous or there are
some conflicts in requirements of various stakeholders, if they are, it is
then negotiated and discussed with stakeholders. Requirements may then
be prioritized and reasonably compromised.

Page 77
 The requirements come from various stakeholders. To remove the
ambiguity and conflicts, they are discussed for clarity and correctness.
Unrealistic requirements are compromised reasonably.

 Documentation - All formal & informal, functional and non-functional

requirements are documented and made available for next phase
processing.

Requirement Elicitation Techniques

Page 78
Requirements Elicitation is the process to find out the requirements for an
intended software system by communicating with client, end users, system users
and others who have a stake in the software system development.
There are various ways to discover requirements
Interviews
Interviews are strong medium to collect requirements. Organization may
conduct several types of interviews such as:
 Structured (closed) interviews, where every single information to gather
is decided in advance, they follow pattern and matter of discussion
firmly.
 Non-structured (open) interviews, where information to gather is not
decided in advance, more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the
table.
 Group interviews which are held between groups of participants. They
help to uncover any missing requirement as numerous people are
involved.
Surveys
Organization may conduct surveys among various stakeholders by querying
about their expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options
is handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned
in the questionnaire, the issue might be left unattended.

Page 79
Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the
domain can be a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for
user to interpret the features of intended software product. It helps giving better
idea of requirements. If there is no software installed at client’s end for
developer’s reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the
actual working of the existing installed systems. They observe the workflow at
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the software.
Software Requirement Specification (SRS) :

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.

When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.

Page 80
Referencing to this information, the analysts does a detailed study about
whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in terms
of implementation, contribution of project to organization, cost constraints and
as per values and objectives of the organization. It explores technical aspects of
the project and product such as usability, maintainability, productivity and
integration ability.

The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or
not the project should be undertaken.

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.

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.

Page 81
After requirement specifications are developed, the requirements mentioned in
this document are validated. User might ask for illegal, impractical solution or
experts may interpret the requirements incorrectly. This results in huge increase
in cost if not nipped in the bud. Requirements can be checked against following
conditions -

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

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.

Page 82
Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software
development project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible (understandable)
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

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 (understandable)
o Modifiable

o Verifiable
Page 83
 o Prioritized
o Unambiguous
o Traceable
o Credible source
o User Interface requirements
o UI is an important part of any software or hardware or hybrid system. A
software is widely accepted if it is -
o easy to operate
o quick in response
o effectively handling operational errors
o providing simple yet consistent user interface
o User acceptance majorly depends upon how user can use the software. UI
is the only way for users to perceive the system. A well performing
software system must also be equipped with attractive, clear, consistent
and responsive user interface. Otherwise the functionalities of software
system can not be used in convenient way. A system is said be good if it
provides means to use it efficiently. User interface requirements are
briefly mentioned below -
o Content presentation
o Easy Navigation
o Simple interface
o Responsive
o Consistent UI elements
o Feedback mechanism
o Default settings
o Purposeful layout
o Strategically use of color and texture.
o Provide help information
o User centric approach
o Group based view settings.

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

Page 84
 documented in different forms. The functional requirements are
describing the behavior of the system as it correlates to the system's
functionality.

Requirements, which are related to functional aspect of software fall into

this category.

They define functions and functionality within and from the software
system.

Examples -

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.

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.

Requirements, which are not related to functional aspect of software, fall into
this category. They are implicit or expected characteristics of software, which
users make assumption of.

Non-functional requirements include -

 Security

Page 85
  Logging
 Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility
Requirements are categorized logically as
 Must Have : Software cannot be said operational without them.
 Should have : Enhancing the functionality of software.
 Could have : Software can still properly function with these
requirements.
 Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is

a matter of debate with stakeholders and negation, whereas ‘could have’ and
‘wish list’ can be kept for software updates.

Four Phases of Requirement Engineering:-

Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining service
provided by the system. Requirements Engineering Process consists of the
following main activities:

 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management

Requirements Elicitation:

It is related to the various ways used to gain knowledge about the project
domain and requirements. The various sources of domain knowledge include
customers, business manuals, the existing software of same type, standards and
other stakeholders of the project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, Elicitation does not
produce formal models of the requirements understood. Instead, it widens the

Page 86
domain knowledge of the analyst and thus helps in providing input to the next
stage.

Requirements Specification:

This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required
which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.

Requirements verification and validation:

Verification:

It refers to the set of tasks that ensures that the software correctly implements a
specific function.

Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
 The requirements should be consistent with all the other requirements i.e
no two requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used
for this.

Requirements Management :-
Requirement management is the process of analyzing, documenting, tracking,
prioritizing and agreeing on the requirement and controlling the communication
to relevant stakeholders. This stage takes care of the changing nature of
requirements. It should be ensured that the SRS is as modifiable as possible so
Page 87
as to incorporate changes in requirements specified by the end users at later
stages too. Being able to modify the software as per requirements in a
systematic and controlled manner is an extremely important part of the
requirements engineering process.

Structure and Content of SRS :-

A software requirements specification (SRS) is a description of a software
system to be developed. It is modeled after business requirements
specification , also known as a stakeholder requirements specification .The
software requirements specification lays out functional and non-functional
requirements, and it may include a set of use cases that describe user
interactions that the software must provide to the user for perfect interaction.
Software requirements specification establishes the basis for an agreement
between customers and contractors or suppliers on how the software product
should function. Software requirements specification is a rigorous assessment of
requirements before the more specific system design stages, and its goal is to
reduce later redesign. It should also provide a realistic basis for estimating
product costs, risks, and schedules. Used appropriately, software requirements
specifications can help prevent software project failure.
The software requirements specification document lists sufficient and necessary
requirements for the project development. To derive the requirements, the
developer needs to have clear and thorough understanding of the products under
development. This is achieved through detailed and continuous communications
with the project team and customer throughout the software development
process
An example organization of an SRS is as follows:
1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces

2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints

Page 88
 2. Design constraints
1. Operations
2. Site adaptation requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Performance requirements
3. Logical database requirement
4. Software system attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
5. Functional requirements
1. Functional partitioning
2. Functional description
3. Control description
6. Environment characteristics
1. Hardware
2. Peripherals
3. Users
7. Other

A Software Requirements Specification (SRS) is a document that describes the

nature of a project, software or application. In simple words, SRS document is a
manual of a project provided it is prepared before you kick-start a
project/application. This document is also known by the names SRS report,
software document. A software document is primarily prepared for a project,
software or any kind of application.
There are a set of guidelines to be followed while preparing the software
requirement specification document. This includes the purpose, scope,
functional and nonfunctional requirements, software and hardware requirements

of the project. In addition to this, it also contains the information about

environmental conditions required, safety and security requirements, software
quality attributes of the project etc.

Page 89
A Software requirements specification document describes the intended
purpose, requirements and nature of software to be developed. It also includes
the yield and cost of the software.

In this document, flight management project is used as an example to explain

few points.

Table of Contents

Page 90
Page 91
1. INTRODUCTION
1.1 PURPOSE
The purpose of this document is to build an online system to manage flights and
passengers to ease the flight management. <<Include the purpose as applicable to
your project >>
1.2 DOCUMENT CONVENTIONS
This document uses the following conventions. <<Include the conventions as per
your application >>

DB Database

DDB Distributed Database

ER Entity Relationship

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS

This project is a prototype for the flight management system and it is restricted within
the college premises. This has been implemented under the guidance of college
professors. This project is useful for the flight management team and as well as to
the passengers.

1.4 PROJECT SCOPE

The purpose of the online flight management system is to ease flight management
and to create a convenient and easy-to-use application for passengers, trying to buy
airline tickets. The system is based on a relational database with its flight
management and reservation functions. We will have a database server supporting
hundreds of major cities around the world as well as thousands of flights by various
airline companies. Above all, we hope to provide a comfortable user experience
along with the best pricing available.

1.5 REFERENCES
www.irtc.co.in
www.airindia.com

2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
A distributed airline database system stores the following information.
 Flight details:

Page 92
  It includes the originating flight terminal and destination terminal, along
with the stops in between, the number of seats booked/available seats
between two destinations etc.

 Customer description:

It includes customer code, name, address and phone number. This

information may be used for keeping the records of the customer for any
emergency or for any other kind of information.

 Reservation description:

It includes customer details, code number, flight number, date of booking,

date of travel.

2.2 PRODUCT FEATURES

The major features of airline database system as shown in below entity–
relationship model (ER model)

Page 93
The diagram shows the layout of airline database system – entity–relationship
model

2.3 USER CLASS and CHARACTERISTICS

Page 94
Users of the system should be able to retrieve flight information between two
given cities with the given date/time of travel from the database. A route from
city A to city B is a sequence of connecting flights from A to B such that: a)
there are at most two connecting stops, excluding the starting city and
destination city of the trip, b) the connecting time is between one to two hours.
The system will support two types of user privileges, Customer, and Employee.
Customers will have access to customer functions, and the employees will have
access to both customer and flight management functions. The customer should
be able to do the following functions:
 Make a new reservation

• One-way

• Round-Trip

• Multi-city

• Flexible Date/time

• Confirmation

 Cancel an existing reservation

 View his itinerary

The Employee should have following management functionalities:

 CUSTOMER FUNCTIONS.

• Get all customers who have seats reserved on a given flight.

• Get all flights for a given airport.

• View flight schedule.

• Get all flights whose arrival and departure times are on time/delayed.

• Calculate total sales for a given flight.

 ADMINISTRATIVE

Page 95
 • Add/Delete a flight

• Add a new airport

• Update fare for flights.

• Add a new flight leg instance.

• Update departure/arrival times for flight leg instances.

Each flight has a limited number of available seats. There are a number of
flights which depart from or arrive at different cities on different dates and time.

2.4 OPERATING ENVIRONMENT

Operating environment for the airline management system is as listed below.
<<Include the details as per your application >>
 distributed database
 client/server system
 Operating system: Windows.
 database: sql+ database
 platform: vb.net/Java/PHP
2.5 DESIGN and IMPLEMENTATION CONSTRAINTS
1. The global schema, fragmentation schema, and allocation schema.
2. SQL commands for above queries/applications
3. How the response for application 1 and 2 will be generated. Assuming
these are global queries. Explain how various fragments will be combined
to do so.
4. Implement the database at least using a centralized database management
system.
2.6 ASSUMPTION DEPENDENCIES
Let us assume that this is a distributed airline management system and it is used
in the following application:
 A request for booking/cancellation of a flight from any source to any
destination, giving connected flights in case no direct flight between the
specified Source-Destination pair exist.
 Calculation of high fliers (most frequent fliers) and calculating
appropriate reward points for these fliers.

Page 96
Assuming both the transactions are single transactions, we have designed a
distributed database that is geographically dispersed at four cities Delhi,
Mumbai, Chennai, and Kolkatta as shown in fig. below.

3. SYSTEM FEATURES
 DESCRIPTION and PRIORITY
The airline reservation system maintains information on flights, classes of seats,
personal preferences, prices, and bookings. Of course, this project has a high
priority because it is very difficult to travel across countries without prior
reservations.
 STIMULUS/RESPONSE SEQUENCES
 Search for Airline Flights for two Travel cities
 Displays a detailed list of available flights and make a
“Reservation” or Book a ticket on a particular flight.
 Cancel an existing Reservation.
 FUNCTIONAL REQUIREMENTS
Other system features include:
DISTRIBUTED DATABASE:
Distributed database implies that a single application should be able to operate
transparently on data that is spread across a variety of different databases and
connected by a communication network as shown in below figure.

Page 97
Distributed database located in four different cities

CLIENT/SERVER SYSTEM

The term client/server refers primarily to an architecture or logical division of

responsibilities, the client is the application (also known as the front-end), and
the server is the DBMS (also known as the back-end).
A client/server system is a distributed system in which,
 Some sites are client sites and others are server sites.
 All the data resides at the server sites.
 All applications execute at the client sites.

4. EXTERNAL INTERFACE REQUIREMENTS

4.1 USER INTERFACES
 Front-end software: Vb.net version
 Back-end software: SQL+
4.2 HARDWARE INTERFACES
 Windows.
 A browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES
Following are the software used for the flight management online application.
<<Include the software details as per your project >>
Software used Description

We have chosen Windows operating system for its

Operating system best support and user-friendliness.

To save the flight records, passengers records we

Database have chosen SQL+ database.

To implement the project we have chosen Vb.Net

VB.Net language for its more interactive support.

Page 98
4.4 COMMUNICATION INTERFACES
This project supports all types of web browsers. We are using simple electronic
forms for the reservation forms, ticket booking etc.

5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps involved to perform the implementation of airline database are as
listed below.
A) E-R DIAGRAM
The E-R Diagram constitutes a technique for representing the logical structure
of a database in a pictorial manner. This analysis is then used to organize data as
a relation, normalizing relation and finally obtaining a relation database.
 ENTITIES: Which specify distinct real-world items in an application.
 PROPERTIES/ATTRIBUTES: Which specify properties of an entity
and relationships.
 RELATIONSHIPS: Which connect entities and represent meaningful
dependencies between them.

Page 99
The diagram shows the ER diagram of airline database

B) NORMALIZATION:
The basic objective of normalization is to reduce redundancy which means that
information is to be stored only once. Storing information several times leads to
wastage of storage space and increase in the total size of the data stored.
If a database is not properly designed it can give rise to modification anomalies.
Modification anomalies arise when data is added to, changed or deleted from a
database table. Similarly, in traditional databases as well as improperly designed
relational databases, data redundancy can be a problem. These can be
eliminated by normalizing a database.
Normalization is the process of breaking down a table into smaller tables. So
that each table deals with a single theme. There are three different kinds of
modifications of anomalies and formulated the first, second and third normal
forms (3NF) is considered sufficient for most practical purposes. It should be

Page 100
considered only after a thorough analysis and complete understanding of its
implications.

5.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to
catastrophic failure, such as a disk crash, the recovery method restores a past
copy of the database that was backed up to archival storage (typically tape) and
reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed up log, up to the time of failure.

5.3 SECURITY REQUIREMENTS

Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors
must choose their database partner carefully.

5.4 SOFTWARE QUALITY ATTRIBUTES

 AVAILABILITY: The flight should be available on the specified date
and specified time as many customers are doing advance reservations.
 CORRECTNESS: The flight should reach start from correct start
terminal and should reach the correct destination.
 MAINTAINABILITY: The administrators and flight in chargers should
maintain correct schedules of flights.
 USABILITY: The flight schedules should satisfy a maximum number of
customers needs.

IEEE Standard format :-

1.Overview
1.1 Scope
2. Reference

3. Definition
3.1 Contract
3.2 Customer
3.3 Supplier
3.4 User

4. Consideration of producing good SRS

4.1 Nature of SRS (Functionality, External Interface, Performance,
Attributes, Design Constraints)
4.2 Environment of SRS

Page 101
4.3 Characteristics of good SRS (Correct, Complete, consistent
, unambiguous, verifiable, Modifiable , Traceable )
4.4 Prototyping
4.5 Design in SRS
4.6 Project requirement in SRS
5. Parts of an SRS
5.1 Introduction
5.1.1 Purpose
5.1.2 Scope
5.1.3 Definition
5.1.4 References
5.1.5 Overview
5.2 Overall description
5.2.1 Product Perspective
5.2.2 System Interface
5.2.3 User Interface
5.2.4 Hardware Interface
5.2.5 Software Interface
5.2.6 Communication Interfaces (e.g. local network protocols)
5.3 Specific Requirement
5.3.1 External Interface
5.3.2 Functions
5.3.3 Performance Requirement
5.3.4 Logical Database Requirement
5.3.5 Design Constraints
5.3.6 Software System Attribute
5.3.6.1 Reliability
5.3.6.2 Availability
5.3.6.3 Security
5.3.6.4 Maintainability
5.3.6.5 Portability
5.3.7 Organizing the specific requirement
5.3.7.1 System Mode
5.3.7.2 User Class
5.3.7.3 Object
5.3.7.4 Feature
5.3.7.5 Stimulus
5.3.7.6 Response
5.3.7.7 Functional Hierarchy
5.3.8 Additional Comment
5.4 Supporting Information
5.4.1 Table of Content & Index
Page 102
 5.4.2 Appendixes

Note :-
 User Interface: - The logical characteristics of each interface between
the software product and its users. All the aspects of optimizing the
interface with the person who must use the system

 Hardware Interface: This should specify the logical characteristics of

each interface between the software product and the hardware
components of the system. This includes configuration characteristics
(number of ports, instruction sets, etc.). It also covers such matters as
what devices are to be supported, how they are to be supported, and
protocols. For example, terminal support may specify full-screen support
as opposed to line-by-line support.

 Software interfaces
This should specify the use of other required software products (e.g., a data
management system, an operating system, or a mathematical package), and
interfaces with other application systems (e.g., the linkage between an accounts
receivable system and a general ledger system). For each required software
product

following should be provided:

- Name;
- Mnemonic;
- Specification number;
- Version number;
- Source.

 Logical database requirements

This should specify the logical requirements for any information that is to be
placed into a database. This may include the following:

a) Types of information used by various functions;

b) Frequency of use;
c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements

Page 103
  System mode :- Some systems behave quite differently depending on the
mode of operation. For example, a control system may have different sets
of functions depending on its mode: training, normal, or emergency. The
choice depends on whether interfaces and performance are dependent on
mode.
 User class
Some systems provide different sets of functions to different classes of users.
For example, an elevator control system presents different capabilities to
passengers, maintenance workers, and fire fighters.
 Objects
Objects are real-world entities that have a counterpart within the system. For
example, in a patient monitoring system, objects include patients, sensors,
nurses, rooms, physicians, medicines, etc. Associated with each object is a set
of attributes (of that object) and functions (performed by that object). These
functions are also called services, methods, or processes
 Stimulus
Some systems can be best organized by describing their functions in terms of
stimuli. For example, the functions of an automatic aircraft landing system may
be organized into sections for loss of power, wind shear sudden change in roll,
vertical velocity excessive, etc
 Response
Some systems can be best organized by describing all the functions in support
of the generation of a response. For example, the functions of a personnel
system may be organized into sections corresponding to all functions associated
with generating paychecks, all functions associated with generating a current
list of employees, etc.

 Functional hierarchy
When none of the above organizational schemes prove helpful, the overall
functionality can be organized into a hierarchy of functions organized by either
common inputs, common outputs, or common internal data access. Data flow
diagrams and data dictionaries can be used to show the relationships between
and among the functions and data.

Page 104
(Another) SRS Format With IEEE Standard :-
1. Introduction
a. Background
b. Overall Description
c. Environmental Characteristics
i. Hardware
ii. Peripherals
iii. People
d. Interfaces
i. Interface with Device
ii. Interface with OS
iii. Interface with Database used
iv. Interface with the user
e. Constraints

2. Functional Requirements
a. Functional Partitioning
b. Functional Description
c. Control Description
3. Non Functional Requirements

4. Behavioral Description
a. System State
b. Event &Action

5. Validation Criteria
a. Performance Bound
b. Classes of Test
c. Response to undesired events

Page 105