Business Process ReEngineering

AAU School of
Commerce
Course Title: Introduction to Business
Information System
Business Proc ess Engineering
Dec -22, AA
Business Process Engineering
Agenda:
 Definitions and c onc epts
 Requirements Engineering (As-IS)
 System Design (To-Be)
 Implementation
 Verific ation and Validation
 Maintenance.
 SDLC models
 Tools and tec hniques for IS development
Dec-22 Business Process Engineering 2

Business Process Engineering
Objectives:
After the end of this chapter students will be able to
 Identify phases of system development and models
 Disc uss Requirements Engineering and its objec tives
 Explain the purpose of the Design phase and identify tasks
 Identify the major activities in the implementation phase
 Explain Verific ation and Validation
 Disc uss the nec essity of maintenanc e.
 Identify some tools and techniques for ISdevelopment
Business Process Engineering: Definitions
 A process is a specific ordering of work activities across time and
space, with a beginning, an end, and clearly identified inputs and
outputs:a struc ture for ac tion.
 A business process is a group of logically related activities that use
the firm’s resources to provide customer-oriented results in support
of organization’s objec tives.
 A business process is the DNA of a company.
 Business process Engineering focuses (in our case) on automating
business processes with software processes and on assisting the
analysis, design, implementation, control, maintenance, and
optimization of software development process to ensure success.
 It is also called, –Business process Re-engineering –Business process
Re-design

 Software engineering is an important and critical discipline
concerned with cost effective software development.
 It is based on a systematic approach that uses appropriate tools
and techniques, operates under specific constraints and most
importantly follows a proc ess.
 The IEEE definition- Software Engineering:
1. The application of a systematic, disciplined, quantifiable
approac h to the development, operation, and maintenanc e
of software; that is, the application of engineering to software.
2. The study of approac hes as in 1)

A layered technology
 Software engineering is a layered technology which includes:
 Tools
 Methods
 Proc ess and
 Quality foc us

 The foundation for software engineering is the process layer.
 The software engineering process is the glue that holds the
technology layers together and enables rational and timely
development of computer software.
 Process defines a framework that must be established for effective
delivery of software engineering tec hnology.
 The software process forms the basis for management control of
software projects and establishes the context in which technical
methods are applied, work products (models, documents, data,
reports, forms, etc.) are produced, milestones are established,
quality is ensured, and change is properly managed.

 Software engineering methods provide the technical how-to’s for
building software.
 Methods encompass a broad array of tasks that include
communication, requirements analysis, design modeling, program
c onstruc tion, testing, and support.
 Software engineering methods rely on a set of basic principles that
govern each area of the technology and include modeling
activities and other descriptive techniques.

 Software systems which are intended to provide automated support
for software process activities
 Upper-CASE
o Tools to support the early process activities of requirements and
design, and planning
 Lower-CASE
o Tools to support later activities such as programming, debugging
and testing

Business Proc ess Engineering: SDLC
 Software System development process contains fundamental
ac tivities or phases.
 These phases are:
o Requirements engineering (As-Is),
o System Design (To-Be),
o Implementation,
o Verification and Validation, and finally
o Maintenance.
 These phase can be seen reorganized in different form in other
texts. However the main idea is related.
Dec-22 10
Requirements Engineering
 It is the process of establishing the needs of stakeholders that are to
be solved by software.
 Why is this phase so important?
o In general the c ost of c orrec ting an error depends on the
number of subsequent dec isions that are based on it.
o Therefore, error made in understanding requirements have the
potential for greater cost because many design and other
following phase decisions depend on RE results.
Dec-22
 It is also called requirements analysis and specification
 How c an we c ollec t the right requirements?
 Traditional requirements engineering does so through a set of steps:
The first step is
 Requirements Elicitation which is the collection of requirements from
stakeholders and other sources and can be done in a variety of
ways (methods)
o [through questionnaire survey, interview, brainstorming, prototype, document
analysis, work plac e observation, and so on]
Dec-22
 Requirements analysis which involves the study and deeper
understanding of the collected requirements.
o Structuring/modeling of system requirements is also part of this
activity.
 Specification of requirements in which the collected requirements
are suitably represented organized and saved so that they can be
shared (SRS).
o They can be validated and delivered (as SRS).
 Requirements management may account to changes to
requirements during the life time of the project.
Dec-22
Design
 It is the phase where the description of the internal structure and
organization of the system are produced and this description will
serve as the basis for the construction of the actual system.
 Design activities normally consist of architectural design, abstract
specification, interface design, component or subsystem design,
persistent data management, and so on.
 These activities result in a set of design products which describe
various c harac teristic s of the system.
o Software/System spec ific ation
Dec-22
System Implementation
 Here what we do is basically realizing the design of the system that
we just c reated and c reate an ac tual software system.
 There are four fundamental principles or pillars that can affect the
