Linguistic Patterns and Linguistic Styles for Requirements Specification (I)

Abstract

System requirements specification describes technical concerns of a system and is used throughout the project life-cycle. specification helps sharing the system vision among its stakeholders, as well facilitating the communication, project management and system development processes. For an effective communication, everyone communicates by means of a common language, and natural language provides the foundations for such language. Although natural language is the most common and preferred form of requirements representation, it also exhibits intrinsic characteristics that often present themselves as the root cause of many requirements quality problems, such as incorrectness, inconsistency, incompleteness and ambiguousness.This paper presents the RSL (short name for Requirements Specification Language) which is a language to improve the production of requirements specifications in a more systematic, rigorous and consistent way. RSL includes constructs logically arranged into views according to the specific requirement engineering concerns they address. These constructs are defined as linguistic patterns and are represented textually by multiple linguistic styles. Due to space constraints, this paper focuses only on its business level constructs and views, namely on glossary terms, stakeholders, business goals, processes, events and flows. RSL can be used and applied by different types of users such as requirement engineers, business analysts, or domain experts. They can produce system requirements specifications with RSL at different level of detail, considering different writing styles and different types of requirements (e.g., business goals, system goals, functional requirements, quality requirements, constraints, user stories, and use cases). In addition, they can use other types of constructs (e.g., terms, stakeholders, actors, data entities) that, in spite of not being requirements, are important to complement and enrich the specification of such requirements. Based on a simple running example, we also show how RSL users (i.e., requirements engineers and business analysts) can produce requirements specifications in a more systematic and rigorous way.