Managing Requirements Knowledge

The use of tacit knowledge is a common feature in everyday communication. It allows people to communicate effectively without forcing them to make everything tediously and painstakingly explicit, provided they all share a common understanding of whatever is not made explicit. If this latter criterion does not hold, confusion and misunderstanding will ensue. Tacit knowledge is also commonplace in requirements where it also affords economy of expression. However, the use of tacit knowledge also suffers from the same risk of misunderstanding, with the associated problems of anticipating where it has the potential for confusion and of unravelling where it has played an actual role in misunderstanding. Thus, the effective communication of requirements knowledge (whether verbally, through a document or some other medium) requires an understanding of what knowledge is and isn’t (necessarily) held in common. This is very hard to get right as people from different professional and cultural backgrounds are typically involved. At its worst, tacit requirements knowledge may lead to software that fails to satisfy the customer’s requirements. In this chapter, we review the diverse views of tacit knowledge discussed in the literature from a wide range of disciplines, reflect on their commonalities and differences and propose a conceptual framework for requirements engineering that characterises the different facets of tacit knowledge that distinguish the different views. We then identify methodological and technical challenges for future research on the role of tacit knowledge in requirements engineering.

This chapter reports results from two recent studies of how operational experience with mission-critical product lines can enhance knowledge management for use with their future products. The challenge was how to propagate new requirements knowledge forward in a product line in ways that projects will use. In the first product line, the concern was capture and retention of requirements knowledge exposed by defects that occurred during operations. This led to two mechanisms not traditionally associated with requirements management – feature models extended with assumption specifications (formal) and structured anecdotes of paradigmatic product-line defects (informal). In the second product line, the traditional notion of binding time in a product line did not accurately reflect the timing of project decisions. This led to a definition of product-line binding times that better accommodates the varying requirements of the different missions using the product line. It appears that the practical techniques reported here to build requirements knowledge into software product lines in the spacecraft domain also are useful in other product-line developments.

Working with requirements is a knowledge-intensive task. During the elicitation, comprehension, or management of requirements, practitioners often consume and produce additional information such as domain knowledge, rationale, requirements dependencies, “who knows what”, or how-to’s. However, current requirements engineering processes and tools lack a systematic support for the management of knowledge about requirements. This makes it difficult for practitioners to capture and share such knowledge.

This chapter summarises our experience on implementing a lightweight, pragmatic approach to capture and share requirements knowledge. We recommend practitioners to Draw a knowledge landscape, Use lightweight tools, Follow a simple iterative process, Interact with external communities, Capture tacit knowledge, and Establish a knowledge culture. We introduce these guidelines, report on motivating examples, and discuss how they can be applied successfully in practice.

Software requirement reuse strategies are necessary to capitalize and reuse knowledge in the requirement engineering phase. The PABRE framework is designed to support requirement reuse through the use of software requirement patterns. It consists of a meta-model that describes the main concepts around the notion of pattern, a method to conduct the elicitation and documentation processes, a catalogue of patterns, and a tool that supports the catalogue’s management and use. In this chapter all these elements are presented in detail making emphasis on the construction, use and evolution of software requirement patterns. Furthermore, the chapter includes the construction of a catalogue of nontechnical software requirement patterns for illustration purposes.

Safety analysis (SA) procedures, such as hazard and operability analysis (HazOp) and failure mode and effect analysis (FMEA), are generally regarded as repetitious, time consuming, costly and require a lot of human involvement. Previous efforts have targeted automated support for SA at the design stage of system development. However, studies have shown that the cost of correcting a safety error is much higher when done at the later stages than the early stages of system development. Hence, relative to previous approaches, this chapter presents an approach for hazard identification (HazId) based on requirements and reuse-oriented safety analysis. The approach offers a convenient starting point for the identification of potential system safety concerns from the RE phase of development. It ensures that knowledge contained in both the requirements document and previously documented HazOp projects can be leveraged in order to attain a reduction in the cost of SA by using established technologies such as ontology, case-based reasoning (CBR), and natural language processing (NLP). The approach is supported by a prototype tool, which was assessed by conducting a preliminary evaluation. The results indicate that the approach enables reuse of experience in conducting safety analysis, provides a sound basis for early identification of system hazards when used with a good domain ontology and is potentially suitable for application in practice by experts.

