Requirements Definition Process Research Articles

MIGRATING TO ARP4754A: TAILORING OF ARCHITECTURE AND SYSTEMS REQUIREMENTS DEFINITION PROCESSES IN THE ROTORCRAFT INDUSTRY

AbstractRotorcrafts are very complex systems that require a huge systems engineering effort to design, implement and integrate. A successful aircraft design is a matter of good integration between engineering disciplines and suppliers just as much as it is about finding a good technical solution to the customers' expectations. This issue is well understood within the industry and competent authorities. Companies now face the challenge of transitioning from integrating complex systems to make an aircraft (as per ARP4754) to engineering and collating a complex aircraft system as per ARP4754A: in other words, the focus shifted to a more holistic view to the aircraft development, a game changer in all respects. Leonardo Helicopters is tailoring its internal processes to reflect this change and challenge. While the ideal process can be defined today, the transition takes time and a significant change in culture and organization needs to take place. To support the transition, the authors have developed a hybrid approach to the aircraft architecture and system requirements definition process. This new approach leverages existing expertise at a system level to facilitate the integration between systems and the subsequent migration to bridge the gap with the aircraft engineering activities required by the ARP4754A.

Physical modeling and simulation of electro-mechanical actuator-based TVC systems for reusable launch vehicles

This paper presents the high-fidelity physical modeling of a Thrust Vector Control (TVC) system operated by Electro-Mechanical Actuators (EMAs) for Reusable Launch Vehicles (RLVs). In contrast to simplified, often linear, models, high-fidelity physical models enable a better assessment of the actual system performance and a deeper verification of the on-board software robustness against disturbances, unmodeled dynamics or degradation. This aspect is essential to enable the reusability concept as driven by long-term reliability requirements. Moreover, critical systems like Fault Detection, Isolation and Recovery (FDIR) logic, whose robustness and efficacy are often difficult to prove, can be thoroughly tested without requiring hardware experiments with eventual invasive modifications for fault injections. This work captures the whole dynamics of the EMA and TVC components, including the power drive electronics, the electrical motor, and the mechanical transmission for the EMA, as well as the mechanical properties of the engine nozzle acting as a load. The resulting differential algebraic equation system is modeled in the Modelica acausal object-oriented modeling language. An ad-hoc framework is implemented to guarantee flexibility and modularity, which allows models with different fidelity levels to be easily exchanged to achieve the simulation objectives and needed accuracy level. The impact of the different models on the closed-loop TVC dynamics is analyzed in both the frequency and time domain, and then benchmarked with a realistic RLV mission. The results show that the high-fidelity physical models provide a better understanding of the more complex effects governing the TVC dynamics and can, in turn, effectively improve its requirement definition process.

Requirements Rationalization and Synthesis Enabled by Model Synchronization

In the international standard for system and software engineering ISO/IEC/IEEE 15288: 2015, the output of the stakeholder needs and the business or mission analysis technical processes are transformed into a technical view of the system by the system requirements definition process. In model-based systems engineering, functional needs can be modeled by use case diagrams. Intended outcomes of system requirements definition include resolution of disagreement about requirements, explicit agreement between stakeholders, and traceability. However, stakeholder needs are often elicited in a siloed manner and may be inconsistent. The lack of mathematically based systematic approaches for requirements definition poses a challenge to model-based transformation of needs into a technical view of the system that achieves agreement between stakeholders. This paper specifies and demonstrates mathematical frameworks for <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">rationalizing</i> and <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">synthesizing</i> functional needs that have been captured through an elicitation process. Benefits of this approach include but are not limited to supporting rigorous identification and resolution of disagreements and facilitating systematic analysis of change impact to achieve stakeholder agreement all with minimal intervention by the system engineers.

Design Requirements for a Teledermatology Scale-up Framework

The value proposition of full-scale teledermatology is evidenced in the literature. The public health sector of South Africa’s KwaZulu-Natal province began synchronous teledermatology in 2003, followed by spontaneous asynchronous (mobile) teledermatology in 2013. No scale-up has been formally planned. This paper establishes design requirements that will inform the identification or de novo development of a teledermatology scale-up framework.&#x0D; &#x0D; Methods: A requirements definition process with inductive reasoning approaches was applied. Analysis of semi-structured interviews (19) with key teledermatology stakeholders (17) and observations from two teledermatology programmes, informed by lessons learned from prior teledermatology implementation attempts, eHealth scale-up literature and authors’ expert opinion, led to identification of Themes, and iterative reflection gave rise to Categories and Requirements.&#x0D; &#x0D; Results: Teledermatology scale-up framework design requirements emerged comprised of themes (4), categories (12), and specific design requirements (30). &#x0D; &#x0D; Discussion: This paper describes a process and resulting evidence-based (stakeholder interviews; programme observations; literature) and experience-based (expert opinion) design requirements to inform the identification and adoption / adaptation or de novo development of a teledermatology scale-up framework (TDSF) for KwaZulu-Natal’s public health sector. The proposed approach is recommended as a pre-requisite for scaling, including in other settings and for other telehealth applications.

