JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 14, ISSUE 2, AUGUST 2012 1

Documenting Software Requirements Specification Using R2UC Ontology

Elviawaty M. Zamzami and Eko K. Budiardjo
Abstract It is quite common to represent Software Requirements Specification in text document, graphical model, formal model, prototype, or any combination of them. Meanwhile, Ontologies have been applied in software engineering, including requirements ontology. This paper describes an ontology approach on documenting SRS. It is convey ontology coined as Requirements Representation with Use Case (R2UC) Ontology. The oontology refers to elements of requirements specification in Requirements Management with Use Case (RMUC). The R2UC ontology can be used to describe software requirements that is captured in software engineering process or forward engineering process. The R2UC ontology represents the software requirements as the interpretation of software features. The software features as in solution domain fulfill stakeholder's needs or stake holder request as captured in problem domain. The R2UC ontology is modeled on three levels. The final level describes how software requirements will be specified. Requirements representation in R2UC ontology refers to Rational Unified Process (RUP) format. The R2UC ontology is implemented in OWL-DL language, developed using Protg as graphical tools, OWLViz as visualization tool, and Pellet as reasoner. Index TermsRequirements, Software Requirements Specification (SRS), RMUC, R2UC, Requirements Ontology.

1 INTRODUCTION

NE of key to success of software engineering and software reengineering is software requirements. The software requirements will be implemented into software through software engineering process. the contrary, software requirements that had implemented in software can be recovered through reverse engineering process. The requirements that recovered, will be learned whats redundant, should be maintained, and can reuse in software reengineering or the next software development [1]. Software requirements are documented as a software requirements specifications (SRS), called as SRS document. SRS documents will guide software engineer or software team in develop software. To build SRS document can be a problem in software development. Documents have to clear to represent the requirements. The document can be a text document, graphical model, formal model, prototype, or any combination of them [2]. There are some formats to documenting SRS using text, e.g. IEEE and RUP formats. In this paper SRS is documented using ontology, namely as Requirements Representation with Use Case (R2UC) ontology. Ontology is selected because it can present as visual graph, semi formal, also help to check inconsistency, and generate particular code. Documenting using ontology should use ontology tools, those are Portege as editor, OWLViz as visualization tool, and Pellet as reasoner. The ontology using OWL-DL language.

2 REQUIREMENT
In IEEE Standard Glossary of Software Engineering Terminology, defined that requirement is a condition or capability needed by an user to solve a problem or achieve an objective [3]. The requirement is a necessary, quantifiable, and verifiable. Requirement indicates the software behaviour, function, property, characteristic, constraint, satisfaction in problem solving to achieve an objective [4]. Requirements are distinguished into functional and non-functional requirements. Functional requirements are functional capabilities and behaviours, from a product; non-functional requirements identify constraints that product has to satisfy (quality of product). Nonfunctional requirements always indentify CPU utilization, data, interfaces, memories, operations, performances, measurements, and timing requirement [5]. Requirements can be elicited from any resources, i.e. stakeholders, organizations standards, regulations, domain information, and documents. Also, requirements can be recovered from existing software by reverse engineering process as software artefact. Requirements should be implemented in software as solution of problem. Requirements and features are solution domain for problem domain that expressed as need (Error! Reference source not found.). Needs are the stakeholders needs in the certain problem domain. Features will fulfill the needs, and requirements as capability that will be given by software [6].

Elviawaty M. Zamzami is with the Department of Computer Science, University of Sumatera Utara, Medan, 20155, Indonesia. Eko K. Budiardjo is with the Faculty of Computer Science, University of Indonesia, Depok, 16424, Indonesia. 2012 JCSE www.Journalcse.co.uk

Fig. 1. Requirements seen as solution of problem [6].

In the existing software, implementation of requirements can be known among others from software users, software behaviours or features, also interaction between users and software. Requirements that have been analyzed to be software capability are collected in software requirements specification.