way software is c onstruc ted.
o The first is the reduction of complexity (Usability).
o The second is the anticipation of diversity (Agility).
o The third pillar is the structuring for validation (Testability).
o Finally it is important that the SW conforms to standards
(Interoperability and other issues).
Dec-22
Verification and Validation

 After we have built the system, here is the phase where we check
that the software system meets its specification and fulfills its
intended purpose.
 Validation is the activity that answers the question, did we build the
right system?
 Verification answers a different question, did we build the system
right? Did we build the system that actually implement the
spec ific ation that we defined?
Dec-22
Verification and Validation

 Verification can be performed at the unit level, integration level,
and finally the system as a whole.
 Thus, in verification, we want to make sure that the different
modules talk to eac h other in the right way.
 During system testing, we test the system as a whole and want to
make sure all the system, all the different pieces of the system work
together in the right way.
 This is also the level at which we apply validation and some other
testing techniques like stress testing or robustness testing and so on.
Dec-22
Maintenance
 Software development effort normally result in the delivery of a
software produc t that satisfies the user requirements. However,
when the software is in operation many things can happen.
 The environment might change (there might be new libraries, new
operating systems) in which our software system has to operate.
 There may be feature request that the users might want to do
something different with the product that we gave them.
 Or users might have problems with the software and may file bug
report.
Dec-22
Maintenance
 Software maintenance is the activity that sustains the software
produc t as it evolves throughout its lifec yc le.
 Development organizations should perform three kinds of
maintenanc e ac tivities:
 Corrective maintenance to eliminate problems with the code (bug).
 Perfective maintenance to accommodate feature requests (and in
some cases just to improve the software for example to make it
more effic ient, refac toring).
 Adaptive maintenanc e to take c are of environment c hanges.
 Preventive maintenance , involves those activities intended to
reduce the chances of a system failure or extend the capacity of a
c urrent system’s useful life.
Dec-22
Maintenance
 And after these activities have been performed, the software
developer will produce a new version of the application and will
release it and the cycle will continue throughout the lifetime of the
software.
 That is why maintenance is a fundamental activity and very
expensive one.
 One of the reasons, in addition to the reasons in the previous slide,
why maintenance is expensive is regression testing. Regression
testing is the activity of retesting software after it has been modified.
Dec-22 20
Tools and Techniques for ISDevelopment: Data Collection Techniques
Traditional Methods for gathering requirements: Interview
 The traditional ways to get information directly from those who have
the information include conducting interviews, questionnaires, direct
observation and document analysis.
Interview
 The SA has to spend a large amount of time in interviewing the
people about their work, the information they use to do it and the
types of information processing that might supplement their work
 Other people are too interviewed to understand organizational
direc tion, polic ies and expec tations that managers have on the
units they supervise.
 The fac ts, opinion and spec ulation (rumor) are gathered, the body
language, emotions and other signs of what people want and how
they assess c urrent systems.
 SA can sometimes determine if people are answering truthfully or
fully by the words they use, whether they make direct eye contact,
the tone of voic e they use or their body language.
Dec -22 Business Proc ess Engineering 21

Tools and Techniques for IS Development: Data Collection Techniques
Guidelines for effective interview
 Prepare thoroughly before the interview. Set up an appointment at
a convenient time for the interviewee. The general nature of the
interview should be explained to the interviewee in advance.
 You want the interview to be natural and to some degree, you want
to direc t the interview spontaneously as you disc over what
expertise the interviewee brings to the session.
 Prepare an interview guide or checklist so that you know in which
sequence to ask your questions and how much time to spend in
each area of the interview.
 The interviewee may provide information you were not expecting,
you may not follow the guide in sequence. However check off
questions you have asked and write remainders to yourself to return
to or skip other questions as the interview takes place.
Dec-22 22
Choosing interview Questions
 The open-ended and closed-ended questions must be mixed.
 Open-ended questions in interviews and on questionnaires are those that
have no pre-specified answers.
 The advantages of open-ended questions: previously unknown information
can surface, and interviewee may get more of a sense of involvement and
c ontrol in the interview.
 The major disadvantage of open-ended questions in the length of time it can
take for the questions to be answered.
 Closed-ended questions provide a range of answers from which the
interviewee may choose.
 These sort of questions works well when the major answers to questions are
well known. Another plus is that interviews based on these questions do not
require a large time.
 The major disadvantage of closed-ended questions is that useful information
that does not quite fit the defined answers may be overlooked as the
respondent tries to make a choice instead of providing his or her best
answers.

Interview Guidelines
 Don’t phrase a question in a way that implies a right or wrong answer.
Enable the respondents to feel free to tell their true opinions and
perspectives and make them to trust that their ideas will be considered
carefully.
 Listen carefully to what is being said, take notes, or if possible record the
