Towards ubiquitous requirements engineering through recommendations based on context histories

The growing technological advance is causing constant business changes. The continual uncertainties in project management make requirements engineering essential to ensure the success of projects. The usual exponential increase of stakeholders throughout the project suggests the application of intelligent tools to assist requirements engineers. Therefore, this article proposes Nhatos, a computational model for ubiquitous requirements management that analyses context histories of projects to recommend reusable requirements. The scientific contribution of this study is the use of the similarity analysis of projects through their context histories to generate the requirement recommendations. The implementation of a prototype allowed to evaluate the proposal through a case study based on real scenarios from the industry. One hundred fifty-three software projects from a large bank institution generated context histories used in the recommendations. The experiment demonstrated that the model achieved more than 70% stakeholder acceptance of the recommendations.

Identification and classification of barriers and benefits of requirements traceability in project development

Requirements are conditions that a product, service, or process must present and requirements management facilitates this realization. For this, the requirements traceability technique is used for the development of projects and systems and all management of the requirements life cycle. However, the literature recognizes the proven benefits of adherence to the technique, but the plurality of problems inhibits its adherence. Thus, this article aims to identify and classify the barriers and benefits of requirements traceability. For this purpose, it was elaborated a systematic literature review, and for the results´ analysis and codification, the MAXQDA software was used. A total of 15 barriers and 15 benefits were identified. It is possible to verify that both in the case of benefits and barriers, there is a cause and effect relationship between them. In other words, barriers such as “Low flexibility and integration of tools” lead to the emergence of other barriers such as “Management inefficiency”.

Improving the Requirements Engineering Process Through Automated Support: An Industrial Case Study

Although Distributed Software Development (DSD) has been a growing trend in the software industry, performing requirements management in such conditions implies overcoming new limitations resulting from geographic separation. SIDIA is a Research and Development (R&D) Institute, located in Brazil, responsible for producing improvements on the Android Platform for Samsung Products in all Latin America. As we work in collaboration stakeholders provided by Mobile Network Operators (MNO) from Latin countries, it is common that software requirements be provided by external stakeholders. As such, it is difficult to manage these requirements due to the coordination of many different stakeholders in a distributed setting. In order to minimize the risks, we developed a tool to assist our requirements management and development process. This experience paper explores the experience in designing and deploying a software approach that facilitates (I) Distributed Software Development, (II) minimizes requirements error rate, (III) teams and task allocations and (IV) requirements managements. We also report three lessons learned from adopting automated support in the DDS environment.

Method for managing requirements in healthcare projects using building information modelling

PurposeThis paper proposes a method for managing client requirements with the use of Building Information Modelling (BIM). The development of healthcare projects demands a large amount of requirements information, in order to deal with a diversity of clients and frequents changes in healthcare services. The proposed method supports healthcare design by adopting a process-based approach for client requirements management, with the aim of improving value generation.Design/methodology/approachDesign Science Research was the methodological approach adopted in this investigation. The main outcome of this study emerged from an empirical study carried out in a healthcare project in Brazil.FindingsThe proposed method involves three stages: (1) capturing and processing requirements; (2) product and requirements modelling, which involves the connection between requirements and the BIM 3-D model and (3) supporting design solution refinement, through the communication of requirements and the assessment of design in relation to updated client requirements information.Originality/valueThis study explores client requirements management from a process perspective, proposing activities and their interdependences and possible sources of data, including healthcare services information. The main theoretical contributions are related to the understanding of the nature and complexity of the information involved in client requirements management, and how this can be modelled.

Requirements Management for Data Driven Requisitions

