A New Traceable Software Requirements Specification Based on IEEE 830

Azeddine Chikh, and Mashael Aldayel Information System Department

King Saud University Riyadh, Saudi Arabia

az_chikh@ksu.edu.sa, maldayel@ksu.edu.sa

Abstract—This paper aims to enrich software requirements specification by integrating the concept of traceability. This integration, which will allow a more helpful reading of that specification, will provide a critical support to different requirements stakeholders. Indeed traceability will help for example designers in refining requirements into lower-level design components and analysts in understanding the implications of a proposed change, to ensure that no extraneous code exists and to minimize or eliminate the presence of faked or frivolous requirements that lack any justification. The main contribution of this paper is building a schema for software requirements specification that make it easily traceable by linking each requirement to real-world dimensions such as detail design deliverables, related system requirements and sources such as user requirement, analyst, regulation and standard.

Keywords— Software Requirements Specification, Requirement Traceability, IEEE standard 830, Traceability schema.

I. INTRODUCTION Traceability has become more important over past years

and subject to research in many areas of software development. One of these areas is software requirements engineering which is part of software engineering. This is considered as a challenge not because the difficulty in research questions but also the limited communication between diverse research communities that concern about traceability such as requirements engineering, modeling, or programming… [1]. In addition, the lack of the traceability information may lead to higher costs, waste of time, wrong or unnecessary modification, difficulty in reusability, and many other problems during a software development [2].

A software requirements specification (SRS) is often rich in knowledge. It provides readers with a great amount of information in various sections which smooth the progress of reading. Nevertheless, problems may occur as a result of the complexity of this specification. Among these problems, cognitive overload is an important drawback. But recently semantic traceability is considered as an essential solution for this problem. So this specification should be consistent and easily traceable with other related artifacts in both directions forward and backward. However, there are various challenges

facing companies in practicing requirements traceability such as difficulty in specifying which traceability relations should be documented, which semantic is used for the same relation and limited project time and cost [2].

The success of any software depends on the quality it achieves in meeting the requirements specification. Software requirements traceability can be viewed as a measure of system quality in a software development. It helps ensuring many aspects of system quality such as adequacy, understandability and maintainability to come over inconsistencies or omissions in the system. Also, it helps ensuring validation and verification between pairs of relating artifacts. It is required in many software development standards. The most famous one is IEEE Software Requirements Specification Standard 830 [4] which is chosen as basis to enhance requirements traceability in it.

This research work contributes in re-engineering SRS as a semi structured adopting the IEEE 830 standard and integrating requirements traceability.

After this introduction, section II recalls software requirement engineering. Section III explains requirement traceability concepts such as traceability links, their classifications. Section IV presents a literature review in the domain of requirements traceability. Section V shows our proposed concept for representing traceability links and how to model requirements traceability in SRS based on IEEE 830 standard. Finally, section VI shows the conclusion and future work.

II. SOFTWARE REQUIREMENT ENGINEERING Requirements engineering is common term but still difficult

and not well understood. Its main goal is to help the organizations in achieving their goals. It can be defined as a structured set of activities which are followed to derive, analyze, validate, maintain and check requirements, usually stored in system requirements document [16]. Software requirements engineering can be defined as a subfield of requirements engineering that concern about the software and it is critical for successful software development.

978-1-4673-5157-7/13/$31.00 ©2013 IEEE

Specifying requirements is classified as one of the most difficult and important areas of software requirements engineering [17]. Many companies agree that software requirements engineering is very important to the success of any project because any change in a requirement during later stages of system development lifecycle (such as design, programming, testing) can cost much more than during analysis stage. The key success in software requirement engineering is how to generate efficiently and quickly the project in a manageable process. This is very important in a global competitive market to reduce the time and cost by meeting stakeholder requirements [18][2].

A software requirements specification (SRS) is a complete description of the behavior of a system to be developed from supplier perspective. It describes all the interactions between users and the system [19][20][17][6]. It helps to understand users and satisfy stakeholders. It is acting as the “parent” document because all subsequent software development documents, such as design specifications, statements of work, verification and validation plans, and documentation plans, are derived from it [6]. Consequently, it should be based on a template that resulted in clear, unambiguous and complete requirements specification document. The IEEE standard 830 [4] describes recommended approaches for the SRS. It describes the content and qualities of a good SRS. So, it is used as basis to enhance requirements traceability in it.

