Requirement analysis

UNIT II
Requirement Analysis
By Dr. Dhobale J V
Associate Professor
School of Engineering & Technology
RNB Global University, Bikaner
RNB Global University, Bikaner. 1Course Code - 19003400

Objectives
 Problem definition.
 Identification and Investigation of system.
 Fact finding techniques.
 Tools for documenting procedures and
decisions .
 System design considerations.
 Process and stages of system design: Logical
and Physical.
 Selection of best alternate design strategy.
2RNB Global University, Bikaner.Course Code - 19003400

 System Analysis is the part of the system
development life cycle.
 Which determines how the current information
system functions and access what users
would like to see in a new system.
 Analysis has two sub phases.
1. Requirement Determination
2. Requirement structuring

Requirement Determination
 Once management has granted permission to
pursue development of a new system and a
project is initiated, you begin determining what
the new system should do?
 Analysts collect information from current
users, current system, form reports, forms,
procedures & observing users.
 This information is carefully documented and
made ready for structuring.

 Deliverables & Outcomes: The primary
deliverables from requirements determination
are the various forms of information gathered
during the determination process.
 It incorporates transcripts of interviews; notes
of observations and analysis of documents;
sets of forms, reports, job descriptions,
computer generated output such as system
prototype.

 These deliverables contain the information you
need for the system analysis within the scope
of the system you are developing.
 Analyst has to understand following
components of an organization:
1. The business objectives that drive what and how
work is done.
2. The information needed by employees.
3. The data required to handle job in the
organization.
4. Data storage, Movement, processing aspects.
5. Sequence and dependency of data handling.
6. Policies & guidelines of the organization.

Traditional Methods of Requirement
Determination
1. Interviewing & Listening.
2. Interviewing Group Technique
3. Directly Observing Users
4. Analyzing Procedures and Other Documents

Determination
1. Interviewing & Listening: Is the most common
technique of information-gathering.
 Usually, if you need to know something, you
ask someone.
 Generally Interviews are conducted one-on-
one (interviewer & Interviewee).

Determination
1. Interviewing & Listening: Interview technique
involves several basic steps:
 Preparation for the interview.
 Design of Interview Questions.
 Conduct the Interview.
 Document the Interview.
 Perform a Follow-Up Interview

Determination
1. Interviewing & Listening: To plan for
interview, System analyst first reviews the
documents available on the company,
existing system, and users. He or she
examines:
 Company’s goals and objectives.
 Forms, reports, and business models of the
current system.
 Organization chart and user roles.

Determination
1. Interviewing & Listening: After this study and
in discussion with the sponsoring agent of the
organization, the analyst prepare a list of
interviewees who will provide various levels
of information for as-is and to-be system.
 Higher level of management provide an
overview of the current system & its future
needs while lower-level user provides the
operational level details.

Determination
1. Interviewing & Listening: Thus the top
management is interviewed first, then the
department heads followed by next level of
employees in the hierarchy up to last user.
 Once a list of prospective interviewees is
generated, the analyst schedules interview
with personnel.

Determination
1. Interviewing & Listening: Designing Interview
Questions: Three types of interview
questions.
a. Closed-ended questions: It enables analysts to
control the interview and obtain information they
need. Ex. True/False, MCQs, Ratings, Scaling.

Determination
1. Interviewing & Listening:
a. Open-ended questions: These questions leave
rooms for further elaboration by the interviewee.
These questions provides additional information.
Ex. What is your idea about new system? What
would you suggest?
b. Probes: These are follow-up questions in
response to one of the above questions, when the
analyst is unclear about the answer.

Determination
1. Interviewing & Listening: Conduct the
Interview: Guidelines
1. Listen very carefully to the interviewee and
give opportunity to answer.
2. Take careful notes. take a second person, if
needed to take notes.
3. If Permission, record the interview.

Determination
4. Ask questions, even if they sound “dumb”.
Not asking questions may result wrong
conclusion causing further potential problem.
5. Give the interviewee opportunity to ask
questions.
6. Separate facts from individual user opinions,
facts are important.

Determination
7. Do not make any premature promise on any
part of the delivery of the system.
8. Thank the interviewee at the end and
mention that a follow-up interview may occur
to further clarification.

Determination
1. Interviewing & Listening: Document the
Interview: after interview, the analyst should
organize and type interview notes within 48
hours in the form of report.
 Write down any unclear or additional
questions that may arise during this process
and make a list of questions for follow-up
interview.
 The report should sent to the interviewee for
his/her comments and approval.

Determination
1. Interviewing & Listening: Follow-up Interview:
Follow-up interview arises due to the
questions that may arises in writing the
interview report and obtaining a response of
the report.
 Depending on the number and type of
questions, the follow-up interview can be
performed in person or over telephone or any
other suitable mechanism (Mail, E-mail, Fax
etc.)

Determination
2. Interviewing Groups – One drawback of
interviews to collect system requirements is
the need for the analyst to reconcile apparent
contradictions in the information collected.
 A series of interviews may turn up
inconsistent information about the current
system or its replacement.
 Gathering information about an information
system through a series of individual
interviews and follow-up calls is not and
efficient process.

Determination
2. Interviewing Groups – Group interview is the
another option to the problem.
 In a group interview, you interview several
key people at once.
 To make sure all of the important information
is collected, you may conduct the interview
with one or more analysts.
 In the case of multiple interviewers, one
analyst may ask questions while another
takes notes, or different analysts may
concentrate on different kinds of information.

Determination
2. Interviewing Groups – the number of
interviewees involved in the process may
range form two to however many you believe
can be comfortably accommodated.
 This process is a much more effective use of
