I read and taught a lot about collecting formal requirements in the context of a waterfall: spend months grinding precedents, turning them into specifications, and, ultimately, delivering a bloated piece of crapware that no one wants.
The projects I'm working on now have several special characteristics: the stakeholders are scientists, the development teams are very small (2-3 FTE), the general timeframes are short (3-9 months), and the stakeholders are quite flexible in the final form of the product. (They request A, B, and C, but get A, X, and Z — no problem.) Usually we get regular, if limited access to interested parties: say, 1 hour a week.
Some consequences of the above:
- we need to get coding within 10 hours from the time of the interview with interested parties, often less.
- we can continue to collect requirements throughout the process. Areas
- extremely flexible. Time and budget are fixed, but the scope is what ends when we run out of time.
Obviously, we use a flexible method, but since team membership is very dynamic, there is no real opportunity to create a complex scrum process, for example.
In my role as a PM / Customer relationship, I developed the habit of collecting spreadsheets (Google Docs) with the following categories:
- “We can realize now” (we believe that we understand this well enough, and it’s definitely
- "More information / workshop required"
- "Low priority" (it often happens that one user mentioned once, but since then we have not heard)
- "Great discussion opportunities" (a significant new set of features, especially integration with something else). Often this would be nice, but we just don’t know if we can do it on time - in this case we should not run it.)
The problems that my “methodology” does not solve are that I would like to hear suggestions on:
- Exciting show stops early on - sniffing requirements that greatly limit our choice of platform / technology / solution / ...
- Structuring and scheduling future requirements collection sessions so that we know how long we can work on a specific set of functions before we hit the fog of uncertainty.
- Knowing whether the priority is sufficient, that he will definitely make a reduction (and if not, spend more time researching it).
- Manage sets of interdependent functions
- Management of functions that can be developed to varying degrees (for example, to get 80% of the benefits for 30% of the cost - how do we know if we should spend another 70%?)
- Election management (in one case, we implement the authentication mechanism X or Y - there is not much benefit for both, but there are also big uncertainties around both)
- Dependencies: it often makes no sense to start implementing Y until we see how users react to X.
- The relationship between "requirements" and "problems" in the tracker problem. You just drop everything into the tracker and continue to update problems when you learn more about them, perhaps sharing them or combining them?
So - I’m interested to hear how other people approach these issues. The search for “requirements tools” did not bring anything useful - just a bunch of CASE business tools for enterprises.
source share