interview with their permission. Sc hedule follow ups.
 Once the interview is over, key in or document it within 48 hours, otherwise
your memory of the interview will fade quic kly.
 Organize the notes, write down the additional questions that might arise
from lapses in the doc ument or ambiguous information. Separate fac ts
from your opinions and interpretations. Make a list of unclear points that
need clarification. Call the person and get answers to these questions.
You may send a written copy of your notes to the person you interviewed
to check for accuracy. Make sure to thank the person for his or her time.

Interview Guidelines
 Be careful during the interview not to set expectations about the
new or replacement system unless you are sure these features will
be part of the delivered system. Let the interviewee understand the
steps to the project. Due to the repetitive nature of the systems
development process, it is premature to say now exactly what the
ultimate system will or will not do.
 Seek a variety of perspectives from different people: potential users
of the system, users of other system that might be affect by this new
system, managers, superiors, information systems staff and others.
Encourage people to think about current problems and
opportunities and what new information services might better serve
the organization.

Traditional Methods for gathering requirements: Questionnaires
 Questionnaires have the advantage of gathering information from
many people in a relatively short time. Interviews are quite
expensive and time-consuming process, but the questionnaires are
not expensive.
 Questionnaires are passive and often yield less rich information than
interviews.
 Questionnaires are most useful in the requirements determination
process when used for very specific purposes rather than for more
general information gathering.

Choosing Questionnaire Respondents
 It must be decided which questionnaire to be given to which group
of people. It should be send to representatives of all users.
 The representatives can be selected by any one or combination of
these following
 Those c onvenient to sample: The people those willing to be
surveyed, or those most motivated to respond.
 A random group: the nth person of all users list c an be c hosen
randomly
 A purposeful sample: Only people who satisfy c ertain c riteria, suc h
as users of the system.

Designing Questionnaires
 Questionnaires are less expensive means that the people c an
complete the questionnaire without help. Also answers can be
provided at the c onvenienc e of the respondent.
 Questionnaires may include closed-end questions and open-end
questions, preferably closed-end questions, because they are easier
to complete and they define the exact coverage required.
 A few open-ended questions give the person being surveyed an
opportunity to add insights not anticipated by the designer of the
questionnaire.
 The questions must be extremely clear in meaning and logical in
sequence, without ambiguity in question and answers.

Choosing between Interviews and Questionnaires
 The interviews are good tools for collecting rich, detailed
information and that interview allow exploration and follow-ups but
quite time intensive and expensive.
 The questionnaires are inexpensive and take less time, as specific
information can be gathered from many people at once but the
information gathered is less ric h and follow up questions is more
diffic ult as it often involves interview or phone c alls
 These differences are important to remember during the analysis
phase. Deciding which method to use and what strategy to employ
to gather information will vary with the system being studied and its
organizational c ontext.

Traditional Methods for gathering requirements: Onsite observation
 It is also possible to gather information about a system by watching the users of the
system at work.
 This method can bring more objective information - as the analyst can see what
the person does (behavior), rather than what they say they do.
 This can be used to supplement or confirm the information obtained by asking
questions.
 Observation c an take plac e in two ways.
 1. By the analyst participating in the user’s work Ex. becoming a member of the team for a week
 2. By watching the users at work – this can be done in person or by video camera.
 The advantages of observation over asking questions is that the analyst can see
what the user’s behavior and interactions with the system actually are, not what
they say they are.
 There are also disadvantages to observation – while being observed, people may
not behave normally ( if they know they are being observed) – they may change
their behavior. Also the time at which the observation takes place may mean that
the analyst sees only a small subset of the work done by the user.
Traditional Methods for gathering requirements: Document Analysis
 Another way to gather information about the current system or
possible improvements to it is to review and analyze
documentation
 This c an provide information about :
 Problems with existing systems (Ex. Missing information, redundant
steps)
 Possible new features that can be added to existing systems, if
certain new information is now available (Ex. analysis of sales based
on customer type)
 Spec ial C irc umstanc es that oc c ur irregularly but may not be
identified by any other requirements gathering technique (Ex. if
special handling is required for a few very large volume customers,
where customized customer ordering procedures are required)

Traditional Methods for gathering requirements: Document Analysis
(Reports, forms, proc edures and manuals)
 Data definitions, rules for processing data (Business rules) in the system.
 Relevant type of doc umentation inc lude:
 Written work procedures for an individual role or a work group – a work procedure
describes how a particular job or task is carried out, it includes the data and
information used and c reated in the proc ess.
 Business forms – forms are used for many business functions Ex. in a bank, there
are forms for making deposits, withdrawals, transfers etc. forms can provide good
understanding of a system because they explicitly show what data flows in and
out of the system.
 Reports generated by current systems- it is possible to work back from the
