Sequoia it development methodology
 | welcome page | projects | contact us | get  the free off-line version |

PRELIMINARY STUDY

Phase PS.1 Requirements analysis - Diagnostic 

PS.1.1 Purposes

(-)  be informed of the existing system; describe it

The added value of this phase is to structure progressively the domain following a logic that can be automated or computerized: processes, data, management rules.

The study of the existing system must always be limited to the essential. It may not become an extended description of all the details of the current system. Nevertheless, it is mandatory that the requirements analysis is built upon a sufficient knowledge of the existing system.

(-)  identify all requirements

processes requirements

management information requirements

(-)  gather all the documentation that will be necessary for a detailed study

(-)  allow all participants to get a global knowledge of the domain to be processed.

PS.1.2 Realization actions

(-)  Study of the existing system and new requirements :

As in the System Architecture Design phase, but the scope is limited to one domain, and the study has to be done more in depth.

(-)  Structure logically & describe

(-)  Structure the processes: cut the domain into applications, systems and functions, and describe them

(-)  select the representative cases, the normal cases; do not take exceptions into account at this stage of the analysis

The selection of the representative cases depends on the type of objective that you pursue: there is a major difference between a mass procedure, sometimes extremely simplified (case of the production and storage of white latex in a paint factory, or case of the procurement and storage of malt in a brewery) and the normal procedures, that process less massive but more numerous cases. Although they process a major part of the activity, these mass procedures may be not representative of the way 'normal activities' need being managed.

(-)  put the accent on the functions to be performed ("What needs being done ?"), and not on the current procedures ("How do we do it ?")

A functions description replaces favorably the processes description at this stage of the analysis. Indeed,

The functions can be performed in several ways, by different procedures.

You have interest, as from the description of the current situation, to raise the reflection above the current habits in order to create a new solution at a higher abstraction level. The functions description will grow up more likely than its practical processes version.

A detailed processes description costs a lot and is often nor useful nor to be recommended.

identify and describe the actors and their responsibilities.

identify and describe the functions that are already computerized.

(-)  Structure the data:

Identify the needed information blocks (data store) and the main entities

begin the normalization procedure

(-)  Structure the management rules:

e.g. as decision tables

Identify the imprecisions, the contradictions, the remaining questions.

(-)  Complete the System Architecture Design

go more into details

fill in the possible lacks of the System Architecture Design

(-)  Set up a precise requirements inventory

processes requirements

management information requirements

(-)  Describe the available resources

IT sites, servers, networks, applications distribution, interfaces

it can be useful to detail the technical possibilities that could be offered by a new architecture !

(-)  Conclusions:

Set out a precise diagnostic over the domain.

Set up the new orientations in a more precise way that in the System Architecture Design

PS.1.3 Project management actions

(-)  Propose an action plan for the next step

PS.1.4 Quality assurance actions

(-)  Control by a second reading, simple or alternate

(-)  Key factors

identify all information sources and take them into account

brainstorm effectively in order to imagine the future evolution.

(-)  The correct identification of the requirements is the base for the quality assurance of the next steps.

the requirements inventory identified during this study will be the control base of the next realizations. Express the requirements under a systematic form, that can be re-used in the quality control of the conception phase.

take also care, concerning the management information requirements, to identify reports allowing a synthetic report of the different faces of the application. These tools will be used during the realization and launch phases.

PS.1.5 Phase closing actions

(-)   At the end of this phase, the following documents should be available:

(-)  full inventory of the reference documentation

(-)  description of the current system

(-)  full inventory of the requirements

processes requirements (operational requirements)

management information requirements (control and piloting)

(-)   At the end of this phase, you should have for certain:

(-)  which are the purposes of the new system

preferably expressed under an objective and controllable form.

(-)  which are the constraints of the future system and of the evolution path

(-)  one scenario of the target system

(-)  one action plan or evolution scenario

resources: budgets, time limits, availabilities, work groups,...  


copyright (c) séquoia sprl (www.sequoia.be), belgium, 1999-2000. all right reserved.