Revision Slides

Introduction to IS and
the role of the analyst

Topic 1
Systems Analysis and Design in a Changing World, 7th Edition - Online Chapter A
©2016. Cengage Learning. All rights reserved.
People today are attracted to information systems
careers because information technology (IT) can
have a dramatic impact on productivity and profits
It is the people who develop information system
solutions that harness the power of the technology
that makes these benefits possible
The key to successful system development is
thorough systems analysis and design to understand
what the business requires from the information
system
Systems analysis – the process of understanding and
specifying in detail what the information system should
accomplish
Systems design – the process of specifying in detail how
the many components of the information system should
be physically implemented
Systems analyst –a business professional who uses
analysis and design techniques to solve business problems
by using information technology
This text is about the tools and techniques used by a
systems analyst to develop information systems
YouTube Video
https://www.youtube.com/watch?v=M14kFg88Vk0
Customers want to order products any time of the day or
night. So, the problem is how to process those orders around
the clock without adding to the selling cost.
Production needs to plan very carefully the amount of each
type of product to produce each week. So, the problem is
how to estimate the dozens of parameters that affect
production and then allow planners to explore different
scenarios before committing to a specific plan.
Suppliers want to minimize their inventory holding costs by
shipping parts used in the manufacturing process in smaller
daily batches. So, the problem is how to order in smaller lots
and accept daily shipments to take advantage of supplier
discounts.
Marketing wants to better anticipate customer needs by
tracking purchasing patterns and buyer trends. So, the
problem is how to collect and analyze information on
customer behavior that marketing can put to use.
Management continually wants to know the current financial
picture of the company, including profit and loss, cash flow,
and stock market forecasts. So, the problem is how to collect,
analyze, and present all the financial information
management wants
Employees demand more flexibility in their benefits
programs, and management wants to build loyalty and
morale. So, the problem is how to process transactions for
flexible health plans, wellness programs, employee
investment options, retirement accounts, and other benefit
programs offered to employees.
System – a collection of
interrelated components
that function together to
achieve some outcome
Information system – a
collection of interrelated
components that collect,
process, store, and provide
as output the information
needed to complete
business tasks
Subsystem – a system that
is part of a larger system
Systems Analysis and Design in a Changing World, 7th Edition - Online Chapter A 6
Tools – a software application that assists developers in
creating models or other components required for a
project
Techniques –strategies for completing specific system
development activities
Project planning techniques
Cost/benefit analysis techniques
Interviewing techniques
Requirements modeling techniques
Architectural design techniques
Network configuration techniques
Database design techniques
Computers and how they work
File, database, and storage hardware and software
Input and output hardware and software
Computer networks and protocols
Programming languages, operating systems, and
utilities
Communication and collaboration technology such as
digital telephones, videoconferencing, and Web-based
document management systems
What business functions do organizations perform?
How are organizations structured?
How are organizations managed?
What type of work goes on in organizations (finance,
manufacturing, marketing, customer service, etc)?
What the specific organization does
What makes it successful
What its strategies and plans are
What its traditions and values are
Interpersonal skills are perhaps the analyst’s most important
skills because analysts rely on others, including managers,
users, programmers, technical specialists, customers, and
vendors, to take a system from initial idea to final
implementation
The analyst must develop rapport with users who may be
resistant to change, negotiate with management for such
resources as budget, time, and personnel, and manage
development personnel with many different skills,
capabilities, and attitudes
The analyst must be an effective teacher, mentor, confidant,
collaborator, manager, and leader, shifting easily among those
roles many times over the course of a typical work day
Approaches to Systems
Analysis
Topic 2
Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Information systems – a set of interrelated components-
collects, processes, stores, and provides as output
Iterative development – an approach to system development
in which the system is “grown” piece by piece through
multiple iterations
Complete small part of system (mini-project), then repeat processes
to refine and add more, then repeat to refine and add more, until
done
Agile development – an information system development
process that emphasizes flexibility to anticipate new
requirements during development
Fast on feet; responsive to change
https://www.youtube.com/watch?v=OJflDE6OaSc

Iterative and Agile Systems
Development Lifecycle (SDLC)

Large Retail US-based Company
outdoor and sporting clothing and accessories
Skiing, mountain biking, water sports
Hiking, camping, mountain climbing
Rocky Mountain and Western States
Started mail order and phone order
Added retail stores
Added extensive E-business component
Revenue now $67 million retail, $10 million
phone, and $200 million Web-based
Sample project for this topic
Small information system (app)
Being added to larger supply chain management
system
Demonstrates one iteration of the small project –
assumes more iterations in total project
Goes through all six core processes of SDLC
The plan in this topic is to complete iteration in
six days

