SOFT 423: Software Requirements Week 5 Class 1 Personas and Interactive Systems SOFT 423 Winter 2015 1
Feedback Survey Don t forget to please fill out the survey! I would appreciate if you could fill it out by Tomorrow. https://www.surveymonkey.com/s/r8d5n MV SOFT 423 Winter 2015 2
Last Class Problem Domain Oriented Analysis (PDOA) SOFT 423 Winter 2015 3
This Class Personas Interactive Systems SOFT 423 Winter 2015 4
Personas SOFT 423 Winter 2015 5
Personas Specification Technique Often used with Web Design The Inmates are Running the Asylum Alan Cooper, 1998 SOFT 423 Winter 2015 6
Personas A way to personalize user requirements information for designers fictitious stand ins for real user categories removes obvious abstraction does not help with other stakeholders identify user motivations, expectations and goals. SOFT 423 Winter 2015 7
Persona Benefits Enable the design team to stand in the user s shoes focus on users goals, rather than being driven by the formal requirements Relatively quick to develop and replace the need to canvas the whole user community Help avoid trap of building what users ask rather than what they actually use SOFT 423 Winter 2015 8
Simple Layout Name photo prose summary of persona multiple paragraphs this layout tends not to be as useful as the information tends to be disorganized SOFT 423 Winter 2015 9
Simple Layout Eric Eric is both a student and an instructor at Queen s University. With a specialization in Software Engineering, specifically modelbased testing, he works closely with General Motors. Outside of research and academia, Eric is actively involved in the student governance of Queen s University. SOFT 423 Winter 2015 10
Simple Layout 2 Name photo prose introduction to personalize Category 1 Description 1 Category 2 Description 2 SOFT 423 Winter 2015 11
Simple Layout 2 Eric Eric is both a student and an instructor at Queen s University performing research. Position Research Industrial Partner Field Hobbies Grad Student/Adjunct Lecturer Model-Based Testing General Motors Software Engineering Student Government SOFT 423 Winter 2015 12
Full Layout Name narrative prose describing user multiple paras photo Point-form summary: background attributes General needs Scenario Needs Feature Behaviour sc1 n1.1 f1.1 b1.1 n1.2 f1.2 b1.2 sc2 n2.1 f2.1 b2.1 n2.2 f2.2 b2.2 sc3 n3.1 f3.1 b3.1 n3.2 f3.2 b3.2 SOFT 423 Winter 2015 13
Personas No one set layout! DIY User Personas http://www.ux-lady.com/diy-userpersonas/ Excellent resource! SOFT 423 Winter 2015 14
Roadblocks to Acceptance Personas!= Market Segments Market segments are useful for identifying groups of people, but do not provide insight into how the software needs to work. Personas do. SOFT 423 Winter 2015 15
Roadblocks to Acceptance Personas are not serious enough make some developers uncomfortable, and the storytelling nature does not fit in with some organizational cultures. can be helped with simple layout 2 or any other full layout with categories and organizational structure SOFT 423 Winter 2015 16
Roadblocks to Acceptance Small set of personas = user population? traditional requirements involves researching as many users as possible with the resources personas allow you to create the typical users primary and secondary personas allow your to prioritize user requirements SOFT 423 Winter 2015 17
Some Guidelines Look for patterns in attitudes and behaviours of users in travel: users who are price driven users who travel frequently users who research vs word of mouth SOFT 423 Winter 2015 18
Some Guidelines give each cluster a title add details around the traits work environment, frustrations, relationships with others, skill level, demographics Give the persona a name and a photo Keep the persona to one page can be referred to quickly SOFT 423 Winter 2015 19
Some Guidelines add personal details, but don t go overboard design tool first and foremost include goals experience goals older person -> not look stupid end goal investor -> remain informed about the market SOFT 423 Winter 2015 20
Some Guidelines Other details work environment (tools used) computer proficiency pet peeves SOFT 423 Winter 2015 21
Negative Personas Negative personas are non-users People who will not be using the software and we are not designing for allows you to exclude functionality that is not needed SOFT 423 Winter 2015 22
Using Personas Identify the features and functionality Determine if one user interface will meet the goals of all users, or if there needs to be more than one interface SOFT 423 Winter 2015 23
Using Personas make design decisions about how functionality will work focus other user activities such as task analysis develop scenarios for usability testing SOFT 423 Winter 2015 24
Other Issues Marketing and sales targets may not be design targets in-flight entertainment system frequent business traveller retired teacher visiting grand children SOFT 423 Winter 2015 25
Other Issues Keep persona set small how many characters in a movie or book? Use the right goals goals and tasks are different each persona = 3-4 goals SOFT 423 Winter 2015 26
Persona Summary Personas represent behaviour patterns, not job descriptions not a list of tasks and duties describes the flow of someone's day, as well as skills, attitudes, environment, and goals SOFT 423 Winter 2015 27
Persona Summary Answers critical questions such as: What pieces of information are required at which points in the task? Do users focus on one thing at a time? Why are they using this in the first place? SOFT 423 Winter 2015 28
References www.steptwo.com.au/papers/kmc_pers onas/ http://www.cooper.com/journal/person as http://www.ux-lady.com/diy-user-personas/ SOFT 423 Winter 2015 29
Interactive Systems SOFT 423 Winter 2015 30
Interactive Systems class of systems that involve a significant degree of user interaction keyboard voice video touch screens mouse control stick instruments SOFT 423 Winter 2015 31
Interactive Systems Issues User Interface keyboard, voice, video, touch screens, mouse User Classes more than one class of users more complicated than beginner and advanced system managers, pilots, ground maintenance SOFT 423 Winter 2015 32
Interactive Systems Issues Other Systems interactive systems interface with other systems in the environment Indirect system concerns issues other than user interaction Quality of Service reliability, performance SOFT 423 Winter 2015 33
Viewpoint Oriented Requirements Definition Known as VORD introduced in the UK primarily developed for interactive systems focusses on external entities that interact with the system SOFT 423 Winter 2015 34
VORD service oriented model system delivers services to viewpoints viewpoints pass control information to the system Viewpoints map to classes of end-users or to other systems that must interface with it similar to terminators in structured analysis SOFT 423 Winter 2015 35
Example Viewpoints Consider a system for a train which will automatically halt the train when it goes through a danger signal SOFT 423 Winter 2015 36
Example Viewpoints Some examples of viewpoints for this system and the requirements they encapsulate might be: Driver Trackside Equipment Requirements from trackside equipment which must interface with the system Safety Engineer Safety requirements Existing on-board systems Compatibility requirements Braking characteristics Requirements which are derived from the braking characteristics of a train. SOFT 423 Winter 2015 37
VORD Viewpoint is an entity outside the system requirements source (i.e. generates a requirement) system user other system organizational concern Viewpoints organized hierarchically used to handle variations in user requirements SOFT 423 Winter 2015 38
VORD Viewpoints Top level hierarchy is two classes Direct Viewpoints Indirect Viewpoints SOFT 423 Winter 2015 39
VORD Viewpoints Direct Viewpoints interact directly with the system users/operators/other systems Indirect Viewpoints generate requirements do not interact with the system development/testing/organizational/ regulatory SOFT 423 Winter 2015 40
VORD Three main iterative steps 1. Viewpoint Identification and Structuring 2. Viewpoint Documentation 3. Viewpoint requirements analysis, specification and validation SOFT 423 Winter 2015 41
Viewpoint Template Identifier Number Name or Label Description of the role in the problem domain Viewpoint type (inheritance hierarchy) Attributes of the viewpoint in the application domain control information supplied by viewpoint Viewpoint requirements services, control and non functional requirements Event scenarios interaction between system and viewpoint Subclasses/specialization History interaction between system and viewpoint SOFT 423 Winter 2015 42
Viewpoint Template Identifier Label Description Type Attributes Requirements Event Scenarios Subclasses History * Identifier Label Description Definition Identifier Statement Rational Type Source Priority Specification Version Identifier Service Description Scenario SOFT 423 Winter 2015 43
Viewpoint Notation Simple Graphical Notation rectangular box for the viewpoint identifier (number) in top left viewpoint label in bottom half type in top half attributes below with line on left subclasses shown from left to right the notation is augmented with viewpoint information templates SOFT 423 Winter 2015 44
Viewpoint Template Subclasses n.1 Type n Type Label [m attribute] Label n.2 Type Label SOFT 423 Winter 2015 45
Viewpoint Template Subclasses 1.1 Direct 1 Direct User Casual 1.2 Direct [1 attribute] Super SOFT 423 Winter 2015 46
Identifying Viewpoints System authorities people or documents providing information on the application domain stakeholders + documentation of existing systems VORD has a starting set of abstract viewpoints labels only no attributes, requirements, etc. organizational only SOFT 423 Winter 2015 47
Abstract Viewpoints Direct System Operator Viewpoint Engineering Regulatory Maintenance Standards Indirect Organization Environment SOFT 423 Winter 2015 48
Any questions? Just email me at eric@cs.queensu.ca SOFT 423 Winter 2015 49
A Few Notes on Assignment 1 I responded to all questions that came in. There are still a lot of people getting very technical at this stage! DON T we are simply eliciting requirements, no need to worry about design We want the WHAT not the HOW SOFT 423 Winter 2015 50
A Few Notes on Assignment 1 Reminder: I have given different answers to the same questions to different groups your interview is your own! SOFT 423 Winter 2015 51
A Few Notes on Assignment 1 Reminder: due at the beginning of class on Thursday 4:30pm In person to me at the beginning of class, or by email Late submissions we be penalized, as outlined when the assignment was introduced SOFT 423 Winter 2015 52
Next Class Writing Requirements (finally!) SOFT 423 Winter 2015 53