This is a blatant recruitment drive for a new sourceforge project. It's going to take some explaining, but here goes...

There are three big time suckers in development: bugs, doing the wrong thing, bringing new developers up to speed. I want to have a go at the second one. I want to tie the development process right into the original requirements document.

This isn't a new idea. Ward Cunningham invented FIT for this purpose. What I am proposing is a FIT like tool for small web shops with a few extra wrinkles.


1) Requirements are written on a word processor (usually word).
2) The use cases are best communicated as stories.
3) If you want to have a project to be flexible along the lines of the problem domain, then the names of classes/interfaces should match the language of the domain.
4) Use cases for web apps. are easy to describe after the initial discussions, but tend to get very detailed. Click here, then there, etc.
5) If you want to monitor project progress then the only reliable indicator is working code.
6) A measure of working code that both business people and programmers understand is a runnable use case.

The plan...

A programmer and client sit down next to each other with the requirements document in the word processor. The format is textual, something like...

"They log in to their account. The first thing they will see is that their account has their opening balance".

Of course the document has a title and a lot more text. The programmer highlights terms that will need precise definition...

"They log in to their account. The first thing they will see is that their account has their opening balance".

The next thing we do is list the actions and output we expect as a bulleted list...

Opening balance test
* "New user" with name=fred, password=wibble
* "Log in" with name=fred, password=wibble
* Click "My account"
* Expect to see "$200.00"

If it starts with quoted text then it's a macro and the click line is obvious. The expectation is the tricky bit.

Ok, having adjusted the document while sitting next to the client, we now upload it to our project server. This server will parse this document to build a central requirements repository. It has two main goals.

The first is to add highlighted text to the glossary. This is a special requirements area. If any definitions are missing then they will be highlighted in some nasty way (red if you are not colour blind). The glossary pages are otherwise just like other requirements pages (they are distinguished by title or something).

The next is to build test cases from the bulleted lists and run them. After uploading the page a download link is given for pulling the same document back (like FIT). Besides the missing glossary entries, ant failed actions are now also highlighted. If we haven't written any code yet, likely all four list items will be marked red.

So far so good.

As the project progresses, more of these tests and glossary entries will "go green". The measure of these will help to measure project progress and to aid in sign off. They will also help with future maintanence.

The requirements docs. can be uploaded and downloaded by everyone in the project. Both developers and business people can edit stuff at certain times, and a record and history is kept of all of this. The information and summaries are on-line and there are lot's of possibilities here. Test cases can be integrated into the full application tests of the developers.

What (PHP) code is needed...

1) A word file or RTF parser.
2) The repository.
3) The test case generator and runner.
4) The glossary.

Also needed are people willing to try out such a tool at the alpha stages so as to refine it. For such a project to work, it needs real world experience in the early stages.

It is not a big project, probably a year at most. Anyone feel they could contribute? I'd be project lead to get to the first alpha I am afraid. Getting a minimal proof of concept out quickly needs someone as a central point of contact. It also needs someone keeping the milestones minimal. Once user feedback started to come in it would take on a more community feel as I drop down to just coding. The management of this would be Scrum like via Sourceforge. I'll explain the system in later posts if anyone is interested.

So...anyone able to help?

yours, Marcus