Article Index
System Description and Specification
Page 2
Page 3
Page 4
Page 5
All Pages

System Description and Specification

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.

Risk Identification

Consists of categorizing risk into particular fields. In this sense project risk relates to budget, schedule, and staffing problems that may impact development. In this sense project type and complexity may pose additional risk factors. Technical risk is related to the possibility of encountering difficulties that were not initially anticipated. For example, an unexpected development in the field may make a project technically obsolete. Business risk, perhaps the most deluding one, relates to market changes, company strategy changes, sale difficulties, loss of management support, and loss of budgetary support.

Risk Estimation

In this phase of risk analysis we attempt to rate the likelihood and consequences of each risk. The first step is to establish the risk probability, the second one to describe the consequences of the risk, the third one to estimate the risk’s impact on the project, and finally to determine the accuracy of the risk estimate itself. These four items can be quantified with a “yes” or “no” answer, but a better approach is to establish a probability rating for risk likelihood, consequence, impact, and projection accuracy. Historical data collected by the developers can often serve to quantify some of the project risks. As a general rule we can assume that the higher the probability of occurrence and impact of a risk the more concern that it should generate.

Risk Assessment

Is based on the aforementioned impact and probability of occurrence of a risk, as determined during the risk estimation phase. The accuracy of the risk estimate is also a factor that must be taken into account. The first task at this stage is the establishment of acceptable risk levels for the project’s critical activities. For system development projects three typical critical activities are cost, schedule, and performance. A degradation of one or more of these factors will determine the project’s termination. Risk analysts talk about a referent point (or break point) at which the decision to terminate or continue a project is equally acceptable. Since risk analysis is not an exact science, the break point can better be visualized as a break area.

Figure 2.2 Referent Level in Risk Assessment

Figure 2.2 shows the effects of cost and schedule overruns on a software project. The dark region bound by the curves (the uncertainty or break area) represents the region in which the decisions to stop or continue the project are approximately of equal weight. Below this area is the go region, in which the project continues without question. The area above the curve (no-go region) represents conditions that determine the cancellation of the project. Note that in Figure 2.2 we have considered only two project risks; often there are others that can influence the decision to terminate. The reader should not assign any meaning to the particular shape of the curve in Figure 2.2. The fact that it is not uniform simply indicates that the uncertainty factor in risk assessment may not be a smooth function.

The following steps are usually followed during the risk assessment process:

1. The referent level is defined for each significant risk in the project.

2. The relationship between the risk, its likelihood, and its impact on the project is established for each referent level.

3. The termination region and the uncertainty area are defined.

4. An attempt is made to anticipate how a compound risk will affect the referent level for each participating risk.

Risk Management

Once the elements of risk description, likelihood, and impact have been established for each project risk, they can be used to minimize the particular risk or its effects. For example, assume that the analysis of historical data and the risk estimation process determine that for the particular project there is a substantial risk of schedule overruns due to low programmer productivity. Knowing this, management can attempt to locate alternative manpower sources which could be tapped if the identified risk is realized. Or perhaps steps can be taken to improve productivity by identifying the causes of low programmer output. Risk management, in itself, can become costly and time-consuming. Scores of risks can be identified in a large development project. Each risk may be associated with several risk management measures. Keeping track of risks and remedies can become a major project in itself. Therefore, managers and directors must sometimes perform cost-benefit analysis of the risk management activities to determine how it will impact project cost. The Pareto principle, sometimes called the 80/20 rule, states that 80 percent of project failures are related to 20 percent of identified risks. The risk analysis phase should help recognize this critical 20 percent, and eliminate the less significant risks from the risk management plan.

2.1.2 Risk Analysis in a Smaller Project

Risk analysis is a specialty field on which numerous monographs and textbooks have been published. A frivolous or careless attempt at risk analysis and management is often counterproductive. In the smaller software project it is common that specialized personnel are unavailable to perform accurate risk analysis. Furthermore, even if technically qualified personnel could be found, it is doubtful that a formal risk investigation would be economically justified. Consequently, most smaller projects take place with no real risk analysis and without a risk management plan. In this case the feasibility study or other project documents should clearly state that risk analysis and risk management efforts have not been performed, the reasons why this step was skipped, and the dangers that can result from the omission.Perhaps a greater danger than the total omission of a formal risk analysis is its trivialization. When risk analysis has been performed superficially, with little rigor, and by untrained personnel, the most likely results are the identification of unreal risks, or, worse, a false feeling of confidence resulting from a plan that has failed to identify the real perils associated with the project. If the risk analysis and management have been performed with less-than-adequate resources then the resulting low accuracy of the risk projection should be clearly noted in the project documentation. Occasionally, it may be considered valid to attempt some form of perfunctory risk analysis for the purpose of gaining experience in this field or for experimenting with a specific methodology. This should also be clearly noted so that management does not place undue confidence in the resulting plan.

