Systems Analysis: History, Concepts And Theories

One could unarguably suggest that systems exist, in various forms, since the dawn of time. From the Solar System, to our planet’s ecosystem, to the human societies where people gathered into teams to hunt animals or farm the land to be able to survive, all are prime examples of thousand years old systems. By definition, a system could be described as “any entity, conceptual or physical, which consists of interdependent parts” (Ackoff, 1960).

As the human-controlled systems (i.e. society, organizations, information systems and business systems) started to become increasingly more complex, various issues appeared like an increase of costs, harder maintenance and more administrative complexities. The need to overcome and solve all these problems led to the appearance of the field of Systems Analysis.

Systems Analysis: History, Concepts & Theories

The analysis, as defined in the Oxford Dictionary, is the “separation of a substance into parts for study and interpretation; detailed examination”. Subsequently, Systems Analysis could be described as the early process in the development of a new system, or the evaluation of an old one, where the analysts try to investigate a given situation, identify the main problems that need to be solved, break them up into sub-problems if needed, and finally recommend the most efficient and costless way to solve them (Yeates et al, 1994; Silver et al, 1989; Bingham et al, 1978). Plato once said: “the beginning is the most important part of work”. Nowadays, Plato’s words are proved far from wrong in the case of developing or evaluating a system. The first steps of working on a new project are probably the most important ones to guarantee any fair chance of success. This is the main reason why many organizations, companies and governments prefer to spend a significant amount of money in the early stages of development, in order to be able to minimize the risk of potential disaster later on (Daniels et al, 1981). After all, the sooner a mistake is identified, the sooner it will be fixed, saving a lot of effort, time and money.

There are many types of human-controlled systems, as previously mentioned, ranging from large-scale, complex human societies (whose boundaries are usually not so easy to define as they constantly interact with other societies near them), to small-scale computer information systems (whose boundaries are easier to define). Although each key author and researcher tried to describe his own concept of what analysis is and why it is critical to apply it in the development process, their thoughts and views share many common elements. Depending on the type of system they concentrated on, various definitions where given.

To begin with, Systems Analysis is the process of investigating a system’s boundaries, users, processes, inputs and outputs with the aim of suggesting more efficient and economical ways to solve the problems in question (Silver et al, 1989). Another, more general suggestion is that Systems Analysis “refers to an orderly, structured process for identifying and solving problems” (Gore et al, 1983). Finally, according to George Marshall in his book Systems Analysis and Design: Alternative Structured Approaches, Systems Analysis is “the process of defining precisely what a computer system should do” (Marshall, 1986).

Igor Hawryszkiewycz describes in his book Introduction to Systems Analysis and Design that analysis is mainly used in order to effectively understand the structure of a system and what its requirements are (Hawryszkiewycz, 1994). John Bingham in his book A Handbook of Systems Analysis describes the analysis in six steps: the project selection, the feasibility study, the definition phase, the design phase, the implementation phase and finally the evaluation phase (Bingham et al, 1978).

Perhaps one of the most straightforward explanations of Systems Analysis main objective is that it aims to “transform user needs into specifications for programmers” (Marshall, 1989). To achieve this, the systems analyst has to complete five tasks and responsibilities: to plan, investigate, understand, document and communicate with the rest of the team (Yeates et al, 1994). Firstly and probably most importantly too, the analyst must study the feasibility of the system. This means that he has to thoroughly search and decide if it is humanly possible to develop the system and how much effort in time and money it will cost to do so. Second step is to discuss with the system’s target group and find out their needs in order to be able to understand and elicit the requirements. Third step is to research the existing data, human recourses and available computer procedures to find out the limitations, techniques or methods that will be used in the later stages of development. Usually from this phase and on the analyst works close together with the designers, programmers and testers in order to establish a successful communication between the team and share feedback with them (Parkin, 1980; Daniels et al, 1981; Open University, 1982).

Although the human-controllable systems are in existence ages now, Systems Analysis as a scientific field is quite more recent, and its roots can be traced back a few decades. Before computers became mainstream, the first analysts where using more traditional approaches to analyze and solve the given problems. They followed two main steps: firstly they analyzed the project’s requirements and secondly they specified these requirements. Although this practice was logical and theoretically correct, it depended too much on the human factor, which means it was prone to mistakes. Among the disadvantages of the traditional approach was that it required vast amounts of written documentation, many times there was a lack of communication between the analysts and the designers and last but not least it was very time consuming. All these negatives caused a great number of system development projects to face difficulties during the analysis phase in the 1970s (Yeates et al, 1994).

