Introduction Case

Dilbert Cartoon MS Project task

Typical Requirements Modeling Task list.

Systems Analysis Phase Overview

Objectives Understand the Proposed project. Ensure that it will support business requirements. Build a solid foundation for system development.

System Analysis Activities

Four Main Activities : Requirements modeling Data and Process Modeling Object modeling Development strategies

System Analysis Phase Tasks

Requirments Modeling

Data and Process Modeling

Object Modeling

Development Strategies

Requirements Modeling
Fact Finding Describe the current system and identification of the requirements for the new system, such as outputs, inputs, processes, performance and security.

Requirements Modeling
Outputs Refer to electronic or printed information produced by the system. Inputs Refer to necessary data that enters the system, either manually or in an automated manner.

Requirements Modeling
Process Refer to the logical rules that are applied to transform the data into meaning. Perform Refer to system characteristics such as speed, volume, capacity, availability and reliability.

Requirements Modeling
Security Refer to hardware, software and procedural controls that safeguard and protect the system and its data from internal or external threats.

Data And Process Modeling

Continuing the modeling process by learning how to represent graphically system data and processes using traditional structured analysis techniques.

Object Modeling
While structured analysis treats processes and data as separate components, object-oriented analysis (O-O) combines data and the process that act on the data into things called objects.

Object Modeling
These objects represent actual people, things, transactions, and events that affect the system.

Development Strategies
Considering various development options and preparing for the transition to the systems design phase of the SDLC.

Development Strategies
You will learn about: Software trends Acquisition and development alternatives Outsourcing Formally documenting requirements for the new system.

System Analysis Requirements Development

It is the Deliverable, or end product , of the systems analysis phase which is an overall design for the new system.

System Analysis Requirements Development

Large systems projects require considerable effort to coordinate people, tasks, timetables, and budgets.

System Analysis Skills

Analytical skills Enable you to identify a problem, evaluate the key elements and develop a useful solution.

System Analysis Skills

Interpersonal Skills Especially valuable to a systems analyst who must work with people at all organizational levels, balance conflicting needs of users, and communicate effectively.

System Analysis Skills

Because information systems affect people throughout the company, you should consider team-oriented strategies as you begin the systems analysis phase.

Team Oriented Methods and Techniques

Greater user involvement usually results in better communication, faster development times and more satisfied users.

Team Oriented Methods and Techniques

Joint Application Development (JAD) A popular fact Finding technique that brings users into the development process as active participants.

Joint Application Development (JAD)

User Involvement Until recent years, the IT department usually had sole responsibility for systems development, and users had a relatively passive role.

Joint Application Development (JAD)

During Development process, the IT staff would collect information from users, define system requirements and construct the new system.

Joint Application Development (JAD)

At various stages of the process, the IT staff might ask users to review the design, offer comments, and submit changes.

Joint Application Development (JAD)

Successful systems must be user-oriented, and users need to be involved , formally or informally, at every stage of system development.

Joint Application Development (JAD)

JAD team approach One popular strategy for user involvement.

JAD Participants and Roles

The OBJECTIVES is to analyze the existing system, obtain user input and expectations, and document user requirements for the new system.
A JAD team of users, managers, and IT professionals works together to identify and document requirements for a new system

JAD Participants and Roles

JAD Participants JAD project leader Role Develops an agenda, acts as a facilitator, and leads the JAD session

JAD Participants and Roles

Top management Provides enterprise-level authorization and support for the project and understanding of how the project must support business functions and requirements

JAD Participants and Roles

Users Provide operational-level input on current operations, desired changes input and output requirements, user interface issues, and how the project will support day-to-day tasks

JAD Participants and Roles

Systems analysts and other Provides technical IT staff members assistance and resources for JAD team members or issues such as security, backup, hardware, software, and network capability

Agenda for a JAD session

JAD Participants Recorder Role Documents results of JAD sessions and works with systems analysts to build system models and develop CASE tool documentation

Agenda for a JAD session