III. REQUIREMENT TRACEABILITY Requirements traceability is [1][7] the ability to describe

and follow the life of a requirement, in both forwards and backwards direction, from user demands (origins), through analysis (requirement specification), design, programming (deployment) and all its phases in software lifecycle.

There are many standards that consider traceability as required activity such as IEEE standard 830-1998 which defines an SRS as 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". This standard defines two types of traceability: backward traceability from each requirement to previous stages of development and forward traceability from each requirement to all documents derived from the SRS [4].

A. Traceability Schema A traceability scheme defines the guiding constraints to

record traces by specifying artifacts and amount of details for each one. It is implemented as a model or metamodel when it is represented in a tool. There are two kinds of models: semantic or structural models. The models that explain domain concepts and replace natural language descriptions totally or partially are considered as semantic models such as goal models or business object. On the other hand, the models that assign importance to natural language and address requirements by using their elements are considered as structural models such as the requirements model in SysML [1].

B. Traceability Link A traceability link can be defined as any relationship used

to interrelate artifacts (e.g., by causality, content, dependency, influence etc.) in the software development lifecycle. It can be unidirectional (such as depends- on) or bidirectional (such as alternative- for). The direction of a link only indicates the order in time or causality [1]. Traceability links cardinality can be one-to-one, one-to-many, or many-to many [3]. Furthermore, traceability links can be defined by person who has the proper information.

C. Traceability Link Classifications According to the traceability sate of art, there are many

different classifications of traceability links types but none of them has been agreed as a commonly standard semantics for all these types. Based on [1] in classifying traceability links, we suggest re-classifying them into formal or informal as seen in fig. 1.

The informal classification categorizes traceability links based on their structural properties. They depend on specifying which trace information should be followed. However, these informal classifications suffer from ambiguity or unclear formal definitions which make them difficult in evaluating and comparison [1][20][3].

Figure 1. Traceability Link Classifications

On the other side, the formal classification solves the problem of ambiguity and unclear formal definitions. It is more recent and much realistic in the software requirement engineering. It classifies traceability links based on their semantic properties between artifacts into eight types as explained in [1][21].

IV. LITERATURE REVIEW Requirements traceability and its significant role in

software development have been well explained in many researches [1][2][15]. There are many requirements management tools that support requirement tracing.

Furthermore, there are many works that solve similar problems related to this paper. The methods and approaches developed to support requirements traceability activities are based on information retrieval [8][9][11][12][13][14], reference model [7][10][16] and rule based approach [5]. The

problem with many existing traceability approaches is that they are efficient for only a limited part of the software development process but there is a little or no support for other parts of the software development lifecycle. Traceability is most frequently found between software documents representations and source code for automated analysis [14]. Although requirement specification is the most important part of the software lifecycle, there is little or no support for tracing requirements to sources or design documents. Hence, this increases the importance of this paper.

Marcus[14] et al. present an information retrieval approach for the semi-automated recovery of traceability links between software documents and source code using an information retrieval technique, namely Latent Semantic Indexing (LSI), to extract and analyze the semantic information from the source code and related software documents. This method is evaluated using two case studies. The results show that the LSI method is better than probabilistic and vector space model-based information retrieval methods.

Ramesh [10] et al. conduct empirical studies in a wide range of industrial software development organizations to find out reference models for recording the objects and traceability links. They identify two segments of traceability users and present reference models at two levels: Low-end and high-end models of traceability. The low-end model has 31 types of entities and about 50 types of links. Besides to the complexity of diverse types of entities and links, a specific definition for those elements is not included, which makes the application of such models a difficult task.

Zisman et al. [5] present a rule-base approach for automatic generation and maintenance of bi-directional traceability relations between textual requirement statements (expressed in XML) and object models (expressed in UML). Traceability rules identify ways for matching syntactically related words in the requirements statements with related elements in an object model (e.g. classes, attributes, operations). When a match is found, a traceability relation of different types is created between these artifacts. Only three types of traceability relations are described which are overlaps, realizes and requires. They only consider traceability between diverse requirements artifacts.

V. MODELING REQUIREMENTS TRACBILITY IN IEEE 830 We built a traceability schema in a structured model to re-

