Utilising Perspectives to Improve Completeness in Industrial Requirements Specifications

Abstract

In projects with requirements-related troubles the reason is often plainly that too little effort has been spent on requirements engineering (RE). Our varied industrial experience repeatedly showed, however, that even in projects with plenty of RE-budget and -efforts spent numerous problems are often found during acceptance testing that can still be traced back to incomplete or even missing requirements. How is that possible? After observing this repeatedly throughout more than eight years of industrial experience we performed a careful, in-depth qualitative analysis on the underlying root causes that lead us to the hypothesis we present in this paper: requirements engineers often tacitly lay a strong focus on one particular perspective in text-based requirements documentation, while the others typically remain un- or underspecified. Thus, incompleteness arises. In this paper we summarise our observations and present a solution idea that more explicitly considers the different perspectives during the RE process. This can significantly increase requirements completeness, lead to an improved overall balancing of RE efforts and, hence, also lead to higher chances for project success.

Full text

Utilising Perspectives to Improve Completeness in
Industrial Requirements Specifications
Reinhard Stoiber
Stoiber Informatik GmbH, Canton of Zurich, Switzerland
Web: https://www.stoiber-informatik.ch, Mail: reinhard.stoiber@stoiber-informatik.ch
Abstract—In projects with requirements-related troubles the
reason is often plainly that too little effort has been spent on
requirements engineering (RE). Our varied industrial experience
repeatedly showed, however, that even in projects with plenty
of RE-budget and -efforts spent numerous problems are often
found during acceptance testing that can still be traced back to
incomplete or even missing requirements. How is that possible?
After observing this repeatedly throughout more than eight years
of industrial experience we performed a careful, in-depth quali-
tative analysis on the underlying root causes that lead us to the
hypothesis we present in this paper: requirements engineers often
tacitly lay a strong focus on one particular perspective in text-
based requirements documentation, while the others typically
remain un- or underspecified. Thus, incompleteness arises. In this
paper we summarise our observations and present a solution idea
that more explicitly considers the different perspectives during
the RE process. This can significantly increase requirements
completeness, lead to an improved overall balancing of RE efforts
and, hence, also lead to higher chances for project success.
I. INTRODUCTION
Both developing software without understanding the re-
quirements as well as spending too much time trying to
understand the requirements is a waste of time and budget,
according to Al Davis [1]. There’s no magic formula, though,
to determine much effort to spend on RE as it depends on
many things like the problem’s fuzziness, volatility, complex-
ity and the variability of needs between stakeholders.
In our experience seasoned requirements engineers had no
trouble to determine when their requirements understanding
and text-based documentation has reached a stable and suf-
ficient level (analysis paralysis wasn’t observed). Unfortu-
nately, the same experience also showed that major problems
found during acceptance testing could still be traced back
to missing or incomplete requirements documentation. And
yet, the requirements engineers still typically insist that their
documentation is actually complete.
We hypothesise that this is typically due to one strong
focus and a lack of explicit consideration of other perspectives
on the requirements. By perspectives we found the IREB’s
distinction of the three overlapping modeling perspectives
‘data’, ‘functional’ and ‘behavioral’ besides others already
highly feasible [7]. We observed that exhaustive specification
is typically written in one of these, while the others are often
left un- or underanalysed and -specified.
As a solution idea we propose enhancing the RE process
to help the requirements engineer to better consider different
perspectives during RE towards improving completeness.
II. INDUSTRIAL EXPERIENCE
The presented observations are based on the author’s indus-
trial work experience over the last 8+ years as a consultant
in different roles at varied digitalisation projects and clients.
The project experiences ranged from early phase business
consulting, conceptual studies, high-level requirements engi-
neering, project management, system-level requirements and
test engineering, business analysis, application management
and test management to management consulting. Most experi-
ence was gained in acceptance testing roles. The clients were
renowned organisations in the Swiss public domain, primarily
high-reliability and governmental organisations.
III. OBSERVATIONS
Text-based requirements – Natural language was prevalent,
providing the clear advantage that anyone could read and
comprehend the documented requirements.
Standardisation and uniform styles – Styles and foci of
previously successful projects were reused in later projects
and typically led to implicit (and sometimes also explicit) stan-
dardisation in the organisation. This was found beneficial as it
reduced methodological complexity and improved readability.
Uniform styles of written requirements – For example,
“the system shall” statements became omnipresent in the
high reliability domain (behavioral perspective focus). Long
document-style specifications describing details around user
interaction on different screens were found more frequently in
the governmental domain (functional perspective focus). While
the overall standards and styles varied widely much homo-
geneity within particular projects and clients was observed.
Impression of sufficient RE efforts – The domain experts
generally recognised quite well when sufficient RE effort was
made, based on their typical contents and styles followed in
requirements documentation.
Many issues rooted in missing requirements – During accep-
tance testing it was typically surprising that despite a general
impression of having done sufficient RE the system frequently
did not sufficiently meet the end user and business needs. Most
of these missing functional requirements, however, would have
been difficult to specify within the standards and styles used
(i.e., they were not on the perspective in focus).
Every project is different – In one project many problems
arose on user interaction, while correct features were built, but
the end users could not use them the way they needed to. This
project had a strong focus on the behavioral perspective, with
408
2020 IEEE 28th International Requirements Engineering Conference (RE)
2332-6441/20/$31.00 ©2020 IEEE
DOI 10.1109/RE48521.2020.00058

