SEON: Networked Ontology Specification

Reference Software Requirements Ontology (RSRO)

1. Ontology Description

The Reference Software Requirements Ontology (RSRO) aims at being a reference for software requirements notions. RSRO is centered in the conception of requirement as a goal to be achieved, and addresses the distinction between functional and non-functional requirements, how requirements are documented in proper artifacts, among others. Since RSRO provides the technical concepts for requirements, it is reused in other SEON networked ontologies.

2. Related Ontologies

Networked ontologies used by RSRO:

3. Ontology Models

Figure 1 presents the conceptual model of the RSRO.

Figure 1. RSRO conceptual model.

The main RSRO concept is Requirement. It is a goal, representing the users' needs and expectations (Stakeholder Intention) to be achieved as result of the system development. Requirements can be functional or non-functional. Functional Requirements are the ones defining a function to be available from the target system (e.g. the need for providing a client register or controlling an order). They refer to Software Function Types, i.e. types of functions that the software must provide (e.g., providing a client register, controlling an order). Non-Functional Requirements define criteria or capabilities for the system (e.g. being easy to operate, being in conformance with a standard). A special type of NFR is Product Quality Requirement, which refers to Quality Characteristics that the product shall present in some degree, such as reliability, usability, efficiency.
Requirements are documented by Requirement Artifacts, an Information Item that describes the Requirement in a proper way. The Requirements Document is composed of Requirement Artifacts and related information (such as models, information sources and varied descriptions). This Document is under the responsibility of the Requirements Engineer, a Stakeholder that conducts the requirements development activities. The Requirements Stakeholder represents the Stakeholders from whom the Requirements are collected and, consequently, are the ones interested in the Requirement Artifacts.

4. Concepts Definition

The following table shows the definitions for RSRO concepts.

Concept	Definition
Assumption	Assumptions describe states-of-affairs in the environment of interest that the Stakeholders believe to be true, i.e., they are the propositional content of Stakeholders' Beliefs. They express the belief that a specific situation exists in the environment.
Functional Requirement	Requirement defining a function to be available in the product being built. Ex.: The need for the system to control client orders.
Non-Functional Requirement	Requirement defining criteria or capabilities for the product. Ex.: Being accessible from some specific browsers, Being in conformance with a standard, Performing a function in an established time.
Product Quality Requirement	Non-Functional Requirement referring to a Quality Characteristic of the software product. Ex.: Being accessible from some specific browsers, Performing a function in an established time.
Quality Characteristic	Quality Universal denoting the types of quality characteristics expected in a software. Ex.: reliability, usability, efficiency, maintainability, portability.
Requirement	Goal to be achieved, representing a condition or capacity needed for the system users for solving a problem. Ex.: Providing a product register; Performing a function in an established time.
Requirement Artifact	Information Item describing a Requirement. Ex.: "The system shall provide a product register.", "The system shall control the client orders.", "The system shall be operable from Google Chrome version 32+."
Requirements Document	Document composed of Documented Requirements and related information, as a basis for other technical software processes, including maintenance. Ex.: the Requirements Document of the Alfa Project.
Requirements Engineer	Stakeholder responsible for conducting the requirements development activities. Ex.: an organization employee assigned as Requirements Engineer in the requirements development activities.
Requirements Stakeholder	Stakeholder that provides needs and expectations for the product. Ex.: users, operators, customers, suppliers.
Software Function Universal	Function Universal denoting the types of functions expected in a software. Ex.: Controlling client orders.
Stakeholder Belief	The belief of Requirements Stakeholders regarding the environment of interest that are described in terms of Assumptions.
Stakeholder Intention	The intention of Requirements Stakeholders that defines requirements to be achieved.

Detailed Concepts