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 advantage is often their graphical mode, a characteristic components, which are further described in the software design o the document in question contains or descriptions produced in the next phase. The Functional implements all applicable stipulations of the Specification describes how the software requirement predecessor document, specifications will be met in terms of the software’s logical o A given term, acronym, or abbreviation means architecture. To avoid confusion, many of the terms used in the same thing in all documents, this paper are defined below. o A given item or concept is referred to by the same name or description in the documents, Function: “(1) A function is a module that performs a o All material in the successor document has its specific action, is invoked by the appearance of its name in an basis in the predecessor document, that is, no expression, may receive an input value, and returns a single untraceable material has been introduced, and value” [5]. When a function is decomposed, sub-functions can o The two documents do not contradict one be identified Even though this definition is technical in nature, another” [8]. it is deemed to be useful because of its emphasis on the discrete nature of a function. III. MODELING METHOD FOR GRAPHICAL REQUIREMENTS ANALYSIS Functional Characteristics: Inputs, outputs, process (algorithms), and interfaces of a function are defined as functional characteristics in this paper [5]. Graphical Requirement Analysis (GRA) is a method for translating functional requirements expressed in a text format Functional Requirement: “A requirement that specifies a to a graphical format. It is also proposed as a traceability function that a system [software] or system [software] analysis method for system and software requirements The component must be able to perform” [5]. GRA modeling core concept was derived from a system engineering technique called the Master Logic Diagram Functional Specification: “A document that specifies the (MLD) [9,10,11]. This technique has been used to model functions that a system [software] or component must complexity for system diagnostic purposes. GRA includes, as perform” [5]. well, a mapping to the COSMIC-FFP method [6] for measuring software functional size though this topic is not Functional User Requirements (FUR): “The term discussed in this paper. As shown in Fig. 1, the GRA Functional User Requirements is a sub-set of the user modeling method adopts the following graphical language requirements. The FUR represent the user practices and notation: 1 procedures that the software must perform to fulfill the user’s Module : A rectangle in the centre represents a module or needs. FUR exclude Quality Requirements and any Technical Functional User Requirement in a multilevel hierarchy. Requirements” [6]. External I/O: The rectangles on the top and on the left represent external input and output sets. User inputs, sensor Traceability: Definitions or descriptions of traceability that outputs, system variables, and outputs of another module are can be found in software engineering standards include: examples of such external input and outputs. o “The degree to which a relationship can be established Internal I/O: The numbered circles represent the output of a between two or more products of the development sub-module which will be an input to another sub-module process, especially products having a predecessor within a time sequence, as shown in Fig 1. successor or master-subordinate relationship to one Sub-module: These are illustrated with decision logic another; for example, the degree to which the symbols in Fig. 1. Sub-modules can be mathematical operators, requirements and design of a given software component decision algorithms, etc. match” [5]. Boundary: This is identified by the entry and exit points of o “A Software Requirements Specification (SRS) is a Functional User Requirement or module. traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation.” Forward and backward traceability are also recommended [7]. o “Traceability […] means that the document in question is in agreement with a predecessor document to which it has a hierarchical relationship. Traceability has five elements:

1The terms of module and function are used interchangeably. The description of the Vessel Water Level Controller OUTPUT function was taken from the System Requirement Specifications, and is as follows: “The level controller A module 6 provides the dynamic level position inside a given component 5 along with the current feed water line and steam line mass flow A sub-module 5 rates. The output consists of the mass flow rate of the FILL component, which provides the inlet flow of the feed-water system.” Internal I/O 4

4

3 Step 1: Identifying the external I/O

3

2 To achieve the Vessel Water Level Controller function, five

1 2 inputs were identified in the System Requirement Specification

1 as follows. These were traced forward from, and backward to, the User Manual to verify their correctness. User/operator inputs INPUT 1 X1(meter) should be provided with the vessel down water

