My experience with change
On this chapter we saw how requirements ultimately change. This is an inevitable part of software development. I’ve been developing an app this winter and I’ve seen how much the requirements have changed, even before releasing the app. This happened to me when I realised that one of the requirements conflicted with another requirement. That’s when I decided to call my friend who was responsible for the app and asked him about it. He decided to change requirements that we have already established. Then I had to change a lot of what I’ve made.
Alternate paths
I liked the “interview” of the Alternate path. I had the same thoughts when I was reading the use case. If the bark recognizer opens the door for them, why bother with the alternate path of the remote control? But it is true that without that alternate path the use case would feel incomplete . The analogy with the credit card use case is very good. Because just like the credit card, the bark recognizer can fail. To be solely dependent of the bark recognizer doesn’t make the program robust. So it makes sense to have that alternate path that takes care of that potential problem.
Retrieved from https://www.bridging-the-gap.com/what-is-a-use-case/
Cellar Door Blog 