1. Week Two: Systems Planning
Dr Manolya Kavakli
Department of Computing
Macquarie University
Sydney
Read: Chapter 2 (Shelly)

2. Phase Description Systems planning: In this phase, you will learn
the first of five phases in the systems development life cycle (SDLC)
In this phase, you will learn
how IT projects get started and
how a systems analyst
evaluates a proposed project and
determines its feasibility

3. Chapter Objectives
Explain the concept of a business case and how a business case affects an IT project
Describe the strategic planning process and why it is important to the IT team
Explain the purpose of a mission statement 3 3

4. Chapter Objectives Describe the SDLC, and
explain how it serves as a framework for systems development and business modeling
Describe risks and risk management features
List the reasons for information systems projects and the factors that affect such projects 3 4

5. Chapter Objectives
Explain the initial review of systems requests and the role of the systems review committee
Define operational feasibility, technical feasibility, economic feasibility, and schedule feasibility
Describe the steps in a preliminary investigation and the end product of an investigation

6. Cost of Information Overload
38% of managers waste a substantial amount of time trying to locate the right information.
43% of managers think decisions are delayed as a result of having too much information.
47% say the collection of information for decision making distracts them from their main job responsibilities.

7. Business Case During Systems Planning phase,
IT team reviews a proposal to determine if it presents a strong business case.
Business Case refers to the reasons, or justification, for a proposal.
Systems development starts with
a systems request,
followed by a preliminary investigation,
which includes a feasibility study 4 7

8. Strategic Planning – A Framework for IT Systems Development
the process of identifying long-term organizational goals, strategies, and resources
What do we evaluate in Strategic Planning?
Strategic Planning Overview
SWOT analysis 4 8

9. Strategic Planning – A Framework for IT Systems Development
From Strategic Plans to Business Results
Mission statement
Describes a company for its stakeholders
States the company’s overall purpose, products, services, and values
Stakeholders
Anyone affected by the company’s operations
Goals
1 year, 3 year, 5 year goals to accomplish the mission
Objectives
Shorter term objectives to achieve goals

11. Strategic Planning – A Framework for IT Systems Development
To be able to present a Case for Action, we need to inspect the Business Enterprise Direction Model:
The mission statement
Critical success factors
A few key circumstances (less than 10) that must occur for the enterprise to fulfill its mission
Critical business issues
Opportunities, problems, trends, threads causing the enterprise to take action at the current time
Case for action
Summary of primary business issues raising the sense of urgency for change

12. Strategic Planning – A Framework for IT Systems Development
The Role of the IT Department in Project Evaluation
Management leadership and information technology are linked closely, and remarkable changes have occurred in both areas
Today, systems development is much more team oriented
Although team-oriented development is the norm, some companies see the role of the IT department as a gatekeeper

13. Strategic Planning – A Framework for IT Systems Development
The Future
New industries, products, and services emerging from amazing advances in information technology,
customers who expect world-class IT support,
a surge in Internet-based commerce, and
a global business environment that is dynamic and incredibly challenging.

14. What Is a Business Case? Should be comprehensive,
yet easy to understand
describe the project clearly,
provide the justification to proceed, and
estimate the project’s financial impact

15. Information Systems Projects
Main Reasons for Systems Projects 15

16. The PIECES Problem-Solving Framework
P the need to improve performance
I the need to improve information (and data)
E the need to improve economics, control costs, or increase profits
C the need to improve control or security
E the need to improve efficiency of people and processes
S the need to improve service to customers, suppliers, partners, employees, etc.
Teaching Notes
We really emphasize PIECES as a useful way to characterize all problems. Later, we teach our students to use PIECES to analyze requirements and solutions as well.
It can be useful to apply the PIECES framework to a project from the instructor’s professional background.
Refer to Figure 3-4 in the text for the PIECES checklist.

17. Information Systems Projects
Factors that Affect Systems Projects 17

18. Information Systems Projects
External Factors
Technology
Bar Code Technology replaced with RFID tags to monitor the movement of product: Electronic product code (EPC)
Suppliers
Expansion of EDI to include Just-in-time (JIT): right product at the right place at the right time.

