0% found this document useful (0 votes)
3 views

Lec5 - System Diagrams

The document outlines the systems analysis phase, focusing on activities such as requirements modeling, data and process modeling, and the use of various methodologies like JAD, RAD, and agile methods. It discusses the importance of modeling tools like functional decomposition diagrams and UML in understanding system requirements, as well as the need for effective fact-finding techniques. Additionally, it highlights the significance of scalability and total cost of ownership in system development.

Uploaded by

nadi59032
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

Lec5 - System Diagrams

The document outlines the systems analysis phase, focusing on activities such as requirements modeling, data and process modeling, and the use of various methodologies like JAD, RAD, and agile methods. It discusses the importance of modeling tools like functional decomposition diagrams and UML in understanding system requirements, as well as the need for effective fact-finding techniques. Additionally, it highlights the significance of scalability and total cost of ownership in system development.

Uploaded by

nadi59032
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 42

System Analysis and Process

Integration
BAem 414
System Diagrams
Learning Objectives
• Describe systems analysis phase activities

• Explain joint application development (JAD), rapid application development (RAD), and agile methods

• Use a functional decomposition diagram (FDD) to model business functions and processes

• Describe the Unified Modeling Language (UML) and create examples of UML diagrams

• List and describe system requirements, including outputs, inputs, processes, performance, and controls

• Explain the concept of scalability

• Use fact-finding techniques, including interviews, documentation review, observation, questionnaires,


sampling, and research

• Define total cost of ownership (TCO)

• Conduct a successful interview

• Develop effective documentation methods to use during systems development


Introduction
Systems Analysis Phase Overview
Involves fact-finding to
• The overall objective of the systems analysis
describe phase is system
the current to understand the proposed
project, ensure that it will support business requirements,
and identification of the and build a solid
foundation for system development
requirements for the new
While structured
system, suchanalysis treats
as outputs,
Shows how to represent
processes
• In this phase, the analyst uses andprocesses,
inputs,
models data as separate
and other documentation tools to visualize and
graphically system data
components, object-oriented
performance, (O-O)
and security.
describe the proposed system and processes using
analysis combines data and the
traditional structured
processes
• Systems Analysis Activities: that act on the data into
analysis techniques
things called objects.considers various development
• Requirements modeling options and prepares for the
transition to the systems design
• Data and process modeling phase of the SDLC
• Object modeling
• Consideration of development strategies
Systems Analysis Skills

• A systems analyst needs strong analytical and interpersonal skills to build an


accurate model of the new system
• Analytical skills enable the analyst to identify a problem, evaluate the key
elements, and develop a useful solution.
• Interpersonal skills are especially valuable to a systems analyst who must
work with people at all organizational levels, balance conflicting needs of
users, and communicate effectively.

• Because information systems affect people throughout the company, team-


oriented strategies should be considered at the start of the systems analysis
phase
Joint Application Development

• Joint application development (JAD) is a popular fact-finding technique that


brings users into the development process as active participants
JAD PARTICIPANT ROLE
ROLE
JAD project leader Develops an agenda, acts as a facilitator, and leads the JAD session
Top management Provides enterprise-level authorization and support for the project
Managers Provide department-level support for the project and understanding of
how the project must support business functions and requirements
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
Systems analysts Provide technical assistance and resources for JAD team members on
and other IT staff issues such as security, backup, hardware, software, and network
members Capability
Recorder issues such as security, backup, hardware, software, and network
capability
JAD Advantages and Disadvantages

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

• When users participate in the systems development process, they are more
likely to feel a sense of ownership in the results and support for the new
system.
• 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

• Rapid application development (RAD) is a team-based technique

• While the end product of JAD is a requirements model, the end product of
RAD is the new information system.
• RAD is a complete methodology, with a four-phase life cycle that parallels
the traditional SDLC phases
• RAD relies heavily on prototyping and user involvement

• The project team uses CASE tools to build the prototypes and

• create a continuous stream of documentation


RAD Phases and Activities
RAD Advantages and Disadvantages

• The primary advantage is that systems can be developed more quickly with
significant cost savings.

• RAD stresses the mechanics of the system itself and does not emphasize the
company’s strategic business needs
• The risk is that a system might work well in the short term, but the corporate
and long-term objectives for the system might not be met.
• Another potential disadvantage is that the accelerated time cycle might allow
less time to develop quality, consistency, and design standards.
Agile Methods

• agile methods attempt to develop a system incrementally, by building a series of


prototypes and constantly adjusting them to user requirements.
• An agile approach emphasizes continuous
feedback, and each incremental step is affected
by what was learned in the prior steps.
• Many agile developers prefer not to use CASE
tools at all and rely instead on whiteboard
displays and arrangements of movable sticky
notes.
Scrum Agile Method

