Requirments Modeling

8/4/2019 Requirments Modeling

1/147


2/147

Introduction Case

Dilbert Cartoon

MS Project task


3/147


4/147

Typical RequirementsModeling Task list.


5/147

Systems Analysis Phase Overview

Objectives

Understand the Proposed project.

Ensure that it will support businessrequirements.

Build a solid foundation for systemdevelopment.


6/147

System Analysis ActivitiesFour Main Activities :

Requirements modeling

Data and Process Modeling Object modeling

Development strategies


7/147

RequirmentsModeling

Data andProcessModeling

ObjectModeling

DevelopmentStrategies

SystemAnalysis

Phase Tasks


8/147

Requirements Modeling

Fact Finding

Describe the current system andidentification of the requirements for thenew system, such as outputs, inputs,processes, performance and security.


9/147

Requirements ModelingOutputs

Refer to electronic or printed information

produced by the system.Inputs

Refer to necessary data that enters thesystem, either manually or in an

automated manner.


10/147

Requirements Modeling

Process

Refer to the logical rules that are applied

to transform the data into meaning.Perform

Refer to system characteristics such asspeed, volume, capacity, availability andreliability.


11/147

Requirements ModelingSecurity

Refer to hardware, software and

procedural controls that safeguard andprotect the system and its data frominternal or external threats.


12/147

Data And Process Modeling

Continuing the modeling process by learninghow to represent graphically system data andprocesses using traditional structured analysis

techniques.


13/147

Object Modeling

While structured analysis treats processes anddata as separate components, object-orientedanalysis (O-O) combines data and the process

that act on the data into things called objects.


14/147

Object Modeling

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


15/147

Development Strategies

Considering various development options andpreparing for the transition to the systemsdesign phase of the SDLC.
http://systems%20development%20life%20cycle.htm/http://systems%20development%20life%20cycle.htm/


16/147

Development Strategies

You will learn about:

Software trends

Acquisition and development alternatives

Outsourcing

Formally documenting requirements for thenew system.


17/147

System Analysis RequirementsDevelopment

It is the Deliverable, or end product , of thesystems analysis phase which is an overalldesign for the new system.


18/147

System Analysis RequirementsDevelopment

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


19/147

System Analysis Skills

Analytical skills

Enable you to identify a problem, evaluate thekey elements and develop a useful solution.


20/147


Interpersonal Skills

Especially valuable to a systems analyst whomust work with people at all organizational

levels, balance conflicting needs of users, andcommunicate effectively.


21/147


Because information systems affect peoplethroughout the company, you should considerteam-oriented strategies as you begin the

systems analysis phase.


22/147

Team Oriented Methods andTechniques

Greater user involvement usually results inbetter communication, faster developmenttimes and more satisfied users.


23/147

Team Oriented Methods andTechniques

Joint Application Development (JAD)

A popular fact Finding technique that bringsusers into the development process as active

participants.


24/147


User Involvement

Until recent years, the IT department usuallyhad sole responsibility for systems

development, and users had a relativelypassive role.


25/147


During Development process, the IT staffwould collect information from users, definesystem requirements and construct the new

system.


26/147


At various stages of the process, the IT staffmight ask users to review the design, offercomments, and submit changes.


27/147


Successful systems must be user-oriented, andusers need to be involved , formally orinformally, at every stage of system

development.


28/147


JAD team approachOne popular strategy for user involvement.


29/147

JAD Participants and Roles

A JAD team of users, managers, and ITprofessionals works together to identifyand document requirements for a newsystem

The OBJECTIVES is toanalyze the existingsystem, obtain user inputand expectations, anddocument user

requirements for the newsystem.


30/147


JAD Participants RoleJAD project leader Develops an agenda, acts as

a facilitator, and leads the

JAD session


31/147


Top management Provides enterprise-levelauthorization and support

for the project and

understanding of how the

project must supportbusiness functions and

requirements


32/147


Users Provide operational-levelinput on current

operations, desired changes

input and output

requirements, userinterface issues, and how

the project will support

day-to-day tasks


33/147


Systems analysts and otherIT staff members

Provides technicalassistance and resources

for JAD team members or

issues such as security,

backup, hardware,

software, and network

capability


34/147

Agenda for a JAD session

Recorder Documents results of JAD

sessions and works with

systems analysts to build

system models and develop

CASE tool documentation

