workshop gathering and managing product...

WorkshopGathering and Managing Product Requirements

TIE project course 2014-201516.9.2014

Thomas Olsson & Matti Vuori

What is this WS about?

• Understanding the scope and field of the project– Identifying stakeholders (e.g. competitors, authorities)– Understanding the users, their tasks, and the context of use– Identifying customer requirements and technical requirements

• Gathering requirements– From which stakeholders to ask what, why, and how?

• Creating a product vision based on the requirements– Forming a shared understanding of the product with the client– Transforming abstract requirements to concrete design– Using prototypes to refine the unclear requirements

• What is the role of a UX person in a project?

9/16/2014 2

Requirements throughout the SE Process

• Elicitation & identification– consider various sources of requirements

• Analysis and negotiation– resolving stakeholder conflicts– which are critical requirements, which “only wishes” – prioritizing

• Specification & design– turning requirements into design targets and eventually a system design

• Validation– checking that the documented requirements are consistent, clear, and

meet stakeholders’ (e.g. users’) needs

• Management– managing changes to the requirements as the system is developed and

put into use; work allocation; backlog

9/16/2014 3

Types and Sources of Requirements

9/16/2014 4

CustomerEnd users

TechnologyOther stakeholders

What thesystemmust do

What thesystem must be

Business goals

What is the need forthe system

Early product visionsvs. product update

Tasks

Characteristics &limitations

Context of use

What defines quality? Reliability,security, scalability…?

Platform reqs & constraints

Data requirements

What ispredefined and

can it bechanged?

Internals

Interfaces

Conventions, standards,legislation

Collaborationpracticalities

Data providers

Developercommunity

Competitors

MethodsGathering & Analysing requirements• Group discussions

– With users, with stakeholders

• Quick interviews & observation of users; surveys• Reviews of literature, standards, etc.• Rapid prototyping

– Card sorting, scenarios, mock-ups, paper prototypes, simulations, etc.

• Competitor analysis: heuristic analysis• Prioritizing: think of the criteria for doing that

Communicating the requirements• Personas; Scenarios & storyboards; models of sequences & interactions• Developers want details, managers want numbers, designers want

examples

9/16/2014 5

Focus, focus, focus!

collaboration, rather than inquiry

Unambiguous – Measurable – Feasible – Traceable

Group work

• Let’s form 3 groups with as many project teams representedas possible in each– Each group discusses one main theme of problems that

the groups sent in advance• Choose that which of the themes would you like to discussà discussion in groups, for ~45mins

• In the end, let’s go through your ideas, as well as those ofthe teachers’

9/16/2014 6

Next, a few slides to be recapped at home

16.9.2014 7

Interviewing techniques and hints

• Set a suitable atmosphere• Leading the interview:

– Get users to speak about their own experiences– … about concrete examples and stories– … in terms of problems, not solutions– Notice when users are censoring their own comments– Allow time for thinking as well as lengthy answers– Allow spontaneous comments before asking too detailed questions– Empathy and adaptability – easier said than done

• For each theme: What – How – Why? (+where, when, how often, who…)

• Laddering technique: why – why – why …• Most importantly, prepare yourself well!

9/16/2014 8

9

Example of analysis:Contextual design: Affinity Diagram

• Affinity diagram is a structure of individual notes that areinterpreted from the sessions with users– A hierarchical structure organizes notes by their type or meaning– Allows identifying problems, risks, users’ needs, usability issues in current

systems, users’ ”strategies” to do the work being studied

Affinity diagram reveals:• The main points to focus in redesign• User data that is related to each issue• Even some design ideas

At-FM 10: Kuva on sitä arvokkaampi mitäenemmän se muistuttaa sellaisista asioista,joita olen jo unohtanut

Example of analysisPersonas

Describing for example:• a fabricated name (pseudonym)• background: e.g. approx age,organization, personal characteristics,values, motivations• skills and competences• activities and tasks (e.g. roles,responsibilities, strategies, limitations)• tools and applications in use• relevant opinions, attitudes• central requirements or problems withcurrent systems• a mug shot can help communicating thepersona to other stakeholders

Descriptions of imaginary users:• Concretizing the users’ characteristics and needs• Combinations of several similar users• Is usually used together with scenarios about the new system or used in design as inspiration

Example of analysisStoryboards - A type of scenario

One frame describes one ’scene’ or a detail, e.g.:• User inputs or system outputs

– E.g. very rough UI sketches• Use of an artifact• Interactions between different roles• Context of use and target end users• A specific task with the system

Is usually done in pairs, and the evaluated in groups

Comic strip –like concretization of the vision (product concept)• illustrations + text

Describes how specific tasks are done with the new system• Helps to find a consensus and to communicate the concept

1/6

TIE-13011ProjectWorkonPervasiveSystems2014-2015Workshop on UX evaluation, 16.9.2014

Thomas Olsson & Matti Vuori

