requirements modeling

50
Systems Analysis & Design Requirements Modeling

Upload: nixie

Post on 16-Jan-2016

68 views

Category:

Documents


0 download

DESCRIPTION

Requirements Modeling. Phase Description. Systems analysis is the second of five phases in the systems development life cycle (SDLC) Uses requirements modeling and data and process modeling to represent the new system - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Requirements Modeling

Systems Analysis & Design

Requirements Modeling

Page 2: Requirements Modeling

2222

Phase Description

● Systems analysis is the second of five phases in the systems development life cycle (SDLC)

● Uses requirements modeling and data and process modeling to represent the new system

● Before proceeding to the next phase, systems design, you will consider system development strategies

Page 3: Requirements Modeling

3333

Systems Analysis Phase Overview

● The overall objective is to understand the proposed project, ensure that it will support business requirements, and build a solid foundation for system development

● You use models and other documentation tools to visualize and describe the proposed system

Page 4: Requirements Modeling

4444

Systems Analysis Phase Overview

● Systems Analysis Activities– Requirements modeling

• Outputs• Inputs• Processes• Performance• Security

– Data and process modeling

Page 5: Requirements Modeling

5555

Systems Analysis Phase Overview

● Systems Analysis Activities – Development

Strategies• System

requirements document

Page 6: Requirements Modeling

6666

Systems Analysis Phase Overview

● Systems Analysis Skills– Analytical skills– Interpersonal skills

● Team-Oriented Methods and Techniques– Joint application development (JAD)

Page 7: Requirements Modeling

7777

Fact-Finding

● Fact-Finding Overview– The first step is to identify the information

you need

● Who, What, Where, When, How, and Why?– Difference between asking what is being

done and what could or should be done

Page 8: Requirements Modeling

8888

Performing Requirements Determination

● Gather information on what system should do from many sources– Users– Reports– Forms– Procedures

Page 9: Requirements Modeling

9999

Performing Requirements Determination

● Characteristics for gathering requirements– Question everything– Impartiality

• Find the best organizational solution

– Relaxation of constraints– Attention to detail– Reframing

• View the organization in new ways

Page 10: Requirements Modeling

10101010

Deliverables and Outcomes

● Types of deliverables:– Information collected from users– Existing documents and files– Computer-based information– Understanding of organizational

components• Business objective• Information needs• Rules of data processing• Key events

Page 11: Requirements Modeling

11111111

Interviews

● Systems analysts spend a great deal of time talking with people

● Much of that time is spent conducting interviews

Page 12: Requirements Modeling

12121212

Traditional Methods for Determining Requirements

● Interviewing and Listening– Gather facts, opinions and speculations– Observe body language and emotions– Guidelines

• PlanChecklistAppointment

• Be neutral• Listen• Seek a diverse view

Page 13: Requirements Modeling

13131313

Traditional Methods for Determining Requirements

● Interviewing (Continued)– Interview Questions

• Open-EndedNo pre-specified answers

• Close-EndedRespondent is asked to choose from a set of

specified responses

– Additional Guidelines• Do not phrase questions in ways that imply a

wrong or right answer• Listen very carefully to what is being said• Type up notes within 48 hours• Do not set expectations about the new system

Page 14: Requirements Modeling

14141414

Interview

● Step 1: Determine the People to Interview– Informal structure

● Step 2: Establish Objectives for the Interview– Determine the general areas to be

discussed– List the facts you want to gather

Page 15: Requirements Modeling

15151515

Interviews

● Step 3: Develop Interview Questions– Creating a standard list of interview

questions helps to keep you on track and avoid unnecessary tangents

– Avoid leading questions– Open-ended questions– Closed-ended questions– Range-of-response questions

Page 16: Requirements Modeling

16161616

Interviews

● Step 4: Prepare for the Interview– Careful preparation is essential because

an interview is an important meeting and not just a casual chat

– Limit the interview to no more than one hour

– Send a list of topics– Ask the interviewee to have samples

available

Page 17: Requirements Modeling

17171717

Interviews

● Step 5: Conduct the Interview– Develop a specific plan for the meeting– Begin by introducing yourself, describing

the project, and explaining interview objectives

– Use engaged listening– Allow the person enough time to think

about the question– Summarize main points– After interview, summarize the session

and seek a confirmation

Page 18: Requirements Modeling

18181818

Interviews

● Step 6: Document the Interview– During the interview, note taking should

be kept to a minimum– After the interview, record the information

quickly– After the interview, send memo

expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections

Page 19: Requirements Modeling

19191919

Interviews

● Step 7: Evaluate the Interview– In addition to recording the facts obtained