JAD Participants Role
http://case.htm/http://case.htm/http://case.htm/http://case.htm/http://case.htm/


35/147


Project leader Introduce all JAD teamMembers

Discuss ground rules,

goals, and objectives for

the JAD sessions Explain methods of

documentation and use

of CASE tools, if any


36/147


Top management(sometimes

called the project owner or

sponsor)

Explain the reason for the

project and express top

management

authorization and support


37/147


Project leader

Provide overview of thecurrent system and

proposed project scope

and constraints

Present outline of specific

topics and issues to be

investigated


38/147


Open discussionsession, moderated by

project leader

Review the main businessprocesses, tasks, user roles,

inputs, and output.

Identify specific areas of

agreement or disagreement Break team into smaller

groups to study specific

issues and assign group

leaders


39/147


JAD team members working

in smaller group sessions,

supported by IT staff

Discuss and document all

system requirements

Develop models and

prototypes


40/147


Group leaders Report on result and

assigned tasks and topics

Present issues that

should be addressed by

the overall JAD team


41/147


Open discussion session,moderate by project leader

Review reports fromsmall group sessions

Reach consensus on main

issues

Document all topics


42/147


Project leader Present overall recap of

JAD session

Prepare report that will

be sent to JAD team

members


43/147

JAD Disadvantage

Compared with traditional methods, JAD ismore expensive and can be cumbersome if thegroup is too large relative to the size of theproject.


44/147

JAD Advantage

Many Companies find, however, that JADallows key users to participate effectively in therequirements modeling process.


45/147

JAD Advantage

Users are more likely to feel a sense ofownership in the results, and support for thenew system.


46/147

JAD Advantage

When properly used, JAD can result in a moreaccurate statement of system requirements, abetter understanding of common goals, and astronger commitment to the success of thenew system.


47/147

Rapid Application Development

A team-based technique that speeds upinformation systems development andproduces a functioning information system.


48/147


RAD Relies heavily on prototyping and userinvolvement. The RAD process allowsusers to examine a working model as earlyas possible, determine if it meets theirneeds, and suggest necessary changes.
http://rad.htm/http://rad.htm/http://rad.htm/http://rad.htm/


49/147

FourPhases ofRAD

Requirments

Planning

User Design

Cutover

Construction


50/147


Requirements Planning

Users, managers and IT staff agree uponbusiness needs, project scope and system

requirements Obtain approval to continue


51/147


User Design

Interact with users

Build models and prototypes

Conduct intensive JAD-type sessions


52/147


Construction

Program and application development

Coding

Unit, integration, and system testing


53/147


CUTOVER

Data conversion

Full-scale testing

System changeover User training


54/147

RAD Objectives

The main objective of all RAD approaches is tocut development time and expense by involvingusers in every phase of the systemsdevelopment.


55/147

RAD Disadvantage

RAD stresses the mechanics of the systemitself and does not emphasize the companysstrategic business needs.

Accelerated time cycle might allow less timeto develop quality, consistency, and designstandards.


56/147

RAD Advantage

System can be develop more quickly withsignificant cost savings.


57/147

Difference of JAD and RAD

Like JAD, RAD uses a group approach, butgoes much further.

While the end product of JAD is a

requirements model, the end product of RADis the new information system.

M d li T l d


58/147

Modeling Tools and

Techniques


59/147

Modeling Tools and Techniques

Modeling helps users, managers, ITprofessionals understand the design of a system.& involves graphical methods & non-technicallanguage that represent the system at variousstages of development. During modeling, you canuse various tools to describe business process,requirements, and user interaction with the system.


60/147

In Chapter 1 you learned that CASEtools can offer powerful modeling features.For example, the business modeling tutorialshown in Figure 3-8 provides a tool that ananalyst can use to document what thebusiness does, why those functions are, whocarries out the tasks, and how it is done.

Case Tools

Case Tools


61/147

Case Tools


62/147

Systems analysts use modeling and factfinding interactively.

first they build fact finding results into model

Then they study the models to determinewhether additional fact-finding is needed.

CASE Tools


63/147

To help them understand systemsrequirements, systems analysts often usefunctional decomposition diagrams, whichprovide a business-oriented overview, and the

Unified Modeling Language, which showshow people interact with the system.

Case Tools

FUNCTIONAL DECOMPOSITION


64/147

A functional decomposition diagram (FDD) is atop-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-levelfunctions and processes.