your time than a series of interviews with
individuals.
 Interviewing several people together allows
them to hear the options of the key people
and gives them the opportunity to agree or
disagree with their peers.

Determination
2. Interviewing Groups – Primary disadvantage
of a group interview is the difficulty in
scheduling it.
 The more people who are involved, the more
difficult it will be finding a convenient time &
place for everyone.
 Modern videoconferencing technology can
minimize this issue.
 Group interviews are at the core of JAD (Joint
Application Development) modern
methodology of requirement determination
process. 23RNB Global University, Bikaner.Course Code - 19003400

Determination
2. Nominal Group Technique – Many different
techniques have been developed over the
years to improve the process of working with
groups, one of more popular is NGT.
 A facilitated process that supports idea
generation by groups.
 At the beginning of the process, group
members work alone to generate ideas, which
are then pooled under the guidance of a
trained facilitator.

Determination
3. Directly Observing Users :
 People cannot always be trusted to reliably
interpret and report their own actions, you
can supplement and corroborate what people
tell by watching what they do or by obtaining
relatively objective measures of how people
behave in work situations.

Determination
3. Directly Observing Users : Observations of
current operating procedures of the system is
another fact-finding technique.
 A system can be understood better and faster
through observation than other techniques.
 It also allows opportunities to verify statements
and answers gathered through interviews and
questionnaires.
 It also allows opportunities to build
relationships with the users.

Determination
3. Directly Observing Users : A Successful
observation should be planned through
checklist.
 Ask questions to obtain a good understanding of the
system operation procedure.
 Observe all steps in the processing cycle and note
the output from each procedural step.
 Examine each form, record, and report. Determine
the purpose of each item on the documents.

Determination
3. Directly Observing Users : Consider
observing each person working with the
system to complete a process.
 Talk to people who receive current reports to
see whether the reports are complete, timely,
accurate, and in a useful form.
 Consider the Hawthorne Effect: During the
observation day, people may work more
efficiently than the normal day. Operations
may also run less smoothly because people
might be nervous during observation.

Determination
: Project team often use document analysis to
understand the as-is system.
 This technique is also called as Work and
Product Sampling technique.
 In this case, the project team can start by
reviewing the documentation and examining
the system itself.

Determination
: Unfortunately, most systems are not well
documented, therefore, there may not be
much technical documentation about recent
system changes.
 There are many other helpful documents that
do exist in the organization – Reports,
Memorandums, policy Manuals, User training
manuals, Organizational charts & Forms.
 Problem reports filed by system user can be
another rich source of information about
issues with existing system. 30RNB Global University, Bikaner.Course Code - 19003400

Determination
: All these documents represents the formal
system information, quite often, the real or
informal documents may give strong
indications of what needs to be changed?
 Like User created their own forms, Reports
which are differ from existing one.

Contemporary Methods of
 Interviews, Observations & Document
analysis are traditional methods for
determining a system’s requirements.
 Still all these methods are effective in
collecting system requirements.
 Now we are going to discuss several
contemporary information gathering
techniques like JAD & Prototyping.

5. Joint Application Design (JAD): This
information gathering techniques is
developed by IBM in 1970s.
 It is structured process in which users,
managers, and analysts work together for
several days in a series of intensive meetings
to specify or review system requirements.
 In this session, a work session consisting of a
task force of users, managers, and IT
professionals is conducted to gather
information, discuss business needs, and
define the new system requirements. 33RNB Global University, Bikaner.Course Code - 19003400

5. Joint Application Design (JAD): JAD is similar
to a group interview; a JAD, however, follows
a particular structure of roles and agenda that
is quite different from a group interview in
which analysts control the sequence of
questions answered by users.
 The primary purpose of using JAD in the
analysis phase is to collect system
requirements simultaneously from the key
people involved with the system.

5. Joint Application Design (JAD): This group
usually meets over a period of several hours
to few days in a meeting room outside the
work area.
 Because of the wide range of users input,
JAD produces the best possible requirements
of a new system than a single analyst can
provide.
 The organization of the JAD Session: various
roles and responsibilities.

5. Joint Application Design (JAD):
 Session Leader: The session leader
organizes and runs the JAD. This person
guides the team to keep on agenda, aids
participants in openly expressing ideas, and
resolving conflicts and disagreements
between participants.
 Active Participants: The users and managers
who know the necessary facts and details
regarding both the current system and the
objectives of the future system.

5. Joint Application Design (JAD):
 Observers: These are IT staff such as
analysts, programmers, operators, or any
other technical person who can learn by
participation. They may also provide some
technical assistance when needed. Expert in
some functional areas of business
(accounting, billing, etc.) may also participate
to provide assistance.

6. Prototyping:
 Is an iterative process involving analysts and
users whereby a rudimentary version of
information system is built and rebuilt
according to user feedback.
 This methodology covers three phases of the
SDLC – Analysis, design, and
implementation, concurrently and repeatedly
in a cycle until the system is completed .

6. Prototyping:

6. Prototyping:
 In order to develop a prototype during the
requirement analysis, the analyst performs
some interviews and collects necessary
documents.
 With the basic requirements from the users, a
quick analysis and design of the system is
performed, and a prototype of the system
containing main features of the requirements,
are developed.

6. Prototyping:
 The prototype is then handed to the users for
testing and to provide comments; which are
then reanalyzed and redesigned, and a
second prototype is developed.
 The process continues in a cycle until the
users and developers agree to a final systems
requirement.

Methods of Requirement Determination
 These methods of Requirement
determination help analysts to identify and
collect user requirements effectively.
 These methods are also called as fact finding
