Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Formal Spec

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] Formal Spec
  • Date: Wed, 09 Feb 2005 22:39:36 +0000

Aloha,

I'm not sure if an XML DTD is the right way to approach this. Mainly because its hard to understand for lay people.

IMO an XML DTD will be a part of formal specs - specifically, it will be the spec for XML markup to be used however we end up using XML markup in the project.

Definitely not a primary spec document.

That should be in as plain as possible English...a functional spec stating in chunks and steps and substeps what the product will do.

Chunk 0: database
The database will be/do...(high level statement(s) - HLS hereafter - of what it will do)
HLS1 will be accomplished by...(details of HLS1)
HLS2 will be accomplished by...(details of HLS1)
And so on...


Chunk 1: data engine
The data engine will be/do...(high level statement(s) - HLS hereafter - of what it will do)
HLS1 will be accomplished by...(details of HLS1)
HLS2 will be accomplished by...(details of HLS1)
And so on...

Chunk 2: data transport
Data transport will be accomplished by/with...(HLS(s) on data transport)
HLS1 wil be....etc. as above, the XML DTD goes in here somewhere

Chunk 3: User interface (initial/dev/test)
The user interface will provide/do...(high level statement(s) - HLS hereafter - of what it will do)
HLS1 will be accomplished by...(details of HLS1)
HLS2 will be accomplished by...(details of HLS1)
And so on...

Each HLS1 may have substatements that break down into smaller steps.

Smallest steps should describe each function at a level of detail adequate to code from without having to make any significant/non-trivial assumptions.

Can be written with word processor using outline formatting; some people like to use spreadsheet.

If done this way it becomes a "good enough" functional test spec also.

A post by Heidi on piw suggested a way that we might proceed.

Then really what remains to be decided is
- what criteria we want to report
- how we want to label them
- how we want to report them (plain text etc.)
- how we want to search them


A few questions like this, suitably broken down, could start the process. Then we can find solutions to these questions and if necessary
break the questions down. Once we are there we can translate to a database schema or XML DTD.

Yep!!

I'm also thinking that the bug tracker could be used to focus our decision making. I've not had a look at the specific software John S+H are investigating, but if its like bugzilla we have some useful features
1) Ability to prioritise tasks
2) A means to assign tasks to people.

Yes, will have both of those.
As mentioned, it is my #1 PIW task, and will still be a week or so realistically. Gotta get the roof on!

Task no 1 could be "produce formal spec."

Task 2: Devlope key questions.
Heidi has nicely identified some

Q2 - what criteria do we want to report?
Q3 - how do we lable them?
Q4 - how do we report them?
Q5 - how do we search them?

I'd also add:

Q1 - what objects do we want to record data about?
(not necessarily just plants, also have cultivars,
families & higher order taxa, locales etc.)
Q6 - what user input is allowed?

We have covered a lot of these questions in an informal manner
but it is imperitive that we start to converge on some answers.

I think we should start with Q2 for plants for now.
I'll post a separate post with the answers to some of these.

Agree, sounds good.
Exactly what questions we need to answer will evolve once we get started.

John S.


--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net




Archive powered by MHonArc 2.6.24.

Top of Page