Questionsfromthegroups,grouped

Methods of requirements engineering:

- Are there certain processes or guidelines to find the requirements of a system, especially thenot so obvious ones? (G10)

- We were wondering that is there any mechanisms to transfer tacit knowledge torequirements? Are there certain questions, which may lead into better understanding whatthe customer wants? (G6)

- Jim Highsmith presents a model of agile project management triangle in his book "AgileProject Management". This triangle contains value, restrictions and functionality and theidea is to maximize value. In what kind of situations we should consider of using this modelover the traditional triangle model (timescale, functionality, cost)? (G3)

- Our project is a game, where customer has defined general theme for the game, it'splatform and it's genre, but customer doesn't yet have any guidelines or opinions onaesthetics, gameplay or other details. What are the most common pitfalls we should avoid,when major part of project is undefined or yet to be settled and how to we could avoidthese pitfalls? (G9)

- Why the research of UX is important? What kinds of knowledge should a UX expert know?And how to use these knowledge into a project? (G9)

Interaction /w the customer:

- What if the client doesn’t have enough time for properly specifying the requirements theyhave for the product? (G8)

- What if the client keeps coming up with new requirements and changes for the product atthe later stages of the project? (G8)

- Which one takes more responsibility of requirement specification, the customer or thedeveloper? (G2)

- How often is user observation used to identify use cases? Do companies accept someone tocome and observe their employees using a product? (G1)

- What sort of differences are to be expected between receiving requirements from a non-software-related customer and a customer who itself produces software? Are we to expectwell documented requirements without too much ambiguity? (G7)

2/6

What is good enough?

- Are interviews with a few people enough to get started figuring out the end user’srequirements for the product? (G8)

- What if project doesn’t have enough requirements? For example, if requirements are tooabstract and project team has too much to decide themselves. (G4)

- How much user tests or surveys are necessary before starting the implementation? And is itworth to do much usability tests with finished product? (in scope of this project or in worklife) (G2)

- Jim Highsmith presents a model of agile project management triangle in his book "AgileProject Management". This triangle contains value, restrictions and functionality and theidea is to maximize value. In what kind of situations we should consider of using this modelover the traditional triangle model (timescale, functionality, cost)? (G3)


UI design:

- How a large database table should be managed in a user interface? What are the mainmistakes and opportunities? (G5)

AnswerstotheQuestions

Methods of requirements engineering:

- Are there certain processes or guidelines to find the requirements of a system, especially thenot so obvious ones? (G10)

o laddering technique: why – why – whyo provoke the customer with unorthodox ideaso plenty of methods for understanding user-based requirements: interviews,

observation, diaries, etc.: qualitative methods rather than quantitativeo might also require first building a prototype to help people think of their needs

- We were wondering that is there any mechanisms to transfer tacit knowledge torequirements? Are there certain questions, which may lead into better understanding whatthe customer wants? (G6)

o create a positive and constructive atmosphere in the meetingo try to approach the problem from the viewpoint of the use contexto laddering technique in interviewing: why – why – why …

§ is the product vision based on internal gut feeling, studied user needs, orwhat

o observation often brings out conventions, problems and other things that peopleare not aware of

3/6

o co-design with the customer in early phase§ sketch a storyboard / user story and analyze how the product would help in

that§ sketch a minimum viable product : what are the most important

functions/features that still make the product what it is supposed to be§ not only sketch, but also try to use the prototype

o stakeholder analysis: what different stakeholders of the company would want fromthe product

- Jim Highsmith represents a model of agile project management triangle in his book "AgileProject Management". This triangle contains value, restrictions and functionality and theidea is to maximize value. In what kind of situations we should consider of using this modelover the traditional triangle model (timescale, functionality, cost)? (G3)

o agile triangle might be more suitable in small-scale projects while the traditionalcould work better in big projects where the project management is more important(stiff organization)

o Basically, the newer model is more comprehensiveo especially in this project work the schedule and costs are predetermined, which

does only leaves the ‘functionality’ from the traditional triangleo utilizing the triangle as a tool in negotiations

- Our project is a game, where the customer has defined a general theme for the game, it'splatform and it's genre, but customer doesn't yet have any guidelines or opinions onaesthetics, gameplay or other details. What are the most common pitfalls we should avoid,when major part of project is undefined or yet to be settled and how to we could avoidthese pitfalls? (G9)

o avoid redundant and useless worko prototypingà testingà feedbackà more detailed requirementso What are the reasons for choosing this specific genre or the platform, and are they

actually reasonable? Or should you instead design for a specific target user group?o sounds like lots of brainstorming and competitor analysisà aim for novelty and

breaking the conventional when designing the concept§ also the potential gamers could be involved in group brainstorming§ don’t forget to stimulate your thinking with idea creation tools (PLEX cards,

VNA cards, etc.)o continuous validation (with the customer) of the game concept that you createo choose an architecture and development environment that allow changing the

