Systems Requirements Engineering Research Articles

E-Government Information Systems (IS) Project Failure in Developing Countries: Lessons from the Literature

E-government information systems (IS) projects experience numerous challenges that can lead to total or partial failure. The project failure factors have been identified and studied by numerous researchers, but the root causes of such failures are not well-articulated. In this study, literature on e-government IS project failures in developing-world contexts is reviewed through the application of qualitative meta-synthesis, design–reality gap analysis, and root cause analysis. In the process, 18 causal factors and 181 root causes are identified as responsible for e-government IS project failures. The most prevalent of the 18 causal factors are found to be inadequate system requirements engineering (with 22 root causes), inadequate project management (19 root causes), and missing or incomplete features (16 root causes). These findings can be of use to future researchers, policymakers, and practitioners seeking to identify methods of avoiding e-government IS failures, particularly in developing-world contexts.

Modelling Health Process and System Requirements Engineering for Better e-Health Services in Saudi Arabia

This systematic review aimed to examine the published works on e-health modelling system requirements and suggest one applicable to Saudi Arabia. PRISMA method was adopted to search, screen and select the papers to be included in this review. Google Scholar was used as the search engine to collect relevant works. From an initial 74 works, 20 were selected after all screening procedures as per PRISMA flow diagram. The 20 selected works were discussed under various sections. The review revealed that goal setting is the first step. Using the goals, a model can be created based on which system requirements can be elicited. Different research used different approaches within this broad framework and applied the procedures to varying healthcare contexts. Based on the findings, an attempt has been made to set the goals and elicit the system requirements for a diabetes self-management model for the entire country in Saudi Arabian context. This is a preliminary model which needs to be tested, improved and then implemented.

Adapting LOD definition to meet BIM uses requirements and data modeling for linear infrastructures projects: using system and requirement engineering

BackgroundWithin the current organization of design activities it is difficult to fully realize the potential of BIM (Building Information Modelling). In BIM processes, it is necessary to identify and exchange the specific information that is relevant in the exchange information requirements of each project. The concept of level of detail of the information is a tool for describing and quantifying the information that should be exchanged. But the existing definitions of level of detail of information are not easily usable. Precise definitions of methodology, tools and principles are needed to redefine this concept and to use it in order to define the elements of information that are relevant to be exchanged.MethodsThe authors propose the use of System Engineering and Requirements Engineering to define BIM uses and the relevant level of detail of information and its modelling concerned by each BIM use. The authors first explain why, in this context, the existing definitions of LOD, which can mean level of detail, level of development, level of definition, etc., are not sufficient and not always coherent. They demonstrate through real use cases that System Engineering and Requirement Engineering are a part of this methodology and propose, using formalisms, to describe each BIM use in detail.ResultsThe authors apply two different approaches to defining the relevant information to each BIM use. Using a top-down conceptual approach they show that Level Of Detail (LOD) is a crucial element in defining the content of a BIM use. They then verify the practicality of their proposal using a bottom-up approach based on three use cases (acoustic studies, safety audit, sizing drainage system). These cases studies allow the authors to address different kinds of systems and objects within a whole infrastructure project. They represent domain use cases (acoustic and drainage) and coordination use cases (safety audit). This part of the work is based on the L2 project in Marseille, which is a Public Private Partnership for expressways.As a result, a methodology is proposed both to redefine the level of detail of information concept and to describe how this concept is used to complete the BIM uses definition. The system engineering and requirement engineering methods are partially adapted to infrastructure projects. These elements facilitate the description of BIM uses expected in BIM Execution Plans. It was necessary to change the definitions of LOD in order to make them compatible with the methods of requirement management.ConclusionsDesign activities should be reorganized toward the common goal of meeting project needs and requirements. The authors demonstrate that the best way to meet requirements is to define BIM uses using a new definition of the level of detail of information. It has first to consider requirements that have to be reached through BIM and then define the relevant level of detail of information, using the concept of abstraction of reality. To do it well, applying system engineering and requirement engineering, adapted to infrastructure project, is required. To validate this proposal on an entire project, more use cases will be tested in further work.

A Literature Survey on International Standards for System Requirements Engineering

A Literature Survey on International Standards for System Requirements Engineering

Development Prospect of Requirements Engineering for C<sup>4</sup>ISR System

With the construction of C4ISR system was changing from technology-dominated traditionally to requirements-dominated, C4ISR system requirements analysis has already developed into requirements engineering. The conceptual framework and connotation of C4ISR system requirements engineering was introduced, as well as the procedure and methods. Finally, the status of domestic and overseas and future development trend for C4ISR system requirements engineering were analyzed, which will provide guideline for the research of C4ISR system requirements engineering.

