Phase 2 : System Analysis
Download
1 / 96

Phase 2 : System Analysis Determining Requirements - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

Phase 2 : System Analysis Determining Requirements

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Phase 2 : System Analysis Determining Requirements' - cliff


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Phase 2 : System Analysis

Determining Requirements

In the preliminary investigation phase, your job is to determine if a problem does in fact exist. In the system analysis phase, your objective is to learn exactly what take place in the current system, to determine and fully document what should take place, and to develop and make recommendations to management.

System analysis overview

During the system analysis phase, the emphasis of your investigation is on what is taking place. You must obtain answers to many questions about the current system.


For example, you must determine what procedures and documents are used and what people are involved in each operation. Also, you need to know what transactions are processed and what information is generated and used within the system. At the same time, you must determine what is desired by the end users.

You must learn such things as the strengths of the current system, procedures that should be eliminated, and improvements that are needed. You must determine why system activities are being performed as they are and where improvements and changes should be made.


Management uses the following simple three-step documents are used and what people are involved in each operation. Also, you need to know what transactions are processed and what information is generated and used within the system. At the same time, you must determine what is desired by the end users.

approach to decision making that is equally applicable to the

task of system analysis.

1. Get the facts.

2. Analyze the facts.

3. Make a decision.

Requirements Determination

(Get the Facts)

Requirements Analysis

(Analyze the Facts)

System Requirements Document

(Make a Decision)


System analysis characteristics documents are used and what people are involved in each operation. Also, you need to know what transactions are processed and what information is generated and used within the system. At the same time, you must determine what is desired by the end users.

The system analysis phase is a complex undertaking because information system are large, difficult to define, and subject to change. Additionally, a system problem might be ill-defined initially because of uncertainty about its true nature and scope.

During system analysis, you must interact with end users at various organizational levels. In addition, you must be able to understand and integrate the system needs of all the end users, who can have different, and occasionally conflicting, objectives.


The system analysis phase requires you to obtain complete answers to the questions who, what, when, where, and how. With each of these five questions, you also must ask why, as you seek answers for questions, such as:

1. Who? Who performs each of the procedures within the system? Why? Is the correct person performing the activity? Could the job duties be assigned to someone else?

2. When? When is a procedure performed? Why? Why is it being performed at this time? Is this the best time?


Requirement Determination Requirement Analysis answers to the questions

What is done? Why is it done? What should be done?

Where is it done? Why is it done there? Where should it be done?

When is it done? Why is it done at this time? When should it be done?

Who does it? Why does this person do it? Who should do it?

How is it done? Why is it done this way? How should it be done?

Why is it done Why should it be Should it be

(or not be) done? changed(or eliminated)


  • System requirement answers to the questions

  • Typical system requirements

  • A system requirement is a feature that must be included in an information system in order for the system to be acceptable to the end users. Determining all the system requirements is essential, because these documented requirements form the basis for further development of the new system. The documented requirements also later serve as a standard against which the finished system is compared to determine its acceptability.


  • We classify system requirements into five categories: outputs, inputs, processes, timings, and controls.

  • Outputs

    • On a weekly basis, the system must produce a report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all parts, sorted by part number.

  • Inputs

    • The information on approved Customer Account Applications, including date, account number, name, address, telephone, standard industrial classification code, and credit limit, is used to add a new customer to the system


  • Processes outputs, inputs, processes, timings, and controls.

    • Student records must be accessible by either the student name or the student number.

    • As the final step in the year-end processing cycle, the system deletes terminated employee records.

  • Timings

    • Monthly statements are prepared no later than the end of the third business day of each month.

    • Class lists are produced within five hours after the end of final registration.

  • Controls

    • An employee record may be added, changed, or terminated only by a member of the personnel department.


  • Volumes, sizes, and frequencies outputs, inputs, processes, timings, and controls.

  • As you determine the system requirements, you also must gather quantitative information about both current and future volumes, sizes, and frequencies for all the outputs, inputs, and processes.

  • Codes

  • A code is a sequence of letters or numbers that represents an item of data that is more lengthy, cumbersome, or ambiguous. You encounter codes constantly in your everyday life.


Interviews - an important fact-finding technique outputs, inputs, processes, timings, and controls.

By now you realize that system analysts spend a great deal of time talking with people both inside and outside the information system department. Much of this time is spent in interviewing people to collect information, so it is critical that you have the skills to properly plan, conduct, and document interviews. An interview is a planned meeting during which you obtain information from another person. The process of interviewing consists of these six steps.

1. Determine who to interview.

2. Establish objectives for the interview.

3. Prepare for the interview.

