Generating Mockup From Requirements - Semantic Scholar€¦ · Generating Mock-ups from...

Generating Mockup From Requirements

Łukasz Olek, Bartosz Michalik, Mirosław Ochodek

Poznań University of Technology, Institute of Computing Science ul. Piotrowo 3A, 60-965 Poznań, Poland

{ Lukasz.Olek, Bartosz.Michalik, Miroslaw.Ochodek}@cs.put.poznan.pl

Abstract. The software industry needs better prototyping techniques to lower prototype creation and maintainability costs. This goal can be achieved using proper set of tools and representation for requirements. Special tool for analyst has been developed at Poznań University of Technology, that is able to generate Mock-ups from requirements.

Keywords: Prototyping, Requirements Engineering, Mock-up, Use Cases

1 Introduction

Software industry is aware of the fact, that using a prototyping technique could solve most of problems with requirements engineering. Unfortunately the cost of creating such a prototype and maintenance effort seems to be too high many projects. This article presents a requirements model, method and tool for a cheap creation of Mock-ups straight from the requirements. This model currently allows to describe requirements for web applications. Generated Mock-up is presented to reviewers in a form of HTML page. The paper gives answers to the following questions: − Is proposed model flexible enough, to describe a wide variety of software systems? − Is Mock-up easy to understand? Does it help reviewers to imagine how future

system will look like ? − Is it easy to maintain Mock-up in case of many requirements changes? Generation of the Mock-up is supported by the UC Workbench tool created at Poznan University of Technology. It is a development environment for analysts, used for requirements authoring activity ([17], [9], [10]).

2 UC Workbench Requirements Model

Before going into details concerning Mock-up generation, an overview of requirements model in UC Workbench is necessary. Requirements are the core of each software project, or at least they should be. They are the source of knowledge for creating prototypes, making effort estimates,

2 Łukasz Olek, Bartosz Michalik, Mirosław Ochodek

preparing project schedule, creating acceptance test cases, and much more. Being really the heart of software project requirements specification should have many properties: − be easy to understand - as a tool of communication between customers and

suppliers − describe business domain - each software exists in some context and it is much

easier to understand requirements, when we know the environment in which the system will operate

− be easy (cheap) to create − can be changed easily (cheaply) - software projects tend to be more and more agile,

and agility allows easy changes in requirements, we need better methods of coping with changes in requirements.

Our proposition is to gather requirements describing three aspects of the system (fig. 1). They form three layers of description and are tightly connected with each other.

Fig. 1. UC Workbench requirements model describing three different aspects of the system.

The most important part for each system are functional requirements. According to recent trends ([1], [4], [6]), reasonably good method for this purpose are use cases. This approach suggests writing scenarios describing interaction between users and the system in natural language. Use cases can be written in different forms: e.g. draft, unstructured form, structured form. The example of use case in structured form is presented on the figure 2. Use cases are easy to understand by customer, and are very popular in the industry ([4,1]). A computer can also understand the structure, and this knowledge is very usable in many applications (e.g. see section 2).

Generating Mock-ups from Requirements 3

Fig. 2. An example of a use case in a structured form.

