Requirements management and agile / scrum
In software development, it is quite common to use agile / scrum. In this approach, the user requirements are elaborated in user stories. Subsequently, these are specified in scenarios, also called use cases. The user story is focused on the happy flow. The scenarios / use cases detail the desired behavior in case of deviations and exceptions.
How does this match with requirements? You could argue that the user stories / scenarios / use cases are the requirements. However, if you still have a set of "loose" requirements, it is useful to link them to the user stories. Most likely the conclusion will be that there are missing user stories. It is also wise to walk through your business processes again, and map the user stories to the business processes. So you're sure you're beaten by not supporting critical processes...
To manage this effectively and consistently I would recommend to use software developed for this purpose, and not mess with self-built solutions in Office. Use that specific software from day one, because the longer you keep messing with Office, the harder it is to migrate ..
"When" the key word in requirements management ...
Often in gathering requirements on a new project, everything is that can possibly matter is collected. This provides two challenges:
- The amount you see the forest for the trees. There will be duplicate formulations and each user sticks to his own formulation.
- The formulation does not take into account the condition under which the formulation applies. Without a specific condition, the formulation should therefore always apply, and that can lead to strange / expensive / not necessary ICT solutions. If you describe a requirement in a purely "use case format", you prevent these two challenges manifest themselves. Instead of quickly gathering everything it is recommended to briefly reflect on each formulation. Please take the "when" into account as well. Due to the addition of "when" the possible solution will be substantially different and simpler. An example of the past week confirms this. There was a use case formulation without "when". The IT solution must validate compliance with all conditions before a production machine starts producing. After some discussion "when" was added. The "when" condition added is to check in case of a change. So instead of continuing to check the conditions, thereby delaying the production, now only conditions are checked when there is a change. The IT solution is easier to realize, it is still safe and the production output is higher! In short, "when" will help you !!