Chapter 3 System Analysis Phase.pptxfjgf

CHAPTER THREE
IS DEVELOPMENT – ANALYSIS PHASE
 Contents:
 System Requirement Determination
 Requirement Elicitation techniques
 Requirement Analysis Strategy
 System Requirement Structuring/Modeling
 Process modeling
 Logic Modeling
 Data modeling
1

2
 Understanding and specifying in detail what an information system should do.
 The analysis phase answers the questions of who will use the system, what the system
will do, and where and when it will be used.
 During this phase, the project team investigates any current system(s), identifies
improvement opportunities, and develops a concept for the new system.
 This phase has three steps:
1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy
usually includes a study of the current system (called the as-is system) and its
problems, and envisioning ways to design a new system (called the to-be system).
INTRODUCTION

3
2. Requirements gathering (e.g., through interviews, group workshops or questionnaires).
 The analysis of this information—in conjunction with input from the project sponsor and
many other people—leads to the development of a concept for a new system.
 The set typically includes models that represent the data and processes necessary to support
the underlying business process.
3. The analyses, system concept, and models are combined into a document called the system
proposal, which is presented to the project sponsor and other key decision makers (e.g.,
members of the approval committee) who will decide whether the project should continue to
move forward.
 The system proposal is the initial deliverable that describes what business requirements the
new system should meet.
Introduction….

4
Requirements determination is performed to transform the system request’s high
level statement of business requirements into a more detailed, precise list of
what the new system must do to provide the needed value to the business.
This detailed list of requirements is supported, confirmed, and clarified by the
other activities of the analysis phase: creating use cases, building process models,
and building a data model.
The requirements is a text report that simply lists the functional and non-functional
requirements in an outline format.
Requirements Determination

5
 What is a Requirement?
A requirement is simply a statement of what the system must do or what
characteristics it needs to have.
During system study, we identify different requirements
1. Business requirements - what the business needs
2. User requirements – what users need to do
3. Functional requirements -what the software should do
4. Non-functional requirements - characteristics the system should have
5. System requirements - how the system should be built
Requirements Determination…

6
 Sample functional requirements definition for Holiday Travel Vehicles
 Discussion: what is functional and non-functional requirement? Assume one system and give examples.

7
Sample none-functional requirements definition for Holiday Travel Vehicles

8
Requirement elicitation Techniques
In this section, we focus on the five most commonly used requirements elicitation
techniques: interviews, JAD sessions, questionnaires, document analysis, and
observation.
1. Interviews
The interview is the most commonly used requirements elicitation technique.
Interviews are conducted one on one (one interviewer and one interviewee), but sometimes,
due to time constraints, several people are interviewed at the same time.
There are five basic steps to the interview process: selecting interviewees, designing
interview questions, preparing for the interview, conducting the interview, and post
interview follow-up.

9
Requirement elicitation Techniques…
1. Interviews
 Select interviewees
 The first thing to determine for an interview is the fact and opinion you need to
collect from the interview.
 In short, what is the objective of the interview? Then, you should select those
individuals who would provide you with the facts or opinions you like to collect.
 Taking a look at the organizational chart can give you a clue about who you need
to interview.
 Try to learn as much as possible about the individuals you are going to interview.

10
1. Interviews
 Prepare interview questions
 In this section we considered the two types of interview questions:
 Closed-ended questions and open-ended questions.
 Closed ended questions require a specific answer.
 Closed-ended questions are used when the analyst is looking for specific, precise
information (e.g., how many credit card requests are received per day).
 Open-ended questions are designed to gather rich information and give the
interviewee more control over the information that is revealed during the interview.

11
1. Interviews
 Prepare interview questions example

12
1. Interviews
 Preparing for the Interview
 It is important to prepare for the interview in the same way that you would prepare
to give a presentation.
 You should have a general interview plan which lists the questions that you will ask
in the appropriate order; anticipates possible answers and provides how you will
follow up with them; and identifies segues between related topics.
 Confirm the areas in which the interviewee has knowledge so you do not ask
questions that he or she cannot answer.
 Review the topic areas, the questions, and the interview plan, and clearly decide
which ones have the greatest priority in case you run out of time.

13
1. Interviews
 Conducting the Interview
When you start the interview, the first goal is to build rapport with the interviewee
so that he or she trusts you and is willing to tell you the whole truth, not just give
the answers that he or she thinks you want.
You should appear to be professional and an unbiased, independent seeker of
information.
The interview should start with an explanation of why you are there and why you
have chosen to interview the person, and then move into your planned interview
questions.