Table 2.1 is a variation of the risk management and monitoring plan as presented by Charette. We have simplified the plan to include only those elements that, in our judgment, should never be omitted. Most computer systems development projects demand a tangible economic benefit. This does not mean that every system must generate a profit, but rather that the expected benefits must justify the cost. Exceptions to this rule are systems that are legally mandated or those whose purpose is beyond economic analysis, as could be the case with a project for national defense, or a scientific or academic experiment. Under normal circumstances the system’s economic justification is the most important result of the feasibility study since it is a critical factor in deciding project support.

Table 2.1 Simplification of a Risk Management Outline

I. Introduction

II. Risk Analysis

1. Risk Identification

a. Risk Survey

b. Risk Item Checklist

2. Risk Estimation

a. Probability of Risk

b. Consequence of Risk

c. Estimation Error

3. Risk Evaluation

a. Evaluation of Risk Analysis Methods

b. Evaluation of Risk Referents

c. Evaluation of Results

III. Risk Management

1. Recommendations

2. Options for Risk Aversion

3. Risk Monitoring Procedures

2.1.3 Cost-Benefit Analysis

Cost-benefit analysis is a standard business evaluation instrument, but not all project results can be exactly measured in dollars and cents. Some systems bring about less tangible benefits that relate to factors such as the company’s long-term plans, a higher quality of product or services, or increased employee morale. It could be a taxing task to attempt to attach a dollar value to some of the less concrete project benefits. It is often preferable to include a category of intangible benefits in the cost-benefit analysis document rather than to attempt to quantify these gains. The reference point for evaluating the benefits of a new system is usually the existing system. For example, a manufacturer called Acme Corporation plans to upgrade its present inventory management system with a new one based on the use of bar codes to identify products in stock. The new system requires an investment of $500,000 in software and computer equipment but has the following advantages:

1. The number of employees used in inventory management functions will be reduced by 4. This will bring about a saving of $90,000 per year.

2. The flow of materials and supplies to the assembly line will be improved, with an estimated reduction in lost time of 200 work hours per month. Since an hour of lost time at the assembly line costs

the company $12, this will bring about a saving of $2400 per month.

3. The better control of stocks will allow the company to reduce the size of its inventory. The smaller investment and the reduction in warehousing costs is estimated to bring the company a saving of

$20,000 per year.

In this case the cost-benefit analysis could appear as follows:

Acme Corporation

Cost-benefit analysis for new inventory management system over a 5-year period

1. COST

a. Computer and peripherals ................................. $300,000

b. Software ................................................. 110,000

c. Installation and technical support ....................... 90,000
===============

total investment ................. $500,000

2. BENEFITS

a. Personnel reductions .......... $450,000

b. Reductions in down time ....... 144,000

c. Savings in inventory costs .... 100,000

===============

total savings ............... $694,000

Balance ..................... $194,000

In the case of Acme Corporation the benefits over a five-year period are relatively modest. Therefore it is likely that Acme’s higher management would like to see a more detailed and accurate analysis before committing to a major overhaul of the company’s existing system. On the other hand, some systems can be economically justified clearly and definitively. Under different circumstances the development and implementation of a computerized inventory control would bring about savings that leave no doubt regarding the project’s benefits, even without considering less tangible factors such as improvements in distribution operations.

2.2 Requirements Analysis and Specification

Once the feasibility of a proposed system has been established, the next task that the analyst must undertake is defining the system’s requirements. Requirements analysis, or requirements engineering as it is sometimes called, has been considered a critical phase of computer systems development since the original conception of an engineering methodology for software development. The fundamental notion consists of generating an unambiguous and consistent specification that describes the essential functions of the proposed system. In other words, the specifications phase of the system development process must describe what the system is to do. How it is to do it is addressed during the design phase.

2.2.1 The Requirements Analysis Phase

