0% found this document useful (0 votes)
15 views71 pages

BA Requirement Analysis and Business Process Modelling 21

The document provides a comprehensive overview of requirement analysis and process modeling, defining requirements and their types, including business, user, and functional requirements. It discusses the importance of understanding stakeholder needs through requirement elicitation and outlines various modeling techniques such as data flow diagrams and process mapping. Additionally, it highlights tools like SIPOC and Six Sigma for process improvement and emphasizes the interconnectedness of business processes and requirements.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views71 pages

BA Requirement Analysis and Business Process Modelling 21

The document provides a comprehensive overview of requirement analysis and process modeling, defining requirements and their types, including business, user, and functional requirements. It discusses the importance of understanding stakeholder needs through requirement elicitation and outlines various modeling techniques such as data flow diagrams and process mapping. Additionally, it highlights tools like SIPOC and Six Sigma for process improvement and emphasizes the interconnectedness of business processes and requirements.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 71

Requirement Analysis &

Process Modelling
Definition of a Requirement
• A condition or capability needed by a stakeholder to
solve a problem or achieve an objective.
• A condition or capability that must be met or
possessed by a system or system component to satisfy
a contract, standard, specification, or other formally
imposed documents.
• A documented representation of a condition or
capability.
• Requirements serve as the foundation of solution or
system components.
Dr. Gita A. Kumta
School of Business Management, NMIMS
Software Requirement
• A property which must be exhibited by software developed
or adapted to solve a particular problem.
• The problem may be to
– Automate part of a task of someone who will use the software,
– Support the business processes of the organization that has
commissioned the software,
– Correct shortcomings of existing software,
– Control a device.
• Requirements are typically a complex combination of
requirements from
– Different people at different levels of an organization,
– Environment in which the software will operate.
• Essential property of all software requirements is that they
should be verifiable.

Dr. Gita A. Kumta


School of Business Management, NMIMS
Types of Requirements

Physical
Interfaces Users &
Environment
Human factors
Security
Functionality

Resources Software
Requirements Data

Quality
Assurance Documentation

Dr. Gita A. Kumta


School of Business Management, NMIMS
Types of Requirements
• Business Requirements
• User Requirements
• Functional Requirements
• Quality of Service Requirements
• Assumptions and Constraints.
• Implementation requirements

Dr. Gita A. Kumta


School of Business Management, NMIMS
Basic Requirements

• What is the basic business process?


- What is the purpose of this business activity?
- What steps are performed?
- Where are they performed?
- Who performs them?
- How long does it take?
- How often is it done?
- Who uses the resulting information?
• What data is used or produced during that process?
• What are the limits imposed by time and the
volume of work?
• What performance controls are used?

Dr. Gita A. Kumta


School of Business Management, NMIMS
User Transaction Requirements

• What makes up the transaction?


• Who & what condition initiates the transaction?
• What details are needed to process the transaction?
• What is the volume?
• What information is generated?
• What data needs to be stored? For how long?
• Well structured, Recur frequently, Emphasize details

Dr. Gita A. Kumta


School of Business Management, NMIMS
User Decision Requirements

• What information is used to make the decision


• What is the source of the information?
( Is it produced by the transaction? Does not result from
processing transactions? Is the data from an external source?)
• How should data be processed? (Logic)
• How should the information be presented?
(Report / Query)
• Structured by the individual, Lack routine, Summary

Dr. Gita A. Kumta


School of Business Management, NMIMS
Requirements Traceability

Dr. Gita A. Kumta


School of Business Management, NMIMS
Requirement Elicitation
• To ensure that a stake holder's actual
underlying needs are understood, rather than
their stated or superficial desires.
• The process of how business analysts work
with stakeholders to identify and understand
their needs and concerns, and understand the
environment in which they work.

Dr. Gita A. Kumta


School of Business Management, NMIMS
Elicitation of Requirements
• Who are the customers of the process?
• Who performs each activity?
• What generates the process/task?
• What forms and reports are used?
• What computer systems and files are used?
• How do we do it? Why do we do it?
• What decisions are made in the process?
• What happens next? What sequence are the activities performed in?
• Who reviews it and when?
• How long does it take?
• What is the nature, frequency and cause of errors/problems?
• How are errors/problems/exceptions handled?
• What is the output? How many?
• Where does the output go?
What should we understand?
Responsibilities The key responsibilities of the process area