FUNCTIONAL DECOMPOSITIONDIAGRAMS



65/147


Creating an FDD is similar to drawing anorganizing chart

you start at the top and work your way down.

Figure 3-9 shows a four level FDD of a librarysystem drawn with the Visible Analysts CASEtool.



66/147

DIAGRAMS



67/147

DIAGRAMS

FDD can be used at several stages of systemsdevelopment.

During use FDDs to model business functions and showhow they are organized into lower-level processes.

Those processes translate into program modules duringmodules during application development.

DATA FLOW DIAGRAMS


68/147

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 theLibrary Management diagram in Figure 3-9.

DATA FLOW DIAGRAMS


69/147

DATA FLOW DIAGRAMS

DATA FLOW DIAGRAMS


70/147

DATA FLOW DIAGRAMS

Notice that the two shapes in the DFD representprocesses, each with various inputs andoutputs.

Additional levels of information and processmodeling is described in detail in Chapter 4.


71/147

UNIFIED MODELING LANGUAGE

The Unified Modeling Language (UML) is widelyused method of visualizing and documentingsoftware systems design.

UML uses object-oriented design concepts, but it is

independent of any specific programming languageand can be used to describe, business processesand requirements generally.


72/147

UNIFIED MODELING LANGUAGE

Use case diagrams, sequence diagrams, andother UML concepts are discussed in moredetail in Chapter 5, along with other object

each technique follows.


73/147

USE CASE DIAGRAMS

During requirements modeling, systemsanalysts and users work together to documentrequirements and model system functions.

A use case diagram visually representsthe interaction between users and theinformation system.


74/147

In a use case diagram, the userbecomes an actor, with a specific role thatdescribes how he/she interacts with thesystem. Systems analysts can draw use case

diagrams freehand or use CASE tools thatintegrate the use cases into the over-all systemdesign.

USE CASE DIAGRAMS


75/147

Figure 3-11 on the next page shows a simpleuse case diagram for a sales system where theactor is a customer & the use case involves a creditcard validation that is performed by system.

Because use cases depict the system through theeyes of a user, common business language can beused to describe the transactions..

USE CASE DIAGRAMS


76/147

For example, Figure 3-12 shows atable that documents the credit cardvalidation use case, and Figure 3-13 shows astudent records system, with several use

cases and actors.

USE CASE DIAGRAMS


77/147


78/147


79/147

SEQUENCE DIAGRAMS

A sequencediagram shows the timingof interactions between objects as they occur.A systems analysts might use a sequencediagram to show all possible outcomes, orfocus on a single scenario. Figure 3-14 showsa simple sequence diagram of a successfulcredit card validation.


80/147

SEQUENCE DIAGRAMS


81/147

The interaction proceeds from top to bottomalong a vertical timeline, while the horizontal arrowsrepresent messages from one object to another.

SEQUENCE DIAGRAMS

SYSTEM REQUIREMENTS


82/147

QCHECKLIST

During requirements modeling,systems developers must identify anddescribe all system requirements. A systemrequirement is a characteristic or feature

that must be included in an informationsystem to satisfy business requirements andbe acceptable to users.

SYSTEM REQUIREMENTS


83/147

SYSTEM REQUIREMENTSCHECKLIST

System requirements serve asbenchmarks to measure the overall acceptabilityof the finished systems.

System requirements fall into five generalcategories: outputs, processes, performance,and controls. Typical examples of systemrequirements for each category are listed below.


84/147

OUTPUT EXAMPLES

The Web site must report online volume statisticsevery four hours, and hourly during peak periods.

The inventory system must produce a dailyreport showing the part number, description,quantity on hand, quantity allocated, quantityavailable, and unit cost of all sorted by partnumber..

OUTPUT EXAMPLES


85/147

The contact management system mustgenerate a daily reminder list for all salesreps.

The purchasing system system mustprovide suppliers with up-to-datespecifications.

OUTPUT EXAMPLES


86/147

The customer analysis system mustproduce a quarterly report that identifieschanges in ordering patterns or trends

with statistical comparisons to theprevious four quarters.

OUTPUT EXAMPLES

INPUT EXAMPLE


87/147

INPUT EXAMPLE

Manufacturing employees mustswipe their ID cards into online datacollection terminals that record laborcosts and calculate production

efficiency. The department head must enterovertime hours on separate screen.


