Portal de Periódicos da CAPES

Artigo Acesso aberto Produção Nacional Revisado por pares

BIBTEX RIS

Why use case specifications are hard to use in generating prototypes?

2019; Institution of Engineering and Technology; Volume: 13; Issue: 6 Linguagem: Inglês

10.1049/iet-sen.2018.5239

1751-8814

Ana Carolina Oran, Natasha Valentim, Gleison Santos, Tayana Conte,

Advanced Software Engineering Methodologies

IET SoftwareVolume 13, Issue 6 p. 510-517 Research ArticleOpen Access Why use case specifications are hard to use in generating prototypes? Ana Carolina Oran, Corresponding Author Ana Carolina Oran ana.oran@icomp.ufam.edu.br orcid.org/0000-0002-6446-7510 Institute of Computing, Federal University of Amazonas, Manaus, BrazilSearch for more papers by this authorNatasha Valentim, Natasha Valentim Department of Informatics, Federal University of Paraná, Curitiba, Paraná, BrazilSearch for more papers by this authorGleison Santos, Gleison Santos Federal University of the State of Rio de Janeiro (UNIRIO), Rio de Janeiro, BrazilSearch for more papers by this authorTayana Conte, Tayana Conte Institute of Computing, Federal University of Amazonas, Manaus, BrazilSearch for more papers by this author Ana Carolina Oran, Corresponding Author Ana Carolina Oran ana.oran@icomp.ufam.edu.br orcid.org/0000-0002-6446-7510 Institute of Computing, Federal University of Amazonas, Manaus, BrazilSearch for more papers by this authorNatasha Valentim, Natasha Valentim Department of Informatics, Federal University of Paraná, Curitiba, Paraná, BrazilSearch for more papers by this authorGleison Santos, Gleison Santos Federal University of the State of Rio de Janeiro (UNIRIO), Rio de Janeiro, BrazilSearch for more papers by this authorTayana Conte, Tayana Conte Institute of Computing, Federal University of Amazonas, Manaus, BrazilSearch for more papers by this author First published: 01 December 2019 https://doi.org/10.1049/iet-sen.2018.5239Citations: 1AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Requirements communication is essential in software development projects since customer needs must be communicated to the development team clearly and effectively. Although the use case (UC) specifications are used to communicate requirements in detail, developers do not always follow them. This study presents an empirical study carried out to understand the reasons why developers do not follow UC specifications and their difficulties using UC specifications in generating prototypes. Results show that the four reasons why developers fail to follow UC specifications are the existence of specification errors, ambiguous information, lack of detailed specification, or incomplete information, and due to improvement suggestions. Also, the specification defects types that impacted prototypes creation the most were an omission, ambiguity, and incorrect fact. The authors noted that 6 out of 25 (24%) defects in the UC specifications caused discrepancies in prototypes, 12 (48%) were corrected during the prototypes creation, and 7 (28%) were not propagated to the prototypes. 1 Introduction Requirements communication is essential in all software projects, given that during the entire cycle of the software development process there is a constant need to understand the requirements and auxiliary information associated to them [1]. Requirements communication starts with the requirements elicitation with customers and continues throughout the entire development project, involving different roles [2]. During the requirements engineering process execution, customers must be able to communicate their needs to requirements analysts which need to be able to communicate these requirements to all the other members of the development team clearly and effectively. Tu et al. [2] and Fernández et al. [3] state that both customers and software professionals have difficulties related to the validation and understanding of the information resulting from the requirements specification. Good communication does not only mean specifying all the requirements but also ensuring that requirements are understood by all team members. According to Hoisl et al. [4], the way how the requirements are described can influence the effort required to understand what should be developed. It is important to represent the requirements in such a way that all involved stakeholders can establish a common understanding of the system functionalities so that the final product developed attends customers' expectations. System requirements can be represented in different ways, from free texts to more structured forms. Requirements communication problems may arise due to the chosen specification model [5]. Use cases (UCs) [6] are widely used by industry to represent requirements [7, 8, 9]. UCs, in addition to describing requirements, are used as a means of communication between project team members and other stakeholders [10]. Prototypes are graphical representations of user interfaces [11]. To identify the needs, developers have to create prototypes and their difficulties to create prototypes based on UC specifications, this paper presents an empirical study conducted with undergraduate students who played the role of developers. We investigated why developers modify, insert, or do not represent information from the UC specifications when creating prototypes. To guide the research, we defined the following research question: 'What difficulties do developers face to create prototypes from UC specifications?'. Besides the research question, we also want to understand the reasons why developers do not follow UC specifications. The remainder of this paper is organised as follows: Section 2 presents concepts about requirements specification, and UCs, and related work. Section 3 describes the planning and execution of the empirical study. Section 4 presents the analysis of the results. Section 5 presents the discussion and the threats to the validity of the study. Finally, Section 6 presents conclusions and future work. 2 Software requirements specification Bjarnason et al. [12] state that requirements specifications are used for different purposes and support the main activities associated to obtain and validate stakeholder requirements, software verification, tracking, and management of requirements, and for contractual purposes through the documentation of customer agreements. There are different ways to represent software requirements and the choice by one of these forms depends on factors such as team experience and the visibility of these requirements [13]. The following is a brief description of how to represent the requirements. 2.1 Use case UC specifications [13] describe and document software requirements. According to Cockburn [8], UCs comprise sequences of interactions between a system and one or more actors (agents external to that system), representing a usage report of some functionality of a given system, without revealing the structure and behaviour of this system. UCs were originally proposed by Jacobson et al. [14] as a way for software professionals to gain a better understanding of the requirements of a system. Tiwari and Gupta [13] state that there are different ways to represent UCs and that they can be specified in different structures. One of the structures widely used by requirements engineers is the structure proposed by Phalp et al. [15], which is focused on describing the main and alternative flows (AFs) of events: UC name, UC description, preconditions (optional), main flow (MF), AFs, exception flows (EFs), post-conditions (optional), and business rules (BRs). This predefined structure facilitates the understanding of the functionality [16] and fosters software engineers flexibility in specifying the requirements [13], thus helping requirements communication within development teams. 2.2 Related work Oran et al. [17] carried out an exploratory empirical study to compare the requirements communication dynamics from UC specifications and user story as the basis for mock-ups creation. According to the mock-up inspection results, UC specifications led to more defects to build mock-ups than user story specifications. After inspecting the specifications, the authors found the UCs presented fewer defects than the user stories. However, the quantity and impact of the defects on the final result are not sufficient to determine which specification form is better or worst for communicating requirements among software development members. Results showed that there is no significant difference that supports choosing one form of specification over the other. So, from this point of view, software development teams who are in doubt about which form of the specification to adopt can use either user stories or UCs. Tu et al. [2] state that the use of more transparent documents, with greater visibility of information to stakeholders, can contribute to more effective communication. They conducted an experiment that showed evidence that higher transparency of requirements documents leads to more effective communication. Liskin [18] conducted a study in order to verify how requirements artefacts can support the activities related to requirements communication and requirements engineering. She also applied interviews with 21 practitioners in order to check how the team members with different functions and different informational needs of requirements used the artefacts. The results pointed out that each development team member has different informational needs to perform their activities. For instance, architects have difficulty making architectural design decisions due to lack of crucial information from architectural differentiators in an UC specification [19]. Although these papers focused on problems and solutions in the use of requirements specification documents for requirements communication among team members, they did not intend to assess the problems faced by developers while carrying out their activities. It is worth emphasising that if developers do not understand the requirements properly the system might not meet the customers' needs. 3 Empirical study To investigate developers' needs regarding requirements information, we conducted an empirical study to identify the difficulties they face to create prototypes using UCs specifications. This section describes the study plan and execution. 3.1 Empirical study planning We planned the empirical study from the research question in order to evaluate the reasons why developers do not follow UC specifications and their difficulties using UC specifications in generating prototypes. 3.1.1 Participants We carried out the study in an academic environment with 14 undergraduate students from the Information Systems course at the Federal University of Amazonas, enrolled in Introduction to Software Engineering class. The participants were characterised as novices, as they had only academic experience with UC specifications. Only one participant had development experience in the industry. The participants played the role of developers in this paper, as they received UCs specification to create prototypes, thus simulating the system initially. 3.1.2 Artefacts All participants signed an informed consent form, in which they agreed to provide their results for analysis. We used the following artefacts to perform this study: (a) form to characterise participants' familiarity with UC specifications and their experience developing software; (b) problem scenario and three UCs textual description; and (c) questionnaire to evaluate the requirements communication. The questions in the questionnaire were: Did you have any difficulties extracting information from the specification to build the prototype? Did you note the lack of information in the specification that you needed to build the prototype? Did you modify or inferred any part of the specification to create the prototype? Considering all specifications received, please review and classify all the items indicated as required (i.e. the item was necessary to create the prototype) or not required (i.e. the prototype could have been created without the item). The items are UC name, UC description, actors description, UC precondition, MF, AFs, EFs, BRs, messages (MSGs) to users, system's screen fields, and navigability. Did you miss in the specification received any information necessary to build the prototype? Did you miss in the specification received any information related to the screen layout? We used part of an industry project specification regarding a document management system to prevent documents from running out of their validity and causing business expenses such as fines and stoppages. We presented the following scenario: 'The whole process of the company's legal documentation control is carried out through using a spreadsheet, where information is updated manually. This document management model can result in potential risks such as the expiration of some important fiscal document for the company's compliance with tax authorities. It was detected that there is no mechanism that alerts the sector or person responsible for regularising the documentation, causing expenses with fines, interest etc. Therefore, it is necessary to develop a new system for managing the company's documents to avoid them to run out of their validity and cause the company expenses (fines and stoppage of activities). Fig. 1 presents an excerpt from the UC 'UC01 – Maintain department'. Fig. 1Open in figure viewerPowerPoint UC UC01 – maintain department 3.1.3 Training All participants were already familiar with UC specifications. Therefore, participants were trained on prototyping only, so they could gain insight into how to create prototypes with MSG details, BRs, and navigation, thus simulating the system development. The training session lasted 2 h and comprised of practical exercises. 3.1.4 Prototypes inspection To identify discrepancies inserted into the prototypes, the researchers used an inspection form based on Travassos et al. [20] as shown in Table 1. The task was carried out in two stages. In the first stage, a researcher evaluated the prototypes created by the participants from the UC specifications. In the second stage, two researchers reviewed the identified discrepancies to decide which ones were real defects or false positives. Table 1. Classification of discrepancies (based on [20]) Category Description Example omission information present in the specification but not in the prototype specification says 'The client selects the 'Save' option' but there is no 'Save' button in the prototype incorrect fact information described in the specification but represented into the prototype in another way specification says 'The client selects the 'Save' option' but the button in the prototype is labelled 'Insert' extraneous information information present in the prototype but not in the specification specification includes a 'Save' option only but the prototype has 'Save' and 'Cancel' options inconsistency information contained in one part of the software artefact is inconsistent with other information in the software artefact fields 'age' and 'price of the movie entrance' in the prototype are both dependent on the birthdate inserted. However, the 'age' does not match the birthdate inserted ambiguity information is described in the specification clearly but inserted into the prototype ambiguously, i.e. it is possible that clients, developers or testers interpret the information in different ways there are buttons with the same name, fields with the same description or without navigation between the screens in the prototype. Button name or field without clear objective: the button's name is 'OK' and should be 'Save' — — — 3.1.5 Specification defects The specifications had 25 defects: 12 real defects committed by the requirements analysts who specified the UCs, and 13 new ones inserted by the researchers. We included the new defects so all categories of defects in Table 1 would be present in the specification. Therefore, we would be able to verify whether the defects in the specifications would impact the prototypes creation. We did not add the same number of defects in the UC specifications to avoid the bias generated by students who wanted to find the same defect quantity in each UC specification. Table 2 shows the defects in the three UC specifications. Table 2. Defects found in the specifications Id Defect Description Source UC1_D1 ambiguity EF2 says a document cannot be deleted if it is associated with another document but the business rule says the other way around researchers UC1_D2 incorrect fact actor associated to UC should be an administrator, not a student business analyst UC1_D3 incorrect fact AF3 should be classified as an exception flow rather than an alternative flow researchers UC1_D4 inconsistency BR1 should mention departments registered, not documents registered. UC1 refers to departments, not documents business analyst UC1_D5 extraneous information MSG6 is not used in UC1 business analyst UC1_D6 omission option 'Cancel' is not described in the alternative flow researchers UC1_D7 omission missing business rule associated with EF3 exception flow researchers UC1_D8 omission business rule BR2 omission researchers UC1_D9 omission step AF2.1 does not mention business rule BR1, necessary to show already registered departments business analyst UC2_D1 ambiguity 'Edit' button is used for two purposes in the UC researchers UC2_D2 incorrect fact use of EF instead of AF to describe option 'Cancel' business analyst UC2_D3 incorrect fact UC description wrongly says that the next step after EF3.2 is MF1 researchers UC2_D4 inconsistency update MSG in step AF1.7 mentions MSG2 instead of MSG3 researchers UC2_D5 inconsistency since UC2 refers to documents, step EF2 should mention that the document cannot be deleted researchers UC2_D6 extraneous information step AF2.2 should not mention EF1 business analyst UC2_D7 omission UC description does not mention option 'Cancel' business analyst UC2_D8 omission UC description lacks a business rule mentioning already registered documents business analyst UC3_D1 ambiguity there is no clarity on whether all or just some fields mentioned in business rule BR1 are mandatory researchers UC3_D2 incorrect fact UC name is already in use. UC3 should be named 'Regularise document' researchers UC3_D3 inconsistency same button is named 'Add document' in the main UC flow and 'Add attachment' in business rule BR1 researchers UC3_D4 extraneous information precondition 'The department must be registered' is not related to the UC researchers UC3_D5 omission there is no information on acceptable attachment file types business analyst UC3_D6 omission UC lacks option 'Cancel' business analyst UC3_D7 omission there is no business rule defining date validation rules business analyst UC3_D8 omission business rule BR1 lacks mention to the required fields business analyst MF – main flow, AF – alternative flows, EF – exception flows, BR – business rules, and MSG – message. 3.2 Empirical study procedure We carried out the experiment in three stages: (i) training on prototyping, (ii) UCs prototyping, and (iii) final evaluation and focus group. Training was carried out on the first day. On the second day, participants received the UC specifications and created the prototypes based on them. Prototypes simulating the system development were created using the online tool Draw.io (https://www.draw.io/). Fig. 2 shows a prototype created during the study. Fig. 2Open in figure viewerPowerPoint Prototype example On the third day, participants answered the questionnaire to evaluate the requirements communication from their point of view. Also, we conducted a focus group session in order to obtain qualitative data related to the participants' difficulties and needs when creating prototypes based on the UCs provided. According to De França et al. [21], a focus group is a technique for collecting qualitative data from a group of people through simultaneous interviews giving a focus on a specific topic that one wishes to deepen. Focus groups should be mediated by a moderator or facilitator and participants should discuss points raised by the moderator with the rest of the group. The focus group objective was to raise and discuss the difficulties faced by the participants to create prototypes based on the use of cases specifications. The researcher worked as a facilitator of the session by motivating the participants to present and discuss their point of view about the following questions: (i) What difficulties did you face for prototype creation based on the UC specifications received? (ii) What UC specifications information do you consider essential for prototype creation? (iii) What UC specifications information do you consider dispensable for prototype creation? (iv) What were the reasons that led you to modify or infer information that was described in the specification when you created the prototype? (v) What information did you need for prototype creation that was not in the specification? The focus group session took 2 h in total. We started the session by giving an overview of the study objective and explaining how participants should discuss and act during the session. The session was audio and video recorded to increase transcription accuracy and documentation of the points rose for future analysis. 4 Results analysis In this section, we present the quantitative and qualitative results regarding the analysis of the discrepancies identified in the prototypes created. We analysed which discrepancies were caused by the specification defects (propagation of the defects) and the reasons for each discrepancy. In addition, we analysed participants' requirement informational needs and the difficulties they faced. 4.1 Analysis of prototype inspection We assessed whether participants followed the specification to create the prototypes. Thus, we performed inspections to verify all prototypes discrepancies from the UC specifications. We classified the discrepancies as actual defects or improvements. Actual defects were caused by participants not following specifications or inserting or omitting new information in the prototypes. Improvements are associated with corrections of defects present in UC specifications, i.e. prototypes have discrepancies because they do not follow the UC specifications though they meet the customer needs. In addition, we classified the discrepancies with the taxonomy suggested by Travassos et al. [20] as presented in Section 3.1.4. We identified 42 unique discrepancies in the prototypes comprising only three types: 'incorrect fact', 'omission', and 'extraneous information' Fig. 3 shows the discrepancies distribution. Fig. 3Open in figure viewerPowerPoint Number of found discrepancies As stated before, some discrepancies between the specifications and the prototypes are not defects. Therefore, we considered 'incorrect fact' and 'omission' as defects, and 'extraneous information' as improvements. An 'incorrect fact' relates to information present in specifications that were inserted into prototypes in another way. For instance, some participants changed the MSGs to users, button names, labels on screen elements, and so on. We identified nine 'incorrect facts' in the prototypes. An 'omission' is an information described in specifications but not insert into prototypes. Participants who committed this defect, omitted buttons, flows, and MSGs. We identified 10 'omissions' in prototypes. We identified 23 'extraneous information' in prototypes. These discrepancies are caused by information not present in specifications but inserted as enhancements to the specifications used to create the prototypes. Examples of found improvements were new screens, buttons, and MSGs. 4.2 Analysis of the propagation of specification defects to the prototype To verify which of the 25 defects found in the specifications impacted the prototypes creation, we performed an analysis of associating specification defects to prototypes discrepancies. We identified 6 (24%) specification defects that were propagated to prototypes (UC1_D6, UC2_D1, UC2_D7, UC3_D3, UC3_D6, and UC3_D8). These defects caused 14 discrepancies in the prototypes, as shown in Table 3. Table 3. Discrepancies propagation Incorrect fact Omission Extraneous information UC1_D6 — — 5 UC2_D1 — 1 — UC2_D7 — 1 3 UC3_D3 1 — — UC3_D6 — 2 — UC3_D8 1 — — We found 7 (28%) specification defects that had no influence on prototypes (UC1_D2, UC2_D6, UC3_D4, and UC3_D5), they included modified actor name, exception and alternative flow change, unused MSG to user, flow call in the wrong place in the specification, precondition information that was not part of the UC, lack of format information etc. Also, 12 (48%) specification defects were corrected by participants (UC1_D1, UC1_D04, UC1_D7, UC1_D8, UC1_D9, UC2_D2, UC2_D4, UC2_D5, UC2_D8, UC3_D1, UC3_D02, and UC3_D7), thus they were not propagated to the prototypes. Two defects were of the 'ambiguity' type, where participants assumed one of the specified information. Two defects were 'incorrect facts', where the participants analysed the specification and inferred the correct information to represent the information. Three defects were 'inconsistencies', the participants adopted one of the presented options. Finally, 5 defects were 'omissions' that the participants corrected by inferring the missing information by reviewing the UC specifications. Fig. 4 shows the total number of defects found in the prototypes: 14 out of 42 defects were propagated from specifications, 28 new defects were inserted because participants did not follow the specifications. Fig. 4Open in figure viewerPowerPoint Total defects found in the prototypes 4.3 Analysis of the reasons for changes In this section, we present the results of a qualitative analysis to evaluate the difficulties faced by the developers in creating prototypes from UC specifications. We collected participants' feedback from two sources: responses to a follow-up questionnaire and a focus group session at the end of the study. As outcome of the questionnaire application, we were able to identify the reasons why participants did not follow what was described in UC specifications when they created the prototypes. From the participants' point of view, the focus group session allowed us to understand the reasons identified by the participants. Participants stated that they changed specifications due to: (i) the existence of specification errors, (ii) ambiguous information, (iii) lack of detailed specification or incomplete information, or (iv) improvement suggestions. Fig. 5 shows the quantitative results regarding these reasons. Fig. 5Open in figure viewerPowerPoint Reasons for changes The reasons 'I made it differently because there was an error in the specification' and 'I made it differently because the specification was ambiguous' generated 'incorrect fact' discrepancies. The reason 'I made it differently because it lacked details/it was incomplete' generated 'omission' discrepancies. Finally, the reason 'I did it differently as an improvement suggestion' generated 'extraneous information' discrepancies. The reason 'I did it differently as a suggestion of improvement' avoided the propagation of 12 specification defects that were corrected when participants created the prototypes. Therefore, they were not considered prototype defects but rather improvements. 4.4 Analysis of informational needs of requirements We performed an analysis of participants' perceptions regarding the UC specifications fields that they deemed necessary for the prototype's development. Fig. 6 summarises the quantitative results. Fig. 6Open in figure viewerPowerPoint Information needed by developers All 14 participants considered necessary the UC description, MF, AFs, EFs, and BRs. About 13 participants considered necessary the screen fields description. About 12 participants stated that actors' definition and navigability were necessary. About 11 participants stated that actors' description and MSGs should be specified to assist in the creation of prototypes. Only nine participants considered necessary preconditions specification. Table 4 presents examples of participants' feedback on how important the UC specifications fields are. Table 4. Participants' feedback on the UC fields UC fields Participants' quotes UC name 'it is necessary, as it can be used to name a menu item' – P10 UC description 'it is necessary to understand what happens in the UC and its limitations' – P4 actors description 'depends on the UC, if you have doubts regarding roles so actors description is needed' – P10 preconditions 'sometimes it is important having it to verify input conditions associated with the UC' – P10 MF 'it is necessary because it shows the steps that must be followed during implementation' – P5 AFs 'it is required to take note of user's optional steps' – P12 EFs 'depending on the UC, EFs are more important than AFs, because they will always have to exist' – P4 BRs 'they are needed to support UCs description' – P7 MSGs 'they are necessary, so MSGs' content is not on developers discretion and to maintain a common style' – P4 system's screen fields 'it is needed to know what will be inserted in the prototype' – P11 navigability 'it is needed to indicate accurately where the system screen to be shown when an action i