in an interview, try to identify any possible biases

● Unsuccessful Interviews– No matter how well you prepare for

interviews, some are not successful

Page 20: Requirements Modeling

20202020

CASE IN POINT 3.2: Deep River CollegeDeep River College is a two-year school in Southern California. Twice a year, the fund-raising office at Deep River mails requests for donations to the alumni. The staff uses a word processing program and a personal information database to create personalized letters., Data on past contributions and other alumni information, however, is stored manually. The dean, Alexandra Ali, recently submitted a systems request asking the college’s IT department to develop a computerized alumni information system. The school does not have a formal systems review committee, and each department has an individual budget for information services.

Eddie Bateman, a systems analyst, performed a preliminary investigation and he concluded that the system met all the feasibility tests. After reading his report, Alexandra asked him to proceed with the systems analysis phase. Eddie has scheduled an interview with her, and he asked you to help him prepare for the meeting. Specifically, he wants you to list all the topics he should cover during the interview. Eddie also wants you to prepare a list of specific questions that he should ask. Be sure to include open-ended, closed-ended, and range-of-response questions.

Page 21: Requirements Modeling

21212121

CASE IN POINT 3.3: FastPak Overnight Package System

● FastPak, the nation’s fourth-largest overnight package system, is headquartered in Los Angeles, California. Jesse Evans is a systems analyst on an IT team that is studying ways to update FastPak’s package tracking system. Jesse prepared well for her interview with Jason Tanya, FastPak’s executive vice president. Mr. Tanya did not ask his assistant to hold his calls during the meeting, however. After several interruptions, Jesse tactfully suggested that she could come back another time, or perhaps that Mr. Tanya might ask his assistant to hold his calls. “No way,” he replied. “I’m a very busy man and we’ll just have to fit this in as we can, even if it takes all day.” Jesse was unprepared for his response. What are her options? Is an analyst always in control of this kind of situation? Why or why not?

Page 22: Requirements Modeling

22222222

Traditional Methods for Determining Requirements

● Administering Questionnaires– More cost-effective than interviews– Choosing respondents

• Should be representative of all users• Types of samples

ConvenientRandom samplePurposeful sampleStratified sample

Page 23: Requirements Modeling

23232323

Traditional Methods for Determining Requirements

● Questionnaires– Design

• Mostly closed-ended questions• Can be administered over the phone or in

person

– Vs. Interviews• Interviews cost more but yield more information• Questionnaires are more cost-effective

Page 24: Requirements Modeling

24242424

Traditional Methods for Determining Requirements

● Interviewing Groups– Advantages

• More effective use of time• Enables people to hear opinions of others and

to agree or disagree

– Disadvantages• Difficulty in scheduling

– Nominal Group Technique• Facilitated process to support idea generation

by groups• Individuals work alone to generate ideas which

are pooled under guidance of a trained facilitator

Page 25: Requirements Modeling

25252525

Traditional Methods for Determining Requirements

● Directly Observing Users– Serves as a good method to supplement

interviews– Often difficult to obtain unbiased data

• Hawthorne EffectPeople often work differently when being observed

Page 26: Requirements Modeling

26262626

Analyzing Procedures and Other Documents

● Types of information to be discovered:– Problems with existing system– Opportunity to meet new need– Organizational direction– Names of key individuals– Values of organization– Special information processing

circumstances– Reasons for current system design– Rules for processing data

Page 27: Requirements Modeling

27272727

Analyzing Procedures and Other Documents

● Four types of useful documents– Written work procedures

• Describes how a job is performed• Includes data and information used and created

in the process of performing the job or task

– Business form• Explicitly indicate data flow in or out of a

system

– Report • Enables the analyst to work backwards from the

report to the data that generated it

– Description of current information system

Page 28: Requirements Modeling

28282828

Modeling Tools and Techniques

● CASE Tools– Offer powerful modeling features– Systems analysts use modeling and fact-

finding interactively

● Functional Decomposition Diagrams– Functional decomposition diagram (FDD)

Page 29: Requirements Modeling

29292929

Modeling Tools and Techniques

● Unified Modeling Language– Provides various graphical tools – Use case diagrams

• Actor

– Sequence diagrams

Page 30: Requirements Modeling

30303030

What is UML?

● UML stands for Unified Modeling Language

● The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system

● It can be used with all processes, throughout the development life cycle, and across different implementation technologies

Page 31: Requirements Modeling

31313131

Modern Methods for Determining Requirements

● Joint Application Design (JAD)– Brings together key users, managers and systems

analysts– Purpose: collect system requirements

simultaneously from key people– Conducted off-site

