Presentation delivered on 28th November at Sri Lanka Developer Forum MeetUp, Colombo, Sri Lanka by Tharshan Sreetharan

1. Software Product Engineering
TharshanSreetharan, PMP®,CBAP®,CSP®,CSM®,CSPO®,ITIL®,CPRE®,MITP, MBA(Aus),BScSoftwareEngineering&IT.
28th November 2018
Sri Lanka Developer Forum – November Meetup

2. Common Challenge’s faced by Developers
• Poorly Defined & Ambiguous Requirements – I Just don’t get it or it doesn’t meant the same for everyone in
the team
• Client says every feature and every requirement is of high priority and is in scope
• Get it ALL done quickly and ship the potential product out – Schedule/ Cost?
• Does your PM/BA effectively present requirements so you can develop the right solution?
• I just sit and code whole day and only my Tech Lead or Architect knows the big picture? Do They at least? ☺
• What Else?
2

3. Disruptive Innovation
“An innovation that creates a new market by providing a different set of values,
which ultimately (and unexpectedly) overtakes an existing market.” 3

4. Digital Disruption
4

5. Minimum Viable Product?
• A Minimum Viable Product (MVP) is a product with just enough features to satisfy early customers,
and to provide feedback for future product development.
• The allure of a good plan, a solid strategy & thorough market research for an established company mapped to
a Startup.
• Doing without thinking about the processes lead to execution problems within the team.
• Lack of focus & execution.
“The goal of customer discovery is to test your understanding of the customer’s problem & see if your solution will prompt
him to use/buy the product based on the important features alone”. 5

6. Product Vision & Eliciting Requirements
• Consists of work required to
• Plan, prepare & conduct elicitation of information from stakeholders
• Analyze & document the results of the elicitation activities
• Define requirements to enable definition / selection of preferred solution
• Elicitation → Bring forth / draw out information (actual needs and wants) from stakeholders & other sources to solve a problem,
take advantage of an opportunity or ultimately to build a solution
• Elicitation is more than collecting or gathering requirements - Requirements are not “ready made” but the real requirements needs to be
carefully drawn out
• Collecting / Gathering Requirements → Implies stakeholders already have requirements ready to be collected
6

7. Importance of Eliciting Information
• Elicitation is the core input for requirements management work & is essential to effectively:
• Support executive strategic decision making
• Apply influence successfully (influence to get things done backed with information)
• Assist in negotiation or mediation
• Resolve conflict
• Define real problems
• Failing to elicit enough information may result in increase of assumptions, erroneous conclusions
• Too much information may hinder team's ability to move forward
• Elicit enough information which will enable project progress
7

8. Prototyping / Prototypes
• Used to obtain early feedback on requirements by providing a 'tangible, working
model' of the expected product
• Supports progressive elaboration through mockup creation, user experimentation,
feedback generation & prototype revision
• Prototyping (visual representation) allows elicitation, clarification of additional or
uncovered requirements which may have been omitted originally
• Dimensions of Prototypes
• Vertical
• Enhanced complete elaboration of single subsystem or function
• Useful for getting detailed requirements for given function
• Horizontal
• Broad view of entire system or subsystem.
• Focus of user interaction
• Two types of Prototypes
• Low-Fidelity
• High-Fidelity 8
Create
Review
Make
Adjustments
Review again
© LearntIn (Pvt.) Ltd., 2018

9. Types of Prototypes
Low-Fidelity Prototypes
• Completed with pen & paper, marker & whiteboard or modeling
tool on the computer
• e.g. Wireframes, Mockups of interface screens / reports,
Architectural renderings of a building, Floor plans, Sketches of a new
product, Any design that is evolving
• Typical use: Mock-up user interfaces, share them with intended
users to provide a visual representation of how the solution will look
like & how it will function
9
High-Fidelity Prototypes
• Creates a representation of the final finished product
• Typically has limited data, is restricted to a single computer device,
has partial functionality
• Performed in an iterative fashion
• Two types: Throwaway & Evolutionary
• Throwaway → Discarded once interface has been confirmed
• Evolutionary →Actual finished product in process. First
prototype reviewed is the earliest workable version of the
final product. More functionality gets added at successive
prototyping sessions. Agile projects are considered
evolutionary since features get added with each iteration.