4. Conduct the interview.


  • 5. Document the interview. outputs, inputs, processes, timings, and controls.

  • 6. Evaluate the interview.

  • Determine who to interview

  • Even if you eventually ask all the right questions, if you do not ask the right questions of the right people, you will never get an accurate picture of the system under study. Also, you want neither to waste your time asking unproductive questions nor to waste the time of the people you interview. Thus, you must first carefully determine who should be interviewed.


  • Establish objectives for the interview outputs, inputs, processes, timings, and controls.

  • Once you decide who to interview, you must establish objectives for each interview. You must determine the general areas to be discussed and the specific facts you require for each of those general areas. In addition, you must plan to solicit ideas, suggestions, and opinions from those you interview.

  • The objectives of an interview depend on the role of the person being interviewed. Different information is obtained from a vice president of the company than from a clerk. From upper-level management, you learn about the big picture, the system as a whole. Specific details about processes are best learned from the people who actually perform the processes.


  • Prepare for the interview outputs, inputs, processes, timings, and controls.

  • Once you determine the objectives for an interview, you must prepare for the interview. Careful preparation is essential because the probability of gaining the required information by merely sitting down to chat is quite small.

  • You should schedule a meeting with the person to be interviewed for a given day at a given time. It is also best to call ahead about an hour before the meeting to be sure that the interviewee will be available. Remember that your interview is an interruption of the interviewee’s routine responsibilities. Other business might arise for the interviewee to cause a postponement of the meeting. If this occurs, you should schedule another appointment.


Keep department managers informed of your meeting with their staff members. Sending a memo to each department manager listing your planned appointments one excellent way to keep them informed.

Your objectives also influence the way you ask your questions. Two types of questions are open-ended questions and closed-ended questions. Open-ended questions are questions that are designed to permit spontaneous and unguided responses. Open-ended questions are most useful when you are trying to understand a larger process or when you want to draw out the interviewee’s opinions, attitudes, or suggestions. Example of open-ended question is How are the checks reconciled?


Closed-ended questions are questions that limit or restrict the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

When you have completed a list of questions and topics you want to discuss, send this list to the interviewee several days before the meeting. This allows time for the interviewee to prepare for the interview. Furthermore, you often can avoid the need for a follow-up interview because the interviewee will be prepared at the first meeting.


  • Conduct the interview the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • After you determine who to interview, establish your objectives, and plan for the interview, you are ready to conduct the interview. The model for a typical interview is to introduce yourself; summarize the project objectives and progress; summarize your interview objectives; ask your questions, generally going from open-ended to closed-ended questions; summarize the main point covered in the interview; specify what is to be done next by you and the interviewee and thank the interviewee.

  • Establishing a rapport between you and the interviewee is important, especially in a first interview. If the interviewee feels comfortable and at ease with you, you are more likely to


  • receive more complete and candid answers to your questions. the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • Your primary responsibility during an interview is to listen to the answers. All too often, system analysts do not listen properly to the answers given and, instead, hear only what they expect to hear. You must carefully and actively listen to the actual words being said and must be aware of the non-verbal communication taking place.

  • Document the interview

  • After you conduct the interview, you must take definite steps to ensure that you don’t forget the information from the interview. One step involves setting aside time immediately after the interview to record what transpired during the meeting.


  • Evaluate the interview the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • In addition to recording the facts obtained in an interview, you should analyze the interview and the person interviewed. Many facts that were stated in the interview might have been biased by one or more circumstances. For example, the interviewee might be attempting to protect an empire and could believe that any knowledge he or she reveals will destroy that empire. Such a person might not actually lie when asked questions, but yet might not give complete answers.


  • Unsuccessful the interview the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • No matter how well you prepare for interview, some are not successful. One of the primary reasons might be that you and the interviewee do not get along with each other. This can be caused by several factors. For example, you and interviewee might simply have a personality conflict, or the interviewee might be anti-computer and afraid that you are there to eliminate his or her job. The interviewee might be involved in an internal political problem that prevents him or her from cooperating.

  • In other interview situations, the interviewee might give only short or incomplete responses to your open-ended questions.


  • Other important fact-finding technique the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • There are several standard fact-finding techniques. Although interviewing is the most commonly used, the others are also valuable and effective techniques for requirements determination. During a typical project, you can use a variety of these fact-finding techniques, the most used of which are data collection, observation, questionnaires, and research.

  • Data collection

  • - The existing system documentation

  • - The system’s operating procedure documents


  • Observation the response. You would use closed-ended questions when you are seeking more specific information or need verification or clarification of facts. Example of closed-ended questions are How many microcomputers are there in this department?

  • Another fact-finding technique is the observation of current operating procedures. Often, it takes observation of a system in action to fully understand that system’s requirements. Seeing the system in action gives you an additional perspective to supplement what you have heard and read. During observation, you might solidify your hazy understanding of the system and its procedures. You might also correct any misconceptions or erroneous impressions you had formed. In addition, by personal observation you can verify statements made in interviews, as well as determine if procedures operate as specified in the system documentation. You might even discover that neither the


  • System documentation nor the statements from those interviewed truly reflect the system in operation.

  • When you observe individuals performing tasks, you should be aware of a phenomenon called the Hawthorne Effect.

  • Questionnaires

  • In large system projects where it is not possible to interview all individuals associated with the system, the questionnaire can be a valuable tool. A questionnaire is a document containing a number of standard questions that you ask of a large number of people. Questionnaires are used to obtain information such as work loads, reports


  • received, volumes of transactions handled, types of job duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • Apply the following rules when you design a questionnaire.

    • Make the questionnaire as brief and easy to answer

    • as possible

    • Arrange the questions in logical order.

    • Phrase questions to avoid misunderstandings

    • Phrase questions to avoid giving clues to expected

    • answers.

    • Avoid questions that require long, narrative

    • answers.


  • Avoid questions that appear threatening to a duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • person’s job.

  • Determine carefully what questions are required to

  • obtain the information you desire.

  • Test the questionnaire whenever possible on a small

  • group of subjects before handing out the

  • questionnaire formally.