information on the report to understand what data was used to generate the
report. Analysis of reports can determine what data needs to be captured over
time and over what time periods, and how the data needs to be manipulated or
transformed.
 Documentation about current computer systems – if the team that analyzed,
designed and built the existing system also produc ed good doc umentation
about the system (specifications, test plans, user manuals etc) then this can be a
good sourc e of information about the system.

Modern Methods for gathering requirements: Joint Application Design (JAD)
 The modern methods are additional techniques to collect information
about the current system, the organizational area requesting the new
system, and what the new system should be like: the modern methods are
Joint Applic ation Design and Prototyping.
 These techniques reduce the time of collecting and structuring the
requirements.
Joint Application Design (JAD)
 JAD is a means to bring together the key users, managers, and systems
analysts involved in the analysis of a current system.
 The goal of JAD is to collect systems requirements simultaneously from the
key people involved in the system.
 JAD sessions are usually conducted in a location away from where the
people normally work, to keep them away from all distractions, so that
they c an c onc entrate fully on systems analysis.
The people involved in JAD inc lude:
 JAD session leader: To organize and run the JAD- should be trained in
facilitation and group management and is usually a systems analyst.
Sets The agenda, resolves conflicts and disagreements, keeps the
session on trac k and gets all ideas from partic ipants
 Users:Key users of the existing and new system
 Mangers of User group: To provide information about the
organization’s direc tion and the motivations and impac ts of the
systems, also to support the requirements determined during the JAD.
 Systems Analysts: To learn from users and mangers, may partic ipate
and advise on ISissues
 Sponsor: A senior person in the organization who is supporting and
providing the budget for the development, usually attends only at start
and end of session
Dec-22 34
 Sc ribe:To take notes during the

sessions and rec ord the
outcomes of the meeting (on a
laptop or PC if possible)
 IS staff: To learn from the
disc ussion, may also c ontribute
ideas on tec hnic al feasibility or
limitations of systems
 JAD sessions are held in a
special room equipped with
white boards, audiovisual tools,
overhead projec tor, flip c harts
and computer generated
displays. Figure-5.1 A typical room layout for a JAD session

Modern Methods for gathering requirements: Prototyping
 Prototyping allows to quickly converting basic requirements into a working,
though limited, version of the desired information system. The user can
view and test the prototype.
 The goal of prototyping is to support requirements determination to
develop concrete specifications for the ultimate system, not to build the
ultimate system.
 Prototyping is most useful in the following circumstances
o User requirements are not clear or well understood
o Only one or a few users involved
o Possible designs are c omplex
o Communication problems have existed in the past, between users and analysts
 It also has some disadvantages
o Analysts may avoid creating formal documentation of the system
o The prototype may be very influenced by the initial user who reviews it- and thus
might not be adaptable to other users
o Often build as a stand-alone system, whic h may result in interfac es with other
systems being ignored during this phase.

Dec -22 36
Business Process Engineering: SDLC Models
Waterfall model
 The waterfall approac h is one
of the oldest SDLC models, but it
has fallen out of favor in rec ent
years.
 This model involves a rigid
struc ture that demands all
system requirements be defined
at the very start of a projec t.
Only then c an the design and
development stages begin.
 Once development is
c omplete, the produc t is tested
against the initial requirements
and rework is assigned.
Dec-22
Prototyping model
 In the prototyping methodology,
the design team's foc us is to
produc e an early model of the
new system, software, or
application.
 This prototype won’t have full
func tionality or be thoroughly
tested, but it will give external
c ustomers a sense of what’s to
come.
 Then, feedbac k c an be gathered
and implemented throughout the
rest of the SDLC phases.
 Onc e the prototype is ac c epted,
the full system will be
implemented.
Dec-22
Spiral model
 Spiral model is one of the most important Software Development
Life Cycle models, which provides support for Risk Handling.
 In its diagrammatic representation, it looks like a spiral with many
loops.
 Each loop of the spiral is called a Phase of the software
development process.
 The exact number of phases needed to develop the product can
be varied by the project manager depending upon the project
risks.
Dec-22
Spiral model
Dec-22 40
Agile model
 Agile SDLC model is a combination of iterative and incremental
process models with focus on process adaptability and customer
satisfaction by rapid delivery of working software product.
 Agile Methods break the product into small incremental builds.
 These builds are provided in iterations. Each iteration typically lasts
from about one to three weeks. Every iteration involves cross
functional teams working simultaneously on various areas like −
Planning, Requirements Analysis, Design, C oding, Unit Testing and
Acceptance Testing.
 At the end of the iteration, a working produc t is displayed to the
c ustomer and important stakeholders.
Dec-22
Agile model
 Agile model believes that every project needs to be handled
differently and the existing methods need to be tailored to best suit
the projec t requirements.
 In Agile, the tasks are divided to time boxes (small time frames) to
deliver specific features for a release.
 Iterative approach is taken and working software build is delivered
