Specifying Usability Features with Patterns and Templates

Transcription

1 Specifying Usability Features with Patterns and Templates Holger Röder University of Stuttgart Institute of Software Technology Universitätsstraße 38, Stuttgart, Germany Abstract Functional usability features like Undo or Auto- Save can greatly add to the usability of interactive software systems. This paper presents a pragmatic approach to considering usability features as first-class citizens during early phases of software development, in particular during requirements analysis and definition. A catalog of usability patterns is used to describe proven and reusable solutions and to support software engineers in selecting appropriate usability features for a system. To allow for a systematic consideration, usability features are specified in a use casebased software requirements specification using semiformal specification templates. The resulting extended specification defines where and how usability features shall be integrated in the system, thus facilitating subsequent development activities (e. g. software architecture design, implementation, and test). Keywords-Software Requirements Specification; Use Cases; Usability; Usability Features; Usability Patterns I. INTRODUCTION AND MOTIVATION Usability is an important factor for the overall success of a software system. Functional usability features can substantially add to the system s perceived usability. The wide acceptance of features like Undo (allow users to revert actions) or Run in Background (allow users to have the system perform long-running tasks in the background ) shows that such features have become essential parts of usable interactive systems. They can add to usability characteristics like error tolerance and controllability of the system. From a human-computer interaction (HCI) or usability engineering perspective, functional usability features should be clearly considered when defining and building systems [1]. From a software engineering perspective, however, there is still a lack of integration with established development processes, starting with requirements elicitation and specification. Software engineers 1 often do not take usability features into account systematically, and, in particular, do not consider them first-class citizens during requirements-related activities. As a result, usability features are often not adequately (or not at all) specified in the software requirements specification. This is despite the fact that usability features need to be considered in various subsequent activities in the development process. They are far from being limited to the systems user 1 In this paper, the term software engineer subsumes roles like requirements engineer, software architect, or software developer. interface and, consequently, cannot simply be realized by some pitiful user interface (UI) designer. Usability features often imply significant constraints and requirements on the systems architecture, and result in additional functionality to be implemented and tested [2]. The lack of an agreed specification may thus result in usability features not being integrated in the system at all, being integrated inconsistently, or not being tested sufficiently, thus leading to lower usability and overall quality of the system. The approach presented in this paper attempts to improve visibility and consideration of usability features in established requirements engineering activities and artefacts commonly found in the industry. It proposes using a catalog of proven patterns to support the selection of usability features of an interactive system during requirements definition, and suggests specifying the selected usability features within use case descriptions using a template-based specification technique. The remainder of this paper is as follows: In the next section, the notion of usability patterns and usability features is presented. Section III outlines the specification technique, and section IV introduces the use of templates to support specification. A subsequent example in section V illustrates the specification technique. Section VI describes the evaluation of the approach that has been done so far. The last section concludes the paper with a short discussion, conclusions, and outlook. II. USABILITY PATTERNS AND USABILITY FEATURES In today s software industry, many systems are still built without the involvement of HCI specialists in the development process [3]. Systems are built by software engineers with little or no usability expertise who often have limited knowledge of adequate usability features for the systems they develop. It seems reasonable to support software engineers by showing them what kind of usability features exist, when and how the features should be taken into account, and the positive and negative impact particular features can have (e. g. on system architecture, system costs, or usability). In recent years, the concept of patterns as recurring solutions to common problems in a given context [4] has gained increasing popularity in both the software engineering and the HCI community. In HCI, proven UI solutions /12/$31.00 c 2012 IEEE 6 UsARE 2012, Zurich, Switzerland

