*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

[dervishspin.livejournal.com]

SO I thought you had captured one of the Use Cases I would ask for. It's inherent in the name. Then after reading it I realized I had made an assumption which was not true, so I'll ask a different way.

How about a Requirements Inventory?
Managing requirements for IT projects is... OMG awful. The DBs that are out there are hideous, limited in functionality and expensive. As a result, most companies are effectively tracking their requirements through email and excel spreadsheets. There must be a better, more intuitive way. Someplace that allows multiple people to work on it at the same time. Some way to track which business area came up with what requirement for what system which matches what High Level Requirement or Scope Statement.

I think as you manage your requirements for Querki, you will see what I mean.

Managing Requirements for a Managing Requirements Use Case will probably feel pretty "meta" and strange, actually.

Did somebody say meta?

[etherial.livejournal.com]

It sounds to me like jducoeur has a use case for tracking use cases. I'd start the requirements list with a field for Requirements Lists.

Re: Did somebody say meta?

[jducoeur]

See below -- very nearly the first thing in the plan...

[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.