Software Engineering
Prototyping:
For Requirements Elicitation, Validation, and other Risk Reduction
Same meaning as in other branches of engineering:
A very limited version of the system, or of a small part of the system. Usually implemented quickly using familiar tools.
o Stakeholders may not be able to visualize the product just from reading the Vision document. Give them something to see, try and validate.
o For Requirements Elicitation: use it to visualize part of the system you are unsure about to get feedback from stakeholders
o As always in modern software engineering, a goal is to allow the stakeholders to see and comment on something early. Here very early.
Prototyping – What is it?
COMP3297: Software Engineering 2
Prototyping – Why?
Use it to minimize the risk of misunderstanding the problem.
Building prototypes can help:
to clear up any misunderstanding between users and developers
as early as possible. Use it to confirm things you think you know. when parts of the requirements are still not clear after using other
elicitation techniques like interviews – this is quite common. Use it to clarify things you think you don’t know.
when users don’t know or can’t describe what they want. The infamous “I’ll know it when I see it” – IKIWISI
COMP3297: Software Engineering 3
Building prototypes can help:
to reduce the risk of making the wrong decision. For example, when there are several ways to deliver the required behaviour and you are not sure which will be most effective
to check and demonstrate feasibility and market potential:
– reduce the risk of failure. – attract venture capital.
COMP3297: Software Engineering 4
What happens to the prototype
Fate Scope
Throwaway
Evolutionary
Horizontal
?
Generally represents a single architectural layer
Vertical
?
A slice through all layers
What part of the system does it cover
Kinds of prototypes
COMP3297: Software Engineering 5
Why those names?
Because of a very influential, traditional logical architectural pattern:
Vertical
Layered architecture. Here for .NET
Presentation Business Persistence Database
COMP3297: Software Engineering
Horizontal 6
Scope of prototype Horizontal prototypes
mostly just the UI
almost no functionality really implemented – it is faked all reports, charts, results, etc. are hard-coded
Objective: clarify workflow, confirm required functionality and general structure of the interface
Vertical prototypes
thin slice of functionality, implemented end-to-end
touches all layers from UI to infrastructure services/data access
Objective: confirm we can build it. Confirm can satisfy non-functional requirements
Ultimately, both are risk-reduction techniques
COMP3297: Software Engineering 7
Fate of prototype Throwaway prototypes
Evolutionary prototypes
Must be decided ahead of constructing the prototype COMP3297: Software Engineering 8
quick, cheap and dirty
no effort put into quality of construction
most common for horizontal prototyping
will NOT become part of the final product
don’t add more to it than you absolutely need to resolve issues
decide before starting that it will be a throwaway REALLY discard it or consider it unreleasable
an increment or part of the final product apply production-level standards of quality
Wireframes, Mockups and Interactive UI Prototypes
Wireframe (“Lo-Fi UI prototype”):
Rough, static sketches – graphical representation of the UI. Clearly throwaway.
COMP3297: Software Engineering 9
Wireframes
, Mockups and Interactive UI Prototypes
Wireframe (“Lo-Fi UI prototype”):
Shows main features of layout and content. Placeholders for images and other detail.
Great for initial communication and to refine understanding of requirements, but may need to explain to users what is being represented.
For clarifying requirements, avoid adding design elements such as fonts, colours, graphics, etc. – they distract stakeholders who will then want to discuss those design choices rather than their core requirements.
Shows a snapshot of the UI. But need to know how the snapshots work together as a user interacts with a page.
This is storyboarding, simulating the navigation through a UI. Or wireflow, for a wire frame.
COMP3297: Software Engineering 10
Wireframe example
1: enter search
text
2: click
First frames of storyboarding
COMP3297: Software Engineering
11
Wireflow
COMP3297: Software Engineering
12
https://wireflow.co
Wireframes, Mockups and Interactive UI Prototypes
Mockup (“Hi-Fi UI prototype”):
Like the wireframe, also a static visualization.
Used later in UI design. Shows details of the current ideas for the final product, complete with actual fonts, colours, etc.
Now want stakeholder feedback and buy-in about those choices.
Agile projects do not often produce throwaway Mockups. They are evolutionary.
COMP3297: Software Engineering 13
Mockup
1: enter search
text
2: click
COMP3297: Software Engineering 14
Wireframes, Mockups and Interactive UI Prototypes
Interactive Prototype:
Can be in Wireframe or Mockup form, but they are dynamic (clickable). Clickable mockups allow users to fully experience the product’s look and feel.
Now aspects of user interaction can be tested directly.
Good for usability testing and, depending on how constructed, maybe as the foundation for the final product interface.
COMP3297: Software Engineering 15
Many applications available that make it easy to create clickable wireframes. Balsamiq is a good example: https://balsamiq.com/wireframes/
COMP3297: Software Engineering 16
Example of an online tool. Pidoco: https://pidoco.com/en
COMP3297: Software Engineering 17
Don’t need a dedicated tool for simple wireframing. Most drawing tools provide the basics.
COMP3297: Software Engineering 18
Summary
Fate Scope
Throwaway
“Spikes”
Evolutionary
Horizontal
– Clarify/refine requirements
– Explore forms of UI
– Can link from relevant user story and write less
– High-quality presentation layer
Vertical
“Technical Spikes”
– Research
– Demonstrate feasibility
“Tracer Bullets”
– Incremental development
– Test, tune and demonstrate performance
COMP3297: Software Engineering 19
Prototyping tips
Iterate!
Whatever technique you use, it must support easy rework.
That is the whole point.
Paper prototypes or sketches on a tablet are very useful.
Very cheap, very fast, easily changed – sometimes get more useful critique from users because of that.
Watch your users (experienced and inexperienced) actually work with the prototype. And don’t instruct.
Lightweight usability testing.
Ask specific questions, not just “how do you like it?”
COMP3297: Software Engineering 20
Prototyping tips
Don’t spend time making your throwaway prototypes very detailed and realistic.
But if you show data, do use sensible data.
Make sure stakeholders understand the purpose of the prototype – particularly that a throwaway prototype is not production software.
Don’t prototype what you really know already just because you can.
That is missing the whole point.
COMP3297: Software Engineering 21