Software Engineering

Unit 4: Requirement Analysis

Requirement Analysis

Requirements are descriptions of the services that a software system

must provide and the constraints under which it must operate.
Requirements analysis is critical to the success or failure of systems or
software project. The requirements should be documented, actionable,
measurable, testable, traceable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system
design.

Software requirements are defines as follow:

 A condition or capability needed by a user to solve a
problem or achieve an objective.
 A condition that must be met or possessed by a system or
system components to satisfy a specification or other
formality imposed documents.

Requirement analysis also called requirement engineering- is the

process of determining user expectation for a new or modified product.
It is the task that determines the need or conditions to meet product
of the user.

Requirement analysis can be defined as a subset of software

engineering that mainly focuses on the use of various tools and
techniques for development and management of software
requirements.

Requirement analysis involves frequent communication with the

system user to determine specific feature expectations, resolution of
conflict or ambiguity in requirements as demanded by various users or
groups of users and documentation of all aspects of the project
development process from start to finish.

Focus: “What” instead of “How”

Input: Software project plan and system specification
Output: Software Requirement specification document.
Provides the software engineer with models that can

By: Heta S. Desai Page 1

 Software Engineering

be translated into data, architectural, interface and

procedure design.
Who performs: System Analysts
(Basic of requirement Analysis)

Types of Requirement:

The requirements are classified into three categories:

 Functional requirement: (Behavioral
Requirement)
o Statements of services that the system should
provide, how the system should react to
particular inputs and how the system should
behave in particular situations.
o Describe functionality or system services.
o Functional user requirements may be high-level
statements of what the system should do;
functional system requirements should describe
the system services in detail.
 Non- Functional requirement: (Quality
Requirement)
o Related to system attributes like reliability and
response time.
o Arise due to user requirements, budget
limitations, and organizational policy.
o Are not directly related to any particular function
provided by the system.

 Domain requirement:
o Requirements which are derived from application
domain for a system instead from the needs of
the user are known as domain requirements.
o Describe system characteristics and features that
reflect the domain.
o If domain requirements are not satisfied, the
system may be unworkable.

Software requirement analysis is separated into five areas of

efforts:
By: Heta S. Desai Page 2
 Software Engineering

 Problem reorganization or System

understanding:
 Discover and understand the system
requirement
 Refine the requirement
 Evaluation:
 What is the alternative solution?
 Focus on what solution should be selected
or used instead of how to implement a
solution.
 Modeling:
 Required data
 Information and control flow
 Operation and behavior
 Specification:
 Software functions and performance
 Interface between system elements
 System constraint
 Review:
 Requirement review is carried out to find
out the following problems:
o Lack of conformance to quality
standards
o Errors in requirements analysis
 Review team consists of software
engineers, users and other stakeholders
who inspect the specification to guarantee
that the problems related with consistency,
errors are detected and corrected.

By: Heta S. Desai Page 3

 Software Engineering

Requirement Analysis Process:

Requirements analysis is the first stage in the systems
engineering process and software development process. Requirements
analysis in systems engineering and software engineering,
encompasses those tasks that go into determining the needs or
conditions to meet for a new or altered product, taking account of the
possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users.
Requirements analysis is critical to the success of a development
project. Requirements must be actionable, measurable, testable,
related to identified business needs or opportunities.

(Requirement Analysis Process)

1) Domain understanding:
Domain understanding means, understanding of application
to be developed.
2) Requirement collection:
It is the process of interacting with customers or users to
discover the requirements for the system.
3) Requirement classification:

By: Heta S. Desai Page 4

 Software Engineering

After the requirements are gathered, they are grouped and

classified according to functional and non-functional
requirements.
4) Conflict resolution:
Many times, when the multiple clients or users are involved
requirements may be conflict. Conflicts need to be resolved
keeping in mind the overall objective.
5) Prioritization:
Here, requirements are classified and listed according to
their importance.
6) Requirements validation:
Check and validate the gathers required requirements to
see if they are complete, correct and sound.

Requirement gathering Techniques:

Requirement gathering is carried out to obtain the requirements

from system users, customers and stockholders. This process is also
sometimes called as requirements gathering.
Before requirements can be analyzed, modeled or specified they
must be gathered through gathering techniques.
Following are common fact finding or information gathering
methods:
1) Interviews
2) Questionnaires
3) Record review
4) Observation
5) Joint Application Development(JAD)
6) FAST
7) Rapid Application Development(RAD)
8) Sampling of existing documentation, forms and
databases.

