User and Project Team The user and the project team must communicate at both technical and management levels. A technical user representative

is required when the needs fast and accurate answers to technical questions. These questions do not stop at the Analysis but become more and more complex as the project proceeds. The should appoint at one person to be available to answer

6.5 Other Uses for the Functional Specification 65 questions. This person must know the user's business well, and have authority to make decisions for every that proposed system will affect. The user and project team must cornmunicatc at managcmcnt lcvcl as well. This will be done at least by project coordinator and the Project Manager. They will discuss issues such as budgets, schedules, major changes orpcople problems. This sectioncontains

(or more) names and the lines of communication. Note that this section, as well as several other sections in the FS just rciine items in the Proposal and the RD.

11. User's In to save money and time, or if the user wishes to be more involved. the mav ask him to tasks such as providing test data, writing the User's or test. List in this section all such activities, and the due dates. Remember that the user this document so he is committed these things.

12. Terms, Conditions and Assumptions List here any new rules and regula- tions by which cvcryonc is to abide. any important assumptions for protection.

6.4 TECHNICAL WRITING FOR THE NON-TECHNICAL READER

The FS is difficult to well. Since it describes a technical system it is a technical document, but it is written for a non-technical reader. In addition, the bonus of ensuring the user understands it is on the analyst. How can you ensure this?

Write from the point of view-use his terminology. You must

learn the user's business and Use simple constructions:

"You do this, the system does that." diagrams possible.

the greatest reasons for misunderstanding a document is that the words are ambiguous. Avoid mamby-pamby words such as "can be, could, usually, probably, most, etc." It is tempting to make no commitment, but that if you use the word "some" and mean "minimum," the will assume "maximum." Similarly, avoid implied that are or impossible to prove. Words such as

"any, all, every", superlatives (words ending in "est") may cause problems later. For each promise you make in the FS, ask yourself, "How am I going to prove it?"

6.5 OTHER USES FOR THE FUNCTIONAL SPECIFICATION

A good FS can be used to introduce new members of the to the project. can use it to introduce the new system to his or her management, or to other interested parties. But most important, the sections describing the menus, forms, queries and can be used in the User's Guide. If you intend to use these parts of FS in the User's Guide, write everything in the present tense. It is tempting to write in the future tense. Writing "When the user will type 'X' the following menu will appear (we hope) leaves you an escape route. But be brave, use the present tense and you will be to use these sections of the FS verbatim in the User's Guide.

Chap. 6 The Analysis Phase

6.6 CASE SOFTWARE TOOLS FOR ANALYSIS

Computer Aided Software Engineering (CASE) is using a set of software tools in each phase of the system life cycle. These tools should allow you to produce the required documents, as well ascomputerreadable products that can be usedas input to the CASE tools of the following phases.

A word processor is all the software that you need to do the Definition Phase.

There are several excellent software products available to help you do analysis. The examples presented here are based on a personal computer product called Excelerator (Reference 2.2). This product, introduced in 1984, has become the most popular analysis tool in the industry. Excelerator can be used to draw the high level data flow diagrams as in Figure 6.2, then to 'blow up' the into lower and lower levels of detail.

The parameters among the diagrams can be detailed, and Excelerator ensures consistency-all parameters passed and received among diagrams must have the same attributes, and the parameters used by a diagram at a lower level must be the same as the corresponding parameters at the higher levels.

Analysis tools provide menu, screen and report painting facilities to help describe the user interfaces to the system. In Chapter 15 we will see how this can be used to prototype a system. Input and output screen forms can be painted using mouse input.

Similarly, reports and on-line queries can be quickly mocked up (Figure 6.3).

Figure 6.3 Excelerator report

6.6 Case Software Tool for Analysis 67 And the icing on the cake is that these products can then print out all the menus, screens, forms, and reports. This is most of the Functional Specification! Excelerator even has a word processor built in which can be used to produce all the other required documentation, index them, and so forth.

These tools are truly CASE tools they integrate other tools used in subsequent phases. For example, design tools can use the analysis to draw the design structure diagrams (or at least that all the analysis items are designed), and again ensure that all the parameters remain consistent.

Tools such as Excelerator can track of all the records and fields defined in your forms and reports and store these in a Data Dictionary (DD). This is how the tool ensures consistency in the Definition and assists in the design of data and files in the Design Phase.

On mini computers, tools such as DECDESIGN support the Analysis Phase by drawing data flow or entity relationship diagrams, as well as the Design Phase by drawing structure charts and state transition diagrams. Context checking is handled through the data dictionary. All of thcsc tools are mouse and window graphics driven.

Figure 6.4 Entity Relationship Diagrammer

Chap. 6 The Analysis Phase

6.7 REVISING THE PLAN

Planning is an iterative process. Revise the preliminary project plan right after analysis. Remember, weeks, possibly months havepassedsince you wrotethefirstplan has been learned in this period. Rc-assess the work breakdown. Are the tasks still able to beestimated, assigned, scheduled and completed? Most important, the resources assumed for each task are still available when needed. This is an excellent time to do planning. For each resource needed ask, "What if it is late or unavailable?" Suggest alternative plans. The following is a short list of problems that can occur in the next phases (Design, Programming, System Test) along with suggested contingency plans:

A key programmer or designer leaves. Can you train a backup? has suc- cessfully used a buddy a programmer is assigned as a buddy to a key 'guru' programmer. The buddy's job is esentially to 'carry the water' for the but also to from him to be able to take over in case he leaves.

The development is unavailable. Can you another in the to use, perhaps alter hours?

Special hardware devicedoes not materialize on time. Can you simulate it with software, or a Personal Computer?

New release of a software package (or hardware) does not work. Can you use the old Call it 1; Phase 2 comes out when it all works.

A resource provided by a third party does not materialize. Can you exercise somecontrol to ensure that it is on time? Can you negotiate penalty clauses, get on their hoard of directors? If it is an internal project and the third parties do not report to you, can you get input into their performance reviews? Can you get someone who has authority on project Steering Committee (see Chapter

Training Plans for the Project Members

When is check to training. Your programmers will

be the most likely candidates. all training to be done by the end of Design.