• The name comes from the rugby term scrum, where team members lunge at
each other to achieve their objectives.
• In the Scrum session, agile team members play different roles between
opponents and supporters. Some members (owner, facilitator, and
development team) take opponent roles, while others (users and other
beneficiaries) play supporter roles.
• However, the first part declines, because that role would require a total
commitment, while for the second, it would only be a contribution.
• Scrum sessions have specific guidelines that emphasize time blocks,
interaction, and team-based activities that result in deliverable software.
• An agile team uses a series of scrums to pause the action and allow the
Agile Method Advantages and
Disadvantages
• Agile, or adaptive, methods are very flexible and efficient in dealing with change.

• They are popular because they stress team interaction and reflect a set of
community-based values.
• Also, frequent deliverables constantly validate the project and reduce risk.

• Team members need a high level of technical and interpersonal skills.

• Also, a lack of structure and documentation can introduce risk factors, such as
blurring of roles and responsibilities, and loss of corporate knowledge.
• Finally, the overall project may be subject to significant change in scope as user
requirements continue to evolve during the project.
Modeling Tools And Techniques

• Modeling involves graphical methods and nontechnical language that


represent the system at various stages of development.
• Systems analysts use modeling and fact-finding interactively.
• First, they build fact-finding results into models
• Then they study the models to determine whether additional fact-finding
is needed.
• To help them understand system requirements, analysts use functional
decomposition diagrams, business process models, data flow diagrams, and
Unified Modeling Language diagrams.
Functional Decomposition Diagrams

• A functional decomposition diagram


(FDD) is a top-down representation
of a function or process.
• Using an FDD, an analyst can show
business functions and break them
down into lower-level functions and
processes.
• During requirements modeling,
analysts use FDDs to model business
functions and show how they are
organized into lower-level processes
Business Process Modeling

• A business process model (BPM)


represents one or more business processes
• During requirements modeling, analysts
often create models that use a standard
language called business process modeling
notation (BPMN).
• BPMN includes various shapes and
symbols to represent events, processes,
and workflows.
• Integrating BPM into the CASE
development process leads to faster
results, fewer errors, and reduced cost
Data Flow Diagrams

• Working from a functional


decomposition diagram, analysts can
create data flow diagrams (DFDs) to
show how the system stores, processes,
and transforms data.
• Additional levels of information and
detail are depicted in other, related
DFDs.
Unified Modeling Language

• The Unified Modeling Language (UML) is a 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.
• UML provides various graphical tools, such as use case diagrams and sequence
diagrams. During requirements modeling, a systems analyst can utilize the UML
to represent the information system from a user’s viewpoint.
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 Name of Use Case: Credit card validation process
information system Actor: Customer

• In a use case diagram, the user becomes Description: Describes the credit card validation
process
an actor, with a specific role that Successful ………………
describes how he or she interacts with Completion:
the system. Systems analysts can draw Alternative: ………………

use case diagrams freehand or use CASE Precondition: ………………

tools that integrate the use cases into the Postcondition: ………………
Sequence Diagram

• A sequence diagram shows the timing


of interactions between objects as they
occur.
• A systems analyst might use a sequence
diagram to show all possible outcomes
or focus on a single scenario.
• 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 serve as benchmarks to measure the overall acceptability
of the finished system.
• System requirements fall into five general categories: outputs, inputs, processes,
performance, and controls.
Output Examples

• The website 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.
• The contact management system must generate a daily reminder list for all sales reps.
• The purchasing system must provide suppliers with up-to-date specifications. The sales
tracking system must produce a daily fast-moving-item report, listing all products that
exceed the forecasted sales volume grouped by style, color, size, and reorder status.
• 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 Examples

• 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.
• Student grades must be entered on machine-readable forms prepared by the
instructor.
• Each input form must include date, time, product code, customer number, and
quantity.
• Data entry screens must be uniform, except for background color, which can
be changed by the user.
• A data entry person at the medical group must input patient services into the
billing system.
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 produce tax data required by the IRS.
• The warehouse distribution system must analyze daily orders and create a routing
pattern for delivery trucks that maximizes efficiency and reduces unnecessary mileage.
• The human resources system must interface properly with the existing payroll system.
• The equipment rental system must not execute new rental transactions for customers
who have overdue accounts.
• The prescription system must automatically generate an insurance claim form.
Performance Examples

• The system must support 25 users online simultaneously.

• Response time must not exceed four seconds.

• The system must be operational seven days a week, 365 days a year.

• The accounts receivable system must prepare customer statements by the


third business day of the following month.
• The student records system must produce class lists within five hours after
the end of registration.
• The online inventory control system must flag all low-stock items within one
hour after the quantity falls below a predetermined minimum.
Control Examples
• The system must provide logon 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.
• The system must maintain separate levels of security for users and the system
administrator.
• All transactions must have audit trails.

• The manager of the sales department must approve orders that exceed a
customer’s credit limit.
• The system must create an error log file that includes the error type,
description, and time.
Future Growth, Costs, And Benefits