The formats for the questions duties, difficulties, and opinions of how the job could be better or more efficiently performed.

- Close-end questions

- Open-end questions

- Check-off questions

- Range questions


Sample questionnaire duties, difficulties, and opinions of how the job could be better or more efficiently performed.

1. How many purchase requisitions did _________

you process in the past five working day?

2. What percentage of your time is spent [ ] under 20%

processing requisitions? [ ] 21-39%

[ ] 40-59%

[ ] 60-79%

[ ] 80% or more

3. Do you believe there are too many [ ] yes

errors on requisitions? [ ] no

4. Out of every 100 requisitions you [ ] fewer than 5

process, how many contain errors? [ ] 5 to 9

[ ] 10 to 14

[ ] 15 to 19

[ ] 20 to 29

[ ] 30 or more


Sample questionnaire duties, difficulties, and opinions of how the job could be better or more efficiently performed.

5. What errors do you most often [ ] Incorrect charge

see on requisitions?(Place a 1 next number

to the most common error, place [ ] Missing charge

a 2 next to the second most common) information

[ ] Arithmetic errors [ ] Incorrect discount percent used

[ ] Missing authorization

[ ] Other(please explain)________ ______________

6. If the currently used purchase requisition form were to be redesigned, what changes to the form would you recommend?

___________________________________________________________________________________________________


  • Research duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • Research can involve reviewing journals, periodicals, and books that contain information relevant to the task at hand. Research can involve attending professional meetings and seminars. Formal and informal discussions with other professionals in related area also can shed valuable light on the problem. And finally, research can involve site visitations.

  • A site visitation is a visit to another installation to see one of its system in actual use.


  • Recording the facts duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • The need for recording the facts

  • We cannot overemphasize the importance of adequate records of interviews, facts, ideas, and observations. You might have difficulty appreciating the significance of particular facts in a sea of facts, and you might easily forget ideas and understandings as you move from procedure to procedure through a system. The basic rule, therefore, is to write it down. You should document your investigations according to the following principles.

  • Often, SA use specialized forms for documenting a system, such as special forms for interviews.


  • Writing tips duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • Good writing is important. Other people judge you by your writing. Grammatical mistakes, typographical errors, and spelling mistakes cause readers of your documents to judge you poorly and, consequently, to downgrade or dismiss what you are trying to say. The points you are trying to make will be lost.

  • If you have not already taken a writing class, and if it is at all possible to fit one into your program, we strongly encourage you to do so.


Requirement analysis overview duties, difficulties, and opinions of how the job could be better or more efficiently performed.

Two important tasks conclude the system analysis phase. The first task is the creation of a formal report, the system requirements document, that details everything that you have learned and concluded about the information system. This formal report serves as the starting point for systems design, the next phase in the system development life cycle.

The final task of the system analysis phase is the formal presentation of your findings. Even though the audience has already received your formal report, this oral presentation is necessary and very important.


  • Presentations duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • Presentation techniques

  • 1. Define the audience.

  • 2. Define the objectives.

  • 3. Organize the presentation.

  • 4. Define terms.

  • 5. Prepare presentation aids.

  • 6. Practice.

  • The presentation

  • When you give the actual presentation, keep the following points in mind to maximize your chances for success.


  • Sell yourself and your credibility. duties, difficulties, and opinions of how the job could be better or more efficiently performed.

  • Control the presentation.

  • Answer questions appropriately.

  • Use good speaking techniques.


Analyzing Requirements duties, difficulties, and opinions of how the job could be better or more efficiently performed.

In this chapter, you will learn about structured analysis, which is the most popular technique used for requirements analysis. Specifically, you will learn about the components of structured analysis: data flow diagrams, the data dictionary, and process descriptions.

