Now that we have elicited Amanda’s needs we can start to work on requirements. As we begin working on creating new requirements we will need to manage them effectively so they are useful to Amanda and Bob through out the project.
Trace Requirements
Tracing requirements means thinking about and writing down the relationships between requirements. This means linking requirements through time and levels as well as to each other. Some requirements will be dependent on others, some will have relationships to effort and other will need to be link to specific validation.
As an example, for Amanda, she will need handle bars on her bike. Therefor “needs handle bars” may be a requirement. It will be linked however to a more abstracted requirement “needs a way to steer”. It will also be related to the requirements “needs to be available at Bobs shop”. If in the future Bob changes the stock he has on hand, “needs to be available at Bobs shop” will be satisfied by a different set of handlebars or solutions. If we hadn’t linked “needs handle bars” with “needs to be available at Bobs shop” we might have missed that the handle bars we were planning on no longer satisfy all the requirements.
Equally when reviewing requirements Amanda may ask where the requirements “needs to be available at Bobs shop” came from. We will have linked Bob to that requirement as the creator and if we have questions about stock on hand, we will know who to contact.
Maintain Requirements
Our requirements are the back bone of our analysis work. They are a core unit of BA work. More importantly Requirements are the questions that solutions answer, ask good questions get good solutions. In this instance the solution we are aiming for is a bike. To make sure we are writing good questions, or requirements, we need to make sure our requirements are maintained.
Maintenance means that our requirements remain correct and current throughout the lifetime of the requirement. As we learn new information and create new requirements or as the project progresses requirements can become outdated. Take the handle bar example above for instance. We may learn that Bob begins to use an online portal for same day delivered parts. This means that Bob has access to all the part possible. If we don’t update our “must be available at Bobs shop” requirement to reflect this, we may end up asking Bob if a specific part is available every week; Frustrating Bob and adding friction to the entire project.
We will need to make sure that we are keeping all the requirements updated as we learn new information. Including keeping up with the tracing and adding new relationships where appropriate.
It may be important to note here that requirement maintenance can extend after the specific project has finished. Many requirements can see reuse, especially in larger enterprises. For instance Amanda may know someone with a similar use case and need for a bike. Luckily we have a manicured requirements list which we have maintained past the life of the project. This is especially true for the more abstracted requirements.
Prioritise Requirements
Once we have a semblance of requirements we can begin to prioritise them. Prioritisation is crucial as some requirements may conflicts, there may be time pressure, or some stakeholders may be resistant to some requirements. By having them effectively prioritised we know which is most important and what need to come first.
Do to this effectively we will need to come to agreement on what