See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221222111

Challenges of requirements engineering - A case study in nuclear energy

domain

Conference Paper · August 2011

DOI: 10.1109/RE.2011.6051629 · Source: DBLP

CITATIONS READS
16 173

4 authors, including:

Mikko Raatikainen Tomi Männistö

University of Helsinki University of Helsinki
69 PUBLICATIONS   478 CITATIONS    153 PUBLICATIONS   2,044 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

OPENREQ: Intelligent Recommendation & Decision Technologies for Community-Driven Requirements Engineering, EU H2020 project View project

Svamp/Tekes View project

All content following this page was uploaded by Tomi Männistö on 21 May 2014.

The user has requested enhancement of the downloaded file.

2011 IEEE 19th International Requirements Engineering Conference
Challenges of Requirements Engineering – A Case Study in Nuclear Energy Domain
Mikko Raatikainen and Tomi Männistö
Aalto University, School of Science
P.O.Box 19210 00076 Aalto, Finland
mikko.raatikainen@aalto.fi, tomi.mannisto@aalto.fi
Abstract—The successful practices of requirements engineer-
ing vary between application domains and are characterized
by the nature of the application domain. One relatively
peculiar application domain is the nuclear energy domain,
which is characterized by the long life cycle of power plant
operation and construction project, strict control of safety,
and collaboration between several stakeholder groups includ-
ing various branches of technology. We describe the state
of the practice of requirements engineering in the nuclear
energy domain in Finland on the basis of a descriptive case
study focusing on the safety-related automation systems of
the nuclear power plants. The results of the study indicate
that explicit requirements engineering practices are becoming
increasingly important due to the increasing complexity of the
technology used, retirement of the older generation of experts,
and construction of new power plants along with renewal of the
existing nuclear power plants. The challenges of requirements
engineering are especially within efficient communication and
management of requirements. We highlight challenges that are
emphasized by the characteristics of the nuclear energy domain
but also discuss the more generic nature of these challenges.
The identified challenges are in authority requirements, aging,
communication, knowledge transfer, representation of require-
ments, and tool support.
Keywords-nuclear energy; requirements engineering; safety
critical; case study
I. I NTRODUCTION
Requirements are fundamental to specifying what a sys-
tem should or should not do. The successful requirements
engineering practices vary depending on the characteristics
of the project in question [1], [2]. Although software engi-
neering has recently moved towards increased use of agile
methods, application domains and cases still exist where
more traditional methods are to be applied [3]. One such
domain is nuclear energy, for which specific classes of re-
quirements engineering techniques have been proposed [4].
The focus in the nuclear energy domain is on a nuclear
power plant (NPP) that produces electrical energy. An NPP
is a large safety-critical system consisting of several different
devices and therefore interests several stakeholders including
constructors and public authorities. In other systems for
which safety or dependability are critical, previous research
has identified that challenges in requirements engineering
978-1-4577-0924-1/11/$26.00 © 2011 IEEE
Industry Paper
Teemu Tommila and Janne Valkonen
VTT Technical Research Centre of Finland
P.O.Box 1000, 02044 VTT, Finland
teemu.tommila@vtt.fi, janne.valkonen@vtt.fi
are in elicitation [5], representation [6], and interpretation
of regulatory guidelines [7].
In this paper, we report the results of a case study of
requirements engineering practice in the nuclear energy
domain in Finland focusing on safety-related automation
systems. The objectives were to capture the state of the
practice of requirements engineering and to identify areas
with potential for improvement. We give an account of
the state of the practice and discuss challenges highlighted
by peculiar characteristics of the nuclear energy domain.
The scope of this study is limited to the construction,
operation, and maintenance of nuclear power plants. Design
and development of new kinds of nuclear power plants
or devices used in nuclear power plants are beyond the
scope of this study. The results indicate that the practices in
requirements engineering are relatively conventional and that
the challenges are mostly in representation and management
of the requirements.
The rest of the paper is organized as follows. Section 2
summarizes the research method. Section 3 gives the account
of the state of the practice. Section 4 discusses the high-
lighted challenges in requirements engineering. Section 5
draws conclusions.
II. R ESEARCH M ETHOD
The research was carried out as a case study, a method
of studying contemporary phenomenon in a real life con-
text [8]. The data was collected by interviewing two nuclear
energy domain experts representing public authority and five
experts working at the three existing power companies in
Finland. The interviews were semi-structured and each inter-
view took roughly two hours. The predefined themes, which
defined the questions asked during the interviews, were
requirements engineering concepts and terms; processes and
practices; documentation and representation; and challenges,
benefits, and areas for improvement. We focused mainly on
requirements for the NPPs rather than requirements for the
development processes. During the interviews, notes were
taken by the researchers that were summarized afterwards
and sent to the interviewee for review and correction. In ad-
dition, other available material was studied, such as laws and
253
regulatory guides on nuclear safety. The data from different
stakeholders were collated to form a synthesized summary
about the domain. The data analysis was carried out adhering
to open and axial coding and memoing of the Grounded
Theory approach [9] using the Atlas.TI qualitative analysis
software tool. A summary of the results was presented and
additional data were gathered in a workshop. A summary
report in Finnish was also composed that was reviewed by
one public authority representative and two persons from
different power companies.
III. R EQUIREMENTS E NGINEERING IN N UCLEAR
E NERGY D OMAIN
This section describes background and the state of the
practice of requirements engineering in the nuclear engineer-
ing domain in Finland focusing on safety-related automation
systems.
A. Background and Terminology
Currently in Finland, four NPPs are operational, one NPP
is under construction, and licenses have been granted for
construction of two new NPPs. The four operational NPPs
were constructed in the 1970s. Of the four operational NPPs,
the automation of two of them is being modernized, and the
other two are expected to start modernization projects within
a few years. Consequently, due to construction and renewals
the nuclear energy domain is becoming more active after a
few decades of a quieter phase. Nevertheless, maintenance
has been carried out constantly in these four operating NPPs.
The operation life cycles and construction projects are
long. For example in the case of Olkiluoto 3 NPP, the license
application was made in 2000, the license was granted in
2002, construction was started in 2005, and the NPP is
expected to be in operation in 2013. An NPP is expected
to be in operation for several decades.
The employees acquire deep domain knowledge and
knowledge about the NPP in question due to long life cycles
of operation and projects. However, much of the knowledge
also becomes tacit among employees.
Four main stakeholder groups exist in the nuclear energy
domain. First, the power companies are the owners of
NPPs and are responsible for constructing, operating, and
maintaining NPPs. Since the power companies have the final
responsibility for an NPP including safety of the NPP, they
also need to have detailed understanding about the entire
NPP in question. The second stakeholder group consists of
suppliers that typically are large international companies;
they carry out work in construction projects within NPPs and
supply technology to NPP, such as in the case of construction
of a new NPP or automation renewal. The third stakeholder
group, referred as subcontractors, does smaller work items
upon request for suppliers and also for other stakeholders,
but they are rarely responsible for a large project. Finally,
the fourth stakeholder group is public authority, which is
254
mainly represented by the Radiation and Nuclear Safety Au-
thority (STUK). STUK formulates the safety requirements
concerning the use of nuclear energy, provides instructions
about them, and grants operation permits for NPPs. There
exist other stakeholders such as Fingrid, as the owner of the
power-distribution network, and other stakeholders within
the above groups such as the environmental authorities.
Within the stakeholder groups, various branches of technolo-
gies, such as construction, automation, nuclear physics, and
electrical engineering, need to cooperate.
An NPP is divided structurally roughly into three levels
that constitute a plant hierarchy. The plant is the highest
level, referring to the entire NPP. The systems, at the second
level, are often further divided into sub-systems. A system
represents a meaningful whole. At the third level are devices
such as measurement and control instruments, and physical
structures of which systems consist. The devices can be
qualified off-the-shelf devices but a suitability analysis for
a specific purpose needs to be carried out. The three levels
thus represent a breakdown structure from the viewpoint of
a static structure.
Another viewpoint of the structure describes the functions
of an NPP. A function describes something that an NPP
should do, such as a safety shutdown. A function is, thus, a
dynamic or operation time viewpoint of an NPP. Each device
or system can participate in several functions.
The processes applied in construction and operation typ-
ically adhere to industrial standards including quality con-
trol and other life cycle processes. Design is iterative but
proceeds top-down. The supplier has a significant role and
responsibility for construction to the extent that even turn-
key projects have been used applied although the power
companies also carry out large parts of construction by
themselves.
B. Requirements Engineering
An existing or planned plant concept serves as the starting
point for a plant design provided by different suppliers, as
well as legislation, decrees, public authority regulations, and
international practices and standards. Therefore, from the
point of view of a power company, the result is that a general
reference architecture for the plant becomes predefined.
However, a plant is rarely copied without modifications
due to the power company requirements and changes in
technology and legislation in different countries and over
time. Therefore, construction always includes tailored design
solutions.
The plant concept is used as a basis for a set of require-
ments that include expected characteristics of the systems,
functions, and devices of the plant. These requirements in-
clude and are compromises between the various stakeholders
and branches of technologies of the plant. These require-
ments also include the requirements of the power company
or owner and standards applied in the plant. However, many
of the power company and supplier requirements can be
considered a part of and fulfilled by the plant concept. They
are thus not included in requirements definition, at least not
explicitly, but rather may be found in the contract with the
supplier.
Another major set of requirements arises from the leg-
islation, decrees, and regulatory guides on nuclear safety
(YVL) [10]. At the highest level is the law, which the
decrees specify. STUK maintains YVL on the basis of law
and decrees in order to give more detailed and practical
descriptions. YVL primarily specifies safety requirements
from the viewpoint of public authority. Examples of YVL
are a requirement for diversification and a requirement that
each system must be assigned to one of the five safety
classes. In addition to these general requirements applicable
to any plant, STUK makes also resolutions about a specific
NPP on the basis of plant design plans. The resolutions can
include additional requirements for the plant as a part of the
resolution.
The state of the practice of requirements engineering is
that most of the focus seems to be on analysis and ful-
fillment of requirements of public authorities and the basic
functionality. Other requirements such as maintainability or
ease of use are more implicit but followed during the project.
The supplier has a significant role and responsibility in
requirements definition, at least in the details of technical
requirements. For example, a power company can specify
requirements for a system, whereas a supplier is responsible
for specifying the requirements for the devices of which the
system consists. Besides this, the requirement to fulfill the
public authority requirements can be included as a clause
in the contract with the supplier. The reason for the role of
supplier is that the suppliers carry out much of the work
during construction and renewal of the plants and thus have
much control over the implementation of the project.
The requirements are mostly represented as natural lan-
guage sentences, usually at a relatively detailed level. In fact,
sometimes detailed specifications that are quite technical are
used as requirements. Some metadata such as identification
number and classifications are used in the requirements. An
issue is that requirements are often vague. For example, there
can be statements with no inherent measurability such as ”as
well as possible,” which often originate from YVL. In recent
years, additional means to visualize requirements such as
graphical representation of functions have also been piloted.
During construction of the existing plants, few requirements
were created so that the requirements would be usable and
available today.
Requirements today are written in documents that are
stored in a document management system. The documents
contain meta-information typical of technical documents,
such as a change log, authors, and a purpose. An exception
is that STUK resolutions are placed in different storage,
which, however, is a task management system rather than a
255
dedicated requirements management tool. A need for dedi-
cated tools for requirements management has been identified
and tools have been piloted, although tools alone do not
solve anything. Some suppliers have already started to use
dedicated requirements engineering tools.
Prioritization of requirements is relatively rudimentary
since requirements are only assigned into the five different
safety classes and in practice all requirements are important
and will be implemented before the nuclear power plant
can start to operate. Therefore, the implementation order of
requirements is not an issue but is influenced by the order
of construction in general.
Relationships such as hierarchies and dependencies be-
tween requirements are mainly captured in the requirements
documents in the form of references from one requirement to
another requirement. Some tables and matrixes are also used
to provide additional structure and organization to require-
ments. Nevertheless, few relationships are explicitly defined
and managed. In particular, hierarchical structures are not
necessarily explicit and requirements focus on the detailed
level; plant level requirements are scarcely specified. The
consequence is that traceability and dependency checking
become laborious and challenging.
To sum up, the requirements engineering practices are
quite conventional and basic in the nuclear energy domain in
Finland. This seems to be due to the tradition of the domain,
clarity of the current analog technology, and thorough expert
knowledge based on long experience. In particular, we did
not find that any special systematic or formal approaches
would have been applied in the form of structured reviews,
verification and validation processes, comprehensive check-
lists, formal methods, or model-based approaches. In fact,
we found no indications of a special need for formal or
systematic practices but rather a need for good practices
and practices suitable for NPPs in particular.
IV. C HALLENGES
The description in the previous section gave an account
of the state of the practice of requirements engineering in
the nuclear energy domain in Finland. In the following, we
elaborate challenges within requirements engineering high-
lighted by the characteristics peculiar to the nuclear energy
domain. These characteristics include the strict control of
safety, strict public authority control, the very long life cy-
cles of the projects and NPP operation, and the collaboration
and network of stakeholders including the several different
branches of technologies. The challenges are common issues
identified in general practice and emphasized by the current
situation: when the new modernized and digitalized technol-
ogy is applied, that introduces increasingly more complexity
in the form of added abstraction layers and relations between
the systems and devices compared with the old analog
technologies; new NPPs are being constructed and existing
NPPs are undergoing renewal; and the existing generation
 Table I