1) Interviews:
Interview is fact finding technique where two parties
work together; one person acts as an interviewer and other
as interviewee. The person who collects information is
By: Heta S. Desai Page 5
 Software Engineering

known as system analyst, who plays the role of interviewer.

System analyst collects fact from individuals who are known
as interviewees.
The interviewees are usually present user of the
existing system or possible user of the proposed system.

Types of Interview:
1) Structured:
 Structured interviews are those where the
interviewee is asked a standard set of
questions in a particular order.
 All interviewees are asked the same set of
questions.

2) Unstructured:
 The unstructured interviews are undertaken in
a question and answer format.
 More flexible than structured interview and
can be very rightly used to gather general
information about the system.

Advantages:
 Beneficial for those individuals who cannot
communicate effectively in writing.
 Allow the analyst to determine are of confusion and
indicates to points for resistance to the proposed
system.
 Permit the interviewees to replay freely and openly
to any type of question.
Disadvantages:
 This technique fails if suitable environment is not
provided for conducting interview.
 Interview can be subject to bias if the interviewer
has a closed mind about the difficulty.

2) Questionnaires:
It is a technique used to extract information from number
of people. Questionnaires gather data from both large and small
By: Heta S. Desai Page 6
 Software Engineering

groups of people. This method can be adopted and used only by

a skilled analyst. Developing of questionnaires requires in depth
planning and usually more than one draft is necessary.
Questionnaires are useful when the analyst need to gather
information from a large number of people. It is not possible to
interview each individual. Also if the time is very short, in that
case also questionnaires are useful.
Questionnaire design is critical. The Questionnaire consists
of series of Questions framed together in logical manner. The
questions are simple, clear and to the point. This method is very
useful for attaining information from people who are concerned
with the usage of the system and who are living in different
countries.
The Questionnaire can be mailed or send to people by post.
This is the cheapest source of fact finding. Questions should be
short, easy to understand, unbiased, non threatening and
specific.
Questionnaires are of two types:
1. Open-response based
2. Close –response based
Open-response based:
Main objective of open response Questionnaire is to
gather information and data about the critical design
features of the system.
This form is used to learn about the feeling, opinions and
experience of the respondents. This helps in the making of
the system effective because the analyst can offer
subsequent modification as per the knowledge gained.
Respondents must answer the question in their own words.
Space is provided under each question for the response. It
gives a person the chance to respond in detail. Although
open ended questions are important, they are time-
consuming and should not be over-used.

close-response based:
The objective of closed response questionnaire is to
collect the factual information of the system.
The closed questions can be of various types and the most
common ones are listed below:
By: Heta S. Desai Page 7
 Software Engineering

 Multiple Choice questions:

This gives respondents a specific set of potential
answer, which offer respondents few fixed
alternatives to choose from.
Example:
How did you first hear about our product?
 Television
 Radio
 Magazine
 Internet
Please specify:____________

 Rating Scale Questions:

This is similar to multiple choices except that
respondents must rate their satisfaction. A rating
scale question requires a person to rate a
product or brand along a well-defined spaced
continuum.
Example:
1. Excellent
2. Very good
3. Good
4. Average
 Rank Order Scaling Question:
Rank requires respondents to priorities their
response fro high to low. This allows a certain
set of brands or products to be ranked based
upon a specific attribute or characteristics.
Example:
 ___Honda
 ___Ford
 ___Toyota

 Dichotomous Question:
This question is generally a “Yes/No” question.
Example:
Have you ever purchase from our website?
Yes
No
By: Heta S. Desai Page 8
 Software Engineering

3) Record Review:
Records and reports are the gathering of information and
data collected over the time by the users about the system
and its operations. For better understanding of any existing
system is to review its related records, existing documents,
forms or files. This process is known as record review. It
starts at the preliminary stage of the system study or later
on in the study for measuring actual operations with what
the records indicate. Records and reports may have a
limited if they are not up to date or if some essential links
are missing.
An analyst always gets facts from documents. An existing
system can be better understood by examining existing
documents, forms and files.
Record review may include:
 Written policy
 Rules and regulation
 Forms and documents
