Software requirements engineering is an essential activity for the successful development of information systems. Requirements can be specified using different techniques, but taking into account the different stakeholders that have to deal with requirements information, a successful approach has to balance the need to use a widely understood requirements notation, with the importance of eliminating the frequent ambiguity and imprecision, by adding rigor to the specification. In this paper we present the metamodel of a controlled natural language for interactive systems requirements specification, called ProjectIT-RSL, based on the identification of the linguistic patterns that are most frequently used in requirements documents written in natural language.
The development of information systems is a complex process usually initiated with
the identification and specification of the requirements of the system to be developed,
and in particular of its software components. Requirements describe what the system
should do, which is obviously critical for the success of the whole development
process. Several surveys and studies (such as [
Software requirements are normally described using a requirements specification language. These languages can be classified through many perspectives; one that is € The work presented in this paper is partially funded by FCT (Portuguese Research and Technology Foundation), project POSI/EIA/57642/2004 (Requirements engineering and model-based approaches in the ProjectIT research program). particularly interesting for our work is the level of formality used, ranging from the formal initiatives to those completely informal. The ideal solution should combine the benefits of simultaneously using natural language and a precise (not necessarily formal) approach for requirements specification, which leads to the idea of using a controlled natural language. A controlled natural language is a subset of the words used in our common natural language, where the selected terms have their usual meaning, but can also be interpreted in specialized contexts (normally using tools).
As a result of the experience gathered from previous research and practical
projects, the Information Systems Group of INESC-ID [http://gsi.inesc-id.pt/], in Lisbon,
Portugal, started an initiative in the area of requirements engineering, named
ProjectIT-Requirements [
The analysis of the interactive systems requirements can lead to the identification of a number of frequently occurring patterns. Most of the sentences are used to specify what the system should (a verb frequently found in requirements specifications) do, and present an operational perspective of the system. This is why they follow a simple and common structure, where a subject performs an operation (expressed by a verb), which affects an object. More elaborated sentences can also include a condition, which describes a constraint about a simpler fact. So we started with some basic patterns, described below using an EBNF notation; the list presented here is representative of our current requirement patterns and not complete.
<Requirement>: <Simple Requirement> | <Conditional Requirement> <Simple Requirement>: <Subject> <Operation> <Object> <Subject>: <System> | <Actor> <Object>: <Entity> | <Entity property> | <Entity>* | <Entity Property>* <Operation>: <Action> | <Complex Operation> <Action>: <Interaction Action> | <Database Action> | … <Interaction Action>: manages | enters | shows | gets | creates | … <Database Action>: inserts | updates | deletes <Complex Operation>: <Operation>*
The above list introduces the patterns for higher level requirements, but also demonstrates that, using some of them, we can describe detailed operations. One important goal we wanted to achieve is to provide a single (or at least integrated) technique for the specification of early and late requirements. This is also demonstrated by the list of patterns involved in the specification of conditional requirements.
<Conditional Requirement>: <Condition> <Requirement> <Condition>: <Simple Condition> | <Complex Condition> <Simple Condition>: <Condition Type> <Expression> <Comparison> <Expression> <Complex Condition>: <Condition> <Logical Operator> <Condition> <Condition Type>: if | while <Logical Operator>: or | and | not <Comparison>: greater than | less than | equal to | … These simple patterns enable the representation of requirements sentences such as: System manages entities.
User creates invoices.
User enters invoice date.
System gets invoice number.
If invoice total greater than 1000€, then invoice discount equals 10%.
The introduction of rigour in the specification, even when using natural language, imposes some rules that necessarily make a requirements specification different from another used without such restrictions. We can see from the above patterns that we try to simplify the description, for example by eliminating verbs frequently found in requirements specification, such as shall, will or must, or by eliminating words such as the. In this area there are still some issues under discussion, for example, a complete definition about the use of singular or plural forms of verbs.
After the identification of requirement’s patterns for this type of systems, we derived a metamodel that can adequately represent the patterns identified. ProjectIT-RSL is currently a simple language represented by a metamodel and a grammar that defines the rules to map the metamodel’s concepts into sentences, which are validated by the requirements tools.
Type Primitive Types
Entity relates with
Property performs operation Operation specializes
Actor Action
Activity
The main concepts of our language (the ontology) are represented in Figure 1: Actors are active resources (e.g., an external system or an end-user role) that perform operations involving one or more entities.
Entities are static resources affected by operations (e.g., a client or an invoice). Entities have Properties that represent and describe their state.
Operations are described by their respective workflows, which consist of a sequence of simpler Operations that affect Entities and their Properties. Operations are specialized in Actions, which are atomic and primitive (and provided by default by our framework), and Activities, which are not atomic.
The metamodel includes other concepts whose goal is to define the organization of the requirements, and which are represented in Figure 2.
imports
Package
Requirements Module imports Sentence
System Description
All requirements information is expressed in terms of Sentences (which represents every sentence of our text), which can be a Requirement, a Description or a Declaration. These statements are included in requirements documents, which we call Requirements Modules that are specialized in: 1. Packages allow the specification of information about concepts (Actors, Entities,
Operations, Requirements) that can be reused in other requirements documents. 2. A System, which represents a software component (either a complete application or a reusable software component) with which an actor interacts, by executing operations to access or manage entities and their properties.
Requirements describe what the system is expected to do, and are represented by a number of concepts, as Figure 3 shows.
Requirement Other Requirement
Functional Requirement
Non-Functional Requirement Simple Requirement
Conditional Requirement
Condition Actor
Operation
Entity
Requirements are currently specialized in: 1. Functional Requirements are the current focus of our research and specify the functional features of the system; these requirements are themselves specialized into (1) Simple Requirements, which is basically a relationship between an Actor, an Operation and an Entity or an Entity’s Property, and (2) Conditional Requirements, which add a condition to a Simple Requirement. 2. Non-Functional Requirements (e.g., for timing restrictions) 3. Other Requirements (e.g., to include information about the need to use a specific database management system).
Sentence Description
Declaration Entity Description
Actor Description
Entity Declaration
Actor Declaration
Package Declara Operation Description
Operation Declaration
System Declaration
Besides the requirements sentences, a requirements specification in ProjectIT-RSL can also include two other types of sentences, represented in our metamodel by Description and Declaration classes (Figure 4); the first represents the sentences that begin the detailed information about a concept, such as an entity (Entity Description), an actor (Actor Description) or an operation (Operation Description). Declarations represent sentences that enumerate the entities, the operations and the actors of the system (Entity Declaration, Operation Declaration and Actor Declaration, respectively), as well as those name the requirements module being defined, a System or Package (System Declaration and Package Declaration). For simplicity reasons, there are other classes in our current metamodel that are not shown in the above figures, such as the classes that represent the description of the properties of an Entity.
We recognise that there are a number of issues in ProjectIT-RSL that need to be addressed. One of the most important questions still under discussion is the level of resemblance to natural language that we will adopt; the option is between a description very close to natural language (the current option), or one that adopts a style similar to a programming language. Other types of requirements will have to be supported by our language. As Figure 3 has shown, he have already included in the metamodel two classes for Non-Functional Requirements and Other Requirements, for future use. However, as we have not provided any feature in our tools to validate these requirements and to take them into consideration by code generation techniques, they have not been object of current research, which is a situation we will change in the future.
An area considered of prime importance in this project is the support of requirements reuse. Besides the possibility of reusing a previously specified operation in the same requirements module, we have developed other techniques, such as “including” requirements modules in new modules. The information contained in the included module can be reused by the including module. This poses other questions, such as the visibility of the information of the included module, which are currently being discussed.
In our work, we have been influenced by a number of different approaches that
have researched on the elaboration of requirements specification using patterns of
natural language. Approaches such as [
In the near future we will concentrate on the open issues of ProjectIT-RSL, above all in the development of the requirements reuse mechanisms and in advancing tool support. In a further iteration, it is our intention to include support for the specification of the goals of the system, and from them deriving the requirements specification