Systems Analysis and Design
From GSLISWiki
Systems Analysis and Design: 1. Problem Definition | 2. Requirements Gathering / Requirements Analysis | Systems Design:Design | Systems Design:Development | Systems Design:Testing | Systems Design:Implementation | Systems Design:Maintenance
Contents |
[edit] Systems Development Life Cycle
The systems development life cycle has been outlined below. To learn more about each of the steps in this process, please click on the appropriate link.
Links that are red have not yet been created. This section is still a work in progress.
- Problem Definition
- Requirements Gathering / Requirements Analysis
- Systems Design:Design
- Systems Design:Development
- Systems Design:Testing
- Systems Design:Implementation
- Systems Design:Maintenance
You can view this process of Systems Analysis and Design as being cyclical. Why is the process cyclical? In the real world, no system is ever perfect. There are a number of reasons for this:
- No matter how good the design process, something will inadvertantly be overlooked.
- Organizations and their needs are always in flux, and as the organization changes, its systems needs change.
- The very implementation of the system changes the way the organization works, and changes the needs of the people in the organization in unpredictable ways.
- With the speed at which technology is evolving, every system will eventually be insufficient to meet the needs of the organization in which it has been implemented.
Developing design methodologies for creating systems that are better at degrading gracefully in the face of these inevitabilities is an area of cutting edge research.
This conception of a cyclical process mirrors the ideas behind Inquiry Based Design.
The articles in this summary of the Systems Development Life Cycle were developed by using the account in Davis (1994) as a framework, and adding material that was present in Kendall & Kendall (1992) and in Edwards (1993) that was missing from Davis's account.
[edit] Kendall & Kendall's Version
- Identifying Problems, Opportunities, Objectives
- How does the organization run?
- Where are problems?
- What can be improved through use of computer systems (opportunities)?
- What are the objectives of the organization?
- How can these objectives be pursued/met?
- Determining Information Requirements -- Methods include sampling and processing of quantitative data, Interviews, Surveys/Questionnairs, Ethnography/observing decision-making behavior and the office environment in which it occurs, Prototyping.
- Analyzing System Needs -- UML
- Designing the Recommended System
- Developing and Documenting Software
- Testing and Maintaining the System
- Implementing and Evaluating the System
[edit] Edwards's Version
- Systems Analysis
- Systems Design
- Systems Implementation
- Systems Maintenance
[edit] Davis's Version
- Problem Definition
- Identify the problem.
- Determine the cause of the problem.
- Outline a strategy for solving the problem.
- Summarize the findings of your investigation with a Problem Statement
- Larger projects may require a feasibility study.
- Customer Sign-Off
- Analysis
- Design
- Development
- Testing
- Implementation
- Maintenance
You can view this process as being cyclical as well.
[edit] Types of Electronic Systems
- Data-Processing Systems -- Computer systems designed to process large amounts of data to faciliate consumption by humans.
- Management Information Systems (MIS) -- Computer systems containing Data-Processing Systems but designed to facilitate purposeful interaction between humans and computers.
- Decision Support Systems (DSS) -- MIS designed to support decision-making by people in all of its phases, often by information structure, presentation, selection, etc.
- Executive Information Systems -- MIS that extends the functionality of DSS to include enterprise modeling, parallel processing, virtual reality, multimedia, etc. and extends the scope of the software beyond the boundaries of the company.
- Expert Systems & Artificial Intelligence -- MIS designed to make decsions.
[edit] Roles of the Systems Analyst
- Consultant -- outside consultants bring a fresh perspective, but are at a disadvantage because they can never know the true organizational culture. This is much the same problem a folklorist encounters, and could probably be remedied in a similar manner: Teaming up Outsider Systems Analysts with Insider Systems Analysts.
- Supporting Expert -- IT Systems Analyst.
- Change Agent -- a person who is responsible for facilitating change in the organizational systems, both by (cooperatively) planning it and enacting it.
[edit] References
This article created from several sources, including:
- Davis, William S. (1994). Business Systems Analysis and Design. Wadsworth Publishing Company: Belmont, California.
- Somewhat more detailed than Kendall & Kendall, but still good for the newbie. It has enough richness to describe the methodology in a general sense, yet may still not be rich enough to apply it without the guidance of someone experienced in applying the methodology.
- This book uses lots of examples to illustrate the points it makes. The examples are useful as illustrations of abstract ideas, but are perhaps not very generalizable--they are more like an artist's sketches than his final masterpiece.
- Edwards, Perry (1993). Systems Analysis & Design. Mitchell McGraw Hill: New York, NY.
- Kendall, Kenneth E.; Kendall, Julie E. (1992). Systems Analysis and Design. Prentice Hall: Englewood Cliffs, NJ.
- This is the only reference that has been reissued in later editions. It is currently in its 6th edition. It takes a simplistic straightforward approach perfect for the newbie, and is easy to read, but lacks the richness required to develop expertise.