after eac h iteration.
 Each build is incremental in terms of features; the final build holds all
the features required by the customer.
Dec-22
Agile model
 The most popular Agile methods inc lude
 Rational Unified Proc ess (1994),
 Sc rum (1995),
 Crystal Clear, Extreme Programming (1996),
 Adaptive Software Development, Feature Driven Development,
and Dynamic Systems Development Method (DSDM) (1995).
 These are now collectively referred to as Agile Methodologies, after
the Agile Manifesto was published in 2001.
 Reading Assignment: Read about the above mentioned agile

methods.
Dec-22
Tools and Techniques for IS Development: Data Flow Diagrams
 The Data Flow Diagram (DFD) is an excellent communication tool for analysts to
model processes and functional requirements.
 One of the primary tools of the structured analysis efforts of the 1970's, it was
developed and enhanced by the likes of Yourdon, McMenamin, Palmer, Gane
and Sarson.
 It is still considered one of the best modeling techniques for eliciting and
representing the processing requirements of a system
DFD Mec hanic s
 DFD’s are versatile(able to change easily from one activity to another)
programming tools. With only four symbols, it can represent both physical and
logical information systems. The symbols are data flow, process, data store, and
external entity.
1. Data flow
 The directional movement of data to and from external entities, the process and
data stores. If it flows into a data store, means a write, update, delete, etc. Flows
out of data stores, mean read, query , display, select types of transaction.
 Symbol: Solid line with arrow. Each data flow is identified with a descriptive name
that represents the information on the data flow.
 eg. Registration data
Dec-22 Business Proc ess Engineering 44
2. Proc ess
 Is a work or ac tions performed on data so that they are
transformed, stored, or distributed. When modeling the data
processing of a system, it doesn’t matter whether process is
performed manually or by a c omputer.
 Depending on the level of the diagram it may represent the whole
system as in a Context (level 0) diagram or a business area, process
(activity), function, etc. in lower levels.
 Symbol:C irc le or a Rounded Rec tangle.
eg. 2.0 2.0
Update OR Update
Students
Detail Students Detail
Dec-22
3. Data Store
 Data store is a repository of information.
 In the physical model, this represents a file, table, etc.
 Symbol: Two parallel lines or open ended rectangle
 Ex.
D1: Student Master OR D1 Student Master
Dec-22
4. External Entity
 It is a sourc e/sink ( the origin and/or destination of the data).
 A person or group which interacts with the system.
 Something outside the system.
 Eg. Customer, supplier, government agency, accounting
department, etc. usually external to the business or system but may
be internal
 Data must be originated outside a system from one or more sources,
and the system must produce information to one or more sinks.
 Symbol:Rec tangular box whic h may be shaded.
 Eg.
Customer
Dec-22
Developing DFD’s
 The DFD for a food ordering system - An example
 A context diagram is a DFD that provides a general overview of a
system, other dfd’s can be used to focus the details of a context
diagram.
 This c ontext diagram c ontains only one proc ess, no data stores, four
data flows, and three external entities. The single process labeled
“0” represents the entire system.
 All context diagrams have only one process labeled “0”. No data
stores appear on a context diagram, since the data stores of the
system are conceptually inside the one process.
Dec-22
Developing DFD’s: Restaurant Food Ordering System Example
CUSTOMER KITCHEN
0
FOOD
ORDERING
SYSTEM
Management
Reports
RESTAURANT
Dec-22
 After drawing the context diagram, the next step is to analyze the
processes that are represented by the single process.
 Four main processes are identified, the processes represent the major
func tions of the system, the major func tions are:
o Capturing data from different sources (process 1)
o Maintaining data stores (process 2 and 3)
o Produc ing and distributing data to different sinks (proc ess 4)
 High level descriptions of data transformation operations (process 1)
 The flow from first proc ess-1 are:
1. the food order is transmitted to the kitc hen,
2. the customer order is transformed into a list of goods sold,
3. the customer order is transformed into inventory data, and
4. the process generates a receipt for the customer.
Dec-22 50
CUSTOMER KITCHEN
1
Receive
and
Transform 3
2
Customer Update
Update
Food Order Inventor
Goods
Sold File y File
Formatted Goods Formatted

Sold Data Inventory Data
D1: Goods Sold 4 D2: Inventory File
Produce
Managem
ent
Report
Figure :Level 1- diagram of a

Mgt Reports
Restaurant food ordering system
RESTAURANT MGR
Dec-22
 Two of the data flows generated by the proc ess, rec eive and
transform customer food order, go to external entities
 The data labeled Goods Sold go to process 2, update Goods Sold
file. The output for this process is labeled Formatted Goods Sold
Data. The output updates a data store labeled Goods Sold File.
 Daily Goods Sold amounts are then used as input to process 4,