Activities The key activities of the process area

Inputs The main sources of data input for each activity

Outputs The key deliverables of each activity (internal &


external)

Customers Recipients of the outputs of each activity

Performance Indicators Key Performance Indicators e.g. cycle time for


process

Volumes Key volumes related to an activity e.g.no. of


items produced per day
Workflow/Dependency Diagram
Activity Dept A Dept B Person C
1. Set New Account Critieria
Sequential
2. Accept New Account dependency
3.Determine Requirements
Parallel
4. Allocate Manpower
dependency
5. Allocate Supplies

6. Sell Lottery tickets Repetitive


7. Select Winning Ticket
dependency

8. Announce Winning Ticket

9. Accept Credit Information Optional


dependency
10. Accept Personal
References
11. Approve/Reject Loan
Simulation
• Simulation is the imitation of some real thing,
state of affairs, or process. The act of simulating
something generally entails representing certain
key characteristics or behaviours of a selected
physical or abstract system.
• Business Simulation allows managers to try out
various options or scenarios to assist in the
decision making process.
Types of Simulation
• Physical simulation: Physical objects are substituted for
the real thing because they are smaller or cheaper than the
actual object or system.
• Interactive simulation: A special kind of physical
simulation in which physical simulations include human
operators, such as in a flight simulator or a driving simulator.
• Computer simulation: An attempt to model a real-life or
hypothetical situation on a computer so that it can be studied
to see how the system works. By changing variables,
predictions may be made about the behaviour of the system.
Critical Analysis

What Why What Else


is being done is it being done is being done
Who Why Who Else
is doing it are they doing it could do it
When Why When Else
Are they doing it then could it be done
Where Why Where Else
Is it being done there could it be done
How Why How Else
is it being done that way could it be done
Why-Why Analysis
Bad quality milk
Bad quality milk
Milk gone off Fridge Cold
Milk gone off Fridge Cold
Milk gone off
Milk gone off
etc.
etc.
Local store closed
Local store closed
Can't go to store
Can't go to store
Large store too far
Large store too far
No Milk in Fridge
No Milk in Fridge
To eat cereal
Housemates To eat cereal
Housemates
finished milk
finished milk To feed cat
To feed cat

Rent too high


No Money to buy Rent too high
No Money to buy
milk
milk Too many debts
Too many debts

Insufficient Salary
Insufficient Salary
Cause and Effect Diagram

Outside
Influences Quality
Housemates
Cheap Milk
finished milk Expired
Faulty Fridge

Fridge not cold No money


For breakfast

For Micky the Milk gone off


cat
No Milk in
Large store too far
Fridge
Milk ran out
Rent too high
Battery dead Closed on Sundays
Mortagage
Lazy
Left lights on Poor Salary Student loans
Old battery
Small Store Too many
Car won't start
Insufficient debts

Supplies No Money
Requirements 4-dimensional Views
User Stories
Process Maps Data Models
Use Cases Data Dictionary
Scenarios (information;
Behaviour Structure data; objects)
Activity diagrams
Workflow models
(process; action; Control
function; task;
script) Business Rules
Validation Rules
Process models
cannot stand
alone and must All 4 views are important
trace to data and
Dynamics and rely on each other to
business rules provide a holistic
perspective of the
Event/Response requirement.
State Diagrams
(time; lifecycles)
Dr. Gita A. Kumta
School of Business Management, NMIMS
Modeling Business
Processes
What is Business Modeling?
A representation of the Business as one
large system showing
- Interconnections
- Inter dependencies
- Business Processes
Based on the organisation’s goals,
objectives and strategic plans.
Components of a Business
Model
In Business Modeling we model the
business as an integrated system
taking the processes and materials
as resources.
Information is a critical resource
for managing all other Resources
What is a Business Process?
Process
Trigger Policy development Value-Added
Assessment
Input Output
Customer Service
Order Fulfilment
Application Procedure

