Explore chapters and articles related to this topic
Intelligent Agents
Published in Satya Prakash Yadav, Dharmendra Prasad Mahato, Nguyen Thi Dieu Linh, Distributed Artificial Intelligence, 2020
Rashi Agarwal, Supriya Khaitan, Shashank Sahu
There are constantly evolving changes in the requirements to meet business goals. Frequent changes in the environment also reflect that it is difficult to find out reasons for the change (Kavakli & Loucopoulos, 2006). Changes in the requirements can occur during software development as well as after software development. Changes may be of different types varies from error correction to change in the behavior of functionality (Lin & Poore, 2008). Changes affect product quality. It also affects the testing of the software because we need to re-test the code that has been changed (Heindl & Biffl, 2008). Requirements are a fundamental activity of software development. It acts as reducing the gap between business and its services (Zhao et al., 2010). There are unknown requirements which are arising in the domain (A. Sutcliffe et al., 2018). Requirements deal with involvement of product engineering, service engineering, and software engineering. Requirements needed for integration are missing and unclear (Berkovich et al., 2014). Large organizations are struggling for management of requirements that may come from informal communications also. There should be suitable methods to adapt and balance these changes in organizations (Heikkilä et al., 2017).
Map Your Best UX Cycle
Published in Andrew Mara, UX on the Go, 2020
For software developers, Requirements (often called Requirement Specifications) are a common document genre that distills what needs to happen in the software before it is considered a complete product. Features, functions, actions, and even style can be included in this document that serves to formalize the complex negotiation between parts of the business (administration, design, marketing, sales, etc.) and the users. By documenting what has come before in the UX Inventory, Opportunity Workshop, and Project Précis (along with any other must-dos that come up during the process), this document creates a set of marching orders for the software developers and other creators of the product. This document should take consideration of costs, time resources, and talents that might be better deployed elsewhere.
Context Modelling for Variability-intensive Systems During Requirements Engineering
Published in Ivan Mistrik, Matthias Galster, Bruce R. Maxim, Software Engineering for Variability Intensive Systems, 2019
Nelufar Ulfat-Bunyadi, Maritta Heisel
Context modelling is performed during requirements engineering. Requirements engineering is the activity of eliciting, documenting, negotiating, validating, and managing requirements for a system [21]. Context modelling is an important activity during requirements engineering due to the following dependency. Each system is developed for a certain context. Requirements for the system are defined based on assumptions about this context. Satisfaction of the system requirements can only be guaranteed if the developed system is integrated into this context. If it is integrated into another context, it is possible that the set of system requirements is no longer satisfied. Due to this dependency between system and context, it is not sufficient to elicit and document only system requirements during requirements engineering. The underlying assumptions about the context, or more generally, the underlying knowledge about the context (i.e. facts and assumptions) needs to be documented as well during requirements engineering.
A comprehensive validation framework addressing utility parameter validation for application in small and medium enterprises (SMEs):A case study in pharmaceutical industry
Published in Cogent Engineering, 2023
Vothia Surian Subramaniam, Joshua Prakash, Shahrul Kamaruddin, Sze Wei Khoo
VEE validation framework (Forsberg and Mooz, 2005a) is based on project cycle and represents a progressive product development process. User requirements are used to ensure a product or system is built according to its specification. The maintenance of ongoing operation is carried out to ensure the system meets the stated requirements. Forsberg and Mooz (2005) also modified their original VEE framework to produce Architecture VEE validation framework, which implements planning of validation activities. In 2006, Forsberg and Mooz introduced Entity validation framework which emphasizes on direct correlation between activities on the left and right legs of the framework at each elaboration. User requirements, risk investigations, validation planning and preparation are executed in this framework.
A Redundancy-Guided Approach for the Hazard Analysis of Digital Instrumentation and Control Systems in Advanced Nuclear Power Plants
Published in Nuclear Technology, 2022
Tate Shorthill, Han Bao, Hongbin Zhang, Heng Ban
While diversity in analog I&C systems is a standard practice, its effectiveness for digital I&C systems remains a topic of concern. The use of digital technologies may “increase the potential for CCF vulnerabilities because of the introduction of undetected systematic faults.”12 These systematic failures (i.e., failures inherent to design specifications and systems interactions13) in the software may result from “(1) errors in the requirement specification, (2) inadequate provisions to account for design limits (e.g., environmental stress), or (3) technical faults incorporated in the internal system (or architectural) design or implementation.”12 Knight and Leveson indicate that independently developed software may not necessarily fail independently.14 These sources highlight the importance of properly defined software requirements to help eliminate system failures. To effectively determine software requirements, one must identify system vulnerabilities. As summarized by Arndt and Kuritzky in 2011, the identification and modeling of software failure modes remains the most challenging aspect of risk analysis for digital I&C systems.15 Once system vulnerabilities have been identified, NUREG/CR-6303 and NUREG/KM-0009 can provide approaches on how to limit them.11,16 More recently, NUREG/CR-7007 was written to determine “how much diversity is enough.”17
(AIAM2019) Artificial Intelligence in Software Engineering and inverse: Review
Published in International Journal of Computer Integrated Manufacturing, 2020
Mohammad Shehab, Laith Abualigah, Muath Ibrahim Jarrah, Osama Ahmad Alomari, Mohammad Sh. Daoud
A software process (also known as software methodology) is a set of related activities that leads to the production of the software (Eisty, Thiruvathukal, and Carver 2019). These activities may involve developing software from scratch or modifying an existing system. Any software process must include the following four activities: Software specification (requirements engineering): The major functionalities of the software and the constrains around them are defined.Software design and implementation: The software is designed and programmed.Software verification and validation: The software must conform to specifications and meet the customer needs.Software evolution (software maintenance): The software is modified to meet the customer needs and the changes in market requirements.