Use case provides developer a way to determine a general understanding with end users and domain experts. Also, use case helps to validate architectures, and verify a system during development [Booch et.al, 1999]. The use case model contain of actors, use cases, and relation between them. The actors represent something that should exchange information with system. When an actor use the system, so system do an use case (Jacobson et.al. at Object-Oriented Software Engineering A Use Case Driven Approach, Addison Wesley ACM Press, 1992). Some definitions that relate to use case are the following [7]: a. Use case model, model presents the actors and their objective that achieved through software. b. Use case, shows the interaction between actor and software to obtain observable result of value to the actor. c. Flow, shows sequence of steps within a use case describes a set of steps between within a use case (Error!

3 SRS
Software Requirement Specification (SRS) contain functions and system capabilities that must be developed and fulfilled. Other than that, SRS describes the development restrictions that must be obeyed. SRS is base for next phases in software development. SRS is usually contained in document. There is no standard of name for this document. In the different organization, document may be named differently like as requirements documents, functional specification, system requirements specifications, etc. Although using the different name, requirements document (in software context) describes the following [5]: a. The services and functions of software. b. The constraints of software must operate. c. Properties of the software. d. Definition of other software that integrated. e. Information about the software domain. f. Constraints of process to develop the software. Requirements documents can be represented in many forms, i.e. text, model, and prototype. Documents can also include diagram because they are considered easy to learn. The example of diagram that can be used is use case.

Fig. 2. Flow at use case [7].

4 RMUC
RMUC is abbreviation of Requirements Management with Use Case. Thus, requirements management is represented using use case. Use case represents requirements with perspective an actor achieve the goal. Use case is an important part of UML (Unified Modeling Language) notation to explain external behaviour of software. Use case is a sequence of transaction that produce a result that observable of value for an actor. Collection of use cases is complete functionality that had by system.

Reference source not found.). d. Basic flow, shows the main and simple steps within use case to achieve the goal. e. Alternate flow, shows steps that take the route outside of the basic flow to achieve the goal, errors, and the others. f. Scenario, a path of steps through use case, consist the basic flow and one or more alternate flows. The graphical use case representation only presents an overview of requirements. Use case should be combined with the textual representation of use case that describes input-output scenarios with all their possible variants and exceptions [8]. Use case completely useful if using with activity diagrams. Activity diagram is the special case of state diagram. Activity diagram is a model that describes a collection of the different states of an object during its life and condition to change from one state to the other. Besides in use case form, requirements can also be represented as requirements ontology.

5 REQUIREMENTS ONTOLOGY
Requirements can be represented formal or informal. Representation using natural language include in the informal representation, so more easy readable and learn by humans, but difficult by computers. Informal representa-

tion can inflict ambiguity. Therefore, necessary the formal representations. One of them is using ontology. An ontology describes base concept in a domain and define relation among them. Ontology contain the following: a. Class or concept. b. Properties of each concept describe variety of feature and attribute of concept (sometimes called as slot, role, or property). c. Restriction at slots (sometimes called as facets or role restrictions). Requirements ontology can represents [9]: a. Functional hierarchy of the software. b. Relationships among the functional requirements. c. Properties of functional requirements. In this paper, requirements ontology is used to documenting SRS. Ontology contains definitions that can be interpreted by machine (computer) about base concept in domain and relation among them. Fensel said that in ontology, conceptualization stand for an abstract model, explicitly means element defined clearly, and formally means ontology should be able to processed by machine [10]. Using ontology, domain knowledge can be represented generally and provide common view and understanding of the domain. W3C recommends that ontologies are usually expressed using a logic-based language, so detail, accurate, consistent, sound, and significant different can be made among classes, relations, and properties [11]. This research using OWL-DL as ontology language. One ways to presenting or documenting the requirements is use ontology template that has been built. Authors as researchers have built the R2UC ontology template that can be a SRS document.

model.

Fig. 3. The 1 Level of R2UC Ontology Model.

st

From the 1st level, ontology expanded be 2nd level of R2UC ontology as Error! Reference source not found.. The 2nd level presents software requirements are specified by supplementary specification and use case model. They are part of SRS (Software Requirements Specification) with RMUC-RUP format.