Produce Management reports. Similarly the data flow generated by
process 1 called Inventory Data, serves as input for process 3,
Update Inventory File. The Daily Inventory Depletion amounts are
then used as input to proc ess 4.
 The DFD hides the physical characteristics of the system it describes.
 Proc ess 1 and 3 are c oupled to eac h other, sinc e the data flow
from process 1 must be readily accepted by process 3. Process 2
and 4 are dec oupled by plac ing a buffer, a data store.
Dec-22
Data Flow Diagramming Rules
 A data flow to a data store means update (delete or change)
 A data flow from a data store means retrieve or use
 A data flow has a noun phrase label.
 More than one data flow noun phrase can appear on a single arrow as
long as all of the flows on the same arrow move together as one
package.
Decomposition of DFD’s
 The act of going from a single system to more component processes is
called decomposition
 The functional decomposition is a repetitive process of breaking the
system into finer and finer detail.
 Each of the processes (or subsystem) is also candidate for decomposition.
Each process may consist of several sub processes. Each sub process may
also be broken down into smaller units.
Dec-22
 Decomposition continues until no sub process can logically be
broken down any further.
 The lowest level of DFD is c alled primitive DFD.
 The first process in Figure-2 can be decomposed into four different
outputs.
1. Rec eive a c ustomer order,
2. transform the entered order into a printed receipt for the customer,
3. transform the order into a form meaningful to the kitchens system
4. transform the order into goods sold data, and
5. transform the order into inventory data.
 We can decompose processes 2, 3, or 4 in a similar manner. In
general, a level-n diagram is a DFD that is generated from n nested
dec ompositions from a level-0 diagram.
Dec-22 54
 As a rule of thumb, no DFD 1.1
should have more than Receive
Customer
1.3 Customer Order
Transform
about seven proc esses in it. Order Order to
Kitchen
 The labels for the proc esses
Customer Order
and numbering rules for
clear communication,
proc ess names should be 1.5
c lear and c onc ise;it may 1.2
Generate
Inventory
begin with an ac tion verb, Generate Depletions
Customer
suc h as rec eive, c alc ulate, Receipt
transform, generate or 1.4
produce. Generate
Goods Sold
Increments
Figure: Decomposition of Process 1 (Level-2)
Dec-22
Tools and Techniques for ISDevelopment: Data Flow Diagrams
Balancing DFDs
 Is the conservation of inputs and outputs to a data flow diagram
process when that process is decomposed to a lower level.
 For Ex. Process 1, which appears in a level-0 diagram, must have
the same inputs and outputs when decomposed into a level-1
diagram is c alled balanc ing.
 The principle of balancing and goal of keeping a DFD as simple
as possible lead to four additional, advanced rules for drawing
DFDs.
o A composite data flow on one level can be split into
component data flows at the next level, but no new data can
be added and all data in the composite must be accounted
for in one or more sub flows.
Dec-22
Balancing DFDs
o The input to a proc ess must be suffic ient to produc e the
outputs from the process. Thus all outputs can be produced,
and all data in inputs move somewhere, either to another
process or to a data store outside the process or on a more
detailed DFD showing a decomposition of that process.
o At the lowest level of DFDs, new data flows may be added to
represent data that are transmitted under exc eptional
c onditions;these data flows typic ally represent error messages
or c onfirmation notic es.
o To avoid having data flow lines c ross eac h other, you may
repeat data store or entities on a DFD. Use an additional
symbol, like a double line on the middle vertical line of a data
store symbol, or a diagonal line in a corner of a entity square,
to indic ate a repeated symbol.
Dec-22
Additional guidelines for drawing DFDs
 Completeness: refers to whether the DFDs include all the components
necessary for the system you are modeling. If the DFD contains data
flows that do no lead anywhere, or data store, processes, or external
entities that are not connected to anything else, that DFD is not
complete.
 Consistency: It refers to whether or not the depiction of the system
shown at one level of a DFD is c ompatible with the depic tions of the
system shown at other level. A gross violation of consistency would be a
level-1 diagram with no level-0 diagram. Another example of
inconsistency would be a data flow that appears on higher level DFD
but not on lower levels.
 Timing considerations: On a given DFD, there is no indication of
whether a data flow oc c urs at what time and there is also no
indication of when a system would run. When you draw DFDs, then
draw them as if the system you are modeling has never started and will
Decn
-22ever stop. 58
Tools and Techniques for ISDevelopment: Data Flow Diagrams
Additional guidelines for drawing DFDs
 The iterative nature of drawing DFDs: Iterative development recognizes that
requirements determination and requirements structuring are interaction, not
sequential, sub phases of the analysis phase of the SDLC. One rule of thumb is
that it should take you about three revisions for each DFD.
 Drawing primitive DFDs: The lowest level DFD is the primitive DFD, one rule is to
stop drawing when the lowest logic al level is reac hed.
 It is not easy to know what the lowest level is, hence few concrete rules for