4) Observation:
Another information gathering technique used by the
system analyst is known as on site observation or direct
observation, where the system analyst personally goes to the site
and discovers the functionalities of the system. As an observer,
the system analyst can gain direct knowledge of the activities,
operations, processes of the system non-site. Here the role of the
system analyst is of an information seeker. This technique is
useful when on needs to actually observe how documents are
handled, how operations and activities are carried out.
Observation can look for:
 Operational inefficiencies
 The usage of files and documents
 Inter communication channels
 Interruptions n the normal flow of work
 Alternative routes and procedures

Advantage:
 Facts gathered using this technique is highly
reliable.
By: Heta S. Desai Page 9
 Software Engineering

 Inexpensive way of collecting data.

 The system analyst can make out task that have
been missing or wrongly illustrated by other fact
finding techniques.
 Practical experience.

Disadvantage:
 This technique is time consuming and system
analyst should not jump to conclusion or draw
assumption from minute sample of observation
rather the analyst should be more patient in
gathering the information.

5) Joint Application Development(JAD) :

JAD is a methodology that involves the client or end user in
the design and development of an application through a
succession of collaborative workshops known as JAD
sessions or in other words, a group information gathering
technique of systems development.
Joint Application Design was developed by IBM in
1970’s. JAD was designed to bring system developers and
users of varying backgrounds and opinions together in a
productive and creative environment. The structured
approach provides a good alternative to traditional serial
interview by system analyst.
JAD centers more on people than on technology. By
following a structured method that utilizes group dynamics,
electronic software, visual aids and software modeling tools,
JAD encourages a partnership between business clients,
management and IS personnel
JAD is a technique that allows the developments,
management, and customer group to work jointly to build a
system. It is a series of highly structured interviewed
session aimed at reaching consensus on a project’s goal
and scope.
The aim is to get all groups with a stake in the project
to work together by getting the team together in meeting
rooms with U-shaped or round tables, white boards,
overhead projectors and audio-visual tools. This allows
By: Heta S. Desai Page 10
 Software Engineering

everyone in the room to talk and be heard. By hearing each

other the team is able to produce the appropriate systems
requirements. Therefore JAD sessions require the right mix
of people actively participating in order to achieve the goals
of the session.
A typical JAD team is has five to eight roles depending on
the project.
 The Users:
The end user should have good knowledge
and experience in the field, are responsible for
input concerning system design and are the only
participants with a clear idea of how the system will
be used in the work.
 IT Representatives:
This is normally made up of programmers and
other developers. This group is present to assess
technical feasibility and learn about future plans.
For this role, the representative should be able to
listen as well communicate ideas and technical
information.
 The Session Leader:
This individual organizes the sessions and
keeps the group focused on the task. A good
knowledge of the business processes, good
interpersonal skills and an outstanding ability to
organize and lead group is a must.
 System Analyst:
The analyst attends to learn from the users
and managers to be able to better analyze the
entire system.

Advantages:
 JAD actively involves users and management in the
development project.
 JAD helps to avoid the requirements which cause trouble
during implementation and acceptance.

Disadvantages:

By: Heta S. Desai Page 11

 Software Engineering

 Slow communication and long feedback time.

 Can be weak or no support from upper management.

6) FAST(Facilitated Application Specification Technique):

FAST is an important technique for Requirements elicitation.

FAST is a technique for gathering requirements during early
stages of analysis and specification.
The main objective of this technique is to cover the gap
between what the developers think they are going to
design and what customers believe they will receive
from the particulars program. This is a team oriented
approach for requirement gathering.
It is a technique where there are meeting software
customers and developers at a natural site (no home
advantage). Any discussion about expectations from
proposed software system or cost associated with the
system at customer’s premises or developers premises
may lead to strong disagreements on account of home
advantage. To avoid this, meeting between selected end-
users and representatives from developers is conducted at
neutral sites, which is facilitated by a third party.
Such meetings are highly successful because the two
parties arrive at agreement very fast because of neutral
environment. Use of wall posters, banners, flip-charts
is a common feature of such meeting which helps in
finalizing high level requirements.

Goals of FAST
a. Problem Identification
b. Solution of Elements
c. Approaches negotiate
d. Requirements specified

Such meeting needs lot of preparation in advance in the

form of well defined agenda, points for discussion and so
on. Facilitator generally assists in providing necessary
infrastructure and documentation. JAD (Joint Application
Development) approach frequently uses in this method.
By: Heta S. Desai Page 12
 Software Engineering

Process for FAST:

 Initial meetings between the developer and customer