engineer SRS as a semi structured adopting the IEEE 830 standard and integrating requirements traceability links. This schema is written in XML schema (XSD) for data modeling to describe logical structure of semi-structured SRS document written in XML (fig. 2).

As seen in fig. 3 and fig. 4, the main SRS components are versions, introduction, overall description, specific requirements and appendices. First component is 'Versions' which is used for design rationale to build a table in the beginning of the SRS document to keep track for update number, update date and reason of that change. Next components are 'Introduction' and 'Overall Description' which are both used to describe SRS as recommended in IEEE 830 standard. Then the most important component is 'Specific

Requirements' which this paper is focus on and is detailed later in this section. Finally, there is the 'Appendices' component which presents each appendix as hyperlink.

Figure 2. The first level of the proposed XML schema

However, it can be noticed that a trace can be documented as two parts:

• Set of metadata of an artifact (such as creation and modification dates, creator, modifier, and version history)

• Relationships explaining the influence of a set of stakeholders and artifacts on an artifact. These relationships are an essential concept in traceability and they are often called traceability links.

Figure 3. Second Level of XML Schema (part 1)

Figure 4. Second Level of XML Schema (part 2)

In our proposed schema, we choose the formal traceability links classification which is modified according to different artifacts generated during various phases in the software development lifecycle. These traceability links are well explained in table I.

In SRS document based on IEEE 830 standard, modeling requirements include re-representing 'Specific Requirements' section of SRS to support traceability. Accordingly, documenting requirement traceability can be viewed in two parts: requirement metadata and traceability links between the requirement and other dimensions.

A. Representing Requirement Metadata Requirements are presented in two types: user requirement

and system requirements where each user requirements has a list of system requirements and each system requirement has its own traceability links.

TABLE I. PROPOSED TRACEABILITY LINKS CLASSIFICATION

Traceability Link Cardinality Traceability Link Classification

System requirement and design deliverable

one-to-many - Dependency - Refinement - Satisfiability - Conflict link - Rationalization

System requirement and another system requirement

many-to-many - Dependency - Refinement - Evolution - Satisfiability - Overlap - Conflict - Rationalization

System requirement and standard

one-to-many - Dependency - Refinement - Conflict - Rationalization

Analyst and system requirement

one-to-one Contribution link

System requirement and user requirement

one-to-many Evolution link

User and user requirement

one-to-one Contribution link

The user requirement components are illustrated in fig. 5 and table II where some traceability links can be noticed in the user requirement attributes. The 'User' attribute represents a traceability link between a user and his request (user requirement). Moreover, 'Analyst' attribute represents a traceability link between the assigned analyst and a user requirement. Therefore, 'User' and 'Analyst' attributes can be considered as traceability links.

Figure 5. User Requirments Components

TABLE II. USER REQUIREMENT COMPONENTS: ATTRIBUTES AND ELEMENTS

Data Member Name Description @ UserReq_ID The unique identifier of the user

requirement @ Status The approval status of the user

requirement as decided by the assigned analyst. If the status is not decided yet, it will take 'Wait' value. Only one of three values can be selected which are: 'Accept', 'Reject' or 'Wait'

@ User The ID of the User who request and write this user requirement.

@ Analyst The ID of the analyst who authorize to decide about the approval status of this user requirement. If he accepts it, he will generate a list of system requirements for it.

UserReq Short description about the user requirement

File File contains details of the user requirement such as tables or drawings.

SystemRequirement The system requirements derived from this user requirement.

Comment The authorized analyst comment of the user requirement.

The details of system requirement components are illustrated in table III.

B. Representing Traceability Links Some of traceability links are represented as attributes and

the others are represented as complex elements with the help of XLink. The former case is explained earlier in 'User' and 'Analyst' attributes of the user requirements which considered one-to-one relationships. The latter case is shown in table III as complex elements of the system requirements named 'Design_G', 'Related_Req_G' and 'Standard_G'.

TABLE III. SYSTEM REQUIREMENT COMPONENTS: ATTRIBUTES AND ELEMENTS

Data Member Name

Description

@ Req_ID The unique identifier of the system requirement @ Category The category of the system requirement. Only one of five

values can be selected which are: 'data', 'functional', 'non-functional', 'managerial' or 'other' requirement [17]

