On the Systematic Analysis of Natural Language Requirements with CIRCE

Abstract

This paper presents CIRCE, an environment for the analysis of natural language requirements. CIRCE is first presented in terms of its architecture, based on a transformational paradigm. Details are then given for the various transformation steps, including (i) a novel technique for parsing natural language requirements, and (ii) an expert system based on modular agents, embodying intensional knowledge about software systems in general. The result of all the transformations is a set of models for the requirements document, for the system described by the requirements, and for the requirements writing process. These models can be inspected, measured, and validated against a given set of criteria.Some of the features of the environment are shown by means of an example. Various stages of requirements analysis are covered, from initial sketches to pseudo-code and UML models.

Extracting conceptual models from user stories with Visual Narrator

“…CM-builder [27] managed to extract candidate attributes, entities, and relationships from a 220 word text with 73% recall and 66% precision. CIRCE [3] is a sophisticated tool that generates many different models including ERD, UML, and DFD from NL requirements. Experimental application in three case studies indicated improvements in software model analysis and changing requirements.…”

“…3 Aside from generating views that highlight a specific role or relationship, it supports filtering based on agile artifacts. In agile software development, user stories are frequently managed in an issue tracker such as Jira.…”

A systematic review of transformation approaches between user requirements and analysis models

“…After eliminating duplicates, 361 papers remained to be further investigated. After filtering the results (361 papers) of the electronic search by applying the inclusion/exclusion criteria, we identified 11 papers [6,14,19,21,24,25,36,40,48,51,54] to include. The manual search of journals and conference proceedings yielded an additional six primary studies (i.e., [10,17,18,20,47,49]), and two of them (i.e., [18,49]) are more recent discussions and therefore replaced two of the 11 papers identified from the electronic search (i.e., [19,48]).…”

“…A Glossary describes and classifies all the domain-specific terms used in requirements. A Definition [6] defines the notational short hand for expressing requirements in a succinct, practical, and domain-specific way. A Domain model is created to document the key concepts and the vocabulary of an application domain.…”

“…Configurations 2, 3, and 6 require the second largest effort to document requirements. Though configuration 2 [6] does not rely on restricted NL and does not require any specific requirement representation, the difficulty of documenting requirements is still high as users are Is a kind of, is specialization of, is generalization of Inheritance sentences Identify generalization between subject and object [54] Drive, work for, maintain, manage, own, execute, serve, use Action sentences Identify objects and associations [54] Talk to, communicate with, refer to Communication sentences Identify objects and associations [54] Next to, goto Location sentences Identify objects and associations [54] Has (a capability of), has (a capacity for), can, able to has not (a capability of), has not (a capacity for), cannot, not able to Behavioral sentences Identify behaviors [54] a A simple sentence is composed of one subject and one predicate required to manually specify glossary and a significant number of definitions in a specific form. Configuration 3 [54] implies requirements to be manually documented in a non-standard modeling language (OBFS) and the use of restricted NL.…”