We have a culture here that we do the use cases first and then work on implementation and then derive the requirements from the use cases when all is done. But I learnt that the requirements always have to come first, so that we are always reminded of what we are trying to solve while doing use cases. How do you do it?
Users first. Try to create user stories from a customer perspective focused on solving a problem.
Requirements first Which will give you a MVP Cut down on the original reqs to see if MVP is worth the scope ( to launch sooner) Use cases will be covered in reqs, if not, the requirement collected were not done right Corner cases next(if needed) Prototype it Dog fooding next Soaking, iterating and optimizing next. Good luck
This is good, except dog fooding would not work if you want to cut down scope and focus on MVP.
Right. But purely from the launch perspective, the minimal the better. Agreed.
Doesn’t matter. Be iterative. Customers first. As long as your capture working backwards from the customer, doesn’t matter if you start with the use case or the requirement. What’s important is to identify your target customer segment and hence customer persona clearly.
Chicken and egg problem huh? The only answer is to have quick feedback and frequent revision, as often as possible, so you go toward the right direction and get there eventually, fast.
Work backwards from the customer’s perspective. I think that could be either one tbh.
+1000
^not frugal