Before the systems requirements can be specified, the interface between the system and the real world must be analyzed. Based on this interface, a set of specifications of the software requirements is developed. The documents containing the program specification play a decisive role during the entire development process. For example, the development of a software system to control the operation of a probe vehicle via remote to operate on the surface of the planet Mars should be based on a detailed analysis of the interface requirements. In this case the following elements may be considered critical:

1. What information is returned by the sensors on the Mars probe.

2. What vehicle operation controls installed on the probe are governed by the software.

3. What is the time lapse between perception by the probe’s sensors and reception by the earth system.

4. What is the time lapse between a command issued by the earth system and its execution by the probe.

The analysis of this data helps determine the operational specification of the system. In this case the delay in receiving information and transmitting commands may require that upon sensing certain types of obstacles, the vehicle come to a stop until a command signal is received. In this case the requirements analysis phase serves to define the system specifications. Concrete system specification guidelines result from the requirements analysis phase. In particular this could refer to difficulties, tradeoffs, and conflicting constraints; also from the functional and nonfunctional requirements. Functional requirements are those which are absolutely essential while the nonfunctional ones are merely desirable features. In this sense a functional requirement of the Martian probe could be that the vehicle not be damaged by obstacles in its path. A nonfunctional requirement could be that given several possible safe paths to a destination point, the software selects the one that can be traversed in the shortest time.

Customer/User Participation

An ideal scenario is that the customer, client, or eventual user of a system provides the detailed specification. In this “neat” world all the developer has to do is implement a system according to these specifications thus ensuring that the client’s needs are thoroughly satisfied. In reality the customer/user often has little more than a sketchy idea of the intended system; its specification must be developed through a series of interviews, proposals, models, and revisions. Communications skills and systems analysis experience are important factors in the success of this difficult and critical phase.

The developer of systems specifications must not assume that a customer does not really know what he or she wants. It is the client’s system, not the developer’s. New systems often encounter considerable resistance from employees who must devote time and effort to learning its operation, often with little or no compensation. Furthermore, employees may feel threatened by a new system which could make their jobs unnecessary. The more participation that clients and users have in the systems specifications and definition the less resistance that they will present to its implementation. If there is a single secret to being a successful analyst it is to maximize the client’s participation in the specification, design, development, and implementation phases, thus making sure that the participants include those who will be the effective users of the new system. A regrettable situation is that the developer initially deals with an administrative elite, while the actual systems operators, administrators, and users do not become visible until much later in the development process.

The Virtual Customer

While in many development projects there is a clearly identifiable customer, in others the client role is not quite visible. For example, a software company developing a program that is to be marketed to the public may not have a visible client who can participate in the system’s specification, design, and development phases. Another example: a research group at a university or a private firm is often confronted with the task of developing a program for which no user or client is immediately at hand. The customer/user element plays such an important role in the development process that in these cases it may be advisable to invent some sort of a virtual participant to play this role. In the context of research and development, the team’s director sometimes takes on this function. Or perhaps a higher level of management will play the devil’s advocate for the duration. As separation of powers ensures the operation of a democracy, separation of interests between clients and developers promotes the creation of better systems. When this duality does not naturally exist, creating it fictitiously may be an option.

2.2.2 The Specifications Phase

Once the systems requirements have been determined the analyst creates a list of program specifications. These specifications serve to design, code, and test the proposed program and, eventually, validate the entire development effort; their importance can hardly be overstressed. Since specifications are derived directly from the requirement analysis documents, a preliminary step to

composing a list of specifications is to validate the requirements analysis phase. Whatever method or notation is used in requirements analysis, the following goals should be achieved:

1. Information contents and flow are determined.

2. Processes are defined.

3. Systems interfaces are established.

4. Layers of abstraction are drawn and processing tasks are partitioned into functions.

5. A diagram of the system essentials and its implementation is made.

We can adopt varying degrees of formality and rigor in composing the actual specifications. Many difficulties in system design and coding can be traced to imprecise specifications. The English language (in fact, any natural language) contains terms and expressions that require interpretation. For example: the statement that a routine to calculate mathematical functions must do so with the “highest possible degree of precision” may seem a strict specification. However, at system design and coding time the expression “the highest possible degree of precision” has to be interpreted to mean one of the following:

1. The precision of the most accurate computer in the world.

2. The precision of the most accurate machine of a certain type.

3. The highest precision that can be achieved in any high-level language.

4. The highest precision that can be achieved in a particular programming language.

5. The highest precision that can be achieved in a certain machine.