88/147

PROCESS EXAMPLES

The student records system must calculate theGPA 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 datarequired by the IRS.


89/147

PERFORMANCE EXAMPLES

The system must support 25 users onlinesimultaneously.

The accounts receivable system must

prepare customer statements by the thirdbusiness day of the following month.

CONTROL EXAMPLES


90/147

CONTROL EXAMPLES

The systems must provide log-onsecurity at the operating system leveland at the application level.

An employee record must be added,changed, or deleted only by a memberof the human resources department.

FUTURE GROWTH, COST, AND


91/147

FUTURE GROWTH, COST, ANDBENIFITS

In addition to the system requirements listedabove, systems analysts must consider scalability,which determines how a system will handle future

growth and demands, and the total cost ofownership, which includes all future operationaland support costs.


92/147

SCALABILITY

Scalability refers to a systemsability to handle increased businessvolume and transactions in the future.

Because it will have a longer useful life, ascalable system offers a better return onthe initial investment.


93/147

In addition to direct costs, systemsdevelopers must identify and document indirectexpenses that contribute to the total costs of

ownership (TCO).One problem is that cost estimates tend to

understate indirect costs such as user support anddowntime productivity losses.

TOTAL COST OWNERSHIP


94/147

Even if accurate figures areunavailable, systems analysts should try

to identify indirect costs and includethem in TCO estimates.

TOTAL COST OWNERSHIP


95/147

Fact-Finding

collecting of information by various


96/147

g y

techniques including:

- Interviews

-Document reviews

-Observation

-Surveys and Questionnaire

-Sampling & Research

Fact-Finding Overview


97/147

Fact Finding Overview

-What business functions are supported by thecurrent system?

-What strategic objectives and business

requirements must be supported by the newsystem?

-What are the benefits and TCO of theproposed system?

What transactions will the system process?


98/147

-What transactions will the system process?

-What information do users and managersneed from the system?

-Must the new system interface with legacysystems?

-What procedures could be eliminated by

business process reengineering?


99/147

-What security issues exist?

-What risks are acceptable?

-What budget and timetable constraints willaffect system development?

To obtain answer to this questions, you


100/147

develop a fact-finding plan which involveanother series of questions:

-Who? ,What? ,Where?, When?, How?

Or use a more structured approachsuch as the Zachman Framework to beexplained later.

Either way, you will develop a:


101/147

-Strategy

-Carry out fact-finding techniques

-Document the results and

-Prepare a system requirements documents tobe presented to the management.

Who?


102/147

Who performs each of the procedures within the

system?

What?

What is being done? What procedures arebeing followed?

Where?


103/147

e e

Where are the operations being performed?

When?

When is a procedure performed? Why is itbeing performed this time? Is this the besttime?


104/147

How?

How is the procedure performed?


105/147

There is a difference between asking what isbeing done and what could or should be

done. The system analyst first must understandthe situation. Only then can he she tackle thequestion of what shouldbe done.

Z h F k


106/147

Zachman Framework

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

-Is a interface that allows users to view asystems project from different perspective andlevel of detail.


107/147

I t i


108/147

Interview

Is a common fact-finding technique. An interviewis a planned meeting during which you obtaininformation from another person.

An interviewer must have the skills needed toplan, conduct, and document interviewssuccessfully.

T pes of inter ie


109/147

Types of interview:

-Screening interview

-First interview (maybe the only one)

-Panel interview

-Technical interview

-Video conference

7 interviewing process:


110/147

7 interviewing process:

1.) Determine the People to Interview

You must select the right people to

interview and ask them the right questions.


111/147

2.) Establish Objectives for the Interview

Determine the general areas to bediscussed, and then list the facts you want togather. You can also solicit ideas, suggestion,

and opinions during interview.


112/147

2.) Establish Objectives for the Interview

Determine the general areas to bediscussed, and then list the facts you want togather. You can also solicit ideas, suggestion,

and opinions during interview.


113/147

3.) Develop Interview Question


114/147

Creating a standard list of interviewquestion helps to keep you on track and avoidunnecessary tangents. It should consist ofseveral different kinds of question: open-ended, close-ended and questions with a

range of responses. When you phrase yourquestions you should avoid leadingquestions that suggest or favor a particularreply.

ex. What advantages do you see in the


115/147

g yproposed system? instead Do you see anyadvantages in the proposed system.

