Engineering Software Products PDF
Document Details
2020
Ian Sommerville
Tags
Summary
This document is a textbook, Engineering Software Products by Ian Sommerville. It is the first edition from 2020, published by Pearson Education. The content covers topics like software product design, features, scenarios, user understanding and personas.
Full Transcript
Engineering Software Products First Edition Chapter 3 Features, Scenarios, and Stories Copyright © 2020, Pearson Education, In...
Engineering Software Products First Edition Chapter 3 Features, Scenarios, and Stories Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-1 Software products There are three factors that drive the design of software products – Business and consumer needs that are not met by current products – Dissatisfaction with existing business or consumer software products – Changes in technology that make completely new types of product possible In the early stage of product development, you are trying to understand, what product features would be useful to users, and what they like and dislike about the products that they use. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-2 Software features A feature is a fragment of functionality such as a ‘print’ feature, a ‘change background feature’, a ‘new document’ feature and so on. Before you start programming a product, you should aim to create a list of features to be included in your product. The feature list should be your starting point for product design and development. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-3 User understanding (1 of 2) It makes sense in any product development to spend time trying to understand the potential users and customers of your product. A range of techniques have been developed for understanding the ways that people work and use software. – These include user interviews, surveys, ethnography and task analysis. – Some of these techniques are expensive and unrealistic for small companies. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-4 User understanding (2 of 2) Informal user analysis and discussions, which simply involve asking users about their work, the software that they use, and its strengths and weaknesses are inexpensive and very valuable. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-5 Figure 3.1 From personas to features Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-6 Figure 3.2 Feature description Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-7 Figure 3.3 The New Group feature description Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-8 Personas (1 of 2) You need to have an understanding of your potential users to design features that they are likely to find useful and to design a user interface that is suited to them. Personas are ‘imagined users’ where you create a character portrait of a type of user that you think might use your product. – For example, if your product is aimed at managing appointments for dentists, you might create a dentist persona, a receptionist persona and a patient persona. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3-9 Personas (2 of 2) Personas of different types of user help you imagine what these users may want to do with your software and how it might be used. They help you envisage difficulties that they might have in understanding and using product features. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 10 Table 3.1 A persona for a primary school teacher Jack, a primary school teacher Jack, age 32, is a primary school (elementary school) teacher in Ullapool, a large coastal village in the Scottish Highlands. He teaches children from ages 9 to 12. He was born in a fishing community north of Ullapool, where his father runs a marine fuels supply business and his mother is a community nurse. He has a degree in English from Glasgow University and retrained as a teacher after several years working as a web content author for a large leisure group. Jack’s experience as a web developer means that he is confident in all aspects of digital technology. He passionately believes that the effective use of digital technologies, blended with face-to-face teaching, can enhance the learning experience for children. He is particularly interested in using the iLearn system for project-based teaching, where students work together across subject areas on a challenging topic. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 11 Persona descriptions A persona should ‘paint a picture’ of a type of product user. They should be relatively short and easy-to-read. You should describe their background and why they might want to use your product. You should also say something about their educational background and technical skills. These help you assess whether or not a software feature is likely to be useful, understandable and usable by typical product users. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 12 Figure 3.4 Persona descriptions Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 13 Table 3.2 Aspects of persona descriptions Aspect Description Personalization You should give them a name and say something about their personal circumstances. It is sometimes helpful to use an appropriate stock photograph to represent the person in the persona. Some studies suggest that this helps project teams use personas more effectively. Job-related If your product is targeted at business, you should say something about their job and (if necessary) what that job involves. For some jobs, such as a teacher where readers are likely to be familiar with the job, this may not be necessary. Education You should describe their educational background and their level of technical skills and experience. This is important, especially for interface design. Relevance If you can, you should say why they might be interested in using the product and what they might want to do with it. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 14 Table 3.3 A persona for a history teacher Emma, a history teacher Emma, age 41, is a history teacher in a secondary school (high school) in Edinburgh. She teaches students from ages 12 to 18. She was born in Cardiff in Wales, where both her father and her mother were teachers. After completing a degree in history from Newcastle University, she moved to Edinburgh to be with her partner and trained as a teacher. She has two children, aged 6 and 8, who both attend the local primary school. She likes to get home as early as she can to see her children, so often does lesson preparation, administration, and marking from home. Emma uses social media and the usual productivity applications to prepare her lessons, but is not particularly interested in digital technologies. She hates the virtual learning environment that is currently used in her school and avoids using it if she can. She believes that face-to-face teaching is most effective. She might use the iLearn system for administration and access to historical films and documents. However, she is not interested in a blended digital/face- to-face approach to teaching. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 15 Table 3.4 A persona for an IT technician Elena, a school IT technician Elena, age 28, is a senior IT technician in a large secondary school (high school) in Glasgow with over 2000 students. Originally from Poland, she has a diploma in electronics from Potsdam University. She moved to Scotland in 2011 after being unemployed for a year after graduation. She has a Scottish partner, no children, and hopes to develop her career in Scotland. She was originally appointed as a junior technician but was promoted, in 2014, to a senior post responsible for all the school computers. Although not involved directly in teaching, Elena is often called on to help in computer science classes. She is a competent Python programmer and is a “power user” of digital technologies. She has a long-term career goal of becoming a technical expert in digital learning technologies and being involved in their development. She wants to become an expert in the iLearn system and sees it as an experimental platform for supporting new uses for digital learning. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 16 Persona benefits (1 of 2) The main benefit of personas is that they help you and other development team members empathize with potential users of the software. Personas help because they are a tool that allows developers to ‘step into the user’s shoes’. – Instead of thinking about what you would do in a particular situation, you can imagine how a persona would behave and react. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 17 Persona benefits (2 of 2) Personas can help you check your ideas to make sure that you are not including product features that aren’t really needed. They help you to avoid making unwarranted assumptions, based on your own knowledge, and designing an over-complicated or irrelevant product. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 18 Deriving personas (1 of 2) Personas should be based on an understanding of the potential product users, their jobs, their background and their aspirations. You should study and survey potential users to understand what they want and how they might use the product. From this data, you can then abstract the essential information about the different types of product user and use this as a basis for creating personas. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 19 Deriving personas (2 of 2) Personas that are developed on the basis of limited user information are called proto-personas. – Proto-personas may be created as a collective team exercise using whatever information is available about potential product users. They can never be as accurate as personas developed from detailed user studies, but they are better than nothing. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 20 Scenarios A scenario is a narrative that describes how a user, or a group of users, might use your system. There is no need to include everything in a scenario – the scenario isn’t a system specification. It is simply a description of a situation where a user is using your product’s features to do something that they want to do. Scenario descriptions may vary in length from two to three paragraphs up to a page of text. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 21 Table 3.5 Jack’s scenario: using the iLearn system for class projects (1 of 2) Fishing in Ullapool Jack is a primary school teacher in Ullapool, teaching P6 pupils. He has decided that a class project should be focused around the fishing industry in the area, looking at the history, development, and economic impact of fishing. As part of this, students are asked to gather and share reminiscences from relatives, use newspaper archives, and collect old photographs related to fishing and fishing communities in the area. Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a history archive site) to access newspaper archives and photographs. However, Jack also needs a photo-sharing site as he wants students to take and comment on each others’ photos and to upload scans of old photographs that they may have in their families. He needs to be able to moderate posts with photos before they are shared, because pre-teen children can’t understand copyright and privacy issues. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 22 Table 3.5 Jack’s scenario: using the iLearn system for class projects (2 of 2) Fishing in Ullapool Jack sends an email to a primary school teachers’ group to see if anyone can recommend an appropriate system. Two teachers reply and both suggest that he use KidsTakePics, a photo-sharing site that allows teachers to check and moderate content. As KidsTakePicsis not integrated with the iLearn authentication service, he sets up a teacher and a class account with KidsTakePics. He uses the the iLearn setup service to add KidsTakePics to the services seen by the students in his class so that, when they log in, they can immediately use the system to upload photos from their phones and class computers. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 23 Figure 3.5 Elements of a scenario description Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 24 Scenario elements (1 of 2) A brief statement of the overall objective. – In Jack’s scenario, this is to support a class project on the fishing industry. References to the personas involved (Jack) so that you can get information about the capabilities and motivation of that user. Information about what is involved in doing the activity. For example, in Jack’s scenario this involves gathering reminiscences from relatives, accessing newspaper archives, etc. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 25 Scenario elements (2 of 2) An explanation of problems that can’t be readily addressed using the existing system. – Young children don’t understand issues such as copyright and privacy, so photo sharing requires a site that a teacher can moderate to make sure that published images are legal and acceptable. A description of one way that the identified problem might be addressed. – In Jack’s scenario, the preferred approach is to use an external tool designed for school students. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 26 Emma’s scenario Emma’s scenario is different from Jack’s scenario in that it describes a common and well-understood process rather than something new. Emma is an e-learning sceptic and she is not interested in innovative applications. She wants a system that will make her life easier and reduce the amount of routine administration that she has to do. The scenario discusses how parts of the process (setting up an email group and web page) are automated by the iLearn system. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 27 Table 3.6 Using the iLearn system for administration (1 of 3) Emma is teaching the history of World War I to a class of 14-year-olds (S3). A group of S3 students are visiting the historic World War I battlefields in northern France. She wants to set up a “battlefields group” where the students who are attending the trip can share their research about the places they are visiting as well as their pictures and thoughts about the visit. From home, she logs onto the iLearn system using her Google account credentials. Emma has two iLearn accounts—her teacher account and a parent account associated with the local primary school. The system recognizes that she is a multiple account owner and asks her to select the account to be used. She chooses the teacher account and the system generates her personal welcome screen. As well as her selected applications, this also shows management apps that help teachers create and manage student groups. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 28 Table 3.6 Using the iLearn system for administration (2 of 3) Emma selects the “group management” app, which recognizes her role and school from her identity information and creates a new group. The system prompts for the class year (S3) and subject (history) and automatically populates the new group with all S3 students who are studying history. She selects those students going on the trip and adds her teacher colleagues, Jamie and Claire, to the group. She names the group and confirms that it should be created. The app sets up an icon on her iLearn screen to represent the group, creates an email alias for the group, and asks Emma if she wishes to share the group. She shares access with everyone in the group, which means that they also see the icon on their screen. To avoid getting too many emails from students, she restricts sharing of the email alias to Jamie and Claire. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 29 Table 3.6 Using the iLearn system for administration (3 of 3) The group management app then asks Emma if she wishes to set up a group web page, wiki, and blog. Emma confirms that a web page should be created and she types some text to be included on that page. She then accesses Flickr using the icon on her screen, logs in, and creates a private group to share trip photos that students and teachers have taken. She uploads some of her own photos from previous trips and emails an invitation to join the photo-sharing group to the battlefields email list. Emma uploads material from her own laptop that she has written about the trip to iLearn and shares this with the battlefields group. This action adds her documents to the web page and generates an alert to group members that new material is available. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 30 Writing scenarios (1 of 2) Scenarios should always be written from the user’s perspective and based on identified personas or real users. Your starting point for scenario writing should be the personas that you have created. You should normally try to imagine several scenarios from each persona. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 31 Writing scenarios (2 of 2) Ideally, scenarios should be general and should not include implementation information. – However, describing an implementation is often the easiest way to explain how a task is done. It is important to ensure that you have coverage of all of the potential user roles when describing a system. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 32 Table 3.7 Elena’s scenario: configuring the iLearn system (1 of 2) Elena has been asked by David, the head of the art department in her school, to help set up an iLearn environment for his department. David wants an environment that includes tools for making and sharing art, access to external websites to study artworks, and “exhibition” facilities so that the students’ work can be displayed. Elena starts by talking to art teachers to discover the tools that they recommend and the art sites that they use for studies. She also discovers that the tools they use and the sites they access vary according to the age of their students. Consequently, different student groups should be presented with a toolset that is appropriate for their age and experience. Once she has established what is required, Elena logs into the iLearn system as an administrator and starts configuring the art environment using the iLearn setup service. She creates sub-environments for three age groups plus a shared environment that includes tools and sites that may be used by all students. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 33 Table 3.7 Elena’s scenario: configuring the iLearn system (2 of 2) She drags and drops tools that are available locally and the URLs of external websites into each of these environments. For each of the sub-environments, she assigns an art teacher as its administrator so that they can’t refine the tool and website selection that has been set up. She publishes the environments in “review mode” and makes them available to the teachers in the art department. After discussing the environments with the teachers, Elena shows them how to refine and extend the environments. Once they have agreed that the art environment is useful, it is released to all students in the school. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 34 User involvement (1 of 2) It is easy for anyone to read and understand scenarios, so it is possible to get users involved in their development. The best approach is to develop an imaginary scenario based on our understanding of how the system might be used then ask users to explain what you have got wrong. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 35 User involvement (2 of 2) They might ask about things they did not understand and suggest how the scenario could be extended and made more realistic. Our experience was that users are not good at writing scenarios. – The scenarios that they created were based on how they worked at the moment. They were far too detailed and the users couldn’t easily generalize their experience. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 36 User stories (1 of 2) Scenarios are high-level stories of system use. They should describe a sequence of interactions with the system but should not include details of these interactions. User stories are finer-grain narratives that set out in a more detailed and structured way a single thing that a user wants from a software system. – As an author, I need a way to organize the book that I’m writing into chapters and sections. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 37 User stories (2 of 2) This story reflects what has become the standard format of a user story: – As a , I to As a teacher, I want to tell all members of my group when new information is available A variant of this standard format adds a justification for the action: – As a I to so that As a teacher, I need to be able to report who is attending a class trip so that the school maintains the required health and safety records. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 38 User stories in planning (1 of 2) An important use of user stories is in planning. – Many users of the Scrum method represent the product backlog as a set of user stories. User stories should focus on a clearly defined system feature or aspect of a feature that can be implemented within a single sprint. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 39 User stories in planning (2 of 2) If the story is about a more complex feature that might take several sprints to implement, then it is called an epic. – As a system manager, I need a way to backup the system and restore either individual applications, files, directories or the whole system. – There is a lot of functionality associated with this user story. For implementation, it should be broken down into simpler stories with each story focusing on a single aspect of the backup system. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 40 Figure 3.6 User stories from Emma’s scenario Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 41 Feature description using user stories Stories can be used to describe features in your product that should be implemented. Each feature can have a set of associated stories that describe how that feature is used. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 42 Figure 3.7 User stories describing the Groups feature Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 43 Stories and scenarios (1 of 2) As you can express all of the functionality described in a scenario as user stories, do you really need scenarios?’ Scenarios are more natural and are helpful for the following reasons: – Scenarios read more naturally because they describe what a user of a system is actually doing with that system. People often find it easier to relate to this specific information rather than the statement of wants or needs set out in a set of user stories. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 44 Stories and scenarios (2 of 2) Scenarios are more natural and are helpful for the following reasons: – If you are interviewing real users or are checking a scenario with real users, they don’t talk in the stylized way that is used in user stories. People relate better to the more natural narrative in scenarios. – Scenarios often provide more context - information about what the user is trying to do and their normal ways of working. You can do this in user stories, but it means that they are no longer simple statements about the use of a system feature. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 45 Feature identification (1 of 2) Your aim in the initial stage of product design should be to create a list of features that define your product. A feature is a way of allowing users to access and use your product’s functionality so the feature list defines the overall functionality of the system. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 46 Feature identification (2 of 2) Features should be independent, coherent and relevant: – Independence Features should not depend on how other system features are implemented and should not be affected by the order of activation of other features. – Coherence Features should be linked to a single item of functionality. They should not do more than one thing and they should never have side-effects. – Relevance Features should reflect the way that users normally carry out some task. They should not provide obscure functionality that is hardly ever required. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 47 Figure 3.8 Feature design Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 48 Table 3.8 Knowledge required for feature design Knowledge Description User knowledge You can use user scenarios and user stories to inform the team of what users want and how they might use the software features. Product knowledge You may have experience of existing products or decide to research what these products do as part of your development process. Sometimes your features have to replicate existing features in these products because they provide fundamental functionality that is always required. Domain knowledge This is knowledge of the domain or work area (e.g., finance, event booking) that your product aims to support. By understanding the domain, you can think of new innovative ways of helping users do what they want to do. Technology knowledge New products often emerge to take advantage of technological developments since their competitors were launched. If you understand the latest technology, you can design features to make use of it. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 49 Figure 3.9 Factors in feature set design Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 50 Feature trade-offs (1 of 2) Simplicity and functionality – You need to find a balance between providing a simple, easy-to-use system and including enough functionality to attract users with a variety of needs. Familiarity and novelty – Users prefer that new software should support the familiar everyday tasks that are part of their work or life. To encourage them to adopt your system, you need to find a balance between familiar features and new features that convince users that your product can do more than its competitors. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 51 Feature trade-offs (2 of 2) Automation and control – Some users like automation, where the software does things for them. Others prefer to have control. You have to think carefully about what can be automated, how it is automated and how users can configure the automation so that the system can be tailored to their preferences. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 52 Feature creep (1 of 2) Feature creep occurs when new features are added in response to user requests without considering whether or not these features are generally useful or whether they can be implemented in some other way. Too many features make products hard to use and understand Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 53 Feature creep (2 of 2) There are three reasons why feature creep occurs: – Product managers are reluctant to say ‘no’ when users ask for specific features. – Developers try to match features in competing products. – The product includes features to support both inexperienced and experienced users. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 54 Figure 3.10 Avoiding feature creep Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 55 Feature derivation Features can be identified directly from the product vision or from scenarios. You can highlight phrases in narrative description to identify features to be included in the software. – You should think about the features needed to support user actions, identified by active verbs, such as use and choose. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 56 Table 3.9 The iLearn system vision FOR teachers and educators WHO need a way to help students use web- based learning resources and applications, THE iLearn system is an open learning environment THAT allows the set of resources used by classes and students to be easily configured for these students and classes by teachers themselves. UNLIKE Virtual Learning Environments, such as Moodle, the focus of iLearn is the learning process rather than the administration and management of materials, assessments, and coursework. OUR product enables teachers to create subject and age-specific environments for their students using any web-based resources, such as videos,simulations, and written materials that are appropriate Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 57 Features from the product vision A feature that allows users to access and use existing web-based resources; A feature that allows the system to exist in multiple different instantiations; A feature that allows user configuration of the system to create a specific instantiation. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 58 Table 3.10 Jack’s scenario with highlighted phrases (1 of 2) Jack is a primary school teacher in Ullapool, teaching P6 pupils. He has decided that a class project should be focused around the fishing industry in the area, looking at the history, development, and economic impact of fishing. As part of this, students are asked to gather and share reminiscences from relatives, use newspaper archives, and collect old photographs related to fishing and fishing communities in the area. Students use an iLearn wiki to gather together fishing stories and SCRAN (a history archive) to access newspaper archives and photographs. However, Jack also needs a photo- sharing site as he wants pupils to take and comment on each others’ photos and to upload scans of old photographs that they may have in their families. He needs to be able to moderate posts with photos before they are shared, because pre-teen children can’t understand copyright and privacy issues. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 59 Table 3.10 Jack’s scenario with highlighted phrases (2 of 2) Jack sends an email to a primary school teachers’ group to see if anyone can recommend an appropriate system. Two teachers reply and both suggest that he use KidsTakePics, a photo-sharing site that allows teachers to check and moderate content. As KidsTakePics is not integrated with the iLearn authentication service, he sets up a teacher and a class account with KidsTakePics. He uses the the iLearn setup service to add KidsTakePics to the services seen by the students in his class so that when they log in, they can immediately use the system to upload photos from their phones and class computers. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 60 Features from Jack’s scenario A wiki for group writing. Access to the SCRAN history archive. This is a shared national resource that provides access to historical newspaper and magazine articles for schools and universities. Features to set up and access an email group. A feature to integrate applications with the iLearn authentication service. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 61 The feature list The output of the feature identification process should be a list of features that you use for designing and implementing your product. There is no need to go into a lot of detail about the features at this stage. You add detail when you are implementing the feature. You can describe features using a standard input- action-output template by using structured narrative descriptions or by a set of user stories. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 62 Figure 3.11 The iLearn authentication feature Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 63 Table 3.11 Feature description using user stories (1 of 2) iLearn system configuration Description As a system manager, I want to create and configure an iLearn environment by adding and removing services to/from that environment so that I can create environments for specific purposes. As a system manager, I want to set up sub-environments that include a subset of services that are included in another environment. As a system manager, I want to assign administrators to created environments.As a system manager, I want to limit the rights of environment administrators so thatthey cannot accidentally or deliberately disrupt the operation of key services. As a teacher, I want to be able to add services that are not integrated with the iLearn authentication system. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 64 Table 3.11 Feature description using user stories (2 of 2) iLearn system configuration Constraints The use of some tools may be limited for license reasons so there may be a need toaccess license management tools during configuration. Comments Based on Elena’s and Jack’s scenarios Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 65 Innovation and feature identification (1 of 2) Scenarios and user stories should always be your starting point for identifying product features. – Scenarios tell you how users work at the moment. They don’t show how they might change their way of working if they had the right software to support them. – Stories and scenarios are ‘tools for thinking’ and they help you gain an understanding of how your software might be used. You can identify a feature set from stories and scenarios. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 66 Innovation and feature identification (2 of 2) User research, on its own, rarely helps you innovate and invent new ways of working. You should also think creatively about alternative or additional features that help users to work more efficiently or to do things differently. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 67 Key points 1 (1 of 2) A software product feature is a fragment of functionality that implements something that a user may need or want when using the product. The first stage of product development is to identify the list of product features in which you identify each feature and give a brief description of its functionality. Personas are ‘imagined users’ where you create a character portrait of a type of user that you think might use your product. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 68 Key points 1 (2 of 2) A persona description should ‘paint a picture’ of a typical product user. It should describe their educational background, technology experience and why they might want to use your product. A scenario is a narrative that describes a situation where a user is accessing product features to do something that they want to do. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 69 Key points 2 (1 of 2) Scenarios should always be written from the user’s perspective and should be based on identified personas or real users. User stories are finer-grain narratives that set out, in a structured way, something that a user wants from a software system. User stories may be used as a way of extending and adding detail to a scenario or as part of the description of system features. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 70 Key points 2 (2 of 2) The key influences in feature identification and design are user research, domain knowledge, product knowledge, and technology knowledge. You can identify features from scenarios and stories by highlighting user actions in these narratives and thinking about the features that you need to support these actions. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 71 Copyright This work is protected by United States copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning. Dissemination or sale of any part of this work (including on the World Wide Web) will destroy the integrity of the work and is not permitted. The work and materials from it should never be made available to students except by instructors using the accompanying text in their classes. All recipients of this work are expected to abide by these restrictions and to honor the intended pedagogical purposes and the needs of other instructors who rely on these materials. Copyright © 2020, Pearson Education, Inc. All Rights Reserved 3 - 72