Project leader Introduce all JAD team Members Discuss ground rules, goals, and objectives for the JAD sessions Explain methods of documentation and use of CASE tools, if any

Agenda for a JAD session

Top management(sometimes Explain the reason for the called the project owner or project and express top sponsor) management authorization and support

Agenda for a JAD session

Project leader Provide overview of the current system and proposed project scope and constraints Present outline of specific topics and issues to be investigated

Agenda for a JAD session

Open discussion Review the main business session, moderated by processes, tasks, user roles, project leader inputs, and output. Identify specific areas of agreement or disagreement Break team into smaller groups to study specific issues and assign group leaders

Agenda for a JAD session

JAD team members working Discuss and document all in smaller group sessions, system requirements supported by IT staff Develop models and prototypes

Agenda for a JAD session

Group leaders Report on result and assigned tasks and topics Present issues that should be addressed by the overall JAD team

Agenda for a JAD session

Open discussion session, Review reports from moderate by project leader small group sessions Reach consensus on main issues Document all topics

Agenda for a JAD session

Project leader Present overall recap of JAD session Prepare report that will be sent to JAD team members

JAD Disadvantage
Compared with traditional methods, JAD is more expensive and can be cumbersome if the group is too large relative to the size of the project.

JAD Advantage
Many Companies find, however, that JAD allows key users to participate effectively in the requirements modeling process.

JAD Advantage
Users are more likely to feel a sense of ownership in the results, and support for the new system.

JAD Advantage

When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system.

Rapid Application Development

A team-based technique that speeds up information systems development and produces a functioning information system.

Rapid Application Development

RAD Relies heavily on prototyping and user involvement. The RAD process allows users to examine a working model as early as possible, determine if it meets their needs, and suggest necessary changes.

Four Phases of RAD

Requirments Planning

User Design

Construction

Cutover

Rapid Application Development

Requirements Planning Users, managers and IT staff agree upon business needs, project scope and system requirements Obtain approval to continue

Rapid Application Development

User Design Interact with users Build models and prototypes Conduct intensive JAD-type sessions

Rapid Application Development

Construction Program and application development Coding Unit, integration, and system testing

Rapid Application Development

CUTOVER Data conversion Full-scale testing System changeover User training

RAD Objectives
The main objective of all RAD approaches is to cut development time and expense by involving users in every phase of the systems development.

RAD Disadvantage
RAD stresses the mechanics of the system itself and does not emphasize the companys strategic business needs. Accelerated time cycle might allow less time to develop quality, consistency, and design standards.

RAD Advantage
System can be develop more quickly with significant cost savings.

Difference of JAD and RAD

Like JAD, RAD uses a group approach, but goes much further. While the end product of JAD is a requirements model, the end product of RAD is the new information system.

Modeling Tools and Techniques

Modeling Tools and Techniques

Modeling helps users, managers, IT professionals understand the design of a system. & involves graphical methods & non-technical language that represent the system at various stages of development. During modeling, you can use various tools to describe business process, requirements, and user interaction with the system.

Case Tools
In Chapter 1 you learned that CASE tools can offer powerful modeling features. For example, the business modeling tutorial shown in Figure 3-8 provides a tool that an analyst can use to document what the business does, why those functions are, who carries out the tasks, and how it is done.

Case Tools

CASE Tools

Systems analysts use modeling and fact finding interactively.

first

they build fact finding results into model Then they study the models to determine whether additional fact-finding is needed.

Case Tools
To help them understand systems requirements, systems analysts often use functional decomposition diagrams, which provide a business-oriented overview, and the Unified Modeling Language, which shows how people interact with the system.

FUNCTIONAL DECOMPOSITION DIAGRAMS

A functional decomposition diagram (FDD) is a top-down representation of function or process. FDDs also are called structure charts. Using an FDD, an analysts can show business functions and break them down into lower-level functions and processes.

FUNCTIONAL DECOMPOSITION DIAGRAMS

Creating an FDD is similar to drawing an organizing chart you start at the top and work your way down. Figure 3-9 shows a four level FDD of a library system drawn with the Visible Analysts CASE tool.