10. Prototyping Techniques
• Storyboards
• Shows sequence or navigation through a series of images or
illustrations
• In Software Development, mock-ups show navigation paths
through webpages, screens or other user interfaces
• A graphical representation of the sequence of events
• Storyboards typically are static & throw away
• Storyboards focus on the User Experience (UX), Prototypes focus
on what the product would look & feel like
10
• Wireframes
• A diagram representing a static blueprint or schematic of a user
interface
• Used to identify basic functionality (not the look & feel)
• Provides a stripped-down, simplified version of the page
• Identifies all entry, exit, action points & illustrates logical / business
flows or functions
• Wireframes contain key page elements (header, footer, navigation,
content areas, labelling, page titles, placeholders for text & images
etc.)
• Drives communication helping in evolutionary discovery of
requirements

11. Story Boarding - Examples
11

12. Sample
Wireframes
12

13. Theme (or initiative)
“Build an web based airline booking system to book flights online"
Epic
As a customer, I want to search for flights and
see a list of available flights
User Story
As a customer I want to Geo IP
current location so that I can
save time entering origin
User Story
As a customer I want to enter
origin, destination, departing
and returning schedules so that
I can see list of flights
Epic
As a customer, I want to pay for my flights online
User Story
As a customer I want to pay for
my flights using my credit card
so that I do not have to visit a
bank
User Story
As a customer I want to choose
between card payments and
Pay Pal so that I have options to
pay
13

14. User Stories & 3 C’s
A User Story has 3 parts - The 3 C’s: Card,
Conversation, Confirmation
a
As a customer,
I want to search for and book a flight,
So that I can fly to London.
`
As a customer who has booked a flight,
I want to cancel my flight booking,
So that fly on another schedule
14

15. ▪ The card does not include all the details needed by the Dev Team
▪ We want to force a conversation between the Development
Team and the Product Owner.
▪ We want to make it impossible for work to begin on a User Story
without an in-depth conversation having taken place.
▪ The conversation begins at the start of the project
▪ The Scrum Team might spend a day going one-by-one through
the User Stories on the Product Backlog, discussing each and
asking questions.
▪ The conversation continues sprint by sprint
The 2nd C: Conversation
15

16. ▪ During the conversations, team identifies “confirmations” for each User Story
▪ Similar to high-level acceptance criteria
▪ The Development Team uses these as a guide to development, and for confirming the requirements have
been met
The 3rd C: Confirmation
As a customer who has
booked a flight,
I want to cancel my
flight booking,
So that fly on another
schedule
☐ Ticket price plus cancellation fee should be
refunded to the credit card
☐ 10% cancellation fee should be deducted
☐ No cancellation fee for business class
☐ Confirmation email should be sent
☐ Seat reservation should be released immediately
16

17. Prioritization Tools & Techniques – MoSCoW & HML
MoSCoW
• A prioritization technique used that can be used effectively in software development to reach a common understanding with
stakeholders on the importance they place on the delivery of each requirement
• Attempt to deliver the highest value items first
• Components
• Must haves → Fundamental to project success
• Should haves → Important, but the project success does not rely on them
• Could haves → Can easily be left out without impacting the project
• Won't haves → Not delivered this time around
17
High-Medium-Low (HML)
• A prioritization technique which is a variant to MoSCoW
• Categorize items based on importance classifying them as High, Medium and Low importance

18. Prioritization Tools & Techniques - Time Boxing
• Another prioritization technique
• Used when the project has a fixed timeline & the timeline is not negotiable
• Typically an ‘Agile Sprint’
• Prioritize requirements based on the amount of work the project team is capable of delivering during a prescribed time period
• e.g. If time-box is 90 days, the project team evaluates & determines the list of requirements that can be delivered within that 90 day
window.
• A variation → Prioritize based on the amount of money (budget) available & the number of features that can be delivered
within that time period
18