Managing Information System Analysis and Design

Abstract

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.

Overview

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 that 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 satisfied 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 full functionality is achieved” (p. 482).

The manager confronts two challenges. The first is to determine the extent to which prototyping or more traditional approaches should be applied in a situation. The second is to control the “course of a prototyping effort once it has been decided to use this approach” (pp. 482–83). Prototypes “provide users with a more concrete understanding of the proposed computer system. They eliminate the confusion and potential for misunderstanding that originates from the interpretation of abstract specifications and replaces this with meaningful and direct communication between systems developers and users” (p. 482). This is very important in class three and four development situations.

Baskerville and Stage (1996) assert that,

“Risk analysis techniques can support the management of prototype development by providing a framework for determining priorities, resources, and activities during the course of an evolutionary prototyping project. A risk analysis cycle evaluates the current situation of the project and determines relevant resolution strategies. Risk analysis in prototyping essentially enables collaboration on evaluating a situation” (p. 485).

Thus, risk analysis should begin with an “unstructured, brain-storming group session” charged with formulating the initial risk inventory. Risk of failure in a prototyping project can be reduced by taking several basic steps.

“First, the prototype project managers should promote action by organizational management that provides the project with access to resources and otherwise strengthens commitments to the project. This strategy is appropriate for organizational risks regarding users or the problem domain. This strategy corrects dysfunctional aspects of the social and organizational setting of the prototyping project.

Second, the users can be trained in the prototyping process. This strategy involves using the prototyping team to educate users in their benefits and responsibilities in the prototyping process. This can improve user understanding and promote user-designer cooperation in the project. Like organizational action, this can improve user willingness to participate in the prototyping process and can increase collaboration among the social groups.

Third, is to develop several prototypes for the users to select from. This strategy can involve parallel development of multiple, competing prototypes. Each prototype will demonstrate an alternative information architecture or technological base in the context of the users' information problems. Competing prototypes can also demonstrate alternative ways in which functional and interface components might support user tasks. These prototypes will likely be shallow mock-ups that will result in the highest degree of user understanding of the architecture” (Baskerville & Stage, 1996, pp. 489–90).

Applications

Computer-Aided Software Engineering (CASE) Tools. All parties involved, including corporate managers, end-users, IS managers, and members of software development share the perspective that better software and greater development efficiency is good. Over the years, there have been many efforts to improve both quality and efficiency.

In the 1980s, the idea that automated tools could improve the quality of applications software was taking hold. It was also believed that the tools may reduce the cost of development projects. Computer-aided software engineering (CASE) tools began to draw the interest of developers and MIS managers. Many people saw the tools as silver-bullet solutions that would solve all the problems of development. Others were more skeptical and the research on productivity improvements provided by the tools was heavily scrutinized.

To understand how CASE tools are used, as well as how they impact productivity, Guinan, Cooprider, and Sawyer (1997) studied applications development teams “across the systems development life cycle, across multiple development efforts, and across many organizations, with both objective and subjective performance measures” (p. 1). To collect such data, a longitudinal study approach was necessary. After collecting data on more than 100 projects at 22 development sites over a period of four years, it was found that:

• There was a relatively high use of upper CASE tools (tools to help with high-level design issues) during analysis and design but usage dropped off during build and test.
• Development teams with higher levels of CASE tool training use the CASE tools significantly more than the less-trained teams. Furthermore, teams with more CASE-tool training receive higher ratings from their user population.
• The use of structured methods influences the level of CASE use and enhances aspects of application development performance.
• Development teams with less group coordination use CASE more and have lower labor cost per function point while teams with higher levels of group coordination use CASE tools less but have higher labor cost.
• Smaller projects use less CASE, have a lower labor cost per function point and have lower levels of user satisfaction. This result may indicate that the use of CASE tools for small projects is not warranted.
• For larger projects, increased use of CASE, specifically lower CASE and project management tools, is related to higher levels of user satisfaction. However, larger projects have higher labor costs per function point. Larger projects demand more coordination and management, which increases costs.
• Using CASE tools actually increased the likelihood that well-trained project teams would exceed their projected schedules.
• CASE tools enhanced the productivity of development teams that were taking advantage of structured methods for development. For teams with well-structured processes, CASE use enhances the process and improves performance. For those teams with ad hoc processes, CASE tool use apparently abets chaos (Guinan, Cooprider & Sawyer, 1997).