19. Information Systems Projects
External Factors
Customers
Customer Relationship Management (CRM): integrate all customer-related events and transactions
Electronic proof of delivery (EPOD)
Competitors
The economy
Government

20. Information Systems Projects
Project Management Tools
All IT projects, large and small, must be managed and controlled
Project management begins with a systems request, and continues until the project is completed or terminated

21. Evaluation of Systems Requests
Systems review committee
Systems Requests Forms

22. Evaluation of Systems Requests
Systems Review Committees
Most large companies use a systems review committee to evaluate systems requests
Many smaller companies rely on one person to evaluate system requests instead of a committee
The goal is to evaluate the requests and set priorities

23. Overview of Feasibility
A systems request must pass several tests, called a feasibility study, to see whether it is worthwhile to proceed further

24. Overview of Feasibility
Candidate solutions evaluated in terms of:
Operational Feasibility
Means that a proposed system will be used effectively
Technical Feasibility
refers to technical resources needed to develop, purchase, install, or operate the system
Economic Feasibility
Means that the projected benefits of the system outweigh the estimated costs
Total cost of ownership (TCO): ongoing support support and maintenance costs, as well as acquisition costs
Tangible benefits: benefits that can be measured in dollars
Intangible benefits: user friendliness, better information, etc.
Schedule Feasibility
Means that the project can be implemented in an acceptable time frame.

25. Evaluating Feasibility
The first step in evaluating feasibility:
to identify and weed out systems requests that are not feasible
Even if the request is feasible, it might not be necessary
Setting priorities is important.
Feasibility analysis: an ongoing task that must be performed throughout the systems development process

26. Setting Priorities Factors that Affect Priority
Will the proposed system reduce costs? Where? When? How? How much?
Will the system increase revenue for the company? Where? When? How? How much?
Will the systems project result in more information or produce better results? How? Are the results measurable?
Will the system serve customers better?
Will the system serve the organization better?
Can the project be implemented in a reasonable time period? How long will the results last?
Are the necessary financial, human, and technical resources available?
Whenever possible, the analyst should evaluate a proposed project based on tangible costs and benefits that represent actual (or approximate) dollar values

27. Setting Priorities Discretionary Projects Nondiscretionary Projects
Projects where management has a choice in implementing them
Nondiscretionary Projects
Projects where no choice exists
E.g., Payroll, tax

28. Preliminary Investigation
Preliminary investigation is conducted to
study the system request and
recommend specific action
Through Interaction with Managers and Users

29. Preliminary Investigation Overview
Planning the Preliminary Investigation
During a preliminary investigation, a systems analyst typically follows a series of steps
The exact procedure depends on the nature of the request, the size of the project, and the degree of urgency

30. Preliminary Investigation
Step 1: Understand the Problem or Opportunity
popular techniques:
A fishbone diagram, or Ishikawa diagram
for investigating causes and effects
Pareto chart
For prioritizing issues

31. Preliminary Investigation
Step 2: Define the Project Scope and Constraints
Project scope:
defining the specific boundaries of the project
Project creep: Is it clear?
projects with very general scope definitions are at risk of expanding gradually, without specific authorization.
Constraint:
requirement or condition that a system must satisfy or
an outcome that the system must achieve.
Characteristics of constraints:
Present versus future
Internal versus external
Mandatory versus desirable
Regardless of the type, all constraints should be identified as early as possible to avoid future problems and surprises

32. Preliminary Investigation
Step 3: Perform Fact-Finding
might consume several hours, days, or weeks
Fact-finding involves various techniques:
Analyze Organization Charts
Conduct interviews
Review documentation
Observe operations
Conduct a user survey

33. Preliminary Investigation
Step 3: Perform Fact-Finding
Conduct interviews
Determine the people to interview
Establish objectives for the interview
Develop interview questions
Prepare for the interview
Conduct the interview
Document the interview
Evaluate the interview

34. Preliminary Investigation
Step 4: Evaluate Feasibility
Evaluate the project’s operational, technical, economic, and schedule feasibility