Your Wish, My Command – Speeding up Projects in the Transportation Industry Using Ontologies

AbstractThis paper presents the results of an exploratory study conducted at ALSTOM on the application of knowledge‐centric approaches to the requirements definition process. The original scope of the study concerned the application of ontologies to analyze and improve the quality of specification documents in an industrial context. An additional idea quickly emerged as a collateral benefit of the study to extend the usage of the gathered knowledge base in order to perform computer‐assisted identification of requirements from structured and unstructured documents. The purpose of this new approach is to improve the execution of projects in railway transportation by accelerating the requirements management and development processes and, in particular, the stakeholder requirements capture and elicitation activities.

Stabilization Model Building of Management-research for Requirement Definition Streamlining in ITSC Management

Requirements definition that is an important work process for a project and may determine the success or failure of system development project tends to draw an ambiguous conclusion, which will lead directly to the failure of such a system construction. We think the destabilizing factors that introduce ambiguity into the requirements definition process and, as a result, cause requirements definition projects to fail are factors due to requirements definition methods, factors due to undefined implicit requirements, and factors due to interpersonal relationships among stakeholders. We will analyze requirements definition projects’ “destabilizing factors” that destabilize the requirements definition process and result in requirements definition failures as well as failure of IT System Construction (hereinafter referred to as ITSC) as a whole, then we will use fuzzy logic to model this. Additionally, using examples of actual ITSC requirements definition projects, we will apply our model to the situations of a project that concluded successfully and a project that ended in failure, then consider the cause and effect relationship between destabilizing factors and the success and failure of requirements definition projects.

The Analysis and Proposed Modifications to ISO/IEC 25030—Software Engineering—Software Quality Requirements and Evaluation—Quality Requirements

The quality of the software product is a crucial factor that contributes to its success. Therefore, it is important to specify the right software quality requirements that will establish the basis for desired quality of the final system/software product. There are several known methodologies/ processes that support the specification of the system/software functional requirements starting from the user needs to finally obtain the system requirements that the developers can implement through their development process. System/software quality requirements are interdependent with functional requirements, which means that the system/software quality requirements are meant to be specified in parallel with the latter. The ISO/IEC 25000 [1] SQuaRE series of standards include the standard ISO/IEC 25030—Software engineering—Software Quality Requirements and Evaluation—Quality requirements [2], which has as main goal to help specify software quality requirements. As to date, this standard does not offer clear and concise steps that a software quality engineer could follow in order to specify them. This article presents modifications recommended for ISO/IEC 25030 standard, with, among the others, a new requirements definition process that allows for specifying the system/software quality requirements taking into account the existing published system and software quality model ISO/IEC 25010 [3] as well as all the stake- holders of the project.

The Success or Failure of the Requirements Definition and Study of the Causation of the Quantity of Trust Existence Between Stakeholders

Abstract Requirements definition that is an important work process for a project and may determine the success or failure of system development project tends to draw an ambiguous conclusion, which will lead directly to the failure of such a system construction. To optimize the requirements definition process we present a model that the trust management process is integrated into the requirements definition process, as measures to minimize the gap between requirements caused due to a lack or discrepancy in communication that is produced easily in requirements definition and to use a negotiation method for solving problems in the following processes provided by the gap between requirements including tacit ones. We discuss a matter that building trust between the stakeholders in the requirements definition process is effective to optimize the requirements definition, which has been produced by the special characteristics of Japanese firms in the information system development, and we also describe the necessity and effectiveness of information system in Japan.

Taxonomy and Application of EM for Functional Design of Web Map Applications

Designand development of a Web map application as part of Geographic Information Systems (GIS) is a complex activity because of specific areas and stakeholders that are involved in this process. The quality aspect of the requirement definition process is important for application functionality. The complexity of web applications has increased in the last few years and web map applications have made great progress from simple map portrayal to complex applications with a large number of functions. Enterprise modelling (EM) can be used for a multitude of different purposes, like visualization of the current situation, analysis of the reasons for shortcomings or problems, development of strategies for business or IT, optimization of processes, or establishment of new cooperation with other enterprises, as well adapted to the versatile purpose in the design of an information system. The aim of this paper is to discuss opportunities and a new approach supported by enterprise models for designing web map applications. The outcomes of this paper are: (1) taxonomy of a web map application and support of enterprise modelling for functionality analysis; (2) extension of EM to specify requirements for web map application; (3) description of practical applications of the findings.

