PRELIMINARY STUDY
Phase PS.1 Requirements analysis - Diagnostic
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
adapted
to web-based processed: 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
marketing 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.
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.
Complete the market study
Identify accurately the customer/product niches and
describe their :
-
importance, in number of individuals ;
-
global purchase potential ;
-
e-commerce acceptance ;
-
e-purchase potential ;
-
finally, potential e-commerce revenue.
Structure logically & describe
Structure the
information to be published (pages,
layout-oriented analysis)
identify roughly which pieces of information are to be
published :
-
describe the information :
-
-
structured data only
-
free text and graphics only
-
mix of structured data with texts & graphics
;
-
locate its source :
-
-
database: existing / to be created / to be
upgraded
-
other data storage
-
no data origin ;
Choose which information should be included in the
corporate databases (it will be considered as a part of
the corporate data), and which should be
provided separately.
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
marketing and
management information requirements
Describe the available resources
web sites, domain names, hosting services
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
Propose an action plan for the next
step
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.
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 and
marketing 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.
for instance :
-
reducing support center costs by 30% over the next 24
months ;
-
getting 25% of corporate revenue through e-commerce
within the next 2 years ;
-
retaining 10% of online visitors as regular
customers.
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.