@ Level The goal-design scale of the system requirement. Only one of four values can be selected which are: 'goal', 'domain', 'product' or 'design' level[17]

@ Creation _Date

The date of creation of the system requirement

@ Style The way to show how the system requirement is written [17]

@ IsValid The user validation state of the system requirement. Only one of three values can be selected which are: 'Yes', 'No' or 'Wait'

Description Short description about the system requirement File File contains details of the system requirement such as

tables or drawings. Comment The authorized user comment of the system requirement. Design_G Element that group traceability links between system

requirement and design deliverables RelatedReq_G Element that group traceability links between system

requirement and other related system requirement Standard_G Element that group traceability links between system

requirement and related standards

These elements are gathering traceability links consequently with design deliverables, related system requirements and standards. These traceability links has three types based on related artifacts type. These types are design, related requirement and standard as shown in table IV.

The Xlink:simpleLink is attribute group to handle unidirectional binary links which has one source and one destination.

TABLE IV. COMPLEX ELEMENTS OF TRACEABILITY LINKS UNDER SYSTEM REQUIREMENT ELEMENT

C. Tools and Implementation Since XML has become the standard for representing and

interchanging data in web-based applications, this research work chooses XML to build semi-structured SRS documents. The proposed data model was used in building web-based system named SRS-T (Software Requirements Specification for traceability). Furthermore, compatible languages with XML were applied which are .NET languages, such as asp.Net, C# and LINQ to XML languages, and some of W3C technologies such as XSD, XLink, XSL, XLinq and XPath expressions.

Parent Data Member

Name

Data Member

Name

Description

Design @DL_ID The unique identifier of the design

link.

@Relation_ Type

The type of the traceability link between a system requirement and a design deliverable. Possible values are dependency, refinement, satisfiability, conflict and rationalization

@detail_Type The type of the detail design deliverable

@ xlink: simpleLink

Reference group to store destination in XLink:href attribute

Related_ Requirement

@RL_ID The unique identifier of the Related Requirement link.

@Relation_ Type

The type of the traceability link between a system requirement and another related system requirement. Possible values are dependency, refinement, evolution, satisfiability, overlap, conflict and rationalization

@Related_ Req_ID

The destination ID of related system requirement

Standard

@SL_ID The unique identifier of the standard link.

@Relation_ Type

The type of the traceability link between a system requirement and a related standard or regulation. Possible values are dependency, refinement, conflict and rationalization.

@Standard_ Type The type of standard or regulation

@xlink: simpleLink

Reference group to store destination in XLink:href attribute

Each of these programming languages was used for data representation, data processing or web-based building. For data representation, we used XSD to re-engineer and encode SRS document and XLink for representing the traceability links as hyperlinks. For building the SRS-T system, we use asp.NET and C#. The remaining languages were used for data processing. Furthermore, Microsoft Visual Studio 2008 and <oXygen/> XML Editor 12.2 were used.

VI. CONCLUSION AND FUTURE WORK The traceability between requirements specification has

been recognized as a significant task in the software development lifecycle where well-organized project management and software quality are supported. We found the IEEE standard 830 is the most famous and universal standard that describes recommended approaches for the SRS. Hence, we choose it as basis to build a traceability schema in XSD.

Moreover, we classify traceability links based on their semantic and structural properties into two major classifications: formal and informal. We indicate a clear semantic for traceability links with specific cardinality and refine the formal traceability link classification based on type of paired artifacts of a traceability link.

As a result, we build a web-based system named SRS-T (software requirements specification for Traceability) that use XML technology to make the SRS easily traceable by linking each system requirement in the SRS to real-world dimensions such as detail design deliverables, related system requirements and sources (user requirement, regulation & standard, and analyst). Such dimensions could connect each requirement backward from its source and forward to design deliverables. The manual approach of requirements traceability in SRS document based on IEEE 830 standard is used in SRS-T. The traceability links are represented through an automatic cross reference representation.

Furthermore, the proposed traceability approach is XML-based and comprised of three levels of abstraction, namely conceptual level, logical level, and physical level. This paper details the logical traceability level which explains the data model of SRS document.

