The decision to create requirements with Use Cases or User Stories are based on four things
- Stakeholders Involved
- Developers Involved
- The complexity of the System
- Implementation Risks
The comfort of the stakeholders is a key part of this decision. Some stakeholders require the rigor of well-documented use cases where they can see step by step what will happen in the new system. Other stakeholders will be ok with user stories where the focus is more on the outcomes they are looking for. Regardless of which approach you choose, how the approach is viewed by the stakeholders will determine the trust the stakeholders will have in how the process will result in the system they require.
The strength of the developers is another key part of the decision. If the stakeholders are experiences, user stories may be enough for them to develop the system. The user stories also give the developers more freedom in determining what that system will look like. More junior developers may require the step-by-step that is documented within use cases.
The more complex the system, the more use cases may be required to map out exactly what should be happening in what order. If the system is more straightforward, the step by step is understood without it needs to be articulated. This criteria also opens the door for hybrid solutions. The complicated parts of the system can be mapped out in detailed use cases and the remainder in user stories.
The last criteria is the risks that are involved once the system is implemented. If there are parts of the system where the severity of an incorrect process is high, then use cases that set out the step-by-step process should be used. Usually, n where money or lives are involved, the step-by-step process should be stated.
One last note, regardless of whether use cases or user stories are used, the business rules should be mapped out in detail. I will write about business rules in a future post.