1. Chapter 2
par
Overview

2. Overview
There are two principal groups of participants in systems analysis – users and analysts.
In planning for system development, analysts must take into consideration the different interests of different types of users.
© Prentice Hall

3. Overview (continued)
Systems analysts are responsible primarily for understanding, modeling, and communicating the requirements for a new system. Successful systems analysts possess interpersonal and communication skills as well as analytical and technical skills.
© Prentice Hall

4. Overview (continued)
System designers are responsible for the technical quality of the system design. They must assure that the system is designed to satisfy all the requirements.
Programmers are responsible for construction of the system.
© Prentice Hall

5. Iterative and Incremental System Development
Iterative development allows a part of the system to be reworked.
It improves the product by revising any part of the design or implementation that is flawed.
Incremental development organizes the process as a series of builds.
It improves the product by dividing it into these phased builds.
© Prentice Hall

6. Goals of Systems Analysis
Primary Goal:
To state accurately the users’ requirements.
Secondary Goals:
To understand the users’ requirements.
To communicate the current understanding of the proposed system
To prevent expensive mistakes
To state a design problem
To state the conditions for system acceptance

7. Participants in Systems Analysis and Design
The system developing team are:
Users
Analysts
Designers
Programmers
Quality Assurance Specialists

8. 1- Users Types of Users
System owner: A high-level manager and decision-maker for the business area supported by the system
Responsible user: A lower-level manager with operational responsibility for the business functions supported by the system
Hands-on user: A person who interacts directly with the system input and output devices
Beneficial user: A person who has no direct contact with the automated system but provides input or receives output

9. Responsibilities of Users
Knowing and understanding the business functions supported by the information processing system.
Serving as a reliable information source.
resolving conflicts among system objectives users’ requirements.
Reviewing, understanding, and approving the system development document which define users’ objectives and requirements.
Allocating the necessary resources.

10. 2- Analysts Responsibilities of Analysts
Assuring the technical quality of the products and procedures of system analysis.
Determine the implications (technical, economic, psychological, and organizational) of decision about the kind of automation.
Facilitating communication and understanding among the other participants of the process.
Providing organized information to support user decision leading to the development of the best computer based information system (CBIS) to the organization.

11. 3- Designers Responsibilities of Designers
Reviewing the requirements specifications to verify its completeness and consistency.
Notifying users and analyst of any deficiencies found in the requirements.
Defining design alternatives and selecting the best.

12. 4-Programmers Responsibilities of Programmers.

13. 5-Responsibilities of Quality Assurance Staff

14. System Change
Information system change often introduces significant organizational change.
Analysts need to understand the interests of each type of user and work with the users to plan for change.
The plan should incorporate appropriate incentives for each type of user.
© Prentice Hall

15. System Feasibility
 feasibility is the measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.
Feasibility analysis makes explicit:
The constraints on the system – what conditions must be satisfied for the system to be acceptable
A feasible system satisfies all the constraints.
The criteria for comparative analysis of alternatives.

16. System Feasibility (continued)
Analysis of the feasibility of a system addresses these questions:
What benefits is the system expected to provide for its users and major stakeholders?
What specific objectives is the system supposed to achieve?
What are some promising alternatives for an architecture of the new system?
What is it likely to cost to develop the new system?

17. Categories of Feasibility
Technical: Can the proposed system be built?
Resource: Are the required resources available when they are needed?
Organizational: Can the system work in the culture and power structure of the organization?
Economic: Is the system a worthwhile investment?
Schedule or temporal: Can the system be developed and deployed in time to meet the business needs of the organization?

18. Economic Feasibility Analysis
Measures of economic feasibility:
Net present value: A measure over time of the costs and benefits of the project. Their future values are discounted to account for the time value of money.
Break-even point: The time at which all the costs of the system will be recovered.
Return on investment: The ratio of the net present value of the system to the net present value of the costs.