A Review of Requirements Engineering Tools for Requirements Validation Software Engineering Process

Transcription

1 International Journal of Software Engineering and Technology A Review of Requirements Engineering Tools for Requirements Validation Software Engineering Process Massila Kamalrudin, Safiah Sidek, Sharifah Sakinah Syed Ahmad Innovating Software System and Services Group Universiti Teknikal Malaysia Melaka, Melaka, Malaysia [massila, safiahsidek, Nadiah Daud Faculty of Information & Communication Technology Universiti Teknikal Malaysia Melaka, Melaka, Malaysia nadiahdaud@yahoo.com Abstract Requirements need to be handled systematically in order to ensure their consistency, completeness and correctness. Several requirements engineering tools have been developed to assist software engineers in handling the requirements. However, each of the tools have different features, hence there is a need to identify the strengths and weaknesses of each tool to provide valuable information for software engineers to choose the most suitable tool for handling requirements and development of future requirements engineering tools. Based on seven RE tools, this paper reports the analysis of these tools based on three criteria, namely the requirements engineering activities, requirements modeling technique and requirements specification to determine their strengths and weaknesses. It was found that the validation activity is still lacking in most of the RE tools. This analysis leads to the identification of research gaps that need further exploration by the developers of requirements engineering tools. Keywords Requirement Engineering Tools; requirements engineering activities, requirements modeling techniques; requirement specification INTRODUCTION Requirements are often unstable due to the occurrence of defects, such as conflicts, inconsistencies and incompleteness []. These defects usually exist during the activity of requirements engineering. For example, a document-based requirement specification approach can constrain the flow of requirement as it is complicated to keep them up-to-date due to the difficulties to inform the stakeholders of any changes made []. Additionally, the storage of newly added information and the linkages between requirements and design such as the use cases are cumbersome []. In this case, there is a need to manage the requirements in order to ensure its consistency, integration and correctness. Requirements engineering consists of four main activities which are requirements elicitation, requirements validation, requirements management and requirement document [8]. As one of the activities of requirement engineering is the requirement management, it involves activities such as finding, organizing, documenting and tracking the requirements for software system [, 3]. Managing requirement is crucial from the beginning of system/software development as it is actually responses to changes and directly related to the result of changes [4]. Requirement management also manages the multiple configurations of requirements, requirement versions and requirements deliveries based on the allocated time, cost and correct quality [5]. It relates to documentations and ensures that changes are made consistently across the sets of documents. Requirements validation is another important activity in requirement engineering as it determines the development of a quality requirement. It is a process executed throughout the system life cycle to ensure the quality of requirement based on three aspects: correctness, completeness and consistency of a requirement [7]. The validation process helps to determine the end product is correct and complete as well as guarantees that the system developed satisfies the stakeholder s original requirements [7]. Requirement engineering tools (RE tools) are considered essential as they can be used to overcome the problems existing in the requirement engineering domain, especially in controlling and tracking the changes in requirements. Further, their automated feature is necessary to support the collaborative requirement activity for software requirement specifications. Requirements engineering (RE) tools can be categorized into two categories, which are the commercial RE tools and the RE research tools. Although there are varieties of RE tools that have been developed to support the requirement activities, these tools have different features and not all of the RE tools are suitable for all software development projects. Hence, software engineers need to have knowledge in choosing the most suitable RE tools. Further, an analysis of the different features of the RE tools lead to the identification of research gap that can be explored further by researchers interested to develop newly improved RE tools. Drawn from this context, this paper aims to report a comparison analysis of seven (7) RE tools that are available in the market in order to determine their strengths and weaknesses with respect to their support features in the requirement activity. In doing so, this paper will first present the method of analysis of the seven RE tools. The analysis is based on three criteria: The requirements engineering activity, the requirements modeling techniques and the requirements specifications. This is followed by a section that analyses the key features of the seven RE tools in relation to the three criteria stated above. Then, the discussion section presents a summary of the analysis of the seven RE tools in relation to the three criteria. Finally, a conclusion is drawn from the analysis and discussion section. 9

2 METHODS OF ANALYSIS The method of analysis of the selected RE tools is based on the three common criteria that exist in most analyses of Requirement Engineering Tools which are the requirements engineering activity, requirements modeling techniques and the requirements specifications used to develop requirements. Further, the source of evaluation of these tools were drawn from three sources which are the authors experience exploring the tools, reviews of study in published literature and findings from the INCOSE survey. The three criteria for the analysis of the seven RE tools are described below. A. Requirements Engineering Activity Requirements engineering activity is divided into three categories: requirements elicitation and analysis, requirements validation and requirements management. The first activity is the requirements elicitation and analysis, where requirements engineers try to capture and analyse the needs of the client-end users. The second activity is the requirements validation. At this stage, engineers need to validate the requirements. This is done by ensuring that the elicitation does not have any problems such as such as inconsistency and incompleteness []. The third activity is the requirements management activity. Here, the engineers are required to understand and control the changes of the captured and validated requirements. Another requirement activity is the requirement document and this activity is beyond the criteria of the analysis according to requirments engineering activity. B. Requirement Modeling Techniques Knowledge and reasoning from the early phase of requirements engineering is necessary [6]. Requirement modeling such as goal-oriented, aspect-driven and system requirements modeling can be used to capture the requirements [6, 7]. Most requirements are written in informal natural language. Formal language is used to illustrate the requirements to ensure its quality. Most requirements techniques as well as the automated verification tools currently available in the market are used for verifying and checking the requirement quality especially with respect to their completeness and consistency [6]. abstraction and type of formal language used. A formal specification assists in reducing errors such as ambiguity and imprecision that may result in the inconsistency and incompleteness [0] of requirements. A semi-formal specification is a combination of diagram and tabular techniques which represents information in a structured form. It also provides guidelines to structure the information by way of manipulation rules over the specification []. Models are commonly used in managing the requirements because they can be easily decomposed into smaller parts that allow readers/users to understand them better []. Informal specification is defined as the use of unrestricted natural language []. This type of specification, which is more English like describes and specifies system requirements by combining the use of graphics with semi-formal textual grammar [3]. It acts as a vehicle to elicit user s requirements and helps the analyst and the clients to communicate their understanding in verifying a particular requirement [3]. RESULTS OF ANALYSIS: THE SEVEN RE TOOLS The RE tools available in the market can be divided into two main categories: The commercial RE tools and the RE research tools. The commercial RE tools support either the full requirements management activity or just a part of the requirement activity [6]. On the other hand, the RE research tools tend to focus on a partial solution for a particular requirements management activity. The RE tools for the comparison analysis in this paper comprises of three (3) commercial RE tools, namely the RAQuest, QPack Tool and Enterprise Architect and four (4) RE research tools which are the EA-Miner Tool, LRS Requirements, WikiReq system and Nocuous Ambiguity Identification (NAI). The following describes the main features of the seven RE tools to highlight their strengths and weakness for handling requirements. The Commercial RE Tools The first commercial RE tool analysed in this paper is the RAQuest. As shown in Figure, RAQuest is a UML modeling tool that manages the requirement with various supported features [7]. C. Requirements Specification Requirements specifications are commonly generated once the requirement analyst has consulted the users. Based on the purpose of the specifications, these specifications can be represented in formal, semi-formal or informal formats[8]. A formal specification is defined as the expression, in some formal languages and at some level of abstraction, of a collection of properties some system should satisfy [9]. This definition covers different notions depending on the coverage of the system, types of properties, area of interest, level of Figure : Example of Features in RaQuest [7] 0

3 This tool can be used to generate documents for a whole project with different types of forms such as HTML, CVS, Word, Excel and RTF. For managing and defining a requirements item, the tool comes with a few facilities such as prioritization, updating of log, definition of user s attributes and assignation of members [7]. A project hierarchy and all list view are provided to allow requirements to be viewed at a glance. For tracking the requirements, different types of relationships are applicable. Overall, the tool provides rigorous requirements capturing facilities but it does not provide any requirements validation facility. This is also supported by the survey reported by INCOSE [8]. The second RE tool analysed is the QPack tool (see Figure ). It provides better traceability, especially in gathering the business requirements as well as the functional or nonfunctional requirements. It also keeps track the changes made in the requirements using the testing coverage and defects by using QPack Analysis [9]. The QPack Requirements definition also acts as a single repository for requirements management purposes, for example prioritizing and estimating efforts, managing the complete life cycle and notifying the changes in requirements [9]. Furthermore, the solution is used to manage the software hierarchy and the traceability is measured using several KPIs [9]. The validation of a requirement is confirmed through testing and defect tracking. To document a requirement, the tool synchronizes the changes made between the MSWord and the QPAck requirements management repository [9]. Overall, this tool is easy to use and able to trace requirements. However, this tool only supports limited requirements validation, hence, it needs to be integrated with test management and defect tracking tools. software artifacts, test cases and others [0]. Here, a complex traceability graph can be viewed for each requirement. In addition, it helps to produce detailed documentation and involves the whole team in defining or working on the captured requirements [0]. In general, this tool provides full derivation of requirements. However, it provides partial validation as it can only identify inconsistencies from the unlinked requirements using the provided traceability facility. Based on the analysis of the three commercial RE tools, it can be concluded that as a whole, the RE commercial tools provide quite a thorough support for managing requirements, especially in capturing requirements and managing changes that occur. However, the majority of these tools do not provide a full checking or validation of requirements. In this respect, the RE research tools have been developed to provide solutions for limitations of the commercial RE tools. 3 Figure 3: Example of the Enterprise Architect 8 tool in managing: () requirements () internal requirements and (3) exporting the internal requirements [0] Figure : Example of the Qpack Tool for () Requirement tracking and () Requirement traceability [9] Enterprise Architect 8 (See Figure 3) is the third commercial RE tool analysed in this paper. It is a requirement management tool that assists users to capture requirements in detail and to manage changes in a requirement [0]. It also provides a baseline to check for changes, deletions, and addition which occur between activities. This tool has a version control to allow storage of the standard XMI text file of any compliant systems [0]. Further, it provides links to different requirements assets such as the use cases, components, The RE Research Tools The first RE research tool analysed in this paper is the EA- Miner (see Figure 4). It was created by Sampaio et al. [] and it was developed mainly to identify and separate concerns with respect to either the aspectual or non-aspectual, with the relationships of their crosscutting at the different level of requirements []. The tool supports four requirement activities. The first is the elicitation activity, where the tool allows the engineering requirements to focus on a particular section of the input documents so that they can easily understand the system []. The second is the identification of an activity for the purpose of deriving the results or screening out of irrelevant abstractions. In this activity, an internal representation is produced from the input file as a Java object for the use of specific techniques such as a viewpoint or scenario-based presentation []. The

4 third activity supported by this tool is the representation of the results for the internal model. This is represented either in the form of diagrams or textual representation []. Finally, the fourth activity supported by this tool is the activity of screening out and generating the requirement specifications documents. This is done by translating the model which has been refined to different formats such as XML, DOC and others []. Figure 4: Example of the EA-Miner tool in eliciting the input requirement () and identifying concerns () [9] However, this tool needs further improvement so that it can lessen the requirement engineers efforts in using the tool. Specifically, the tool can be improved by providing supports to identify the early aspects of both functional and non-functional requirements and to enhance the functionalities of screening out []. The second RE research tool is the Living Requirement Space (LRS) (See Figure 5), and it is an open-access prototype tool developed by Adisa et al. []. stakeholders []. The requirements life cycle involved are the identification, analysis and management of business requirements, mainly for ERP systems []. This tool helps to collect, store, retrieve, control the versions and relationships with other requirements and to manage change requests []. The analysis of requirements is conducted via forums and discussion as well as prioritizing requirements []. Since this tool uses Web.0 technologies, it is accessible to all users from various places. However, the limitation of this tool is it needs Internet connection or a server to be functionable, hence it cannot be used at places without the Internet connection. The third RE research tool is the WIKIReq system (See Figure 6). Developed by Abeti et al. [3], WIKIReq uses wiki technology, and it is suitable to be used as a collaborative platform for discussion among stakeholders as well as for eliciting and managing requirements that use a semantic wiki [3]. The requirements are edited, argued, and discussed between the stakeholders directly into the wiki. In order to have a rigorous elicitation of requirements, each requirement is acquired in the form of a Si* concept [3]. It also allows interoperability between semantic wiki towards the achievement of Integrated Development Environment (IDE) Eclipse. The approach used in this tool also helps to reduce and simplify concepts which involve requirements and business activities. With the use of other technical artifacts such as UML use cases and BPMN models, this tool helps to maintain the coherence of requirements [3]. The approach also relates the business requirements with the expected system starting with the use of cases, business goals and business activities. 3 3 Figure 6: Example of the WikiReq system in eliciting and managing requirement: () shows the actor view point page, () goal view point page and (3) the WikiReq exported to Eclipse [3] Figure 5: Example of the LRS Requirement document (), LRS scenario object and LRS task model (3) generated from the LRS tool [] This tool was developed with the purpose of gathering ERP system requirements using Web.0 technologies and it helps to handle the problem of constantly changing business requirements characteristics []. It acts as a platform that allows collaboration at any stage of the requirement cycle for all domain experts, business analysts and other ERP The fourth RE research tool was developed by Yang et al. [4], called Nocuous Ambiguity Identifier (NAI) (see Figure 7). This RE tool is more focused than the other RE research tools since it focuses on the requirement validation activity. The main function of the tool is to automatically detect the nocuous coordination ambiguity in natural language requirements. Nocuous ambiguities are harmful ambiguities that lead to misunderstanding and errors in any implementation [4]. They are recognized in any of these conditions: present

5 (acknowledged ambiguities) and undetected (unacknowledged ambiguities [5]. Using the nocuity classifier, this tool is able to identify ambiguity patterns by classifying the ambiguities, either as the nocuous or innocuous cases [4]. The nocuity classifier employs a machine-learning algorithm called LogiBoost. If a nocuous ambiguity exists in the text, the tool will detect and highlight them on the screen, as shown in Figure 7. Based on the experimental results, this tool is found to be effective and perform well. However, the authors believe that the performance of the tool needs further improvement and the heuristics approach requires further enhancement. The focus of the tool also needs an extension to a wider range of ambiguity types, not limited to only nocuous ambiguity [4]. This indicates that most RE tools handle three activities of requirements that are the elicitation and analysis, the identification and the change management, except validation. Most of the RE tools do not handle the validation of the requirements such as the consistency, correctness and completeness. This can be considered as a gap in the field of RE tools development based on the assertions made by Laplante [6] that RE tools must include verification activities and Yu [6] that the currently available requirements modeling techniques are mostly used for validation activity. Only NAI is very focused towards updating the ambiguity of requirements and QPack tries to detect the defects by using a testing mechanism. Thus, this analysis has proven that RE tools for validation activity are still lacking. TABLE : COMPARISON AND CLASSIFICATION OF THE FEATURES OF RE TOOLS Figure 7: Example of Results from the NAI tool in detecting nocuous coordination ambiguity [4] DISCUSSION An overview analysis of the seven RE tools based on the three criteria are presented Table. As shown in Table, the authors have developed a characterization of the RE tools to illustrate their strengths and weaknesses. The three classification criteria used to analyse the RE tools are the requirement engineering activities, requirements modelling techniques and requirements specification. The criteria for the requirements engineering activity is further classified into four activities which are the elicitation and analysis, identification, validation and change management. Further, the source of evaluation of these tools were drawn from three sources which are the authors experience exploring the tools and a study of the published literature combined with the INCOSE survey. The analysis of the RE tools based on the three classification leads to an identification of the gaps that still exist in the RE tools to support requirements management. Based on Table, two commercial RE tools, the QPack and Entreprise have similar features: the elicitation and analysis, validation and change management, whilst the rest have more or less different quantity and types of features. None of the seven RE tools have all the features to handle the requirements activity. Three of the seven RE tools, namely the QPAck, Enterprise and LRS handle three out of four activities with different types of feature respectively. Two of the RE tools which are the EA-Miner and WIKIReq have two out of the four features, while RaQuest and NAI have only one feature. Table also shows that most of the RE tools use semiformal specifications as an input and output activity to generate results. Additionally, the techniques used vary according to the activities that the RE tools handle. Based on a comparison between the commercial and research RE tools, it can be concluded that most commercial RE tools use or apply the traceability techniques, especially in tracking changes and eliciting requirements. The RE research tools use different techniques such as heuristics, early aspects, the wiki approach and interviewing as well as interviewing and brainstorming approach. CONCLUSION The analysis of the seven RE tools with respect to the three criteria for handling requirement management shows that there is still a gap in the RE tools to support requirement engineering activity. The RE tools do have all the four features to handle requirements activity. Further, it was found that the validation activity is still lacking in most of the RE tools. As there is little empirical research in validating requirements, it is recommended that further investigation of the key related research in validating requirements focused on consistency, correctness and completeness should be conducted. Further, a the development of RE tools that support the validation activity is recommended. 3

6 VI. ACKNOWLEDGMENT We acknowledge the financial support from the Ministry of Education, Malaysia and the Universiti Teknikal Malaysia, Melaka for their assistance in this research. All authors acknowledge the support of the grants: PJP/03/PBPI(9D)/SO0. REFERENCES [] Geisser, M., Hildenbrand, T., & Riegel, N. (007). "Evaluating the Applicability of Requirements Engineering Tools for Distributed Software Development," Working papers of University of Mannheim for January 007, Germany. [] Kamalrudin, M., Grundy, J., & Hosking, J. (0, September). "MaramaAI: Tool Support for Capturing and Managing Consistency of Multi-lingual Requirements", in Proc. 7th Automated Software Engineering 0 (ASE 0), ACM: Essen, Germany. [3] Finkelstein, A., & Emmerich, W. (000). "The future of requirements management tools," Information Systems in Public Administration and Law. [4] Xie, Y., Tang, T., Xu, T., & Zhao, L. (00, April). "Research on requirement management for complex systems," in nd International Conference on Computer Engineering and Technology 00 (ICCET), pp [5] Xie, Y., Tang, T., Xu, T., & Zhao, L. (00, April). Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes, st edition.,springer, 007. [6] Yu, E. S. (997, January). "Towards modelling and reasoning support for early-phase requirements engineering," Proc. Third IEEE International Symposium on Requirements Engineering, 997., pp [7] Goknil, A., Kurtev, I., & van den Berg, K. (008, January). "A Metamodeling Approach for Reasoning about Requirements," Model Driven Architecture Foundations and Applications, pp [8] Kamalrudin, M., Hosking, J., & Grundy, J. (0, May). "Improving Requirements Quality using Essential Use Case Interaction Patterns," 0 International Conference Software Engineering, Honolulu, Hawaii, USA. [9] Lamsweerde, A. V. (000, May). "Formal specification: a roadmap," Proc. Conference on The Future of Software Engineering, Limerick, Ireland. [0] Darimont, R., Delor, E., Massonet, P., & van Lamsweerde, A. (997, May). "GRAIL/KAOS: an environment for goal-driven requirements engineering," Proc. 9th international conference on Software engineering, Boston, Massachusetts, United States. [] Wleringa, R., & Dubois, E. (998). "Integrating semi-formal and formal software specification techniques," Information Systems, vol. 3, pp [] Kovacevic, S. (999). "UML and User Interface Modeling," in The Unified Modeling Language. «UML» 98: Beyond the Notation, 999, pp [3] Fraser, M. D., Kumar, K., & Vaishnavi, V. K. (99). "Informal and Formal Requirements Specification Languages: Bridging the Gap," IEEE Trans. Softw. Eng., vol. 7, pp [4] Georgiades, M. G., Andreou, A. S., & Pattichis, C. S. (005, August). "A requirements engineering methodology based on natural language syntax and semantics," Proc. 3th International Conference on Requirements Engineering, 005. IEEE, 005, pp [5] Yadav, S., Bravoco, R., Chatfield, A., & Rajkumar, T. M. (988). "Comparison of analysis techniques for information requirement determination," Commun. ACM, vol. 3, pp [6] Lang, M., & Duggan, J. (00). "A Tool to Support Collaborative Software Requirements Management," Requirements Engineering, vol. 6, pp [7] S. S. J. Co. Requirements Management Tool RaQuest, Available: retrieved on: January 0. [8] INCOSE International Council on system Engineering, INCOSE Requirements Management Tools Survey, Available: http: [9] Orcanos. QPack Requirements Tool for Requirements Management.Available: retrieved on: January 0. [0] S.S.Pty.Enterprise Architect 8. Available: retrieved on: February 0. [] Sampaio, A., Chitchyan, R., Rashid, A., & Rayson, P. (005, November). "EA-Miner: a tool for automating aspect-oriented requirements identification," Proc. 0th IEEE/ACM international Conference on Automated software engineering, Long Beach, CA, USA, ACM Press. [] Femi, A., Frantisek, S., & Björn, J. (00). "Living Requirements Space: An open access tool for enterprise resource planning systems requirements gathering," Online Information Review, vol. 34, pp [3] Abeti, L., Ciancarini, P., & Moretti, R. (009, May). "Wikibased requirements management for Business Process Reengineering," in ICSE workshop of Wikis for Software Engineering 009 (WIKIS4SE '09) 009, pp [4] Yang, H., Willis, A., De Roeck, A., & Nuseibeh, B. (00, September). "Automatic detection of nocuous coordination ambiguities in natural language requirements," in Proc. IEEE/ACM international conference on Automated software engineering, Antwerp, Belgium, ACM Press. [5] Chantree, F., Nuseibeh, B., De Roeck, A., & Willis, A. (006, September). "Identifying Nocuous Ambiguities in Natural Language Requirements," Proc. 4th IEEE International Requirements Engineering Conference,IEEE Press. [6] Laplante, P. A. (009). Requirements Engineering for Software and System, CRC Press. [7] Bahill, A.T. & Henderson, S.J. (005). Requirements development, verification, and validation exhibited in famous failures. Syst. Eng., 8(): p. -4. [8] Pohl,K &Rupp,C, Requirements Engineering Fundamentals,Rocky Nook,Edition () 0,ISBN