Toward a Social Ontology for Conceptual Modeling

Conceptual modeling is fundamental to information systems requirements engineering. Systems analysts and designers use the constructs and methods of a conceptual modeling formalism to represent, communicate, and validate the contents, capabilities, and constraints of an envisioned information system within its organizational context. The value of such a representation is measured by the degree to which it facilitates a shared understanding among all stakeholders of (1) the organizational information requirements and (2) the ability of the envisioned information system to meet them [Wand and Weber, 2002]. We propose using the social ontology developed by John Searle [1995, 2006, 2010] as the basis for conceptual modeling and present a meta-model based on that ontology.

Survey of Concerns in Embedded Systems Requirements Engineering

Survey of Concerns in Embedded Systems Requirements Engineering

A Literature Survey on International Standards for Systems Requirements Engineering

Since 2005, the international organization for standardization (ISO) has published a wealth of standards and reports that deal with requirements engineering for systems. ISO/IEC/IEEE 24765 defines a standard vocabulary for systems and software engineering. ISO/IEC 24766 defines requirements for requirements engineering tools. ISO/IEC/IEEE 29148 describes processes for requirements engineering. The ISO 25000 series targets product quality metrics. This review paper shall provide a high-level description of each of these standards and highlights their interconnection. It thus provides to the systems engineer some guidance as to the relevance of those standards to his or her work.

TOWARDS INTRODUCING A GEOCODING INFORMATION SYSTEM FOR GREENLAND

Abstract. Currently, addressing practices in Greenland do not support geocoding. Addressing points on a map by geographic coordinates is vital for emergency services such as police and ambulance for avoiding ambiguities in finding incident locations (Government of Greenland, 2010) Therefore, it is necessary to investigate the current addressing practices in Greenland. Asiaq (Asiaq, 2011) is a public enterprise of the Government of Greenland which holds three separate databases regards addressing and place references: – list of locality names (towns, villages, farms), – technical base maps (including road center lines not connected with names, and buildings), – the NIN registry (The Land Use Register of Greenland - holds information on the land allotments and buildings in Greenland). The main problem is that these data sets are not interconnected, thus making it impossible to address a point in a map with geographic coordinates in a standardized way. The possible solutions suffer from the fact that Greenland has a scattered habitation pattern and the generalization of the address assignment schema is a difficult task. A schema would be developed according to the characteristics of the settlement pattern, e.g. cities, remote locations and place names. The aim is to propose an ontology for a common postal address system for Greenland. The main part of the research is dedicated to the current system and user requirement engineering. This allowed us to design a conceptual database model which corresponds to the user requirements, and implement a small scale prototype. Furthermore, our research includes resemblance findings in Danish and Greenland's addressing practices, data dictionary for establishing Greenland addressing system's logical model and enhanced entity relationship diagram. This initial prototype of the Greenland addressing system could be used to evaluate and build the full architecture of the addressing information system for Greenland. Using software engineering methods the implementation can be done according to the developed data model and initial database prototype. Development of the Greenland addressing system using a modern GIS and database technology would ease the work and improve the quality of public services such as: postal delivery, emergency response, customer/business relationship management, administration of land, utility planning and maintenance and public statistical data analysis.

Analysis and Need of Requirements Engineering

This paper presents outline of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open Research issues for the future and what is RE all about? When is it needed? What kinds of activities are involved in doing RE? Requirements engineering applies to the development of all software-intensive systems, but not necessarily to the development of all software, as we shall see. There are a huge range of different kinds of software-intensive system, and the practice of RE varies across this range. Our aim throughout this paper is to explore both what is common and what varies across these different types of system. The key techniques used in requirements engineering for dealing with complexity.

Beautiful Testing * Software & Systems Requirements Engineering in Practice * Regular Expressions Cookbook

Beautiful Testing * Software & Systems Requirements Engineering in Practice * Regular Expressions Cookbook

Systems architecting for real-time vehicle controls evaluation

Evaluation systems for Real-Time (RT) vehicle chassis controls as test enabling subsystems are architected and designed using the process for system architecture and requirements engineering. Based on the architecture, plus a few technically ensured subsystem modules, two example test-benches are designed and used for accurate RT Hardware-In-the-Loop Simulations (HILS). The architecture has both common modules, for example RT computer, RT vehicle dynamics model and Graphic User Interface (GUI), and application-dependent modules. Architected test evaluation subsystems are flexible to apply other kinds of vehicle control systems and may be useful for accelerated vehicle development process.

From conceptual modelling to requirements engineering

Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems, i.e., systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events, etc., used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support.