System Description and Specification

The engineer’s first task is understanding the system, the second one is specifying it, and the third one is building it. Analysis must precede specification since it is impossible to define or describe what is unknown. Specification must precede construction, since we cannot build what has not been defined. The first two tasks (understanding and defining the system) can be quite challenging in the software development field, particularly regarding small- to medium-size projects.

2.0 System Analysis Phase

The engineer’s first task is understanding the system, the second one is specifying it, and the third one is building it. Analysis must precede specification since it is impossible to define or describe what is unknown. Specification must precede construction, since we cannot build what has not been defined. The first two tasks (understanding and defining the system) can be quite challenging in the software development field, particularly regarding small- to medium-size projects. The system analysis phase refers to the evaluation of an existing system. Therefore it may be arguable that this phase can be skipped when implementing a system which has no predecessor. In any case, we should not assume that the analysis phase can be circumvented simply because a system has been judged obsolete or because a decision has already been reached regarding its replacement. Outdated, obsolete, and even totally unsuitable systems may contain information that is necessary or convenient for designing and implementing a new one. Very rarely would it be advisable to completely discard an existing system without analyzing its operation, performance, and implementation characteristics. At the same time, the feasibility of a new system must often be determined independently of the one being replaced. In fact, a system’s feasibility should be evaluated even when it has no predecessor.

2.0.1 The System Analyst

In the information systems world the specialist attempting to understand and define a software system is usually called the system analyst. In computer science-oriented environments this person is often referred to as a systems engineer. Other terms used to describe this computer professional are programmer analyst, systems designer, systems consultant, information system analyst, and information system engineer. Under whatever name, the systems analyst’s job description is usually quite different from that of a programmer. While the responsibility of a programmer ends with the computer program, the analyst’s duties extend into management and administration. Typically the analyst is responsible for equipment, procedures, and databases. Furthermore, the system analyst is usually in charge of the software development team. Therefore, the analyst’s job requires management skills in addition to technical competence. Oral and written communications skills are often necessary since the analyst usually has to perform presentations to clients, lead specifications discussions, and oversee the generation of multiple documents and reports. Programming and system-building projects are usually directed by a lead or principal analyst, who may take on the responsibility of managing and overseeing the activities of a team of analysts, programmers, program designers, software testers, and documentation specialists. The ideal profile for the principal system analyst is that of an experienced programmer and program designer (preferably holding a graduate degree in computer science or information systems) who has experience and training in business. In addition, the lead analyst should be a person who has successfully directed the analysis and development of software or systems projects of comparable complexity. The job description includes gathering and analyzing data, executing feasibility studies of development projects, designing, developing, installing, and operating computer systems, and performing presentations, recommendations, and technical specifications.

However, the smaller software project can rarely count on the services of an ideally-qualified lead analyst. Quite often a person with less-than-optimal skills is appointed to the task. In this respect it is important for the project directors to realize that it is the lead system analyst, or project manager, who should be the most highly qualified member of the development team. One common mistake is to think of the principal analyst as a chore that can be undertaken by a professional administrator with little or no technical knowledge. Another is to judge that the personnel with higher technical qualifications are best employed as programmers or program designers. Experience shows that appointing someone who is not the most highly qualified and technically competent member of the development team to the task of lead system analyst is an invitation to disaster.

Although the lead system analyst often wears many hats, the most necessary skills for this job are technical ones. A competent programmer and designer can be coached or supported in administrative and business functions and helped regarding communication skills. But it would be indeed astonishing that a person without the necessary technical skills could analyze, specify, and direct a systems development project.

2.0.2 Analysis and Project Context

The conventional treatment of systems analysis, as found in most current text and reference books, assumes that a typical project consists of developing a commercial system to be implemented in a particular business enterprise. In this context the systems analysis phase consists of evaluating and describing the existing system and its bottom line is determining whether the new system will be a realistic and profitable venture. This business system orientation is typical of computer information systems and management information systems programs as taught in many of our universities. On the other hand, the software engineering textbooks (sometimes considered as the counterpart of systems analysis in a computer science curricula) view the analysis phase more from a systems modeling point and usually stress the requirements analysis element in this development phase.

In other words, the term systems analysis has different connotations when seen from the information systems viewpoint than when seen from a computer science perspective. Furthermore, sometimes neither perspective exactly suits the problem at hand. For example, to assume that a typical systems development project consists of replacing an outdated business payroll program (information systems viewpoint) or designing a new, more efficient operating system (computer science viewpoint) leaves out many other real-life scenarios. For example, a development project could be an experimental, scientific, or research enterprise for which there is no precedent and in which profit is not a factor. Or it may consist of creating a software product that will be marketed to the public, such as a word processor application, a computer game, or a toolkit for performing engineering calculations. In either case, many of the systems analysis operations and details, as described in