techniques, which helps analysts to
investigate and find out the requirement facts
about existing and to be Information system
of the organization.

Tools for documenting procedure and
decisions
 Is a set of techniques and graphical tools that
allows the analyst to develop a new kind of
system specifications that are easily
understandable to the users.
 Traditional approach focuses on cost/benefit
and feasibility, project management, hardware
and software selection and personnel
considerations.
 Structured analysis consists new goals and
structured tools for analysis.

decisions
 The structured Analysis Tools are:
1. Data Flow Diagrams.
2. Data Dictionary.
3. Structured English.
4. Decision Trees.
5. Decision Tables.

decisions
 The objective of Structured analysis is to build
a new document called system specifications.
 System specification provides the basis for
design and implementation.

decisions
1. Data Flow Diagram (DFD): The DFD was first
developed by Larry Constantine as a way of
expressing system requirements in a
graphical form, which lead to modular design.
 A data flow diagram (DFD) is a graphical
representation of the "flow" of data through a
computer system.
 It is also known as a “bubble chart”.

decisions
 It clarifies system requirements and identify
major transformation which becomes
programs in system design.
 It is the starting point of the design phase that
functionally decomposes the requirements
specifications down to the lowest level of
details.
 A DFD consists of a series of bubbles joined
by lines.

decisions
 The bubbles represent data transformations
and the lines represent data flows in the
system.
 It concerns things like where the data will
come from and go to as well as where it will be
stored.
 But you won't find information about the
processing timing.

decisions
 Data flow diagrams (DFDs) are categorized
as:
1. LOGICAL DFD:- A logical DFD focuses on
the business and how the business operates.
It describes the business events that take
place and the data required and produced by
each event.
2. PHYSICAL DFD:- A physical DFD shows how
the system will be implemented.

decisions
PROCESS
DATA
FLOW
DATA
STORE
EXTRNAL
ENTITY

decisions
1. PROCESS: The rounded cornered
rectangles or ovals in a DFD indicate
processes.
 The Process symbol represents an activity
that transforms or manipulates the data
(combines, reorders, converts, etc.).

decisions
1. PROCESSES: Examples
Reservation
System
Accounting
System
HRM
System
Marketing
System

decisions
2. DATA FLOW: Arrow symbol in DFD indicate
data flow.
 The Data Flow symbol represents movement
of data

decisions
2. DATA FLOW: Examples
Amount Customer Details
Employee Details Name

decisions
3. DATA STORE: Opened sided rectangles in
DFD indicates data store.
 The Data Store symbol represents data that is
not moving (delayed data at rest).
 A Data Store is a repository of data.
 Data can be written into the data store. This is
depicted by an incoming arrow.
 Two data stores cannot be connected by a
data flow.

decisions
 Data can be read from a data store. This is
depicted by an outgoing arrow.
 External entity cannot read or write to the data
store.

decisions
3. DATA STORE : Examples

decisions
4. EXTERNAL ENTITY. The sharp cornered
rectangles(or simply boxes) in a DFD
indicates entities.
 The External Entity symbol represents
sources of data to the system or destinations
of data from the system.
 Entities are people things, organizations etc.

decisions
4. EXTRNAL ENTITY: Examples
Student Cashier
Customer Manager

decisions
 RULES OF DATA FLOW :
 Data can flow from:
 external entity to process.
 process to external entity.
 process to store and back.
 process to process.
 Data cannot flow from:
 external entity to external entity.
 external entity to store.
 store to external entity.
 store to store.

decisions
 DFD Example: This diagram represents a
banking process, which maintains customer
accounts.
 In this example, customers can withdraw or
deposit cash, request information about
their account or update their account details.
 The five different symbols used in this
example represent the full set of symbols
required to draw any business process
diagram.

decisions

decisions
2. Data dictionary : is a main method for
analyzing the data flows and data stores of
data-oriented systems.
 The data dictionary is a reference work of
metadata (data about data).
 It collects, coordinates, and confirms what a
specific data term means to different people in
the organization.

decisions
2. Data dictionary : Why Data Dictionary ?
 Provide documentation.
 Eliminate redundancy.
 Validate the data flow diagram.
 Provide a starting point for developing
screens and reports.
 To develop the logic for DFD processes.

decisions
2. Data dictionary : A data repository.
 Information about system data.
 Procedural logic.
 Screen and report design.
 Relationships between entries.
 Project requirements and deliverables.
 Project management information.

decisions
2. Data dictionary : Contents
 Data flow
 Data structures
 Elements
 Data stores

2. Data dictionary : Contents- Data Flow
 Each data flow should be defined with
descriptive information and it's
composite structure or elements.
 Include the following information:
 ID - identification number
 Label, the text that should appear on the
diagram
 A general description of the data flow
Tools for documenting procedure
and decisions

 The source of the data flow.
 This could be an external entity, a process, or a
data flow coming from a data store
 The destination of the data flow.
 Type of data flow, either
 A record entering or leaving a file
 Containing a report, form, or screen
 Internal - used between processes
 The name of the data structure or elements
and decisions

 The volume per unit time
 This could be records per day or any other unit
of time
 An area for further comments and notations
about the data flow
and decisions

2. Data dictionary : Contents- Defining
Data Structure
 Data structures are a group of smaller
structures and elements.
 An algebraic notation is used to
represent the data structure.
and decisions

2. Data dictionary : Contents- Defining
Data Structure
 Notations:
 An equal sign = means “is composed of”.
 A plus sign + means “and”.
 Braces { } indicates repetitive elements also called repeating