Data flow diagrams

A data flow diagram shows how data moves and changes through an information system in a graphical, top-down fashion. System analysts use data flow diagrams, often referred to as DFDs, to produce a logical model of an information system in a simple, direct way. DFDs are not used to show the logic of a program.


Data Flow Diagram Symbols duties, difficulties, and opinions of how the job could be better or more efficiently performed.

Two major versions

- Yourdon/DeMarco

- Gane/Sarson


Yourdon DFD symbols duties, difficulties, and opinions of how the job could be better or more efficiently performed.

Symbols Symbol name Examples

Process

Apply

Payment

Calculate

Commission

Bank Deposit flow

Data flow

Invoice Payment

Data store

STUDENT

External Entity

CUSTOMER


Gane/Sarson duties, difficulties, and opinions of how the job could be better or more efficiently performed. DFD symbols

Symbols Symbol name Examples

Process

Apply

Payment

Calculate

Grade

Data store

STUDENT

External Entity

CUSTOMER


Note duties, difficulties, and opinions of how the job could be better or more efficiently performed.

1. One of the symbols must be a process

2. Two-way flows are not permitted between

processes

3. Flows between processes and to, or from, entities

must be labeled


COMPLETED ORDER duties, difficulties, and opinions of how the job could be better or more efficiently performed.

INVOICE

CREATE

INVOICE

GRADED WORK

SUBMITTED WORK

GRADE

STUDENT

WORK

STUDENT GRADE

HOURS WORKED

GROSS PAY

CALCULATE

GROSS

PAY

PAY RATE

ORDER

ACCEPTED

ORDER

VERIFY

ORDER

ASSEMBLE

ORDER

INVENTORY

CHANGE

Examples of correct combination of data flow diagram


POLICY NUMBER duties, difficulties, and opinions of how the job could be better or more efficiently performed.

PAYMENT AMOUNT

APPLY

INSURANCE

PREMIUM

HOURS WORK

PAY RATE

CALCULATE

GROSS

PAY

Examples of incorrect combination of data flow diagram


POST duties, difficulties, and opinions of how the job could be better or more efficiently performed.

PAYMENT

ADMIT

PATIENT

CUSTOMER

PAYMENT

ADMISSION

FORM

DAILY

PAYMENTS

PATIENTS

DAILY

PAYMENTS

TREATMENT

SYMPTOM

PREPARE

DEPOSIT

DIAGNOSE

PATIENT

TREAT

PATIENT

Examples of correct combination of data flow diagram


BOOK duties, difficulties, and opinions of how the job could be better or more efficiently performed.

FLIGHT

COURSES

CLASS

LIST

FLIGHT

REQUEST

STUDENTS

PASSENGERS

Examples of incorrect combination of data flow diagram


PAYMENT duties, difficulties, and opinions of how the job could be better or more efficiently performed.

APPLY

PAYMENT

CUSTOMER

Examples of correct combination of data flow diagram

PAYCHECK

PAYROLL

DEPARTMENT

EMPLOYEE

CUSTOMER

PAYMENT

ACCOUNT

RECEIVABLE

Examples of incorrect combination of data flow diagram


Steps In Developing Data Flow Diagrams duties, difficulties, and opinions of how the job could be better or more efficiently performed.

Using a Top-Down Approach

1. Make a list of business activities and use it to determine

various

- External Entities

- Data Flows

- Processes

- Data Stores

2. Create a context diagram which shows external entities and

data flows to and from the system. Do not show any

detailed processes or data stores.

3. Draw Diagram 0, the next level. Show processes, but keep

them general. Show data stores at this level.


4. Create a child diagram for each of the processes in Diagram 0.

5. Check for errors and make sure the labels you assign to each

process and data flow are meaningful.

6. Develop a physical data flow diagram from the logical

data flow diagram. Distinguish between manual and

automated processes, describe actual files and reports by

name, and add controls to indicate when processes are

complete or errors occur.

7. Partition the physical data flow diagram by separating or

grouping parts of the diagram in order to facilitate

programming and implementation.


  • Context diagrams Diagram 0.

  • A context diagram is a data flow diagram that shows the boundaries of the information system. The context diagram is a top-level view of the information system. To draw a context diagram, you place one process symbol representing the entire information system in the center of the page. You then draw all the external entities around the perimeter of the page and use data flows to properly connect these external entities to the central process. You do not show any data stores in a context diagram because data stores are internal to the system.


EMPLYP00 Diagram 0.

APPLICANT

MANAGER

APPLICANT

EMPLOYMENT

SERVICES

MANAGER

APPLICANT

DATA

EMPLOYMENT

MONITORING

DATA

PAYROLL

DATA

GOVERNMENT

AGENCIES

GOVERNMENT

AGENCIES