2 Table I USABILITY PATTERNS IN THE CATALOG (EXCERPT) Usability Pattern Undo Run in Background Auto-Save Recycle Bin Progress Display Preview Short Description Allow users to revert actions. Allow users to have the system perform long-running tasks in the background, and to meanwhile continue working with the system. Save changes automatically without users having to care about it. Validate user input while user is typing, and give immediate feedback. Allow users to move data to a virtual recycle bin instead of deleting it permanently, and allow them to restore data from the recycle bin upon request. Inform users about the progress of long-running tasks, and help them estimate the time remaining. Allow users to preview the expected results of an action. have been identified as interaction design patterns and have been used as a means of communicating and teaching design knowledge. Interaction design patterns have been collected in numerous pattern catalogs that have been released as books or published on the web (see [5] for an overview). The approach presented in this paper picks up the basic idea of interaction design patterns, but focuses on functional features, not on UI widgets or design concepts. For this approach, proven functional usability features that can be found in well-designed existing systems have been identified and, on an abstract level, described as so-called usability patterns. The descriptions adhere to a common structure. Each usability pattern describes a typical problem related to the use of an interactive software system, a proven functional solution to this problem, the context of use in which the solution is recommended, the rationale, and realworld examples (illustrated with screenshots) to support the arguments. The individual patterns form a usability pattern catalog. Table I shows some of the patterns included in the catalog. During requirements definition, software engineers can use this usability pattern catalog to learn about possible usability features for the system they are building. Based on the catalog and the pattern descriptions, they can discuss, weight the costs and benefits, and finally decide on the usability features to be integrated in the system. III. SPECIFICATION OF USABILITY FEATURES IN USE CASES Experience tells that naming the required features of a system is not enough. To allow for a systematic (and cost-efficient) consideration during subsequent development activities, usability features have to be specified as fullfledged requirements in the requirements specification. Basically, this can be done using various specification techniques, e. g. by specifying plain functional requirements in natural language. However, the nature of usability features calls for a technique that takes their specific characteristics into account. Usability features often appear as crosscutting features that affect many or all business functions of a system; therefore, the features become part of various interactions between the system and its users. For example, a well-designed system would offer its users the Run in Background feature not only for one particular business function, but for a number of different (presumably longrunning) functions the software performs. This behavior cannot be adequately expressed through single functional requirements. The specification technique used in this approach accounts for both the cross-cutting nature of usability features as well as the objective of having consistent and complete requirements. This is achieved by interweaving business functions and usability features at requirements level in a use case-based requirements specification. Functional requirements for interactive systems are commonly specified in the form of use cases [6], [7]. Use cases are used for modeling and describing interactions between the (future) system and its users. In a use case specification, use cases are described in structured textual form (e. g. in tables), with each use case comprising one or more interaction sequences and each sequence containing a number of basic interaction steps (to be performed by the system or a user). In the present approach, a given use case specification (assumed to specify all the business functions) is extended by adding additional requirements that specify the system s usability features: Global usability feature requirements, also called global parameters, are used to define general constraints (on an abstract level) on how usability features shall be realized in the system, e. g. by specifying default behavior or UI design constraints. This ensures that a particular feature is implemented similarly throughout the system, hopefully adding to a consistent user experience. (E. g. for the Run in Background feature: The background task progress bar shall always appear in the bottom right corner of the dialog window.) Interaction-specific usability feature requirements refer to single interactions between the system and its users. They are used to define where (i. e. for which interactions) particular usability features shall be implemented. This is expressed in the use case specification by adding annotations to the respective use case elements (i. e. use cases, interaction sequences, or interaction steps). If necessary, additional local parameters can be used to describe more precisely how the features shall be implemented, and use case extensions, 7

