Conference PaperPDF Available

Model for Knowledge Capturing During System Requirements Elicitation in a High Reliability Organization: a case study


Abstract and Figures

High reliability organizations (HROs) are those organizations that focus on prevention, not reaction, and that require information systems to operate in nearly error-free conditions. As the consequences of system failure in an HRO are disastrous, system errors are not an option. Systems in an HRO should be examined continuously and pro-actively, and each employee must ensure that their particular operational aspects exclude the potential of disaster. As such, employees are stakeholders in system requirement elicitation which is one of the mechanisms through which operational aspects may be managed. However, traditional system requirements elicitation processes, do not include knowledge capturing as an outcome of the requirements elicitation process. In order to address knowledge capturing during system requirement elicitation, this paper proposes a model for knowledge capturing during system requirements elicitation in an HRO. The model was developed through a single case study conducted at an air navigation service provider organization in South Africa. By considering the ways in which system requirements are elicited and knowledge captured, benefit may be realized across maintaining a zero-failure environment in an HRO. KEYWORDS Knowledge management; system requirements elicitation; requirements elicitation model; high-reliability organizations; knowledge capturing; knowledge capturing model.
Content may be subject to copyright.
Model for Knowledge Capturing During System Requirements
Elicitation in a High Reliability Organization: a case study
T. Kotzé
University of Pretoria
Corner of Lynnwood Road and Roper
Street, Hatfield, Pretoria
H. Smuts
University of Pretoria
Corner of Lynnwood Road and Roper
Street, Hatfield, Pretoria
High reliability organizations (HROs) are those organizations that
focus on prevention, not reaction, and that require information
systems to operate in nearly error-free conditions. As the
consequences of system failure in an HRO are disastrous, system
errors are not an option. Systems in an HRO should be examined
continuously and pro-actively, and each employee must ensure that
their particular operational aspects exclude the potential of disaster.
As such, employees are stakeholders in system requirement
elicitation which is one of the mechanisms through which
operational aspects may be managed. However, traditional system
requirements elicitation processes, do not include knowledge
capturing as an outcome of the requirements elicitation process. In
order to address knowledge capturing during system requirement
elicitation, this paper proposes a model for knowledge capturing
during system requirements elicitation in an HRO. The model was
developed through a single case study conducted at an air
navigation service provider organization in South Africa. By
considering the ways in which system requirements are elicited and
knowledge captured, benefit may be realized across maintaining a
zero-failure environment in an HRO.
Information Systems Models and Principles; Systems and
Information Theory; Value of Information
Knowledge management; system requirements elicitation;
requirements elicitation model; high-reliability
organizations; knowledge capturing; knowledge capturing
High-reliability organizations (HROs), such as nuclear power
generation plants, air navigation service providers, hospital
emergency departments, and naval aircraft carriers, operate in
hazardous environments where the consequences of errors are
catastrophic, yet the occurrence of adverse events are extremely
low. The information systems (IS) in HROs must therefore sustain
delivery at maximum capacity and operate in nearly error-free
circumstances [1]. This dependence on almost flawless IS, in turn
places emphasis on the employees of the HROs as they play a
crucial role in aiding HROs achieve high-reliability performance,
whether it is operations or information systems development,
maintenance or support [2, 3].
The purpose of an information system is to meet the needs of
the organization and the requirements for the information system
are based on regulation, as well as the procedures and
characteristics of the operational requirements and systems of the
organization [4]. The elicitation of IS requirements is knowledge-
intensive and a critical progression in the development of an
information system. Poor execution of the system requirements
elicitation process, and in particular in an HRO, will result in
project failure [5].
In order to define IS requirements, an understanding of the
domain knowledge is required. Requirements are gathered
primarily from the users of the current system or those who are
expected to use the proposed system [6-8]. The process of
requirements elicitation during the development of an information
system relies heavily on knowledgeable individuals and should
they leave the organization, valuable knowledge may disappear [9].
However, since the required portions of knowledge may reside with
different stakeholders, knowledge sharing - the process through
which knowledge is exchanged among stakeholders - becomes a
prerequisite for IS development [10-12]. The adoption of
knowledge management practices in the development, operation,
and maintenance of software would improve both software
construction and more particularly software maintenance [13].
Therefore, the purpose of this study is to consider how knowledge
can be captured effectively during the elicitation of system
requirements in a high reliability organization.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
SAICSIT, September, 2018, Port Elizabeth, Eastern Cape, South Africa.
Copyright 2018 ACM 1-58113-000-0/00/0004…$15.00.
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
The next section presents the background to the study.
Thereafter, knowledge and the capturing of knowledge as part of
the system requirements elicitation process, are explored in section
3. Section 4 highlights the findings and discussion of the research
outcome and section 5 concludes the paper.
HROs operate in an environment that is rich with potential error
and the scale of consequences makes learning through
experimentation impossible [14]. Specific measures must therefore
be established in order to ensure that any critical element that is out
of place, is discovered prior to a possible event that might cause
harm. These procedures are put in place to ensure HROs operate
error-free, but should there be a deviation in the procedure, this is
managed through knowledge earned through experience [15].
When operations are carried out at a very fast pace, decision-
making transfers to the people with the greatest expertise and
knowledge about the events in question [16]. By drawing upon the
knowledge and experience of a group of subject matter specialists
and users, programs and operations are improved [17].
Given the need for expert involvement, it is typically the case
that a business analyst or knowledge engineer will be responsible
for eliciting the know-how from experts [18]. The main challenge
here is to, firstly, find a means by which the expert is enabled to
communicate their knowledge to the person responsible for
developing an information system or knowledge solution.
Secondly, the mechanism must facilitate the interaction among
experts, users and analysts to define requirements consists of
complex patterns [18]. Furthermore, information requirements are
complex, the variety is large and information requirements may be
constricted based on humans as information processors and
problem solvers. These factors make it difficult to form complete
and correct requirements for the information system. This suggests
that there should be different approaches in determining
requirements [19]. A knowledge-based approach in this context is
one that explicitly facilitates the development, evolution, and use
of knowledge that is critical to successful software development
and evolution [20].
In the next sections a brief overview of systems requirements
elicitation, knowledge and of knowledge capturing during system
requirements elicitation, are presented.
2.1 The Nature of Knowledge
The nature of knowledge has drawn a considerable amount of
conjecture in the literature [21]. In his seminal work, Tacit
Knowing: Its Bearing on Some Problems of Philosophy, Polanyi
[22] was the first to articulate the concept of explicit knowledge
and tacit knowledge [22: 601]. Explicit knowledge is knowledge
that has been articulated in the form of images, diagrams, text, or
user requirement specifications [23, 24]. Implicit knowledge is far
less concrete than explicit knowledge and denotes knowledge
entrenched into an organization’s operating practices [24, 25].
Tacit knowledge, as an aspect of implicit knowledge, is context-
specific and personal, and includes values and norms [23, 26].
Knowledge emanates from insight, framed experience, instinct and
judgement, and includes understanding scope and skills that are
intellectually created by people [23, 24]. Information becomes
individual knowledge when it is acknowledged and retained as
suitable exemplifications of the relevant knowledge [27, 28].
Individual knowledge becomes a knowledge asset and creates
economic value when it is converted into organisational knowledge
through knowledge management processes [23, 29, 30]. There are
different ways of presenting knowledge management processes
[31], varying from two generic processes, namely knowledge
production and knowledge integration [32], to a life cycle model of
three to eight steps including phases such as generation,
enrichment, storing, distribution and application of knowledge [23,
33-37]. Although several knowledge management process
definitions exist, a generic knowledge management process with
the purpose of knowledge creation requires that individual
knowledge is represented, transferred, made accessible and used
[37]. Tactical approaches to enabling such knowledge creation
includes an understanding of knowledge and where it resides in the
organization, by considering the modes and context of knowledge
conversion, as well as through the technologies used in this
conversion. A strategic knowledge creation solution encompasses
all of these steps in one seamless and complete procedure for
knowledge work [25, 38-40].
Knowledge work is defined as "the creation, distribution or
application of knowledge by highly skilled (and autonomous)
workers using tools and theoretical concepts to produce complex,
intangible and tangible results" [41 : 533]. Knowledge workers
must be able to interpret the stakeholder requirements and
transform these requirements into a succinct situation-specific
document outlining the software implementation or change
deliverable [42]. In this context, HROs emphasise a knowledge and
learning culture consisting of attentive inter-relating, collective
mindfulness and shared situation awareness based on significant
patterns of cooperative behaviour [43].
In the next section, we present an overview of system
requirements elicitation.
2.2 System Requirements Elicitation
Requirements elicitation refers to the process of discovering
requirements for a system by accessing available knowledge
sources and by communicating with the stakeholders who have a
direct or indirect influence on the requirements [44]. In the success
of software development processes, requirements analysis plays a
critical role as the outcome of this phase affects all other phases
[45]. There are various elicitation techniques such as
brainstorming, data mining, benchmarking and market analysis,
business rules analysis, collaborative games concept modelling,
data modelling, document analysis, focus groups, interface
analysis, interviews, mind mapping, observation, process analysis,
process modelling, prototyping, surveys or questionnaires, and
workshops to help the analysts extract requirements from the
different stakeholders [46]. These stakeholders have a good
understanding of domain knowledge, as well as of their own roles
and duties in the organization [47]. The requirements elicitation
phase is necessary for knowledge sharing and a key factor for
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
successful IS development [11]. Users share their explicit
knowledge, the knowledge of their procedures and processes that is
easy to articulate or already documented. However, the knowledge
that business users do not explain or are unable to articulate; tacit
knowledge, needs to be recognized and identified during the system
requirements elicitation process [48].
In the literature, different requirements elicitation processes are
depicted consisting of different activities. Zowghi & Coulin [49]
refer to five steps namely:
Understanding the application domain,
Identifying the sources of requirement;
Analysis of the stakeholders;
Selecting the techniques, approaches, and tools to use; and
Eliciting the requirements from stakeholders and other
The International Institute of Business Analysis [46] identifies
tasks such as the preparation for elicitation by outlining the desired
outcomes, extract and identification of any information that might
be relevant to the process, confirmation of elicitation,
communication of information to ensure the stakeholders
understand what was captured and the management of stakeholder
collaboration to ensure all stakeholders work towards a common
Hickey & Davis [50] define a general model of elicitation that
assists with the selection of a technique that should be used during
requirements elicitation. The model represents a generalization of
elicitation techniques and enables an analyst to understand the
requirements elicitation process better by identifying the factors
that should be considered when selecting techniques. The
elicitation technique selection is guided and driven by the problem,
a solution, the project domain characteristics, as well as the state of
requirements [50]. The model states that users, customers and other
stakeholders have unsolved problems, and these issues can be
addressed by elicitation, an activity that uncovers challenges that
need to be solved. The model identifies three categories that play
a role in elicitation:
The problem domain which indicates how well the problem is
understood, the type of application domain as well as the
complexity of the problem;
The solution domain pointing to the type of solution
anticipated or whether the solution will be bought or
developed; and
The project domain that includes the organization and the
individuals involved in the project [50].
As the focus of this paper is on knowledge capturing during the
IS requirements elicitation process, the next section reflects on
knowledge and knowledge capturing during requirements
2.3 Knowledge capturing during system
requirements elicitation
The development of software means working with knowledge via
a process that requires collaboration and communication. This
knowledge comes from different sources, i.e. business people’s
experiences, technology, and business rules [51]. There needs to be
a conscientious effort to discover knowledge and give it meaning
in a common language that can be understood by everyone involved
[51]. Furthermore, software requirements cannot be elicited
without taking a system perspective when requirements are elicited,
as software forms part of the larger system and the whole system
should be taken into consideration as the needs of stakeholders are
different [52].
Different techniques have been identified to conduct the system
requirements elicitation which requires interaction, collaboration
and discussions with different stakeholders [53]. Once the system
requirements elicitation process has been completed, the findings
need to be documented [51]. The software requirements document
is a product of requirements elicitation and this document describes
the proposed software system [54].
In order to ensure the consideration of knowledge during
requirements elicitation, Taheri et al. [55] proposed a knowledge
audit model with the focus on addressing knowledge
communication problems during the requirements elicitation
process. The model reflects a relationship between the knowledge
audit process and requirements elicitation process highlighting the
importance of the assessment of the knowledge (domain, technical
and individual) supporting the requirements in order to ensure the
quality of requirements [55].
Maalej & Thurimella [56] introduces five fundamentals of
managing requirements knowledge. The first fundamental points to
the identification of requirements knowledge with the aim to
externalise tacit knowledge such as reasoning or deductions.
Secondly, the representation of requirements knowledge involves
efficient information access and artefact reuse enablement within
and between projects. The third fundamental entails the
improvement of collaboration among stakeholders through the
sharing of requirements knowledge. This fundamental also ensures
that their experiences do not get lost. Fourthly, the purpose of
reasoning about requirements and their interdependencies is the
detection of inconsistencies and to derive new knowledge. Lastly,
the overhead to manage requirements knowledge is reduced
through intelligent tool support.
In the next section we present and discuss the case study that
was conducted in an HRO in South Africa.
The purpose of our research was to investigate how knowledge can
be captured effectively during the elicitation of system
requirements in an HRO. In order to do so, we collected feedback
via a questionnaire from a cross-functional sample population of
the case study organization. Yin [57] defines five components of
research design that are important for case studies namely the
questions, the propositions, the unit(s) of analysis, the logic linking
the data to the propositions and the criteria for interpreting the
findings. The unit of analysis in this single case study is the
organization, with the objective to extract knowledge capturing
guidelines in the context of system requirements elicitation.
The study was conducted in an HRO, namely an air navigation
service provider in South Africa, boasting highly specialized skills.
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
With the implementation of new information systems, the case
study organization relies on the input of individuals to ensure that
the procedures and characteristics of the operational systems of the
organization, are captured.
In order to identify, if and how, knowledge can be captured
effectively during the elicitation of system requirements in an
HRO, a questionnaire was designed, with the following 4 sections:
Biographical information: gather the biographical and
demographic information about each respondent, as well as
the profiles of the respondents.
Knowledge in the organization: determine the respondents’
perception of knowledge in the case study organization.
Information system requirements elicitation: examine the
system development and requirements elicitation process in
the case study organization.
Knowledge capturing: determine the respondents
understanding of knowledge capturing in the context of
system requirements elicitation.
The closed-ended questions in the questionnaire used a 5-point
rating scale, ranging from totally disagree to totally agree. The
responses of the multiple choice questions were tallied and
analysed. For qualitative feedback, relevant parts of the data were
identified and common themes were classified through a two-step
process: (1) use of descriptive codes to attribute a theme to a
segment of text [58], and (2) open coding in order to establish
themes from the questionnaire data [59, 60]. Each theme was then
evaluated for contribution according to knowledge capturing
during system requirements elicitation and will be discussed in
detail in section 4.
The questionnaire was distributed to 150 employees of the HRO
via an on-line survey tool. The questionnaire was completed by 64
respondents, yielding a 43% response rate. The profile of the
respondents is shown in Table 1.
Over 50% of the respondents were over the age of 40 years. This
could be attributed to the fact that the case study organization is the
only air navigation service provider in South Africa with 56% of
respondents showing tenure of more than 10 years.
Table 1: Respondent profile
Age in
Tenure in
# of IS
Air traffic control systems have a very long lifespan [61] and
have to satisfy international technical standards to ensure that the
interoperability of aircraft safety is maintained across all airports
[62]. Information systems must therefore be maintained and new
requirements updated. This is reflected in the number of IS projects
that employees were part of updating and improving the system, as
system overhauls are only implemented every 15 years in this
organization where the case study was conducted.
The elicitation of requirements is a process that involves different
stakeholders in the organization. Each stakeholder brings their own
experience and knowledge, and this process of requirements
gathering creates an opportunity for stakeholders to explain their
expertise and experience [47]. In an HRO there is no room for error
as lives are at stake and safety is the first concern. For this reason,
decisions that are made must consider different options. The
elicitation process provides an opportunity to discuss these
decisions that were made and even if the experience and knowledge
are not captured and acted upon in the information system, the
knowledge would be available for future reference [55].
In this section we analyse and discuss the data collected
regarding knowledge capturing during system requirements
elicitation in an air navigation service provider in South Africa. We
also propose a model for the capturing of knowledge during system
requirements elicitation in an HRO.
4.1 Knowledge in the organization
The purpose of this section in the questionnaire was to determine
the respondents perception of knowledge in the case study
organization. The importance of sharing knowledge was
highlighted by 64% of the respondents and these respondents
indicated they were willing to do so during system requirements
elicitation. Compared to the tenure and age (Table 1), it was shown
that the older and longer tenure employees were the group that
contributed to this finding. Respondents highlighted the importance
of knowledge in their departmental procedures, as well as in
international aviation guidelines, and confirmed that explicit
knowledge (94% of respondents) and tacit knowledge (86% of
respondents) should be captured. However, two themes
highlighting concerns emerged: (1) 50% of respondents indicated
that they perceive knowledge management in the organization not
to be mature and (2) 53% of respondents believed that knowledge
is lost when employees retire or leave the organization.
Respondents highlighted that different stakeholders were part of
the elicitation process and as such they shared a common
understanding of what the information system needed to achieve
informed by standards and regulations, as well as by specialists that
became experts in their fields. Knowledge held by these
stakeholders in the organization must be nurtured and further
enriched through the organization’s own aviation training academy,
providing skills and competency training. Employee training in the
case study HRO requires a constant update and this training must
keep abreast of changing technologies in the aviation industry.
Respondents indicated that knowledge capturing should be
actioned when people leave the organization or when employees
retire. This must be addressed pro-actively by using different
requirements elicitation techniques to extract knowledge. In
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
addition, long tenure employees in the organization hold a wealth
of knowledge that could be harvested. Respondents suggested that
the utilization of knowledge management techniques during system
requirements elicitation should capture the expertise of retired
employees, create an expert directory and utilize it for IS
4.2 Information system requirements elicitation
The objective of this section in the questionnaire was to examine
the system development and requirements elicitation process in the
case study organization. Respondents indicated significant
involvement in IS projects (Table 1), however, only 39% of
respondents believed that there was a standard process in place for
system requirements elicitation and only 38% of respondents
believed that end-users worked closely together when system
requirements were developed. Furthermore, 53% of respondents
agreed that the development of system requirements involved
relevant stakeholders and end-users. The issues pointed out were
further emphasized when only 28% of respondents agreed that the
outcomes (document) of system requirement elicitation were freely
The aviation industry as an HRO focuses on prevention, not
reaction. The requirements for an information system is therefore
based on preventative measures rather than on reactive measures.
In addition, respondents pointed out that requirement elicitation is
a cross-functional matter and the combination of different expertise
in different functional areas provides expert advice towards
ensuring the design of preventative measures. System
requirements elicitation therefore must consider different
requirements, both from a regulatory perspective as well as from a
cross functional stakeholder input perspective when deploying
systems. In this context, the system requirements elicitation process
provides an ideal platform where knowledge and experience that
directly relates to the operational environment can be shared,
disseminated and captured.
Respondents emphasized that knowledge is gained by working
with the information communication technology and different
scenarios are relevant in the process of gaining experience. The
development of information systems used in the case study HRO
required technical expertise from users who have dealt with or have
been in critical situations before. Other than traditional IS projects,
the case study HRO controlled systems that were continuously in
use and dealt with occurrences and events that seldom occurred.
Potential hazards trigger actions by pilots, air traffic controllers and
aviation personnel drawing from their knowledge and experience.
The preoccupation with failures in the case study HRO, ensured
that the developed requirements cater for the prevention of failures,
ensuring safety optimization in the process. The requirements were
known, but the frontline operations that ensure that safety events
are kept to zero, requires decisions based on experiences in
combination with standard operating procedures and practices.
When a new system is deployed in the case study HRO, the new
system runs concurrently with the old system where the new system
is a replica of the old enriched with enhanced functionalities to
ensure that performance is always optimized. Such a simulation
includes the functions of the control tower to ensure that real-life
scenarios are tested and that there is no room for error. Any policies
and procedures that deviate from guided policies and procedures,
are identified and captured. These deviations occur in the standard
operating procedures that require individuals to think on their feet
and to ensure that safety is the first point of call.
4.3 Knowledge capturing in the context of system
requirements elicitation
The aim of this section of the questionnaire was to determine the
respondentsunderstanding of knowledge capturing in the context
of system requirements elicitation. Respondents reflected on
whether knowledge captured during IS requirement elicitation
sessions should be made available to all employees and 86% of
respondents believed that it should be the case. This response was
further amplified by 84% of respondents that indicated that
decisions depended on their experience rather than a step by step
procedure. However, only 40% of respondents agreed that
knowledge was captured during the system requirements elicitation
During the elicitation process, experiences from operations
should be identified and elements previously experienced should
be captured and understood. Some of the occurrences might not be
captured in the requirements documentation, but the knowledge
shared during elicitation could be captured and shared in the
organization or to the greater aviation industry. Respondents
indicated that in order to ensure safety, decisions were sometimes
based on experience. The system requirements elicitation should
take into account how decisions were made, as well as the root
cause(s) of the situation. These requirements formed part of the
system requirements, or it could contribute to the organizational
knowledge or standard operating procedures.
One of the essential elements in the case study HRO is safety.
A safety culture drives the organization, and respondents pointed
out that this was the product of collective cooperation. In terms of
the project domain, critical safety elements must be elicited and
4.4 Implications for the model for knowledge
capture during system requirements elicitation
in an HRO
Based on the findings of the study reported on in the previous
sections, a model for knowledge capturing during system
requirements elicitation in an HRO is proposed in Figure 1. The
proposed model has been adapted from Hickey and Davis [50] and
Taheri et al. [55], and enriched with the findings from the study.
In order to better understand and reflect knowledge capturing
during the requirements elicitation process, the elicitation step in
the model [50] was expanded to include knowledge audit steps as
well as the knowledge audit relationship with the requirements
elicitation process [55]. Based on the findings of the case study, the
problem and solution domain, as well as the project and context
domain were expanded to support two technique choices,
elicitation technique selection and knowledge management
technique selection. Requirements elicitation input and output
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
considerations were updated as informed by the case study in order
to use the knowledge base as input, to include experts to provide
their input, and to consequently output candidate requirements as
well as updated knowledge. As regulation, policy and standards
play a significant role in an HRO, it was reflected explicitly in the
model as a reference point.
Before advancing into the system requirements elicitation
process, the facilitator (business analyst, systems engineer,
enterprise architect, etc.) must choose the most appropriate
requirement elicitation technique as well as the knowledge capture
technique. The elicitation and knowledge capture technique
selection process is determined by the problem and solution, and
by the project and context domain. In terms of the problem and
solution domain, the focus in an HRO is on prevention, not reaction
and the context therefore is pre-occupation with failures, identified
based on user experience. In this situation, prior documented or
known experiences from users, especially is hazardous situations,
must drive the elicitation and knowledge capture technique
consideration. From a project and context domain perspective,
existing domain knowledge in the HRO, whether reflected in a
knowledge base or embedded in the users, drives the elicitation
technique selection as there is no opportunity for trial and error
learning; performance should be optimized at all times.
Alignment to international regulations and the long lifespan of
systems must be considered as a given in an elicitation session
for an HRO. The characteristics of both these domains inform the
choice of best elicitation technique driven by the specific type of
requirements as elicitation techniques vary significantly in their
ability to elicit diverse inputs. From a knowledge perspective
these domains inform whether a standard knowledge exchange
process, a knowledge base extraction process or a knowledge
harvesting process should be followed.
In order to facilitate access to relevant information that will
allow a better understanding of the problem, users participating
in the elicitation session in the HRO must have relevant
knowledge and experience of the problem at hand. The relevant
knowledge and experience may be composed from operational
and long tenure experts in the HRO, current users and
stakeholders, regulation and policy standards pertaining to the
HRO or the base of previously documented requirements and
business rules. As decisions in an HRO are often dependent on
experience to ensure safety, IS requirements should strive for
zero harm and the role of knowledge in performing elicitation or
in selecting elicitation techniques are therefore key.
Considering the elicitation process itself with the aim to
identify candidate requirements, gathering, defining, prioritizing
and development of user interface dialogues are facilitated.
However, in an HRO, the evaluation of requirements within the
existing context, has a high priority and elicitation in this
instance should audit elicited requirements against already
existing knowledge e.g. system requirements must remain within
the legislative requirements of an air traffic management control
policy and regulation. Therefore, requirement discovery is the
first activity of the elicitation process and this is a knowledge
intensive step as operational-, technical-, user-, domain- and
infrastructure knowledge are required to assist stakeholders in
discovering the requirements. During the classification and
prioritization of requirements, the unstructured requirements are
structured into coherent clusters and then prioritized based on
stakeholder knowledge. Domain and technical knowledge are key
enablers during this requirements classification as this knowledge
also guides and informs consensus among all stakeholders. The
knowledge flow analysis process defines the relationship among
knowledge and knowledge sources. The last requirement elicitation
step is the requirement specification document and it should
contain a complete, correct and unambiguous record of the elicited
requirements. Therefore, it is important to evaluate the documented
requirements knowledge in order to ensure the quality of
Once the final candidate requirements document is defined, the
requirement set must be made available as reference to the HRO.
The requirements document as explicit knowledge source supports
the fostering of a safety culture in the HRO and in turn, collective
cooperation. Transparency and availability of such explicit sources
Fig. 1. Proposed model for knowledge capture during
system requirements elicitation in an HRO
(adapted from [50] and [55]).
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
collated through the system requirements elicitation process
nurtures focus on prevention of hazard in an HRO.
Due to the unique nature of HROs and the requirement for an
HRO to function with nearly flawless operations and information
systems, mistakes and errors must be avoided at all cost. In this
context, any failure or deviation from the expected result, should
not be tolerated as it may result in tragedy. Therefore, it is necessary
for HROs to address any level of technical, human or process
failure instantaneously and in totality. In order to avoid mistakes
during system requirements elicitation as the initial step towards
software development, errors must be mitigated by ensuring that
there is no knowledge conflict as a result of miscommunication
among stakeholders. By ensuring that requirements are complete,
well understood and correct within the context of the HRO
environment and regulation, knowledge capture during system
requirements elicitation is a key enabler.
High-reliability organizations (HROs) operate in environments
where the consequences of errors are catastrophic. Information
systems in HROs must therefore sustain delivery at maximum
capacity and operate in nearly error-free circumstances. The
requirement for such optimal performance, places a strong
emphasis on system requirements elicitation for the design,
development and implementation of information systems. The
adoption of knowledge management practices in the requirement
elicitation process would improve the elicitation of candidate
requirements in an HRO and therefore, the purpose of this study
was to consider how knowledge can be captured effectively during
the elicitation of system requirements in a high reliability
organization. This paper reported on a case study in an air
navigations service provider based in South Africa.
A requirements elicitation model was adapted for the capturing
of knowledge during system requirements elicitation in an HRO.
The elicitation process was expanded to include knowledge
considerations and inputs such as regulation, standards and
knowledge management techniques, as well as outputs such as
knowledge capture together with candidate requirements, were
highlighted. The adapted system requirements elicitation model
will assist HROs with key pointers when capturing knowledge
during information system requirements elicitation towards zero
mistake outcomes. In addition, the proposed elicitation model will
assist facilitators of requirement elicitation to take better decisions
with regards to the choice of elicitation techniques.
Since the case study was limited to a single HRO in South
Africa, further research is required in order to generalize the
findings across the entire sector.
1. Casler, J., Revisiting NASA as a High Reliability Organization. Public
Organization Review, 2014. 14(2): p. 229-244.
2. Ericksen, J. and L. Dyer, Toward a strategic human resource
management model of high reliability organization performance. The
international journal of Human Resource Management, 2005. 16(6): p.
3. Yip, L. and B. Farmer, High reliability organizationsMedication
safety. Journal of Medical Toxicology, 2015. 11(2): p. 257-261.
4. Stair, R. and G. Reynolds, Fundamentals of Information Systems. 9th
ed. 2018: Cengage Learning.
5. Hickey, A.M. and A.M. Davis, Requirements elicitation and elicitation
technique selection: model for two knowledge-intensive software
development processes, in Proceedings of the 36th Annual Hawaii
International Conference. 2003: Hawaii.
6. squez-Bravo, D., et al., Knowledge management acquisition
improvement by using software engineering elicitation techniques.
Computers in Human Behavior, 2014. 30: p. 721-730.
7. Appan, R. and G.J. Browne, The Impact of Analyst-Induced
Misinformation on the Requirements Elicitation Process. MIS
Quarterly, 2012. 36(1): p. 85106.
8. Ding, W., Liang, P., Tang, A. & van Vliet, H., Knowledge-based
approaches in software documentation: A systematic literature review.
Information and Software Technology, 2014. 56(6): p. 545-567.
9. Rus, I. and M. Lindvall, Knowledge management in software
engineering. IEEE Software, 2002. 19(3): p. 26-38.
10. Cabrera, A. and E.F. Cabrera, Knowledge-sharing dilemmas.
Organization Studies, 2002. 23(5): p. 687-710.
11. Rosenkranz, C., H. Vranešić, and R. Holten, Boundary Interactions and
Motors of Change in Requirements Elicitation: A Dynamic Perspective
on Knowledge Sharing. Journal of the Association for Information
Systems, 2014. 15(6): p. 306-345.
12. Argote, L. and E. Miron-Spektor, Organizational learning: From
experience to knowledge. Organization Science, 2011. 22(5): p. 1123-
13. de Vasconcelosa, J.B., et al., The application of knowledge
management to software evolution. International Journal of
Information Management, 2017. 37(1): p. 1499-1506.
14. Weick, K.E., K.M. Sutcliffe, and D. Obstfeld, Organizing for high
reliability: Processes of collective mindfulness. Crisis management,
2008. 3(1): p. 81-123.
15. Rochlin, G.I., T.R. La Porte, and K.H. Roberts, The self-designing
high-reliability organization: Aircraft carrier flight operations at sea.
Naval War College Review, 1998. 51(3): p. 97-113.
16. Hopkins, A., The problem of defining high reliability organisations.
2007, National Research Center for Occupational Safety and Health
Regulation: Canberra. p. 15.
17. Downes, C.G., An investigation into hazard-centric analysis of
complex autonomous systems, in Engineering. 2013, Loughborough
University: Loughborough. p. 257.
18. Shadbolt, N.R. and P.R. Smart, Knowledge Elicitation. 4th ed.
Evaluation of Human Work, ed. J.R. Wilson and S. Sharples 2015,
Florida, USA: CRC Press.
19. Ghanbari, H., J. Similä, and J. Markkula, Utilizing online serious games
to facilitate distributed requirements elicitation. Journal of Systems
and Software, 2015. 109: p. 32-49.
20. Ding, W., et al., Knowledge-based approaches in software
documentation: A systematic literature review. Information and
Software Technology, 2014. 56(6): p. 545-567.
21. Davenport, T.H. and L. Prusak, Working Knowledge: how
organisations manage what they know. Paperback 2000 ed. 1998,
Boston: Harvard Business School Press. 198.
22. Polanyi, M., Tacit Knowing: Its Bearing on Some Problems of
Philosophy. Reviews of Modern Physics, 1962. 34(4): p. 601-606.
23. Clarke, T. and C. Rollo, Corporate initiatives in knowledge
management. Education + Training, 2001. 43(4/5): p. 206-214.
24. Meihami, B. and H. Meihami, Knowledge Management a way to gain
a competitive advantage in firms (evidence of manufacturing
companies). International Letters of Social and Humanistic Sciences,
2014. 14: p. 80-91.
25. Kothuri, S. Knowledge in Organisations. 2002; Available from:
26. Nonaka, I. and H. Takeuchi, The Knowledge Creating Company. 1995:
Oxford University Press.
SAICSIT ‘18, September 2018, Port Elizabeth, SA
T. Kotzé & H. Smuts
27. Liu, J., Culture and Knowledge Transfer: Theoretical Considerations
Journal of Service Science & Management 2010. 3: p. 159-164.
28. Lindvall, M., I. Rus, and S.S. Sinha, Software systems support for
knowledge management. Journal of Knowledge Management, 2003.
7(5): p. 137 - 150.
29. Godbout, A.J., Filtering Knowledge: Changing Information into
Knowledge Assets. Journal of Systemic Knowledge Management
(Journal of Knowledge Management Practice), 1999. January 1999.
30. Xie, X., W. Zhang, and L. Xu. A description model to support
knowledge management. in First International Multi-Symposiums on
Computer and Computational Sciences. 2006: IEEE Computer Society.
31. Antonova, A. and E. Gourova, Insight into Practical Utilisation of
Knowledge Management Technologies, in IEEE International
Symposium on Modern Computing. 2006.
32. Firestone, J.M. and M.W. McElroy, Key issues in the new knowledge
management. 2003: Butterworth-Heinemann.
33. Alavy, M., Gotcha Projects (SIMS). 2004, University of Maryland.
34. Katz, M., Knowledge Management. People Dynamics, 1998. 17(6): p.
35. Lindvall, M., et al., Software Tools for Knowledge Management: A
DACS State-of-the-art report. 2001, Fraunhofer Center for
Experimental Software Engineering Maryland and The University of
Maryland: Maryland.
36. Folkens, F. and M. Spiliopoulou, Towards an Evaluation Framework
for Knowledge Management Systems. PAKM 2004, 2004. LNAI 3336:
p. 23-34.
37. Alavi, M. and D.E. Leidner, Review: Knowledge Management and
Knowledge Management Systems: Conceptual Foundations and
Research Issues. MIS Quarterly, 2001. 25(1): p. 107 - 136.
38. Marwick, A.D., Knowledge Management Technology. IBM Systems
Journal, 2001. 40(4): p. 814-830.
39. Vequist, D.G. and M.S. Teachout, A Conceptual System Approach for
the Relationship between Collaborative Knowledge Management and
Human Capital Management. IEEE, 2006. 0-9785699-0-3(06): p. 150-
40. Hoffmann, M., et al., A design process for embedding knowledge
management in everyday work. ACM, 1999. 99(11): p. 296-305.
41. Bosch-Sijtsema, P.M., V. Ruohomaki, and M. Vartiainen, Knowledge
work productivity in distributed teams. Journal of Knowledge
Management, 2009. 13(6): p. 533-546.
42. Carreteiro, P., et al., Knowledge Management Approach for Software
Engineering Projects Development, in New Advances in Information
Systems and Technologies, Á. Rocha, Editor. 2016. p. 444.
43. French, S., et al., Human Reliability Analysis: a critique and review for
managers. Safety Science, 2011. 49(6): p. 753-763.
44. Hadar, I., P. Soffer, and K. Kenzi, The role of domain knowledge in
requirements elicitation via interviews: an exploratory study.
Requirements Engineering, 2014. 19: p. 143159.
45. Sabahat, N., et al., An Iterative Approach for Global Requirements
Elicitation: A Case Study Analysis, in Electronics and Information
Engineering (ICEIE). 2010, IEEE Kyoto, Japan.
46. IIBA, A Guide to the Business Analysis Body of Knowledge in BABOK
Guide. 2009, International Institute of Business Analysis.
47. Ferrari, A., P. Spoletini, and S. Gnesi, Ambiguity and tacit knowledge
in requirements elicitation interviews. Requirements Engineering,
2016. 21: p. 333355.
48. Amit, J., Business analysis. 1st ed. 2010, Mumbai, India: Himalaya
Publishing House.
49. Zowghi, D. and C. Coulin, Requirements elicitation: A survey of
techniques, approaches, and tools, in Engineering and managing
software requirements, A. Aurum and C. Wohlin, Editors. 2005,
Springer. p. 478.
50. Hickey, A.M. and A.M. Davis, A unified model of requirements
elicitation. Journal of Management Information Systems, 2004. 20(4):
p. 65-84.
51. Serna, E., O. Bachiller, and A. Serna, Knowledge meaning and
management in requirements engineering. International Journal of
Information Management, 2017. 37(3): p.:155-161.
52. Boegh, J., A new standard for quality requirements. IEEE Software,
2008. 25(2): p. 57-63.
53. Argote, L., B. McEvily, and R. Reagans, Managing knowledge in
organizations: An integrative framework and review of emerging
themes. Management science, 2003. 49(4): p. 571-582.
54. Aggestam, L., S. Durst, and A. Persson, Critical Success Factors in
Capturing Knowledge for Retention in IT-Supported Repositories.
Information 2014. 5(4): p. 558-569.
55. Taheri, L., et al., A Knowledge Audit Model for Requirement
Elicitation: A Case Study to Assess Knowledge in Requirement
Elicitation. Knowledge and Process Management, 2017. 24(4): p. 257
56. Maalej, W. and A.K. Thurimella, Managing Requirements Knowledge,
ed. W. Maalej and A.K. Thurimella. 2013, Berlin Heidelberg: Springer-
57. Yin, R.K., Case Study Research: Design and Methods. 6th ed. 2017:
Sage Publications Inc.
58. Welman, C., F. Kruger, and B. Mitchell, Research Methodology. Third
ed. 1994, Cape Town: Oxford University Press Southern Africa.
59. Flick, U., Designing qualitative research. The SAGE Qualitative
Research Kit. 2007: Sage Publications Ltd.
60. Leedy, P.D. and J.E. Ormrod, Practical Research: Planning and
Design. 10th ed. 2014, New Jersey: Pearson Education Limited.
61. Ahmad, S. and V. Saxena, Design of formal air traffic control system
through UML. Ubiquitous computing and communication journal,
2008. 3(6): p. 11-20.
62. Hansman, R.J. and A. Odoni, Air traffic control, in The Global Airline
Industry, R.J. Hansman and A. Odoni, Editors. 2009, John Wiley &
Sons, Ltd.
Full-text available
This paper aims to develop a knowledge audit (KA) model with the focus on knowledge assessment in the requirements elicitation process (REP) to allay the problems of REP regarding knowledge communication. The principal problems with REP are knowledge conflict and the failure to mention a variety of knowledge and requirements changes. Despite of many existing studies relating to KA, inadequate effort has been directed towards investigating the full part played by the KA process in REP. The purpose of this paper is to bridge this gap using a software prototype that uses the KA model in the REP. This study proposes a KA model using an iterative triangulation method. The proposed model is validated through a case study by using a software prototype developed based on the proposed KA model to see if this KA model is effective for software developers in REP by improving the completeness, correctness, and understandability of the elicited requirements knowledge. Research findings are based on responses of 40 respondents from software development organizations. The results of case study confirmed the effectiveness of KA model for REP with respect to completeness, correctness, and understandability. This research answers the call to assess knowledge in REP by developing a KA model and prototype to fill the existing gap in this area. Overall, a KA model for REP is introduced and validated to identify and assess knowledge that supports knowledge communication in REP.
Full-text available
Interviews are the most common and effective means to perform requirements elicitation and support knowledge transfer between a customer and a requirements analyst. Ambiguity in communication is often perceived as a major obstacle for knowledge transfer, which could lead to unclear and incomplete requirements documents. In this paper, we analyze the role of ambiguity in requirements elicitation interviews, when requirements are still tacit ideas to be surfaced. To study the phenomenon, we performed a set of 34 customer–analyst interviews. This experience was used as a baseline to define a framework to categorize ambiguity. The framework presents the notion of ambiguity as a class of four main sub-phenomena, namely unclarity, multiple understanding, incorrect disambiguation and correct disambiguation. We present examples of ambiguities from our interviews to illustrate the different categories, and we highlight the pragmatic components that determine the occurrence of ambiguity. Along the study, we discovered a peculiar relation between ambiguity and tacit knowledge in interviews. Tacit knowledge is the knowledge that a customer has but does not pass to the analyst for any reason. From our experience, we have discovered that, rather than an obstacle, the occurrence of an ambiguity is often a resource for discovering tacit knowledge. Again, examples are presented from our interviews to support this vision.
Full-text available
Aiming to emphasize the effect of knowledge management practices during software development projects, this research paper presents a first approach to cope with knowledge management and engineering practices across software development projects. The main goal is to define a roadmap for representative software development life cycle tasks during a typical software project development. The research introduces an ongoing architectural case study using software maintenance tasks as a means to enhance the knowledge flows within the organization. Software maintainers validate, correct and update knowledge from previous phases of software development life cycle through the application of back flushing technique at the software data warehouse. Further research developments will present a detailed guidance model for both research areas: knowledge management for software engineering combining insights across corporate software projects as a means of evaluating the effects on people and organization, technology, workflows and processes.
Requirements engineering is one of the most complex and at the same time most crucial aspects of software engineering. It typically involves different stakeholders with different backgrounds. Constant changes in both the problem and the solution domain make the work of the stakeholders extremely dynamic. New problems are discovered, additional information is needed, alternative solutions are proposed, several options are evaluated, and new hands-on experience is gained on a daily basis. The knowledge needed to define and implement requirements is immense, often interdisciplinary and constantly expanding. It typically includes engineering, management and collaboration information, as well as psychological aspects and best practices. This book discusses systematic means for managing requirements knowledge and its owners as valuable assets. It focuses on potentials and benefits of “lightweight,” modern knowledge technologies such as semantic Wikis, machine learning, and recommender systems applied to requirements engineering. The 17 chapters are authored by some of the most renowned researchers in the field, distilling the discussions held over the last five years at the MARK workshop series. They present novel ideas, emerging methodologies, frameworks, tools and key industrial experience in capturing, representing, sharing, and reusing knowledge in requirements engineering. While the book primarily addresses researchers and graduate students, practitioners will also benefit from the reports and approaches presented in this comprehensive work.
It is traditionally assumed that requirements specification, as a product of requirements engineering, has a high impact on the ensuing software development stages. Therefore, the knowledge management used to construct the requirements specification should be performed in a structured manner to discover, analyze and understand the data–information–knowledge chain, both tacit and explicit, that the interested parties possess. In this article, the results of a literature review are presented, seeking to answer the following questions: (1) What is the meaning of knowledge in requirements engineering? (2) What approaches are proposed to manage knowledge in requirements engineering? (3) Can the efficiency and the efficacy of knowledge management models be evidenced in requirements engineering? Thirty-six works were chosen for analysis out of a total 83 found in our search. The analysis showed that (1) knowledge has a central significance at this stage, but the authors have yet to agree on the best methods to impart and apply that knowledge; (2) no general framework has emerged as a validated approach to manage knowledge for requirements engineering; and (3) the evaluation marks for model efficiency and efficacy are low, consisting mostly of personal interpretations.
In complex software development projects, consistent planning and communication between the stakeholders is crucial for effective collaboration across the different stages in software construction. Taking the view of software development and maintenance as being part of the broader phenomenon of software evolution, this paper argues that the adoption of knowledge management practices in software engineering would improve both software construction and more particularly software maintenance. The research work presents a guidance model for both areas: knowledge management and software engineering, combining insights across corporate software projects as a means of evaluating the effects on people and organization, technology, workflows and processes.
High Reliability Organizations (HROs) have been treated as exotic outliers in mainstream organizational theory because of their unique potentials for catastrophic consequences and interactively complex technology. We argue that HROs are more central to the mainstream because they provide a unique window into organizational effectiveness under trying conditions. HROs enact a distinctive though not unique set of cognitive processes directed at proxies for failure, tendencies to simplify, sensitivity to operations, capabilities for resilience, and temptations to overstructure the system. Taken together these processes induce a state of collective mindfulness that creates a rich awareness of discriminatory detail and facilitates the discovery and correction of errors capable of escalation into catastrophe. Though distinctive, these processes are not unique since they are a dormant infrastructure for process improvement in all organizations. Analysis of HROs suggests that inertia is not indigenous to organizing, that routines are effective because of their variation, that learning may be a byproduct of mindfulness, and that garbage cans may be safer than hierarchies.
From the Publisher: The definitive primer on knowledge management, this book will establish the enduring vocabulary and concepts and serve as the hands-on resource of choice for fast companies that recognize knowledge as the only sustainable source of competitive advantage. Drawing on their work with more than 30 knowledge-rich firms, the authors-experienced consultants with a track record of success-examine how all types of companies can effectively understand, analyze, measure, and manage their intellectual assets, turning corporate knowledge into market value. They consider such questions as: What key cultural and behavioral issues must managers address to use knowledge effectively?; What are the best ways to incorporate technology into knowledge work?; What does a successful knowledge project look like-and how do you know when it has succeeded? In the end, say the authors, the human qualities of knowledge-experience, intuition, and beliefs-are the most valuable and the most difficult to manage. Applying the insights of Working Knowledge is every manager's first step on that rewarding road to long-term success. A Library Journal Best Business Book of the Year. "For an entire have knowledge, that information must be coordinated and made accessible. Thomas H. Davenport...and Laurence Prusak... offer an elegantly simple overview of the 'knowledge market' aimed at fulfilling that goal.... Working Knowledge provides practical advice about implementing a knowledge-management system....A solid dose of common sense for any company looking to acquire -- or maintain -- a competitive edge."--Upside, June 1998