Managing Information System Analysis & Design
The information systems (IS) that provide business data management support are both complex and expensive. This article explains the processes and problems of information systems analysis and design. The types of situations in which systems are developed are examined as well as the types of problems that can occur during the requirement analysis process. Traditional information system development life cycle methods are explained along with a popular alternative development method?prototyping. The impact of computer aided software engineer (CASE) tools is also reviewed. The issue of software development success is examined from a traditional perspective as well as from the perspective of software developers.
Keywords Business Information Systems; Computer Aided Software Engineering (CASE); IS analysis and design; Information systems development life cycle (ISDLC); Information systems prototyping; Management Information Systems; Requirements analysis
Business Information Systems: Managing Information System Analysis
Private companies as well as government organizations depend on data management support for operations management, production or service planning, and to forecast future business trends or service needs. The information systems (IS) that provide data management support are both complex and expensive. Effective management of the analyses of IS needs and the designing of appropriate systems is critical to both an organization's success and to controlling cost. There are five types of situations that commonly guide the methodologies applied to IS analysis and design projects:
- Class 1: “Well-structured problem situations with a well-defined problem and clear requirements.” In these situations, traditional information systems development life cycle (ISDLC) methodologies are appropriate.
- Class 2: “Well-structured problem situations with clear objectives but uncertain user requirements.” In these situations, data modeling or prototyping methodologies can be combined with ISDLC methods.
- Class 3: “Unstructured problem situations with unclear objectives.” In these situations, prototyping methodologies that examine both the perspectives of the users and developers involved are appropriate.
- Class 4: “Situations where there is a high user interaction with the system.” In these situations, modeling or prototyping methodologies can be used to explore the needs of the people that interact with and use the system.
- Class 5: It is not uncommon that development projects may face one or more problem situations. Thus a hybrid, or mix of elements from class one, two, three, or four situations may be required (Avison & Taylor, 1997, Abstract).
When starting a development project, the first steps that IS analysts and designers take is to gain an understanding of the situation and determine, as much as possible, what the requirements are for the proposed system. Typically, an IS project is initiated upon request from a functional department in an organization such as marketing, production, sales, human resources, or customer service. Departmental management usually sends a written request to the central management information systems (MIS) department, which prompts a series of meetings to discuss the project. These meetings are the beginning of what can often be a long requirements analysis process.
The goal of the requirements analysis process is to determine how well the requester understands the requirements and how clearly they can state the goals and objectives of the project. Since the specifications stated in the requirements analysis phase will guide the design and implementation of the system, the accuracy of specifications is critical to a successful project (Sakthivel, 1991). There are five types of errors that can occur during the requirements analysis process which can result in lost time, cost overruns, or poor system performance. The five types of errors are:
- Incompleteness: The requirements are incomplete when parts of the specifications or goals of the project are missing.
- Inconsistency: The requirements are inconsistent when specifications conflict with each other or with goals and objectives.
- Infeasible: The requirements are infeasible when the system cannot meet the requirements.
- Incorrect: The requirements are incorrect when there are errors in data requirements or business rules applied to processing data.
- Untestable: The requirements are untestable when specifications lack clarity and the results that the user is seeking cannot be tested.
- Redundant: The requirements are redundant when unnecessary, overlapping, or duplicate processes are requested (Sakthivel, 1991).
As an IS project is initiated, the project manager needs to address two major challenges. The first challenge is to assess the class of the situation (class one, two, three, four, or five as listed above) and determine a strategy to either eliminate or overcome obstacles. The second challenge is to establish a requirements analysis process to overcome the common errors of incompleteness, inconsistency, unfeasibility, incorrectness, un-testability, and redundancy.
In class one and two situations, where there are well-structured problem situations, errors in the requirements analysis process are less likely, but they can still occur. In class three situations where the problem is unstructured, or class four situations that call for high user interaction, reducing errors in the requirements analysis process is more complicated.
A long-standing issue in the requirements analysis process has been called the user-IS culture gap. Simply stated, the culture gap has two sides. First, do non-IS employees understand problems in IS terms well enough to communicate with system developers? Second, do IS developers understand business problems well enough to communicate with non-IS employees? The answer probably lies somewhere in the middle. However, research shows that socialization is an effective means of creating effective working relationships between IS professionals and their business counterparts, and reducing the culture gap.
Three mutually reinforcing domains of socialization (normative, organizational and work group arrangements), are positively correlated with improved user-IS integration, and project group effectiveness. The socialization practices provide a mutually reinforcing environment that results in improved effectiveness of user-IS relationships. Multidisciplinary teams, credible project managers, short delivery time lines, success criteria based on delivering business benefits, close physical proximity, and team building processes all help to ensure integration and effective work relationships (Taylor-Cummings, 1998).
Information System Development Life Cycle
The Information System Development Life Cycle (ISDLC) is an established concept in the MIS arena. The traditional approach to the ISDLC is that a development project has to undergo a series of phases where the completion of each is a prerequisite to the commencement of the next and where each phase consists of a related group of steps. The ISDLC, as mentioned above, is appropriate for class one and perhaps class two development situations. The general scheme for the ISDLC is similar almost everywhere. It typically contains four major phases consisting of several steps each:
- The Definition Phase: Consisting of preliminary analysis, feasibility study, information analysis, and system design.
- The Construction Phase: Consisting of programming, development of procedures, unit testing, quality control, and documentation.
- The Implementation Phase: Consisting of user training, conversion of old systems to new systems, thorough field testing, and then a move to full operations.
- The Maintenance Phase: After the system is in full operation, updates are made to assure continued operations as new equipment or upgrades to operating systems occur. Enhancements to the system can also be made to meet changing user requirements.
The traditional approach advocates a rigid ISDLC in order to assure control over the development process. In practice, however, development processes are not that rigid. They vary with respect to the complexity of the system under development, the importance attached to that system, and the user's environment (Ahituv, Hadass & Neumann, 1984). When the development needs of classes of situations (three, four, and five) are considered, the various steps from the ISDLC will probably be performed but not necessarily in the same order. For example, the testing, quality control, and documentation steps may not occur until everybody involved is satisifed with data models or with prototypes of systems.
Information System Prototyping Methodologies
The prototyping approach to systems development emphasizes learning and facilitates meaningful communication between systems developers and users. Prototyping is a mechanism for improving the effectiveness of analysis and design in loosely structured situations. Prototyping can be applied in all classes of situations but may be most appropriate in class two, three, or four situations where there is a lack of clarity about system requirements.
According to Baskerville and Stage (1996), there are several different forms of prototyping:
“There are "throw-away" design prototypes, e.g. mock-ups and user interface prototypes that have limited functionality and precede the specification process. There are specification prototypes that provide a throw-away working model of an entire system prior to specification and construction. There are design-driven prototypes that provide a prefinalization "test-drive" of a traditionally developed system. The classic prototyping approach is embodied in evolutionary prototypes that begin as design prototypes and cycle through iterative phases of prototype reconstruction and user evaluation until...
(The entire section is 4447 words.)