Sensor outputs level, which could be provided by type 106 signal variable. INPUT 2 X2 (kg/sec) should be provided with the current time step Outputs of another function/module INPUT 3 feed water line mass flow rate. X3(kg/sec) should be the current time step steam line mass Any hardware action INPUT n flow rate. Fig. 1. Graphical Requirements Analysis (GRA) Notations c1 (meter) is the user-desired vessel collapsed water level position, A general strategy for functional decomposition is to define c2 (kg/sec) is the nominal steady state feed water line mass a Functional User Requirement (FUR) as a mapping from flow rate (kg/sec) inputs to outputs. Ideally, traceability analysis proceeds in a Control block number 202 was identified in the User Manual top-down fashion, first identifying the functions associated as the Vessel Water Level Controller function. The control with the software as a whole. Each level of detail in the block was described as follows: hierarchy provides detail about the processing steps necessary Control Block no.: 202 to accomplish the more abstract function defined one level Control Block name: Vessel water level controller above. The decomposition process is repeated until some Control Block Mathematical Operation: lowest level of sub-functions is reached. On the left side, the X (out) = f (X1, X2, X3, c1, c2) external input sets are linked to sub-modules. Some external Block Inputs: X1, X2, X3 inputs may be used by multiple sub-modules. In a complete Block Constant: c1, c2 decomposition of a Functional User Requirement (FUR), the functional hierarchy specifies the sub-modules, the internal The External I/O of the Vessel Water Level Controller is inputs needed to perform these sub-modules, and the internal illustrated in the GRA framework with rectangles outside the outputs resulting from these sub-modules, as well as their functional boundary in Fig. 2. interrelationships. Any external output of a module can be an input to another module or vice versa. Step 2: Identifying Sub-modules and Internal I/0

IV. A CASE STUDY: The control block function operators or sub-modules belonging to the Vessel Water Level Controller were identified from the System Design Specification (SDS). These are traced An illustration of an application of the GRA method on a forward from, and backward to, the User Manual. To achieve Vessel Water Level Controller, a functional user requirement the process goal of each sub-module as listed in Table 2; their 2 (FUR’s) in a process control system , is presented in this internal inputs/outputs were searched using a functional section. To build the GRA model, the functional characteristics decomposition technique. The application of the GRA method (input/output/process) of the Vessel Water Level Controller notably identified that SUBT 54 had an incorrect control block which is a system level requirement, were searched through the number. This has been replaced by ADD 3 in Figure 2. various documents produced during the system and software development process.

2 For reasons of confidentiality, no reference is cited here.

Table 2: Sub-Modules of Control Block 202 Xout =f (X1,X2,X3 C1,C2)

202 Previously Identified Sub-Modules Sub-Modules Identified by Using the GRA 8 3 Method

Control Control Block Type Control Block Number

Block # & Name and Type 7 23 ING (Integrate) ING 23 26

26 LAG First-order lag LAG 26 6

56 SUBTC (Sum SUBTC 56 59 constant) 59 WSUM (Weighted WSUM 59 . 3 summer) 11 DEAD (Divide) DEAD 11 59 2 54 SUBT (Subtract) ADD 3 59 WSUM (Weighted WSUM 59 1 23 summer) 56 56 SUBTC (Sum SUBTC 56 5 X(1) (m) Vessel Water Level constant) 56 SVT 106

The external inputs identified in step 1 are then mapped to Cbcon1 (m): Water level set-point 4 the internal inputs of the lowest level of sub-module obtained X(2) (kg/sec) Current time step feed-water line mass flow rate 11 using a functional decomposition of the system requirement in (mfw) step 2. As shown in Fig. 2, the inputs of the Control Block X(3) (kg/sec) Current time step steam line mass flow rate Functions or sub-modules 11, 3, 56, and 23 are mapped to the (ms) external inputs. After verifying the correctness of the external Cbcon2 (kg/sec): nominal steady inputs in the GRA method, these inputs are mapped to the state feed-water line mass flow rate System Requirement Specifications; leading to either a set of unmapped requirements or to a set of unnecessary INTERNAL I/O SUB- FUNCTIONS EXTERNAL (SYSTEM EXTERNAL OUTPUT requirements. Models such as Figure 2 are built from top to AND USER) I NPUTS 1 Water Level bottom (that is from the User Manual to the System 56 SUBTC 2 Requirement Specifications, the System Design Specifications Int. Lev. Err X(1) (m) Vessel Wat er Level 23 INT SVT 106 and eventually to the Software Requirement Specifications), 3 (Ki+Kp)term