aesthetics & UI solutions without having to touch the game engine


o distinguishing the product from others; UX is an advantage in product quality, anasset

o consider the users’ targetso helps avoiding the risk of not doing the right thing (validation), helps scoping the

product and defining a suitable workflow & information architecture, helps makingthe product high quality (esp. usable)

4/6

o either think about the UX activities collectively throughout the project or, mostoften preferred, assign someone the role of “UX bitch”§ Hopefully the chosen UX specialist has taken at least a few courses after the

introduction course§ or heavy interest in psychology and other social sciences & user interfaces

Interaction /w the customer:

- What if the client doesn’t have enough time for properly specifying the requirements theyhave for the product? (G8)

o pressure: “if you don’t tell us what you need, there’s no hope!!!”o provide suggestions (prototypes), options to choose fromo observation of end users: workflows, practices, etc.o motivate them: pay the most effort in the beginning to make the product as valid

and well-targeted as possible (e.g. navigation analogue)

§ ”we know how to make software, you know your business. Together we’llcreate diamonds, separately just crap” (anonymous specialist in a softwarehouse)

o it might be easier for them to comment on an early prototype instead of abstractlythinking in advance

o think about other sources of information how to scope the product (end users,competitor analysis)

o trust your own design intuition if there’s gaps in the requirements

- What if the client keeps coming up with new requirements and changes for the product atthe later stages of the project? (G8)

o agile with short sprints allows adding features also in the later phaseso discuss & prioritize; explain the realities (timeline, available resources, expected

work load of the new feature)o you may also ask for help from the course personnelo that’s very likely and that’s one of the reasons to do agileo Prioritize and negotiate, don’t just promise to do everything (e.g. project triangle)o agree with the customer a deadline for freezing the reqs

- Which one takes more responsibility of requirement specification, the customer or thedeveloper? (G2)

o the developer team in the endo the developing team has to make sure they have enough information to start

designing and developingo it’s you who will be blamed in the end if the product is not as expectedo however, an experienced customer will also challenge you understand if they have

acted inappropriately during the process (e.g. changing the reqs, not guiding enoughin the beginning)

5/6

- How often is user observation used to identify use cases? Do companies accept someone tocome and observe their employees using a product? (G1)

o top-secret work cannot be observed

o needs explaining the purpose and benefits of the observation

o very often if the project is about creating a new product to replace old ones

§ but in case of a totally new project, observation is often waste of time

o as a customer, they should understand the benefit of doing that; if not, motivatethem

o as users, some people might be a bit skeptical but most people like the idea thatthey can affect the way they work and the tools they use

o also consider other options how to access the target user group

o a detailed inspection of the current products is a good basis to help understandingwhat the user does while you’re observing

- What sort of differences are to be expected between receiving requirements from a non-software-related customer and a customer who itself produces software? Are we to expectwell documented requirements without too much ambiguity? (G7)

o software companies probably are capable of specifying very detailed reqso amateur companies: probably lots of gaps and open-ended, unclear requirementso the concept of requirements is understood in many ways and they are documented

in various practicesà expect variety, some of them might be clear and detailed butmost probably not

o technology-perspective vs. customer/user perspective

What is good enough?

- Are interviews with a few people enough to get started figuring out the end user’srequirements for the product? (G8)

o yeso often, yes. Just make sure they actually represent the target users, both are well

prepared, and you leave space for unexpected veins of discussiono in some cases, observation together with interview is most useful (e.g. in routine-

like tasks where the user might not even be aware of all the routine-like steps).Discuss practical examples instead of abstractions!

- What if project doesn’t have enough requirements? For example, if requirements are tooabstract and project team has too much to decide themselves. (G4)

o prototyping iterativelyo try to understand the workflow of the userso go and make them more detailed with the customer/users/stakeholdersà demand

details and good examples

6/6

o design a prototype and, while doing so, document where you had to make bigger“leaps of faith” in the design decisionsà discuss the leaps with the customer

o but again, don’t underestimate your skills and insight in filling the holes – after all,you’re the expert of software in general. Mainly the domain-specific gaps should bevalidated with the customer as they probably know the domain better than you do

- How much user tests or surveys are necessary before starting the implementation? And is itworth to do much usability tests with finished product? (in scope of this project or in worklife) (G2)

o yes, it’s worth it – both in the course and in real lifeo how much: really depends on the case – the newer the product, the more you

probably need to validate the design plan with stakeholders. If you create “yetanother mobile game / web site” etc., you can often just trust your instinct and testonly in the later phases

o usability tests in the end: definitely yesà understand the needs for furtherdevelopment work, which is valuable information for the customer; and this is notonly about “polishing the UI” but also validating the overall product with the targetgroup

UI design:

- How a large database table should be managed in a user interface? What are the mainmistakes and opportunities? (G5)

o This is a bad, bad question. Please provide more details ;)

workshop gathering and managing product...

Documents