phase ii :system analysis prepared by ejlal al-khuzaie

Prepared by Ejlal Al-khuzaie

Phase II :System Analysis


Phase Outline Introduction Requirements Collection

Interviews Questionnaires

Requirements Analysis Data Flow Diagram (DFD) Process Specification Entity Relationship Diagram (ERD) Data Dictionary


Introduction What is your purpose of this phase ?! What is going to be earn from doing this

document ?!


Requirements Collection InterviewIn this section you will insert all result you got

for inter Interview outline Interviewer Who are interviewed

Location Appointment date

Objective : Reminders

Agenda Approximate time

What do you notice through?!

Interviewee : Date

Question Note and answers

Q1.

Q2.


Requirements Collection ( cont … ) Interview Questions

Nature of his her job , job experience Current System Suggestions to improve the system


Requirement Collection Preparing the questions

List all the items about which information is required Decide who will be able to give you this information Decide on the question type:

Multiple choice Yes/No Open questions etc….

Write questions on separate pieces of paper When all questions are worded, sort them in order


Requirement collection Assess the questionnaire

Give it to three to five people and check how they answer the questions

Ask the respondents for feedback on the questionnaire: How difficult was it? Were there any questions they were unsure about?

Make adjustments based on the comments you received

Distributing and gathering Decide how the questionnaire would be distributed Start recording data as soon as the questionnaires are

received


System Requirement Functional Requirement

Statements of services the system should provide. How the system should react to a particular input. How the system should behave in a particular

situation. Generally, functional requirements are expressed

in the form "system shall do <requirement>“Title F1

Description:

Activities:

Date:

Source of requirement

Priority


System Requirement Non-Functional Requirement

Statements of system constraints. Define system properties such as reusability,

portability, efficiency, integrity, flexibility, usability … etc.

non-functional requirements are "system shall be <requirement>"

Explanation Non-functional requirement type


System Requirement

Functional Requirement : Non-Functional Requirement :


DFDs You may use either of these two conventions,

just don’t mix them


DFDs Entities:

can be people, departments, other companies, other systems…

are called sources if they are external to the system and provide data to the system, and sinks if they are external to the system and receive information from the system

Processes must have at least one input and at least one output at the primitive level are labeled with verb + object

(e.g. “print invoice” or “add customer”) (e.g. in the hierarchy below, none of the processes are primitive)

at the non-primitive level, are labeled more generally (e.g. “customer maintenance” or “warehouse reports”)


DFDs Data stores:

can be online or “hard copy” (see notes on logical VS physical DFD’s below)

are labeled with a noun (e.g. the label “customer” indicates that information about customers is kept in that data store)

data is stored whenever there are more than one process that needs it and these processes don’t always run one after the other (if the data is ever needed in the future it must be stored)


DFDs Data flows:

must originate from and/or lead to a process (this means that entities and data stores cannot communicate with anything except processes –remember that it takes a process to make the data flow)

can go from process to process, but that does imply that no data is stored at that point

can have one arrowhead indicating the direction in which the data is flowing

can have 2 arrowheads when a process is altering (updating) existing records in a data store


DFDs General rules

Each process must have a minimum of one data flow going into it and one data flow leaving it.

Each data store must have at least one data flow going into it and one data flow leaving it.

Data in data stores must be used (data shown flowing out) otherwise there is no reason to store it. Data must also be updated (new data shown flowing in) otherwise it will be obsolete and will not have been updated by the system.

A data flow out of a process should have some relevance to one or more of the data flows into a process.


DFDs Data stored in a system must go through a

process. Data cannot be filed directly from an external entity (terminator) or retrieved directly by an external entity. This would be classified as a breach of security! A person or business outside another business should not have direct access to another business's filing system.

Similarly, filing systems within an organization cannot logically communicate with one another unless there is a process involved. One data store cannot have a direct link to another data store.

All processes in DFDs must be linked to either another process or a data store. A process cannot exist by itself, unconnected to the rest of the system.


DFDs Context level

Represents a system at a high level. Shows the overall business process as just one process Shows all the outside entities that receive information

from or contribute information to the system Level 0

Shows all the processes that comprise the overall system

Shows how information moves from and to each process Adds data stores


DFDs Level 1

It represents the process in more detail Each level 1 diagram relates to a single process on the

corresponding level 0 diagram. Level 1 diagrams may not be needed for all level 0

processes


Example A customer order a meal , the system check

meal ingredient , the order will reach the kitchen to be prepared . The customer will receives a receipt of his order.


Context level


Level 0


Process Specification Structure English Define process

Process ID Process Name Process Description Input : Logic :

CHECK IF THEN Check

IF Then Change

Else IF Remark


Process Specification Decision Table

Concept

Layout

Condition stub Condition entry

Action stub Action Entry

8 7 6 5 4 3 2 1 Conditions

C1

c2

c3

o1

o2

o3

impossible


Process Specification Entity Relationship Diagram ( ERD )

Entity Relationship Diagrams ( ERDs ) illustrate the logical structure of database.


Data Dictionary Defining Dataflow

ID: Name : Description Source : Destination: Type: Type of data flow , either a record entering

or leaving a file containing report form , or screen , internal-used between processes

The volume per unit time Commment


Data Dictionary Defining Data Structures

The symbols used are: Equal sign , meaning “ consists of” Plus sign , meaning “ and” Braces {} meaning repetitive elements , a repeating

element or group of elements Brackets [] for an either/or situation Parentheses () for an optional element


Data Dictionary Example

Customer order = customer number + customer name + address + Telephone + order date + { order Items } + order Total + method of payment + (credit card type ) + credit Card Number ) + (Expiration Date )


Data Dictionary Defining Elements

– Name Customer Number– Alias Client Number– Description Uniquely identifies a customer that

has made any business transaction within the last five years.

– Length 6– Input Format X(6)– Output Format X(6)– Default Value– Continuous/Discrete Continuous– Type Sting – Base or Derived Derived– Upper Limit <999999– Lower Limit >18– Comments The customer number must pass a

modulus-11 check-digit test.


Data Dictionary Base or Derived

A base element is one that has been initially keyed into the system

A derived element is one that is created by a process , usually as the result of a calculation or some logic.


Define Data Store ID D1 Name Member File Alias Description Contains a record for each

member File Type Computer File Format Database Record Size 200 Maximum Records 45,000 Average Records 42,000 % Growth/Year 6%


Data Set/Table Name Customer Data Structure Customer Record Primary Key Customer Number Secondary Keys Customer Name, Telephone, Zip Code Comments The Customer Master File

records are copied to a history file and purged if the customer has not purchased an item

within the past five years. A customer may be retained even if he or she has not made a purchase by requesting a catalog.


• The Data Store ID• The Data Store Name, descriptive and unique• An Alias for the file• A short description of the data store• The file type, either manual or computerized• If the file is computerized, the file format designates

whether the file is a database file or the format of a traditional flat file

• The maximum and average number of records on the file• The growth per year• This helps the analyst to predict the amount of disk space

required.• The data set name specifies the table or file name, if known.• The data structure should use a name found in the data

dictionary

phase ii :system analysis prepared by ejlal al-khuzaie

Documents