Exploring Knowledge Engineering Strategies in Designing and Modelling a Road Traffic Accident Management Domain

Formulating knowledge for use in AI Planning engines is currently something of an ad-hoc process, where the skills of knowledge engineers and the tools they use may significantly influence the quality of the resulting planning application. There is little in the way of guidelines or standard procedures, however, for knowledge engineers to use when formulating knowledge into planning domain languages such as PDDL. This paper seeks to investigate this process using as a case study a road traffic accident management domain. Managing road accidents requires systematic, sound planning and coordination of resources to improve outcomes for accident victims. We have derived a set of requirements in consultation with stakeholders for the resource coordination part of managing accidents. We evaluate two separate knowledge engineering strategies for encoding the resulting planning domain from the set of requirements: (a) the traditional method of PDDL experts and text editor, and (b) a leading planning GUI with built in UML modelling tools. These strategies are evaluated using process and product metrics, where the domain model (the product) was tested extensively with a range of planning engines. The results give insights into the strengths and weaknesses of the approaches, highlight lessons learned regarding knowledge encoding, and point to important lines of research for knowledge engineering for planning

Modeling and managing tacit product line requirements knowledge

The success of very large product lines systems with globally distributed stakeholders often builds significantly on the implicit knowledge of individuals. Final products are typically built by integrating numerous detailed specifications of subsystems. But how exactly all these parts can and need to be integrated to build valid end products is often left unspecified and to numerous discussions, reviews and the expertise of senior architects and product managers. Building a high-level product line requirements model that explicitly and formally specifies common and variable requirements, their precise integration semantics and the constraints for selecting variable features helps significantly to manage this crucial and often tacit requirements knowledge. Based on an industrial exemplar we motivate and demonstrate such an approach and discuss our early findings regarding knowledge and rationale management in product line requirements engineering

Scope Management of Non-Functional Requirements

In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort estimates and priorities, as well as their risk. This knowledge enables analysts, managers and software engineers to identify the most significant requirements from the list of requirements initially defined by the user. In practice, this scope assessment is applied to the Functional Requirements (FRs) provided by users who are unaware of, or ignore, the Non-Functional Requirements (NFRs). This paper presents ongoing research which aims at managing NFRs during the software development process. Establishing the relative priority of each NFR, and obtaining a rough estimate of the effort and risk associated with it, is integral to the software development process and to resource management. Our work extends the taxonomy of the NFR framework by integrating the concept of the "hardgoal". A functional size measure of NFRs is applied to facilitate the effort estimation process. The functional size measurement method we have chosen is COSMICFFP, which is theoretically sound and the de facto standard in the software industry

Looking for Reasons behind Success in Dealing with Requirements Change

During development, requirements of software systems are subject to change. Unfortunately, managing changing requirements can take a lot of time and effort. Yet some companies show a better management of changes in requirements than others. Why? What is it that makes some projects deal with changing requirements better than others? We pursue the long term goal of understanding the mechanisms used to successfully deal with change in requirements. In this paper we gather knowledge about the state-of-the-art and the state-of-practice. We studied eight software development projects in four different companies --large and small, inclined toward structured and toward agile principles of development--, interviewing their project managers and analyzing their answers. Our findings include a list of practical (rather than theoretical) factors affecting the ability to cope with small changes in requirements. Results suggest a central role of size as a factor determining the flexibility showed either by the organization or by the software development team. We report the research method used and validate our results via expert interviews, who could relate to our findings

BIM semantic-enrichment for built heritage representation

In the built heritage context, BIM has shown difficulties in representing and managing the large and complex knowledge related to non-geometrical aspects of the heritage. Within this scope, this paper focuses on a domain-specific semantic-enrichment of BIM methodology, aimed at fulfilling semantic representation requirements of built heritage through Semantic Web technologies. To develop this semantic-enriched BIM approach, this research relies on the integration of a BIM environment with a knowledge base created through information ontologies. The result is knowledge base system - and a prototypal platform - that enhances semantic representation capabilities of BIM application to architectural heritage processes. It solves the issue of knowledge formalization in cultural heritage informative models, favouring a deeper comprehension and interpretation of all the building aspects. Its open structure allows future research to customize, scale and adapt the knowledge base different typologies of artefacts and heritage activities

Designing a Knowledge Management System – A Case Study of a Global Telecommunications Company

This paper focuses on the challenges a global telecommunication company faces in managing their existing knowledge management (KM) systems and planning for a new enterprise-wide knowledge management system (KMS). Data was collected from six user roles using three disparate knowledge repositories. The design requirements for a new enterprisewide knowledge management system are presented. This paper offers a contribution to the study of information science by providing empirical evidence to the design requirements of an enterprise-wide KMS

An analysis of design for manufacturing requirements for managing aerospace manufacturing knowledge

In the manufacturing lifecycle of aerospace products, large amounts of data are generated throughout the activities involved. Much of this data contains useful knowledge for engineers to improve various aspects of Design for Manufacturing (DFM) of new or existing products that may help reduce defects in future manufacturing activities. An investigation is carried out at a large UK based manufacturer of aerospace products that aims to introduce an improved approach that supports design engineering activities to make use of the ‘data’ generated to drive the number of re-occurring defects down. This paper particularly focuses on analyzing the requirements for introducing a solution identified from questionnaires, observations and stakeholder reviews and proposes a framework of the components to enable its implementation. The research discussed the requirements and concludes the main findings toward implementing a fully integrated solution at the collaborating company in order to improve data usefulness and effectiveness

Requirements Engineering: A Tube-Map.

In this paper, a diagrammatic representation of the main processes occurring in Requirements Engineering has been introduced. Adopted style has been derived by the notorious London Tube Map: it allows practitioners, academics and all stakeholders to fully appreciate the complex set of iterations as they occur during any software development project. Some benefits have been discussed: non technical stakeholders can be provided with a simple and yet effective tool to communicate among each other; requirements engineers and analysts can easily track their activities; academics can use the map for teaching purposes as well as to remind themselves what practical help they can provide against the expected outcomes RE community would look for. Potential developments of the map are its transformation into a system integrator, in order to facilitate practitioners in managing the fragmentation of the discipline; and the possibility of the map to become a virtual “gate” to any knowledge repository which emerges within any development project.Peer reviewe