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 Protégé as graphical tools, OWLViz as visualization tool, and Pellet as reasoner.

Index Terms—Requirements, Software Requirements Specification (SRS), RMUC, R2UC, Requirements Ontology.

—————————— u ——————————

1 INTRODUCTIONNE 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 what’s 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). Non-functional 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, do-main information, and documents. Also, requirements can be recovered from existing software by reverse engi-neering process as software artefact.

Requirements should be implemented in software as solution of problem. Requirements and features are solu-tion domain for problem domain that expressed as need (Error! Reference source not found.). Needs are the stake-holders needs in the certain problem domain. Features will fulfill the needs, and requirements as capability that will be given by software [6].

O

———————————————— • 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

2

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

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

3 SRS Software Requirement Specification (SRS) contain functions and system capabilities that must be developed and ful-filled. 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 or-ganization, document may be named differently like as requirements documents, functional specification, system requirements specifications, etc. Although using the dif-ferent 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.

4 RMUC

RMUC is abbreviation of Requirements Management with Use Case. Thus, requirements management is repre-sented using use case. Use case represents requirements with perspective an actor achieve the goal.

Use case is an important part of UML (Unified Model-ing Language) notation to explain external behaviour of software. Use case is a sequence of transaction that pro-duce a result that observable of value for an actor. Collec-tion of use cases is complete functionality that had by system.

Use case provides developer a way to determine a general understanding with end users and domain ex-perts. 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 re-lation 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 follow-ing [7]: a. Use case model, model presents the actors and their ob-

jective that achieved through software. b. Use case, shows the interaction between actor and

software to obtain observable result of value to the ac-tor.

c. Flow, shows sequence of steps within a use case de-scribes a set of steps between within a use case (Error!

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 oth-ers.

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 dia-grams. Activity diagram is the special case of state dia-gram. Activity diagram is a model that describes a collec-tion 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. Re-presentation using natural language include in the infor-mal representation, so more easy readable and learn by humans, but difficult by computers. Informal representa-

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

3

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 fol-lowing: 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 on-tology 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.

6 R2UC ONTOLOGY

R2UC (Requirements Representation with Use Case) ontology is an ontology to presents software require-ments 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 for-mally. Also, the R2UC ontology can provide structure of software requirements specification (SRS) that refers to RUP as SRS document.

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

model.

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.

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].

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

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

4

Type of Element Element of RMUC Ontology Description

Use Case Model

Special Requirements

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 case’s event flow.

Pre- Condition

The state of the system that must be present prior to a use case being per-formed.

Post- Condition

A list of possi-ble states the system can be in immediately after a use case has finished.

Extension Points Extension points of the use case.

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

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

TABLE 1 DESCRIPTION OF ELEMENTS OF R2UC ONTOLOGY

Type of Element Element of RMUC Ontology Description

Class

Problem Domain The problems that appear in the do-main

Needs Stakeholders’ needs that reflect problem domain.

Features Services to fulfill stakeholders’ needs.

Requirements Capabilities to be provided by soft-ware as the features interpretation.

Use Case Model Contain use case that specifies func-tional require-ments.

Use Case Model

Use Case Name Description briefly conveys the role and purpose of the use case.

Basic Flow Describes what the most common us-age of the system will be.

Alternative Flow

Describes steps that deviate from the basic flow due to other means of achieving the goal, errors, etc.

5

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 Protégé 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 implement-ed like as screenshots at Fig.6., Fig. 7., Fig.8., and Fig.9.

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.

Type of Element Element of RMUC Ontology Description

Class

Supplementary Specification Captures re-quirements that are not included in the use case.

Supplemen-tary Specification

Functionality

Represents func-tional requirements of the system that expressed in the natural language style.

Usability Includes all of those require-ments that affect usability.

Reliability Includes require-ments for reliabil-ity of the system.

Performance Includes the sys-tem’s perfor-mance charac-teristics.

Supportability

Indicates any requirements that will enhance the supportability or maintainability of the system being built.

Design Con-straint

Represents de-sign decisions that have been mandated and must be adhered to.

Property

ReflectedBy Domain is reflect-ed by range.

FulfilledBy Domain is ful-filled by range.

InterpretedBy Domain is inter-preted by range.

SpecifiedBy Domain is speci-fied by range.

ConsistOf Domain consists of range(s).

Has Domain has range(s).

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

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

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

Fig. 9. The properties of R2UC Ontology Implementation.

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

6

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).

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.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.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.

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.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.

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.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.9 Transformation Into Special Requirements

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 SR-n-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 EP-n-a-<brief info>. a, index of sequence of extension points. <brief info> contain brief information about the extension points.

7.11 Transformation Into Software Requirements

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 Features are following: a. Create a sub class to class Feature.

7

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.

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.

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.

8 FUTURE RESEARCH The R2UC ontology not only documenting requirements in

software engineering, but also the requirements from

existing software in reverse engineering. Requirements from existing software that presented in the R2UC on-tology can support to reconstruct the existing require-ments document.

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 re-quirements 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 engineer-ing or forward engineering. Also, software require-ments 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.

REFERENCES [1] 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 Practitioner’s

Approach,” Fifth Edition, Mc Graw Hill, 2001. [3] IEEE, “IEEE Standard Glossary of Software Engineering Terminolo-

gy,” IEEE Std 610.121990, http://ieeexplore.ieee.org/, 1990. [4] R. K. Kandt, “Software Requirements Engineering: Practices

and Techniques,” http://www.whalen.ws/ in-dex_files/JPL_SW_Reqmts_Engr_D24994%5B1%5D.pdf, 2003.

[5] Gerald Kotonya and Ian Sommerville, “Requirements Engineer-ing: Processes and Techniques,” John Wiley & Sons Ltd, 1998.

[6] Dean Leffingwell and Don Widrig, “Managing Software Re-quirements,” Addison Wesley, 1999.

[7] Richard Ouellette, “Mastering SW Quality Starts with Re-quirements Management & Use Case Best Practices,” IBM Ra-tional Software.

[8] Peter Haumer, “Part2: Techniques. Use Case – Based Software Development, IBM Rational Software,” http://haumer.net/paper/UCBased_Software_Development.pdf.

[9] D. V. Dzung and A.Ohnishi, “Improvement of Quality of Soft-ware 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 Require-ments,” http://www.w3.org/TR/webont-req/, 2003.

[12] RUP, “Software Requirements Specification Templates”.

Fig. 11. Example of UCM in the R2UC Ontology.

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

8

Elviawaty M. Zamzami graduated from Bandung Institute of Tech-nology (Indonesia), magister of informatics, 2000. Student of doc-toral of computer science at University of Indonesia, 2009 - now. She is a lecturer at Department of Computer Science, University of Su-matera 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 pro-fessional track record, he has made some scientific contribution such as Software Requirement Specification (SRS) patterns representa-tion 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.