Nowadays many software companies still suffer from dealing with low quality software requirements specification. They need some mechanisms to improve their requirements engineering activities. In this paper we discuss how we face this issue, presenting our STARS methodology. Its foundation relies on the concept of Validation Item (VI) and its steps and most expressive benefits are highlighted.

1. Validation Item – Stating Requirements at the Adequate Level of Detail
André Luiz Alves; Edwagney Inácio da Silva Luz
Qualyx Software e Soluções Ltda
Goiânia, Brazil
{andre.luiz, edwagney}@qualyxsolucoes.com
Abstract—Nowadays many software companies still suffer recognized by software engineers [2] [3] [4], but some
from dealing with low quality software requirements difficulties in adopting good practices still persists. One of
specification. They need some mechanisms to improve the causes we identified is the inability in declaring
their requirements engineering activities. In this paper requirements at the adequate level of detail. Besides, a good
we discuss how we face this issue, presenting our STARS specification requirements document must serve as the basis
methodology. Its foundation relies on the concept of for establishing the software product acceptance criteria [3].
Validation Item (VI) and its steps and most expressive Relevant information and quality requirement attributes that
benefits are highlighted. must be present in a requirement specification have been
proposed by many authors [3] [4] [5] as well as
Keywords-requirements specification; atomic requirements; recommendations [6]. One important reference we consider
validation item. is presented by Davis et al. [7] which establish 24 quality
characteristics for a quality SRS. The quality we consider of
I. INTRODUCTION great importance, and also strongly subjective, is: “the
requirement must be declared at the adequate level of detail”.
Quality Assurance (QA) is one of the most important This characteristic is also emphasized by [6] and [7].
Software Engineer knowledge areas and it has been the Declaring requirements at the adequate level of detail
target of many approaches, techniques and methodologies. contributes for solving the right problem [8] [9] and make
Although many of them have been successful, a gap still possible clearly establish the software product acceptance
remains: the conception of quality between Stakeholders’ criteria [10]. The IEEE-1233 [11] standard established the
and software engineers’ points of view. We developed a named Atomic Requirements and some authors have been
methodology named STARS which uses the Validation Item proposed approaches [12] [13] and applied them in some real
(VI) to address this point. In other words, we intend to cases [14].
contribute to close this gap.
V. THE METHODOLOGY
II. THE APPROACHED SCENARIO
The STARS methodology was developed based on
The scenario most frequently present in many software aforementioned bibliography and our professional
companies is characterized by the absence of a really good experience and can be basically described by the following
requirements specification document. In some of them, there steps:
are no more than textual specifications containing
requirements at different levels of abstraction and detail, A. Extract Users’ Requirements (UR) from the existing
business rules and also some functional specification stating documentation
technical solutions. This High Level Description (HLD) Usually, in the existing software specification, like HLD
document is far from a basis to produce a correct and documents, requirements at different levels are mixed to
complete software product that reaches the users needs and functionalities and, sometimes, business rules. Through a
stakeholders’ expectations. detailed analysis we extract and document the users’
requirements. In addition, at the same time we identify and
III. THE PROBLEM adequately separate what is functionality and business rules.
This scenario leads to a common and recurrent problem:
a great amount of additional work conducted by software B. Derivate Atomic Requirements (AR) associated to the
developers caused by the constant changes in requirements extracted UR
during the software development. The consequence is known The focus is to analyze each user requirement in order to
by everyone in software industry. identify and record the atomic requirements associated to it.
This activity means to clearly declare measurable, testable,
IV. FACING THE PROBLEM traceable and detailed enough requirement to define all
The requirements engineering area have been growing aspects of a need without further breakdown.
and its importance is undeniable [1]. The benefits of a good
Software Requirements Specification (SRS) document are

