Requirements analysis: Listing requirements in logical orders with cross-referencing. This highlights and minimizes duplication, and allows logical grouping of tasks into identifiable areas ready for subsequent action.

Preparation of requirements specification: Documents the requirements to facilitate further stages.

The deliverable end product from the RE phase is the document known as the requirements specification, also called the operational requirement for contractual action. This becomes the input document for the next stage functional analysis.

Functional Analysis Phase

With all the requirements (known to date) laid out in logical groupings in the requirements specification, the next task is to look at the functions involved in each group area. The purpose is to spot duplication of functionality and identify any areas of conflict and contention. For example:

Many stakeholders have had input to the list of requirements, and it is possible that several people have requested the same or similar actions. These duplications of functionality must be sorted out now to eliminate duplication of code and costs later in the development.

Because of the diversity of stakeholder interests, there will be differences of opinion in priority levels among the requirements, with every individual stakeholder claiming that his or her area is more important and a higher priority than others. It is at this stage that the project manager and project development team have to agree on the overall picture for smooth future development.

Not everyone agrees on technical items. The question of who has access and who has write rights can lead to conflict. The project manager and team need to get agreement from the stakeholders. The problems will only get worse if ignored now. Arrange for a conflict resolution meeting where the relevant stakeholders can meet and resolve the issues.

Performance Analysis Phase

With all functionality clear and understood by the development team, the next stage is to consider the performance required. Performance indicators include:

Speed of response.

Routing.

Strange effects avoidance. Choice of hardware.

Preparation for the design stage.

Speed of response to the requirements is the usual way an end user will judge the operational system. When an end user makes an inquiry, he or she expects the whole answer to that inquiry. Some projects allow the response to be a simple message such as inquiry being dealt with please wait. The actual processing has taken an unacceptable amount of time, which frustrates the end user and gives the project a poor name. If a requirement states that the response to an inquiry must appear within x seconds, the performance analysis stage should be sure that it is physically reasonable and technically possible. Stakeholders sometimes make excessive demands. These must be sorted out and agreement reached in this phase.

Routing users through the final system will also be judged as good or poor performance. An end product of the previous stage was a logical grouping of the requirements. Now is the time to start thinking about final performance routing options. Other aspects on which the final system will be judged are how it performs when presented with unexpected input, how it allows the end users to cope with unexpected output, and the error messages and options presented to the end users when strange events occur. This is referred to as strange effects avoidance. Now is the time to decide how some of the requirements are to be handled.

The Final Phases

The phases of design, coding, and integration are standard to most development models. Testing is carried out within as well as at the end of each phase. Notice the loop back from the integration phase goes right to design and not to coding. It is ill advised and sometimes dangerous to attempt to rectify integration problems by altering the code alone.

Reverse Engineering Phase

This phase considers any previous system(s) and attempts to reuse existing components. Software, hardware, documentation, working practices, and local standards may all be reused. Any of these that are reliably proven usable are incorporated directly into the new system. Many parts of the old system will not be usable. Other parts may be reengineered via the design phase. The reverse engineering model gets its name from the reusability of previously proven components that are considered relevant to the new development. These components should be reverse engineered via the design phase with only proven components used directly in the new system. The other fundamental differences in this development model are the inclusion of two new phases, namely, (1) functional analysis and (2) performance analysis. The reverse engineering development model can be used for the whole project or on subunits developed individually and integrated into the whole project.

Team LiB

llJ HI.IIUlg