Context-level DFD : Employment System


  • Conventions for data flow diagrams Diagram 0.

  • - Each context diagram must fit on one page.

  • - The process name in each context diagram should be

  • the name of the information system.

  • - Use unique names within each set of symbols

  • - Avoid crossing lines, if at all possible.

  • - Use abbreviated identifications when you are using a

  • computerized data dictionary.

  • Diagram 0

  • Diagram 0 is a data flow diagram that gives a more detailed view of an IS than does the context diagram. On diagram 0 you show the major process, data flows, and data stores for the IS.


APPLICANT DATA Diagram 0.

PERSONNEL DATA

PAYROLL DATA

APPLI-

CANT

DATA

PERSON-

NEL

DATA

PAY-

ROLL

DATA

EMPLY00P00

EMPLY00P01

EMPLY00P02

APPLICANT

MANAGER

COMPLETE

EMPLOYMENT

APPLICATION

CREATE

PAYROLL

DATA

FILL

OPENING

APPLICANT

MANAGER

JOB

APPLICA-

TION

MANAGER

REPORTS

NEW

EMPLOYEE

JOB

NOTIFICATION

PERSONNEL

DATA

PAYROLL

DATA

GOVERNMENT

AGENCIES

APPLICANT

APPLICANT

GOVERNMENT

AGENCIES

APPLICANT

APPLICANT

Diagram 0 : Employment System


  • Lower level diagrams Diagram 0.

  • - Leveling

  • Leveling is the DFD technique of representing the graphical model of an information system first as a single process, and then in greater and greater detail, until the only processes are functional primitives.

  • - Balancing

  • A balanced data flow diagram is one that has the parent process’s input and output data flows preserved on the child data flow diagram.

  • - Data store

  • The data store might appears on the diagram 2, but it did not appear on diagram 0 nor on diagram 1.


EMPLY0000P00 Diagram 0.

EMPLY0000P01

APPLICANT

APPLICANT FORM

COMPLETE

PERSONNEL

FORM

VALIDATE

APPLICA-

TION

APPLI-

CANT

FORM

APPLICANT

APPLICA-

TION DATA

COMPLETED

APPLICA-

TION

VALID

APPLICA-

TION DATA

EMPLY0000P02

EMPLY0000P03

EMPLY0000P04

CHECK

DUPLICATE

APPLICATION

CHANGE

APPLICA-

TION DATA

TRANSCRIBE

APPLICATION

APPLICA-

TION

CHANGES

NEW

APPLICA-

TION

APPLICANT DATA

APPLI-

CANT

DATA

Diagram 1 : for COMPLETE EMPLOYMENT APPLICATION


Budget allocation Diagram 0.

DEPARTMENTS

MANAGEMENT

Spending

request

Request for

special approval

Response to

special approval

Rejected request

Budget

monitoring

system

Spending summaries

Delivery advice

Part order

SUPPLIERS

Supplier

delivery advice

Context-level DFD : Budget monitoring System


Inventory Diagram 0.

Control

Department

Backorder Item

0

Shipped Order

Customer Billing Statement

Item Information

Customer Order

New Customer Information

Item Number or Description

Customer

Order

Processing

System

Customer

Order Picking List

Order Goods

Accounts Receivable Report

Accounting

Warehouse

Context-level DFD : Order Processing System


The basic definition of entities on a DFD : they represent Diagram 0.

organizations, agents, or people, inside and outside the system

under study, that are sources or destinations of data. They either

provide inputs to or receive outputs from processes of the

business application under investigation. They are considered

to be external to the application processes (not a part of them),

yet necessarily related to them. The analystmust determine

whether the entity is being controlled by the system or whether

it is a part of the system’s processes. Manyentities internal to

the business may become part of theprocesses, rather than

sources of data for the processes.


Data dictionary Diagram 0.

We use DFD to present a graphic, top-down logical model of an IS. This logical model is an organized, structured view of the information system’s data and the data’s transformations without the clutter of details. We place the detailed data definitions and processing rules in a data dictionary. Which is the second component of structure analysis.

A data dictionary is a central storehouse of data about an information system’s data and data’s transformations. You use the data dictionary throughout the SDLC and during systems operation to document the detailed facts about an IS.


DATA DICTIONARY Diagram 0.

DATA ELEMENTS

DATA FLOW

DATA STORES

PROCESSES

EXTERNAL

ENTITIES

The data dictionary, the items defined in the data dictionary, and the

relationships among these items.


  • Documenting data elements Diagram 0.

  • In the DD, you must document every data element in the IS. You define the following characteristics of each data element, as shown in the examples.


DATA ELEMENT Diagram 0.

DATA DICTIONARY FORM

DATA ELEMENT NAME : SOCIAL SECURIT NUMBER

ALTERNATE NAME : EMPLOYEE NUMBER, SSN