Open-ended questions:


116/147

p q

Encourage spontaneous andunstructured responses.

Ex. What are users saying about the newsystem?

Open-ended questions:


117/147

Encourage spontaneous andunstructured responses.

Ex. What are users saying about the new

system?

Closed-ended Questions:


118/147

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:


119/147

Is a closed-ended question that ask the

person to evaluate something by providinglimited answers to specific responses or on anumeric scale.

Ex. On a scale of 1 to 10, with 1 the lowest and10 h hi h h ff i i i


120/147

10 the highest, how effective was your training.

4.) Prepare for the Interview


121/147

Careful preparations is essentialbecause an interview is an important meetingand not just a casual chat . When youschedule a interview suggest a specific day

and time and let the interviewee know howlong it will last.

Remember that the interview is an

interruption of the other persons routine so


122/147

interruption of the other persons routine, soyou should limit the interview to no more than

one hour.

Remember to keep department managers

informed of your meetings with their staff.


123/147

Also have a letter of confirmation about


124/147

Also have a letter of confirmation aboutthe upcoming interview with all the needed

details about things to be discuss.


125/147

5.) Conduct the Interview


126/147

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


127/147

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


128/147

notice any nonverbal communication that takes

place. This process is called engaged

listening.

6.) Document Interview

Although taking notes during an


129/147

Although taking notes during an

interview has both advantages anddisadvantages, 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


130/147

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


131/147

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-FindingTechniques


132/147

Judel Mangubat

Techniques

In addition to interviewing system analysts use

Other Fact-Finding Techniques


133/147

In addition to interviewing, system analysts useother fact-finding techniques, including document

review, observation, questionnaires and surveys,sampling, and research. Such techniques are usedbefore interviewing begins to obtain good overviewand to help develop better interview questions.

Thi h l d t d h th t

1. Document Review


134/147

This can help you understand how the currentsystem is supposed work.

You should obtain copies of actual forms andoperating documents currently in use.

You also should review blank copies of forms, aswell as samples of actual completed forms.

Through observation, you might discover that neitherthe system documentation nor the interview statements

are accurate.

2. Observation

2. Observation (Cont.)


135/147

Consider the following issues when you prepare

your list:

Ask sufficient questions to ensure that you have acomplete understanding of the present operation.Observe all the steps in a transaction and note the

documentations, inputs, outputs, and processesinvolved.



136/147

Examine each form, record, and report.Consider each user who works with the systemand 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?



137/147

1. How is the information communicated?

2. How often do interruptions occur?3. How much support does the user require, andwho provides it?

Talk to the people who receive current reports tosee whether the reports are complete, timely,

accurate, and a useful form.

3. Questionnaire and Survey


138/147

y

A questionnaire, also called a survey, is adocument containing a number of standardquestions that can be sent to many individuals.

Example of a Questionnaire


139/147

When designing questionnaire, the most importantl f ll i k h i


140/147

rule of all is to make sure that your questionscollect the right data in a form that you can use tofurther your fact-finding.

1. Keep the questionnaire brief and user-friendly.

2. Provide clear instructions that will answer allanticipated questions.

3. Arrange the questions in a logical order, going


141/147

g q g , g gfrom simple to more complex topics.

4. Phrase questions to avoid misunderstandings;use simple terms and wording.

5. Try not to lead the response or use questionsthat give clues to expected answers.

6. Limit the use of open-ended questions that aredifficult to tabulate.


142/147

7. Limit the use of questions that can raise

concerns about the job security or othernegative issues.

8. Include a section at the end of the questionnairefor general comments.

9. Test the questionnaire whenever possible on asmall test group before finalizing it and


143/147

distributing to a large group.

4. Sampling

When studying an information system you should


144/147

When studying an information system, you shouldcollect examples of actual document using a

process called sampling.

The samples might include records, reports,operational logs, data entry documents, complaintsummaries work requests and various types of


145/147

summaries, work requests, and various types offorms.

Sampling techniques include systematic sampling,stratified sampling, and random sampling.

5. Research


146/147

This is another important fact-finding technique.Your research can include the internet, ITmagazines, and books to obtain backgroundinformation, technical material, and news aboutindustry trends and developments.

Interview Questionnaire

Interviews versus Questionnaires


147/147

Unintrusive

Long processPersonal

intrusive

Time-consumingImpersonal