The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Because that's not how requirements docs. are written. We have to go with the situation as it is rather than as we would like it. Buy in is going to be the biggest hurdle.

Maybe (probably?) i'm in the ignorant minority, but i would disagree and posit that email is actually how requirements docs are written. in my experience, very rarely are the client and developer ever in the same town, let alone the same room. in my day job, i consider myself a "small web shop" of 1 man, albeit working for a company of thousands (meaning all my clients are in-house), and only once in the past year have i actually been able to sit down with a user and go over requirements. in every case, the application is spec'ed and changed and fleshed out with a flurry of emails. unfortunately, the same holds true in my freelance gigs. in this regard, an email/web-based solution would be fabulous, and ultimately more useful and with a broader appeal, i think. When faced with building a web application, which is by nature a rapid development process, nobody wants to create Word documents. To most people they seem like a beaureaucratic artifact.

Again, i'm probably just woefully and detrimentally ignorant.

"Buy-in" certainly is going to be the biggest hurdle. I would bet most small web shops, the type that could benefit most from your project, don't even use requirements documents. They operate, for better and certainly worse, just as I explained above.

Maybe (probably?) i'm in the ignorant minority, but i would disagree and posit that email is actually how requirements docs are written.

I used to find that when a client turned up with nothing, the developer would initiate an e-mail exchange. Whenever the clients had researched a project (in my London based case the majority) they would arrive in Word form. I am certainly not ruling out e-mail in the future (and I think it has been mentioned in this thread already). It's just that I had to punt with one solution for a first alpha.

And being interactive, this version is easier to write a tutorial for.

Originally Posted by josheli

Again, i'm probably just woefully and detrimentally ignorant.

Users are never ignorant, but some of them do get neglected from time to time Don't worry, your comments have been taken on board and we'll see about adding e-mail transfer (in both Word and text form) later on.

Originally Posted by josheli

"Buy-in" certainly is going to be the biggest hurdle. I would bet most small web shops, the type that could benefit most from your project, don't even use requirements documents. They operate, for better and certainly worse, just as I explained above.

I think the biggest hurdle will be the clients. The developers only have to buy-in once after all, and if they don't already have QA or testing then this tool won't save 'em .

I wasn't aware that you were intending to parse and grab content from all of the flow charts, headlines, wordart and all of the other non-rich text stuff that Word does.

We aren't . We are pattern matching and altering just the bits that we want to. Everything else is preserved as is. It's very important that the tests and verbal/visual explanation sit right next to each other. The tool is to aid communication and that's best achieved by having all relevant information in the same locality.

The idea is to keep things simple - extracting viso diagrams, tables, spreadsheets etc, would be nice, but they are more specialized formats that generally illustrate particularly unique aspects of a solution concept...

I think what we are looking for is the straightforward unambiguous representation of elements in a document. Bullet points, lists, highlighted phrases, etc... Stuff that someone with no particular specialization in modelling or design process/management etc can understand and write without having to understand formal software design techniques or how to use a diagramming tool...

I think project communication can always benefit from simplicity and clarity, regardless of the sophistication of technical/spatial details involved.

It's been more than a year that the project has started, and after 6 months of almost inactivity, I would like to know if new people want to take part in it :-) You can check http://arbiter.sourceforge.net for more information.

I'm thinking about starting a requirements project that sounds similar to arbiter, though starting at the opposite end with wiki/plaintext. The idea of choosing terms and feshing them out with links to nested requirements and tying to test case examples is similar however, as is the idea (in a further iteration) to import from MS Word.

What's that status of arbiter? I might be willing to help resuscitate it. The privilege of working with Marcus would definitely be worth it. Thanks for SimpleTest and Php in Action, by the way.