1.2.2 The Role of Stakeholders in Requirements Elicitation

AbstractThe requirements definition process begins with the elicitation of stakeholder requirements, the first step of which is to identify the stakeholders from whom those requirements are to be gathered. It is common in requirements engineering to define a stakeholder as someone who has a stake in the project—that is, someone who is affected by the system in some way, or can affect the system in some way. In most systems, this definition is not useful since, regardless of where the system boundary is set, it is often difficult to find someone who is not affected by the system. While we must take into account anyone or anything that is affected by, or that can affect, the system when considering requirements, such entities are not automatically (nor necessarily) stakeholders. This paper proposes that a more useful definition of a stakeholder is someone who has a right to influence the system. A method for selecting stakeholders is proposed, and a simple example is provided to illustrate the process.

Improving the Planning and Requirements Definition Process

Improving the Planning and Requirements Definition Process

A Case Study Regarding the Establishment of Non-Functional Requirements Definition Process in IT Department(&lt;Special Issue&gt;Project Planning and Evaluation)

A Case Study Regarding the Establishment of Non-Functional Requirements Definition Process in IT Department(&lt;Special Issue&gt;Project Planning and Evaluation)

10.4.2 On an Appropriate Set of Characteristics for the Structure of Upper‐level Standards When Used to Establish Business Environments

AbstractThe establishment of business environments has been greatly enhanced through the development of upper‐level standards that provide ‘strategic tools and guidelines…They ensure that business operations are as efficient as possible, increase productivity and help companies access new markets‘. (ISO 2012). Once a suitable upper‐level standard is adopted by an organisation, its processes, activities, and tasks must be mapped (or allocated) into the organisation's life cycle stages, procedures, and roles so that subsequent planning can occur, resources can be allocated, and work conducted. Organisations may also wish to claim (or will often be obliged to show) conformance to a particular standard. In many cases, however, this mapping is only able to be demonstrated in general terms, so that upper‐level standards are not always used as comprehensively as they are intended. In order to facilitate the establishment of business environments, this paper addresses what is required for an upper‐level standard to be mappable and then proposes characteristics for the structure of such standards that would enable them to be more readily mappable into a business environment. The Stakeholder Requirements Definition process of ISO/IEC 15288 is used as an example to illustrate how structuring a standard against such characteristics might improve the ability to establish business environments.

Identifying requirement attributes for materiel and non-materiel solution sets utilizing discrete choice models

In 2008, the Government Accountability Office (GAO) performed a study on 11 Department of Defense (DoD) programs and compared how requirements were developed between DoD and private industry. The study found that the DoD did not follow good Systems Engineering practices when developing requirements, resulting in program cost and schedule overruns. With 2011 Defense spending at approximately $711B, it is undeniable that significant portions of these resources are spent on programs that meet their demise due to poorly developed requirements documentation. Such requirements are poorly written, lack clear traceability and threaten the viability of the programs. The question arises whether these issues are due to poor training during the requirements definition process, lack of suf- ficient information and expertise available at program initiation, or a decrease in emphasis on establishing quality attributes for requirements. This study evaluates requirement attributes for materiel and non-materiel solution sets, and whether these attributes are the same or different. A case study example is presented identifying a selected set of requirement attributes and, with the aid of expert practitioner knowledge, these attributes are ranked in order of preference for materiel and non-materiel solutions sets.

How to implement the abstract design paradigm: the case of requirements engineering

This paper presents a framework enabling requirements engineering in accordance with the abstract design paradigm, that is, a systems-modelling conception of and approach to design. Its main contribution is to show how the ISO 15288 standard can be applied and how the appropriate development of Systems Modelling Language (SysML) requirement diagrams can help achieve this objective. ISO 15288 recognises requirements as design entities and specifies the content of a Requirements Definition Process and a Requirements Analysis Process. We propose using four diagrams to map stakeholders’ requirements, to link these requirements via causal relationships and to ensure their traceability. We apply the proposed framework to the case of a robotised gearbox design.

ActCPG framework to learn about information user requirements of a clinical practice guideline

