SOFT 423: Software Requirements

Transcription

1 SOFT 423: Software Requirements Week 5 Class 1 Personas and Interactive Systems SOFT 423 Winter

2 Feedback Survey Don t forget to please fill out the survey! I would appreciate if you could fill it out by Tomorrow. MV SOFT 423 Winter

3 Last Class Problem Domain Oriented Analysis (PDOA) SOFT 423 Winter

4 This Class Personas Interactive Systems SOFT 423 Winter

5 Personas SOFT 423 Winter

6 Personas Specification Technique Often used with Web Design The Inmates are Running the Asylum Alan Cooper, 1998 SOFT 423 Winter

7 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

8 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

9 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

10 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

11 Simple Layout 2 Name photo prose introduction to personalize Category 1 Description 1 Category 2 Description 2 SOFT 423 Winter

12 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

13 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

14 Personas No one set layout! DIY User Personas Excellent resource! SOFT 423 Winter

15 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

16 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

17 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

18 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

19 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

20 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

21 Some Guidelines Other details work environment (tools used) computer proficiency pet peeves SOFT 423 Winter

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 References onas/ as SOFT 423 Winter

30 Interactive Systems SOFT 423 Winter

31 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

32 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

33 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

34 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

35 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

36 Example Viewpoints Consider a system for a train which will automatically halt the train when it goes through a danger signal SOFT 423 Winter

37 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

38 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

39 VORD Viewpoints Top level hierarchy is two classes Direct Viewpoints Indirect Viewpoints SOFT 423 Winter

40 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

41 VORD Three main iterative steps 1. Viewpoint Identification and Structuring 2. Viewpoint Documentation 3. Viewpoint requirements analysis, specification and validation SOFT 423 Winter

42 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

43 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

44 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

45 Viewpoint Template Subclasses n.1 Type n Type Label [m attribute] Label n.2 Type Label SOFT 423 Winter

46 Viewpoint Template Subclasses 1.1 Direct 1 Direct User Casual 1.2 Direct [1 attribute] Super SOFT 423 Winter

47 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

48 Abstract Viewpoints Direct System Operator Viewpoint Engineering Regulatory Maintenance Standards Indirect Organization Environment SOFT 423 Winter

49 Any questions? Just me at SOFT 423 Winter

50 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

51 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

52 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 Late submissions we be penalized, as outlined when the assignment was introduced SOFT 423 Winter

53 Next Class Writing Requirements (finally!) SOFT 423 Winter