KIT206 Tutorial 1 – User stories to structured scenarios
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
1/2
Tutorial 1: Agile User Stories to Structured Scenarios
Purpose: To reflect on Agile versus more structured approaches and to make a first attempt at
developing a structured scenario for the Researcher Assessment Program case study.
Outline
Agile user stories are a lightweight methodology for capturing requirements and hence describing use
cases, but they leave out much detail. A structured scenario is a textual description of a discrete block
of functionality in a system (that is, a use case) and can describe the same interaction as a user story.
It should specify all possible execution paths, including any errors. We use a template that is based on
a number of alternatives that software designers use for describing use cases and scenarios.
As the user must interact with something, it is typical for low-fidelity (often hand-drawn) UI
prototypes to be developed at the same time as the scenarios. The second part of today’s tutorial will
have you developing structured scenarios for the RAP, which you will refine over the coming weeks.
1 Agile User Stories (~30 minutes)
Agile user stories are typically one sentence descriptions of a user’s interaction with a software
system, with three components describing who is doing the action, what action they need to perform
and why it is of benefit to them or the business. In Agile methodologies these often replace a more
formal requirements document. The basic structure of a user story is:
As a
Task: Form groups of three (these may be your future assignment 1 groups but that is not necessary)
and spend 15–20 minutes devising user stories about existing products that you use (these may be
web services or desktop applications). Start with functionality these products already have (i.e.,
reverse engineer the user stories), then think of functions you would like them to have.
While you are doing that consider the following questions, which the whole class will discuss when
you are finished devising some user stories:
• Was it an easy way to describe a software requirement?
• Do you think it conveys sufficient detail about a requirement? Would it be enough to guide
later software development?
• Is it a technique you might consider using in the future?
2 Your First Structured Scenario (~30 minutes)
Consider a common use case in a spreadsheet program of loading text-based data and interacting
with it. In the RTM for a (very limited) spreadsheet program, this might be represented by the
following entries (imagine it was extracted from a much larger document):
Entry # Para # Requirement Type Use Case
42 17.1 The user shall be able to load tab-delimited
text files.
SW UC42_User_loads_Text
43 17.1 The user shall be able to sort data based on the
values in the first column.
SWC 42
44 17.2 The user shall be able to print the sheet. SWC 42
Task: Complete a structured scenario for this imaginary use case, leaving blank those fields for which
there is insufficient information in this example. The structured scenario template is available on
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
2/2
MyLO or via a link in the description area for this document (below the viewing window). Remember
to remove the text ‘Scenario Template’ from the top of the document.
Points to note:
• If you believe that there would be other use cases used as part of the scenario you are defining,
remember to mention them (you do not need to write them, as the name should be sufficient
explanation for this exercise).
• Consider that, in this example, the user does not have to sort the data or print the sheet as part of
the use case, so you need to specify alternative paths through the set of actions. Use the scenario
notes section of the template to indicate the order in which the actions listed in the action–
software reaction table may be taken. This allows the action–reaction table to exhaustively cover
the possible actions of the user (including inappropriate ones if the software won’t prevent them),
while the notes describe the alternative paths through the scenario.
• Not all alternative paths (or exceptions) have been mentioned above; there is some scope for you
to get (a little bit!) creative about possible errors, alternative paths, non-functional requirements
and so on.
• You do not need to mention any user interfaces in this task, even though the template has space
to describe the graphical user interface (GUI); the concern is with functionality, not
implementation.
3 Scenarios and Paper Prototypes
Task: If you haven’t already, read the requirements document and RTM for the Researcher
Assessment Program (RAP).
Note that there are only seven use cases, each of which will eventually have its own structured
scenario. Each use case has a number of software constraints that apply to it, some of which define
additional ways the user can interact with the system.
Task: Complete a structured scenario for the first of the use cases in the RAP’s RTM.
As you imagine the user’s actions in this scenario, what graphical user interface (GUI) elements are
they interacting with? Draw (on paper, or in paint.net, or in Word, or in PowerPoint) a simple sketch
of the GUI. Consider if the GUI you are sketching would be easy or pleasant to use. Give names to the
various GUIs you just sketched. It is common to refer to each GUI as a view, and you will probably find
it helpful to give each a name that includes that, such as ‘List View’ (hint: that name is too generic).
Once you are happy that you have a good, if rough, draft of the scenario and its associated UI views,
pick another use case and repeat the process. The second use case follows on well from the first.
4 Further work
If you have more time, start on structured scenarios for the other use cases. It doesn’t matter if you
don’t have answers for every part of the template yet. Fill in as much as you can and add to it later.
Outline
1 Agile User Stories (~30 minutes)
2 Your First Structured Scenario (~30 minutes)
3 Scenarios and Paper Prototypes
4 Further work