FUNCTIONAL DECOMPOSITION DIAGRAMS

FUNCTIONAL DECOMPOSITION DIAGRAMS

FDD can be used at several stages of systems development. During use FDDs to model business functions and show how they are organized into lower-level processes. Those processes translate into program modules during modules during application development.

DATA FLOW DIAGRAMS

Working from a functional decomposition diagram, analysts can create data flow diagrams (DFDs) to show how the systems stores, processes, and transforms data. The DFD in Figure 3-10 describes adding and removing books, which is function shown in the Library Management diagram in Figure 3-9.

DATA FLOW DIAGRAMS

DATA FLOW DIAGRAMS

Notice that the two shapes in the DFD represent processes, each with various inputs and outputs. Additional levels of information and process modeling is described in detail in Chapter 4.

UNIFIED MODELING LANGUAGE

The Unified Modeling Language (UML) is widely used method of visualizing and documenting software systems design. UML uses object-oriented design concepts, but it is independent of any specific programming language and can be used to describe, business processes and requirements generally.

UNIFIED MODELING LANGUAGE

Use case diagrams, sequence diagrams, and other UML concepts are discussed in more detail in Chapter 5, along with other object each technique follows.

USE CASE DIAGRAMS

During requirements modeling, systems analysts and users work together to document requirements and model system functions. A use case diagram visually represents the interaction between users and the information system.

USE CASE DIAGRAMS

In a use case diagram, the user becomes an actor, with a specific role that describes how he/she interacts with the system. Systems analysts can draw use case diagrams freehand or use CASE tools that integrate the use cases into the over-all system design.

USE CASE DIAGRAMS

Figure 3-11 on the next page shows a simple use case diagram for a sales system where the actor is a customer & the use case involves a credit card validation that is performed by system. Because use cases depict the system through the eyes of a user, common business language can be used to describe the transactions..

USE CASE DIAGRAMS

For example, Figure 3-12 shows a table that documents the credit card validation use case, and Figure 3-13 shows a student records system, with several use cases and actors.

SEQUENCE DIAGRAMS
A sequence diagram shows the timing of interactions between objects as they occur. A systems analysts might use a sequence diagram to show all possible outcomes, or focus on a single scenario. Figure 3-14 shows a simple sequence diagram of a successful credit card validation.

SEQUENCE DIAGRAMS

SEQUENCE DIAGRAMS

The interaction proceeds from top to bottom along a vertical timeline, while the horizontal arrows represent messages from one object to another.

SYSTEM REQUIREMENTS CHECKLIST

During requirements modeling, systems developers must identify and describe all system requirements. A system requirement is a characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users.

SYSTEM REQUIREMENTS CHECKLIST

System requirements serve as benchmarks to measure the overall acceptability of the finished systems. System requirements fall into five general categories: outputs, processes, performance, and controls. Typical examples of system requirements for each category are listed below.

OUTPUT EXAMPLES
The Web site must report online volume statistics every four hours, and hourly during peak periods. The inventory system must produce a daily report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all sorted by part number..

OUTPUT EXAMPLES
The contact management system must generate a daily reminder list for all sales reps. The purchasing system system must provide suppliers with up-to-date specifications.

OUTPUT EXAMPLES
The

customer analysis system must produce a quarterly report that identifies changes in ordering patterns or trends with statistical comparisons to the previous four quarters.

INPUT EXAMPLE
Manufacturing employees must swipe their ID cards into online data collection terminals that record labor costs and calculate production efficiency. The department head must enter overtime hours on separate screen.

PROCESS EXAMPLES
The

student records system must calculate the GPA at the end of each semester. As the final step in year-end processing, the payroll system must update employee salaries, bonuses and benefits and procedure tax data required by the IRS.

PERFORMANCE EXAMPLES
The

system must support 25 users online simultaneously. The accounts receivable system must prepare customer statements by the third business day of the following month.

CONTROL EXAMPLES
The