groups or tables.
 Brackets [ ] represent an either/or situation.
 Parentheses ( ) represent an optional element.
Each structural record must be further
defined until the entire set is broken down
into its component elements.RNB Global University, Bikaner. 71Course Code - 19003400
and decisions

2. Data dictionary : Contents- Logical &
Physical Data Structure
 Logical Data Structure – shows what
data the business needs for its day-to-
day operations. Ex. Name, Address,
Orders.
and decisions

2. Data dictionary : Contents- Logical &
Physical Data Structure
 Physical Data Structure – includes
additional elements necessary for
implementing the system.
Examples of physical design elements:
 Key fields used to locate records.
 Codes to identify the status of master records.
 Transaction codes
 Repeating group entries containing a count of how many items are in
the group.
 Limits on the number of items in a repeated group.
 A password. RNB Global University, Bikaner. 73Course Code - 19003400
and decisions

2.Data dictionary : Contents- Data
Elements
 Data elements definitions describe a
data type.
 Each element should also be defined to
indicate specifically what it represents. It
should be specific.
and decisions

2.Data dictionary : Contents- Data
Stores
 Data Stores are created for each
different data entity being stored.
and decisions

3. Structured English:
 Structured English is a language and
syntax, based on the relative strengths of
structured programming and natural
English, for specifying the underlying
logic of elementary processes of
information processes (on DFD).
 No specific standards.
and decisions

 Structured English is based on
structured logic.
 Simple English statements such as add,
multiply, move, and so on.
 It is an appropriate technique for
analyzing the system when structured
decisions are not complex.
and decisions

 Uses a subset of English
• Action verbs
• Noun phrases
• No adjectives or adverbs
 Similar to programming language
• If conditions
• Case statements
• Psudocode.
and decisions

3. Structured English: Advantages
 Clarification of login and relationship in
Human language.
 Easy and effective communication tool.
and decisions

3. Structured English: Problems
 Many of us do not write well, and we also
tend not to question our writing abilities.
 Many of us are too educated.
 Some of us write everything like it was a
program.
 Too often, we allow the jargon and
acronyms of computing to dominate our
language.
and decisions

3. Structured English: Problems
 English statements frequently have an
excessive or confusing scope.
 We overuse compound sentences.
 Too many words have multiple
definitions.
 Compound conditions tend to show up in
natural English.
and decisions

3. Structured English: Example
 If the TOTAL AMOUNTS PAST DUE for
the CUSTOMER NUMBER is greater
than Rs.100000 then:
1. Write the CUSTOMER NUMBER and all
their data attributes as described in the
data flow LOANS AT RISK.
Else
1. Exclude the CUSTOMER NUMBER and
data from the data flow LOANS ATRNB Global University, Bikaner. 82Course Code - 19003400
and decisions

4. Decision Trees:
 Decision trees are one of the methods
for describing decisions, while avoiding
difficulties in communication.
Condition Action
Order is signed Begin order verification process.
Order is unsigned Begin merchandise acceptance
processing.
and decisions

Condition Action
Size of order: Over Rs.10000 Take 3% discount from invoice total.
Rs.5000 to Rs.10000 Take 2% discount from invoice.
Less than Rs.5000 Pay full invoice amount.
and decisions

4. Decision Trees – Characteristics:
 A decision tree is a diagram that
presents conditions and actions
sequentially.
 It shows which conditions to consider
first, which second, and so on.
 It shows the relationship of each
condition and its permissible actions.
 The diagram resembles branches on a
tree, hence the name.RNB Global University, Bikaner. 85Course Code - 19003400
and decisions

4. Decision Trees – Characteristics: The
root of the tree, on the left of the given
diagram, is the starting point of the
decision sequence.
 The particular branch to be followed
depends on the conditions that exist and
the decision to be made.
 Progression from left to right along a
particular branch is the result of making
a series of decisions.RNB Global University, Bikaner. 86Course Code - 19003400
and decisions

4. Decision Trees – Characteristics:
 The nodes of the tree thus represent
conditions and indicate that a
determination must be made about
which condition exists before the next
path can be chosen.
 The right side of the tree lists the actions
to be taken depending on the sequence
of conditions that is followed.
and decisions

and decisions

4. Decision Trees – Using Dec. Trees:
 Developing decision trees is beneficial to
analysts in two ways:
1. The need to describe conditions and
actions forces analysts to formally
identify the actual decision that must be
made.
2. whether it depends on quantitative or
non quantitative variables.
and decisions

4. Decision Trees – Using Dec. Trees:
 Decision trees also force analysts to
consider the sequence of decisions.
 And Actions based on those conditions.
and decisions

 Decision trees may not always be best choice
for decision analysis.
 A decision tree for a complex system with
many sequences of steps and combinations of
conditions will be unwieldy.
 The analyst may not be able to determine
formulation of specific decisions.
 Where these problems arises, Decision Tables
should be considered.
RNB Global University, Bikaner. 91
Avoiding Problem with Decision Trees
Course Code - 19003400

 Problem with decision trees is the lack of
information in its format to tell us what other
combinations of conditions to test.
 A decision table is a table of contingencies for
defining a problem and the actions to be
taken.
 It is single representation of the relationship
between conditions and actions.
 A decision table consists of two part: stub and
entry.
Decision Tables

 The stub part is divided into an upper quadrant
called the condition stub and a lower quadrant
called the action stub.
 The entry part is also divided into an upper
quadrant, called the condition entry and a
lower quadrant called the action entry.
 The four elements are shown below:
Decision Tables

 Each condition corresponds to a variable,