2. C. Identify Validation Items existing in each AR and maintains the high degree of traceability assuring high
Validation Item is each element that characterizes the cohesion through the existent information. The second one
atomic requirement and can be associated to a value or a refers to the quality assurance through the possibility to
range of values, including logical values. Logical values consider the information obtained by STARS methodology
comprehend affirmative and negative conditions that validate to the test cases generation.
the atomic requirement. This information makes the atomic ACKNOWLEDGMENT
requirement measurable and, as a consequence, testable.
We would like to thank the following companies that
D. Establish the Validation Conditions (VC) for each VI allow us to apply the STARS methodology: Atos Origin
The Validation Condition is each value, or range of Brasil, Decisão Sistemas, Information and Communication
values, or logical values, that qualifies and validates (each Technology Department of Pontifícia Universidade Católica
part of) the validation item. The set of validation conditions de Goiás – Brasil. Our researches are sponsored by Qualyx
related to each validation item result in the VI scope totally Software e Soluções Ltda.
covered.
VI. REACHED RESULTS REFERENCES
Applying STARS methodology in the software industry [1] G. Kotonya and I. Sommerville, Requirements Engineering:
has shown that it brings various practical benefits. The most Processes and Techniques, England: John Wiley & Sons,
1998.
expressive are listed bellow:
[2] R. H. Thayer, “Software System Engineering: An Engineering
 The way that it drives the “reading” of existing Process,” Software Requirements Engineering, 2nd ed.,
documentation (including business process California, IEEE Computer Society Press, 1997, pp 84-106.
diagrams, for example, if it exists) to identify [3] M. Dorfman, “Requirements Engineering,” Software
requirements and functionalities. This is a Requirements Engineering, 2nd ed., California, IEEE
consequence of the adopted perspective, i.e., by Computer Society Press, 1997, pp 7-22.
looking for the validation items. [4] S. R. Faulk, “Software Requirements: A Tutorial,” Software
 The identification of requirements that were Requirements Engineering, 2nd ed., California, IEEE
Computer Society Press, 1997, pp 128-149.
“invisible” in the documentation, but that became
[5] R. Harwell et al, “What is A Requirement?”, Proceedings of
explicit by grouping the validation items related to the Third Annual International Symposium, National Council
them. In this sense, it works as an elicitation on Systems Engineering, 1993.
technique. [6] IEEE Std 830-1998, IEEE Recommended Practice for
 The improving quality of the scope. The scope Software Requirements Specifications, New York. IEEE
definition became more clear and consistent, Computer Society Press, 1998.
providing a better knowledge and evidencing [7] A. Davis et al, “Identifying and Measuring Quality in a
eventual need of adjusts. Software Requirements Specification,” First International
Software Metrics Symposium, 1993.
 The production of a better quality SRS document.
[8] J. Rumbaugh, “Getting Started - Using Use Cases to Capture
 The explicit declaration of requirement satisfaction Requirements,” Journal of Objet Oriented Programming,
criteria through the validation items and its September, 1974.
validation conditions. [9] B. W. Boehm, “Verifying and Validating Software
 The contribution for an effective discipline to Requirements and Design Specifications,” IEEE Software,
develop Requirements Engineering activities. VOl1. Nº. 1, Jan 1984, pp 75-88.
[10] R. T. Yeh and P. A. Ng, “Software Requirements A
Management Perspective. System and Software Requirements
VII. LOOKING FORWARD Engineering,” R.H. Thayer and M. Dorfman eds., 1990.
[11] IEEE 1233-1998, IEEE Guide for Developing System
The aforementioned benefits allow us foresee two groups Requirements Specifications, New York. IEEE Computer
of research and application concerns: The first is regarding to Society Press, 1998.
the Requirements Engineering activities. In this sense, we [12] S. Robertson and J. Robertson, Mastering the Requirements
intend to enlarge the application of traceability in practice by Process, 2nd ed, Massachusetts, Addison Wesley, 2006.
establishing relationships among, business process, business [13] H. Salzer, “ATRs (Atomic Requirements) - Used Throughout
activities in the business process, users’ requirements Development Lifecycle,” RTS Software Ltd., Israel, 1999.
associated to the business process activities and then, to the [14] H. Salzer and I. Levin, “Atomic Requirements in Teaching
Logic Control Implementation,” International Journal of
atomic requirements. Thus, this relevant chain establishes Engineering Education, 2004.