Systems analysis establishes the need for an information system and its extent.

Heightened global competition has made it imperative for organizations to deliver products - goods and services - of consistently high quality. The principles of total quality management (TQM) recognize that consistent product quality results from designing and executing business processes so as to remove error and waste.

Product quality is the result of :

a. Customer focus

b. Introduction and continuous improvement of business processes and product-development processes that reduce variations

c. Creation of a company-wide quality culture through motivation and training of all its members

d. Continuous measurement and analysis of the accomplished results.

Quality information systems are vital to total quality management, because:

1. Business processes of the firm depend on information systems and, therefore, their quality depends to a large degree on IS quality

2. Information systems enable most projects of business process design. This IS enabled streamlining of processes gives fewer opportunities for error, thus leading to higher quality of the processes' outputs.

3. Information systems are a necessary component of the feedback loop in managing an enterprise. IS are necessary to continually gauge any deviations from the expected norms in the firm's performance and thus help reduce variance in performance.

There are many attributes of software quality. These include:

1. Effectiveness

2 Usability

3. Efficiency

4. Reliability

5. Maintainability

6. Understandability

7. Modifiability

8. Testability

Effectiveness Refers to the satisfaction of the user and organizational requirements as established during an analysis of these requirements, possibly using prototyping.

Usability The ease with which the intended users can use the system, depend on the proper user-system interface.

Efficient Efficient operation is reflected mainly in how economically hardware resources are used to satisfy the given effectiveness requirements

Reliability Refers to the probability that the information system will operate correctly; that is, according to specifications over a period of time. It may also be defined as the mean time between failures. Software reliability is rooted in its freedom from defects. If a system must run on different hardware or systems software platforms, portability should be included as a desired attribute.

Maintainability Refers to ease of understanding, modifying, and testing.

Understandability Is achieved by readable and well-commented system code and by documentation, which includes the requirements specifications, system documentation, user manuals, and, sometimes special maintenance documentation.

Modifiability Means that it is relatively easy to identify and change any part of the system that requires maintenance without affecting its other parts.

Testability Is the ease with which we can demonstrate that a modification resulted in a quality system.

The following are the principal aspects of TQM - oriented quality assurance for information systems:

1. Customer focus is achieved by involving end users in the IS development process, particularly during its early stages when the requirements for the system are being defined. Systems prototyping and joint application development (JAD) are the principal techniques applied to this end.

2. The life-cycle oriented systems development, with the inclusion of prototyping, is a process that lends itself to control, measurement, and continuous improvement. Support with CASE tools helps to ensure product quality.

3. Software development and maintenance teams are the primary human element in ensuring software quality.

4. The quality measurement program can assist in consistent striving for higher quality levels. Such a program rests on the foundation of software metrics. Software matrices include techniques for measuring the attributes of software and techniques for measuring the attributes of software development process.

The systems development life cycle (SDLC) gives organizations a means of controlling a large development project by dividing it into manageable stages with well-defined outputs. SDLC consumes a significant amount of resources itself - it takes time and money to manage projects in such an elaborate fashion.

Characteristics of the SDLC:

1. Every stage is defined in terms of the activities and responsibilities of the development team members.

2. Each stage terminates in a milestone defined in terms of the subproducts to be delivered, such as system requirements specifications or coded and tested software modules.

3. Stress to students that developers often need to rework the deliverables produced in earlier stages in the light of the experience they gain as the development effort progresses and to accommodate legitimate user requests for change.

4. The effort expended on developing an information system is generally surpassed by the efforts needed for the system's maintenance, which may cost over time twice as much as the development. Many organizations spend 60 to 70 percent of their IS budgets on systems maintenance.

5. Producing extensive system documentation during the development is necessary to support maintenance. It is desirable that the documentation necessary for system operation and maintenance be produced as the by-product of the development process.

Stages of the SDLC and their deliverables

- recommendation to abandon

Requirements analysis - requirements specifications

Logical design - conceptual design or programs and databases

Physical design - detailed design of systems modules and databases

- specification of system hardware and software

Coding and testing - accepted system with complete documentation

Conversion - installed operational system

Postimplementation review - recommendation for enhancement of the system and of the

development method -  recommendation for organizational adjustment

The task of systems analysis is to establish in detail what the proposed system will do (as opposed to how this will be accomplished technologically).

Characteristics of systems analysis include:

The main objective of the feasibility study, the introductory phase of development, is to establish whether the proposed system is feasible or, to be more accurate, desirable, before resources are committed to the full-scale project.

In a feasibility study, systems analysts perform a preliminary investigation of the business problem or opportunity represented by the proposed system development project. Specifically, they undertake the following tasks:

1. Define the problem or the opportunity which the system will address

2. Establish the overall objectives of the new system

3. Identify the users of the system

4. Establish the scope of the system.

