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.
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.
|Feature||Application Domain||Priority||Will be prototyped|
|Allow storing and changing information about current clients||information system||High||yes|
|Allow storing and changing information about supply of items||information system||High||yes|
|Allow storing and changing information about orders and their status||information system||High||yes|
|Allow real time monitoring and filtering of any order||information system||high||Yes|
|Allow real time monitoring of orders by the clients (read-only)||information system||low||No|
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.
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.
|Requirements prerequisites||Define system operational environment||Create SYSTEM STRUCTURE DIAGRAM which shows the environment in which the PROPOSED SYSTEM will run|
|Identify interfaces with other systems||Create CONTEXT DIAGRAM to better identify the interfaces with other systems|
|Identify application domains||Identify with which APPLICATION DOMAIN(s) the PROPOSED SYSTEM shares attributes and list them in the APPLICATION DOMAIN LIST|
|Requirements management||Identify requirements for each application domain||Create a REQUIREMENTS LIST by going through every APPLICATION DOMAIN and analyzing the SYSTEM STRUCTURE DIAGRAM and CONTEXT DIAGRAM|
|Review which requirements are applicable to the current system||Identify the REQUIREMENTS which make sense in the PROPOSED SYSTEM|
|Choose the requirements that are going to be prototyped||Analyze the REQUIREMENTS LIST and choose which will be prototyped in the USER INTERFACE AND REQUIREMENTS PROTOTYPE|
|User interface and requirements prototype||Prototype the user interface and requirements||Create the USER INTERFACE AND REQUIREMENTS PROTOTYPE document(s)|
|PROPOSED SYSTEM||General information about the desired application (Ravid & Berry, 2000)|
|SYSTEM STRUCTURE DIAGRAM||A figure which defines the system's operational environment (Ravid & Berry, 2000)|
|CONTEXT DIAGRAM||A figure which shows how the system communicates with other systems and through what interfaces (Ravid & Berry, 2000)|
|APPLICATION DOMAIN||A domain in which applications share common data, attributes and applications (Ravid & Berry, 2000)|
|REQUIREMENTS LIST||The list of REQUIREMENTS which are applicable to the PROPOSED SYSTEM (Ravid & Berry, 2000)|
|REQUIREMENT||Application information regarding functionality, behavior, constraints, data, taxonomy or any other general knowledge about the PROPOSED SYSTEM and it’s intent. (Ravid & Berry, 2000)|
|USER INTERFACE AND REQUIREMENTS PROTOTYPE||A requirements document which “permits both users and developers to relate to something tangible and to see as concretely as possible the effects of different choices for dealing with problematic requirements” (Ravid & Berry, 2000)|
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.
|Feature||Sub-feature (optional)||Application domain||Priority||Will be prototyped|
|jpg||PDD.jpg||manage||225.8 K||12 Apr 2012 - 21:51||RaresSfirlogea||Figure 3: Process-deliverable diagram|
|vsd||PDD.vsd||manage||132.0 K||30 Mar 2012 - 11:52||RaresSfirlogea||PDD Visio template|
|docx||Peer_Review_Sfirlogea.docx||manage||13.6 K||06 Apr 2012 - 10:57||MarioNarwan|
|ppt||Presentation.ppt||manage||1053.5 K||13 Apr 2012 - 09:06||RaresSfirlogea||Presentation (legacy PowerPoint? )|
|pptx||Presentation.pptx||manage||610.7 K||13 Apr 2012 - 09:06||RaresSfirlogea||Presentation|
|Review_Rares.pdf||manage||765.4 K||06 Apr 2012 - 10:56||MarioNarwan|
|UIRP_3856909.pdf||manage||745.5 K||30 Mar 2012 - 11:50||RaresSfirlogea||Paper|
|jpg||figure1.jpg||manage||65.9 K||17 Feb 2012 - 11:48||RaresSfirlogea||Figure 2: User Interface Prototype for viewing an order|
|review_2.pdf||manage||758.7 K||06 Apr 2012 - 09:20||StevenJol|
|docx||reviewform2.docx||manage||15.7 K||06 Apr 2012 - 09:20||StevenJol|
|jpg||system_structure.jpg||manage||102.1 K||30 Mar 2012 - 11:08||RaresSfirlogea||Figure 1: Context diagram|
|jpg||table1.jpg||manage||91.0 K||17 Feb 2012 - 11:49||RaresSfirlogea||Table 1: Identified features|