Functional requirements are embedded in business domain model, second part of the model. It is usually divided in three parts: − Actors – roles of people, that act in business processes − Business objects – description of data passed between actors − Business processes – describes interaction between actors and other systems. In general business processes can be described using different approaches: e.g. BPMN ([12], UML ([5]), or even use cases ([11], [4]). UC Workbench supports analyst in authoring business process written as use cases.

3.1 UC Workbench GUI Model

The last part of the requirements model is a model of GUI. This model consists of loose drafts of application screens, that are connected to the use cases. An example of such a screen is given on figure 3.:

Fig. 3. An example of screen sketch. Such sketches are prepared quickly using simple screen editor .


There is always one question about the type of prototype ([16]), whether it should be a high fidelity (hi-fi) prototype, or rather a low fidelity (lo-fi) one. We decided to use lo-fi prototype for UC Workbench, due to the fact that it seems to have serious advantages ([14]): − it is much easier to prepare lo-fi prototype, you do not waste time for representing

graphical details of the future system − it is better for customers, because they can focus on functional aspects, and not

graphical ones (e.g. fonts, colors, layout) Current version of UC Workbench GUI model can represent only web applications. It was much easier to focus research on the simpler interaction model. Screen drafts in UC Workbench can contain three types of widgets: − Static – a user cannot act on them, but can read information: e.g. text or image − Dynamic – a user can interact with them (read information and act): e.g. edit box,

check box, combo box, radio button, list box or button. They represent HTML controls.

− Grouping – are used to structure screen properly. There are two widgets of this type: Group widget, used for grouping elements of radio buttons, and Repeater, used for marking, that some part of the screen can be repeated (figure 4.).

Fig. 4. Repeater widget, used to model fragments of a GUI that can be multiplied at screen (e.g. table, list of items)

4 Generation of Mock-ups from Use Cases

When you combine use cases with GUI drafts, you receive a two dimensional description of the system under consideration: − use cases describe the flow of interaction between users and system, making it easy

to realize how particular tasks will be executed − GUI drafts are connected to particular steps of use cases and show the details of

this interaction Figure 5. shows the relation between use cases and GUI drafts.


Fig. 5. Relation between use cases and GUI drafts.

Maintaining this connection is quite easy, but requires specialized tool. In our UC Workbench tool you are able to do this easily. After entering use cases, preparing GUI drafts, and setting connection between them, it is time for Mock-up generation. UC Workbench Mock-up is generated as HTML page that visualizes the future system. Example of such Mock-up is shown on the figure 6. There is a use case visible in the left panel of Mock-up. It defines navigation through the system. When reviewer clicks on a particular step, connected screen appears on the right. At any time he/she can switch to another use case, describing another function of the system. That is the way in which reviewer can browse requirements and imagine how the future system will look like.

Fig. 6. Example of Mock-up generated with UC Workbench, presented as a HTML page.

4.1 UC Workbench Mock-up Case Studies

One of the main questions we have asked proposing our solution concerned its


applicability. We claim that Mock-up solution is good way to show systems functionality to customers. But how precisely can we model system requirements? To answer this question following case study were proposed. We decided to check whether it is possible to model (in details) existing systems or not. We have taken three classes of web systems that are well known to the Internet community: − banking system − auctions system − on-line shopping system It is known that all of that systems are highly user interaction oriented, so it is very important for users to understand how to use such systems. It was not our intention to build Mock-ups for whole examined systems, so we have focused on most business oriented parts: − cash transfer for banking application − auction for auctions system − buying item for on-line shop We browsed through these systems to check how its works and to gather user scenarios. Then for each system use case set was written and application screens using low-fidelity approach were created. Next Mock-up were generated. In this part the results of described case study are described. First of all, we manage to model each of examined system in details. It was possible to model each part of application screens using proposed earlier set of components. There was straightforward mapping between screens from real application to our Mock-up's screens. Especially easy to translate was form-based screens and info screens.

Fig. 7. Example of a logging in screen from the www.wbk.pl banking system, and corresponding screen sketch for Mock-up purposes.

There are also some modeling aspects to consider. What is the best metaphor for repeatable blocks of screen (eg. list of product)? What is the best way to show tree structures in respect to the fact that the depth is not fixed. The last thing concerning screen modeling issues is what the best way to show that some parts of the screens contains default content is(eg. order form with default delivery address data for logged user). Low-fidelity static screens approach has also some limitations. It is hard to show complicated interaction (eg. drag and drop actions) using static screens. But some nonstandard tab orders can be shown on added comment layer. Also format and validation information can be provided in that way.


5 Mock-up evaluation

5.1 Is Mock-up Easy to Understand?

The main question, which appears after presenting the generated Mockup concept, is to acknowledge usefulness of such a prototype in a matter of understanding described system with a limited analyst support. We have decided to verify experimentally thesis that proposed approach to demonstrate system behavior to end users provides comprehensive understanding of the business logic and user interface. More importantly we should be able to receive feedback concerning usability of application at early stage of the design process. Another considered issue was analyst involvement in the prototyping process. We have already stated that Mock-up is a relatively cheap solution. We assume it may lower analyst effort in supporting end users with a better understanding of the business logic and user interface.

5.1.1 Experiment process description

The main idea of conducted experiment was to verify whether potential end users are able to write down all operations required to attain established business goal with the use of Mock-up instead of the real system. We have decided to choose an electronic shop system under the assumption that e-commerce domain is well known to the participants. The experiment was conducted in 2006 at the Poznan University of Technology. The participants were 4th year students working on their master degrees in Software Engineering (SE). There were 15 students in the examined group. The experiment procedure consisted of the following steps: 1. Introductory presentation, covering basic knowledge concerning use cases and

generated Mock-up (15 min). 2. Survey: verification of students past experiences regarding the e-commerce domain

(especially electronic shops) and requirements engineering with the use cases. 3. Main task: achieve business goal from the user perspective, using the prepared

online shop Mock-up. 4. Survey: participants personal assessment of the Mock-up prototyping concept and

usability of the presented e-commerce system.

5.1.2 Main task description

Business goal was to buy two types of products: apples and books in specially designed e-Shop system. We assumed that proper system for this experiment purpose, should conform two requirements: − domain of the problem should be well known to the participants,


− proposed system should be more complex and less usable than application participants might have encountered in the past.

In the real life projects both customer and analyst have knowledge about system business domain, thus it was very important that the problem domain was well recognized by the students. On the other hand, verifying Mock-up usefulness on a simple example might trigger corrupted results, because participants might understand system by analogy. Thus, proposed e-Shop system should be a non typical solution. We decided that created e-Shop system should have several usability problems, mostly concerning breaking common conventions and introducing complicated user interface flow. To verify complexity of the system in procedural aspects of usability, we decided to use a GOMS [7] model (NGOMSL implementation). It enabled comparison of predicted execution times for buying single product scenario in the proposed e-Shop and Amazon.com [2]. According to the GOMS simulation results scenario execution times were: − e-Shop – 184 seconds, − Amazon.com – 121 seconds. It seemed that buying a single product scenario required 52% more time to complete in case of the e-Shop system. Thus, we assumed that proposed system fulfilled complexity requirement. Participants task was to use the e-Shop system Mock-up (based on the 7 use cases) in order to write down a sequence of operations one should perform on the real system, to achieve a business goal. Each operation entry was logged using the following format: − use case unique id, − step number, − action describing single user activity put down using following format

<Type> '<Name>' [:<Value>], where: <Type> is a type of an object, e.g. Button, Link, Edit etc., '<Name>' is a name of an object, e.g. 'Login', 'Surname' etc., <Value> (optional) is value used to fill a field.

Table 2. Main task results summary.

Although students were working individually, they could request analyst support (1 analyst was assigned to 5 students). Each analyst intervention was precisely reported and described. Participants were explicitly provided with the data necessary to achieve the goal (e.g. product name, category, user personal data etc.).


5.1.3 Results Before participants were asked to proceed to the main task, they were surveyed in order to verify their familiarity with the e-commerce domain and use cases. Questionnaire consisted of the following questions: 1. How many times have you been browsing through a content of the electronic

shop? 2. How many times have you been buying products in the electronic shops? 3. How many times have you been preparing use cases (for how many systems)? 4. How many times have you been reading requirements specification written with

use cases? Possible answers were:

− Never, − Once, − Few times (less then 10), − Many times (10 or more). All participants were browsing through the content of electronic shop before and nearly all participants have bought a product at least once (fig. 7). Participants were also familiar with the concept of use cases for requirements description.

Fig. 7. Summary of the domain knowledge verification survey.

The most important question was whether operations sequences defined by participants were correct. Assumption was made that business goal was achieved if there were no major errors concerning business logic in the log (e.g. omitting the whole use case). We have also defined two types of errors which might occur: − Flow error – minor defect in business logic (e.g. omitting extension, when it was

necessary), − Data error – wrong input data format (form validation errors) or inaccurate data

entered. Another important aspect was the analysts involvement in helping participants attaining business goal. We divided analyst interventions into three categories: − R1 – small problems or questions concerning screens, fields validation etc., − R2 – more serious problems concerning understanding business logic (flow of

control in use cases), − T – solving problems addressed to the task description, not connected with the


Mock-up. To our surprise, all participants achieved business goal. Results summary is presented in table 3. The average analyst interactions per participant was 1.6, including both R1 and R2 issues (T was not considered). Moreover, approximately 30% of the questions concerned business logic (R2). Average number of errors made by a single participant was 0.40 for flow problems and 0.80 for data defects. It seems that Mock-up is easy to understand, it provides necessary information required to understand the developed system business logic (average total errors number per single use case was 0.17).It also does not require much analyst support (average analyst support requests number was only 1 per 4.38 use cases). For these reasons, generated Mock-up is very cheap to create and review, so it seems to be a good alternative for traditional prototyping methods.

Table 3. Main task results summary.

After completing experiment's main task, participants were asked to express their opinion about the Mock-up concept and usability of the e-Shop system. Survey consisted of the following questions: 1. Does a Mock-up properly presents functionality of the software system? 2. Are use cases and actors presented in an easy to read mode? 3. Do you think it is easy to learn how to use a Mock-up? 4. Do you think that Mock-up is an easy to use tool? 5. If you were an analyst, would you like to use a Mock-up to present requirements

to end users of the system? 6. Do you think, that presented e-Shop system is properly designed, in a manner of

usability? Possible answers were: − Definitely yes, − Yes, − Hard to tell, − No,


− Definitely no. It seems that students perceived Mock-up as a reliable tool for animating requirements, which was confirmed by 73% of participants, who stated that Mock-up properly presents functionality of the system (fig. 8). Furthermore, 80% decided that it is easy to learn how to interact with a Mock-up. Another important issue was that 93% of students decided that presented e-Shop system, in fact, had design defects regarding usability.

Fig. 8. Participants personal assessment of the Mock-up prototyping concept and usability of

the presented e-Shop system.

Acknowledgments

First of all we would like to thank the students participating in our experiments. We owe also a lot to the software companies belonging to the XPrince Consortium. Special thanks go to Piotr Godek and Grzegorz Leopold from PB Polsoft Ltd, and Maciej Dziergwa from AltControl Poland – they provided us a valuable feedback on the ideas presented in the paper. This work has been financially supported by the State Committee for Scientific Research as a research grant 91-0269 (years 2006-2008).

References

[1] Adolph S.: P. Bramble, A. Cockburn, and A. Pols. Patterns for Effective Use Cases. Addison-Wesley, 2002.

[2] Amazon.com online shop: http://www.amazon.com [3] Beynon-Davies P., Tudhope D., MacKay H.: Information systems prototyping in practice.

Journal of Information Technology, 14:107–120, 1999. [4] Cockburn A.: Writing Effective Use Cases. Addison-Wesley, 2001. [5] Fowler M., Scott K.: UML Distilled: Applying the Standard Object Modeling Language.


Addison-Wesley, 1997. [6] Jacobson I.: Use cases - yesterday, today, and tomorrow. Technical report, Rational

Software, 2002. [7] Kieras D.: A Guide to GOMS Model Usability Evaluation using NGOMSL, University of

Michigan (1996) [8] Landay J. A.,Myers B. A.: Sketching storyboards to illustrate interface behaviors. In CHI

’96: Conference companion on Human factors in computing systems, pages 193–194, New York, NY, USA, 1996. ACM Press.

[9] Nawrocki J., Olek Ł.: UC Workbench: A tool for writing use-cases. In 6th International Conference on Extreme Programming and Agile Processes, volume 3556 of LNCS, pages 230–234. Springer Verlag, jun 2005.

[10]Nawrocki J., Olek Ł.: Use-cases engineering with UC Workbench. In K. Zieliński and T. Szmuc, editors, Software Engineering: Evolution and Emerging Technologies, volume 130, pages 319–329. IOS Press, Oct 2005.

[11]Nawrocki J.,Ochodek M.,Nędza T., Olek Ł.: Describing business processes with use cases. In W. Abramowicz, editor, Proceedings of the Business Information Systems Conference, volume P-85 of Lecture Notes in Informatics, pages 13–27. Koellen Druck+Verlag, May 2006

[12]Owen M., Raj J.: BPMN and Business Process Management, 2003. [13]Rettig M.: Prototyping for tiny fingers. Communication of the ACM, 37(4):21–27, 1994. [14]Snyder C.: Paper Prototyping: The Fast and Easy Way to Define and Refine User

Interfaces. Morgan Kaufmann Publishers, 2003. [15]Sommerville Y., Sawyer P.: Requirements Engineering. A Good Practice Guide. Wiley &

Sons, 1997. [16]Walker M., Takayama L.,Landay J. A.: High-fidelity or low-fidelity, paper or computer?

choosing attributes when testing web applications. In Proceedings of the Human Factors and Ergonomics Society 46th Anuual Meeting, pages 661–665, 2002.

[17]http://www.ucworkbench.org

Generating Mockup From Requirements - Semantic Scholar€¦ · Generating Mock-ups from...

Documents

Transcript of Generating Mockup From Requirements - Semantic Scholar€¦ · Generating Mock-ups from...