5. Propose general hardware/systems software options for the new system

6. Perform a make-or-buy analysis for the application

7. Perform a value assessment, such as the cost-benefit analysis, based in part on the estimate of the development project size

8. Assess the project risk

9. Recommend whether to proceed with the project, or whether to abandon the project

The five essential aspects of a feasibility study include:

2. Ethical feasibility - will the proposed system conform to the norms of ethics?

3. Technological feasibility - do we have the technology and skills needed to develop and operate the system?

4. Economic feasibility - will the system result in competitive advantage or another payoff to the enterprise?

5. Organizational feasibility - will the organizational change result in an acceptable quality of working life for those affected by the system?

- Will the political changes caused by the system be accepted?

- Will the organization benefit as a whole?

The principal objective of requirements analysis, the main systems analysis stage, is to produce the requirements specifications for the system, which set out in detail what the system will do. Requirements (also known as functional) specifications establish an understanding between the system developers, its future users, the management and other stakeholders.

Requirements analysis needs to establish:

1. What outputs the system will product, what inputs will be needed, what processing steps will be necessary to perform inputs into outputs, and what data stores will have to be maintained by the system.

2. What volumes of data will be handled, what numbers of users in various categories will be supported and with what levels of service, what file and database capacities the system will need to maintain, and other quantitative estimates of this type.

3. What interface will be provided for the users to interact with the system, based on the skills and computer proficiency of the intended users.

4. What control measures will be undertaken in the system

Techniques for information gathering in systems analysis: [Figure 15.5]

Techniques for gathering information during systems analysis can be grouped into four categories. A combination of these approaches is usually employed. They include:

1. Asking the users

2. Deriving from an existing system

3. Deriving from the analysis of the business area

4. Experimenting with the system under development

Characteristics of interviews include:

1. Both open-ended and closed-ended questions may be employed where appropriate. Open-ended questions aim to draw the user out into a longer explanation or opinion, and closed-ended questions can be answered with yes, no, or a specific brief response.

2. The interviewing process must be planned, since managers at several levels may have to be questioned.

3. The analyst has to prepare for each interview by establishing the position, activities, and background of the interviewee. In a structured interview, the analyst relies on a prepared list of questions. In an unstructured interview, the direction unfolds as the person being interviewed answers the largely-open ended questions; follow-up questions are then asked.

4. During the interview, the analyst must convey a clear understanding of the purpose of the interview, ask specific questions in terms understandable to the interviewee, listen rather than anticipate answers, control the interview but be open to a suddenly discovered rich source of information, and create a record of what is learned.

5. The analyst should analyze the results immediately following an interview session.

Questionnaires are an efficient way of asking many users at once, particularly users who are dispersed in the field.

Characteristics of questionnaires:

1. Increasingly, questionnaires are distributed on diskettes or intranets.

2. An easy-to-fill-out questionnaire with concise and closed-ended questions is most likely to meet with success. Simple yes/no questions and checklists are preferable.

3. Questionnaires have limitations as compared with interviews, in part because of their requisite simplicity.

4. Generally, questionnaires are employed together with other, more powerful, means of eliciting user requirements.

5. Group decision-making processes such as the Delphi method, brainstorming, and nominal group techniques may also be used in search of creative new solutions. These techniques are sometimes used during JAD sessions.

The requirements for a proposed system may be derived from an existing information system. The possibilities are:

1. The system that will be replaced by the proposed system

2. A system similar to the proposed one that has been installed elsewhere and is accessible to the analyst

3. A proprietary package, whose functionality may be analyzed.

Data Analysis the requirements for the proposed system are derived from the data contained in the outputs of the existing system and inputs to it. The data can also be obtained from the existing programs and systems documentation, such as procedures, manuals, organization charts, file descriptions, operations manuals, and so forth.

Document Analysis concentrates on the analysis of business documents, such as orders or invoices.

Observing Work the work of an intended user or by actually participating in the work, the analyst learns first-hand about the inadequacies of the existing system.

3. Deriving the Requirements from the Analysis of the Business Area

Informational analysis of the business unit to be served by a system may be carried out with Business Systems Planning. As well, the critical success factors methodology can be used to establish the CSFs of the individual managers and support them with information.

A method that will also help establish the informational needs of an individual manager is decision analysis. It consists of the following steps:

1. Identify the key decisions that a manager makes

2. Define the steps of the process whereby the manager makes these decisions

3. Define the information needed for the decision process

4. Establish what components of this information will be delivered by the information system and what data will be needed to do so.

4. Experimenting with the System as it is being Developed

Experimenting with the system under development is the prototyping approach.

Characteristics of the prototype approach include:

1. An initial system version that embodies some of the requirements is built.

2. The users are able to define their requirements in an Aas compared to something@ manner - which is much easier than defining them without such a comparison.

