ANALYSIS PHASE. Requirements Analysis is done in order to understand the problem for which the software system is to solve.

For example, the problem could be automating an existing manual process, or developing a completely new automated system, or a combination of the two. For large systems which have a large number of features, and that need to perform many different tasks, understanding the requirements of the system is a major task. The emphasis in requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals. This task is complicated by the fact that there are often at least two parties involved in software development - a client and a developer. The developer usually does not understand the client's problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirements Analysis. In most software projects, the requirement phase ends with a document describing all the requirements. In other words, the goal of the requirement specification phase is to produce the software requirement specification document. The person responsible for the requirement analysis is often called the analyst. There are two major activities in this phase - problem understanding or analysis and requirement specification in problem analysis; the analyst has to understand the problem and its context. Such analysis typically requires a thorough understanding of the existing system, the parts of which must be automated. Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of document, some specification language has to be selected (example: English, regular expressions, tables, or a combination of these). The requirements documents must specify all functional and performance requirements, the formats of inputs, outputs and any required standards, and all design constraints that exits due to political, economic environmental, and security reasons. The phase ends with validation of requirements specified in the document. The basic purpose of validation is to make sure that the requirements specified in the document, actually reflect the actual requirements or needs, and that all requirements are specified. Validation is often done through requirement review, in which a group of people including representatives of the client critically review the requirements specification.

Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle. During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization's current procedures and

business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements. Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones. Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage. Some Advantages of Prototyping: Reduces development time. Reduces development costs. Requires user involvement. Developers receive quantifiable user feedback. Facilitates system implementation since users know what to expect. Results in higher user satisfaction. Exposes developers to potential future system enhancements. Some Disadvantages of Prototyping Can lead to insufficient analysis. Users expect the performance of the ultimate system to be the same as the prototype. Developers can become too attached to their prototypes Can cause systems to be left unfinished and/or implemented before they are ready. Sometimes leads to incomplete documentation. If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost. Based on the results of their research, Hardgrave and Wilson found that industry followed only six of the seventeen recommended in information system literature. The guidelines practiced by industry whose adherence was found to have a statistical effect on system success were: Prototyping should be employed only when users are able to actively participate in the project. Developers should either have prototyping experience or given training.

Users involved in the project should also have prototyping experience or be educated on the use and purpose of prototyping. Prototypes should become part of the final system only if the developers are given access to prototyping support tools. If experimentation and learning are needed before there can be full commitment to a project, prototyping can be successfully used. Prototyping is not necessary if the developer is already familiar with the language ultimately used for system design.