systems must provide log-on security at the operating system level and at the application level. An employee record must be added, changed, or deleted only by a member of the human resources department.

FUTURE GROWTH, COST, AND BENIFITS

In addition to the system requirements listed above, systems analysts must consider scalability, which determines how a system will handle future growth and demands, and the total cost of ownership, which includes all future operational and support costs.

SCALABILITY
Scalability refers to a systems ability to handle increased business volume and transactions in the future. Because it will have a longer useful life, a scalable system offers a better return on the initial investment.

TOTAL COST OWNERSHIP

In addition to direct costs, systems developers must identify and document indirect expenses that contribute to the total costs of ownership (TCO). One problem is that cost estimates tend to understate indirect costs such as user support and downtime productivity losses.

TOTAL COST OWNERSHIP

Even if accurate figures are unavailable, systems analysts should try to identify indirect costs and include them in TCO estimates.

Fact-Finding

collecting of information by various techniques including:

- Interviews
-Document

reviews

-Observation -Surveys

and Questionnaire & Research

-Sampling

Fact-Finding Overview
-What

business functions are supported by the current system?

-What

strategic objectives and business requirements must be supported by the new system?
-What

are the benefits and TCO of the proposed system?

-What

transactions will the system process?

-What

information do users and managers need from the system?

-Must

the new system interface with legacy systems?

-What

procedures could be eliminated by business process reengineering?

-What

security issues exist?

-What

risks are acceptable?

-What

budget and timetable constraints will affect system development?

To obtain answer to this questions, you develop a fact-finding plan which involve another series of questions:
-Who?

,What? ,Where?, When?, How?

Or use a more structured approach such as the Zachman Framework to be explained later.

Either way, you will develop a: -Strategy

-Carry

out fact-finding techniques the results and

-Document

-Prepare

a system requirements documents to be presented to the management.

Who?
Who performs each of the procedures within the system?

What?
What is being done? What procedures are being followed?

Where?
Where are the operations being performed?

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

How?
How is the procedure performed?

There is a difference between asking what is being done and what could or should be done. The system analyst first must understand the situation. Only then can he she tackle the question of what should be done.

Zachman Framework
-Is

a model that asks the traditional fact-finding questions in a systems development context.
-Is

a interface that allows users to view a systems project from different perspective and level of detail.

Interview
Is a common fact-finding technique. An interview is a planned meeting during which you obtain information from another person. An interviewer must have the skills needed to plan, conduct, and document interviews successfully.

Types of interview:
-Screening -First

interview

interview (maybe the only one) interview

-Panel

-Technical
-Video

interview

conference

7 interviewing process:
1.) Determine the People to Interview
You must select the right people to interview and ask them the right questions.

2.) Establish Objectives for the Interview Determine the general areas to be discussed, and then list the facts you want to gather. You can also solicit ideas, suggestion, and opinions during interview.

2.) Establish Objectives for the Interview Determine the general areas to be discussed, and then list the facts you want to gather. You can also solicit ideas, suggestion, and opinions during interview.

2.) Establish Objectives for the Interview Determine the general areas to be discussed, and then list the facts you want to gather. You can also solicit ideas, suggestion, and opinions during interview.

3.) Develop Interview Question

Creating a standard list of interview question helps to keep you on track and avoid unnecessary tangents. It should consist of several different kinds of question: openended, close-ended and questions with a range of responses. When you phrase your questions you should avoid leading questions that suggest or favor a particular reply.

ex. What advantages do you see in the proposed system? instead Do you see any advantages in the proposed system.

Open-ended questions:
Encourage spontaneous and unstructured responses. Ex. What are users saying about the new system?

Open-ended questions:
Encourage spontaneous and unstructured responses. Ex. What are users saying about the new system?

Closed-ended Questions: limits or restrict the responses when you need to verify facts. ex. How many computers do you have in this department?c

Range-of-Responses Questions: Is a closed-ended question that ask the person to evaluate something by providing limited answers to specific responses or on a numeric scale.

Ex. On a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective was your training.