3. Prototype may be discarded after it has been put to such use, or it may evolve into the system to be delivered.

The purpose of systems analysis is to devise a logical model of the proposed system. Using the methodology known as structured systems analysis, we graphically describe the system as interacting processes that transform input data into output data. These processes may then become code modules as the system is further designed and programmed.

The principal tool used in structured analysis is the data flow diagram (DFD), which graphically shows the flow and transformation of data in the system. A DFD representation of a system is the graphical depiction of what the system will do.

There are four symbols employed in a DFD. These include:

1. Process - circle

2. Data flow - line

3. Data store - parallel lines

4. External entity - square

Characteristics of a process include:

1. A process (shown as circle) as the term is used in structured analysis, transforms inputs into outputs.

2. The name of the process very briefly explains what the process does.

3. Since the processes are the Aactive@ components of the system, their names reflect this.

4. All processes in a DFD are numbered.

A data flow, shown as a line ending in an arrow, represents a flow of data into or out of a process.

Characteristics of a data flow:

1. Flows show the movement of data between all the components of a DFD.

2. Although during the initial analysis we may consider physical data flows in the existing system, ultimate analysis will deal with their logical data content.

A data store, shown as a parallel line, shows a repository of data maintained by the system.

Characteristics of a data store:

2. Both data stores and data flows are data structures

3. Data store names are frequently in the plural, to distinguish them from data flows.

An external entity is represented as a square. It is a source from which the system draws data or a receiver of information from the system.

Characteristics of external entities

1. Entities are external to the system; they are beyond the system boundary.

2. External entities may also be other systems with which the given system interacts.

Our fundamental requirement concerning tools for systems development is that they lend themselves to a process of progressive refinement, bringing in the details gradually. This helps manage the complexity of the analysis process. DFD levelling is such a process of progressive refinement.

A context diagram shows only the system interfaces (inputs and outputs) flowing to or from external entities. A context diagram shows the system as a single process bearing the system's name, with its principal incoming and outgoing data flows, as they are known at this early stage of analysis. If there are too many to show, a table may be employed to show inputs and outputs in two columns.

Figure 15.9 - use this figure to discuss a level-0 DFD of a simple order processing system.

1. The top level DFD is the context diagram of the system. Subsequent levels are obtained by progressively breaking down individual processes into separate DFDs.

2. Decomposition is governed by the balancing rule, which ensures consistency. The balancing rule states that data flows coming into and leaving a process must correspond to those coming into and leaving the lower level DFD that shows this process in more detail.

3. No more than 10 processes should be shown on a given DFD to prevent cluttering the diagram.

4. Not all processes have to be broken down - only those whose complexity warrants it.

5. The levelling process is not over until it's over. That is, as you introduce more detail into the analysis by levelling, you will note omissions in higher level DFDs - and you will correct them.

6. The numbering rules for processes is as follows. Use 1, 2, 3, and so on in the level - 0 DFD. If you decompose, say process 3, the processes shown on process 3's level-1 DFD will be numbered 3.1, 3.2, 3.3, and so on.

The entities that appear in the data flow diagrams are described in further detail in a data dictionary. Data dictionaries have evolved into powerful tools as repositories of descriptions of all project entities.

The principal tool that is used to show how the primitive DFD processes transform their input into outputs is through describing their logic. The principal tool for this specification is structured English, which is a form of pseudocode - a code describing the processing logic to a human rather than to a computer.

Constructs used to express any processing logic include sequence, loop, and decision. An additional construct represents multiple choice.

A decision table specifies in tabular form the actions to be carried out when given conditions exist.

To design a decision table:

1. Specify the name of the table as its heading, and insert a reference to it at the place in the process description where the table applies

2. List all possible conditions in the condition stub

3. List all possible actions in the action stub

4. Fill in the condition entries by marking the presence (Y) or absence (N) of the conditions. The number of rules, that is, entries in the right-hand side of the table equals the number of possible combinations of conditions.

5. For every condition entry, mark with an X an action entry opposite the action(s) to be taken under these circumstances.

Characteristics of decision trees

1. They are easier to read than are decision tables, but the greater the number of conditions, the more tedious they are to draw up.

2. They are better for checking the completeness of the policy represented.

All the descriptions of the DFD entities are entered into the data dictionary of the project. We need to plan what data and what relationships among data are stored in an organization's databases. The principal vehicle for managing data is the data dictionary.

The composition of each data store and data flow appearing in the DFDs must be described in the dictionary. Generally, both data flows and the records in the data stores are data structures, that is, they are composed of more elementary data entities.

When we establish the need for an information system and its extent is called system analysis?

What are the 4 phases of system analysis?

Which of the following is established during the systems design phase in which the designer completes the design of all required system processes?

What is the part of a system that defines the extent of the design pursuant to the operational requirements?