Phase 2 : System Analysis Determining Requirements

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 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 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 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 • 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 • 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 • 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 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. • 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 • 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 • 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 • 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. • 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 • 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 • 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 • 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 • 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 • 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 - Close-end questions - Open-end questions - Check-off questions - Range questions

Sample questionnaire 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 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 • 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 • 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 • 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 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 • 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. • Control the presentation. • Answer questions appropriately. • Use good speaking techniques.

Analyzing Requirements 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 Two major versions - Yourdon/DeMarco - Gane/Sarson

Yourdon DFD symbols Symbols Symbol name Examples Process Apply Payment Calculate Commission Bank Deposit flow Data flow Invoice Payment Data store STUDENT External Entity CUSTOMER

Gane/Sarson DFD symbols Symbols Symbol name Examples Process Apply Payment Calculate Grade Data store STUDENT External Entity CUSTOMER

Note 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 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 PAYMENT AMOUNT APPLY INSURANCE PREMIUM HOURS WORK PAY RATE CALCULATE GROSS PAY Examples of incorrect combination of data flow diagram

POST 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 FLIGHT COURSES CLASS LIST FLIGHT REQUEST STUDENTS PASSENGERS Examples of incorrect combination of data flow diagram

PAYMENT 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 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 • 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 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 • - 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.

Phase 2 : System Analysis Determining Requirements