35. Preliminary Investigation
Step 5: Estimate Project Development Time and Cost
What information must you obtain, and how will you gather and analyze the information?
What sources of information will you use, and what difficulties will you encounter in obtaining information?
Will you conduct interviews? How many people will you interview, and how much time will you need to meet with the people and summarize their responses?
Will you conduct a survey? Who will be involved? How much time will it take people to complete it? How much time will it take to prepare it and tabulate the results?
How much will it cost to analyze the information gathered and to prepare a report with findings and recommendations?
You should provide an estimate for the overall project, so managers can understand the full cost impact and timetable.

36. Preliminary Investigation
Step 6: Present Results and Recommendations to Management
The final task is to prepare a report to management
The format of the preliminary investigation report varies from one company to another
A typical report consists of:
Introduction
Systems request summary
Findings
Recommendations
Project Roles
Time & cost estimates
Expected benefits
Appendix

37. Chapter Summary
Systems planning is the first phase of the systems development life cycle
Effective information systems help an organization support its business process, carry out its mission, and serve its stakeholders 49 37

38. Chapter Summary
Strategic planning allows a company to examine its purpose, vision, and values and develops a mission statement, which leads to goals, objectives, day-to-day operations, and business results that affect company stakeholders
Systems projects are initiated to improve performance, provide more information, reduce costs, strengthen controls, or provide better service 49 38

39. Chapter Summary
Various internal and external factors affect systems projects
During the preliminary investigation, the analyst evaluates the systems request and determines whether the project is from an operation, technical, economic, and schedule standpoint
Analysts evaluate systems requests on the basis of their expected costs and benefits, both tangible and intangible 49 39

40. Chapter Summary
The steps in the preliminary investigation are to understand the problem or opportunity; define the project scope and constraints; perform fact-finding; estimate the project’s benefits; estimate project development time and cost; and present results and recommendations to management
The report must include an estimate of time, staffing requirements, costs, benefits, and expected results for the next phase of the SDLC
Chapter 2 complete 49 40

41. Week Two: Systems Analysis and Requirements Modeling
Dr Manolya Kavakli
Department of Computing
Macquarie University
Sydney
Read: Chapter 3 (Shelly)

42. Phase Description Systems Analysis: Uses requirements modeling and
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

43. Chapter Objectives
Describe systems analysis phase activities and the end product of the systems analysis phase
Explain joint application development (JAD) and rapid application development (RAD)
Understand how systems analysts use a functional decomposition diagram (FDD)
Describe the Unified Modeling Language (UML) and explain use case diagrams particularly 3 43

44. Chapter Objectives
List and describe system requirements, including outputs, inputs, processes, performance, and controls
Explain the importance of scalability in system design
Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research 3 44

45. Introduction
This chapter describes requirements modeling techniques and team-based methods that systems analysts use to visualize and document new systems
The chapter then discusses system requirements and fact-finding techniques, which include interviewing, documentation review, observation, surveys and questionnaires, sampling, and research 4 45

46. Systems Analysis Phase Overview
The overall objective: to
understand the proposed project,
ensure that it will support business requirements, and
build a solid foundation for system development
You use a models and other documentation tools to visualize and describe the proposed system

47. Systems Analysis Activities

48. Systems Analysis Activities
Requirements modeling
Involves fact-finding to describe
Outputs (electronic or printed info produced by the system)
Inputs (necessary data that enters the system)
Processes (logical rules applied to transform data into info)
Performance (systems characteristics such as speed, capacity, reliability, availability, etc.)
Security (hardware, software and procedural controls that protect the system and its data)

49. Systems Analysis Phase
Systems Analysis Skills
Analytical skills
Interpersonal skills
Team-Oriented Methods and Techniques
Joint application development (JAD)
Rapid application development (RAD)

50. Joint Application Development
User Involvement
Users have a vital stake in an information system and they should participate fully
Successful systems must be user-oriented and users need to be involved
One popular strategy for user involvement is a JAD team approach

51. Joint Application Development
JAD Participants and Roles
JAD participants should be insulated from the distraction of day-to-day operations
Objective is to analyze the existing system, obtain user input and expectations, and document user requirements for the new system

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

53. Rapid Application Development
a team-based technique that speeds up information systems development and produces a functioning information system
Relies heavily on prototyping and user involvement
Process continues until the system is completely developed and users are satisfied
Similarities and differences between JAD and RAD?
Like JAD, it uses a group approach
End product of JAD is a requirements model.
End product of RAD is the new IS.