Coupe and Onodu (1996) indicated that CASE tools have a “positive effect on developer productivity and the quality of applications software. It particularly improved the reliability and accuracy of applications software, though this was sometimes offset by a deterioration in software efficiency. There was little evidence of productivity being 'traded' for quality, since developers citing productivity gains also tended to report quality improvements. The extent to which organizations were able to realize the benefits of CASE depend on the experience, competence, and training of individual developers” (Coupe & Onodu, 1996, Abstract).

Issue

Defining Software Development Success. The use of the traditional definition of software project success (completing a project that meets customer/user requirements on time and within budget) is somewhat simplistic. Software developers (programmers, database developers, systems analysts) are often heavily criticized for not meeting dates or not staying within budget. However, software developers generally have an innately high need for achievement and professional growth and programmers have a particular need to create useful things.

An examination of the definition of success from the perspective of software developers provides insight into the development process and the problems that can occur during development. Procaccino, Verner and Lorenzet (2006) analyzed the components of success (those that contribute to successful software development and those that help define “successful” projects from the view point of software developers) helps to bring out the perspective of developers.

The first area of consideration is the driver of success (rather than the assisting in defining success). For this set of components, developers were asked to rate how significant they believe each component is in its contribution to what they consider a 'successful' software project. According to Procaccino et al., these components “have implications for individual developers and the development team, as well as those that address” (p. 80) the project itself (including project management, customers/users, and requirements). The most important drivers of success, from the developer's perspective are:

• Requirements are clear and understood by the development team
• Overall, the development team is sufficiently skilled
• Customers/users and development team has a good relationship (cooperative, mutually responsive) (Procaccino et al., 2006, p. 81).

The highest-ranking process component was having clear and understood requirements for the development team. Clear and understood requirements help to lessen developers' frustration at having to redo the design and code elements of a poorly understood system. At the same time, such understanding of “requirements, particularly early on, will help save expensive and time-consuming rework, which contributes to the timely, affordable delivery of a well-tested system that meets customer/user” requirements (Procaccino et al., 2006, p. 81).

Procaccino et al. ranked having a sufficiently skilled development team “second highest and this component has been cited as one of the ‘10 signs of IS project failure.’ It seems to support team productivity and lessen the detrimental impact of excessive training of team members” (p. 80). A good relationship between customers/users and the development team was the third highest-ranked process component, and it seems to support customers/users having realistic expectations.

To investigate the work-related aspects of project is success, developers were asked to rate how important they believe each component is, in general, to their definition of a successful software project. In this case, investigated components were related to either the individual developer (related to the work they perform) or the project at large (meeting requirements, timeliness, cost, and ease of use of the final system). The three highest ranked components were:

• You had a sense that you delivered sufficient quality (did a good job)
• You had a sense of achievement
• You were provided with enough independence and freedom (autonomy) to work creatively on a project (Procaccino et al., 2006, p. 81).

These components have implications for the intrinsic motivation of developers. The highest-ranked work component was having a sense of delivering sufficient quality. The second highest-ranked work component (having a sense of achievement) is an intrinsic need and, as previously mentioned, is typical of developers. Being provided with enough independence/ freedom (autonomy) to work creatively on a project was the third highest-ranked work component. An inspired team will presumably contribute toward meeting organizational goals; including the completion of a project that is on time, within budget, and meets customer/user requirements.

System/project success components related to either the final system or the project. The three highest-ranked components were (Items three and four were tied for third place):

• The final system worked as intended
• Requirements of customers/users were met by the completed system
• Project was delivered when needed by customers/users
• Final system consisted of solid, thoroughly tested code.