Problem– purchasing agents attend apparel and fabric
trade shows around the world to order new products
from suppliers
Need– information system (app) to collect and track
information about suppliers and new products while at
tradeshows
Tradeshow Project– is proposed
Supplier information subsystem
Product information subsystem

Identify the problem and document the objective
of the system (core process 1)
Preliminary investigation
System Vision Document
Obtain approval to commence the project (core
process 1)
Meet with key stakeholders, including executive
management
Decision reached, approve plan and budget

Problem description
System capabilities
Business benefits

Core Process 2: Plan the Project
Determine the major components (functional
areas) that are needed
Supplier information subsystem
Product information subsystem
Define the iterations and assign each function
to an iteration
Decide to do Supplier subsystem first
Plan one iteration as it is small and straight forward
Determine team members and responsibilities
Describes the work and
covers Core Processes 3,
4, 5, and 6

Quick Quiz
Q: What is the purpose of a Work Breakdown
Structure?
A: To identify all of the tasks that must be
done to complete a particular iteration and
produce the defined deliverable.

Elaborates the Work Breakdown
Structure

Core Process 3: Discover and Understand
Details
Do preliminary fact-finding to understand
requirements
Develop a preliminary list of use cases and a use
case diagram
Develop a preliminary list of classes and a class
diagram

Identify Use Cases
Both subsystems

Identify Object Classes
Both subsystems

Preliminary Class Diagram
Both subsystems

Core Process 3: Discover and Understand
Details
Do in-depth fact-finding to understand
requirements
Understand and document the detailed
workflow of each use case
Core Process 4: Design System Components
Define the user experience with screens and
report sketches

Supplier Information Subsystem
Use cases:
Look up supplier
Enter/update supplier information
Lookup contact information
Enter/update contract information

Look up supplier use case

Design the database (schema)
Design the system’s high level structure
Browser, Windows, or Smart phone
Architectural configuration (components)
Design class diagram
Subsystem architectural design

Includes View Layer Classes
and Domain Layer Classes

Lots of design diagrams shown
Design in a complex activity with multiple levels
One diagram builds on/complements another
Not everything is diagrammed, especially for a
small project. Pick and choose.
Programming is also done concurrently
You don’t design everything then code
You do some design, some coding, some design,
some coding

Continue with design details
Proceed use case by use case
Core Process 5: Build, Test, and Integrate
System Components
Continue programming (build)
Build use case by use case
Perform unit and integration tests

Core Process 6: Complete System Testing and
Deploy the System
Perform system functional testing
Perform user acceptance testing
Possibly deploy part of system

This was a 6 days iteration of small project
Most iterations are longer (2 to 4 weeks)
This project might be 2 iterations
Most projects have many more iterations
End users need to be involved, particularly in
day 1, 2, 3 and 6.
Days 4 and 5 involved design and programming
concurrently.

Topic 3
Discover and
understand the details
Topic 2 introduced the system development lifecycle

(SDLC) and demonstrated its use for a small project
This topic expands the SDLC processes to cover a
wider range of concepts, tools and techniques
Core process 3: Discover and understand the details of
the problem or need—is the main focus of systems
analysis
Systems analysis activities are detailed in this topic

45
Sales Subsystem
Integrates online, phone, and retail stores
Order Fulfillment Subsystem
Track shipments, rate products and services
Customer Account Subsystem
Shopping history, linkups, “mountain bucks” rewards
Marketing Subsystem
Promotional packages, partner relationships, more
complete merchandise information and reporting