TYPE AND LENGTH : 9N,0 DECIMALS

OUTPUT FORMAT : nnn-nn-nnnn

DEFAULT VALUE : none

PROMPT / COLUMN HEADER : SCO SEC NUM

SOURCE : Employee Application Form

SECURITY : Payroll Department (update)

department management (access only)

RESPONSIBLE END USER : Payroll Department

ACCEPTABLE VALUES : any number

OTHER VALIDATION : none

DERIVATION FORMULA : none

DESCRIPTION AND COMMENTS :


DATA ELEMENT Diagram 0.

DATA DICTIONARY FORM

DATA ELEMENT NAME : STATE

ALTERNATE NAME : STATE CODE, STATE POSTAL ABBREVIATION

TYPE AND LENGTH : 2A

OUTPUT FORMAT : XX

DEFAULT VALUE : MI

PROMPT / COLUMN HEADER : STATE

SOURCE : Credit Card Application Form

SECURITY : none

RESPONSIBLE END USER : Marketing Department

ACCEPTABLE VALUES : STATE CODE TABLE values only

OTHER VALIDATION : ZIP CODE and STATE must be consistent

DERIVATION FORMULA : none

DESCRIPTION AND COMMENTS : Standard state postal abbreviation. May be changed

when customer completes a Change of Address

Form.


  • Documenting data flows Diagram 0.

  • You must document every DFD data flow in the data dictionary.

  • DATA FLOW

  • DATA DICTIONARY FORM

  • DATA FLOW NAME : COMMISSION

  • ALTERNATE NAME : SALES COMMISSION

  • ABBREVIATION : F7

  • RECORD : COMMISSION

  • DESCRIPTION : Commission earned by a given sales rep on a given

  • order that has been paid by the customer

  • ORIGIN : PAY COMMISSION process

  • DESTINATION : SALES REP external entity

  • VOLUME AND FREQUENCY : approximately 20 per day


  • Documenting data stores Diagram 0.

  • You must document every DFD data store in the data dictionary.

  • DATA STORE

  • DATA DICTIONARY FORM

  • DATA STORE NAME : PRODUCTS

  • ALTERNATE NAME : PARTS, INVENTORY ITEMS

  • ABBREVIATION : D3

  • RECORD : PRODUCTS

  • DESCRIPTION : The raw materials, subassemblies, and finished

  • goods for the products manufactured.

  • INPUT DATA FLOWS : INVENTORY CHANGE

  • OUTPUT DATA FLOWS : PICKING DETAIL

  • VOLUME AND FREQUENCY : 4500 to 5000 total product records

  • 2 to 20 additions and changes per month


  • Documenting processes Diagram 0.

  • You must document every DFD process that is a functional primitive in the data dictionary.

  • PROCESS

  • DATA DICTIONARY FORM

  • PROCESS NAME : VERIFY ORDER

  • PURPOSE : Determines if an incoming customer order should

  • be accepted based on the customer’s credit

  • standing and each product’s availability.

  • INPUT DATA FLOWS : ORDER, CREDIT STATUS, PRODUCT DETAIL.

  • OUTPUT DATA FLOWS : REJECTED ORDER, ACCEPTED ORDER


  • Documenting external Diagram 0.

  • You must document every DFD external entities in the data dictionary.

  • EXTERNAL ENTITY

  • DATA DICTIONARY FORM

  • EXTERNAL ENTITY NAME : WAREHOUSE

  • ALTERNATE NAME : STOREROOM

  • ACRONYM : W

  • INPUT DATA FLOWS : PICKING LIST.

  • OUTPUT DATA FLOWS : COMPLETED ORDER

  • DESCRIPTION : Raw materials and finished goods are stored in

  • three warehouse locations.


  • Documenting records Diagram 0.

  • You must document all records in the data dictionary.

  • RECORD

  • DATA DICTIONARY FORM

  • RECORD NAME : CREDIT STATUS

  • ALTERNATE NAME : none

  • DEFINITION : The customer’s level of credit and quality rating.

  • DATA ELEMENT CONTENT :

  • CUSTOMER NUMBER PK

  • CUSTOMER STATUS CODE

  • REMAINING CREDIT LIMIT


Entry Type Dictionary ID Diagram 0.

Data Structures LOG-APPLICATION

Alias : JOB APPLICATION DATA

Comment : A LOG-DS for job application data.

Starting Volume : Growth Potential : __________

No. Ele/DS Name DE/DS SV/MV Occurrence

01 SSNUMBER DE SV

02 NAME DE SV

03 ADDRESS DE SV

04 TELEPHONE_NUMBER DE SV

05 NEXT_OF_KIN DE SV

06 NEXT_OF_KIN_TELEPHONE DE SV

07 DATE DE MV

08 POSITION DE MV

09 MPHY_APPLICATION DS

_________________________________________________________

