School of Electronic Engineering and Computer Science EBU6304: Live Session

EBU6304 Software Engineering

Live Session
Week 3a

1
School of Electronic Engineering and Computer Science EBU6304: Live Session

Live Session
• Revision of key knowledge in week 2
• Exercises
• Product backlog
• Prioritisation of stories
• Estimating
• Prototyping

2
School of Electronic Engineering and Computer Science EBU6304: Live Session

Key Knowledge

3
School of Electronic Engineering and Computer Science EBU6304: Live Session

Key Knowledge
• Be able to identify stakeholders
• Understand functional and non-functional
requirements
• Use appropriate techniques to capture
requirements
• Be able to write user stories
• Be able to break epics to detailed stories

4
School of Electronic Engineering and Computer Science EBU6304: Live Session

Identify stakeholders
• Stakeholders view the system differently
– perspective
– priorities

• Requirements will continue to change

throughout the project!

5
 School of Electronic Engineering and Computer Science EBU6304: Live Session

Functional and non-functional requirements

• Functional requirements
• Services
• Should be complete/precise

• Non-functional requirements
• Constraints
• Sometimes more critical
• Should be verifiable

6
School of Electronic Engineering and Computer Science EBU6304: Live Session

Requirements capture
• Fact-finding techniques
– Background reading
– Interviewing
– Observation
– Document sampling
– Questionnaires

7
School of Electronic Engineering and Computer Science EBU6304: Live Session

User stories
As a <type of user>,
I want <some goal>,
so that <some reason>.

All agile user stories include a written sentence or

two and, more importantly, a series of conversations
about the desired functionality.

8
School of Electronic Engineering and Computer Science EBU6304: Live Session

Break epics to detailed stories

• Large user stories are generally known as epics.
• Split into multiple smaller user stories before it is
worked on.
– How small is enough?
– You should be able to start writing code from a story.

9
School of Electronic Engineering and Computer Science EBU6304: Live Session

Exercises
There is no notes in this part. It is important that you
attend the live session and take notes yourself.

10
School of Electronic Engineering and Computer Science EBU6304: Live Session

Requirements in Agile Development

• More topics
• Product backlog
• Prioritisation of stories
• Estimating
• Prototyping

11
School of Electronic Engineering and Computer Science EBU6304: Live Session

Product backlog
• Product backlog, which is a prioritised list of the
functionality to be developed in a product or service.
• User stories have emerged as the best and most popular
form of product backlog items.
• Important: the written part of an agile user story (“As a
…, I want …”) is incomplete until the discussions about
that story occur.
• It’s often best to think of the written part as a pointer to
the real requirement.

12
 School of Electronic Engineering and Computer Science EBU6304: Live Session

Product backlog (excel template)

A spreadsheet is a simple good tool for writing and managing
produce backlog. Other comprehensive tools are available, for
example: Kanban, Trello, Jira, Axosoft…

Story Iteration
ID Story Name Description Priority number Acceptance Criteria Notes Date started Date finished

The template is available to download from QMPLUS

13
School of Electronic Engineering and Computer Science EBU6304: Live Session

Prioritisation of stories
• Product backlog
user stories must
be prioritised.
– Based on
business value
– Value must also
be supported by a
positive return on
investment (ROI)
– Consideration of
the risks

14
School of Electronic Engineering and Computer Science EBU6304: Live Session

MoSCoW
• A method of prioritisation favoured by the DSDM
(dynamic systems development method). Elements are:
– Must have: features must be implemented, and if not, the
system would not work.
– Should have: features are important but can be omitted if
time or resources constraints appear.
– Could have: features enhance the system with greater
functionality, but the timelines of their delivery is not
critical.
– Want to have: features serve only a limited group of users
and do not drive the same amount of business value as
the preceding items.

15
School of Electronic Engineering and Computer Science EBU6304: Live Session

MoSCoW example
• Payment processing story:
– Must have: ability to accept Visa and MasterCard.
– Should have: add American Express.
– Could have: add PayPal.
– Want to have: add gift cards.

16
School of Electronic Engineering and Computer Science EBU6304: Live Session

Estimating
• Estimates: how long the work is likely to take
• Some methods include:
– Level of Effort or T-shirt sizing: small, medium, large,
extra large…
– Ideal Time: under ideal circumstance
– Hours: actual clock hours
– Story points: an arbitrary measure that allows the teams
to understand the size of the effort

17
School of Electronic Engineering and Computer Science EBU6304: Live Session

Estimating story points

• Story points:
– Fibonacci Sequence:
1,2,3,5,8,13,21…
– As the points get higher, the
degree of uncertainty is
increasing.
– Abstract and negotiable
– Everyone on the team agrees
to the size of a story point,
using relative sizing
• E.g. adding a field to the
database, agreed as a 5
story points
18
School of Electronic Engineering and Computer Science EBU6304: Live Session

Good user story?

• INVEST
– Independent
– Negotiable
– Valuable
– Estimatable
– Small
– Testable

19
School of Electronic Engineering and Computer Science EBU6304: Live Session

Prototyping
• Physical user-interface design
– Draw the user interfaces on a paper
• Get quick feedback
• Logical user-interface design (information)
– Which user-interface elements are needed?
– How are these elements related to each other?
– What should they look like?
– How should they be manipulated?

20
School of Electronic Engineering and Computer Science EBU6304: Live Session

Low-fidelity Prototyping
• Paper and sketch
Quick
• No technical learning curve
• Relevant feedback on early concepts
• Provides conceptual direction
Effective
• Low investment of time/resources
• Fail early, fail fast
• Expedites detailed design

http://www.nngroup.com/

http://cosent.nl/en/blog/agile-design-paper-prototyping 21
 School of Electronic Engineering and Computer Science EBU6304: Live Session

Medium-fidelity Prototyping
• Limited functionality but clickable areas which presents the
interactions and navigation of an application.
• Usually built upon storyboards or user scenarios.
• Tools:
– Fliplet.com
– Proto.io
– Adobe XD
– And many more

22
School of Electronic Engineering and Computer Science EBU6304: Live Session

High-fidelity Prototyping
• Computer-based interactive representation of the
product in its closest resemblance to the final design in
terms of details and functionality.
• Consider user interface (UI) and the user experience
(UX).

23
School of Electronic Engineering and Computer Science EBU6304: Live Session

Examples
Low Medium High

Source: https://www.mockplus.com/blog/post/high-fidelity-and-low-fidelity

24