46
The New Consolidated Sales and Marketing System (CSMS) will
require discovering and understanding extensive and complex
business processes and business rules
The SDLC indicates the project starts with identifying the
problem, obtaining approval, and planning the project (as seen
in Topic 2)
To get to the heart of systems analysis, this subject skips right
to analysis activities generally and the specifically for the RMO
CSMS project (Core Process #3)
Project planning and project management will be covered in
detail later in the subject

47
48
Gather Detailed Information
Interviews, questionnaires, documents, observing business processes,
researching vendors, comments and suggestions
Define Requirements
Modeling functional requirements and non-functional requirements
Prioritize Requirements
Essential, important, vs. nice to have
Develop User-Interface Dialogs
Flow of interaction between user and system
Evaluate Requirements with Users
User involvement, feedback, adapt to changes

49
Gather Information, define requirements, prioritize
requirements, and gather and evaluate alternatives.
System Requirements are all the activities the new system

must perform or support and the constraints that new
system must meet.
http://www.youtube.com/watch?v=4a4ZxOAQifE
Discover and understand the details of the problem or need 50

System Requirements =
Functional requirements
Non-functional requirements
Functional Requirements– the activities the system
must perform
Business uses, functions the users carry out
Shown as use cases in Topic 2
Non-Functional Requirements– other system
characteristics
Constraints and performance goals

51
Functional requirements
Usability requirements
Reliability requirements
Performance requirements
Security requirements
+ even more categories…

52
53
Design constraints –
Specific restrictions for hardware and software
Implementation requirements
Specific languages, tools, protocols, etc.
Interface requirements
Interface links to other systems
Physical requirements
Physical facilities and equipment constraints
Supportability requirements
Automatic updates and enhancement methods

Stakeholders– persons who have an interest in the successful
implementation of the system
Internal Stakeholders– persons within the organization
External stakeholders – persons outside the organization
Operational stakeholders – persons who regularly interact
with the system
Executive stakeholders– persons who don’t directly interact,
but use the information or have financial interest

55
Interviewing users and other stakeholders
Distributing and collecting questionnaires
Reviewing inputs, outputs, and documentation
Observing and documenting business procedures
Researching vendor solutions
Collecting active user comments and suggestions

56
Prepare detailed questions
Meet with individuals or groups of users
Obtain and discuss answers to the questions
Document the answers
Follow up as needed in future meetings or interviews

57
58
59
60
61
62
63
Observe and Document Business Processes
Watch and learn
Document with Activity diagram (next section)
Research Vendor Solutions
See what others have done for similar situations
White papers, vendor literature, competitors
Collect Active User Comments and Suggestions
Feedback on models and tests
Users know it when the see it

64
How do we define requirements? After collecting
information, create models
Model– a representation of some aspect of the
system being built
Types of Models
Textual model– something written down, described
Graphical models– diagram, schematic
Mathematical models– formulas, statistics, algorithms
Unified Modeling Language (UML)
Standard graphical modeling symbols/terminology used for
information systems

65
Learning from the modeling process
Reducing complexity by abstraction
Remembering all the details
Communicating with other development team
members
Communicating with a variety of users and
stakeholders
Documenting what was done for future
maintenance/enhancement
66
67
Topic 4
Topic 3 provided an overview of systems analysis
activities, functional and non-functional requirements,
modeling, and information gathering techniques
This topic focuses on identifying and modeling the key
aspect of functional requirements– use cases
In the RMO Tradeshow System from Topic 1, some use
cases are Look up supplier, Enter/update product
information, Enter/Update contact information
In this topic’s opening case Waiters on Call, examples of
use cases are Record an order, Record delivery, Update an
order, Sign in driver, Reconcile driver receipts, Produce end
of day deposit slip, and Produce weekly sales reports

A User Story is a one-sentence description of a
work-related task done by a user to achieve
some goal or result
Acceptance Criteria identify the features that
must be present at the completion of the task
The template for a user story description is:
“As a <role> I want to <goal> so that <benefit>

Use case— an activity that the system performs,
usually in response to a request by a user
Use cases define functional requirements
Analysts decompose the system into a set of use cases
(functional decomposition)
Two techniques for Identifying use cases
User goal technique
Event decomposition technique
Name each use case using Verb-Noun

This technique is the most common in industry
Simple and effective
Identify all potential categories of users of the
system
Interview and ask them to describe the tasks
the computer can help them with
Probe further to refine the tasks into specific
user goals, “I need to Ship items, Track a
shipment, Create a return”

More Comprehensive and Complete Technique
Identify the events that occur to which the system must
respond.
For each event, name a use case (verb-noun) that describes
what the system does when the event occurs
Event– something that occurs at a specific time and
place, can be described, and should be remembered
by the system

External Event
an event that occurs outside the system, usually
initiated by an external agent or actor
Temporal Event
an event that occurs as a result of reaching a point
in time
State Event
an event that occurs when something happens
inside the system that triggers some process
reorder point is reached for inventory item

Brief use case description is often a one sentence
description showing the main steps in a use case

Use case diagram— a UML model used to graphically
show uses cases and their relationships to actors
Recall UML is Unified Modeling Language, the standard
for diagrams and terminology for developing
information systems
Actor is the UML name for a end user
Automation boundary— the boundary between the
computerized portion of the application and the users
who operate the application

A relationship between use cases where one use case is
stereotypically included within the other use case— like a
called subroutine. Arrow points to subroutine

Topic 5
This topic focuses on another key concept for defining
requirements— data entities or domain classes
In the RMO Tradeshow System from Topic 1, some
domain classes are Supplier, Product, and Contact
Opening case Waiters on Call, examples of domain
classes are Restaurants, Menu Items, Customers,
Orders, Drivers, Routes, and Payments
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 84

Problem domain—the specific area (or
domain) of the users’ business need that is
within the scope of the new system.
Example: create an order entry system
allowing customers to enter orders over the
internet
85
Image source: http://tecnoesis.wordpress.com
“Things” are those items users work with when
accomplishing tasks that need to be remembered
Examples of “Things” are products, sales, shippers,
customers, invoices, payments, etc.
These “Things” are modeled as domain classes or
data entities
In this subject, we will call them domain classes. In
database class you may call them data entities

Brainstorming Technique
Use a checklist of all of the usual types of things
typically found and brainstorm to identify domain
classes of each type
Noun Technique
Identify all of the nouns that come up when the
system is described and determine if each is a
domain class, an attribute, or not something we
need to remember

Are there any tangible things? Are there any organizational
units? Sites/locations? Are there incidents or events that need
to be recorded?

A technique to identify problem domain classes
(things) by finding, classifying, and refining a list of
nouns that come up in discussions or documents
Popular technique. Systematic.
Does end up with long lists and many nouns that are
not things that need to be stored by the system
Difficulty identifying synonyms and things that are
really attributes
Good place to start when there are no users available
to help brainstorm

Attribute— describes one piece of information about
each instance of the class
Customer has first name, last name, phone number
Identifier or key
One attribute uniquely identifies an instance of the class.
Required for data entities, optional for domain classes.
Customer ID identifies a customer
Compound attribute
Two or more attributes combined into one structure to
simplify the model. (E.g., address rather than including
number, street, city, state, zip separately). Sometimes an
identifier or key is a compound attribute.

Class is a type of thing. Object is a specific instance of the class.
Each instance has its own values for an attribute

Association— a naturally occurring
relationship between classes (UML term)

Called association on class diagram in UML
Multiplicity is term for the number of associations between classes: 1 to
1 or 1 to many (synonym to cardinality)
UML is the primary emphasis of this text
Called relationship on ERD in database class
Cardinality is term for number of relationships in entity relationship
diagrams: 1 to 1 or 1 to many (synonym to multiplicity)
Associations and Relationships apply in two directions
Read them separately each way
A customer places an order
An order is placed by a customer

Binary Association
Associations between exactly two different classes
Course Section includes Students
Members join Club
Unary Association (recursive)
Associations between two instances of the same
class
Person married to person
Part is made using parts
Ternary Association (three)
N-ary Association (between n)
Class
A type of classification used to describe a collection of objects
Domain Class
Classes that describe objects in the problem domain
Class Diagram
A UML diagram that shows classes with attributes and
associations (plus methods if it models software classes)
Domain Model Class Diagram
A class diagram that only includes classes from the problem
domain, not software classes so no methods

Domain class a name and attributes (no methods)
Class name is always capitalized
Attribute names are not capitalized and use camelback
notation (words run together and second word is
capitalized)
Compound class names also use camelback notation

Bank with many branches as show previously in ERD
Note notation for the key
Note the precise notation for the attributes (camelback)
Note the multiplicity notation

Generalization/Specialization
A hierarchical relationship where subordinate classes are special types
of the superior classes. Often called an Inheritance Hierarchy
Superclass
the superior or more general class in a generalization/specialization
hierarchy
Subclass
the subordinate or more specialized class in a
generalization/specialization hierarchy
Inheritance
the concept that subclasses classes inherit characteristics of the more
general superclass

There are several ways to create the domain model
class diagram for a project
RMO CSMS has 27 domain classes overall
Can create one domain model class diagram per
subsystem for those working on a subsystem
Can create one overall domain model class diagram to
provide an overview of the whole system
Usually in early iterations, an initial draft of the domain
model class diagram is completed and kept up to date.
It is used to guide development.

100
101
102
Topic 6
Write a brief description as shown in Topic 4 for most
use cases.
Systems Analysis and Design in a Changing World, 7th edition – Chapter 5

104
105
A UML sequence diagram
Special case for a sequence diagram
Only shows actor and one object
The one object represents the complete system
Shows input & output messaging requirements for
a use case
Actor, :System, object lifeline
Messages

106
107
108
[true/false condition] return-value := message-name (parameter-list)
An asterisk (*) indicates repeating or looping of the message

Brackets [ ] indicate a true/false condition. This is a test for that message only. If it
evaluates to true, the message is sent. If it evaluates to false, the message isn’t
sent.
Message-name is the description of the requested service written as a verb-noun.
Parameter-list (with parentheses on initiating messages and without parentheses
on return messages) shows the data that are passed with the message.
Return-value on the same line as the message (requires :=) is used to describe data
being returned from the destination object to the source object in response to the
message.

109
Opt Frame (optional)
Alt Frame
(if-else)

110
111
Topic 7
Systems Analysis and Design in a Changing World, 7th Edition – Online Chapter B
Topic 4: identified use cases and describe them with
use case diagrams
Topic 5: learned to describe things in the user's domain
by using domain model class diagram and entity-
relationship diagrams, state-machine diagrams
Topic 6: learned how to describe use cases in further
detail with use case descriptions, activity diagrams,
and system sequence diagrams used to describe a
system's functional requirements.
This topic presents an older and more traditional
approach to representing requirements
Topic 8
Systems Analysis and Design in a Changing World, 7th edition - Chapter 10

Topic 1 demonstrated a system development project that used an
iterative and agile system development life cycle (SDLC)
Later topics focused on Systems Analysis activities and tasks and
some System Design activities and tasks
Now we return to look at the SDLC and related concepts in more
detail
Predictive versus Adaptive SDLC variations
Activities and Tasks of System Support
Models, Methodologies, Tools and Techniques
Agile Development
Specific SDLC Approaches
Unified Process (UP)
Extreme Programming (XP)
Scrum

Most projects fall on a continuum between Predictive and
Adaptive

Earlier approach based on engineering
Typically have sequential Phases
Phases are related groups of development
activities, such as planning, analysis, design,
implementation, and deployment
Waterfall model
SDLC that assumes phases can be completed
sequentially with no overlap or iteration
Once one phase is completed, you fall over the
waterfall to the next phase, no going back

Emerged in response to increasingly complex
requirements and uncertain technological
environments
Always includes iterations where some of design and
implementation is done from the beginning
Many developers claim it is the only way to develop
information systems
Many IS managers are still sceptical due to apparent
lack of overall plan

Incremental development
Completes portions of the system in small
increments and integrated as the project
progresses
Sometimes considered “growing” a system
Walking Skeleton
The complete system structure is built first, but
with bare-bones functionality

Six Core Processes go across iterations
Multiple Iterations as required

A guiding philosophy and set of guidelines for
developing information systems in an unknown,
rapidly changing environment

Agile Values in “Manifesto for Agile Software
Development”
Value responding to change over following a plan
Value individuals and interactions over processes
and tools
Value working software over comprehensive
documentation
Value customer collaboration over contract
negotiation
Chaordic
A term for adaptive projects – chaotic yet ordered
Agile Modeling (AM) – 12 Principles
A philosophy – build only necessary models that
are useful and at the right level of detail

The UP was the early leader in adaptive
approaches
UP and UML (Unified Modeling Language) were
developed together

UP SDLC divides iterations into four phases

UP Phases organize iterations into four primary
areas of focus during a project
Inception phase – getting the project started
Elaboration – understanding the system
requirements
Construction – building the system
Transitions – preparing for and moving to deploying
the new system

Objectives of each phase

A set of functionally related development
activities
Each discipline are all the activities related to
achieving one objective in the development project
Two types of disciplines
Development disciplines
Management – planning and control disciplines

Development Disciplines
Business modeling
Requirements
Design
Implementation
Testing
Deployment

Planning and Control disciplines
Configuration and change management
Project management
Environment

Disciplines are used across all iterations

Topic 9

Topic 8 covered the various alternatives for the
SDLC and approaches to development
You should be asking yourself:
“How are all these activities coordinated?”
“How do I know which tasks to do first?”
“How is the work assigned to the different teams
and team members?”
“How do I know which parts of the new system
should be developed first?”

Categories of project success
Successful projects – on time, within budget, on scope
Challenged projects – failure in one area
Failed projects – cancelled or not used
Recent years have seen some improvement, but still
1/3 to 1/2 of projects are challenged or fail

Reasons for failure
Undefined project management practices
Poor IT management and poor IT procedures
Inadequate executive support for the project
Inexperienced project managers
Unclear business needs and project objectives
Inadequate user involvement

Project Management
Organizing and directing other people to achieve a
planned result within a predetermined schedule
and budget
The processes used to plan the project and then
to monitor and control it.
Project Manager
Great need for effective project managers
Internally managing people and resources
Externally conducting public relations

PMPOK is organized into 10 knowledge areas:
Project Integration Management—Integrating all the other
knowledge areas into one seamless whole
Project Scope Management—Defining and controlling the functions
that are to be included in the system as well as the scope of the work
to be done by the project team
Project Time Management—Creating a detailed schedule of all
project tasks and then monitoring the progress of the project against
defined milestones
Project Cost Management—Calculating the initial cost/benefit
analysis and its later updates and monitoring expenditures as the
project progresses
Project Quality Management—Establishing a comprehensive plan
for ensuring quality, which includes quality control activities for
every phase of a project

Project Human Resource Management—Recruiting and hiring
project team members; training, motivating, and team building; and
implementing related activities to ensure a happy, productive team
Project Communications Management—Identifying all stakeholders
and the key communications to each; also establishing all
communications mechanisms and schedules
Project Risk Management—Identifying and reviewing throughout
the project all potential risks for failure and developing plans to
reduce these risks
Project Procurement Management—Developing requests for
proposals, evaluating bids, writing contracts, and then monitoring
vendor performance
Project Stakeholder Management—Identifying and communicating
with the stakeholders of the new system

Identify the Problem and Obtain Approval

IS Development Projects usually:
Respond to an opportunity
Strategic initiative
Something that provides competitive advantage
Resolve a problem
Operational issues keep coming up
User needs aren’t being met
Respond to an external directive
Legislation requires new form of reporting
Changes in tax laws or regulations

System Vision Document
Problem Description
What is the problem and idea for the solution?
System Capabilities
What are the capabilities the new system will have?
Helps define the scope
Business Benefits
The benefits that accrue to the organization
Tangible (in dollars) and intangible benefits

Estimated Time for Completion

Estimated Cost for Development

Estimated Cost for Support

Tangible “Dollar” Benefits
Used for Cost/Benefit Analysis--process of comparing costs and
benefits to see whether investing in a new system will be
beneficial--

Cost/benefit analysis
comparing costs and benefits to see if the net
result is plus or minus
Net Present Value (NPV)
the present value of dollar benefits and dollar costs of a
particular investment
Break-even Point
point in time at which benefits and costs are equal
Payback Period
the time period after which the dollar benefits have offset
the dollar costs

Tangible Benefit
a benefit that can be measured or estimated in terms of
dollars
Intangible Benefit
a benefit that accrues to an organization but that can’t be
measured quantitatively or estimated accurately

Use present value (after discount factor) for all dollar
values
Estimate the useful life of the system
The NPV after 5 years is $1,713,097
Payback Period is 2 years and 128 days

Increased levels of service (in ways that can’t
be measured in dollars)
Increased customer satisfaction (not
measurable in dollars)
Survival—need to do it to compete
Need to develop in-house expertise (such as a
pilot program with new technology)

Determine the organizational risks and feasibility
How well does the new system fit the organizational
culture? Risk of negative impacts?
Evaluate the technological risks and feasibility
Can the system be built by the team using technology
needed? Training available?
Assess the resource risks and feasibility
Are the needed resources available? Skilled people?
Identify the schedule risks and feasibility
Can the system be built in the amount of time available?
Fixed Deadline?

Sample Dashboard showing project information and status

Gantt Chart for first iteration
Shows task, duration, start date, predecessors, and resources
Generates chart graphically showing dates, predecessors, tasks, and
critical path

Sample Issues-Tracking Log

Best of Luck for Final Exam

Revision Slides

Uploaded by

Copyright:

Available Formats

You might also like

Revision Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Revision Slides

Uploaded by

Copyright:

Available Formats

Introduction to IS and

the role of the analyst

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1

Topic 2 introduced the system development lifecycle

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

System Requirements are all the activities the new system

Discover and understand the details of the problem or need 50

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

©2016. Cengage Learning. All rights reserved.

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 84

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 86

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 87

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 88

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 89

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 90

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 91

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 92

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 93

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 95