Software requirements traceability can be viewed as a measure of system quality in a software development. The lack of the traceability information may lead to higher costs, waste of time, wrong or unnecessary modification, difficulty in reusability, and many other problems during a software development. Future works involve further investigate traceability links with a clear hierarchy and well accepted semantics to build a traceability standard.

ACKNOLEDGEMENT The authors would like to thank the partial support funded

by the Research Center of the College of computer and Information Sciences at King Saud University.

REFERENCES [1] S. Winkler and J. von Pilgrim, “A survey of traceability in requirements

engineering and model-driven development,” Software and Systems Modeling, vol. 9, no. 4, pp. 529–565, 2010.

[2] V. Leino, “Documenting Requirements Traceability Information: A Case Study,” Helsinki University of Technology, 2001.

[3] M. Hokkanen, “Requirements Traceability,” Lappeenranta University of Technology, 2001.

[4] I. C. S. S. E. S. Committee and I.-S. S. Board, “IEEE Recommended Practice for Software Requirements Specifications,” 1998.

[5] A. Zisman, G. Spanoudakis, E. Pérez-Miñana, and P. Krause, “Tracing software requirements artifacts,” Proceedings of 2003 International Conference on Software Engineering Research and Practice (SERP’03), Las Vegas, Nevada, USA, pp. 448–455, 2003.

[6] D. Le Vie Jr, “Writing software requirements specifications,” TECHWR-L (MAR 2007) http://techwhirl.com/skills/tech-docs/writing-software-requirements-specs (accessed November 4, 2012), 2007.

[7] J. I. Maletic, M. L. Collard, and B. Simoes, “An XML based approach to support the evolution of model-to-model traceability links,” Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering, pp. 67–72, 2005.

[8] J. I. Maletic, E. V. Munson, A. Marcus, and T. N. Nguyen, “Using a hypertext model for traceability link conformance analysis,” Proceedings of International Workshop on Traceability in Emerging Forms of Software Engineering (TEFSE ’03), pp. 47–54, 2003.

[9] E. Munson, “The software concordance: Bringing hypermedia to software development environments,” Proceedings SBMIDIA’99: V Simposio Brasileiro de Sistemas Multimidia e Hipermidia, pp. 1–12, 1999.

[10] B. Ramesh and M. Jarke, “Toward reference models for requirements traceability,” IEEE Transactions on Software Engineering, vol. 27, no. 1, pp. 58–93, 2001.

[11] T. N. Nguyen and E. V. Munson, “A model for conformance analysis of software documents,” Proceedings of the Sixth International Workshop on Principles of Software Evolution, pp. 24–35, 2003.

[12] S. C. Gupta, T. N. Nguyen, E. V. Munson, and others, “The software concordance: A user interface for advanced software documents,” Proceedings of 6th IASTED International Conference on Software Engineering and Applications, MIT, Cambridge, MA, USA, 2002.

[13] S. C. Gupta, T. N. Nguyen, and E. V. Munson, “The software concordance: Using a uniform document model to integrate program analysis and hypermedia,” Software Engineering Conference, 2003. Tenth Asia-Pacific, pp. 164–173, 2003.

[14] A. Marcus, J. I. Maletic, and A. Sergeyev, “Recovery of traceability links between software documentation and source code,” International Journal of Software Engineering and Knowledge Engineering, vol. 15, no. 5, pp. 811–836, 2005.

[15] O. C. Z. Gotel and C. Finkelstein, “An analysis of the requirements traceability problem,” Proceedings of the First International Conference on Requirements Engineering, pp. 94–101, 1994.

[16] P. Letelier, “A framework for requirements traceability in UML-based projects,” Proceedings of 1st International Workshop on Traceability in Emerging Forms of Software Engineering, pp. 173–183, 2002.

[17] S. Lauesen, Software requirements: styles and techniques. Addison-Wesley Professional, 2002.

[18] E. Hull, K. Jackson, and J. Dick, Requirements engineering. Springer, 2010.

[19] I. Sommerville, Software Engineering. Addison-Wesley, 2004. [20] "Software Requirements Specification." Wikipedia.

http://en.wikipedia.org/wiki/Software_Requirements_Specification (accessed November 4, 2012).

[21] G. Spanoudakis and A. Zisman, “Software traceability: a roadmap,” Handbook of Software Engineering and Knowledge Engineering, vol. 3, pp. 395–428, 2005.