occur and basic questions and
answers help to establish the scope of the
problem and the overall perception of a solution.
 Out of these
initial meetings, the developer and customer write a o
ne- or two
page "product request." A meeting place, time, and da
te for FAST are selected and a facilitator is chosen.
 Attendees from both the
development and customer/user organizations are invi
ted to attend.
 The product request
is distributed to all attendees before the meeting date.

Basic guidelines:
1. Meetings are conducted at a neutral site attended by
both developers and users.
2. The group establishes rules for preparation and
participation.
3. An agenda is suggested that with enough formality to
cover all important points but informal enough to encourage
the free flow of ideas.
4. A facilitator controls the meeting.
5. A definition mechanism
(can be work sheets, flip charts, or wall stickers or
an electronic bulletin board, chat room or virtual forum) is
used.

Advantages:

 Helpful because meeting is conducted at a neutral

site.

By: Heta S. Desai Page 13

 Software Engineering

 Team oriented approach. Both developer and user

will work together.

Disadvantages:

 Weak meeting if facilitator not prepared well for the

meeting.

7) Rapid Application Development(RAD):

This application development methodology goes further

than JAD in reducing the time taken to develop an application, is
not always as structured as the JAD and focuses more on
software development than JAD. RAD is based on the concept
that systems can be developed faster and of higher quality by
gathering requirements through workshops or focus groups,
prototyping and early, reiterative user testing of designs, use of
already existing software components and less formality in
reviews and other team communication. RAD uses small
integrated teams of developers, end users and IT technical
resources and short iterative development cycles to optimize its
goals of speed, effective informal communication, unity of vision
and purpose, and simple project management. This RAD Process
continues until the system is completely developed and users are
satisfied

By: Heta S. Desai Page 14

 Software Engineering

RAD Phases and Activities

 Requirements planning
 Requirements planning phase
 User design
 User design phase
 Construction
 Construction phase
 Cutover
 Cutover phase

RAD Objective:
 To cut development time and expense by involving
the users in every phase of systems development
 Successful RAD team must have IT resources,
skills, and management support
 Helps a development team design a system that
requires a highly interactive or complex user
interface
Advantages:

By: Heta S. Desai Page 15

 Software Engineering

 Might allow less time to develop quality, consistency,

and design standards
 Systems can be developed more quickly with
significant cost savings

Disadvantages:
 Requires highly skilled developers/designers.

8) Sampling of documentation, forms and files:

Sampling is the process of collecting a representative
sample of documents, forms and records.
 Organizational chart
 Documents that describe the problem.
 Standard operating procedure for current system.
 Sample databases.
 Flowchart and other system documentation.

Data Dictionary and Process Specification:

Data Dictionary:
A data dictionary lists all data items appearing in the data
flow diagram. Data dictionary is a set of meta-data which
contains the definition and representation of data elements that
are related to system. It stores data elements with accurate
definition so that both user and system analyst will have a
common understanding of input, output and component of
stores. The elements of data dictionary are data flows, data
stores and processes.
Data dictionary is the centralized collection of information
about data. It stores meaning and origin of data, its relationship
with other data, data format for usage etc. Data dictionary has
rigorous definitions of all names in order to facilitate user and
software designers.

Reasons to use data dictionary:

1) Data dictionary is very useful in building a database.

By: Heta S. Desai Page 16

 Software Engineering

2) The data dictionary provides the analyst with a means to

determine the definition of different data structures in
terms of their component elements.
3) A data dictionary provides a terminology for all relevant
data for use by engineers working in a project.

Data dictionary is organized into four sections:

1) Data elements The elements are Eg: Order_id,

grouped together customer_id,QTY_ordered.
to make up a
data structure.
2) Data structures Data structure is Eg: “INVOICE” consist of
a collection of group of data elements
data elements such as vendor_name,
that are related Item_details,etc.
to one another.

3) Data flows and Data flows are Eg: Invoice_detail.

Data stores data structures in
motion where
data stores are
data structures at
reset. Data stores
may be file,
database.

Format for data dictionary:

Data Name: Name of the data elements/data flows/data

stores.
Data aliases: An alternative name use for the connivance
by multiple uses.
Data description: A short description of the data
By: Heta S. Desai Page 17
 Software Engineering

Data Stores: Name of the data store where data are going
to store.
Format: Specify information about data types.
Physical location of In terms of record files or data base.
data:
Data characteristics: Data length, range of data values or so on.