S UMMARY OF CHALLENGES
Topic Key challenge
Authority requirements How to deal with authority requirements
Aging How to synthesize and maintain old and new
requirements and realization over time
Communication How to communicate efficiently with stake-
holders of different background and over
organizational borders
Knowledge transfer How to explicate and ensure integrity of
knowledge over organizational borders
Representation of How to represent several crosscutting con-
requirements cerns in requirements
Tools How to incorporate tools into existing envi-
ronment
of engineers who built and have operated the first plants
in Finland are starting to retire and the new generation of
engineers is starting to take responsibility. The challenges
are described as follows and summarized in Table 1.
A. Authority Requirements
The authority requirements are in practice expressed in
YVL, a set of guidelines that roughly tries to help power
companies to fulfill the requirements of law and decree and
public authority in general. YVL adds details to law and
decree but cannot be in conflict with them and cannot require
more. In general YVL is applicable to any NPP, although in
practice YVL reflects to some extent the existing NPPs in
Finland. Thus, the statements in the YVL are in fact not even
meant to be requirements and are not written in the form of
requirements. Rather, requirements are to be derived from
YVL.
The power companies do not need to follow YVL as
long as their solution fulfills the requirements of law and
decree. In practice, the power companies try to follow YVL.
STUK seems to expect to see how YVL guidelines are
implemented in a plant. However, the requirements of a
plant typically refer to YVL in a general fashion rather
than to the specific sentence in YVL. For example, the
rationale of a requirement derived from YVL is typically
omitted or written in the form ”is based on YVL” rather
than as a more detailed reference to a specific section or
requirement in YVL. Traceability to YVL seems to be
an elusive target. Both the power companies and public
authorities seem to aim at fulfilling the requirements of YVL
and seeing traceability between YVL, the requirements, and
the plant design. Consequently, the practice is in conflict
with the intended role of YVL.
The challenge in general is how authority guidelines
should be managed within requirements engineering. On the
other hand, another issue is how the authority guidelines
should be written in order to make the guidelines usable
and understandable for the stakeholders who need to adhere
to the guidelines. Similar challenges seem to exist in the
256
cases of other authority requirements or similar external
generic requirements such as standards in other domains.
For example, many application domains extensively apply
industrial standards that specify requirements, such as in the
case of medical devices and telecommunications. The main
practical issue is therefore to what extent and how should
such statements be treated as requirements and whether
or not the statements, or an unambiguous reference to the
statement, should be incorporated into the requirements.
B. Aging
An NPP has a long operation life cycle during which
maintenance, including renewal, is carried out. However, a
specific system can remain relatively intact for quite a long
period of time until renewal or other major maintenance is
carried out. For instance, consider an existing plant where
a device is being replaced. A similar device cannot be used
since the same device using the same technology does not
necessarily exist anymore or is outdated. Requirements for
the device do not necessarily exist; this may be because the
requirements were not captured and documented properly
during initial construction, or requirements are not usable
since the integrity of requirements cannot be assured due to
earlier changes in a related system. Consequently, the need
emerges to replace the device with a new device.
However, placing a new device in the plant has conse-
quences. First, the new device must replace the purpose
of the original device, i.e., fulfill the requirements of the
old device–but as described earlier, the old requirements
are not necessarily available. Second, whenever changes are
made new needs for the new device may emerge, such as
for improved efficiency, safety, or usability, thus introducing
new requirements, typically from the power company point
of view. Third, the new device might need to fulfill the
existing regulations. It is not enough that the new device
fulfills the old regulations although the new device is re-
placing the old device; since renewal has taken place the
new public authority requirements apply. That is, whenever
regulations change, the existing NPPs do not necessarily
need to be changed to fulfill new regulations. However, if
the existing NPP is changed, the changed system or device
typically needs to fulfill the latest revision of the regulations.
Even if new authority requirements do not emerge, the new
device needs to be assessed for suitability for the specific
purpose even if the device is an externally qualified device.
Finally, the changes that these requirements imply might
affect the relationships the device has to other devices, hence
requiring a check of whether or not other requirements,
such as diversification or dissimilarity requirements, are still
fulfilled.
The challenge arises from capturing and synthesizing the
different requirements from different points of time and
adapting these synthesized requirements to current imple-
mentation. If something in an existing system is changed
the system needs to fulfill the old purpose, taking into
account the other interacting systems, but also adhere to
the current situation. There are two facets of the challenge.
On the one hand everything, including but not limited to
the requirements, has to be kept up to date as well as
possible. On the other hand, a synthesis needs to be formed
by combining all relevant information. Both of these need to
be carried out efficiently in terms of costs and effort spent.
The challenge seems not to be tied to the nuclear energy
domain but seems to be general to any system that is in
operation for a long time and that has multiple generations
and sources of requirements.
C. Communication
The nuclear energy domain includes three relatively sep-
arate stakeholder groups who have their own practices:
STUK, the power company, and the supplier including
subcontractors. All stakeholders need to have technical un-
derstanding about the whole in order to permit, license,
operate, and construct an NPP. Each stakeholder is relatively
separate so that they cannot affect each other’s processes and
systems. A uniform process cannot be achieved; processes
of suppliers cannot and should not be changed and disturbed
too much, for example.
Each of these stakeholders has different branches of
technology present and each is relatively specialized, even
having a specialized terminology. The different branches of
technologies are represented by different people who also
typically have different educational backgrounds, resulting
in differences in applied practices and even in terminology
used. For example, a characteristic of software in automation
is that the end product cannot be completely tested. Rather,
focus needs to be also in development processes in order
to ensure the quality of the end product. The situation is
different in some other branches of technology such as in
construction: despite general requirements specified for a
physical structure the details are described in a blueprint,
and the end product can be tested or measured with relative
certainty.
The challenge is therefore to establish practices in a
network of people who are in a relatively equal position and
have relatively different backgrounds but need to communi-
cate and collaborate. Even simple concepts and terminology
become an issue in such a truly multidisciplinary environ-
ment. The challenge can be considered a relatively generic
requirements engineering challenge that is emphasized in the
nuclear energy domain due to the network of stakeholders.
D. Knowledge Transfer
Currently, much of the construction is carried out by the
plant supplier. Therefore, it is meaningful that the supplier
also maintains and even partially creates documentation,
including at least the technical requirements in their sys-
tem during the construction project. In addition to that
257
knowledge created by the supplier, the knowledge also
becomes fragmented beyond the supplier to the network
of subcontractors that the supplier uses. The suppliers are
expected to ensure that the requirements are delivered when
the project is completed. The requirements alone are not
sufficient; at least equally valuable are the relationships
between requirements, such as dependencies, hierarchies,
and traceability links. However, it is not at all clear whether
or not all of the requirements and the relationships between
requirements can be explicated and transferred and how
much of the knowledge remains tacit and nontransferable.
Experience indicates that old requirements are challenging
to re-engineer or acquire. That is, an initial poor requirement
engineering practice might become laborious or costly in the
long term.
A challenge, nevertheless, is to transfer knowledge about
the requirements and especially the relationships between the
requirements after projects so that integrity is preserved and
maintained. It is a further challenge to maintain and under-
stand all knowledge about requirements. In fact, knowledge
transfer is not only a challenge over organizational borders.
Internally there are challenges between the multiple branches
of technologies but also challenges for knowledge transfer
from the old generation of engineers who are starting to
retire. This challenge seems not to be limited to the nuclear
energy domain; the trend exists in software engineering
include global software engineering, offshoring, and sub-
contracting. In all these situations, a similar challenge seems
relevant.
E. Representation of Requirements
There are few challenges in determining what an NPP
should or should not do, i.e., eliciting the requirements.
Rather, the challenges are in representing the requirements.
The requirements are currently written in natural language
combined with some metadata and stored in documents.
Although such a means to represent requirements provides
a good basis there is also a need for an advanced means.
That is, natural language sentences provide a relatively one-
dimensional and fragmented view of requirements.
However, several different concerns need to be taken into
account. Multiple levels of hierarchies in requirements and
relationships between the requirements exist as the result
of the plant hierarchy; the static and dynamic viewpoints of
the plant; the different branches of technologies; and several
crosscutting concerns that need to be taken into account such
as requirements for assignment of all systems to one of the
five safety classes, for several different defense lines, and
for replication, diversification, and dissimilarity. Defining
these concerns is not a challenge for the requirements but
managing, representing, and verifying the concern is more
challenging.
Therefore, the challenge is to have an efficient means to
represent and manage the requirements, taking into account
 the aforementioned crosscutting concerns. The challenge