Customer

A process is...
• A series of related activities that “flow” through an organisation
• Not limited to a single function or department
• Something that can be viewed from end to end
Elements of a Business Process
• Has a Goal
• Has specific inputs
• Has specific outputs
• Uses resources
• Has a number of activities that are performed in some
order
• May affect more than one organizational unit.
Horizontal organizational impact
• Creates value of some kind for the customer. The
customer may be internal or external.
Business Process Modeling

Provides ways of expressing business


processes or strategies in terms of activities
and collaborative behaviour to better
understand the process and the participants in
the process.
What is Process mapping?
• Process mapping is a tool that is used to
understand, analyse and document processes
and activities in an organisation and assist in
identifying opportunities for improvement
• A process map displays the sequential steps
involved in converting a specific input into the
required output
Deliverables of Process Mapping
• An action plan for implementation containing
identified and prioritised suggestions for
improvement.
• Documented differences between existing
work flow and Best Practices.
• Identified problem areas using root cause
analysis
• Documented existing work flow with
highlighted problems.
Identify Opportunities for Improvement

Go beyond understanding the current flow to


identifying areas for improvement, such as:
• Process opportunities
• Technology opportunities and issues
• Short-term fixes or urgent action items
Tools for Business Process
Modeling
• Flow Chart
• Activity Flow Diagram
• Data Flow Diagram
• Use – Case Diagram
• SIPOC of Six Sigma
• System Dynamics
• Business Process Modeling Notation
(BPMN)
Flowcharting
• A tool for analysing processes and is the most basic
method of process mapping..
• A graphical representation of sequence of activities
carried out as part of the process from start to end
along with their inter-relationships and inter-
dependence.
• Promotes better understanding of processes.
• Helpful in understanding the logic of complicated
and lengthy problems.
• Flowcharts are usually drawn using some standard
symbols.
Standard Symbols Used For
Flowcharting
Start or end of the
program
Computational steps or
processing function of a
program
Input or output
operation

Decision making and branching

Connector or joining of two parts


of program

Flow line
Document Logic
Sum Of First 50 Natural Numbers
Understand
Process
Predictive Car Maintenance of a Rental
Car
• Involves obtaining and using information
about the problems with the cars from
customers.

• Relevant problems are those that can be


prevented in the future through predictive
maintenance.
Activity Flow Representation
Cross-Functional Flowcharts - ‘Swim
Lanes’
Publication Process

Publication Process
Customer

Order received
Request

The
Printing

information
Dept

to be Printing Process
published is
collected
Packaging

The printed
material is stuck
Dept

and bound
together

Spelling checks
Dept

Ready for
QA

for grammar and


distribution?
spelling are run
Shipping

Order
Fulfilment
Process
DATA FLOW DIAGRAMS

• Data flow diagrams illustrate how data


is processed by a system in terms of
inputs and outputs.
• Notations
- Process

Not Satisfied
- Data store Satisfied

- Data flow
- External Entity
• Types of Notations
• Yourdon & Coad
• Gane & Sarson.
Data Flow Diagram Symbols
Process
A process transforms incoming data flow into
outgoing data flow.

Data Store
Data stores are repositories of data in the system.
They are sometimes also referred to as files.

Dataflow
Data flows are pipelines through which packets of
information flow. Label the arrows with the name
of the data that moves through it.

External Entity
External entities are sources and destinations of the
system's inputs and outputs.
Context Diagram
Supplier/
Vendor Management
Customer

Purchas
Stock of goods e order Supply Stoc Accurate
delivered req k Productio Demand
n strategy vs
wastage
data
Inventory MIS for Production
Production staff/shop floor
Planning & manager and
Stock Execution workers
Inventor Productio
y n Cycle
Consumption New
and new Order
demand/ new
stock
Data Flow Diagram Notations

Data Flow

Processes

Source or Destination of data

