Employing user stories
Video: Employing user storiesThere is another common format for writing description of parts of our application. It's called a User Story. Now a user story is simpler and shorter than a use case. It still describes a single small scenario from a user's perspective focused on their goal rather than on the system. It's what do they want to do and why do they want to do it. But unlike a use case, which could be several pages, a user story is typically written as just one, perhaps two sentences, and they're very commonly written on index cards.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Employing user stories
There is another common format for writing description of parts of our application. It's called a User Story. Now a user story is simpler and shorter than a use case. It still describes a single small scenario from a user's perspective focused on their goal rather than on the system. It's what do they want to do and why do they want to do it. But unlike a use case, which could be several pages, a user story is typically written as just one, perhaps two sentences, and they're very commonly written on index cards.
And that forces us to keep them short and sweet, and that's kind of the point here. But even though they are concise, user stories do generally follow a particular format. And the format looks something like this. "As a" -- type of user or role, "I want" -- here you describe the goal, "so that" -- the reason or the benefit. The final part, the "so that" is optional, but it's very useful. So an example, as a bank customer I want to be able to change my pin online so that I don't have to go into a branch.
Focused on one specific goal of one specific user for a particular reason or as a regular user I want to search by keyword so I can find and read relevant articles. The idea is you can quickly brainstorm a lot of user stories, even quite particular ones. As a user I want to sort entries by date so I can find the most recent content. We could be describing big goals, we could be describing small but important specifics like this.
We're still focused on intention, say, as a reader I want to change the font and color scheme so that I can read in different lighting. But we're not describing user interface, we're not actually describing buttons that are clicked or how this is done. We're focused on the intent. And what we're doing is expressing one need. We're not detailing alternate paths or exceptions or listing any technical information. They are very quick readable summary of what a specific goal is and why the user wants it.
They can be done very early on, often right at the start of a project, and they can serve as placeholders for deeper conversations that you need to have. When you first hear about them, it can be tempting to regard a user story as just a short use case, but that would be a mistake, they are really very different things. Well, the difference in format is obvious, one is very short, one could be one or several pages. Perhaps my favorite description of a user story is that it is a placeholder for a conversation. It's a reminder that we need to get deeper into the details of something.
Whereas a use case we can regard as a record of a conversation that already happened. It will detail the steps of how a particular goal may or may not be achieved. Now certain software development methodologies favor one of these over the other. If someone told me that their company was doing a formal unified process methodology, I'd expect to see use cases. But if I'm working with Scrum or Extreme Programming teams, I'd expect to see a focus on user stories. But these are not direct competitors. They are different tools that should both be part of your own toolkit.
You could use one or the other or in many cases, both. But however you do it, describing your system in simple language is incredibly useful. We don't just write these and then save them as historical record, it's that whatever we write--use cases or user stories or both--we use as input for the next stage of the process, dropping down into identifying the main objects that our application needs.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.