54. Rapid Application Development
RAD Phases and Activities

55. Rapid Application Development
RAD Objectives
To cut development time and expense by involving the users in every phase of systems development
Successful RAD team must have IT resources, skills, and management support
Helps a development team design a system that requires a highly interactive or complex user interface

56. Rapid Application Development
RAD Advantages and Disadvantages
Advantages
Systems can be developed more quickly with significant cost savings
Disadvantages
RAD stresses the mechanics of the system itself and does not emphasize the company’s strategic business needs
Might allow less time to develop quality, consistency, and design standards

57. Modeling Tools and Techniques
CASE Tools
Document business functions and processes
Develop graphical models
Provide an overall framework for IS development
Functional Decomposition Diagrams (FDD)
Also called structure charts
Top-down representation of a function or process

58. Modeling Tools and Techniques
Data Flow Diagrams (DFD)
Shows how the system stores, processes and transforms data

59. Modeling Tools and Techniques
Unified Modeling Language
Widely used method of visualizing and documenting software systems design
Uses object-oriented design concepts
Provides graphical tools such as:
Use case diagrams
Visually represents the interaction between users and the IS.
The User becomes an Actor with a specific role.
Sequence diagrams
Shows the timing of interactions between objects

60. System Requirements Checklist
A characteristic or feature that must be included in an IS to satisfy business requirements and be acceptable to users.
Five general categories:
Outputs
Inputs
Processes
Performance
Controls

61. 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 sorted by part number

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

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

64. System Requirements Checklist
Performance
The system must support 25 users online simultaneously
Response time must not exceed four seconds

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

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

67. 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):
Microsoft’s method for measuring total costs and benefits

68. Fact-Finding Fact-Finding Overview
The first step is to identify the information you need
Develop a fact-finding plan describing:
Who, What, Where, When, How, and Why?
Difference between asking
what is being done and
what could or should be done

69. Interviews
Systems analysts spend a great deal of time talking with people
Much of that time is spent conducting interviews

70. Interview Step 1: Determine the People to Interview
Informal structures
Step 2: Establish Objectives for the Interview
Determine the general areas to be discussed
List the facts you want to gather

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

72. Interviews Step 4: Prepare for the Interview
Careful preparation is essential because 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

73. 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
After interview, summarize the session and seek a confirmation

74. Interviews Step 6: Document 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

75. Interviews Step 7: Evaluate the Interview Unsuccessful Interviews
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

76. Other Fact-Finding Techniques
Document Review
Observation
Seeing the system in action gives you additional perspective and a better understanding of the system procedures
Plan your observations in advance
Hawthorne Effect:
Productivity improves whenever the workers know they are observed.

77. Other Fact-Finding Techniques
Questionnaires and Surveys
When designing a questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding
Fill-in form

78. Other Fact-Finding Techniques
Sampling: collecting examples of actual documents
Main objective of a sample is to ensure that it represents the overall population accurately
Systematic sample
(select every 10th customer for review)
Stratified sample
(geographically balanced using ZIP code)
Random sample
(selecting any 20 customers)

79. Other Fact-Finding Techniques
Research
Can include the Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments
Site visit

80. Other Fact-Finding Techniques
Interviews versus Questionnaires
Interview is more familiar and personal
Questionnaire gives many people the opportunity to provide input and suggestions
Brainstorming
Structured brainstorming
Unstructured brainstorming

81. 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 so related material is located easily

82. Documentation Software Tools CASE Tools Productivity Software
Word processing, spreadsheets, database management, presentation graphics programs
Histogram

83. Documentation Software Tools Graphics modeling software
Personal information managers
Personal information manager (PIM)
Handheld computers
Personal digital assistants (PDAs)
Wireless communication devices

84. 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 model the logical design of the system

85. Logical design – the translation of business user requirements into a system model that depicts only the business requirements and not any possible technical design or implementation of those requirements. Common synonyms include conceptual design and essential design.
System model – a picture of a system that represents reality or a desired reality. System models facilitate improved communication between system users, system analysts, system designers, and system builders.