When we create storyboards and begin discussing them, whether we're doing it in a passive way or an active way, we try to find the happy and the sad paths that should be addressed in the program. One way to address the happy and the sad paths is through the use of scenarios. Scenarios are similar to storyboards in that they illustrate sequences of interactions. But they have quite a bit more detail. Instead of just little stick figures, you're actually defining who, what, when, where, and how things are interacting. Answering those questions becomes a scenario. The scenario shows how all of the system components are interacting to accomplish the implicit objectives and determine how the implicit objective can be met. You also discover, as you go through the scenarios, how you would hit the sad paths, like I can't find the movie or I pulled the dollar away from my friend and they fell into the street and died. Ugh. When we create scenarios, creating scenarios is made simpler by discussing the concrete examples of real life interaction sequences. From these interactions, you can gather concrete examples of hypothetical interaction sequences. You can ask specific questions about them. From that, you can also elicit underlying objectives. By that I mean, you can say, well, why would you do that? Or why could that happen? All of these ideas can later be pulled together to generalize the interactions into models of the desired behavior. Let's say that in our meeting scheduler, the meeting initiator asks that the scheduler plan a meeting with some particular date range. This request includes a list of desired participants. The scheduler goes and checks to see that first, the initiator is allowed to create a meeting and that their request is valid. So for example, you can't say that you want the meeting to start in January of 2017 and end in December 2016. That would be a faulty date range. The scheduler should be checking that. As an additional requirement, one of the participant returns their constraints. Then, the scheduler will validate those constraints. Just like in making sure it's not looking at invalid dates, it does that for both the initiator and the participant. Additionally, when the participant returns their constraints, the scheduler will validate them. Just like they did for the initiator of the meeting, we also check to see that the participants' dates are also correct. In this confirmation, the constraints are confirmed as being received. Once all of the valid constraints are received, the scheduler determines a meeting date and a location that will fit the constraints. We all know this never really goes well. There are going to be conflicts. But these are the key goals. Finally, the scheduled meeting date and the location are notified to the initiator and also to all the invited participants. Again, this is the happy path where everything goes well. In scenarios, we have positives and negatives. Positive scenarios are what should happen in terms of the one or more behaviors that the system should cover. Negatives, you can think of as counter examples. Negatives illustrate what may not happen. These are behaviors that the system should include, but they should deal with them. This relates to our sad paths. In our scenario example, what are these? What might a negative scenario look like? Well, one sad path might be that the participant returns a list of constraints that covers all of the dates within the prescribed date range, but they mess it up and go a couple days later too. Is that really a sad path? They're saying they're available. So what do you do? As another example, let's say that the scheduler forwards the message of confirming the dates to all participants, asking for alternative constraints with some extended date range. In this case, while this is not a sad path, it is a negative scenario. Because we have an implicit requirement that participant behaviors are not disclosed to others. If I say, nope, I can't be there Friday, you shouldn't know that. So this is an example of a negative scenario that isn't a sad path, as sad paths are described in the software development life cycle. However, it is not allowed by the system. That's why we define it as the negative scenario. Within the program, that functionality should just not exist. We do need to think about it though, so that, that would provide an error if it occurred, maybe. Do we need to code that in or not? Balancing act. So scenarios can also be defined as normal or abnormal. Normal scenarios capture the course of the action as it is expected. These overlap very closely with the positive scenarios. Abnormal behavior scenarios show the desired interaction under exceptional circumstances. If you work in an agile environment, all of these terms end up being confused. We confuse normal, abnormal, positive, negative, happy path, sad path. Be careful when you are hearing these terms because we don't always use them in very firm ways. Sad paths overall are covering the abnormal paths. Negative scenarios can usually be considered as sad paths too. In this example of an abnormal scenario, where that abnormal scenario is that the participant constraints are not valid, that would be a sad path. You wouldn't want to raise an exception. You wouldn't want to just throw up an error. You wouldn't want the program to crash. You need this abnormal scenario to make sure that it's accounted for. However, this is not a negative scenario, despite the terminology. It sounds negative. But negative scenarios are policies or ideas that are not allowed to happen. This scenario is abnormal in that it's allowed, given the policies and expectations, but we do not expect it.