Data dictionary can be created for:

 Data element:
 Data structure:
 Data Stores:

1. Data Element:
Data element for student Name:

Data Element Student Name

Description Student name consist first name, middle
name and last name
Length 45
Alias None
Remark First fifteen characters for first name,
next fifteen for middle name remaining
for last name.

2. Data structure:
Data dictionary for data structure pay slip

Data Structure Pay slip

Description Gives the pay details of the employee for
the month
Contents Emp_id, Emp_name,Basic_Pay,D.A
Data store PayRoll_DB
Remark First fifteen characters for first name,
next fifteen for middle name remaining
for last name.
Where Used: Process number (process no:2.3)

By: Heta S. Desai Page 18

 Software Engineering

3. Data stores:

Data Store Faculty file

Description Store faculty details
In Bound Data Faculty detail (eg : faculty_id =1)
Out Bound Detail of faculty (eg: where id=1)
Data

Software Requirement Specification (SRS):

The specification is a contract between client and developer. It

must specify what the product must do and the constraints on the
product. It is produced when the analysis task is near to complete.
SRS is a complete description of the system and functionality of the
system.

SRS take two types of requirements:

1) Behavioral requirements (Functional requirements):

This defines what the system must do that is how the
inputs are transformed into output.

2) Non-Behavioral requirements (Non-Functional

requirements):
This defines the attributes of the system as it performs its
tasks that is, system’s required levels of efficiency,
reliability, security, maintainability, portability, visibility,
capacity and so on.

Characteristics of SRS:

1) Complete:
An SRS is complete if, and only if, it include following
elements:

By: Heta S. Desai Page 19

 Software Engineering

 All significant requirements, whether related to

functionality performance, design constraints,
attributes, or external interface.
 Full label and references to all figures, tables, and
diagrams in the SRS and definition of all terms and
unit of measure.
2) Consistent:
System functions and performance level must be
compatible and the required quality features like reliability,
safety, security, ect must not contradict the utility of the
system.
3) Correct:
An SRS is correct if, and only if, every requirement stated
there in is one that the software shall meet. Traceability
makes this procedure easier and less prone to error.
4) Modifiable:
Related concern must be grouped together and unrelated
concerns must be separated. Requirements documents
must have a logical structure to be modified.
5) Ranked:
Raking specification statements according to stability and
importance are established in the requirements document’s
organization and structure. The larger and more complex
the problem addressed by the requirements specification,
the more difficult the task is to design a document that aids
rather than inhibits understanding.
6) Testable:
Requirement specification must be stated in such as
manner that one can test it against pass/fail assessment
criteria. All derived from the specification itself referenced
information.
7) Traceable:
Each requirement stated within SRS document must be
uniquely identified to achieve traceability.
By: Heta S. Desai Page 20
 Software Engineering

8) Unambiguous:
A Statement of a requirement is unambiguous if it can only
be interpreted one way. This is more difficult attribute to
achieve using natural language.
9) Valid:
To validate requirement specification all the project
participants, manager, engineers and customer
representative, must be able to understand, analyze and
accept or approve it.
10) Verifiable
In order to be verified, requirement specifications at one
level of abstraction must be consistent with those at
another level of abstraction.

Components of an SRS:

1. Functionality:
Functional requirements identify the expected behavior
of the system which outputs should be produced from the
given input. They describe the relationship between the
input and output of the system. For each functional
requirement, a detailed explanation of all the data inputs
and their source, the unit of measure, and the range of
valid must be specified.
All the operations to be performed on the input data to
obtain the output should be specified. This includes
specifying the validity checks on the input and output data,
parameters affected by the operation, and equation or
other logical operation that must be used to transform the
inputs into corresponding outputs.
A significant part of the specification is the system behavior
in abnormal situation, like invalid input or error
computation. The functional requirement must clearly state
what the system should do if such situation occurs.
By: Heta S. Desai Page 21
 Software Engineering

2. Performance:
Performance requirements component of SRS specifies the
performance restrictions on the software system. All the
requirements related to the performance characteristics of
the system must be clearly specified.
There are two types of performance requirements:
 Static:
These requirements are like the number of
terminal to be supported, the number of
simultaneous users to be supported, the
number o files that the system has to
process and their sizes. These are called
capacity requirements of the system.
 Dynamic:
These requirements specify constraints on
execution behavior of the system. These
typically include response time and
throughput on the system. Response
time is the expected time for the
completion of an operation under specify
situation. Throughput is the expected
number of operation that can be performed
in a unit time.
3. Design Constraints:
There are a number of issues in the client’s environment
that may restrict the choice of designer leading to design
constraint. That includes standards that must be following,
resource limit, operating environment and security policy.
And other policies that may have impact on the design of
the system. Some example of these:
 Standards compliance:
This specifies the requirements for the
standards the system must follow. The

By: Heta S. Desai Page 22

 Software Engineering

standard may include the report format

and accounting procedure.
 Hardware limitation:
The software may have to operate on some
existing or predetermine hardware, thus
imposing restrictions on the design.
Hardware limitation may include the type
of machines to be used, operating system
available on the system, language
supported and limit on primary or
secondary storage.
 Security:
This factor is become more and more
essential. these requirements place
limitations on the use of the certain
commands, control access to data, provide
different kind of access requirements for
different people, require the use of
password and cryptography techniques.

4. External Interfaces:
These include interface specification part; all the interaction
of the software with people, hardware and other software
should be clearly specified.
For use interface, the characteristics of each user
interface of the software should be specified.
For hardware interface, the SRS should specify the logical
characteristics of each interface between the software
product and hardware components.

By: Heta S. Desai Page 23

 Software Engineering

Analysis Model:
The analysis model encompasses each of the diagrams,
specifications, descriptions and the data dictionary.

The analysis model is a set of models, is a first technical

representation of the system. The analysis model must achieve three
objectives:

1. To describe what the user requires.

2. To establish a basis for the creation of a software.
3. To define a set of requirements that can be validated once the
software is built.

By: Heta S. Desai Page 24

 Software Engineering

Data dictionary:

At center of the model is the data dictionary. Data dictionary is

structured repository of data about system. It is a set of definitions of
all DFD data elements and data structures. It stores data elements
with its definition so that both user and system analyst will have
common understanding of input, output, components of stores and
intermediate calculation. Elements of data dictionary are data flow,
data stores and processes.

Entity relationship diagram (ERD) is a relationship between data

and objects. The ERD is the information that is used to conduct the
data modeling activity. The attributes of each data object noted in ERD
can be described using a data object description.

Data flow diagram (DFD) provides an indication of how data are

transformed as they move through the system. DFD also represent the
functions that transform the data flow. DFD provides additional
information that is used during the analysis of the information domain
and serve as a basis for modeling of function.

Control Specification (CSPEC) is used to indicate

(1) How the software behaves when an event or control signal is

sensed and

(2) Which processes are invoked as a consequence of the

occurrence of the event.

State Transition Diagram (STD) indicates how the system behaves

as a consequence of external events. The STD represents the various
modes of behavior called states of the system and the manner in
which transitions are made from state to state.

One way to characterize change in a system is to say that its objects

change their state in response to events and to time

By: Heta S. Desai Page 25

 Software Engineering

1) e.g. when you throw a switch, a light changes its state

from off to on
e.g. The update_mark method changes the state of the student
subject object
A state diagram shows the various states of a single object
 There must be a separate transition diagram for each object class
 It helps analysts, designers and developer understand the
behavior of the objects in the system,
 State diagrams ensure that they won't have to guess about what
the object is supposed to do.

Data Object Description stores the detail about each and every
object is going to be used in data model. Data model is an abstract
model that organizes elements of data and standardizes how they
relate to one another and to properties of the real world entities. For
instance, a data model may specify that the data element representing
a car be composed of a number of other elements which, in turn,
represent the color and size of the car and define its owner.

Process Specification (PSPEC) can be used to specify the

processing details implied by bubble within DFD. This specification
describe the input to a function, the algorithm, also indicates
restrictions and limitation imposed on the process. Process
specification is used to describe the inner working of process
representation in a flow.

By: Heta S. Desai Page 26

 Software Engineering

Order Form 1.1

Customer Add Customer

Order_Master
Order

PSPEC

This process is used to add customer

order detail. Insert order details of
customer in order_Master.

Goals of producing process Specification:

 Reduce process ambiguity

 Obtain a description of what is accomplished.
 Validate the system design, including DFD and data
dictionary.

Example of process specification:

Number 1
Name Add customer Order
Description This process is used to add customer order
detail
Input Data Flow Order form from customer
Output Data Flow Insert order detail of customer in order
Master.

By: Heta S. Desai Page 27