14
1. Interviews
 Post-interview Follow-up
After the interview is over, the analyst needs to prepare an interview report that
describes the information from the interview.
The report contains interview notes, information that was collected over the course
of the interview and is summarized in a useful format.
In general, the interview report should be written within 48 hours of the interview,
because the longer you wait, the more likely you are to forget information.

15
2. Joint Application Development (JAD)
Joint application development is an information gathering technique that allows the project
team, users, and management to work together to identify requirements for the system.
IBM developed the JAD technique in the late 1970s, and it is often the most useful method
for collecting information from users.
JAD is a structured process in which 10 to 20 users meet under the direction of a facilitator
skilled in JAD techniques.
The facilitator is a person who sets the meeting agenda and guides the discussion, but does
not join in the discussion as a participant.

16
3. Questionnaire
Questionnaire is a set of written questions for obtaining information from individuals.
Questionnaires often are used when there is a large number of people from whom
information and opinions are needed.
In our experience, questionnaires are commonly used for systems intended for use
outside of the organization (e.g., by customers or vendors) or for systems with business
users spread across many geographic locations.
Most people automatically think of paper when they think of questionnaires, but today
more questionnaires are being distributed in electronic form, either via e-mail or on the
Web.

17
 Project teams often use document analysis to understand the as-is system.
 Under ideal circumstances, the project team that developed the existing system will have
produced documentation, which was then updated by all subsequent projects.
 In this case, the project team can start by reviewing the documentation and examining the
system itself.
 Systems analysts are expected to examine various documents in an organization to
determine system requirements (that is data, process and interface requirements) and
general information that is essential about the organization.
4. Documents Analysis

18
 The following are some of the documents that an analyst can obtain and examine
 Organizational chart
 Documents that describe how the project was initiated
 Interoffice memos, studies, minutes, customer complaints, etc.
 Scheduled operating reports such as performance reviews
 Information system project requests, preliminary study reports, etc.
 The company’s mission statement and strategic plan
 Policy manuals that may place constraints on any proposed system
 Standard job descriptions, work procedure manuals for specific day-to-day operations
 Completed forms that represent actual transactions at various points in the processing cycle
 Samples of manual and computerized databases or records
 System documentation of previous system studies or the current system
Documents Analysis

19
5. Observation
Observation, the act of watching processes being performed, is a powerful tool to
gain insight into the as-is system.
Observation enables the analyst to see the reality of a situation, rather than listening
to others describe it in interviews or JAD sessions.
Observation is often used to supplement interview information.
The location of a person’s office and its furnishings gives clues as to their power
and influence in the organization, and such clues can be used to support or refute
information given in an interview.

20
Requirement Analysis Strategy
Analysts often have to help the business users think critically about their new system
requirements.
Using those strategies, analyst can employ with the stakeholders to accomplish this goal.
1) Problem Analysis
The most straightforward (and probably the most commonly used) requirements analysis
strategy is problem analysis.
Problem analysis means asking the users and managers to identify problems with the
as-is system and to describe how to solve them in the to-be system.
Most users have a very good idea of the changes they would like to see, and most will be
quite vocal about suggesting them.

21
2) Root Cause Analysis
The ideas produced by problem analysis tend to be solutions to problems.
Root cause analysis focuses on problems first rather than solutions.
The analyst starts by having the users generate a list of problems with the
current system, then prioritizes the problems in order of importance.
Starting with the most important, the users and/or analysts generate all possible
root causes for the problem.
Requirement Analysis Strategy…

22
3) Duration Analysis
 Duration analysis requires a detailed examination of the amount of time it takes to
perform each process in the current as-is system.
 The analysts begin by determining the total amount of time it takes, on average, to
perform a set of business processes for a typical input.
 The time to complete the basic steps are then total and compared with the total for the
overall process.
 For example, suppose that the analysts are working on a home mortgage system and discover that, on
average, it takes 30 days for the bank to approve a mortgage. They then look at each of the basic steps
in the process (e.g., data entry, credit check, title search, appraisal, etc.) and find that the total amount
of time actually spent on each mortgage is about 8 hours. This is a strong indication that the overall
process is badly broken, because it takes 30 days to perform 1 day’s work.

23
4) Informal Benchmarking
 Benchmarking refers to studying how other organizations perform a business process in order to learn
how your organization can do something better.
 Benchmarking helps the organization by introducing ideas that employees may never have considered,
but that have the potential to add value.
 Informal benchmarking is fairly common for “customer-facing” business processes (i.e., those processes
that interact with the customer).
 With informal benchmarking, the managers and analysts think about other organizations, or visit them as
