pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Richard Archer wrote:

> At 8:49 PM +0000 2/3/05, Richard Morris wrote:
>
>
> > As to tasks I see the first task has to be implementing user login.
>
>
> I beg to differ.
>
> The first task is to properly define this project. There has
> been much discussion but little action on this critical task.
>
> Perhaps this is because nobody is quite sure how to proceed.
> Here are a couple of links which may help explain what the
> specification should look like:
>
> http://www.microtoolsinc.com/Howsrs.php
> http://www.aldex.co.uk/reqspec.html
>
> Perhaps a Wiki would be of assistance in writing this document?
The second of these is good.

Pasted below. Quite a few straight forward Q's. But some do highlight 
bits we are stuc on. Comments from me start with a *

Introduction
        Who you are.
        Where you are located.
        What you do.
        Who are your customers/market.

* This has been cropping up. I'd say first and formost practicioners of 
* permaculture. Were not clear on this.

        Your contact details.
  	What is the business problem you are trying to solve and why you 
need a new system.


System Overview
        Who is intended to use it
	How many users are there (both the total number and the maximum number 
of concurrent users at any one time)?
        Are they the same type of user or different (eg sales and management)
	What level or computer experience will the users have (eg familiarity 
with Word/Excel).
        What main problems do the users have at present.
	What sort of security (eg different group with different access rights) 
is required.

* Big question for us.

	What hardware/environmental constraints are there. Eg The system is to 
be run on Windows 2000 machines each with a minimum of 128Mb RAM.
        Will it be networked or stand-alone.
  	Any other constraints (throughput requirements, industry protocols, 
etc.)
  	Approx. number of records required initially plus anticipated growth 
eg 1,000 customers increasing at 100 per year; 10,000 jobs increasing at 
1,000/year; etc.
  	Will remote users need access (eg mobile workers with a laptop). If 
so do they just need a copy of the database on their laptop or will they 
need to dial-in to the main system to get the most up-to-date 
information. Will they be updating information in the field for later 
downloading onto the main system. Any what about other sites?
        What sort of technical support is available in-house.
	What other systems, if any, will this system integrate/communicate with 
eg export data to a financial system, import data from Excel, etc.
	What external communications are involved eg automated faxing, import 
csv data from FTP site, etc.
	What Business Rules that need to be included, for example maximum 
credit allowed is 5,000.
	Are there any Business Processes that need to be catered for, eg credit 
card authorisation
	Are there any technical standards that must be complied with, eg code 
must be written using the Leszynski/Reddick naming convention.
	Maintainability/future expansion. Include your thoughts on who will 
maintain the system in future (eg in-house), any plans for future 
developments, etc.
	Backup. Describe what your current back-up regime is (eg tape back-up 
one/day) and if/how you expect the new system to fit in with this.
	Deliverables. What are you expecting? eg system, help files, 
documentation, full source code, training, support, etc. Detail what is 
essential and differentiate these from what would be nice. Don't 
automatically ask for everything unless you really do need it, for 
example documentation can be very expensive. If you are to maintain the 
system make sure you state that you require the full source code - 
alternatively if the developer is to maintain the system you may settle 
for an escrow agreement (where the source is held by an independent 
third party). You must state that you need one of these; if the 
developer is unwilling then find someone else!
        Reliability. Any reliability constraints? acceptable server downtime,.
	History. What have you been using up to now (eg paper, nothing, DOS 
database). Do you have existing data that needs to be converted to the 
new system? What format is this data in and can it be exported, eg to a 
.csv text file.

Functional Requirements
This section should describe what the system is to accomplish rather 
than how it is to be accomplished. This should consist of a list, with 
the most important items at the top. Each entry on the list should be 
specified in a format similar to the following.


	A description of the requirement. This will probably be a couple of 
lines explaining what you want to achieve. Make sure that you provide 
sufficient detail. eg Produce a report of spend/department/year on 
demand with the user selecting the Department and the financial year 
required (note that you would also need to define how your financial 
year is calculated!).


        

How important is this requirement (essential, preferred, nice to have, 
not essential, etc).


        Any known design/implementation issues relating to this requirement.


        Does this requirement interact with other requirements.


	Anything else affecting this requirement (eg only authorised personnel 
should have access)


Data to be Held
Describe what data tables you expect to hold. Eg customer records, 
contact details, machine records, etc. Provide as much detail as you 
can. For example a customer record might consist of a name, address, 
tel. no, fax no, mobile no, region, business type, no employees and so 
on. Try to indicate any unique fields (such as a job number) and also 
show how different tables relate to each other (very important). For 
example Projects are related to Customers through a Customer Number. 
Each customer can have none, one or many associated Projects. Each 
Project relates to one or more Jobs. A Job can exist independently of a 
Project but will still be associated with a Customer. A Project will 
always have a Customer and cannot have more than one Customer.

It is not usually necessary to define the tables in database terms (eg 
Customer Number is a long integer) but examples of the data to be held 
in the fields is useful (eg a typical Job Number might be DT/2345 where 
DT indicates the department undertaking the job and 2345 is a unique 
number. NB In practice a good database designer would then recognise 
that the 'real' job number is actually the 2345 part and the DT bit is 
just an associated field.). If you know the maximum size of any field 
(eg Company Name of 100 characters) then include this as well.

If you have any table definitions from existing systems then provide 
these as well indicating any changes that are required.

Operational Scenario
Describe a set of scenarios that illustrate, from the user's 
perspective, what will be experienced when using the system the system 
under various situations. Eg this would describe how different users 
would use the system and the typical sequence of actions that each would 
take.

Schedule and Budget
Describe what timescale you are working to, any critical deadlines, any 
management constraints (eg nobody available to discuss the project 
during August, awaiting approval to proceed, etc) and the budget you are 
working to (you may, or may not, want to reveal this initially).

Appendices
Include other information here that may be useful in understanding your 
requirements. For example definitions of industry specific terms, 
acronyms, abbreviations, etc. Provide citations to any other documents 
used in the preparation of this specification.

Rich