relation or predicate.
 Possible values for conditions are:
 Boolean values – Limited Entry Decision Table.
 Several values – Extended Entry Table.
 Don’t care value.
 Each action is a procedure or operation
to perform.
 The entries specify whether (order) the
action is to be performed.
Decision Tables

 Printer Troubleshooting Example
Decision Tables Example

 Decision Tables Model complicated
programming logic.
 Decision Table makes it easy to see that
all possible combinations of conditions
have been considered.
Why Decision Tables?

 One need to determine the maximum size of
the table, eliminate any impossible situations,
inconsistencies, or redundancies and simplify
the table as much as possible.
Step 1:
 Determine the number of conditions that may
affect the decision.
 Combine overlapping rows.
 The number of condition becomes the number of
rows in the top half of the decision table
Developing Decision Tables

Step 2:
 Determine the number of possible
actions that can be taken.
 This becomes the number of rows in the
lower half of the decision table.

Step 3:
 Determine the number of condition
alternatives for each condition.
 In the simplest form of decision table, there
would be two alternatives (Y/N) for each
condition.
 In an extended-entry table, there may be
many alternatives for each condition.

Step 4
 Calculate the maximum number of
columns in the decision table by
multiplying the number of alternatives for
each condition.
 If there are three conditions and two
alternatives for each of them, there will be
2
3
= 8 possibilities.

Step 5
 Fill in the condition alternatives. Start
with the first condition and divide the
number of columns by the number of
alternatives for that condition.
Condition1 Y Y Y Y N N N N
Condition2 Y Y N N Y Y N N
Condition3 Y N Y N Y N Y N

Step 6 to 9
6. Complete the table by inserting an X
where rule suggest certain actions.
7. Combine rules where it is apparent that
an alternative does not make a
difference in the outcome.

Step 6 to 9
8. Check the table for any impossible
situations, contradictions, redundancies.
9. Rearrange the conditions and actions
(or rules) to make the decision table
more understandable.

 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 analysis/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.

Problem definition
 Before requirement analysis/determination,
organization decides about incorporation of
new system for their operations.
 What is the problem which makes
incorporation of new system so important?
 Organization try to find out the answer of this
question.

Problem definition
 Organization formulates its problem and in
feasibility study they try to find out its
practicality.
 Problem definition highlight the need of new
system & its importance to the organization.
 In problem definition organization decides new
system with its objectives.

Identification & Investigation of new
System
 Once Problem is defined, next phase comes
as finding solutions.
 Problems are having multiple solutions.
 Feasible solution amongst studied solutions is
finalised by the experts.
 This Feasible solution becomes new system to
the organization.

Major activities - Requirement
Determination
1. Requirement Anticipation.
2. Requirement Investigation.
3. Requirement Specifications.

Determination
1. Requirement 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.

Determination
2. Requirement 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.

Determination
3. Requirement 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.

Design – System Design Considerations
 Software design is the process by which
an agent creates a specification of a software
artifact, intended to accomplish goals, using a
set of primitive components and subject
to constraints.
 Software design may refer to either "all the
activity involved in conceptualizing, framing,
implementing, commissioning, and ultimately
modifying complex systems" or "the activity
following requirements specification and
before programming.

 Software design usually involves problem
solving and planning a software solution. This
includes both a low-level component
and algorithm design and a high-
level, architecture design.
 Software design is the process of
implementing software solutions to one or
more sets of problems. One of the main
components of software design is
the software requirements analysis(SRA).

 The main difference between software
analysis and design is that the output of a
software analysis consists of smaller
problems to solve.
 Additionally, the analysis should not be
designed very differently across different
team members or groups.
 In contrast, the design focuses on
capabilities, and thus multiple designs for the
same problem can and will exist.

 Software design is both a process and a
model.
 The design process is a sequence of steps
that enables the designer to describe all
aspects of the software for building.
 Creative skill, past experience, a sense of
what makes "good" software, and an overall
commitment to quality are examples of critical
success factors for a competent design.
 It is important to note, however, that the
design process is not always a
straightforward procedure; 116RNB Global University, Bikaner.Course Code - 19003400

 Basic Principles of s/w design:
1. The design process should not suffer from
"tunnel vision."
2. The design should be traceable to the
analysis model.
3. The design should not reinvent the wheel.
4. The design should "minimize the intellectual
distance" between the software and the
problem as it exists in the real world.
5. The design should exhibit uniformity and
integration.

 Basic Principles of s/w design:
6. The design should be structured to
accommodate change.
7. The design should be structured to degrade
gently, even when aberrant data, events, or
operating conditions are encountered.
8. Design is not coding, coding is not design.
9. The design should be assessed for quality as
it is being created, not after the fact
10. The design should be reviewed to minimize
conceptual (semantic) errors.

 Design Considerations: There are many
aspects to consider in the design of system.
1. Compatibility
2. Extensibility
3. Modularity
4. Fault-tolerance
5. Maintainability
6. Reliability
7. Reusability
8. Robustness

 Design Considerations: There are many
aspects to consider in the design of system.
9. Security
10. Usability
11. Performance
12. Portability
13. Scalability

Design – Process and Stages
 Systems design is the process of defining
and developing systems to satisfy
specified requirements of the user.
 Until the 1990s, systems design had a crucial
and respected role in the data
processing industry.
 In the 1990s, standardization of hardware
and software resulted in the ability to
build modular systems.
 The increasing importance of software
running on generic platforms has enhanced
the discipline of software engineering. 121RNB Global University, Bikaner.Course Code - 19003400

 Object-oriented analysis and design methods
are becoming the most widely used methods
for computer systems design.
 The UML has become the standard language