customers to watch how the business process is performed.
 For example, suppose that the team is developing a Web site for a car dealer. project sponsor, key managers, and key team members
would likely visit the Web sites of competitors, those of others in the car industry (e.g., manufacturers, accessories suppliers), and
those of other industries that have won awards for their Web sites.

24
5) Outcome Analysis
 Outcome analysis focuses on understanding the fundamental outcomes that provide
value to customers.
 With this approach, the system analysts encourage the managers and project sponsor to
pretend that they are customers and to think carefully about what the organization’s
products and services enable the customers to do—and what they could enable the
customer to do.

25
6) Technology Analysis
Many major changes in business over the past decade have been enabled by new
technologies.
Technology analysis therefore starts by having the analysts and managers develop a
list of important and interesting technologies.
Then the group systematically identifies how each and every technology could be
applied to the business process and identifies how the business would benefit.

26
Requirements structuring
Requirement structuring in the system analysis phase is a crucial activity that
involves organizing and categorizing system requirements in a clear, systematic,
and manageable way.
It aims to create a well-structured and organized set of requirements that can serve
as the foundation for designing and developing a software system or information
system.
Requirement structuring helps ensure that all essential requirements are captured,
documented, and understood by stakeholders and the development team.

27
 Modelling
A model is an abstraction, a representation of part of the real world.
 Model is an idealization or abstraction of the actual process (IS).
A model represents something that exists or is planned in the real world and that in
someway is too complex or large for us to understand it as it stands
Traditionally, there are three basic methods for requirements structuring:
1. Data flow diagrams - used for process modelling
2. Structure English and decision trees - are used for logic modelling
3. Entity and relationship diagram - used for data modelling
Requirements structuring…

28
1. Process Modeling
 Process model describes business processes—the activities that people do.
 It is a graphical way of representing how a business system should operate.
 It illustrates the processes/activities that are performed and how data move among them.
 A process model can be used to document the current system (i.e., as-is system) or the
new system being developed (i.e., to-be system).
 There are many different process modelling techniques in use today. In this section, we
focus on one of the most commonly used techniques: data flow diagramming(DFD).
 Data flow diagramming is a technique that diagrams the business processes and the data
that pass among them.

29
 Data Flow Diagram (DFD)
 Process modeling involves graphically representing the functions, or processes which
capture, manipulate, store and distribute data between a system and its environment
and between components within a system.
 Data flow diagrams are used to graphically represent the flow of data in a business
information system.
 DFD describes the processes that are involved in a system to transfer data from the input
to the file storage and reports generation.
 Data flow diagrams help analysts conceptualize how data move through the
organization, the processes or transformation that the data undergo and what the
outputs are.
Process Modelling

30
Element of Data flow diagramming
There are four symbols in the DFD language (processes, data flows, data stores,
and external entities), each of which is represented by a different graphic symbol.
There are two commonly used styles of symbols, one set developed by Chris Gane
and Trish Sarson and the other by Tom DeMarco and Ed Yourdon.
Data Flow Diagram (DFD)

32
1. Process
A process is an activity or a function that is performed for some specific business
reason. Processes can be manual or computerized.
All information systems include processes.
These processes respond to business events and conditions and transform data
into useful information.
In process modeling the whole system is viewed as a process.
Every process must have at least one input data flow and at least one output data
flow.
Data Flow Diagram (DFD)…

33
2. Data flows
Data flow is a single piece of data (e.g., quantity available) (sometimes called a
data element), or a logical collection of several pieces of information (e.g., new
chemical request).
Data flows are the communications between processes and the system’s
environment. A data flow represents: (a) an input of data to a process, (b) the
output of data from a process, or (c) the creation, deletion, reading, or updating of
data in a file or database.
Data flows show what inputs go into each process and what outputs each process
produces.

34
3. Data store
 A data store is a collection of data that is stored in some way (which is determined
later when creating the physical model).
 Every data store is named with a noun and is assigned an identification number and a
description.
 Most information systems capture data for later use.
 The data is kept in a data store. Ideally, essential data stores describe the “things”
about which the business wants to store data.
 Data flows coming out of a data store indicate that information is retrieved from the
data store.

35
4. External Entity
 An external entity is a person, organization, organization unit, or system that is external to
the system, but interacts with it (e.g., customer, clearinghouse, government organization,
accounting system).
 The external entity typically corresponds to the primary actor identified in the use case.
 External entities provide data to the system or receive data from the system, and serve to
establish the system boundaries
 People who use the information from the system to perform other processes or who