The highest rated components of system/project success was that requirements of customers/users were met by the completed system and the final system worked as intended, point to developer focus on user satisfaction, as does thoroughly tested code and ease of use. In fact, developers tended to assign more importance to the functional aspects of the system (requirements were met; system worked as intended; system consistent of solid, thoroughly tested code) than they did to the organizational/managerial aspects (completed on time, within budget, at an affordable cost) (Procaccino et al., 2006, p. 81).

Essentially, developers indicated that they value producing a quality system that meets customer/user requirements more than delivering that system on time and within budget. This is further emphasized by their ranking the delivering of a system when needed by the customers/users (not necessarily within schedule) higher (third) than delivering the system on time (according to schedule, which was ranked sixth) (Procaccino et al., 2006).

Conclusion

Effective management of the analysis of IS requirements and the designing of appropriate systems is critical to an organization's success as well as to its cost control. Systems development methodologies must be selected and applied based on the clarity of requirements and goals stated by those who will use the system. When goals are clear, ISDLC methods are appropriate. When goals are not clear, alternative development methods need to be used.

Overcoming the user-IS culture gap is a big challenge in many development environments. This gap can contribute to many types of errors during the requirements analysis process including incompleteness, inconsistency, unfeasibility, incorrectness, un-testability, and redundancy. Several methods can be applied to reduce errors and improve quality. In the 1980s, the idea that automated tools could improve the quality of applications software took hold. It was also believed that the tools may reduce the cost of development projects. Research shows that CASE tools can be very effective in some situations.

The use of the traditional definition of software project success (completing a project that meets customer/user requirements on time and within budget) is somewhat simplistic. An examination of the definition of success from the perspective of software developers provides insight into the development process and the problems that can occur during development. Analyzing the components of success (those that contribute to successful software development and those that help define successful projects from the view point of software developers) helps to bring out the perspective of developers.

As information systems became more complex and ever more critical to the performance of businesses and other organizations in the twenty-first century, the security of such systems became an increasing concern. Information breaches such as identity theft gained greater recognition both by industry professionals and the general public, highlighted by media coverage of high-profile incidents. These developments led many in the IS analysis and design field to focus on information security as a chief priority in all stages of the ISDLC, and various security standards were proposed (Salisbury, Ferratt, & Wynn, 2015).

Terms & Concepts

Computer-Aided Software Engineering (CASE) Tools: Automated software development tools that assist developers in designing and programming new information systems.

Function Point: Related pieces of code that enable an IS to perform a function.

Information System Development Life Cycle (ISDLC): The multi-step structured process in which an information system is developed and maintained.

Management Information Systems (MIS) Department: The central department in an organization that is responsible for information systems development and management.

Prototyping: An approach to systems development that emphasizes learning and facilitates meaningful communication between systems developers and users. The process is facilitated through building model systems using the input from the users and thus allowing users to test their understanding of the problem and the developer to learn more about the user's needs.

Requirements Analysis Process: The process through which applications software developers work with end users to determine what a proposed system should do and how it should accomplish various tasks.

User-IS Culture Gap: The gap in user understanding of problems in IS terms and IS developer understanding of problems in user terms.

Bibliography

Ahituv, N., Hadass, M., & Neumann, S. (1984). A flexible approach to information system development. MIS Quarterly, 8, 69–78. Retrieved July 30, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=4679361&site=ehost-live

Avison, D., & Taylor, V. (1997). Information systems development methodologies: A classification according to problem situation. Journal of Information Technology, 12, 73–81. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=6270862&site=ehost-live

Baskerville, R., & Stage, J. (1996). Controlling prototype development through risk analysis. MIS Quarterly, 20, 481.

Connell, J.L. & Schafer, L.B. (1989). Structured rapid prototyping. Englewood Cliffs, NJ: Yourdon Press.

Coupe, R., & Onodu, N. (1996). An empirical evaluation of the impact of CASE on developer productivity and software quality. Journal of Information Technology, 11, 173–181. Retrieved July 24, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=6269314&site=ehost-live

