Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] how to help Chad

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] how to help Chad
  • Date: Thu, 03 Mar 2005 00:33:05 +0000

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





Archive powered by MHonArc 2.6.24.

Top of Page