Figure : LOG-APPLICATION dictionary entry


Entry Type Dictionary ID Diagram 0.

Data Element SSNUMBER

Alias : PERSON ID

EMPLOYEE NUMBER

Element Type Length Input Format Output Format

Character 9 XXXXXXXXX XXX-XX-XXXX

Data request prompt : SOC.SEC.Number:

Columnar heading : SOC.SEC.Number

Roles portrayed by element : Identify People

Identify Applicant

Text Description & Comments

This data item is used to identify people within applicant, employment,

and payroll data structures.

_________________________________________________________

Figure : SSNUMBER dictionary entry


Process description tools Diagram 0.

A process description documents the details of a functional primitive in a precise and concise way. You must have one process description for each functional primitive . Structured analysis’s process description language is based on the fundamental principle of structured design and programming - that all problem solutions can be expressed by appropriate combinations of three logical building blocks, or structures:

1. Sequence

2. Selection

3. Iteration


  • Structured English Diagram 0.

  • 1 for each COMMISSION EARNED

  • 2 if EXTRA BONUS equals Y

  • 3 if PAYMENT TOTAL is greater than $50,000

  • 4 Add 2% to COMMISSION PERCENT

  • 5 Output SPECIAL LETTER

  • 6 Output AWARD LIST

  • 7 Else

  • 8 Add 1% to COMMISSION PERCENT

  • 9 Output AWARD LIST

  • 10 Else

  • 11 if PAYMENT TOTAL is greater than $50,000

  • 12 Add 1% to COMMISSION PERCENT

  • 13 Output SPECIAL LETTER

  • 14 Calculate COMMISSION = COMMISSION PERCENT times

  • PAYMENT TOTAL


  • Decision tables Diagram 0.

  • A decision table is a tabular description of a selection structure. A decision table often is a better tool than structure English for describing a selection process with many complex conditions because you can easily spot inconsistencies. The general format of a decision table :

Rule

Heading

Rule no.

1 2 3 4

Condition

Condition entries

Action

Action entries


Rules Diagram 0.

1 2 3 4

Conditions and Actions

Under $50

Pays by check with 2 forms of ID

Uses credit card

Y Y N N

Y N Y N

N Y N Y

Ring up sale

Look up credit card in book

Call supervisor for approval

Call bank for credit authorization

X

X

X

X

Decision Table


  • Decision trees Diagram 0.

  • A decision tree is a graphic representation of a selection structure.

Add 2% to COMMISSION PERCENT

Output SPECIAL LETTER

Output AWARD LIST

PAYMENT TOTAL

More Than

$50,000

EXTRA

BONUS

PAYMENT TOTAL

Not More Than

$50,000

Add 1% to COMMISSION PERCENT

Output AWARD LIST

Add 1% to COMMISSION PERCENT

Output SPECIAL LETTER

PAYMENT TOTAL

More Than

$50,000

NO

EXTRA

BONUS

PAYMENT TOTAL

Not More Than

$50,000


Completing The System Analysis phase and Considering Alternative Tools

Evaluating alternatives

After constructing the logical model of the proposed IS, you are ready to consider solutions that

might satisfy the information system’s requirements.

