China
Africa
Explore chapters and articles related to this topic
Planning and Defining the Project Scope
Published in Davies A. Igberaese, Introduction to Project Management, 2023
Solution Requirements describe the features, functions, and characteristics of the products, services, and results that would meet the business and stakeholder requirements. These include Functional and Non-Functional Requirements. Functional Requirements relate to the functional behaviour of the product while Non-Functional Requirements are supplementary requirements relating to the operating environment for the product, e.g. security, safety, supportability, etc.
Prognostic and health management design for subsea applications
Published in Stein Haugen, Anne Barros, Coen van Gulijk, Trond Kongsvik, Jan Erik Vinnem, Safety and Reliability – Safe Societies in a Changing World, 2018
Xiaojing Gao, Octavian Niculita, Don McGlinchey, Babakalli Alkali
Step 1 – The start of the PHM design process is represented by the requirements phase. High-Level (HL) requirements are typically divided into functional requirements (FR) and non-functional requirement (NFR) categories. Functional requirements define the technical details of a system (including the function of the system and the functions of each individual component) and non-functional requirements cover the attributes of the system (such as safety, reliability, maintainability, usability, performance, security, etc.). The Design/Re-design/ Instrumentation phase of the PHM development process coordinates various engineering analysis to ensure the final subsea design is meeting the requirements established at the start of the project. During the design phase, data associated with the environmental conditions, reservoir, well completion, process and operations, host facilities, safety and hazards should be considered when progressing through conceptual, FEED and detailed design. These engineering efforts are targeting the technical requirements (also known as functional requirements (FR)) of a subsea system since this design element is heavily regulated and supported through recommended practices (ISO 13628–1, 2010). Non-Functional Requirements are also considered by the current subsea design best practices and they cover safety, performance and security. However, there is no attempt to define and to target the reliability and maintainability requirements at the early stage of the design. This influences the PHM requirements definition as these are derived from the reliability and maintainability requirements. Only recently, the industry has generated recommended practices like the API-RP-17 N on topics related to reliability, technical risk and integrity management (API RP 17 N, 2009). However, they are not yet adopted due to the lack of tools, processes and meaningful reliability data to support their implementation. Reliability and maintainability requirements should be part of the non-functional requirement (NFR) of the system. Deriving PHM requirements should be done from system’s high-level (HL) Non-Functional requirements. For example, a HL NF requirement for a XT can be affordability by reducing the down-time periods while keeping the same levels of safety. In this manner, cost and safety become main drivers for the development of a PHM solution. Derived PHM requirements can be represented: PHM Requirement 1 – the XT must have a feature that can reliably predict functional failures at least one week prior to the actual event and PHM Requirement 2: the XT must have the capability of offering mitigation/advisory generation in the context of current operational conditions. Having access to information provided by such features, the operator reasonable time to schedule a vessel, equipment, personnel to carry out an intervention on the faulty components.
Concept and basic framework prototype for a flexible and intervention-independent situation recognition system in the OR
Published in Computer Methods in Biomechanics and Biomedical Engineering: Imaging & Visualization, 2022
Denise Junger, Bernhard Hirt, Oliver Burgert
The non-functional requirements define functionality, reliability, usability, efficiency, modifiability, and transferability. The system should consist of modules for expandability (e.g. sensors, context information). Interchangeability, like sensors with the same purpose, should be possible. Context information and its probabilities should be estimated via available knowledge from as many different, relevant sources as possible to minimise bad estimations. The interpretation and provision should be done in a reasonable time. The recognised information is supposed to be used by different context-aware systems at their own risk. Interfaces for these systems should be easily integrable. The system should be operative with local dummy data and exemplary interpretation logics for functional demonstration and serve several ORs simultaneously. Standardised protocols should be used for communication and data be kept confidential. The system should be installable and configurable by experts. User interaction and interfaces for configuration purposes are supposed to be minimal. The system should not exceed the server capacity or overload the hospital network. Functionality tests are supposed to be described for evaluation.
Investigating the impact of requirements elicitation and evolution on course performance in a pre-capstone design course
Published in Journal of Engineering Design, 2019
Beshoy Morkos, Shraddha Joshi, Joshua D. Summers
Finally, the requirements are classified as functional or non-functional based on the definitions found in (Lamar and Mocko 2010; Shankar, Morkos, and Summers 2010). Specifically, functional requirements are defined as those that include a ‘transformative’ or an ‘active’ verb. Non-functional requirements are those that define the existence or properties of a solution. This might be ‘height’ or ‘weight’ as a property or ‘clear window’ as an existence. It’s important to note that in some contexts, a non-functional requirement could be a functional requirement. For instance, a ‘clear window’ could serve a functional requirement if it proves visual access to something. Hence, it is important to view the requirement in its context before determining its functionality. In total, the generated and evolved requirements are collected at eight instances throughout the project duration. Table 3 details the average functional and non-functional requirements collected for each team during each week. These documents are analysed to determine correlations between course grades and requirement types and evolution process.