There are many ways to determine what should be happening in a program. In addition to the questionnaires, repertory grids, card sorts, conceptual ladders and the other techniques that we've discussed, another thing that can be useful are narratives. Narratives are especially useful early on for eliciting and validating the understanding that you currently have of the system. One way to tell narratives is through storyboarding. You can also use scenarios and prototypes. With prototyping, you could do a prototype or you could also create an actual working product and we'll go through the differences there. Please note that when I say working product in an agile environment, I mean that the product actually executes, it is not complete but it does work. You're adding individual features that work each individual iteration. You show how it works. Then you get feedback to keep growing and make happy paths and sad paths as identified by the users through the storyboards and the scenarios as they're needed. Happy and sad paths will be discussed shortly. All of these different techniques can be used in any software development life cycle. The terms that I just used though of storyboarding, scenarios, I also mentioned user stories, these are things that are usually heard within an agile environment. So, how do we get requirements? First, we're trying to ask how are things running on the system as it is? Then how should they be on the system to be? One of the loosest forms to represent these kinds of questions, is a storyboard. Storyboards are frequently used in agile development models but they can certainly be applied anywhere else in a spiral model and a waterfall model or any of the other design patterns that we have out there. Think of a storyboard as a movie just made out of a bunch of individual snapshots. The snapshots all come together. They tell a story about the system. Well, hopefully, in a movie they tell the story about the movie. But these are quick and easy to understand for all that are involved. Two techniques to create a storyboard include passive and active. In passive storyboarding, you're kind of going off of your domain knowledge and say, Okay, I think I know what we want to do. So, given that, here's the story. You tell your stakeholder the story and you see if you're right. Your other stakeholders go through that story with you and have them explain and validate your statements. In active storyboarding on the other hand, stakeholders are saying, "here's what we want to do," and you kind of create the story board together. The stakeholders are contributing to joint exploration. This is useful when you aren't really sure what's going on. You're working together in a very active way. In either technique, you need to determine how the story of the software is coming together. In addition to determining the main actors, also you need to ask who are the rest of the cast? Do you have walk ons in the background? Who all do you need to talk to? This allows you to figure out more about your domain knowledge and know what questions you need to ask and whom you need to ask those questions too. So, going along with the movie idea or I guess a TV idea, you just want to ask what happened through specific episodes where you could be involving the main cast, the main characters, all the cast and the Locketts. You ask questions like what if such and such an event occurs. If that happens, what is the ideal outcome? If things go totally wrong, what are the consequences? Storyboards are beautifully simple. And as you can see from this picture, they're understood by all. They lack a lot of detail. However, they can act as a key discussion point. You're getting started. If you are really, really bad at art, remember their drawing stick figures? Totally fine. I don't mean that as a joke. Seriously, a lot of these drawings, these storyboards and the scenarios that we'll be talking about here, are being drawn out on napkins when you go to a lunch meeting and you're discussing possibilities or maybe skyping over the phone or things like that. They look horrible. It's okay. In this picture you see a very simple example of a happy path of a prank. In this picture the kid wants to play a trick on his friend. So, the kid puts a dollar or something. We're going to assume that we're putting it on a string, and we're going to assume that the friend could not see that string, and the person who's pulling the prank goes and hides behind a bush. The friend walks by says, "A dollar!" And they try to pick it up. The hacker of the situation then suddenly or maybe very quickly pulls away the trap. They pull away the dollar. There are many possible consequences after that happens. The happy path is that the friends tricked and they go oh, how did I fall for that? And they start laughing. Or they could get really mad. Or in trying to get the dollar, they could fall and in doing so fall into the street, get hit by a passing car. Okay, that went into the morbid side of things. But let's come back to the idea of what we're doing in dealing with software requirements. We have happy paths. We have sad paths. Happy paths are what we expect to happen. In this example,the friend gets tricked, both laugh over it. The sad paths are basically all of the other possibilities. Sad paths are things in your program that are totally feasible, but just not quite what you want. As another example, if you were searching for, say, a movie title online. We go on to, let's say, Amazon and we look for some movie. The happy path would be that you type in the title of the movie and movie pops up. Good. A sad path would be that Amazon does not find it or whatever movies searcher you're using. The question is then what happens? If you are creating a site like this, you could have the user add the movie in themselves and continue the growth of the system. You could give an error and just say, sorry, it's not here, or your whole system could crash. Note that sad paths are different from exceptions in code. If you do a lot of coding, exceptions are things where you're catching code that could kill the program, it could modify answers within your programs that the program is able to continue to proceed, or it might give an error. We've all seen the exception code and we've worked with the errors. But these are different from sad paths in that exceptions deal with recovery. Sad paths deal with the stuff that we just hope won't happen. It's not what we necessarily expect, but it really is likely at any point.