Objectives/Scope Systems engineering techniques, particularly requirements management, are critical to realizing the value of digital transformation to improve capital project delivery. Drawing on the results of a case study, this paper will demonstrate the value of using digital requirements management to exchange information through a project lifecycle, specifically showing benefits in the integrity of data transfer; more efficient procurement lifecycle; more robust deviation management; and bidirectional traceability of requirements, including full visibility and end to end verification and validation. Methods, Procedures, Process A requirement is a capability to which a project outcome (product or service) should conform, and the purpose of requirements management is to ensure that an organization documents, verifies and validates these capabilities. In this case study the operator provides their technical specifications in the form of requirements. These requirements are then imported into the EPC's PLM platform, where they are supplemented with additional information from the EPC's engineers to create a requirements-based requisition package. This is then transmitted to the equipment supplier, where it is reviewed and, for the purposes of the case study, reviewed for completeness. To test the ability to identify changes and deviations, the EPC engineer modified the requirements and the file was transferred to both the operator and equipment supplier to ensure the changes were transferred and were identifiable. The case study also demonstrates how verification activities (testing, commissioning, etc.) can be linked to requirements; passed through the supply chain and be modified to capture changes to the status of the activity (such as test results). Results, Observations, Conclusions The case studies described show how requirements can be exchanged between operator, EPC and equipment supplier without any loss of data. It will also show how this approach allows a data driven approach, as opposed to a document driven approach, to be deployed in the requisitioning process, which could facilitate substantial reduction in the procurement lifecycle. This is achieved by removing extraneous information exchanged between the companies; the removal of swivel chair solutions, where data is extracted from one system and transferred to another; and expediting the bid evaluation stage. Finally, the case study will demonstrate how this approach could be extended beyond the purchase order to provide a direct link between specific requirements and testing (FATs) or commissioning activities, which facilitates a more efficient process for verification as well as ensuring a digital record of the entire lifecycle of a package. The case study highlighted the importance of aligning data model and developing workflows, these findings are captured in the lessons learned section and have been shared with the International Association of Oil and Gas Producers (IOGP) Requirements Digitalization Task Force (RDTF). Novel/Additive Information The paper will also include a vision of requirements models can be used to establish a holistic requirements model of a project, including the interdependencies of different system components. The case study will also demonstrate how the adoption of a common data standard for requirements allows a software agnostic solution that can be adopted by all.

Transformation of Digital Requirements: An Enabler for Successful Complex Projects

This paper discusses the lessons learned from transforming upstream operational requirements from a document environment into a requirements management tool (database). Operations requirements from upstream practices, procedures, specifications, and guides were migrated from a document centric environment into a requirements management system (data centric). Here, requirements were assigned attributes denoting the organization and accountable operational role that requirement. Many organizations, operating complex offshore procedures, especially where operations are highly regulated, are looking to move their operational requirements from a document centric environment to a data centric environment. This paper highlights some potential pitfalls and mitigation strategies for ensuring a successful migration.

Benefits of Using Requirements Management Tools on a Digitized API 17O Document

Currently oil and gas companies are spending billions of dollars on digitalization efforts. One important aspect of a project that needs to be digitized are requirements. Most oil and gas companies receive project documentation and requirements as PDF files. Receiving PDF documents make it very difficult for companies to manipulate the content to identify which parts of the document are requirements and which parts are just background information. In addition, documents that contain requirements have poorly written requirements that are ambiguous, and can have many interpretations, making it difficult to show compliance. To solve the issues caused by poorly written requirements and receiving PDF files instead of receiving requirements in a more usable format, the solution is to rewrite the requirements and use a requirements management (RM) tool to put the requirements in a database. The American Petroleum Institute (API) 17O 2nd Edition document and a representative list of High Integrity Pressure Protection System (HIPPS) product requirements are used to show the benefits of using a requirements management tool. This paper will describe the prerequisites prior to selecting an RM tool, show how using a requirements quality analyzer tool can aid in preparing requirements to be imported into an RM tool, demonstrate the main benefits of using an RM tool in a project context, and discuss lessons learned from adding an RM tool to a document-based project.

PROCEDURE MODEL FOR STRUCTURED RELATIONAL MODELING OF REQUIREMENTS TO SUPPORT REQUIREMENTS-ORIENTED DECISION MAKING

The development of complex technical systems is characterized by a large number of system elements as well as their interactions. With regard to requirements management, many requirements have to be considered, which can have different relations to each other. If these requirements are used as basis for criteria in the decision making process, these relations must also be considered in the multi-criteria evaluation of product alternatives. Therefore, a computer-aided approach is presented in this paper, which allows the systematic modeling of requirement interactions focusing on multi-criteria decision making. For this purpose, basic relation types are identified, which are used to model submatrices in order to derive the Requirement Relation Matrix (RRM). Matrix-based as well as graph-based visualization methods are used for the RRM in order to improve the alternatives with the knowledge about the relational linkage. In addition, the effects of changes in requirements can be transferred to the decision making process. The approach is exemplarily applied to the extension of a test laboratory by a test bench.