6 R2UC ONTOLOGY
R2UC (Requirements Representation with Use Case) ontology is an ontology to presents software requirements that interpret user, interaction through interface, and features. The features fulfill the stakeholders needs as problem solution. The R2UC ontology can be used to documenting requirements that will be implemented in software engineering and forward engineering processes, also documenting requirements from existing software through reverse engineering processes. Using the R2UC ontology, software requirements are presented semi formally. Also, the R2UC ontology can provide structure of software requirements specification (SRS) that refers to RUP as SRS document.

Fig. 4. The 2 Level of R2UC Ontology Model.

nd

Finally, the 2nd level of R2UC ontology is expanded be 3rd level of R2UC ontology as Error! Reference source not found.. The 3rd level represents detailly how the software requirements are specified in the elements of SRS. Brief descriptions about elements of R2UC ontology are contained at Table 1. These elements refer to RUP formats [12].

6.1 R2UC Ontology Model

R2UC ontology modeled with three (3) levels. The 1st level presents software requirements that interpret features to fulfill needs as solution to the problem. Error! Reference source not found. provide the 1st level of R2UC ontology

Fig. 5. The 3 Level of R2UC Ontology Model.

rd

TABLE 1 DESCRIPTION OF ELEMENTS OF R2UC ONTOLOGY

Type of Element Element of RMUC Ontology Problem Domain Needs Description The problems that appear in the domain Stakeholders needs that reflect problem domain. Services to fulfill stakeholders needs. Capabilities to be provided by software as the features interpretation. Contain use case that specifies functional requirements. Description briefly conveys the role and purpose of the use case. Describes what the most common usage of the system will be. Describes steps that deviate from the basic flow due to other means of achieving the goal, errors, etc. Type of Element

TABLE 1 DESCRIPTION OF ELEMENTS ... (CONT.)

Element of RMUC Ontology Description Typically a non-functional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use cases event flow. The state of the system that must be present prior to a use case being performed. A list of possible states the system can be in immediately after a use case has finished. Extension points of the use case.

Special Requirements

Features

Requirements

Use Case Model

Pre- Condition

Class

Use Case Model

Use Case Name

Post- Condition

Use Case Model

Basic Flow

Extension Points

Alternative Flow

TABLE 1 DESCRIPTION OF ELEMENTS ... (CONT.)

Type of Element Element of RMUC Ontology Supplementary Specification Description Captures requirements that are not included in the use case. Represents functional requirements of the system that expressed in the natural language style. Includes all of those requirements that affect usability. Includes requirements for reliability of the system. Includes the systems performance characteristics. Indicates any requirements that will enhance the supportability or maintainability of the system being built. Represents design decisions that have been mandated and must be adhered to. Domain is reflected by range. Domain is fulfilled by range. Domain is interpreted by range. Domain is specified by range. Domain consists of range(s). Domain has range(s).

Fig. 6. The 1 Level of R2UC Ontology Implementation.

st

Functionality

Usability

Reliability Class Supplementary Specification Performance

Fig. 7. The 2 Level of R2UC Ontology Implementation.

nd

Supportability

Design Constraint

ReflectedBy FulfilledBy InterpretedBy Property SpecifiedBy ConsistOf Has

Fig. 8. The 3 Level of R2UC Ontology Implementation.

rd

6.2 R2UC Ontology Implementation

R2UC ontology implemented using OWL DL language. OWL DL (Description Logic) is a sublanguage of OWL. One of key features using OWL is the ontology that using it can be processed by a reasoner. The graphical tool that use to edit the ontology is Protg 3.4.8. Elements in the R2UC ontology that are modeled as rectangles, are implemented as classes. Relation between an element to other element, in the R2UC ontology is modeled as an arrow. These arrows implemented as properties. Thus, R2UC ontology models are implemented like as screenshots at Fig.6., Fig. 7., Fig.8., and Fig.9.
Fig. 9. The properties of R2UC Ontology Implementation.

7 TRANSFORMATION INTO R2UC ONTOLOGY

Transformation into R2UC ontology consist of procedure

of transformation the use case model into R2UC ontology and procedure of transformation into the other elements of R2UC ontology template.

7.1 Transformation Into Actor