4.) Prepare for the Interview

Careful preparations is essential because an interview is an important meeting and not just a casual chat . When you schedule a interview suggest a specific day and time and let the interviewee know how long it will last.

Remember that the interview is an interruption of the other persons routine, so you should limit the interview to no more than one hour. Remember to keep department managers informed of your meetings with their staff.

Also have a letter of confirmation about the upcoming interview with all the needed details about things to be discuss.

5.) Conduct the Interview After determining the people to interview, setting your objectives, and preparing the questions, you should develop a specific plan for meeting. When conducting the interview begin with introducing yourself, describe the project, and explaining your interview

objectives.

During the interview, ask questions in the order in which you prepared them, and give the interviewee sufficient time to provide

thoughtful answers. Your primary responsibility

during an interview is to listen carefully to the

answers. Analyst sometimes hear only what

they want to hear.

You must concentrate on what is said and notice any nonverbal communication that takes place. This process is called engaged

listening.

6.) Document Interview Although interview has taking both notes during an and

advantages

disadvantages, the accepted view is that note

taking should be kept to a minimum. Too much writing distracts the other person and makes it harder to establish a good rapport.

After conducting the interview, you must record the information quickly. Studies have shown that 50 percent of a conversation is forgotten within 30 minutes. You should use your notes to record the facts immediately so

you will not forget them.

7.) Evaluate the Interview In addition to recording the facts obtained in an interview, try to indentify any possible biases. For example, an interviewee who tries to protect his or her own area or function might

give incomplete answers or refrain from

volunteering information.

Other Fact-Finding Techniques

Judel Mangubat

Other Fact-Finding Techniques

In addition to interviewing, system analysts use other fact-finding techniques, including document review, observation, questionnaires and surveys, sampling, and research. Such techniques are used before interviewing begins to obtain good overview and to help develop better interview questions.

1. Document Review
This can help you understand how the current system is supposed work. You should obtain copies of actual forms and operating documents currently in use. You also should review blank copies of forms, as well as samples of actual completed forms.

2. Observation
Through observation, you might discover that neither the system documentation nor the interview statements are accurate.

2. Observation (Cont.)
Consider the following issues when you prepare your list: Ask sufficient questions to ensure that you have a complete understanding of the present operation. Observe all the steps in a transaction and note the documentations, inputs, outputs, and processes involved.

2. Observation (Cont.)
Examine each form, record, and report. Consider each user who works with the system and the following questions: 1. What information does the person receive from other people? 2. What information does this people generate? 3. How is the information communicated?

2. Observation (Cont.)
1. How is the information communicated? 2. How often do interruptions occur? 3. How much support does the user require, and who provides it? Talk to the people who receive current reports to see whether the reports are complete, timely, accurate, and a useful form.

3. Questionnaire and Survey

A questionnaire, also called a survey, is a document containing a number of standard questions that can be sent to many individuals.

Example of a Questionnaire

When designing questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding.
1. 2.

Keep the questionnaire brief and user-friendly. Provide clear instructions that will answer all anticipated questions.

3.

4.

5.

Arrange the questions in a logical order, going from simple to more complex topics. Phrase questions to avoid misunderstandings; use simple terms and wording. Try not to lead the response or use questions that give clues to expected answers.

6.

7.

8.

Limit the use of open-ended questions that are difficult to tabulate. Limit the use of questions that can raise concerns about the job security or other negative issues. Include a section at the end of the questionnaire for general comments.

9.

Test the questionnaire whenever possible on a small test group before finalizing it and distributing to a large group.

4. Sampling
When studying an information system, you should collect examples of actual document using a process called sampling.

The samples might include records, reports, operational logs, data entry documents, complaint summaries, work requests, and various types of forms. Sampling techniques include systematic sampling, stratified sampling, and random sampling.

5. Research
This is another important fact-finding technique. Your research can include the internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments.

Interviews versus Questionnaires

Interview
Unintrusive Long

Questionnaire
intrusive Time-consuming Impersonal

process Personal