Cbcon1 (m): Water level set-point and traceability analysis is executed from bottom to top (that 59 WSUM 4 mFW X(2) (kg/sec) Current time step is, from the Software Requirement Specifications to the 11 DEAD feed-water l ine mass fl ow rate 5 m - m (mfw) Xout =f (X1, X2,X3 C1, C2) System Design Specifications, the System Requirement S FW 26 LAG X( 3) (kg/sec) Current time step steam line mass flow rate Specifications and to the User Manual). 6 ∆m (dem) FW (ms) 3 ADD Functional characteristics (internal I/O, external I/O, sub- 7 ∆ mFW (act) Cbcon2 (kg/sec): nominal steady functions or sub-modules) can be incorporated into a multilevel state feed-water line mass flow rate 8 202 Level mFW Controller hierarchy using the GRA modeling method.

Fig. 2. Analyzing Water Level Control Function using the GRA Method V. LESSONS LEARNED AND CONCLUSION

This paper discussed a modeling method to support software requirements verification and to facilitate traceability analysis of software requirements. The proposed method has the following strengths: o Using a graphical presentation instead of natural language to specify software requirements at various levels of abstraction can reduce inconsistencies, incompleteness, ambiguities and better reveal requirements that are not specified. o A graphical presentation of requirements helps to visualize functional interrelationships between system requirements and software requirements as well as between stakeholder requirements and software requirements . o Even though these topics are not presented in this paper, effectiveness of test cases and impact analyses are an integral part of the model.

A future research opportunity to be investigated regarding automation of the GRA method is the link between the proposed method and the current research and development on model-driven software development [12]. An investigation of how the proposed method can benefit from a stronger integration with the COSMIC-FFP functional size measurement method should also be pursued [6].

ACKNOWLEDGEMENTS In this work Universidad Politécnica de Madrid has been partially supported by the AGMOD project, Ref. TIC2003- 08503, funded by the Ministry of Education of Spain.

REFERENCES [1] Abran A. and Moore J. W. (Exec. Eds), Bourque P. and Dupuis R. (Eds) "Guide to the Software Engineering Body of Knowledge,", 2004 Version, IEEE Computer Society Press and also published as ISO Technical Report 19759, 2004. [2] Groundwater E.H., Miller L.A., Mirsky S.M. Guidelines for the Verification and Validation of Expert System Software and Conventional Software. Survey and Document of Expert System Verification and Validation Methodologies NUREG/CR-6316, SAIC-95/1028. Vol.1-7. . 1995 [3] Orlena C.Z., Anthony C.W., Finkelstein. “An Analysis of the Requirements Traceability Problem, ,http://www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/rtprob.pdf [4] Jackson, J., “A Key-Phrase-Based Traceability Scheme, Tools and Techniques for Maintaining Traceability during Design,” IEEE Colloquium, Computing and Control Division, Digest No: 1991/180 [5] IEEE, Std. 610.12: Standard Glossary of Software Engineering Terminology. 1990. [6] ISO/IEC, ISO/IEC 19761: Software Engineering - COSMIC-FFP - A Functional Size Measurement Method, International Organization for Standardization, Geneva, Switzerland. 2003. [7] IEEE, Std. 830: Guide to Software Requirements Specification,” 1998. [8] DoD, Std-2167A: U.S. Department of Defense Military Standard: Defense System Software Development, Washington, D.C. 1988. [9] Modarres M.. Functional Modeling of Complex Systems Using a GTST- MLD Framework. Proceeding of the 1st International Workshop of Functional Modelling of Complex Technical Systems, Ispra, Italy. 1993. [10] Hu Y-S, Modarres M., Applying Fuzzy-Logic-Based Hierarchy for Modelling Behaviours of Complex Dynamic System. System and Software Computing in Nuclear Engineering, Da Ruan ed., Springer- Verlage. 1999. [11] Kececi, N., M. Modarres, and C. Smidts. “System Software Interface for Safety-Related Digital I&C Systems”, European Safety and Reliability – ESREL’99 Conference, TUM Munich- Garching, September 13-17, 1999 [12] Sendall, S.; Kozaczynski, W. Model transformation: the heart and soul of model-driven software development. IEEE Software, Vol. 20, No 5, p.42-45 2003.