A clinical practice guideline is a knowledge uptake instrument that supports evidence-based decision making by clinicians. It represents a model of a clinical process that describes the sequence of actions, decisions and their outcomes, and the interface with other processes beyond the scope of a guideline. In domains outside healthcare, the computerization of business processes via information systems follows a very rigorous design labeled as the system development life cycle. Our argument is that the computerization of a clinical practice guideline is the equivalent of building an information system for a clinical process and therefore should follow a similarly rigorous design method. One of the first and also one of the most important steps in the system development life cycle is learning about user information requirements. This paper is about a user requirements elicitation and definition process customized to clinical practice guideline. We propose the novel ActCPG conceptual framework for elicitation of basic user requirements for developing computer-interpreted guidelines. This framework relies on Activity Theory to structure and decompose information coming from a clinical practice guideline and associated narrative. We illustrate operation of the ActCPG framework with an example of a practice guideline for a management of clinically obese children enrolled in the Children's Hospital of Eastern Ontario obesity program.

Design Scenarios: Enabling transparent parametric design spaces

This paper presents a novel methodology called Design Scenarios (DSs) intended for use in conceptual design of buildings. DS enables multidisciplinary design teams to streamline the requirements definition, alternative generation, analysis, and decision-making processes by providing a methodology for building and managing requirements driven design spaces with parametric Computer Aided Design (CAD) tools. DS consists of four interdependent models: (1) Requirements Model – stakeholders and designers explicitly define and prioritize context specific design requirements; (2) Scenarios Model (SM) – designers formally transform these requirements into actions necessary to achieve them, and determine the geometric and material parameters, interrelationships, and potential conflicts; (3) Parametric Process Model (PPM) – CAD experts build and represent the technical implementation of a SM in a parametric model to enable design teams to manage and communicate its CAD models; (4) Alternative Analysis Model – analyze and visually report performance back to the designers and stakeholders. This paper motivates the need for the DS methodology thorough an industry case study, and establishes points of departure for the methodology through literature review. Next, the paper details the elements and methods in the methodology, describes its implementation into a software prototype, provides an illustrative example to explain, and an industry test case to validate how DS can potentially enable multidisciplinary teams to generate and communicate larger and better performing design spaces more efficiently than with traditional methods.

Communication-Centered Project Management for Requirements Definition Phase

Requirements definition, which determines a project baseline, has a strong impact on the success of a project. However, since in-depth requirements are gradually revealed through the requirements definition process, the requirements definition is not a straight forward process and often falls into disorder. Thus project management standpoints are critical for the success of the requirements definition. In this paper, we present a framework and mechanisms of communication-centered project management, which controls the requirements definition process based on the situation of communication-oriented activities among stakeholders. In addition, we present a communication-centered project plan with a planning method. The project plan, which represents a time schedule of requirements definition activities, is made by a simulation-optimization algorithm using a stakeholder matrix showing the relations of requirements domains and relevant stakeholders. The effectiveness and the significance of communication-centered project management at the requirements definition phase are demonstrated by numerical examples.

Quantifying the impact of requirements definition and management process maturity on project outcome in large business application development

Using data from two surveys of people knowledgeable about requirements for, and the success of the development of, large commercial applications (CAs) in hundreds of large organizations from around the world, this paper reports a high positive correlation between an organization's requirements definition and management (RDM) maturity and that organization's successful performance on CA development projects. Among the organizations that responded with a filled survey, an organization that is assessed at a high RDM maturity is significantly more successful in its CA development projects than is an organization that is assessed at a low RDM maturity, when success in CA development projects is measured as (1) delivering CAs on-time, on-budget, and on-function, (2) meeting the business objectives of these projects, and (3) the perceived success of these projects. This paper presents a comprehensive framework for RDM, describes a quality RDM process, and describes RDM maturity and how to measure it. It describes the two surveys, the first of which ended up being a pilot for the second, which was designed taking into account what was learned from the first survey. The paper concludes with advice to practitioners on the application of the RDM maturity framework in any organization that wishes to improve its RDM and its performance in the development of large CAs.

Data Warehousing Requirements Collection and Definition

Defining data warehouse requirements is widely recognized as one of the most important steps in the larger data warehouse system development process. This paper examines the potential risks and pitfalls within the data warehouse requirement collection and definition process. A real scenario of a large-scale data warehouse implementation is given, and details of this project, which ultimately failed due to inadequate requirement collection and definition process, are described. The presented case underscores and illustrates the impact of the requirement collection and definition process on the data warehouse implementation, while the case is analyzed within the context of the existing approaches, methodologies, and best practices for prevention and avoidance of typical data warehouse requirement errors and oversights.