Deng, X., & Chi, L. (2012). Understanding postadoptive behaviors in information systems use: A longitudinal analysis of system use problems in the business intelligence context. Journal of Management Information Systems, 29, 291–326. Retrieved October 31, 2013, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=85985311&site=ehost-live

Goepp, V., Caillaud, E., & Rose, B. (2013). A framework for the design of knowledge management systems in eco-design. International Journal of Production Research, 51, 5803–5823. Retrieved October 31, 2013, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=90503629&site=ehost-live

Guinan, P., Cooprider, J. & Sawyer, S. (1997). The effective use of automated application development tools. IBM Systems Journal, 36, 124. Retrieved July 24, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=9703061744&site=ehost-live

Narayanaswamy, R., Grover, V., & Henry, R. M. (2013). The impact of influence tactics in information system development projects: a control-loss perspective. Journal of Management Information Systems, 30, 191–226.Retrieved October 31, 2013, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=89799096&site=ehost-live

Procaccino, D., Verner, J. & Lorenzet, S. (2006). Defining and contributing to software development success. Communications of the ACM, 49, 79–83. Retrieved July 24, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=21638985&site=ehost-live

Ramasubbu, N., Bharadwaj, A., & Kumar Tayi, G. (2015). Software process diversity: Conceptualization, measurement, and analysis of impact on project performance. MIS Quarterly, 39(4), 787–807. Retrieved December 28, 2016, from EBSCO online database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=110877515&site=ehost-live&scope=site

Sakthivel, S. (1991). A survey of requirements verification techniques. Journal of Information Technology, 6, 68. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=5418120&site=ehost-live

Salisbury, W. D., Ferratt, T. W., & Wynn Jr., D. (2015). Issues and opinions: assessing the emphasis on information security in the systems analysis and design course. Communications of the Association for Information Systems, 36, 36337–356. Retrieved December 4, 2015, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=102116990&site=ehost-live&scope=site

Taylor-Cummings, A. (1998). Bridging the user-IS gap: A study of major information systems projects. Journal of Information Technology, 13, 29–54. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=3869888&site=ehost-live

Suggested Reading

Beynon-Davies, P., Tudhope, D., & Mackay, H. (1999). Information systems prototyping in practice. Journal of Information Technology, 14, 107–120. Retrieved July 30, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=3869904&site=ehost-live

Gardner, S. (1998). Building the data warehouse. Communications of the ACM, 41, 52–60. Retrieved July 13, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=11950998&site=ehost-live

Hughes, J., & Wood-Harper, T. (1999). Systems development as a research act. Journal of Information Technology, 14, 83–94. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=3869907&site=ehost-live

Iivari, J., & Huisman, M. (2007). The relationship between organizational culture and the deployment of systems development methodologies. MIS Quarterly, 31, 35–58. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=23963630&site=ehost-live

Jackson, T. (2016). Bid adieu to traditional IT. Public Management (00333611), 98(11), 22–23. Retrieved December 28, 2016, from EBSCO online database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=119547240&site=ehost-live&scope=site

Kettinger, W. J.; Grover, V.; Guha, S. & Segars, A. H. (1994). Strategic information systems revisited: A study in sustainability and performance. MIS Quarterly, 18, 31. Retrieved June 25, 2007, from EBSCO Online Database Academic Source Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=9503310355&site=ehost-live

Korpela, M., Mursu, A., & Soriyan, H. (2002). Information systems development as an activity. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 11(1/2), 111–128. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=11357818&site=ehost-live

Nelson, A., & Teng, J. (2000). Do systems development methodologies and CASE tools decrease stress among systems analysts? Behaviour & Information Technology, 19, 307–313. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=3961774&site=ehost-live.

Sandblad, B., Gulliksen, J., borg, C., Boivie, I., Persson, J., Gouml; Ransson, B., et al. (2003). Work environment and computer systems development. Behaviour & Information Technology, 22, 375–387. Retrieved July 23, 2007, from EBSCO Online Database Academic Search Premier. http://search.ebscohost.com/login.aspx?direct=true&db=aph&AN=11502191&site=ehost-live

Wallace, P. (2015). Introduction to information systems. Boston, MA: Pearson.