Reaching common level of understanding of a problem domain is one of the key challenges that stakeholders face during the requirements phase of a project. The stakeholders involved in requirements engineering (RE) attempt to achieve this goal through communication and knowledge sharing. The process of clarifying business problems and arriving at a specification necessitates developing a common vocabulary, assigning meanings to various business concepts, determining their interrelations, and reconciling stakeholders’ viewpoints. Oftentimes, knowledge exists in organizations, but is not maintained in a reusable form. To address the knowledge and collaboration needs of RE stakeholders, we have developed a Knowledge-Assisted Ontology-Based Requirements Evolution (K-RE) method and toolset. We demonstrate creation of a knowledge repository and its reuse in two contexts: (1) to resolve change requests (CR) with better speed and accuracy and (2) to jump-start a new project. We combine the social software principles and semantic Web concepts to achieve this.

Knowledge sharing and reuse in global software engineering (GSE) are challenging issues. Knowledge management (KM) is specifically impacted because on top of distance, culture and language mismatches, there is also the perceived risk of sharing something which could mean that others could take over some work. Mistrust and protectionism are often the consequence, leading to insufficient reuse. This is visible specifically in requirements engineering (RE), where all reuse should start. In this chapter, we will look to reuse in RE with a detailed look on how to improve knowledge sharing and collaboration in distributed environments. We first look into the state of the practice. Then we present a lightweight, reuse-based, global RE method called PANGEA (Process for globAl requiremeNts enGinEering and quAlity), based on natural language requirements and software engineering standards. Based on this method, we also build a prototypical tool, called PANTALASA (PANgea Tool And Lightweight Automated Support Architecture) which provides automated support for PANGEA. Its features are drawn from PANGEA and the state of the practice commercially available RE tools. A prototype of PANTALASA was developed by using Semantic MediaWiki and Facebook and applied to a case study in the domain of hotel management. We could show with this method and prototype that collaboration and thus KM and reuse in RE are improved.

We present the results of our field study that describe how requirements knowledge was shared at an industrial software company using agile software practices. As is common in agile processes, the team did not capture requirements knowledge in a comprehensive specification document. Instead, requirements knowledge was captured in user stories, automated acceptance tests, personal notes, and conversations. We identified two modes of knowledge sharing: performative and lexical. Performative knowledge, which occurs through actions such as question-asking, gestures, and informal speeches, was observed in conversations and at the Scrum board. Lexical knowledge sharing, which occurs through inscribed texts, was observed in testing wiki and the software release documents. We found that the software team relied mainly on performative knowledge sharing. Although team members shared few written documents, they were able to effectively develop software that satisfied customer requirements. Results from our field study have implications for both agile practitioners and knowledge management. The former could encourage question-asking to provide opportunities for performative knowledge sharing. The latter could pay attention to personal management so that users can more effectively engage in performative knowledge sharing.

Software projects often fail because stakeholders are omitted. Existing stakeholder analysis methods rely on practitioners to manually identify and prioritise stakeholders, which is time consuming, especially in large projects with many stakeholders. This chapter investigates the use of Web 2.0 technologies, such as crowdsourcing and social networking, to identify and prioritise stakeholders. The investigation is based on the application of StakeSource in practice. StakeSource is a Web 2.0 tool that uses social networking and crowdsourcing techniques to identify and prioritise stakeholders. This chapter describes our experiences of and lessons learnt from applying StakeSource in ten real-world projects from six organisations in UK, Japan, Australia, and Canada, involving more than 600 stakeholders. We find that StakeSource can yield significant benefits, but its effectiveness depends on the stakeholders’ incentives to share information. In some projects, StakeSource elicited valuable stakeholder information; in other projects, the stakeholder responses were insufficient to add value. We conclude with a description of factors that influence stakeholder engagement via the use of Web 2.0 tools such as StakeSource. If collaborative tools such as StakeSource were to find a place in requirements engineering, we would need to understand what motivates stakeholders to contribute.