Researchers in the field of Systems Analysis, in an effort to overcome all the problems caused by the traditional approach, focused their attention to develop new, more efficient methods of analysis. The result of the above efforts was a structured approach to analysis (Yourdon, 1976; DeMarco, 1979; Bansler, 1993). This approach, as described in the book Systems Analysis and Design by Don Yeates et al, follows three general principles: modeling, partitioning and iteration. Modeling is the extended use of models, diagrams, data flow charts and other graphic representations, which aim to provide a non-confusing, realistic image of the system to the rest of the development team. Partitioning is the method of dividing the system in question to sub-systems with the aim of making them more understandable to the rest of the team. Moreover, partitioning helps the analyst to decide which part of the whole problem every member of the team will be given to solve. Iteration is the method of constantly repeating the analysis stage, as many times as needed, in order to reach the best possible solution. The need for iteration arises from the fact that it is rare for a system to be represented correctly the first time, as many repetitions are usually needed, in order to achieve a standard of accuracy (Yeates et al, 1994).

Following the appearance of a more structured and formal way of analyzing a system, researchers were trying to come up with various models, which held a central role for Systems Analysis. These models, if strictly followed, would significantly enhance the development process. The early software development models though, such as the Waterfall Model (Royce, 1970), did not allow a lot of room for feedback and changes because of their linear structure. In contrast to these early models, modified approaches like the V-Model (German Ministry of Defense, 1992) and the Spiral Model (Boehm, 1988) gave the analyst the flexibility to interact with the rest of the team even in the later development phases. This is particularly important for the sole reason that, as discussed earlier, Systems Analysis is one of the most crucial phases during a system’s creation. By providing the team the option to interact with the analyst “on the go”, it can minimize the time needed for system revision and most importantly save a lot of time and money.

Although return of investment and risk minimization are two of the most salient reasons of why Systems Analysis is so important, there are a lot more benefits to be gained in the long term. The efficiency of the project team is greatly enhanced as goals are reached faster and the available resources are used more wisely. Furthermore, errors are recognized earlier which translates to less time invested in testing during the final phases of a project, which in its own turn leads again to more profit (Silver et al, 1989).

It is very important also to mention that nowadays systems become so complex that usually consist of multiple subsystems, each one playing a key role in the whole process. These subsystems coexist and highly depend on each other. Any change that may occur in any of them could affect multiple other subsystems of the whole. It is critical for the analysts to spend a considerable amount of time and effort to understand the system as one single entity and identify all of its problems. Only after a thorough study of the system they will be able to really understand its purpose and support the development team in creating a system that will be safe, robust and effective (Hawryszkiewycz, 1994).

In 1994, a study by the Standish Group provides a better understanding of how valuable the correct application of analysis during a systems development phase is. The company studied eight thousand software projects undertaken by 350 different companies in order to see how successful the development process was. The results were disastrous as around 31% of the projects were cancelled before they make it to the production phase (Standish, 1994). When in further study, these companies were asked about the reasons for these failures, more than 54% answered that it was various problems during the analysis phase (Standish, 1995).

Systems analysis though is not a cure-all medicine. Like all approaches in system development, it has its own disadvantages and limitations. Some company, for example, could have so many internal problems, financial or not, that a single Systems Analysis, even the best one possible, could not be enough to save it from bankruptcy. Another disadvantage is that Systems Analysis costs a lot of money and time (Silver et al, 1989). Although, it has been proven many times that projects that went through a thorough System Analysis phase had greater chances to become successful, its still not a guarantee. As the human factor never stops to play a vital role in the whole development process, there is always the risk that something is mistakenly overlooked (i.e. a bug in the code that escapes the final testing phase), which leads to a fault product in the production line, which in turn leads to less sales or even stigmatize the organization’s “good name”.

Conclusion

Systems Analysis has become a necessity, a highly important and integral tool that development teams, governments and companies use to enhance their productivity and raise their profit margins (Silver et al, 1989). As people say: “money makes the world go round”, and this is especially true nowadays that organizations put even more effort to identify and satisfy their needs in the most effective and efficient way. Systems and projects become even more sophisticated, even more advanced, even more complex and even more critical for the safety of the users. Developers must be able to adapt in this ever-changing environment if they want to survive in the highly competitive world of today. For all these reasons, Systems Analysis continues to play a key role, and researchers are trying constantly to find new ways to make it even more efficient in the future.