• In addition to the system requirements, 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 refers to a system’s 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 of Ownership. systems developers must identify and document
indirect expenses that contribute to the total cost of ownership (TCO).
Fact-finding
• 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?
Who, What, Where, When, How, and
Why?
Fact-finding involves answers to five familiar questions: who, what, where, when,
and how.
CURRENT SYSTEM PROPOSED SYSTEM
Who does it? Why does this person do Who should do it?
it?
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 then? When should it be done?
How is it done? Why is it done this way? How should it be done?

The table lists the basic questions and when they should be asked.

Notice that the first two columns relate to the current system, but the third column
focuses on the proposed system.
Interviews

• An interview is a planned meeting during which the analyst obtains information


from another person. The skills needed to plan, conduct, document, and evaluate
interviews successfully must be understood.
• An interview is a planned meeting during which the analyst obtains information
from another person.

1. Determine the people to interview. 5. Conduct the interview.

2. Establish objectives for the interview. 6. Document the interview.

3. Develop interview questions. 7. Evaluate the interview.

4. Prepare for the interview.


Other Fact-finding Techniques

• Document Review

• Observation

• Questionnaires and Surveys

• Brainstorming

• Sampling

• Research
Document Review

• Document review can help the analyst understand how the current system is
supposed to work
• Remember that system documentation sometimes is out of date. Forms can
change or be discontinued, and documented procedures often are modified or
eliminated.
• It is prudent to obtain copies of actual forms and operating documents currently
in use, and to review blank copies of forms, as well as samples of actual
completed forms.
Observation
• Plan observations in advance by preparing a checklist of specific tasks to observe and questions to ask.
• Ask sufficient questions to ensure a complete understanding of the present system operation.
• Observe all the steps in a transaction and note the documents, inputs, outputs, and processes
involved.
• Examine each form, record, and report. Determine the purpose each item of information serves.
• Consider each user who works with the system and the following questions:
• What information does that person receive from other people?
• What information does this person generate?
• How is the information communicated?
• How often do interruptions occur?
• How much downtime occurs?
• 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,
Questionnaires and Surveys

• In projects where it is desirable to obtain input from a large number of people, a


questionnaire can be a valuable tool.
• Questionnaires can be used to obtain information about a wide range of topics,
including workloads, reports received, volumes of transactions handled, job
duties, difficulties, and opinions of how the job could be performed better or
more efficiently.
• When designing a questionnaire, the most important rule of all is to make sure
that the questions collect the right data in a form that can be used to further the
factfinding effort.
Questionnaires and Surveys – cont.
• Keep the questionnaire brief and user-friendly.
• Provide clear instructions that will answer all anticipated questions.
• 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.
• Limit the use of open-ended questions that are difficult to tabulate.
• Limit the use of questions that can raise concerns about job security or other negative issues.
• Include a section at the end of the questionnaire for general comments.
• Test the questionnaire whenever possible on a small test group before finalizing it and
distributing to a large group.
Interviews Versus Questionnaires

• The interview is more familiar and personal than a questionnaire.

• During a face-to-face interview, the interviewer can react immediately to anything


the interviewee says.
• During a personal interview, the analyst can watch for clues to help determine if
responses are knowledgeable and unbiased.
• Interviewing, however, is a costly and time-consuming process.

• A questionnaire gives many people the opportunity to provide input and


suggestions.
Brainstorming

• Brainstorming refers to a small group discussion of a specific problem,


opportunity, or issue.
• This technique encourages new ideas, allows team participation, and enables
participants to build on each other’s inputs and thoughts.
• Brainstorming can be structured or unstructured.
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.
• The main objective of a sample is to ensure that it represents the overall
population accurately.
• To be useful, a sample must be large enough to provide a fair representation of
the overall data.
Research

• Research can include the Internet, IT magazines, and books to obtain background
information, technical material, and news about industry trends and
developments.
• In addition, attending professional meetings, seminars, and discussions with other
IT professionals can be very helpful in problem solving.
• Online forums and newsgroups are good resources for exchanging information
with other professionals, seeking answers to questions, and monitoring discussions
that are of mutual interest.
DOCUMENTATION

• An analyst should document their work according to the following principles:


• Record information as soon as it is obtained.
• Use the simplest recording method possible.
• Record findings in such a way that someone else can understand them.
• Organize documentation so related material is located easily.

• Many software programs are available to help record and document information:
• CASE TOOLS, PRODUCTIVITY SOFTWARE, GRAPHIC MODELING SOFTWARE
Preview Of Logical Modeling

• At the conclusion of requirements modeling, systems developers should have a


clear understanding of business processes and system requirements.
• The next step is to construct a logical model of the system.
• Structured analysis is a popular, traditional technique that describes the
system in terms of data and the processes that act on that data.
• Object modeling is a methodology that combines data and processes into
things called objects that represent actual people, things, transactions, and
events.
• By studying both structured analysis and object-oriented methods, valuable
knowledge, skills, and perspective can be gained.
Q/A

You might also like