Data Store
Rules for drawing DFD
• Work from the Top Down
• Explode Processes for More Details
• Maintain consistency between Processes
• Add controls on lower-level Diagrams
• Assign meaningful Labels
• Avoid
- Document copy description
- Time descriptions, logic, control description
(if’,’when’)
- Procedure control descriptions (Get next)
Data Flow Diagram Layers
• Draw data flow diagrams in several nested layers.
• A single process node on a high level diagram can
be expanded to show a more detailed data flow
diagram.
• Draw the context diagram first, followed by various
layers of data flow diagrams.
Context Diagrams

• A business context diagram is a top


level data flow diagram which
depicts the relationship among
business role players and the data
they exchange.
• It represents the entire system under
investigation.
• The system under investigation is
represented as a single process,
connected to external entities by data
flows and resource flows.
Developing DFDs
• Context diagram is an overview of an
organizational system that shows:
• the system boundaries.
• external entities that interact with the
system.
• major information flows between the
entities and the system.
• Note: only one process symbol, and no
data stores shown
Context Diagram of a Food-
ordering System
Level-1 Diagram

Level-1 DFD of the food-


ordering system
Six Sigma
• Structured, disciplined, rigorous, approach to
process improvement
• Tactical
• Stages
– Define
– Measure
– Analyze
– Improve
– Control
SIPOC diagram
• A tool used by a team to identify all relevant elements
of a process improvement project before work begins.
• It helps define a complex project that may not be well
scoped, and
• Is typically employed at the Measure phase of the Six
Sigma DMAIC methodology.
• Similar and is related to Process Mapping tools, but
provides additional detail.
Understanding SIPOC
• Prompts the team to consider the
– Suppliers (the 'S' in SIPOC) of your process,
– Inputs (the 'I') to the process,
– Process (the 'P') your team is improving,
– Outputs (the 'O') of the process, and the
– Customers (the 'C') that receive the process outputs.
• In some cases, Requirements of the Customers can
be appended to the end of the SIPOC for further
detail.
What is a Relationship?
• Relationship indicates “connectedness”;
A "fact" that must be "remembered"
by the system and cannot or is not
computed or derived mechanically
• Several instances of a relationship can exist
• Objects can be related in many different
ways
ERD Notation
One common form:
(0, m)
object1 relationship object 2
(1, 1)

attribute

Another common form:

object1 relationship object 2


(0, m) (1, 1)
Building an ERD
• Level 1—model all data objects (entities)
and their “connections” to one another

• Level 2—model all entities and


relationships

• Level 3—model all entities, relationships,


and the attributes that provide further depth
The States of a System
• state—a set of observable circumstances
that characterizes the behavior of a system
at a given time
• state transition—the movement from one
state to another
• event—an occurrence that causes the
system to exhibit some predictable form of
behavior
• action—process that occurs as a
consequence of making a transition
Behavioral Modeling

• Make a list of the different states of a system


(How does the system behave?)
• Indicate how the system makes a transition
from one state to another (How does the
system change state?)
– indicate event
– indicate action
• Draw a state transition diagram.
State Transition Diagram Notation

state

event causing transition


action that occurs

new state
The Control Model

The control flow diagram is


"superimposed" on the DFD and shows
events that control the processes noted in
the DFD
Requirement Analysis
• Refine the overall system Definition
• Prepare detailed software specifications
- Information flow ( DFD)
- Interfaces
- Functional requirements
- Design requirements &constraints
- Coding structures
- Testing criteria
• Software Requirement Specifications (SRS)
is the basis for software development
Writing the Software Specification
• Use a layered format that provides increasing
detail
• Define all acronyms
• Include a table of contents and a glossary
• Write in a simple, unambiguous style
• Draw a picture to depict a structure described in
words
• Specify the calculations with atleast two examples
• Put yourself in the reader's position, "Would I
be able to understand this if I wasn't intimately
familiar with the system?"
Example of AS-Is and To-Be Processes
Procurement Process
How the process worked? (“As Is”)
How the process worked?
(“As Is”)
How the process worked?
(“As Is”)
How the process worked?
(“As Is”)
How the process worked?
(“As Is”)
Reengineered Process (“To Be”)
Reengineered Process (“To Be”)
Reengineered Process (“To Be”)
Reengineered Process (“To Be”)
Reengineered Process (“To Be”)
Reengineered Process (“To Be”)

You might also like