Modeling Functional Requirements to Support Traceability Analysis

Modeling Functional Requirements to Support Traceability Analysis

Modeling Functional Requirements to Support Traceability Analysis Nihal Kececi*, Juan Garbajosa*, Pierre Bourque** Universidad Politécnica de Madrid (UPM) Technical University of Madrid E.U. Informatica. Ctra. de Valencia, Km. 7. E-28031 Madrid. Spain [email protected] [email protected] ** Département de génie logiciel et des TI École de technologie supérieure 1100, rue Notre-Dame Ouest Montréal (Québec), Canada H3C 1K3 [email protected] Abstract Traceability analysis is a technique that enables the accordance with its previously stated software requirement verification of software requirements within the software life specifications. cycle. Within a context where there is a lack of common understanding of what must be traced, a number of methods have The importance of software requirements cannot be been proposed to implement software requirements traceability overstated since all subsequent phases of the software life analysis, many of these methods dealing with software cycle are dependent upon these software requirements. requirements expressed in natural language. This paper provides Developing and managing software requirement specifications a graphical model to visualize software functional requirements represent an especially difficult challenge. Experience has that facilitates identifying functional traceability links. An application of the proposed model is illustrated through a case shown that some of the reasons why errors tend to occur in the study taken from a process control system. software requirements phase are as follows: (1) misunderstanding or misinterpretation of software Keywords: Functional traceability, requirements verification, requirements, (2) incomplete and inconsistent software traceability analysis. requirements, and (3) software requirements written in natural language that are ambiguous, inconsistent, and incomplete. The result of the software requirements elicitation and specification process is often a long document that is difficult to read and is I. INTRODUCTION even more difficult to design and code from. Also, when Requirements specifications for software consist of a changes are needed, processes are often not in place to number of abstraction levels, derived through successive determine how other software requirements are affected by decompositions of the software under development or being particular changes. Software requirements traceability analysis maintained. One of the major challenges within large-scale is therefore an essential activity to support the verification of software engineering is the management of these requirements software requirements as well as to manage changes. The notably because software requirements are generated, used and ability to trace the logical and physical links between software changed throughout the software life cycle by a number of artifacts including different levels of requirements is essential different technical and commercial groups. and critical to the development of complex software. The SWEBOK Guide defines verification as “an attempt to In this section we discuss the importance of software ensure that the product [software] is built correctly, in the requirements in the software life cycle, the verification of sense that the output products of an activity [within the software requirements, and the role of software requirements software life cycle] meet the specifications imposed on them in traceability analysis within the software verification process. previous activities” [1]. Validation deals with ensuring that the Section 2 reviews current verification methods for software. product fulfills its intended purpose. This paper deals with Definitions of the terms used in this paper are introduced in traceability analysis within the context of software verification section 3. A modeling method for graphical software rather than within the context of software validation. requirements analysis is discussed in section 4, and a case The completeness of the verification of software study is presented in section 5. Conclusion and lessons learned requirements is fundamental to effective requirements are discussed in Section 6. management. The complete software requirements verification process shows whether a software component behaves in II. SOFTWARE REQUIREMENTS that facilitates simulation or animation of software requirement VERIFICATION METHODS specifications and designs. But formalization itself cannot guarantee defect detection, nor can it prove that the software To deal with inconsistent and incomplete software requirement specifications are correct. requirements, many approaches to the verification of software requirements have been developed over the last years. C. Review and Analysis: According to a survey and assessment of verification methods A commonly applied method of software verification is the of conventional software [2], software requirements and design review and analysis of the stakeholder requirements definition verification methods consist of four major categories and documents and the software requirement specifications. Such various subcategories. These major categories are described as a review and analysis is carried out by trained personnel to follows and are summarized in Table 1. investigate their adequacy using a detailed pre-established set of criteria and procedures. A group of reviewers is constituted with a mandate to look for errors, mistaken assumptions, lack TABLE 1 CATEGORIES OF SOFTWARE VERIFICATION METHODS of clarity and deviations from standard practices. Reviews may Category Description be constituted on completion of the stakeholder requirements Formal Mathematical Verification of Software definition document, the software requirement specifications, Methods Requirements: Translates software the baseline specifications for a new release, etc. requirements into mathematical form to analyze various properties. D. Traceability Analysis: Semi-formal Requirements Language Analysis: Traceability analysis notably establishes the relationships Methods Express software requirements in a between software requirement specifications and software special requirements language and design, matching elements of one to those of the other. Once analysis of results for completeness, the matching has been completed, all that remains is either a consistency, feasibility, testability, etc. set of unmapped software requirement specifications, or a set Review and Review and analysis by trained personnel of unmotivated or unintended functions that were inserted in Analysis of the adequacy of software requirement the software design artifacts. Traceability analysis may also be specifications using a detailed pre- applied between different levels of software requirements such established set of criteria and procedures. as between the stakeholder requirements definition document Traceability Identification of individual software and the software requirement specifications. Within the Analysis requirements entities and tracing of these context of a lack of common understanding of what must be to design entities and from the design traced, many methods have been proposed for diverse entities to implementation entities. applications of software requirements traceability analysis and many of them deal with software requirements expressed in A. Formal Methods: natural language [3, 4]. Formal methods involve mathematical and logical representations for expressing relationships among data and for expressing the processes which interact with them. II. KEY CONCEPTS AND DEFINITIONS Mathematical representations produced early in the software Functions are discrete actions that must be performed. life cycle, from the stakeholder requirements definition Functional analysis begins by identifying top-level system document, the software requirements specifications, and the functions and decomposing these into a hierarchy of sub- software design documents may then be subjected to formal functions to form a functional architecture. The objective is to deductive reasoning to detect anomalies or defects regarding, break the system down into sub-functions which can be for example, correctness, contradiction, completeness, and performed by people, hardware, and software, and which, consistency. While formal descriptions are valuable, the state when combined with other sub-functions, will achieve the of the art has not evolved to a point, yet, where they can be performance of the higher-level system function. The purpose very widely applied. In particular, the number of people who of functional requirements traceability analysis at the system could be trusted to make formal descriptions of non-trivial level is to determine if all the functional requirements have software is quite limited. been mapped to detailed system specifications and if these, in turn, have all been allocated to the functional components of B. Semi-Formal Methods: the software architecture if these system specifications are Semi-formal methods are less difficult to apply than formal allocated to software. methods. They often involve notations with rigorous The Software Functional Specification (sometimes called a constraints on notably the selection and sequencing of Functional Architecture) contains a high-level diagram of the operators to achieve the goal of analyzing software logical software architecture including interfaces to other requirement specifications within well defined boundaries. One systems and software. The software is divided into functional major

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    6 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us