6. The highest precision that will be required by the most demanding user or application.

7. The highest degree of precision that will be required by the average user or application.

This list could be easily expanded to include many other alternatives. On the other hand, the specifications could have stated that mathematical functions will be calculated “so that the resulting error will not exceed 20 units of machine Epsilon.” In this case very little interpretation is possible at design or coding time. Furthermore, the specification could later be used to validate the resulting product by performing tests that ascertain that the numerical error of the mathematical calculations is within the allowed error range. In recent years the software engineering and programming communities have moved towards stricter and more formal methods of specification, some of which are discussed later in this section. The analyst should be wary of imprecise terms and expressions in the specification documents and should aim at describing the problems and tasks at hand in the least unambiguous terms possible.

The Software Specifications Document

The Software Specifications Document (SSD), also called the Software Requirements Specification, is the culmination and the conclusion of the system analysis. The elements always present in the SSD include the following:

1. An information description

2. A functional description

3. A list of performance requirements

4. A list of design constraints

5. A system testing parameters and a criterion for validation

The National Bureau of Standards, the IEEE, and others have proposed formats for the SSD. Table 2.2 is a simplified outline of the fundamental topics that must be visited in this document.

Headington and Riley propose a six-step program specifications plan consisting of the following parts:

1. Problem title

2. Description

3. Input specifications

4. Output specifications

5. Error handling

6. Sample program execution (test suite)

Table 2.2 Outline of the Software Specifications Document

I. Introduction

1. Purpose and Scope

2. System Overview

3. General Description and Constraints

II. Standards and Conventions

III. Environment Elements

1. Hardware Environment

2. Software Environment

3. Interfaces

IV. Software Specifications

1. Information Flow

2. Information Contents

3. Functional Organization

4. Description of Operations

5. Description of Control Functions

6. Description of System Behavior

7. Database and Data Structures

V. Testing and Validation

1. Performance Parameters

2. Tests and Expected Response

3. Validation Protocol

VI. Appendices

1. Glossary

2. References

Although this simplification is intended for the specification of small projects within the context of an undergraduate course in C++ programming, it does cover the fundamental elements. Even if it is not used as a model, it may be a good idea to check the actual specification against this plan.

2.3.3 Formal and Semiformal Specifications

The proposers of formal specifications methods postulate that software development will be revolutionized by describing and modeling programs using strict syntax and semantics based on a mathematical notation. The fundamentals of formal specification are in set theory and the predicate calculus. The main advantages of formal specifications are their lack of ambiguity and their consistency and completeness, thus eliminating the many possible interpretations that often result from problem descriptions in a natural language. Of these attributes, lack of ambiguity results from the use of mathematical notation and logical symbolism. Consistency can be ensured by proving mathematically that the statements in the specification can be derived from the initial facts. However, completeness is difficult to ensure even when using formal methods of specification, since program elements can be purposefully or accidentally omitted from the specification. The original notion of applying the methods of the predicate calculus to problems in computing, and, in particular to the formal development of programs, is usually attributed to Professor Edsger W. Dijkstra (University of Texas, Austin TX, USA) who achieved considerable fame in the field of structured programming, first expressed his ideas in a book titled A Discipline of Programming. Professor David Gries (Cornell Univeristy, Ithaca NY, USA) and Edward Cohen have also made major contributions to this field.

One of the most interesting postulates made by the advocates of formal specifications is that once a program is mathematically described it can be coded automatically. In this manner it is claimed that formal specifications will eventually lead into automated programming, and thus, to the final solution of the software crisis.
In this book we have opted not to discuss the details of formal specifications for the following reasons:

1. So far, the viability of this method has been proven only for rather small programs dealing with problems of a specific and limited nature.

2. The use of this method assumes mathematical maturity and training in formal logic. It is considered difficult to learn and use.

3. Although formal specifications, program proving, and automated coding have gained considerable ground in recent years, these methods are not yet established in the systems analysis and programming mainstream. Many still consider them more an academic refinement than a practical procedure.

2.3.4 Assertions Notation

Although formal specification methods have not yet achieved the status of a practical methodology applicable in general systems analysis and programming, there is little doubt that reducing the ambiguity and inconsistency of natural languages is a desirable achievement in the software specifications stage. Some current authors of programming textbooks (including Headington and Riley) have adopted a method of program documentation which can also serve as a model for semiformal specifications. This technique, sometimes referred to as an assertion notation, consists of a specific style of comments that are inserted into the code so as to define the state of computation. Although assertions were originally proposed as a code documentation technique, the notation can also be used as a semiformal method of specification during the analysis phase. The following types of assertion are described:

ASSERT

This comment header describes the state of computation at a particular point in the code. Before this notation was suggested, some programmers inserted comments in their code with headers such as AT THIS POINT: that performed a functionally equivalent purpose. The idea of the ASSERT: header is to state what is certainly known about variables and other program objects so that this information can be used in designing and testing the code that follows.

Consider the following C++ example: a function called Power() is implemented so that it returns a float, the result of raising a float-type base to an integer power. The resulting code could be documented as follows:

Power(base, index);

// ASSERT:

// Power() == base raised to index

// (variables base and index are unchanged by call)

Certain symbols and terms are often used in the context of assertions. For example, the term Assigned is used to represent variables and constants initialized to a value. This excludes the possibility of these elements containing “garbage.” In C++ assertions the symbols && are often used to represent logical AND, while the symbol || represents logical OR regarding the terms of the assertion. The symbol == is used to document a specific value and the symbol ?? indicates that the value is unknown or undeterminable at the time. Finally, the symbol —, or the word Implies, is sometimes used to represent logical implication. The programmer should also feel free to use other symbols and terms from mathematics, logic, or from the project’s specific context, as long as they are clear, unambiguous, and consistent.
INV

This comment header represents a loop invariant. It is an assertion which is used to describe a state of computation at a certain point within a loop. The intention of the loop invariant is to document the fundamental tasks to be performed by the loop. Since the invariant is inserted inside the loop body, its assertion must be true before the body executes, during every loop iteration, and immediately after the loop body has executed for the last time. The following example in C++ is a loop to initialize to zero all the elements of an array of integers.

// ASSERT:

// All set1[0 .. sizeof (Set1)/ sizeof (int)] == ??

for (int i = 0, i <= (sizeof (Set1) / sizeof (int)), i++)

// INV:

// 0 <=i <= elements in array

Set1[]

set1(i) = 0;

// ASSERT:

// All set1[0 .. sizeof (Set1) / sizeof *int)] == 0

In this example the number of elements in an array is determined at compile time using the C++ sizeof operator. The expression:

sizeof Set1

returns the number of bytes in array Set1. This value is divided by the number of bytes in the array data type to determine the number of elements. Although this way of determining the number of elements in an array is generally valid in C++, it should be used with caution since the calculation is only permissible if the array is visible to sizeof at the particular location in the code where it is used. The loop invariant states that at this point in the loop body the index to the array (variable i) is in the range 0 to number of array elements, which can be deduced from the loop statement.

PRE and POST

These comment headers are assertions associated with subroutines. In C++ they are used to establish the conditions that are expected at the entry and exit points of a function. Before the assertion notation was proposed some programmers used the terms ON ENTRY: and ON EXIT:

The PRE: assertion describes the elements (usually variables and constants) that must be supplied by the caller and the POST: assertion describes the state of computation at the moment the function concludes its execution. Thus, the PRE: and POST: conditions represent the terms of a contract between caller and function, stating that if the caller ensures that the PRE: assertion is true at call time, the function guarantees that the POST: assertion is satisfied at return time. For example, the following function named Swap() exchanges the values in two integer variables.

void Swap( int& var1, int& var2)

// PRE: Assigned var1 && var2

// POST: var1 == var2 && var2 == var1

{

int temp = var1;

var1 = var2;

vat 2 = temp;

return;

}

FCTVAL

This assertion is also used in the context of subroutines to indicate the returned value. In C++ FCTVAL represents the value returned by a function and associated with the function name. Therefore it should not be used to represent variables modified by the function. For example, the following trivial function returns the average of three real numbers passed by the caller.

float Avrg( float num1, float num2, float num3)

// PRE: Assigned num1 && num2 && num3

// num1 + num2 + num3

// POST: FCTVAL == ..........

// 3

{

return ((num1 + num2 + num3) / 3));

}

2.3 Tools for Process and Data Modeling

Technical methodologies for system development propose that the documents that result from the analysis phase serve as a base for the design phase. Therefore the more detailed, articulate, and clear the analysis documents, the more useful they will be in program design. One way to accomplish this is through the use of modeling tools that allow representing the essence of a system, usually in graphical terms. Many such tools have been proposed over the years and two have achieved widespread acceptance, namely, data flow diagrams and entity-relationship diagrams.