decide what information goes into the system are documented as external entities (e.g.,
managers, staff ).

36
 How to construct process models?
A. Context DFDs
 The first step in constructing a process model for a system is to construct its context
(data flow) diagram.
 The context diagram defines the scope and boundary for the system, but it does not
include data store
B) Level-0 Diagram
 A data flow diagram that represents a system’s major processes, data flows and data
stores at a high level of detail.
C) Level-N Diagrams: This refers to a DFD that is the result of n nested decompositions of
a series of sub-processes from a process on a level-0 diagram.

37
Example, Relationships among Levels of Data Flow Diagrams (DFDs)

38
2. Logic Modeling
 Data flow diagrams do not show the logic inside the processes.
 Logic modeling involves representing internal structure and functionality of processes
depicted on a DFD. Logic modeling can also be used to show when processes on a
DFD occur.
 The following standardized tools (techniques) can be used for such purpose:
 Decision tree
 Structured English
 Sequence Diagram
 Activity diagram
 Decision Tables

39
 Modeling Logic with Decision Trees
 In tree structure we can have main roots and sub roots.

40
 Modeling Logic with Structured English
 Modified form of English language is used to specify the logic of information system
processes.

41
1. Define requirements and discuss on the different requirements that should be identified
during system analysis phase
2. Discuss and explain the requirement elicitation techniques
3. Discuss and explain the different requirement analysis strategy
4. Discuss about Requirement structuring:
• Conceptual level-process modelling techniques (DFD and use case diagram)
• Logical level modelling techniques (Decision tree, structure English, activity
diagram, sequence diagram)
Discussion Questions- Chapter Three Summary

42
3. Data Modeling
 Data model describes the data that flow through the business processes in an
organization.
 During the analysis phase, the data model presents the logical organization of data
without indicating how the data are stored, created, or manipulated so that analysts can
focus on the business without being distracted by technical details.
 Later, during the design phase, the data model is changed to reflect exactly how the data
will be stored in databases and files.
 Process and logic modeling does not show the definition, structure and
relationships within the data but how, where, and when data are used or changed.

43
Data Modeling…
 Although there are several ways to model data, the most commonly used techniques
entity relationship diagramming (ERD).
 Entity-Relationship Diagram (ERD)
 Entity-Relationship diagram is commonly used to show how data are organized
 It is a picture which shows the information that is created, stored, and used by a
business system.
 An analyst can read an ERD to discover the individual pieces of information in a
system and how they are organized and related to each other.

44
Data Modeling…
 Elements of an Entity Relationship Diagram
 There are three basic elements in the data modelling language (entities, attributes, and
relationships), each of which is represented by a different graphic symbol.
 There are many different sets of symbols that can be used on an ERD. No one set of
symbols dominates industry use, and none is necessarily better than another.
1. Entity
The entity is the basic building block for a data model. It is a person, place, event, or
thing about which data is collected—for example, an employee, an order, or a product.
An entity is depicted by a rectangle, and it is described by a singular noun spelled in
capital letters. Entity Name Employee

45
Data Modeling…
 Elements of an ERD…
2. Attribute
 An attribute is some type of information that is captured about an entity. For example, last
name, home address, and e-mail address are all attributes of a customer.
 It is easy to come up with hundreds of attributes for an entity (e.g., a customer has an eye
colour, a favourite hobby, a religious affiliation), but only those that actually will be used by a
business process should be included in the model.
 Attribute is a named property or characteristic of an entity that is of interest to an
organization.
 For example, some attributes of a customer are: name, number, address, and sales territory.
Attribute

46
Data Modeling…
 Elements of an ERD…
3. Relationship
 Relationships are associations between entities, and they are shown by lines that connect the entities
together. Every relationship has a parent entity and a child entity, the parent being the first entity in the
relationship, and the child being the second
 Relationships should be clearly labelled with active verbs so that the connections between entities can
be understood.
 Different types of relationships can exist between the entity types.
 The term cardinality describes the number of times that each type occurs in the relationship (an entity
type can have many instances of that entity type represented by data stored in the database).
 There are three basic cardinalities.
 One-to-one
 One-to-many
 Many-to-many

49
Data Modeling…
 Example

Chapter 3 System Analysis Phase.pptxfjgf

Recommended

Recommended

More Related Content

Similar to Chapter 3 System Analysis Phase.pptxfjgf

Similar to Chapter 3 System Analysis Phase.pptxfjgf (20)

Recently uploaded

Recently uploaded (20)

Chapter 3 System Analysis Phase.pptxfjgf