is emphasized by the characteristics of the nuclear energy
domain but seems to be a relatively generic challenge given
the advanced means of representing requirements in other
domains that also include several crosscutting concerns.
F. Requirements Engineering Tools
Finally, all these challenges have an effect on applied
requirements engineering tools. Although currently require-
ments engineering in the nuclear power domain is mostly
carried out without dedicated tools, in the future there
might be more need for tools since systems are becoming
increasingly complex due to digital technology. In particular
the various relationships, hierarchies, and traceability are
hard to manage by hand. The tools need to adapt to the
existing environment since the tools alone do not solve
anything but can rather provide assistance. That is, several
different systems already exist so that putting a system into
use is not a challenge per se compared with integrating the
system into current work practices, life cycle processes, and
other systems.
Consequently, the challenge in general is for tools to
support solutions to the aforementioned challenges rather
than emphasize the challenges. For example in the case
of aging of the requirements even within one organization
the life cycles are so long that that ensuring access to and
integrity of data that was entered a couple of decades ago
using today’s tools becomes an issue. That is, in addition
to aging of the requirements, aging of the tools themselves
becomes an issue.
V. D ISCUSSION AND C ONCLUSIONS
We have given an account of the state of the practice of
requirements engineering in the nuclear energy domain in
Finland on the basis of a descriptive case study. The results
indicate that the requirements engineering practices are rela-
tively conventional and even basic, such as document-based
requirements definition in natural language. For example, we
did not find usage of or even specific indications of needs
for advanced tools, formal methods, or structured methods
such as checklists or formal reviews. Eliciting requirements
is considered trivial since it is relatively clear what a nuclear
power plant should or should not do.
The central challenges are in efficient representation and
management of requirements and relationships between the
requirements over the course of a nuclear power plant
life cycle and in the complex network of stakeholders,
taking into account all relevant crosscutting concerns such as
safety classes, defense lines, replication, diversification, and
dissimilarity. The challenges are highlighted by the current
situation in Finland, where the nuclear energy domain is
activating itself after a few decades of a more inactive phase.
Although the nuclear energy domain emphasizes the
challenges, the challenges do not seem to be inherently
258
View publication stats
application domain specific; similar challenges seem to be
discoverable in other application domains, and especially in
other large and complex projects. For example, the network
of stakeholders makes some challenges that are to some
extent similar to the challenges to global software develop-
ment [11]. In general, the challenges emphasize contextual
factors similarly to even small companies [12]. Nevertheless,
generalizability to other domains remains to be assessed.
ACKNOWLEDGMENT
The authors acknowledge financial support of SAFIR2010
and participants of the study.
R EFERENCES
[1] P. S. Ian Sommerville, Requirements Engineering: A Good
Practice Guide. Wiley, 1997.
[2] S. Lauesen, Software Requirements: Styles and Techniques,
1st ed. Pearson Education, 2001.
[3] J. Savolainen, J. Kuusela, and A. Vilavaara, “Transition to
agile development - rediscovery of important requirements
engineering practices,” in IEEE International Conference on
Requirements Engineering, 2010, pp. 289–294.
[4] T. Tsumaki and T. Tamai, “Framework for matching re-
quirements elicitation techniques to project characteristics,”
Software Process: Improvement and Practice, vol. 11, pp.
505–519, 2006.
[5] L. M. Cysneiros, “Requirements engineering in the health
care domain,” in IEEE International Conference on Require-
ments Engineering, 2002, pp. 350–356.
[6] A. Mavin, P. Wilkinson, A. Harwood, and M. Novak, “Easy
approach to requirements syntax (EARS),” in IEEE Interna-
tional Conference on Requirements Engineering, 2009.
[7] T. Breaux, M. Vail, and A. Anton, “Towards regulatory
compliance: Extracting rights and obligations to align require-
ments with regulations,” in IEEE International Conference on
Requirements Engineering, 2006, pp. 49 –58.
[8] R. K. Yin, Case Study Research, 3rd ed. Sage, 2003.
[9] A. Strauss and J. Corbin, Basics of Qualitative Research,
2nd ed. Sage, 1998.
[10] Radiation and Nuclear Safety Authority (STUK), “Regulatory
guides on nuclear safety (YVL),” http://www.edilex.fi/stuklex,
2011.
[11] D. E. Damian and D. Zowghi, “The impact of stakeholders?
geographical distribution on managing requirements in a
multi-site organization,” in IEEE International Requirements
Engineering Conference, 2002, pp. 319–330.
[12] J. Aranda, S. Easterbrook, and G. Wilson, “Requirements in
the wild: How small companies do it,” in IEEE International
Requirements Engineering Conference, 2007, pp. 39–48.