3 Usability Features Usability Feature Usability Feature F1 Global Param. 1 Global Param. 2 Global Requirements Usability Feature F1 Global Param. 1 Global Param. 2 Use Usability Feature F1 here! Use Case 1 Use Case 1 Use Case 1 Main Flow Main Flow Main Flow Step 1 Step 2 Step 3 Alternate Flow Step 2a1 Use Case 2 Step 1 Step 2 Step 3 Alternate Flow Step 2a1 Use Case 2 Step 1 Step 2 Step 3 + Alternate Flow Alternate Flow Step 2a1 Use Case 2 + Step 1a1 F1 (Annotation) F1 (Annotation) Interactionspecific Requirements (a) Initial Use Case Specification (b) Specifying Global Usability Feature Requirements (c) Specifying Interaction-Specific Usability Feature Requirements: Annotations and Local Parameters Figure 1. Schematic view of a usability feature specification in a use case-based software requirements specification i. e. additional use case elements, can be used to express an extended interaction sequence which stems from the usability feature being implemented in the particular interaction. (In the above example: Annotate all use case steps that describe long-running processing tasks the system has to run in background at users request. For each annotation, specify how the system shall calculate task progress as a parameter.) Figure 1 outlines how a use case specification can be extended with both global and interaction-specific usability feature requirements. In this example, annotations and local parameters have been added to step 1 and step 2a1 in the first use case. As the feature integration in step 1 may lead to new interactions, an additional interaction sequence (alternate flow) has also been specified. IV. SPECIFICATION TEMPLATES The specification technique introduced in the previous section is centered around specifying a system s usability features in an extended use case specification. However, inexperienced software engineers might not know what to specify, i. e. what information to include in the extended specification to allow for a successful implementation of the usability features. To support software engineers in specifying complete (and adequate) usability feature requirements, each usability pattern s description comes with a set of semiformal guidelines, so-called specification templates. The templates define how the particular usability feature has to be specified. This is based on the assumptation that, on an abstract level, the information software engineers need to know (from the requirements specification) for the effective implementation of a particular usability feature is similar or same for different systems and even for different business domains and technical contexts and that, consequently, this information can be specified in the same way. Each usability pattern description includes multiple specification templates. Each template refers to a particular type of usability feature requirement (as introduced in the previous section) and describes which information should be expressed through requirements of this type when specifying the respective usability feature. E. g., an annotation template tells software engineers to annotate particular use case elements in order to denote where (i. e. in which interactions) a usability feature shall be implemented. As a whole, the set of templates in the pattern description defines which information has to be specified for the usability feature, and how the information should be specified. The templates thus enable software engineers to provide all the information needed to take the usability feature into account in subsequent development activities. Figure 2 shows a (simplified) example: The usability pattern defines three specification templates (shown in the bottom part of the figure). The first template tells software engineers to specify a global parameter UI representation. The second template tells them to annotate all use case steps with a annotation if user input is to be validated. For each annotated use case step, software engineers are also required to specify the criteria for input validation (local parameter Valid Data, third specification template). This information, when adequately specified, is (in this example) assumed to be sufficient for an effective implementation of the feature. 8

4 6. Use Cases Use Case Goal Actor(s) Main Success Scenario Undo Transfer money UC#3 The customer wants to transfer money from his/her bank account to another bank account (target account). Customer 1. Customer selects function Transfer money 2. System shows money transfer form. 3. Customer enters transfer amount. Valid data: Positive amount in German currency format; Max. amount: current balance + credit limit 4. Customer enters target account information. Valid data: Valid International Bank Account Number, IBAN (ISO ) 6. Customer enters reference text. 7. Customer selects to transfer the money. 8. System transfers money from customer s account to target account. 9. System shows confirmation. Undo Condition: Money transfer shall be reversible within 60 minutes after submission Figure 4. Example use case with annotations 5. Usability Figure 2. Pattern Usability Requirements Pattern (excerpt) 5.1. Usability Feature UI Representation The system shall display the validation result next to the input field. The system shall use the following symbols to indicate the validation result: warning sign for invalid data; check mark for valid data. The system shall display an explanatory message upon user s request. Figure 3. Example global parameter for V. SPECIFICATION EXAMPLE The following (again simplified) scenario illustrates the approach. During requirements definition for a new online banking system, software engineers use the catalog of usability patterns to identify and propose adequate usability features that can add to the usability of the system. With respect to the context of use, product management selects the usability feature (among others) to be included in the banking system. Based on the given use case specification, the feature is specified according to the specification templates defined in the pattern description. The global parameter template UI representation requires the specification of UI-related constraints, in order to ensure that validation results are displayed similarly in all dialogs, even if different developers implement the dialogs. Therefore, in the first step, a corresponding global parameter is specified. The parameter defines how the system shall display the results of live validation (figure 3). In the next step, the use cases in the use case specification (i. e., the business-related functional requirements) are analyzed, and all user input steps where live validation should take place are annotated as defined by the Live Validation annotation template. In the example use case Transfer money shown in figure 4, step 3 and step 4 are annotated. Finally, the local parameters Valid Data are specified individually for each annotation. They define the criteria to be used for validation. Following this procedure, the resulting extended use case specification contains all the information needed for taking the usability feature into account during architecture design, implementation, and test. (To illustrate the specification technique, figure 4 also shows another sequence annotation, Undo, that is used to specify under which conditions users can undo the money transfer.) VI. EVALUATION The approach has been successfully evaluated in different settings. In a recent undergraduate software project at the University of Stuttgart, a total of 70 software engineering students in 23 teams applied the approach when developing a Java-based information system for a customer from the industry (total effort per team: approx. 75 person-days). The concept of usability patterns and the usability feature specification technique were introduced in two short trainings beforehand, and students were given a catalog of 20 usability patterns for interactive software systems. The main objective of this evaluation was to find out whether 9