Data flow diagrams originated in, and are often associated with, structured analysis. Entity-relationship diagrams are linked with data base systems and with object-oriented methods. Nevertheless, we believe that either method is useful independently of the context or analysis school in which it originated. In fact, data flow diagrams and entity-relationship diagrams have been used in modeling processes and data flow in both the structured analysis and the object-oriented paradigms.

System modeling can be undertaken using varying degrees of abstraction. One type of model, sometimes called a physical or implementation model, addresses the technical details as well as the system’s essence. Program flowcharts are often considered as an implementation modeling tool since a flowchart defines how a particular process can be actually coded. Essential or conceptual models, on the other hand, are implementation independent. Their purpose is to depict what a system must do without addressing the issue of how it must do it.Although implementation models are useful in documenting and explaining existing systems, it is a general consensus among system analysis that conceptual models are to be preferred in the analysis phase. The following arguments are often listed in favor of conceptual models:

1. Some incorrect solutions that result from implementation-dependent models can be attributed to bias or ignorance on the part of the designers. A conceptual model, on the other hand, fosters creativity and promotes an independent and fresh approach to the problem’s solution.

2. Excessive concern with implementation details at system specification and analysis time takes our attention away from the fundamentals. This often leads to missing basic requirements in the specification.

3. Implementation-dependent models require a technical jargon that often constitutes a communications barrier between clients and developers.

The target of this modeling effort can be either an existing or a proposed system. In this respect we should keep in mind that the fundamental purpose of modeling an existing system is to learn from it. The learning experience can be boiled down to avoiding defects and taking advantage of desirable features.

2.3.1 Data Flow Diagrams

In his work on structured analysis DeMarco suggests that one of the additions required for the analysis phase is a graphical notation to model information flow. He then proceeds to create some of the essential graphical symbols and suggests a heuristic to be used with these symbols. A few years later Gane and Sarson refined this notation calling it a data flow diagram or DDF. A data flow diagram is a process modeling tool that graphically depicts the course of data thorough a system and the processing operations performed on this data. Figure 2.3 shows the basic symbols and notation used in data flow diagrams.

One variation often used in the Gane and Sarson notation is to represent processes by means of circles (sometimes called bubbles). A valid justification of this alternative is that circles are easier to draw than rounded rectangles. Processes are the core operation depicted in data flow diagrams. A process is often described as an action performed on incoming data in order to transform it. In this sense a process can be performed by a person, by a robot, or by software. Processes are usually labeled with action verbs, such as Pay, Deposit, or Transform, followed by a clause that describes the nature of the work performed. However, on higher level DFDs we sometimes see a general process described by a noun or noun phrase, such as accounting system, or image enhancement process. Routing processes that perform no operation on the data are usually omitted in essential DFDs. The operations performed by processes can be summarized as follows:

1. Perform computations or calculations

2. Make a decision

3. Modify a data flow by splitting, combining, filtering, or summarizing its original components

Internal or external agents or entities reside outside the system’s boundaries. They provide input and output into the system. In this sense they are often viewed as either sources or destinations. An agent is external if it is physically outside the system, for example, a customer or a supplier. Internal agents are located within the organization, but are logically outside of the system’s scope. For example, another department within the company can be considered as an internal agent. It is possible to vary the level of abstraction and magnification of details in a DFD. Some authors propose the designation of specific abstraction levels. In this sense a level 0 DFD, called a fundamental system model, consists of a single process bubble which represents the entire software system. A level I DFD could depict five or six processes which are included in the single process represented in the level 0 bubble. Although the notion that several DFDs can be used to represent different levels of abstraction is useful, the requirement that a specific number of processes be associated with each level could be too restrictive. Figure 2.4 shows an initial level of detail for representing a satellite imaging system.
Notice that in Figure 2.4 the process bubble has been refined with a header label that adds information regarding the process. In this case the header refers to who is to perform the process. Also notice that the processes are represented by noun phrases, which is consistent with the general nature of the diagram. Although this initial model provides some fundamental information about the system, it is missing many important details. For example, one satellite may be equipped with several sensing devices that generate different types of image data, each one requiring unique processing operations. Or a particular satellite may produce images that are secret; therefore, they should be tagged as such so that the delivery system does not make them available to unqualified customers. Figure 2.5 shows a second level refinement of the image processing system