books on systems analysis and design or on software engineering, are not pertinent.
Another conceptualization that can vary with project context relates to the components of a computer system. Normally we think of a computer system as an integration of hardware and software elements. Therefore systems engineering consists both of hardware systems and software systems engineering. Therefore, the systems analysis phase embodies an investigation and specification of the hardware and the software subsystems. In reality it often happens that either the hardware or the software elements of a computer system take on a disproportionate importance in a particular project. For instance, in a project consisting of developing a computer program to be marketed as a product to the user community, the hardware engineering element becomes much less important than the software engineering ingredient. Under different circumstances the relative importance of hardware and software elements could be reversed. Consequently, the details of the systems analysis phase often depend on project context. What is applicable and pertinent in a typical business development scenario, or in a technical development setting, may have to be modified to suit a particular case. Two elements of this phase are generally crucial to project success: the feasibility study and the project requirements analysis. Each of these activities is discussed in the following

sections.

2.1 The Feasibility Study

Often a software development project starts with a sketchy and tentative idea whose practicality has not been yet determined. Other projects are initially well defined and enjoy the presumption of being suitable and justified. In the first case the systems analyst must begin work by performing a technical study that will determine if the project is feasible or not. According to Pressman, given unlimited time and resources, all projects are feasible. But in the real world resources are limited and often a project’s feasibility is equated with the economic benefits that can be expected from its completion. This excludes systems for national defense, investigative and research projects, or any development endeavor in which financial returns are not a critical consideration.

In most cases the first project activity is called the feasibility or preliminary study. It can be broken down into the following categories:

1. Technical feasibility is an evaluation that determines if the proposed system is technologically possible. Intended functions, performance, and operational constraints determine the project’s technical

feasibility.

2. Economic feasibility is an evaluation of the monetary cost in terms of human and material resources that must be invested in its development, compared with the possible financial benefits and other

advantages which can be realistically anticipated from the project’s completion.

3. Legal feasibility is an evaluation of the legal violations and liabilities that could result from the system’s development.

Before the feasibility study phase begins, intermediate and high-level management (often in consultation with the lead analyst) must determine if the effort will be advantageous and how much time and resources will be invested in this phase. It is difficult to define arbitrary rules in this respect since the convenience of a feasibility study as well as the time and human resources devoted to it are frequently determined by financial and practical considerations. It is reasonable to expect that a minor development project, anticipated to generate large revenues and requiring a relatively small investment, will often be undertaken with a less rigorous feasibility study than a major project involving greater complexity and uncertainty. Two business management techniques are often used in the feasibility study phase of a system analysis: risk analysis and cost-benefits analysis. By means of risk analysis we attempt to establish the dangers associated with the project and to define the points at which it is preferable to cancel the project than to continue it. By means of cost-benefit analysis we attempt to measure the gains that will result from developing the system and the expenses associated with it. A feasible project is one in which the risks and costs are acceptable in consideration of its expected benefits.

Some books on systems analysis and design propose that risk analysis and cost-benefits analysis are activities that precede the main system analysis effort. Therefore, they should be considered as parts of a phase sometimes called the preliminary analysis. The rationale for this approach is that if a project is judged to be not feasible or financially not justifiable, then no further analysis or design effort is necessary. This is consistent with the accepted definition of risk analysis as a technique that serves to ascertain a project’s technical feasibility, and cost-benefits analysis as a method to determine the project’s economic feasibility. In reality, the technical and economic feasibility of many projects are taken for granted. In these cases risk analysis and cost-benefit analysis become either a formality, or as a justification of the original assumptions. The analyst should keep in mind that loss of objectivity in risk analysis or cost-benefit analysis renders these activities virtually useless.

A unique problem-set of the smaller-size software project is that technically qualified personnel for performing feasibility studies and cost-benefit analysis are often not available. Therefore, linking the feasibility study to risk analysis and cost-benefit analysis techniques may result in no feasibility study being performed. Since in most system development projects it is important that some form of feasibility study be executed, to the highest degree of rigor that circumstances permit, then it is preferable to consider risk analysis and cost-benefit analysis as alternative phases. The project feasibility flowchart in Figure 2.1 illustrates this view.

A word of caution regarding the feasibility study relates to the fact that those performing it may have a vested interest in the results. For example, we may suspect that the feasibility study could turn into a self-fulfilling prophesy if it is performed by a software company that is likely to be the eventual project developer. In such cases it may be advisable to contract an independent consultant to either perform or evaluate the feasibility study, thus assuring the objectivity of the results.

2.1.1 Risk Analysis

One of the factors considered in the feasibility study is the project’s risk. For example, a large project, with a great potential for financial gain, could be a big risk if it could lead to a costly lawsuit. In this case a detailed analysis of this risk factor is indicated. By the same token, a small project, with questionable technical and economic feasibility, could be a desirable risk if its successful completion represents a substantial gain. In this case the potential for gain may make it acceptable to undertake the project even if the feasibility study has determined that the possibilities for its completion are doubtful. In other words, the project is judged to be a good gamble.
 
Figure 2.1 Project Feasibility Flowchart
Risk analysis is usually associated with the following activities:

1. risk identification

2. risk estimation

3. risk assessment

4. risk management

We discuss each of these risk-related operations separately.