Extracting and Stating User Interface Prototype Requirements

Introduction

The term Requirements engineering, first used in a study report by Alfor & Lawson (1979), can be defined as the first step in developing an application and involves the process of discovering the purpose of an application, by “identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation” (Nuseibeh & Easterbrook, 2000).

User Interface Prototyping (UIPing) (Connel & Shafer 1989, 1994) is a frequently used method of stating and validating requirements when building a software application. Using this method allows sketching the system’s functionality, design and structure in a way that is easily understood by both the future users and the development team. The User Interface Prototype is created in the requirements engineering phase along with other documents like an application user’s manual, requirements rationale, software requirements specification etc. In a complex project these documents may contradict one another. Because usually the requirements engineers who developed the documents are moving on to other projects, this leaves the implementers with the problem on deciding which document to actually take into account.

To avoid this some preliminary measures need to be taken before starting the User Interface Prototype document. A method of extracting and stating User Interface Prototype Requirements that can be applied in any working environment is described by Ravid & Berry (2000). Alon Ravid has great experience in research, development and management of software development, and holds a bachelor and master degree in Computer Science at the Technion – Israel Institute of Technology in Haifa. Daniel M. Berry is currently a professor at University of Waterloo in Ontario, Canada, and holds a bachelor degree in Mathematics and PhD? in Computer science.

To give a short overview of their method, it has six well-defined steps that can be followed in sequence and if at any time new information appears the affected step is updated and the sequence restarted. In the first phase the process of defining the environment in which the system will work and how it will cooperate with other systems is followed. The second step involves identifying the application domains to which the system belongs (examples of application domains: simulation systems, information systems, data acquisition systems, UI-intensive systems). Then the main features and properties of the application are described and classified by the application domain they belong to. In the final phase the decision of which of these properties should be prototyped is made and the actual User Interface Prototype document is made. The requirements engineers perform these steps in collaboration with the final users and the development team.

The method that Ravid & Berry (2000) proposes is independent of any extra requirement elicitation method used and has the goal to elucidate any questions that may appear in a later phase. This, as their Target Scene Generator case study demonstrates, concludes in better understanding of the project for future developments or even new people that join the project.

Example

In order to exemplify the method we are going to imagine that a retail store needs an application that would track any acquisition from the order to the actual delivery (order management).

Following the method sequence, in the Define the system operational environment activity, a system diagram is created in order to identify the context in which the application will run. By analyzing the diagram the Identify interfaces with other systems activity is performed. Figure 1 is an example context diagram. It outlines that the system is mainly for internal use and has exchange of information with two other internal application. It can also be inferred that it has a component that communicates with the company website to provide important information about the orders to the customers.

After the context has been clearly defined the requirement engineers continue with Identifying the application domains. Because it is built to model information and processes related to a domain or activity we immediately recognize that the proposed solution belongs to the information system application domain.

Table 1 shows an example list of features that can be implemented linked to the application domain and sorted by priority which can help us in making a decision if we are going to immediately prototype it or not. The priority of each feature is of course a result of a series of discussions with both the beneficiary and the development team that can better fix the immediate goals and respectively the problems the team may encounter on the implementation.

The selection for prototyping will be made accordingly by the requirements engineers taking into account the priorities and all of the information received from the development team and users. After a decision has been made on what should be prototyped the actual User Interface Prototype document is created providing task specifications (or use cases), system and interface functionality specifications etc. all verified by the user feedback received from various sources. Figure 2 shows how a deliverable from a User Interface Prototype could look like in a later phase when an actual use case for our system is converted to a screen layout and behavior, which describes the human-computer interaction.

Process-deliverable diagram

A process-deliverable diagram (PDD) is a product of meta-modeling which is used to analyze, store, select and assembly method fragments (Weerd & Brinkkemper, 2008). The main activities and deliverables of the method of Ravid & Berry (2000) is presented in Figure 3. The activities listed in the diagram are all performed by the Reuqirements Engineer(s) but some may need input from the user(s) or developer(s).

The steps of the method are recurrent, so that on any given activity, which has been followed in a sequence, new information could arrive and one could go back to any sub-activity and update the information accordingly (Ravid & Berry, 2000). For readability purposes this has been modeled only at a higher level (activity level), but this applies to every sub-activity and links it with all of the preceding sub-activities.

Table 2 and Table 3 further describes the activities and concepts presented in the PDD.

Related literature

The popularity of User Interface Prototyping has involved a large numbers of papers and books to be published on this subject that analyze the whole process in detail. Card, Moran & Newel (1986) even tries to analyze the whole human-computer interaction part from a psychological point of view.

Still the method with which we generate User Interface Prototypes depends on the “needs” of the application and the current resources. Elkoutbi, Khriss & Keller (1999) suggest an approach for requirements engineering which involves the Unified Modeling Language (UML) for processing a quick specification of the application with limited manual incursion.

For prototyping the requirements, the engineers can use a large spectrum of tools. Szekely (1994) tried to classify them in a list of main categories: the basic paper and pencil prototyping, façade tools, interface builders, model-based tools or domain-specific tools. This does not mean that any tool, which can't be related to the mentioned categories but still manages to facilitate the development of the project, cannot be used.

An alternative to the method we have described in this paper can also be offered by Martinez, Estrada, Sanchez & Pastor (2002). The paper defines the application production process as a link between basic business models and user interface of the system. Using use case models as an intermediary between business requirements and application software, they change them to user interface prototypes using state transition diagrams.

References

• Alfor, M. W., & Lawson, J. T. (1979). Software requirements engineering methodology (development). TRW Defense and Space Systems Group Huntsville AL.
• Card, S. K., Moran, T. P., & Newell, A. (1986). The psychology of human-computer interaction. Lawrence Erlbaum Associates.
• Connell, J. L., & Shaffer, L. I. (1989). Structured rapid prototyping: An evolutionary approach to software development. Yourdon Press.
• Connell, J. L., & Shaffer, L. I. (1994). Object-oriented rapid prototyping. Prentince Hall.
• Elkoutbi, M., Khriss, I., & Keller, R. K. (1999). Generating user interface prototypes from scenarios. In Proceedings of the 4th IEEE International Symposium on Requirements Engineering (pp. 150-158). Washington: IEEE Computer Society.
• Martinez, A., Estrada, H., Sanchez, J., & Pastor, O. (2002). From early requirements to user interface prototyping: A methodological approach. In Proceedings of the 17th IEEE international conference on Automated software engineering (pp. 257-160). Washington: IEEE Computer Society.
• Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: a roadmap. In Proceedings of the Conference on The Future of Software Engineering (pp. 35-46). New York, NY, USA: ACM.
• Ravid, A., & Berry, D. M. (2000). A method for extracting and stating software requirements that a user interface prototype contains. In Requirements Engineering (pp. 225-241). Springer.
• Szekely, P. (1994). User interface prototyping: Tools and techniques. In R. N. Taylor & J. Coutaz (Eds.), ICSE Workshop on SE-CHI (pp. 76-92). Springer.

Appendix