*God*, I love this project

[jducoeur]

I'm rapidly fleshing out the Querki Use Cases and Features. The Feature list is growing terrifyingly fast, but that's what the Use Cases are for: they are going to help drive which features get implemented when. (And more importantly, which features to *not* implement yet. I'm going to have to pick my battles carefully. Nothing gets implemented until we have a concrete use for it.) I'm starting to sincerely believe that this will be useful enough that people will buy memberships.

I think I'm going to start talking about Use Cases, something like one a day, over on the development blog (querki_project). Please come join in over there, kibitz and comment, point potentially interested friends at it, and keep the ideas coming! The "what we're going to try to accomplish" train is rapidly gaining steam, and the project is looking ever-cooler and more useful...

Comments

[jducoeur]

One of the very first things I'm planning on building, and have been almost from the start -- that's the Project Management Use Case. I plan on having Querki dogfooding its own project-management system as soon as I possibly can. (Probably early next year.) I'm very sensitive to all of this, having spent fully six months at Memento doing to deep review of all the project-management software I could find. And I have *passionate* opinions about usability for this stuff.

The current vision there is somewhat focused on this project: it is built around the usual Agile concepts (Use Cases, Features and Stories), and is aimed at letting end users vote on which things they consider most important. I don't precisely think in terms of "requirements" per se: instead, the structure is a many-to-many-to-many map of those three concepts. The Use Cases drive which Features to build, and the Stories describe the fine-grained specs and the effort required.

But a more conventional Requirements database would be dead-easy -- indeed, taking out the need for voting means that this becomes a completely orthodox Querki app, requiring few or no special features at all. Once things are basically up and running, let's talk specs -- odds are that I could whip out much of it super-fast. (The only hard part of a more-traditional system is the workflow and signoff side, and I'm already pondering how that engine will work...)

[dervishspin.livejournal.com]

Oh good! Keep me posted. I am probably slightly less passionate than you about the usability of it, but possibly not by much. It is a bloody thorn in the side around here.

"Conventional" would be useful. We use Agile while we can, but we are not an Agile shop across the board so some of the voting stuff is interesting, but not required for most stuff we are doing, plain old prioritization functionality would be good enough.