The level of detail shown by the DDF in Figure 2.5 is much greater than that in Figure 2.4. From the refined model we can actually identify the various instruments on board the satellites and the operations that are performed on the image data produced by each instrument. However, the actual processing details are still omitted from the diagram, which are best postponed until the system design and implementation phases. Note that in Figure 2.5 the process names correct, format, and record are used as verbs, consistent with the greater level of detail shown by this model. Note that the names of satellites, instruments, and image formats do not exactly correspond to real ones.

Event Modeling
Many types of systems can be accurately represented by modeling data flow, but some cannot. For example, a burglar alarm system is event driven, as is the case with many real-time systems. First, Ward and Mellor, and later Hatley and Pribhai, introduced variations of the data flow diagram which are suitable for representing real-time systems or for the event-driven elements of conventional systems. The Ward and Mellor extensions to DFD symbols are shown in Figure 2.6.
The resulting model, called a control flow diagram or CFD, includes the symbols and functions of a conventional DFD plus others that allow the representation of control processes and continuous data flows required for modeling real-time systems. Equipped with this tool we are now able to model systems in which there is a combination of data and control elements. For example, a burglar alarm system as installed in a home or business includes a conventional data flow component as well as a control flow element. In this case the conventional data flow consists of user operations, such as activating and deactivating the system and installing or changing the password. The control flow elements are the signals emitted by sensors in windows and doors and the alarm mechanism that is triggered by these sensors. Figure 2.7 represents a CFD of a burglar alarm system.

2.3.2 Entity-Relationship Diagrams

Currently the most used tool in data modeling is the entity-relationship (E-R) diagram. This notation, first described in the early 1980s by Martin and later modified by Chen and Ross, is closely related to the entity-relationship model used in database design. E-R diagram symbols have been progressively refined and extended so that the method can be used to represent even the most minute details of the schema of a relational database. However, in the context of general system analysis we will restrict our discussion to the fundamental elements of the model. Since one of the fundamental operations of most computer systems is to manipulate and store data, data modeling is often a required step in the system analysis phase. E-R diagrams are often associated with database design; however, their fundamental purpose is the general representation of data objects and their relationship. Therefore the technique is quite suitable to data analysis and modeling in any context.

Furthermore, E-R notation can be readily used to represent objects and object-type hierarchies, which makes this technique useful in object-oriented analysis.

The entity-relationship model is quite easy to understand. An entity, or entity type, is a “thing” in the real world. It may be a person or a real or a conceptual object. For example, an individual, a house, an automobile, a department of a company, and a college course are all entity types. Each entity type is associated with attributes that describe it and apply to it. For example, the entity type company employee has the attribute’s name, address, job title, salary, and social security number; while the entity type college course has attribute’s name, number, credits, and class times. Notice that the entity employee is physical, while the entity college course is abstract or conceptual.

The entity-relationship model also includes relationships. A relationship is defined as an association between entities. In this sense we can say that the entity types employee and department are associated by the relationship works for since in the database schema every employee works for a department. By the same token we can say that the works on relationship associates an employee with a project, thus associating the entity types employee and project As shown in Figure 2.8, it is conventional practice to type entity and relationships in uppercase letters while attribute names have initial caps. Singular nouns are usually selected for entity types, and verbs for relationships. Attributes are also nouns that describe the characteristics of an entity type. An entity type usually has a key attribute which is unique and distinct for the entity. For example, the social security number would be a key attribute of the entity type employee, since no two employees can have the same social security number. By the same token, job title and salary would not be key attributes since several employees could share this characteristic. Notice that while some entities can have more than one key attribute, others have none. An entity type with no key attribute is sometimes called a weak entity. Key attributes are usually underlined in the E-R diagram.

In regards to relationships we can distinguish two degrees of participation: total and partial. For example, if the schema requires that every employee work for a department, then the works for relationship has a total participation. Otherwise, the degree of participation is a partial one. Cardinality constraints refer to the number of instances in which an entity can participate. In this sense we can say that the works for relationship for the types DEPARTMENT: EMPLOYEE has a cardinality ratio of 1:N; in this case an employee works for only one department but a department can have more than one employee. Figure 2.9 shows an entity-relationship diagram for a small company schema.

Figure 2.9 Entity-Relationship Diagram for a Company

The diagrams are read left to right or top to bottom. This convention is important: for example, when the diagram in Figure 2.9 is read left to right it is the department that controls the project, not vice versa.

www.Tutorialsforu.info