Procedures of transformation into Actor are following: a. Check sub class Actor. If not found the intended actor, do the step b and c. b. Create a sub class to class Actor. c. Give name the sub class that accordance with the actor (user that do action).

c. If not found the alternative flow, create sub class to class Alternative Flow. The sub class is named as AF-none, and only once.

7.7 Transformation Into Pre-Condition

Procedures of transformation into Pre-Condition are following: a. Create a sub class to class Pre-Condition. b. If not known, the sub class be named as Pre-any kind. Only created once. Else, the sub class be named as Pre-<brief info>. <brief info> contain brief information about the pre-condition.

7.2 Transformation Into Use Case Model

Procedures of transformation into Use Case Model (UCM) are following: a. Create a sub class to class Use Case Model, give name as UCM-1..n. Only once before transformation Use Case Model-1. This sub class contains all of the UCM. b. Create a sub class to class UCM-1..n, then be named refer to UCM-n-<name of UCM>; n=1..n. UCM-n represents an use case diagram that contains use case and actor. Example, UCM-1-User Authentication will represents UCM-1 to user authentication.

7.8 Transformation Into Post-Condition

Procedures of transformation into Post-Condition are following: a. Create a sub class to class Post-Condition. b. If not known, the sub class be named as Post-any kind. Only created once. Else, the sub class be named as Post-<brief info>. <brief info> contain brief information about the post-condition.

7.3 Transformation Into Use Case

Procedures of transformation into Use Case are following: a. Create a sub class to class Use Case, give name as UC-1..n. Only once before transformation Use Case Model-1. This sub class contains all of the UC. b. Create a sub class to class UC-1..n, then be named refer to UCM-n-<name of UCM>; n=1..n.

7.9 Transformation Into Special

Requirements

7.4 Transformation Into Use-Case Name

Procedures of transformation into Use-Case Name are following: a. Create a sub class to class Use-Case Name. b. The sub class be named refer to UCName-n-<name of UC>; n=1..n.

Procedures of transformation into Special Requirements are following: a. Create a sub class to class Special Requirements, if not known, be named as SR-none (only once) else SR-n; n=1..n. b. Create sub class to class SR-n, be named refers to SRn-a-<brief info>. a, index of sequence of special requirements. <brief info> contain brief information about the post-condition.

7.10 Transformation Into Extension Points

Procedures of transformation into Extension Points are following: a. Create a sub class to class Extension Points, if not known, be named as EP-none (only once) else EP-n; n=1..n. b. Create sub class to class SR-n, be named refers to EPn-a-<brief info>. a, index of sequence of extension points. <brief info> contain brief information about the extension points.

7.5 Transformation Into Basic Flow

Procedures of transformation into Basic Flow are following: a. Create a sub class to class Basic Flow. The sub class be named refer to BF-n, n should appropriate to UC index that has the basic flow. b. Create a sub class of BF-n. Give name of sub class using format BF-n-a-<brief info>, a start from 1 and <brief info> contain brief information about the basic flow.

7.11 Transformation Into Software

Requirements

7.6 Transformation Into Alternative Flow

Procedures of transformation into Alternative Flow are following: a. Create a sub class to class Alternative Flow. The sub class be named refer to AF-n, n should appropriate to UC index that has the alternative flow. b. Create a sub class to AF-n. Give name of sub class using format AF-n-a-b-<brief info>. In the format, a is an index of BF where AF started, a start from 1 and <brief info> contain brief information about the alternative flow.

Procedures of transformation into Software Requirements are following: a. Create a sub class to class Software Requirements, be named as SW Req1..n (only once). b. Create sub class to class SW Req1..n, be named using format SW Req-n-<brief req>, n=1..n. <brief req> reflects requirement that contained in this class.

7.12 Transformation Into Features

Procedures of transformation into following: a. Create a sub class to class Feature. Features are

b. Give name the sub class refers to format <brief feature>, where the <brief req> reflects feature that contained in this class.

7.13 Transformation Into Needs

Procedures of transformation into Needs are following: a. Create a sub class to class Need. b. Give name the sub class refers to format <brief need>, where the <brief need> reflects need that contained in this class.
Fig. 11. Example of UCM in the R2UC Ontology.

