5.4 Defining the Project stages Every project should be broken down into a number of manageable stages. Because there are no milestones along the way by which to judge the progress being made, projects can be difficult to manage without them. The size and definition of each stage will depend on the project itself, though as a general rule, each stage hould. L. Be of less than six-months duration Have well-defined resources allocated to it(covering specialist technical resources, resources provided by the user,and other resources, such as trainers, which may be necessary) I. Have clearly defined objectives and specific end-products(e.g. completed programs, training manuals, numbers of people trained) . Have specific roles for each participant in the stage-(e.g. that the office manager will prepare the user manuals for the office staff 1. Have a clearly nominated stage manager for each stage, who is given authority by the management group for the project to use the resources allocated to the stage to complete the work defined within it; I. Have clearly defined rules which define the limits of the stage managers authority. For example, if at any point it becomes clear that the cost of the stage will be more than 5% above the agreed level, the stage manager must report back to the management group 1. Have meetings at designated stages in development. An initial project plan should show the overall costs, timescale and end products expected from the entire project, broken down into individual stages. Each stage can then be managed individually, and any over-or und use of resources in any stage can be examined in relation to its impact on the overall project 5.5 Analysing Requirements If the decision is made to proceed with the project, the first stage is to analyse the requirements in detail nd to document these clearly. There are three purposes in this To ensure that the requirements for the system are fully understood by the technical staff undertaking the analysis and the user staff alike, and that any inconsistencies or deficiencies in the definitions of requirements are identified and clarified I. To provide clear feedback to the users who have requested the system, to ensure that they fully understand the requirements that have been stated and fully agree with the analysts' interpretation of them L. To enable users to contribute to the design of the computer system There are numerous methodologies for analysing and documenting the requirements, each of which uses one or more analysis or diagraming techniques. It is important, however, to ensure that the methodology in use incorporates at least two, and preferably three separate techniques. The reason for this is best seen by drawing an analogy with the plans for a house: An architect will normally prepare three sets of drawings for a house-plan, side elevation and front elevation. Together, these show the detail of what the architect has interpreted as hi client's requirements. They enable a three-dimensional model of the house to be built. The three diagrams also assist by identify ing and eliminating any inconsistencies-for example, that the floor levels are correct or that stairways are in the correct place, since the three sets of diagrams must match in every detail. So it is in the analysis of computer systems. Different diagram techniques give different views of the system, but no matter which techniques are used, they must all be consistent with each other. If they are not, there are errors in the underlying analysis or in the interpretation of requirements. If only one or two methods are used, inconsistencies cannot be readily identified, and this can lead to expensive mistakes later on, when the system is being constructed5.4 Defining the Project Stages Every project should be broken down into a number of manageable stages. Because there are no milestones along the way by which to judge the progress being made, projects can be difficult to manage without them. The size and definition of each stage will depend on the project itself, though as a general rule, each stage should: I. Be of less than six-months duration; I. Have well-defined resources allocated to it (covering specialist technical resources, resources provided by the user, and other resources, such as trainers, which may be necessary); I. Have clearly defined objectives and specific end-products (e.g. completed programs, training manuals, numbers of people trained); I. Have specific roles for each participant in the stage - (e.g. that the office manager will prepare the user manuals for the office staff); I. Have a clearly nominated stage manager for each stage, who is given authority by the management group for the project to use the resources allocated to the stage to complete the work defined within it; I. Have clearly defined rules which define the limits of the stage manager's authority. For example, if at any point it becomes clear that the cost of the stage will be more than 5% above the agreed level, the stage manager must report back to the management group; I. Have meetings at designated stages in development. An initial project plan should show the overall costs, timescale and end products expected from the entire project, broken down into individual stages. Each stage can then be managed individually, and any over- or under￾use of resources in any stage can be examined in relation to its impact on the overall project. 5.5 Analysing Requirements If the decision is made to proceed with the project, the first stage is to analyse the requirements in detail and to document these clearly. There are three purposes in this: I. To ensure that the requirements for the system are fully understood by the technical staff undertaking the analysis and the user staff alike, and that any inconsistencies or deficiencies in the definitions of requirements are identified and clarified; I. To provide clear feedback to the users who have requested the system, to ensure that they fully understand the requirements that have been stated and fully agree with the analysts' interpretation of them; I. To enable users to contribute to the design of the computer system. There are numerous methodologies for analysing and documenting the requirements, each of which uses one or more analysis or diagraming techniques. It is important, however, to ensure that the methodology in use incorporates at least two, and preferably three separate techniques. The reason for this is best seen by drawing an analogy with the plans for a house: An architect will normally prepare three sets of drawings for a house - plan, side elevation and front elevation. Together, these show the detail of what the architect has interpreted as his client's requirements. They enable a three-dimensional model of the house to be built. The three diagrams also assist by identifying and eliminating any inconsistencies - for example, that the floor levels are correct or that stairways are in the correct place, since the three sets of diagrams must match in every detail. So it is in the analysis of computer systems. Different diagram techniques give different views of the system, but no matter which techniques are used, they must all be consistent with each other. If they are not, there are errors in the underlying analysis or in the interpretation of requirements. If only one or two methods are used, inconsistencies cannot be readily identified, and this can lead to expensive mistakes later on, when the system is being constructed