5 Figure 5. Extended use case editor TULIP participants with little usability expertise were able to select appropriate usability features for the system they were building, and whether they were able to specify a complete set of requirements for the usability features to be included in their systems. For specifying use cases and usability features, participants used TULIP, an extended use case editor that has been developed as a supporting tool for the present approach. TULIP allows e. g. adding annotations to use case elements (as defined by annotation templates) with a few mouse clicks, thus facilitating the use of the specification technique. Figure 5 shows a screenshot of the main window and the annotation dialog. Results of this evaluation are promising. 16 out of 23 teams selected between five and nine usability features (which was considered the adequate range) for their systems (out of the 20 usability patterns described in the catalog). The selected features were in most cases both appropriate and feasible. Usability features that did not match the system s context of use or functionality were consequently left out. In total, about 65% of the additional requirements related to usability features were specified completely and correctly in extended use case specifications, following the respective specification templates. Results show that a majority of the teams specified their usability features almost flawlessly, while five teams apparently did not understand the specification technique and thus delivered no correct feature specifications at all. In summary, the evaluation indicates that a catalog of usability patterns can help less-experienced software engineers selecting appropriate usability features for a system during requirements analysis and definition, and that the template-based specification technique enables software engineers to specify requirements that adequately define these features in a software requirements specification. The evaluation also showed a high level of acceptance of the approach among the participants. For example, when asked about the perceived helpfulness of the usability pattern catalog, 19 out of 23 teams answered that the catalog had been helpful or very helpful during their requirements activites. VII. CONCLUSIONS AND OUTLOOK The approach presented in this paper provides a pragmatic way to select and specify, at requirements level, functional 10

6 usability features of a software system. It can be applied in software development processes where system functionality and designated interactions between users and system are specified in the form of use cases. However, as part of future research, the approach might also be adapted to other types of interaction models (e. g. UML activity diagrams), provided that the level of detail of the modeled interactions matches the level of detail needed for usability feature specifications. Usability is a broad subject, and by focusing on functional usability features, the approach takes only a part of the various aspects into account that make for usable systems. It should therefore preferably be used in the context of a greater usability-oriented engineering process, in which other aspects of usability are also considered. However, as the approach represents one of the (still) few attempts to systematically integrate functional usability features with established requirements-related activities and commonly found artefacts, it may increase awareness for usability issues even in more traditional (i. e. less user-centric) organizations. Results of the evaluation so far indicate that the approach can be successfully applied by software engineers with little or no usability expertise, which is often considered a necessary condition for establishing usability-oriented methods in software development organizations [8]. However, further evaluation in an industry setting might be needed to validate this assumption. Future research will also focus on expanding the catalog of usability patterns, and on integrating usability feature specifications with graphical UI prototypes (e. g. mockups). REFERENCES [1] N. Juristo, A. M. Moreno, and M.-I. Sanchez-Segura, Guidelines for eliciting usability functionalities, IEEE Transactions on Software Engineering, vol. 33, no. 11, pp , [2] L. Bass and B. E. John, Supporting usability through software architecture, IEEE Computer, vol. 34, no. 10, pp , [3] B. Jerome and R. Kazman, Surveying the solitudes: An investigation into the relationships between human computer interaction and software engineering in practice, in Human- Centered Software Engineering Integrating Usability in the Software Development Lifecycle, A. Seffah, J. Gulliksen, and M. C. Desmarais, Eds. Springer, 2005, pp [4] C. Alexander, The Timeless Way of Building. Oxford University Press, [5] A. Dearden and J. Finlay, Pattern languages in HCI: A critical review, Human-Computer Interaction, vol. 21, no. 1, pp , [6] I. Jacobson, M. Christerson, and P. Jonsson, Object-Oriented Software Engineering A Use Case Driven Approach. Addison-Wesley Longman, Amsterdam, [7] C. J. Neill and P. A. Laplante, Requirements engineering: The state of the practice, IEEE Software, vol. 20, no. 6, pp , [8] J.-Y. Mao, K. Vredenburg, P. W. Smith, and T. Carey, Usercentered design methods in practice: A survey of the state of the art, in Proceedings of the 2001 Conference of the IBM Centre for Advanced Studies,