existing software in reverse engineering. Requirements from existing software that presented in the R2UC ontology can support to reconstruct the existing requirements document.

7.14 Transformation Into Domain Problem

Procedures of transformation into Domain Problem are following: a. Create a sub class to class Domain Problem. b. Give name the sub class refers to format <brief problem>, where the <brief problem> reflects domain problem that contained in this class.

9 CONCLUSION
The R2UC ontology that has created by authors is an ontology that presents software requirements. The R2UC ontology can provide structure of software requirements specification using use case. Thus, it will support to build SRS document that using use case, e.g. document using RUP format. The R2UC ontology can be used to documenting software requirements that used in software engineering or forward engineering. Also, software requirements from existing software that recovered through reverse engineering can be documented using the R2UC ontology. Documenting the SRS using R2UC ontology have some benefit, i.e. readable by machine, can generate to particular code, easy to check inconsistency elements of SRS.

7.15 Complete the Transformation

Transformation into elements of the R2UC ontology should be completed using procedures are below: a. Write the comment in rdfs:comment to the sub class that added. b. Create restriction at appropriate properties. The examples of the transformation can be seen at Fig. 10. and Fig.11. Result of transformation as the use case specification is visualized at Fig.10, and as the use case model is visualized at Fig.11.

REFERENCES

8 FUTURE RESEARCH
The R2UC ontology not only documenting requirements in

Fig. 10. Example of UC Specification in the R2UC Ontology.

S. A. Fahmi and Ho-Jin Choi, Software Reverse Engineering to Requirements, http://www.computer.org, IEEE, 2007. [2] R.S. Pressman, Software Engineering A Practitioners Approach, Fifth Edition, Mc Graw Hill, 2001. [3] IEEE, IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.121990, http://ieeexplore.ieee.org/, 1990. [4] R. K. Kandt, Software Requirements Engineering: Practices and Techniques, http://www.whalen.ws/ index_files/JPL_SW_Reqmts_Engr_D24994%5B1%5D.pdf, 2003. [5] Gerald Kotonya and Ian Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons Ltd, 1998. [6] Dean Leffingwell and Don Widrig, Managing Software Requirements, Addison Wesley, 1999. [7] Richard Ouellette, Mastering SW Quality Starts with Requirements Management & Use Case Best Practices, IBM Rational Software. [8] Peter Haumer, Part2: Techniques. Use Case Based Software Development, IBM Rational Software, http://haumer.net/paper/UCBased_Software_Development.p df. [9] D. V. Dzung and A.Ohnishi, Improvement of Quality of Software Requirements with Requirements Ontology, 2009 Ninth International Conference on Quality Software, IEEE, 2009. [10] D. Fensel, Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce, Springer, 2001. [11] W3C, OWL Web Ontology Language Use Cases and Requirements, http://www.w3.org/TR/webont-req/, 2003. [12] RUP, Software Requirements Specification Templates. [1]

software engineering, but also

the requirements from

Elviawaty M. Zamzami graduated from Bandung Institute of Technology (Indonesia), magister of informatics, 2000. Student of doctoral of computer science at University of Indonesia, 2009 - now. She is a lecturer at Department of Computer Science, University of Sumatera Utara, Indonesia. Current research interests in reverse engineering, requirements recovery and ontology. Dr. Eko K. Budiardjo has been the faculty member of the Faculty of Computer Science - University of Indonesia since 1985. Teaching, research, and practical services are aligned, resulting a full spectrum of academic achievement. Majoring in Software Engineering as professional track record, he has made some scientific contribution such as Software Requirement Specification (SRS) patterns representation method and Front CRM Framework. Graduated from Bandung Institute of Technology (ITB) in 1985, holds Master of Science in Computer Science from the University of New Brunswick Canada in 1991, and awarded Philosophical Doctor in Computer Science from the University of Indonesia in 2007. Currently he is one of The National Research Council (DRN) member on ICT Commission, member of ICT Evaluation Working Group of The National ICT Council (DetikNAS), and Chairman of IPKIN.