when to stop dec omposing are:
o When you have reduced each process to a single decision or calculation or
to a single database operation such as retrieve, update, create or delete.
o When each data store represents data about a single entity, such as
customer, employee, product, or order
o When every data flow does not need to be split further to show that
different data are handled in various ways
o When there is a separate process for each choice on all lowest-level menu
options.

DFDs Example2: ABC Inventory System-C ontext Diagram
Raw material inventory levels Distributer orders
Purchase orders Distributer invoice and shipments
Invoice and Finished goods

shipment inventory level
Raw Material ABC
Suppliers Inventory Distributers
Supplier System Payment
payment
Inventory levels
demand data
Inventory
Marketing
Manufacturing
Dec-22 60
DFDs Example2: ABC Inventory System
Dec-22 61
Tools and Techniques for IS Development: Flowcharts
 A flowchart is a diagrammatic representation that illustrates the
sequence of operations performed to get to the solution of a problem.
 Flowcharts facilitate communication between system analysts, system
designers and programmers.
 Flowcharts are usually drawn using some standard symbols. Basic
standard symbols used in drawing flowcharts include:
Terminator, used to show start or end of a program
Proc ess, show c omputational steps
Decision making or branching

Dec-22 Business Proc ess Engineering 62
Data input or output operation
C onnec tor, joints two parts of a program
Data flow lines
Dec -22 Business Proc ess Engineering

Guidelines to draw flow charts
 All necessary requirements should be listed out in logical order
 The flowchart should be clear, neat and easy to follow. There
should not be any room for ambiguity in understanding the
flowchart
 The usual direction of the flow of a procedure or system is from
left to right or top to bottom
 Only one flow line should come out from a process symbol
 Only one flow line should enter a decision symbol, but two or
three flow lines, one for each possible answer, should leave the
decision symbol
 Only one flow line is used in conjunction with the termination
symbol

Guidelines to draw flow c harts
 If the flowchart becomes complex, it is better to use connector
symbols to reduce the number of flow lines. Avoid the
intersection of flow lines if you want to make it more effective
and a better way of c ommunic ation.
 Ensure that the flowc hart has a logic al start and finish
 It is useful to test the validity of the flowchart by passing through it
with simple test data.

Example1
 Problem: change temperature record of centigrade value to
Fahrenheit value
 Algorithm/Solution:
o Begin
o Prompt the user for the c entigrade temperature.
o Input the value in C
o Set F to 32+(9/5)*C
o Output/print the value of C , F
o End
 Flowchart:

Example1
 Problem: change temperature record of centigrade value to
Fahrenheit value
 Flowchart: BEGIN
 Code: ?
Input the C value

Output C , F
F =32 +(9/5)*C
END

Example2
 Q: Problem: Decide whether a student fails or passes based on
his/her academic record out of 100%. Assume pass mark is >=60%.
Write the algorithm and draw the flowc hart.

Example2
 Q: Problem:Dec ide
whether a student
fails or passes based
on his/her ac ademic
record out of 100%.
Assume pass mark is
>=60%. Write the
algorithm and draw
the flowc hart.

Example3
Write the algorithmic desc ription and draw a flow
chart to find the following sum. Sum =1+2+3+…. +50 BEGIN
 Algorithmic Desc ription:

1. Initialize sum to 0 and c ounter to 1
1. If the c ounter is less than or equal to
50 Add counter to sum
Inc rease c ounter by 1
Repeat step 1.1
2. Else
END
Exit
2. Write sum
Flowchart:
Dec-22 70
Tools and Techniques for IS Development: Decision Table
 Decision table is a matrix representation of the logic of a decision.
 It specifies the possible conditions and the resulting actions.
 It is best used for complicated decision logic.
 It consists of the following parts:
o Condition stubs: Lists conditions relevant to decision
o Action stubs: Actions that result from a given set of conditions
o Rules: Specify which actions are to be followed for a given set of conditions
 The standard procedure for creating decision tables involves:
a) Name the condition and each values each condition can assume
b) Name all possible actions that can occur
c) List all the rules
d) Define the actions for each rule
e) Simplify the table
Dec-22
 Example 1: Simple Payroll system
Condition/Courses of Rules
Action
1 2 3 4 5 6
Condition Employee Type S H S H S H
Stub
Hours Worked <40 <40 40 40 >40 >40
Pay Basic Salary X X X
Action
Calculate Hourly Wage X X X
Stub
Calculate Overtime X
Produce Absence Report X
Dec-22
 Example 2: Students’ system