too little RE on the functional perspective. In another project
wrong or missing data fields, contents, and dependencies were
quite frequent, while the overall design and flow was well-
specified. This project had a strong focus on the functional
perspective, with too little RE on the data perspective. Yet
other observed projects were highly successful – they focussed
on just the right perspective/s (possibly by chance and not fully
intentionally). These successes typically reinforced the used
standards and styles for reuse in later projects, while, again,
later projects may or may not bear their major challenges in
these same (combinations of) perspectives.
IV. SOLUTION IDEA
To solve these above-mentioned problems we propose a
solution consisting of two parts. First, an explicit consideration
of perspectives and second, an enhancement of the RE process
(and method) to explicitly apply this consideration.
A. Explicit Utilisation of Perspectives
Our core idea is the explicit consideration of the IREB’s
three perspectives on model-based documentation of require-
ments [7] also in text-based requirements specification and
thereby increase completeness. These are 1) behavioral: how
the software system works, its dynamic behavior, 2) func-
tional: how users and other systems interact via inputs and
outputs with the software system and 3) data: structure, usage
and dependencies of data in the system context.
With regards to our project observations we find it remark-
able how well these three perspectives (despite them being just
three) were already suited to pinpoint on which perspective the
projects major focus was and on which it’s majority of missing
requirements were (precision as well as recall). Therefore, we
hypothesise that explicitly considering these three during RE
can help significantly to – from a RE point of view – turn
potentially endangered projects into more successful ones.
To extend on these three, however, additional perspectives
could help even further. For example, the UML decomposes
models into fourteen distinct and complementary diagram
types [2] – these could also be considered as even more
fine-grained perspectives. Further, BABOK distinguishes re-
quirements more widely into business, stakeholder, solution
and transition requirements [6] – these could help to better
consider perspectives on how the developed system will ideally
be placed in it’s organisational and business context.
Our general goal is to explicitly consider additional perspec-
tives on functional requirements as long as more important and
success-relevant requirements are discovered. The overall RE
process, however, should still be simple, pragmatic and not
overload the domain experts, as follows.
B. Enhancement of the RE Process
To actually utilise these above-mentioned perspectives they
need to be explicitly considered in the RE process and/or
method. The following three approaches may be feasible to
do so. 1) passive methodological support: additional artefacts
like a checklist, for example, could be added to the RE process
to explicitly foster and nudge the requirements engineer to also
consider further perspectives. 2) active support by experts:
a consultant or coach trained in perspectives and complete-
ness evaluation could be positioned to provide targeted and
refined support to the requirements engineer in person. 3)
tool-based support: in case the used RE tool is extensible
targeted interventions to guide the requirements engineer to-
wards considering further perspectives could also be integrated
there. Similarly, previous work by Tang et al. could already
significantly improve software design reasoning by applying a
card approach during in group design sessions [11].
V. R ELATED WORK
Fundamentally, from a cognitive psychology point of view,
the lack of explicit consideration of additional perspectives can
be considered a cognitive bias, particularly a confirmation bias
or an availability bias, as reviewed by Mohanani et al. [10].
On requirements completeness previous work in modeling
includes Heimdahl and Leveson [5] on state-based require-
ments specifications and Ko et al. [8] on use case specifi-
cations. In natural language Ferrari et al. [3] used natural
language processing to improve completeness and Geierhos
and Ba¨
emer [4] have proposed an ontology-based approach.
Menzel et al. [9] further found that use case-based approaches
yield more completeness than text-based approaches.
VI. CONCLUSION
This paper presented how varied experiences showed that
incompleteness in industrial projects is often a result of
insufficient explicit consideration of different perspectives on
requirements. Perspectives are reflected and a solution is
outlined towards more explicitly considering different perspec-
tives during RE. Despite observations on a larger number of
projects the paper’s validity is still limited to a specific regional
area (Switzerland) and specific organisations and domains
(high-reliability and governmental). Future work may inves-
tigate whether these observations generalise to other domains,
areas and cultures, further formalise the presented foundations
and/or concretise these findings with more quantitative studies.
REFERENCES
[1] Davis, Alan Mark. Just enough requirements management: Where soft-
ware development meets marketing. Dorset House, 2005.
[2] Booch, Grady, James Rumbaugh, and Ivar Jacobson. The unified modeling
language user guide. Second edition. Addison Wesley, 2005.
[3] Ferrari, Alessio et al. Measuring and improving the completeness of
natural language requirements. In REFSQ, pp. 23-38. Springer, 2016.
[4] Geierhos, Michaela, and Frederik S. B¨
aumer. How to complete customer
requirements. In NLDB, pp. 37-47. Springer, 2016.
[5] Heimdahl, Mats, et al. Completeness and consistency in hierarchical
state-based requirements, IEEE Trans. Soft. Eng. 22.6: 363-377, 1996.
[6] IIBA R
,A guide to the business analysis body of knowledge R
(BABOK R

Guide), ISBN-13: 978-1-927584-03-3, 2015.
[7] IREB e.V. Certified professional for requirements engineering - founda-
tion level - syllabus, version 2.2.2, 2017.
[8] Ko, Deokyoon et al. Automatic recommendation to omitted steps in use
case specification. Requirements Engineering 24, no. 4: 431-458, 2019.
[9] Menzel, Igor et al. An experimental comparison regarding the complete-
ness of functional requirements specifications. IEEE RE Conf., 2010.
[10] Mohanani, Rahul et al. Cognitive biases in software engineering: a sys-
tematic mapping and quasi-literature review. IEEE Trans. Soft. Eng. 2018.
[11] Tang, Antony et al. Improving software design reasoning – a reminder
card approach. Journal of Systems and Software 144, 2018.
409