In this chapter, we present an approach toward better understanding and analyzing significant aspect of software – the requirements. Comprehending the semantics of requirements is crucial to the success of the intended software. In order that the software requirements be well understood, it is imperative that these must be complete and consistent. But, the elicited requirements are often incomplete, inconsistent, and, consequently, ambiguous in nature. Requirements engineer is presented with the task of examining and analyzing such requirements and detecting these issues, i.e., instances of incompleteness and inconsistency. We present here courteous logic-based representations of requirements as an approach toward resolving the issues of incompleteness, inconsistency, and ambiguity in the elicited requirements and assisting improved understanding of elicited requirements. We explain how courteous logic can be an effective solution to requirements interpretation in terms of observable behavior of the system and can be a useful tool for requirements engineer toward improving the quality of software requirements. We will be more concerned toward inconsistency and incompleteness issues in this chapter.

Verification of the domain engineering is motivated by two reasons: (1) the huge size of the software assets and (2) the possibility of changes in business rules or in stakeholders’ needs which affect the structure of the domain engineering. To solve this problem of verifying software product line (SPL), we propose set of rules to verify four operations: inconsistency detection, inconsistency prevention, dead feature detection, and false-optional feature detection. Scalability is a key factor in measuring the applicability of the methods dealing with the domain engineering. We generated experiments for testing the scalability of our approach. Our experiments results show that our approach is scalable.

The recent migration from traditional sequential development process models to the more modern iterative and evolutionary process models has brought about an evolution in the scope of the requirements engineering process, along with new challenges of managing the requirements knowledge. In parallel, conceptual modeling throughout the development process has been receiving growing attention and wide acceptance.

Working under the premise that effective requirements knowledge management is a key factor in developing quality software that meets customer needs, the main contribution introduced in this chapter is creation and study of a new requirements engineering and management (REM) framework that is tightly coupled with the evolving conceptual model of the developed system. The integration of the proposed REM process into an Object-Process Methodology (OPM)-based systems development and modeling environment is demonstrated via a case study, followed by an evaluation.

The work presented in this chapter shows that coupling the requirements knowledge management activities with the development methodology and a tool-supported modeling environment creates a comprehensive approach for the production of high-quality software.

Requirements engineering (RE) is considered as one of the most critical phases in software development. Poorly implemented RE processes are still one of the major risks for project failure. As a consequence, we can observe an increasing demand for intelligent software components that support stakeholders in the completion of RE tasks. In this chapter, we give an overview of the research dedicated to the application of recommendation technologies in RE. On the basis of a literature analysis, we exemplify the application of recommendation technologies in different scenarios. In this context, the approaches of collaborative filtering, content-based filtering, clustering, knowledge-based recommendation, group-based recommendation, and social network analysis are discussed. With the goal to stimulate further related research, we conclude the chapter with a discussion of issues for future work.

Writing a good software requirement specification is a complex task. Many different aspects must be taken into account; most of them can only be learned through experience. Being aware of experiences and distilled best practices at the right time when writing a specification is another challenge. Experience-based requirements engineering tools make sharing and reuse of experience feasible. In this chapter, we present design principles for such tools, define a learning model to describe how organisations and individuals can learn new experiences by using them, and sketch a strategy for evaluating experience-based requirements engineering tools. We highlight these concepts with an example.

This chapter is concerned with the Requirements Modeling Framework (RMF) (http://eclipse.org/rmf), an Eclipse-based open-source platform for requirements engineering. The core of RMF is based on the emerging Requirements Interchange Format (ReqIF), which is an OMG standard [1]. The project uses ReqIF as the central data model. At the time of this writing, RMF was the only open-source implementation of the ReqIF data model.

By being based on an open standard that is currently gaining industry support, RMF can act as an interface to existing requirements management tools. Further, by based on the Eclipse platform, integration with existing Eclipse-based offerings is possible.

In this chapter, we will describe the architecture of the RMF project, as well as the underlying ReqIF standard. Further, we give an overview of the GUI, which is called ProR. A key strength of RMF and ProR is the extensibility, and we present the integration ProR with Rodin, which allows traceability between natural language requirements and Event-B formal models.

This chapter summarises the Managing Requirements Knowledge book and concludes with the future work. For this purpose, we performed a case-by-case review of the book chapters as well as other relevant publications and extracted the research issues, main contributions, benefits or lessons learned, and future research directions.