in object-oriented analysis and design.
 The Unified Modeling Language (UML) is a
general-purpose, developmental, modeling
language in the field of software engineering,
that is intended to provide a standard way to
visualize the design of a system.
 It is widely used for modeling software
systems. 122RNB Global University, Bikaner.Course Code - 19003400

 Architectural design: The architectural
design of a system emphasizes the design of
the system architecture that describes
the structure, behavior and more views of that
system and analysis.

 Logical design: The logical design of a
system pertains to an abstract representation
of the data flows, inputs and outputs of the
system. This is often conducted via
modelling, using an over-abstract (and
sometimes graphical) model of the actual
system. In the context of systems, designs
are included. Logical design includes entity-
relationship diagrams (ER diagrams).

 Physical design: The physical design relates
to the actual input and output processes of
the system.
 This is explained in terms of how data is input
into a system, how it is verified/authenticated,
how it is processed, and how it is displayed.
 In physical design, the following requirements
about the system are decided.

 Physical design:
1. Input requirement,
2. Output requirements,
3. Storage requirements,
4. Processing requirements,
5. System control and backup or recovery.
 Put another way, the physical portion of
system design can generally be broken down
into three sub-tasks.

 Physical design:
1. User Interface Design
2. Data Design
3. Process Design

 User Interface Design is concerned with how
users add information to the system and with
how the system presents information back to
them.
 Data Design is concerned with how the data is
represented and stored within the system.

 Finally, Process Design is concerned with how
data moves through the system, and with how
and where it is validated, secured and/or
transformed as it flows into, through and out of
the system.
 At the end of the system design phase,
documentation describing the three sub-tasks
is produced and made available for use in the
next phase.

Design – Strategies
 Software design is a process to conceptualize
the software requirements into software
implementation.
 Software design takes the user requirements
as challenges and tries to find optimum
solution.
 While the software is being conceptualized, a
plan is chalked out to find the best possible
design for implementing the intended
solution.

 There are multiple variants of software
design:
1. Structured Design: Structured design is a
conceptualization of problem into several
well-organized elements of solution.
 It is basically concerned with the solution
design.
 Benefit of structured design is, it gives better
understanding of how the problem is being
solved. Structured design also makes it
simpler for designer to concentrate on the
problem more accurately. 131RNB Global University, Bikaner.Course Code - 19003400

1. Structured Design: Structured design is
mostly based on ‘divide and conquer’
strategy where a problem is broken into
several small problems and each small
problem is individually solved until the whole
problem is solved.
 The small pieces of problem are solved by
means of solution modules.

1. Structured Design: Structured design
emphasis that these modules be well
organized in order to achieve precise
solution.
 These modules are arranged in hierarchy.
They communicate with each other. A good
structured design always follows some rules
for communication among multiple modules,
namely -.

1. Structured Design:
 Cohesion - grouping of all functionally related
elements.
 Coupling - communication between different
modules.
 A good structured design has high cohesion
and low coupling arrangements.

2. Function Oriented Design: In function-
oriented design, the system is comprised of
many smaller sub-systems known as
functions.
 These functions are capable of performing
significant task in the system. The system is
considered as top view of all functions.

2. Function Oriented Design: Function
oriented design inherits some properties of
structured design where divide and conquer
methodology is used.
 This design mechanism divides the whole
system into smaller functions, which provides
means of abstraction by concealing the
information and their operation.

2. Function Oriented Design: These functional
modules can share information among
themselves by means of information passing
and using information available globally.
 Function oriented design works well where
the system state does not matter and
program/functions work on input rather than
on a state.

2. Function Oriented Design: Design Process
 The whole system is seen as how data flows
in the system by means of data flow diagram.
 DFD depicts how functions changes data and
state of entire system.
 The entire system is logically broken down into
smaller units known as functions on the basis
of their operation in the system.
 Each function is then described at large.

3. Object Oriented Design: Object oriented
design works around the entities and their
characteristics instead of functions involved in
the software system. This design strategies
focuses on entities and its characteristics.
The whole concept of software solution
revolves around the engaged entities.
 The important concepts of Object Oriented
Design :

3. Object Oriented Design:
 Objects - All entities involved in the solution
design are known as objects. For example,
person, banks, company and customers are
treated as objects. Every entity has some
attributes associated to it and has some
methods to perform on the attributes.

 Classes - A class is a generalized description
of an object. An object is an instance of a
class. Class defines all the attributes, which an
object can have and methods, which defines
the functionality of the object.
 In the solution design, attributes are stored as
variables and functionalities are defined by
means of methods or procedures.

 Encapsulation - In OOD, the attributes (data
variables) and methods (operation on the
data) are bundled together is called
encapsulation. Encapsulation not only bundles
important information of an object together, but
also restricts access of the data and methods
from the outside world.
 This is called information hiding.

 Inheritance - OOD allows similar classes to
stack up in hierarchical manner where the
lower or sub-classes can import, implement
and re-use allowed variables and methods
from their immediate super classes.
 This property of OOD is known as inheritance.
This makes it easier to define specific class
and to create generalized classes from
specific ones.

 Polymorphism - OOD languages provide a
mechanism where methods performing
similar tasks but vary in arguments, can be
assigned same name. This is called
polymorphism, which allows a single interface
performing tasks for different types.
Depending upon how the function is invoked,
respective portion of the code gets executed.

Design – Process
 Software design process can be perceived as
