4

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.

Steve Bennett
  • 114,604
  • 39
  • 168
  • 219
  • I'd forgotten about this question. One great tool we started using is Pivotal Tracker. It's quite good at managing user stories as they progress from vague wishlist items through to more concrete tasks for implementation. They can never get scheduled until they're estimated, which forces the issue a bit. – Steve Bennett Feb 16 '14 at 11:46

2 Answers2

1

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.

jhsowter
  • 619
  • 3
  • 8
  • "So why even do anything?" Maybe that's a difference from the private sector: our goal is to maximise outcomes, not to minimise costs. – Steve Bennett Feb 07 '12 at 07:15
  • Also, in our particular case, we're trying to effect culture change, so the users are not the only stakeholders. Maybe the users are "happy" already, but that doesn't mean we (and the project sponsor) don't want to improve on the way they're currently working. – Steve Bennett Feb 07 '12 at 07:16
  • @SteveBennett I see what you mean about the goal being less about cost and more about outcomes. It seems your desired outcomes are vague or not well understood. Perhaps this is because there are many stakeholders with different goals? I just think that any agile methodology needs lots of input from stakeholders, so you know if you're meeting your goals or not. I doubt that one hour per week would cut it. That's why I suggest more input from stakeholders in terms of prioritisation and test cases. – jhsowter Feb 07 '12 at 10:45
  • Sure, but what about tools and techniques? – Steve Bennett Feb 07 '12 at 11:45
  • As far as input from stakeholders goes, ideally you should have one of them on your dev team full time to answer questions and give feedback. If they can't afford them full time, you could compromise with some part time schedule. But ultimately if they don't want to work on the project, then they can't expect the project to reflect their needs. Sorry, that's the closest I can get to a "technique" with my limited experience of agile. – jhsowter Feb 08 '12 at 02:36
1

That seems to be the same problem we have. We use an issue tracker (bugzilla) for issues and requirements. That works pretty well during initial development of new modules. But, if you have to change some features or extend the functionality of your modules half a year later, all you you have is a huge list of issues and requirements that is totally unstructured.

In addition, a lot of information is given in the discussion threads of the issues or requirements. That means a lot of text to read for mostly a small part of information.

So, rewriting the requirements in a structured document (word) afterwards seems to be the sole solution for me so far.

Markus
  • 11
  • 1
  • Yeah, I would say the general process in many areas is a progression from unstructured masses of text describing problems, issues, desires, to highly refined, succinct, structured statements of work to be done. Bug trackers only start to work properly at a certain level of refinement. – Steve Bennett Feb 19 '12 at 04:38