Rules
Conditions/
Condition Course of 1 2 3 4 5 6 7 8 9 10 11 12
Stubs Actions
Student type F NF F NF F NF F NF F NF F NF
Previous status GS GS W W GS GS W W GS GS W W
CGPA <1.75 <1.75 <1.75 <1.75 1.75- 1.75- 1.75- 1.75- 2.00 2.00 2.00 2.00
1.99 1.99 1.99 1.99
Good Standing
X X X X
Action
Stubs
A/Probation
X X X X
A/Dismissal
X X X X
F = Freshman NF= Non freshman W = Warning GS = Good standing

Dec-22
Tools and Techniques for IS Development: Decision Tree
 A decision tree is a graphical representation of a decision situation.
 Decision situation points are connected together by arcs and terminate in ovals.
 The two main components are:
o Decision points represented by nodes
o Action represented by ovals
 The decision tree defines the conditions as a sequence of left to right tests.
 A decision tree helps to show the paths that are possible in a design following an
action or decision by the user.
 IT turns a decision table into a diagram.
 This tool is read from left to right, decision results in a fork, and all branches end
with an outcome.
 Each node corresponds to a numbered choice on the legend.
 All possible actions are listed on the far right.
Dec-22
Tools and Techniques for IS Development: Decision Tree
 Example:
Legend Pay Hourly

1) Salaried? Wage
2) Hours worked <40?
3) Hours worked =40?

Tools and Techniques for IS Development: Structured English
 Structured English is a modified form of English used to specify the logic of
information processes, it uses a subset of English:
 Action verbs
 Noun phrases
 No adjective or adverbs
 If conditions
 Case statements
 There are no specific standards and is similar to programming languages
Dec-22
Tools and Techniques for IS Development: Structured English
Example: Approve Loan
BEGIN
IF c ustomer has a Bank Ac c ount THEN
IF Customer has no dues from previous account THEN
Allow loan fac ility
ELSE
IF Management Approval is obtained THEN
Allow loan fac ility
ELSE
Reject
ENDIF
ENDIF
ELSE
Rejec t
ENDIF
END
Dec-22
Tools and Techniques for IS Development: Gantt Chart
 A Gantt chart is a simple horizontal bar chart that depicts project tasks against
a calendar.
 Each bar represents a named project task.
 The tasks are listed vertically in the left hand column.
 The horizontal axis is a calendar timeline.
 The Gantt chart was first conceived by Henry L. Gantt in 1917, and is the most
commonly used project scheduling and progress evaluation tool.
 Gantt charts give a clear, pictorial model of the project.
 They show progress and can be used for resource planning.
 They also show interrelationships and critical path.
Dec-22
Gantt Chart Methodology
 List vertically all tasks to be performed
 Tasks identified by number and name
 Horizontally indicate duration, resources and any other relevant information
 Graphical part shows horizontal bar for each task connecting start and end
duration
 Relationships can be shown by lines joining tasks – can make diagram
Dec-22
Gantt Chart Example
Dec-22 80

Business Process ReEngineering

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Process ReEngineering

Uploaded by

Copyright:

Available Formats

AAU School of

Dec-22 Business Process Engineering 2

Dec-22 Business Process Engineering 4

Dec-22 Business Process Engineering 5

Dec-22 Business Process Engineering 6

Dec-22 Business Process Engineering 7

Dec-22 Business Process Engineering 8

Dec-22 Business Process Engineering 9

Verification and Validation

Verification and Validation

Dec -22 Business Proc ess Engineering 21

Dec -22 Business Proc ess Engineering 23

Dec -22 Business Proc ess Engineering 24

Dec -22 Business Proc ess Engineering 25

Dec -22 Business Proc ess Engineering 26

Dec -22 Business Proc ess Engineering 27

Dec -22 Business Proc ess Engineering 28

Dec -22 Business Proc ess Engineering 29

Dec -22 Business Proc ess Engineering 31

Dec -22 Business Proc ess Engineering 32

 Sc ribe:To take notes during the

Dec-22 Business Process Engineering 35

Business Proc ess Engineering

 Reading Assignment: Read about the above mentioned agile

D1: Student Master OR D1 Student Master

Formatted Goods Formatted

Figure :Level 1- diagram of a

Dec -22 Business Proc ess Engineering 59

Raw material inventory levels Distributer orders

Purchase orders Distributer invoice and shipments

Invoice and Finished goods

Terminator, used to show start or end of a program

Proc ess, show c omputational steps

Decision making or branching

Data input or output operation

C onnec tor, joints two parts of a program

Data flow lines

Dec -22 Business Proc ess Engineering

Dec -22 Business Proc ess Engineering

Dec -22 Business Proc ess Engineering

Dec -22 Business Proc ess Engineering

Input the C value

Dec -22 Business Proc ess Engineering 67

Dec -22 Business Proc ess Engineering 68

Dec -22 Business Proc ess Engineering 69

 Algorithmic Desc ription:

F = Freshman NF= Non freshman W = Warning GS = Good standing

Legend Pay Hourly

Dec-22 Business Process Engineering 75

You might also like