The two primary solutions you consider are the development of in-house software and the purchase of a software package. You should also consider other potential solutions, such as contracting with another company to develop the system and letting the end users develop their own system. Frequently, you must also make choices among hardware alternatives. We will first consider the softwarealternatives.


  • Software alternatives Alternative Tools

  • When evaluating software alternatives, you must often choose between in-house developed software and software packages.

    • Developing Your Own Software

      • Satisfy unique requirements.

      • Minimize change to business procedure and policies.

      • Meet the constraints of existing systems.

      • Meet the constraints of existing technology.

      • Utilize new technology.

    • Buying a Software Package

      • Package is less expensive.

      • Package requires less time to implement.

      • Package has fewer errors.

      • Package is already in use in many companies.


  • Selecting software packages

  • The selection of a software package involves five steps: evaluate the IS requirements, identify potential software vendors, evaluate software package alternatives, make the purchase, and install the software package.

  • Hardware alternatives

  • You should select hardware similar to the way in which you select software packages. If you are purchasing hardware, such as printers, computers, and workstations, then you need to plan and complete the necessary site preparation activities.


  • Site preparation can range from clearing a space on an office desk for a new workstation to the installation of special raised floors, water pipes, electrical lines, and backup storage batteries for a large mainframe computer.


    • Completion of systems analysis office desk for a new workstation to the installation of special raised floors, water pipes, electrical lines, and backup storage batteries for a large mainframe computer.

    • Preparing and distributing the system requirement document, preparing and making presentations of your analysis, and establishing procedures for controlling future changes to the system requirements are the activities that complete the system analysis phase.

    • System requirements document

    • The system requirements document presents the detailed requirements for the new information system, describes the alternatives considered, and specifies your recommended

    • course of action. The system requirementsdocumentserves as

    • the baseline from which systems design will begin and against which the operational system will be measured in terms of its


    performance, accuracy, and completeness. You can consider the system requirements document to be a contract that details what must be delivered by the system developers to the end users. Therefore, the document should be written in the end users’ language so they can understand it, suggest improvements to it, and approve its final version. The system requirements document is also called the software requirement specification.

    The contents of the system requirements document varies, depending on the company and the complexity of the IS. The organization of a typical system requirements document :

    1. Management Summary

    2. IS background


    • 3. Functional requirement the system requirements document to be a contract that details what must be delivered by the system developers to the end users. Therefore, the document should be written in the end users’ language so they can understand it, suggest improvements to it, and approve its final version. The system requirements document is also called the

    • 4. Environmental requirements

    • 5 Alternatives

    • 6. Recommended Alternative

    • 7. Time and Cost estimates

    • 8. Appendices (as needed)

    • Presentations

    • The presentation given to company management at the end of the systems analysis phase is one of the most critical milestones in the entire SDLC. At the presentation, or as a result of what occurs at the presentation, management makes major decisions and commitments for the ultimate disposition of the IS.


    • The objective of the management presentation is to permit management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    • 1. Develop an in-house system.

    • 2. Modify the current information system.

    • 3. Purchase a software package.

    • 4. Purchase a package and develop an in-house system

    • 5. Perform additional systems analysis work.

    • 6. Stop all further work.

    • Change control

    • Change control is the process of managing and controlling the requested changes in requirements for an IS.


    Computer-aided software engineering (CASE) management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    The last few years have produced exciting results in the

    development of computer tools used to support the analysis and

    design of business system. Electronic tools to automate

    portions of the methodology of A&D are affecting all phases of

    the system life cycle and will continue to do so.This

    technology is call Computer Aided Software Engineering,

    or CASE.

    A CASE tool is a software product that automates a

    specific systems life cycle task; examples are a screen

    generator and a computerized data dictionary.


    Components of CASE management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - Upper CASE includes a computer-aided component

    for planning purposes

    - Middle CASE includes components for analysis and

    design purposes

    - Lower CASE includes components for system

    development


    Upper CASE Tools management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    An upper CASE tool allows the analyst to create and

    modify the system analysis and design. All the information

    about the project is stored in an encyclopedia called the CASE

    repository, a large collection of records, elements,diagrams,

    screens, reports and other information. Analysis reports may

    be produced using the repository information to show where

    the design is incomplete or contains errors.


    Lower CASE Tools management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    The lower CASE tools are used to generate computer

    source code, eliminating the need for programming the

    system.


    The reasons for adopting CASE Tools : management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - increasing analyst productivity

    - improving communication among analysts and users

    - integrating life cycle activities

    - analyzing and assessing the impact of maintenance

    changes


    JOINT APPLICATION DESIGN (JAD) management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - Consists of a joint interactive session between users

    and IS personnel used to acquire user requirements

    through modeling the business and information systems

    JAD Main Objective

    - Help acquire user requirements, review those

    requirements, and obtain changes to them based on user

    responses


    Benefits of JADs management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - JADs help users feel that they have more impact on the

    project

    - JADs help analyst understand what users face in the business

    - JADs improve the communication between users and

    analysts

    - JADs help identify important issues and the people

    responsible for resolving them

    - JADs help answer questions that require making a decision

    or further investigation


    Benefits of JADs (cont) management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - JADs help identify the people who have the knowledge that

    is needed as input to th A&D project

    - JADs facilitate the evolutionary process of defining the

    business and information systems models of the firm

    - JADs provide systematic ways to track user requirements as

    the analyst progresses through the phases of the projrct life

    cycle

    - JADs help to better integrate the outputs from project

    phases


    JAD Participants management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - Functional area managers (including the executive sponsor)

    - Functional area clerical personnel

    - Functional area technical personnel

    - The facilitator

    - JAD/CASE experts

    - Scribes

    - IS managers and systems personnel


    General Rules for JAD Sessions management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - JADs are conducted from the perspective of the user.

    - Everyone participates.

    - One participant at a time speaks, without interruption.

    - Participant availability and the need for participant interaction

    dictate the length of the session.

    - Technology is incorporated into JADs to produce more formal

    results and aid in review.

    - Several JAD sessions may be required over the project life

    span.

    - JAD sessions continue until a consensus is reached.


    JAD structure as having three different phases management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:

    - Preworkshop Activities

    - Workshop Activities

    - Postworkshop Activities


    JAD Room Layout and participant position management to decide on the next step to take for the development of the IS, to give their full support and approval to the chosen direction, and to commit money and other needed resources. Management will make one of these six decisions:


    ad