I've read and been taught quite a bit about formal requirements gathering, in a waterfall context: spend months grinding out use cases, turn those into a spec, and eventually deliver a bloated piece of crapware that noone wants.
The projects I'm working on now have a few special characteristics: the stakeholders are academics, the development teams are very small (2-3 FTE), the overall timeframes are short (3-9 months), and the stakeholders are pretty flexible on the final shape of the product. (They ask for A, B and C but get A, X and Z - no problem.) We usually get regular, if limited access to stakeholders: say 1 hour per week.
Some consequences of the above:
- we need to get coding within 10 hours of stakeholder interview time, often less.
- we can continue to gather requirements throughout the whole process
- scope is extremely flexible. Time and budget is fixed, but scope is whatever is finished when we run out of time.
Obviously we use an agile method, but because team membership is very dynamic, there's no real chance to build up a solid scrum process, for instance.
In my role of PM/client liaison, I've developed a habit of making requirements gathering a spreadsheet (Google Docs) with categories as follows:
- "We can implement now" (we think we understand it well enough, and it's defini
- "More details/workshopping needed"
- "Low priority" (often stuff that one user mentioned once, but we haven't heard of since)
- "Big features to keep discussing" (a substantial new feature set, particularly integration with something else. Often these would be nice, but we just don't know if we can get it done in time - in which case, we shouldn't start.)
Issues that my "methodology" isn't addressing that I'd love to hear suggestions on:
- Catching showstoppers early on - sniffing out requirements that heavily constrain our choice of platform/technology/solution/...
- Structuring and scheduling future requirements gathering sessions such that we know how long we can work on a certain feature set before we hit the fog of uncertainty.
- Knowing whether something is high enough priority that it will definitely make the cut (and if not, spend no more time investigating it)
- Managing sets of interdependent features
- Managing features that can be developed to varying degrees (eg, get 80% of the benefit for 30% of the cost - how do we know if we should spend the other 70%?)
- Managing choices (in one case, do we implement authentication mechanism X or Y - there's not much benefit to doing both, but there are big uncertainties around both)
- Dependencies: often, it makes no sense to start implementing Y until we've seen how users react to X.
- Relationship between "requirements" and "issues" in an issue tracker. Do you just throw everything in the tracker, and keep updating issues as you learn more about them, possibly splitting or merging them?
So - I'm interested to hear how other people approach these matters. A search for "requirements tools" turned up nothing useful - just a bunch of enterprisey desktop CASE tools.
In my opinion, you need more interaction with the stakeholders/business/client in order to 1. prioritise the features and 2. create a test plan for UAT so that you know when you can stop adding features.
Flexible scope is ok so long as you can say that there is a core set of functionality that is essential and that will make the users happy. You say that the project is finished when you run out of time. So why even do anything? Maybe you can whittle down the scope until you know what the absolutely essential functionality is, and if the users are happy with that, don't bother adding more.