● Prototyping– Repetitive process– Rudimentary version of system is built– Replaces or augments SDLC– Goal: to develop concrete specifications for

ultimate system

Page 32: Requirements Modeling

32323232

CASE IN POINT 3.1: North Hills Consulting

Suppose you were employed as a summer intern by North Hills Consulting, which offers a wide range of IT services to clients. North Hills has a Web site that describes the firm and the services it offers. The site includes a monthly feature called “Hot Topic,” which reviews current IT trends and developments.

Yesterday, Jane Hall, your supervisor, mentioned that next month’s topic would be JAD and RAD, and she asked you to write a draft of the Hot Topic article. Specifically, she wants you to go online and locate at least three references that would be of interest to readers who want to learn more about JAD or RAD. When you have completed your research, she wants you to write a summary of your findings.

http://www.credata.com/research/methodology.html

Page 33: Requirements Modeling

33333333

Joint Application Design (JAD)

● Participants– Session Leader– Users– Managers– Sponsor– Systems Analysts– Scribe– IS Staff

Page 34: Requirements Modeling

34343434

Joint Application Design (JAD)

● End Result– Documentation detailing existing system– Features of proposed system

● CASE Tools During JAD– Upper CASE tools are used – Enables analysts to enter system models

directly into CASE during the JAD session– Screen designs and prototyping can be

done during JAD and shown to users

Page 35: Requirements Modeling

35353535

Joint Application Design (JAD)

● Supporting JAD with GSS– Group support systems (GSS) can be used

to enable more participation by group members in JAD

– Members type their answers into the computer

– All members of the group see what other members have been typing

Page 36: Requirements Modeling

36363636

Joint Application Development

● JAD Advantages and Disadvantages– Advantages

• Allows key users to participate effectively • 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

– Disadvantages• More expensive and can be cumbersome if

the group is too large relative to the size of the project

Page 37: Requirements Modeling

37373737

Prototyping● Quickly converts requirements to

working version of system● Once the user sees requirements

converted to system, will ask for modifications or will generate additional requests

● Most useful when:– User requests are not clear– Few users are involved in the system– Designs are complex and require concrete form– History of communication problems between

analysts and users– Tools are readily available to build prototype

Page 38: Requirements Modeling

38383838

Prototyping

● Drawbacks– Tendency to avoid formal documentation– Difficult to adapt to more general user

audience– Sharing data with other systems is often

not considered– Systems Development Life Cycle (SDLC)

checks are often bypassed

Page 39: Requirements Modeling

39393939

System Requirements Checklist

● Five general categories– Outputs– Inputs– Processes– Performance– Controls

Page 40: Requirements Modeling

40404040

System Requirements Checklist

● Outputs– 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 parts — sorted by part number

Page 41: Requirements Modeling

41414141

System Requirements Checklist

● Inputs– 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 a separate screen

Page 42: Requirements Modeling

42424242

System Requirements Checklist

● Processes– 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 produce tax data required by the IRS

Page 43: Requirements Modeling

43434343

System Requirements Checklist

● Performance– The system must support 25 users online

simultaneously– Response time must not exceed four

seconds

Page 44: Requirements Modeling

44444444

System Requirements Checklist

● Controls– The system 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

Page 45: Requirements Modeling

45454545

Future Growth, Costs, and Benefits

● Scalability– A scalable system offers a better return on

the initial investment– To evaluate, you need information about

projected future volume for all outputs, inputs, and processes

Page 46: Requirements Modeling

46464646

Future Growth, Costs, and Benefits

● Total Cost of Ownership– Total cost of ownership (TCO) is especially

important if the development team is evaluating several alternatives

– One problem is that cost estimates tend to understate indirect costs

– Rapid Economic Justification (REJ)

Page 47: Requirements Modeling

47474747

Documentation

● The Need for Recording the Facts– Record information as soon as you obtain

it– Use the simplest recording method– Record your findings in such a way that

they can be understood by someone else– Organize your documentation

Page 48: Requirements Modeling

48484848

Documentation

● Software Tools– CASE Tools– Productivity Software

• Word processing, spreadsheets, database management, presentation graphics, histogram

Page 49: Requirements Modeling

49494949

Documentation

● Software Tools– Graphics modeling software– Personal information managers

• Personal information manager (PIM)• Handheld computers• Personal digital assistants (PDAs)

– Wireless communication devices

Page 50: Requirements Modeling

50505050

Preview of Data and Process Modeling

● At the conclusion of requirements modeling, systems developers should have clear understanding of business processes and system requirements

● The next step is to construct a logical design of the system

● The systems analysis phase includes three activities: requirements modeling, data and process modeling, and consideration of development strategies