Icons: Visual representation to enrich requirements engineering work

This is an electronic reprint of the original article. This reprint may differ from the original in pagination and typographic detail. Author(s): Title: Year: Version: Please cite the original version: All material supplied via JYX is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user. Icons: Visual representation to enrich requirements engineering work Khanom, Sukanya; Heimbürger, Anneli; Kärkkäinen, Tommi Khanom, S., Heimbürger, A., & Kärkkäinen, T. (2013). Icons: Visual representation to enrich requirements engineering work. Journal of Software Engineering and Applications, 6(11), 610-622. https://doi.org/10.4236/jsea.2013.611073 2013 Journal of Software Engineering and Applications, 2013, 6, 610-622 Published Online November 2013 (http://www.scirp.org/journal/jsea) http://dx.doi.org/10.4236/jsea.2013.611073 Open Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work Sukanya Khanom, Anneli Heimbürger, Tommi Kärkkäinen Department of Mathematical Information Technology, University of Jyväskylä, Jyväskylä, Finland. Email: [email protected], anne[email protected], [email protected] Received October 16th, 2013; revised November 10th, 2013; accepted November 17th, 2013 Copyright © 2013 Sukanya Khanom et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. ABSTRACT Adapting icons in requirements engineering can support the multifaceted needs of stakeholders. Conventional approaches to RE are mainly highlighted in diagrams. This paper introduces icon-based information as a way to represent ideas and concepts in the requirements engineering domain. We report on icon artifacts that support requirements engineering work such as priority types, status states and stakeholder kinds. We evaluate how users interpret meanings of icons and the efficacy of icon prototypes shaped to represent those requirements attributes. Our hypothesis is whether practitioners can recognize the icons’ meaning in terms of their functional representation. According to the empirical data from 45 participants, the findings demonstrate the probability of providing users with icons and their intended functions that correspond to RE artifacts in a novel yet effective manner. Based on these findings, we suggest that icons could enrich stakeholders’ perception of the RE process as a whole; however, meaningful interpretation of an icon is subject to the user’s prior knowledge and experience. Keywords: Requirements Engineering; Icon; Culture; Stakeholder; Visual Language 1. Introduction The growth in sophistication of human-computer interaction (HCI) can be seen in graphical user interfaces (GUIs) [1,2]. These interfaces have significantly reduced the amount of typing needed when using a computer. Nowadays, icons are important visible representations of information. They range from device control and icons in public to iconic communication systems assisting some particular areas [3-7]. The use of icons to reflect objects or actions is not new in modern computer-aided systems or software packages. The icons era in interface and screen design began with the Xerox Star computer in the 1970s and thoroughly bloomed with the onset of Apple Macintosh in the mid-1980s. GUI rapidly turned into the paramount user interface when Microsoft adopted variation of icons with its Windows system [1,2,8]. Because of the increasing presence of icons within computer-intensive communication, it is necessary to consider how icons are interpreted and the factors that influence their effectiveness. In addition, because icons are frequently used to supplement texts and overcome language barriers, this makes the ability to recognize and comprehend icons even more complex. In particular, in requirements engineering (RE) the adaptation of appropriate icons can be difficult. The RE process typically involves collaborations of people with different backgrounds, roles and responsibilities, so different that they appear to speak different languages and apply different approaches for the desired outcomes [9-11]. Recently, dozens of requirements methodologies and techniques have been implemented and made available for practitioners. However, the empirical evidence repeatedly reveals that RE is considered as one of the key contributors to the failure of software [12,13]. This position creates a challenge for researchers to find an uncomplicated and easy-to-learn method that can enhance requirements activities, reduce ambiguity and promote collaboration. Even though icons have been accepted successfully in HCI, information on the utilization of icons in RE is scarce (e.g. [14]). Our attempt is to refine icon-based information to support the tasks of RE stakeholders and to clarify how readers recognize connotative meanings of icons, that is, what the icon is intended to represent. There may be numerous approaches to solve the problems encountered in Icons: Visual Representation to Enrich Requirements Engineering Work 611 RE. This paper introduces one such approach with the help of the following key concepts: cultural aspects, RE artifacts and icon-based information. The cultural aspects assist in building a cultural user framework with culturally adaptive user interfaces that adapt themselves to the user’s background. RE artifacts provide a skeleton for the scenarios of requirements activities that can be characterized by icons, such as attributes, stakeholders and relationships. Attributes are the properties that distinguish one requirement from another, and they establish a context and background for each requirement. Stakeholders are the persons or systems that have the purpose of achieving goals and that take action to achieve them. Relationships signify the correlation between two or more requirements. All RE artifacts are patterned as static elements. This type of patterning means that all users visualize requirements features or functions in the same manner. Icon-based information is designed in visually supporting pieces of RE artifacts that go beyond an ordinary textual description. Unlike RE artifacts that are stationary, icon-based information is dynamic depending on the users’ cultural background. The deviation of icon presentations specific to cultural preferences can be seen for example, in how the attached icon for high priority is illuminated. Users from Europe might experience the interface with purple-colored icons, but users in Asia may contemplate the interface with yellow-colored icons [15]. To the best of our knowledge, icon-based information is the first approach that tries to represent icons in RE and that is able to adapt its interface to the preferences according to the user’s cultural background. Our research question explores how well practitioners can predict the meaning of icon representations. To answer this question, this paper evaluates icons that represent priority types, status states, stakeholder kinds and relationships. In our study, icon-based information was tested with 45 participants from Finland. Our findings have the potential to inform the development of unambiguous requirements and avoid the aforementioned problems. Consequently, our contributions are as follows: First, we present a theoretically grounded approach for icon-based information in RE and adapting its interface by cultural background. We propose a cultural user framework to approximate a person’s cultural preference and intertwine RE artifacts with their prospective iconic representations. Second, we empirically evaluate those icons’ meaning and demonstrate whether icons are able to characterize RE artifacts. We expect that the role of iconic information used in RE could facilitate the work of business users and software developers in all phases, from elicitation and negotiation to validation. In the following section, we introduce the previous work on which we have based our method for designing a concept of icon-based information. In Section 3, we describe our research approach. We develop three artifacts that demonstrate the approach and in Section 4, we describe its stepwise nature. In Section 5, we describe an empirical evaluation of icon-based information. Next, we discuss our results and recommendations for improvement. Last, we propose future work and present our conclusions. 2. Related Work We review the relevant work on three questions: What prominent methods are regularly employed in RE? What icon applications already exist? How can we understand how cultural aspects affect icon perception? 2.1. The Nature of Iconic Communication in RE and Other Environments The de facto standard of visualization techniques that have broadly converged in RE are diagram and graphical, such as Unified Modeling Language (UML) and goaloriented models. UML is one of the conceptual modeling tools in software engineering to represent static and dynamic phenomena of user requirements [16,17]. The goal-oriented model is a paradigm for eliciting, evaluating, elaborating, documenting and analyzing software requirements [18,19]. Nevertheless, the empirical evidence (e.g. [14,17,20]) has revealed some shortcomings of these techniques, such as the problematic use of abstract shapes that have articulately conventional meanings which must be learnt. Iconic visualization is one modality recommended to be employed in enhancing cognitive effectiveness for RE notation [14]. However, the applicable icons in RE can be considered because they are pervasively used in toolbars and menu bars, but not in the requirements engineering context itself. Over the decades, icons have been at the center of human-computer interaction (HCI). While concrete icons are believed to be effective in graphical user interfaces, abstract icons are judged to be less effective because they do not represent real-world objects [21]. Interface designers repeatedly use concrete icons because of the strength of their relation between icon and function. Notwithstanding, abstract icons can also be utilized in the interface as they strengthen icon-referent relations by producing a less pictorial representation that is meaningful to the user [21,22]. Within the domain of HCI, the methods of cognitive psychology are commonly followed (e.g. [14,23,24]). The cognitive factors of icons embody the cognition of visual information and the association of connection. The effects on user cognition are based on a range of characteristics such as color, shape and size [25]. By improving the usability of icons, the hope is to improve the interactive interface between peoOpen Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work Open Access JSEA 612 ple and machines. In crisis situations, icons have been exploited in facilitating auxiliary communication among multifaceted users [26,27]. Icon-based communication interfaces have been developed to represent concepts and ideas in crisis environments by providing icons such as explosion, victim, and ambulance that for a crisis observation interface. Those icons are created to conform to ontology-based knowledge, W3C-OWL [28], by defining a case for each icon; the icon victim contains number, location, and status, for instance. This crisis observation interface provides iconic symbols, geometrical features or icon strings. Geometrical shapes, such as arrows, lines, ellipses, and rectangles, can be used to indicate a distinctive area, an object, an event, or a location. 2.2. Cultural Influences on Iconic Perception Culture has a crucial role in the use of information and communication technology. Information system research has long admitted that cultural difference can inhibit the successful use of information technology [15,29-31]. The major finding from the existing literature on cultural differences and icon recognition is that there are differences of modality that groups of users have regarding what icons are. Cultures have different degrees of contexts: some cultures are determined to be high context whereas others are considered to be low context. Context refers to the amount of information given in communication. In high-context communication, most of the meaning is in the context. By contrast, in low-context communication, most of the meaning is in the transmitted message. Problems and conflicts emerge when people from highand low-context cultures communicate with each other [32]. The differences have mostly been considered on national or organization levels. We distinguished the characteristics between countries based on cultural theories (e.g. [15,29,33]). Hofstede has distinguished five dimensions of power distance (PDI), individualism (IDV), masculinity (MAS), uncertainty avoidance (UAI), and long-term orientation (LTO). Power distance, for example, describes the extent to which the hierarchies exist and are accepted by the members in a society. Within countries (e.g. Thailand) that have been assigned a high power distance score, inequalities are believed to be much more acceptable in society than in low power distance countries (e.g. Finland and Australia). The people in highly individualist countries (e.g. Finland and Australia) are usually seen as more independent from a group. In contrast, people in collectivist countries (e.g. Thailand) often see themselves as part of a group. The third dimension, masculinity, refers to a high preference for competitive achievement (high masculinity) versus low preference (femininity). The degree to which the members of society tolerate uncertainty and ambiguity is inversely reflected by UAI, that is, people from high uncertainty avoidance countries prefer less ambiguity than those in low uncertainty avoidance countries. The fifth dimension, long-term orientation, measures how people perceive time. In LTO countries, people are comfortable with sacrificing for long-term benefit, but in countries with short-term orientation people are more focused on immediate results. In Table 1, we have summarized the rules for a cultural interface based on Hofstede’s theory and human-computer interaction components such as color, appearance and contents [15,29,33-35]. The table lists the influences as high or low scores. 3. Research Approach We employed the research methodology of design science [36,37] to construct icon-based information in RE context (see Figure 1). We operationalized our three research problems (see number 1 in Figure 1). First, requirements identification means the challenges of the capability of a system’s stakeholders to express their needs concisely and concretely. In other words, we can say that requirements are difficult to capture in the situation where there is a communication gap in RE between business teams and development stakeholders. Secondly, requirements complexity refers to the difficulty of understanding, communicating and reviewing the requirements. Thirdly, requirements volatility refers to the stability of requirements, which are easily changed as a result of environmental dynamic or individual learning. We then defined solid objectives to inform a potential solution to the aforementioned problems (see number 2 in Figure 1). Our aim is to find a solution that benefits Table 1. Relations between five dimensions and user interaction design variables. Low score High score PDI Less structure data Supportive message Informal representative Complex structure data Strict error message Formal representative IDV High context Colorful interface Low context Tediously colored interface MAS Multiple choices/tasks Social structure (relationship orientation) Limited choice/task Business structure (goal orientation) UAI Complex information Abstraction representation Simple/precise information Daily representation LTO Tolerance complex communication Preference for friendly communication Icons: Visual Representation to Enrich Requirements Engineering Work 613 Figure 1. Design science research methodology. RE stakeholders, particularly in multicultural environments. Large diversity in the cultural backgrounds of stakeholders makes it indispensable to find ways easily adapting interaction. For this adaption process, iconbased information has three benefits. The first benefit is to enable business users to specify and communicate requirements. The second benefit is to support system analysts or requirements engineers to prioritize and resolve conflicts. The third benefit is to enable RE stakeholders to investigate changes in requirements and to continue tracking the requirements life cycle. At the design stage (see number 3 in Figure 1), the key insights of our approach can be obtained by defining cultural user aspects, elaborating RE artifacts and refining icon artifacts. The details of these three artifacts are described in the next section. We inferred the necessities for our artifacts by drawing on theoretical foundations in the interdisciplinary fields of RE, human-computer interaction, and cognitive psychology. We further combined knowledge and techniques from the research fields of modeling languages and iconic communication in order to make design decisions that principally affect the direction of our approach. In the evaluation phase (see number 4 in Figure 1), we conducted two iterative evaluations: one with student users and another with expert users. The first iteration was tested by students in the RE course of the Department of Mathematical Information Technology at the University of Jyväskylä. The results of students from the first iteration are detailed in Section 5. For the latter iteration, software companies in Thailand and Finland (including Australia, if possible) will be the notable key players. We took advantage of usability testing to evaluate if a defined icon-based language supports the tasks of RE stakeholders. The results of these two iterations will be used to inform improvement possibilities. 4. Designing for Icon-Based Information in the RE Domain 4.1. Modeling Requirements Engineering We established a list of RE artifacts to support multicultural environments. It is focused on delineating potential activities that affect the entire RE process and that help diminish ambiguity and misinterpretation. Figure 2 shows an example of how the central concept of requirements artifacts is in relation to stakeholders, attributes, relationships and taxonomies. Each requirement is proposed by a stakeholder and thus it is essential to record information about associated stakeholders. We categorized the requirements into groupings (a taxonomy) to facilitate better organization and management. The eight types were created in order to tackle software quality and development process quality [38]. Business requirement is an abstraction level that reflects a goal or vision of the organization. Business requirements may contain functional requirements that present the behavior of a system under specific conditions. Otherwise, the level also includes non-functional requirements that represent a quality attribute the system must have, such as reliability, usability, efficiency, maintainability, or portability. A requirement may be appended with business rules, laws, policies, or procedures which constrain the degree of freedom in delivering a solution. The importance and urgency (priority) assigned to every individual requirement helps moderate imprecise conflicting requirements and assist the development team in identifying the core requirements. A requested requirement must be assigned one out of five priority levels. A “very high” priority is both important and urgent, a “high” priority is important but not urgent, a “fair” priority is neither important nor urgent, a “low” priority is neither important nor urgent and can wait for the next release, and a “very low” priority is for when the requirement can be delayed for the next release or not implemented. A preference score is attached to the initialized requirement. It stands for the degree of preference or satisfaction of the requirement for each stakeholder. The score, arranged by each stakeholder, can be used to inspect the similarity of detected overlap among stakeholders. The classification of several statuses is more meaningful to help stakeholders monitor the progress of each single requirement throughout development process: Open Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work 614 Figure 2. Model of requirements management with relevant attributes. “Propose” when the requirement has been initialed by an authorized source; “Accept” when the requirement is analyzed and key stakeholders agree to incorporate such requirement; “Reject” if the requirement is proposed but it is not planned for implementation; “Implement” when designing, writing and testing the source code that implements the requirement, and “Verify” when verifying for the correct functionality of implemented requirement. The existence of a relationship between two or more requirements presents and reasons taxonomy of traceability. The requirements can be associated to each other through the link types: dependency or parent-child. Three relationships of dependency (require, refine, and conflict) have been delineated to qualify the association between two or more requirements. Additionally, one requirement can be divided into sub-requirements and those sub-requirements are connected to their parent with a parentchild link. The requirements engineer can use two types corresponding to a logical combination—one is ANDparent-child and the other is OR-parent-child. With an AND relationship, unless all sub-requirements are satisfied, their parent requirement cannot be satisfied. On the contrary, with an OR relationship, a parent requirement could be satisfied when at least one sub-requirement is satisfied. 4.2. Modeling Icon-Based Information Although many visual features (e.g. size, shape and color) have been allocated to aid the recognition, it is now acknowledged that the correlation between recognition and interpretation also plays a crucial role [39,40]. Interpreting and comprehending a single icon is the simplest process of reading iconographic communication, but when icon interpretation occurs in isolation, it makes icon interpretation too complex [39]. Currently, the outstanding icon characteristic that has received the most attention is icon concreteness. In this characteristic, icons are used to represent real-world objects because they happen to convey meaning accurately [23,39]. Abstract icons, in contrast, represent information using visual features such as shapes, arrows, and colors. We propose that the RE context cannot be wholly represented with concrete icons. As a consequence, we decided to combine concrete and abstract icons to represent RE artifacts. This combination is a plausible reason for making iconbased language scalable, so that a single icon may share the same semantic system. In Figure 3, we depict an icon-based ontology. First we need to derive the icon library of a visual notation being designed to attach to the requirement itself, requirements process and user interface. The main element is the class Icon-based Information which defines icon characteristics. To benefit scalability and variability, we build libraries for Icon-based Information into two categories: separated and shared icon libraries. A MainLib acts as a centric base and will store all icons that can be shared among other three Libraries. UILib mainly collects icons that will be utilized for user interface whereas ProcessLib serves icons that associate to the process output. Likewise, AttributeLib provides icons related to attributes that can be adhere to every requirement. Icons in these four libraries must be design in accordance with cultural aspects of Hoftede’s dimensions. Other four subclasses are: Position which characterizes the icon orientation in X and Y axis, Size which exemplifies icon size including 1D iconic elements (lines), 2D iconic eleOpen Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work 615 Figure 3. A set of icon classes and variables. ments (areas), and 3D graphic elements (volumes), Style which typifies the color and shape, and Link which symbolizes link property such as curve and dashed lines. For each icon notation that has to be conducted, we must generate a final library. The library contains the series of iconic symbols for both abstraction and concreteness, and visual sentences that symbolize the icon notation. When designing iconic symbols, guidelines and standards such as ETSI EG: 202-048 [41] and ISO/IEC 11581 [42] can guide us to the applicable design for a particular purpose. Since the interpretation of icons is subjective, the icons should be properly selected, developed and evaluated. Therefore, we applied the ETSI EG 201-379 [43] framework so that its direction would ultimately solve such a challenge. To solve the problems of misinterpretation and cultural prejudice, the test participants were chosen to include different nationalities. Next, we refined the syntax specification of the iconic symbols in accordance with the attribute-based representation approach, which must conform to the criteria for proper visual syntax. When it is grounded in the attribute-based tactic, the grammar of icon-based language can be classified, depending on the structure of its iconic objects, in the way they can be composed in order to form a visual sentence. The criteria for good visual syntax are based on cognitive effective psychology [14,23, 24]. They mainly point to the essential characteristics of icons that must be taken into consideration, for instance, familiarity, concreteness, complexity, meaningfulness and semantic distance. All stages in icon-based language design are iterative [44,45], which means that if tests expose usage drawbacks, we might decide to review the libraries as well as to replicate the usability testing in the next version. Our limitation is the fact that all visual vocabularies in this paper were gathered from existing ones and only used to represent concepts and ideas. At this state we are not concerned with their appearance regarding what they are representing. The design perspective must be taken by the designers who are experts in the area. Design relies enormously on cultural experience and cognitive effectiveness. 4.3. Modeling Cultural Aspects In combination with cultural geographic aspects, we have based our cultural theoretical aspects on those refined in a number of sources [30,31,34]. We focused on extracting the aspects of culture that impact icon usage by conducting a systematic literature review of related work from the interdisciplinary fields of human-computer interaction, cognitive psychology, and RE. As shown in Figure 4, all of these cultural aspects are rudimentarily defined in the web ontology language (OWL) [28]. OWL gives an advantage in that it is an extensible way to represent uniquely identified objects that can be asserted across various users and agents [46]. The focal concept in cultural aspects is the Person class together with its subclass of Female and Male. The Person class further connects to the classes Education Level, Religion and Computer Literacy. Data type properties of the range integer record the five national dimensions. To model the cultural influence of different nationals, the ntology composes the object property, has Nationatlity. o Open Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work 616 Figure 4. A set of cultural components that govern icon-based interface adaptation. The ontology also pertains to Country class, which contains individuals of all continents and countries, but in the beginning we have focused on only three countries (Thailand, Finland and Australia). Likewise, the ontology has been complemented with the class has Experience, which provides us with information about a user’s RE knowledge and skill. No # Month class is inherited to has Expereince class in order to provide a validated series of months. In this paper we have not yet implemented this ontology. Instead we have drawn upon the theoretical framework to derive a cultural conceptual process for executing the first empirical evaluation by students in RE course at the University of Jyväskylä, Finland. This framework can be further improved and developed for icon-based information adaptivity to specify different icon preferences that correspond to cultures. Figure 5 illustrates the convergence of three main artifacts—cultural user framework, RE artifacts and iconbased information—to achieve an icon-based information adaptivity process. First, it is necessary to build a user framework on cultural particularities before the adaptation can be achieved. The idea is that the register process elicits the users’ background by taking into account various influences that affect a user’s iconic preference, such as their nationality and work experience. This information is passed on and stored in a cultural user framework (CUF). A CUF acts as a knowledge base about each user and inherited rules that trigger the adaptation of the icon-based interface. When the user framework is used for the first time, the user needs to provide information in a short questionnaire arranged by an application. This acquired information helps to manage the icon-based information for the user according to that user’s national preference. The application receives the cultural dimensions for each Figure 5. The process for icon-based adaptivity. user’s nationality from the CUF. The application retrieves the RE features and the embedded iconic features that corresponded to the user’s background information. The icon-based interface is tailored to the user on the basis of adaptation rules. For instance, if a user has a high score in UAI, then an interface with very simple, clear imagery and limited choice is provided. Since icon-based information for RE that can adapt its appearance differently among cultures is a novel approach, its design can be partly applied from cultural adaptivity [47] that involves the refinement of interface preferences. Users can interact with this application (MediaWiki), which is enabled to access the cultural user framework. Users can also explicitly add or modify information in their personal user registration. This, in turn, triggers adequate adaptations that change the icon information of the user interface. 5. Experiments In this section we report on our summative evaluation of Open Access JSEA Icons: Visual Representation to Enrich Requirements Engineering Work 617 the ability of icon-based information for RE to adequately adapt to varying requirements scenarios. The evaluation was carried out to ensure that icons are effective and usable. Icon usability testing was conducted to assess the degree to which the graphic chosen for the icon represented the intended concept, so-called icon intuitiveness [39]. The study focuses on participants with a Finnish cultural background. 5.1. Participants To evaluate the cognition of icon-based information for requirements engineering by diverse participants, we invited students attending a Requirements Engineering course at the University of Jyväskylä to participate in the study. Some of them were studying the subject for first time and some already had experience in software engineering. A total of 45 students took part in this study: 14 novices, (0 years of experience) and 31 experts (an average of 1.2 years of experience). Each student completed three testing dimensions: individual icon interpretation, multiple icon interpretation and compound icon construction. 5.2. Test Apparatus A web-based survey, a common instrument for gathering information from participants, was set up for the empirical evaluation. The icons were presented to participants on webpages. The website consisted of three primary sections: background information, a form for personal information and the icon test. Each test contained an explanation that helped users to complete the task. 5.3. Procedure Prior to the real execution of tasks, we briefly explained to participants the purpose of the testing, the amount of tasks they needed to complete and the step-by-step interaction. In addition, iconic symbols were chosen from a variety of sources in order to ensure that they were representative of the icons that are currently well-known in the broad spectrum of RE artifacts. These included the use of norms from standards such as ISO/IEC-11581 [42]. All the selected icons were abstract ones with predictable meanings. However, we selected the icons that could be simply interpreted and recognized without requiring prior knowledge. For this study, our selection consisted of 14 icons, including 5 icons for priority, 5 icons for status, and 4 icons for stakeholder type. Throughout the experiment, participants were encouraged to interpret the icons from the details they were given. The empirical survey ended with a small questionnaire that gathered feedback and comments on icon-based information in RE. Participants completed three series of tasks. For examples, see Figure 6. 5.4. Preliminary Result 5.4.1. Individual Icon Interpretation The requirements life cycle diagram, which consists of five blanks (see Figure 6(a)), was delivered to all replies, in conjunction with icons that resemble all five stages of the requirements life cycle: Propose, Accept, Reject, Implement and Verify. The participant selected the most correlated icon and dropped it into every single blank stage. The number of accurate selections per stage varied from 52% to 94%. 5.4.2. Multiple Icon Interpretation We categorized the iconic symbols into three requirements attributes: five status states, five priority types and four stakeholder kinds. Each respondent mapped icons to their corresponding meaning from two lists (see Figure 6(b)): one list of icons and another list of meanings. Table 2 presents the outcomes for interpreting the icons and their meaning for three distinct categories. 5.4.3. Compound Icon Construction The icons were also used to represent requirements type symbols and relationships imitating the concept of a goal-oriented model (see Figure 6(c)). We offered four types (business requirement, functional requirement, non-functional requirements, and constraint), four relationship symbols (Refine, Require, AND and OR), and five priority symbols (Very high, High, Fair, Low and Very low). Each respondent constructed the iconic sentence according to the statement. The correctness of iconic constructs achieved a prediction accuracy of approximately 84%. 5.5. Role of Experience The expected outcome of this study was that practitioners would be able to recognize the iconic symbols representing RE artifacts, such as stakeholders, attributes and relationships. From the results, we observed that icons were interpreted very well. The average correct prediction accuracy was more than 50 percent. This finding informs our direction to explore improvement possibilities of icon-based information. The individual icon testing revealed that the participants’ capability to answer the status states required prior knowledge and experience of the requirements life cycle and the interaction that takes place during the process, from the beginning of proposing to the end of verification. Training before taking part in this test would probably assist the respondents in understanding the basic elements of RE. The multiple icons testing showed that a participant’s interpretation depended to some extent on their conventional knowledge. For example, participants who have children might perceive a baby carriage as high priority. There was also Open Access JSEA