series of well-defined steps. Though it varies
according to design approach (function
oriented or object oriented, yet It may have
the following steps involved:
 A solution design is created from requirement or
previous used system and/or system sequence
diagram.
 Objects are identified and grouped into classes on
behalf of similarity in attribute characteristics.
 Class hierarchy and relation among them is
defined.
 Application framework is defined. 145RNB Global University, Bikaner.Course Code - 19003400

Design – Approaches
 Two approaches:
1. Top Down Approach
2. Bottom - Up Approach

1. Top Down Approach: The top-down
approach uses the modular approach to
develop the design of a system.
 It is called so because it starts from the
top or the highest-level module and
moves towards the lowest level modules.
 In this technique, the highest-level
module or main module for developing
the software is identified.

1. Top Down Approach: The main
module is divided into several smaller
and simpler submodules or segments
based on the task performed by each
module.
 Then, each submodule is further
subdivided into several submodules of
next lower level.

1. Top Down Approach: This process of
dividing each module into several
submodules continues until the lowest
level modules, which cannot be further
subdivided, are not identified.

2. Bottom - Up Approach: Bottom-Up
Strategy follows the modular approach
to develop the design of the system. It
is called so because it starts from the
bottom or the most basic level modules
and moves towards the highest level
modules.
 In this technique,

2. Bottom - Up Approach: The modules
at the most basic or the lowest level are
identified.
 These modules are then grouped
together based on the function
performed by each module to form the
next higher-level modules.
 Then, these modules are further
combined to form the next higher-level
modules.

2. Bottom - Up Approach: This process
of grouping several simpler modules to
form higher level modules continues
until the main module of system
development process is achieved.

Input /output & Form Designing
 Input Design: In an information system,
input is the raw data that is processed to
produce output.
 During the input design, the developers
must consider the input devices such as
PC, MICR, OMR, etc.
 Therefore, the quality of system input
determines the quality of system output.
 Well designed input forms and screens
have following properties:. 153RNB Global University, Bikaner.Course Code - 19003400

 Input Design: It should serve specific
purpose effectively such as storing,
recording, and retrieving the information.
 It ensures proper completion with
accuracy.
 It should be easy to fill and
straightforward.
 It should focus on user’s attention,
consistency, and simplicity.

 Input Design: All these objectives are
obtained using the knowledge of basic
design principles regarding:
 What are the inputs needed for the system?
 How end users respond to different
elements of forms and screens.

 Objectives of Input Design: The
objectives of input design are:
1. To design data entry and input procedures
2. To reduce input volume.
3. To design source documents for data
capture or devise other data capture
methods
4. To design input data records, data entry
screens, user interface screens, etc.
5. To use validation checks and develop
effective input controls. 156RNB Global University, Bikaner.Course Code - 19003400

 Data Input Methods: It is important to
design appropriate data input methods to
prevent errors while entering data.
 These methods depend on whether the
data is entered by customers in forms
manually and later entered by data entry
operators, or data is directly entered by
users on the PCs.
 A system should prevent user from
making mistakes by:

 Data Input Methods:
 Clear form design by leaving enough space
for writing legibly.
 Clear instructions to fill form.
 Clear form design
 Reducing key strokes
 Immediate error feedback

 Data Input Methods: Some of the
popular data input methods are:
1. Batch input method (Offline data input
method).
2. Online data input method.
3. Computer readable forms.
4. Interactive data input.

 Data Input Methods: Input Integrity
Controls: Input integrity controls include
a number of methods to eliminate
common input errors by end-users.
 They also include checks on the value of
individual fields; both for format and the
completeness of all inputs.
 Data validation.

 Data Input Methods: Input Integrity
Controls: Audit trails for data entry and
other system operations are created
using transaction logs which gives a
record of all changes introduced in the
database to provide security and means
of recovery in case of any failure .

 Output Design: The design of output is
the most important task of any system.
During output design, developers identify
the type of outputs needed, and consider
the necessary output controls and
prototype report layouts.

 Objectives of Output Design:
 To develop output design that serves the
intended purpose and eliminates the
production of unwanted output.
 To develop the output design that meets
the end users requirements.
 To deliver the appropriate quantity of
output.

 Objectives of Output Design:
 To form the output in appropriate format
and direct it to the right person.
 To make the output available on time for
making good decisions.

 External Outputs:
 Manufacturers create and design
external outputs for printers.
 External outputs enable the system to
leave the trigger actions on the part of
their recipients or confirm actions to their
recipients.
 Some of the external outputs are
designed as turnaround outputs, which
are implemented as a form and re-enter165RNB Global University, Bikaner.Course Code - 19003400

 Intenal Outputs: Internal outputs are
present inside the system, and used by
end-users and managers.
 They support the management in
decision making and reporting.
 Thee types of Internal reports:
1. Detailed Report
2. Summary Report
3. Exceptional Report

 Output Integrity Controls: Output
integrity controls include routing codes to
identify the receiving system, and
verification messages to confirm
successful receipt of messages that are
handled by network protocol.

 Output Integrity Controls:
 Printed or screen-format reports should
include a date/time for report printing and
the data.
 Multipage reports contain report title or
description, and pagination. Pre-printed
forms usually include a version number
and effective date.

 Fom Designing:
 Both forms and reports are the product
of input and output design and are
business document consisting of
specified data.
 The main difference is that forms provide
fields for data input but reports are purely
used for reading.
 During form designing, the designers
should know: 169RNB Global University, Bikaner.Course Code - 19003400

 Fom Designing:
 Who will use them
 Where would they be delivered
 The purpose of the form or report
 During form design, automated design
tools enhance the developer’s ability to
prototype forms and reports and present
them to end users for evaluation.

 Objectives of Good Fom Designing:
 To keep the screen simple by giving
proper sequence, information, and clear
captions.
 To meet the intended purpose by using
appropriate forms.
 To ensure the completion of form with
accuracy.

 Objectives of Good Fom Designing:
 To keep the forms attractive by using
icons, inverse video, or blinking cursors
etc.
 To facilitate navigation.

 Types of Forms :
1. Flat Forms
 It is a single copy form prepared
manually or by a machine and printed on
a paper.
 For additional copies of the original,
carbon papers are inserted between
copies.
 It is a simplest and inexpensive form to
design, print, and reproduce, which uses
less volume.

2. Unit Set/Snap out Forms
 These are papers with one-time carbons
interleaved into unit sets for either
handwritten or machine use.
 Carbons may be either blue or black,
standard grade medium intensity.
Generally, blue carbons are best for
handwritten forms while black carbons
are best for machine use.

3. Continuous strip/Fanfold Forms
 These are multiple unit forms joined in a
continuous strip with perforations
between each pair of forms.
 It is a less expensive method for large
volume use.

 Types of Forms:
4. No Carbon Required (NCR) Paper
 They use carbonless papers which have
two chemical coatings (capsules), one
on the face and the other on the back of
a sheet of paper.
 When pressure is applied, the two
capsules interact and create an image.

Inputs to System Design
 System design takes the following
inputs:
 Statement of work.
 Requirement determination plan.
 Current situation analysis.
 Proposed system requirements including a
conceptual data model, modified DFDs, and
Metadata (data about data).

Outputs for System Design
 System design gives the following outputs:
 Infrastructure and organizational changes for the
proposed system.
 A data schema, often a relational schema.
 Metadata to define the tables/files and
columns/data-items.
 A function hierarchy diagram or web page map that
graphically describes the program structure.
 Actual or pseudocode for each module in the
program.
 A prototype for the proposed system.

File Organization
 It describes how records are stored within a
file, There are four file organization methods:
1. Serial: Records are stored in chronological
order (in order as they are input or occur).
Examples: Recording of telephone charges,
ATM transactions, Telephone queues.
2. Sequential: Records are stored in order
based on a key field which contains a value
that uniquely identifies a record. Examples:
Phone directories.

File Organization
3. Direct (relative): Each record is stored
based on a physical address or location on
the device. Address is calculated from the
value stored in the record’s key field.
 Randomizing routine or hashing algorithm
does the conversion
4. Indexed: Records can be processed both
sequentially and non-sequentially using
indexes.

File Organization
 File Access: One can access a file using
either Sequential Access or Random Access.
 File Access methods allow computer programs
read or write records in a file.
1. Sequential Access Every record on the file
is processed starting with the first record until
End of File (EOF) is reached. It is efficient
when a large number of the records on the
file need to be accessed at any given time.
 Data stored on a tape (sequential access) can
be accessed only sequentially.

File Organization
2. Direct (Random) Access : Records are
located by knowing their physical locations or
addresses on the device rather than their
positions relative to other records.
 Data stored on a CD device (direct-access)
can be accessed either sequentially or
randomly.

File Organization
 Types of Files used in an Organization
System: Following are the types of files used
in an organization system.
1. Master file: It contains the current
information for a system. For example,
customer file, student file, telephone
directory.
2. Table file: It is a type of master file that
changes infrequently and stored in a tabular
format. For example, storing Zipcode.

File Organization
3. Transaction file: It contains the day-to-day
information generated from business
activities. It is used to update or process the
master file. For example, Addresses of the
employees.
4. Temporary file: It is created and used
whenever needed by a system.
5. Archive file: Backup files that contain
historical versions of other files.

File Organization
6. Mirror files: They are the exact duplicates of
other files. Help minimize the risk of
downtime in cases when the original
becomes unusable.
 They must be modified each time the original
file is changed.
7. Log files: They contain copies of master and
transaction records in order to chronicle any
changes that are made to the master file.
 It facilitates auditing and provides mechanism
for recovery in case of system failure.

Documentation
 Documentation is a process of recording
the information for any reference or
operational purpose.
 It helps users, managers, and IT staff,
who require it.
 It is important that prepared document
must be updated on regular basis to
trace the progress of the system easily.

Documentation
 After the implementation of system if the
system is working improperly, then
documentation helps the administrator to
understand the flow of data in the system
to correct the flaws and get the system
working.
 Programmers or systems analysts
usually create program and system
documentation.

Documentation
 Systems analysts usually are
responsible for preparing documentation
to help users learn the system.
 In large companies, a technical support
team that includes technical writers
might assist in the preparation of user
documentation and training materials.

Documentation - Advantages
1. It can reduce system downtime, cut
costs, and speed up maintenance
tasks.
2. It provides the clear description of
formal flow of present system and helps
to understand the type of input data and
how the output can be produced.
3. It provides effective and efficient way of
communication between technical and
nontechnical users about system.

Documentation - Advantages
4. It facilitates the training of new user so
that he can easily understand the flow
of system.
5. It helps the user to solve the problems
such as troubleshooting and helps the
manager to take better final decisions of
the organization system.
6. It provides better control to the internal
or external working of the system.

Documentation - Types
 When it comes to System Design, there
are following four main documentations:
1. Program documentation
2. System documentation
3. Operations documentation
4. User documentation

Review
 Problem definition.
 Identification and Investigation of system.
 Fact finding techniques.
 Tools for documenting procedures and
decisions .
 System design considerations.
 Process and stages of system design: Logical
and Physical.
 Selection of best alternate design strategy.

Thank You!

Requirement analysis

More Related Content

What's hot

Similar to Requirement analysis

More from Jaipal Dhobale

Recently uploaded

Requirement analysis