China
Africa
Explore chapters and articles related to this topic
Systems Theory
Published in Vivek Kale, Digital Transformation of Enterprise Architecture, 2019
Functional architectural requirements have the least influence on design. High-level functional requirements are best described with use cases. Although too cumbersome for modeling detailed requirements, use cases are excellent for discovering, analyzing, and documenting functional requirements necessary for designing the architecture. Use cases are not models for functional decomposition, nor should designers use them to describe how the system provides services. Use case models describe what is needed in a system in terms of functional responses to given stimuli. A use case is initiated by an entity, and then goes on to describe a sequence of interactions between the entity (or entities) and the system that, when taken together, model systemic functional requirements. Use cases may also include variants of the normal operation that describe error occurrences, detection, handling and recovery, failure modes, or other alternative behaviors.
Evaluating the Reliability of Digital Forensics Tools for Cyber-Physical Systems
Published in Yassine Maleh, Mohammad Shojafar, Ashraf Darwish, Abdelkrim Haqiq, Cybersecurity and Privacy in Cyber-Physical Systems, 2019
Precilla M. Dimpe, Okuthe P. Kogeda
Functional requirements define the functionality of a software or system, i.e., how it should act in response to certain input or react in certain situations (Nidhra 2012). The functional requirements were determined in order for us to know what to test and how to test it. The core functional requirements of our model are as follows: The model shall recommend a suitable tool based on the task, category and cost.The model shall inform the user (DFI) if the required tool is not available.The model shall allow the user to provide feedback on the tool.The model shall ignore feedback from the beginner and novice user and consider only feedback from the intermediate, advanced and expert user.The model shall calculate feedback based on the weighted score.The model shall use the feedback provided by users to update the data in the database.
Systems Theory
Published in Vivek Kale, Enterprise Process Management Systems, 2018
Functional architectural requirements have the least influence on design. High-level functional requirements are best described with use cases. Although too cumbersome for modeling detailed requirements, use cases are excellent for discovering, analyzing, and documenting the functional requirements necessary for designing the architecture. Use cases are not models for functional decomposition, nor should designers use them to describe how the system provides services. Use case models describe what is needed in a system in terms of functional responses to given stimuli. A use case is initiated by an entity and then goes on to describe a sequence of interactions between the entity (or entities) and the system that, when taken together, model systemic functional requirements. Use cases may also include variants of the normal operation that describe error occurrences, detection, handling and recovery, failure modes, or other alternative behaviors.
A novel fuzzy credit risk assessment decision support system based on the python web framework
Published in Journal of Industrial and Production Engineering, 2020
Yung-Chia Chang, Kuei-Hu Chang, Yi-Hsuan Huang
User requirements are divided into two types: functional and nonfunctional requirements. Functional requirements define the functions and services that the system must perform. Nonfunctional requirements, also known as system quality requirements or limitations, define the system’s characteristics to judge its work based on certain conditions. The functional and nonfunctional requirements defined for this system are described as follows:
The role of environmental requirements in Swedish public procurement of bus transports
Published in International Journal of Sustainable Transportation, 2022
Malin Aldenius, Panagiota Tsaxiri, Helene Lidestam
The European Commission (2019b) has suggested ways to use GPP requirements for purchasing of bus services by dividing the requirements into “technical specification” and “award criteria”. Technical specification (in the Swedish bus sector divided into functional and specific requirements) can include for example, technical options to reduce greenhouse gas emissions. The term “functional” requirements refers to requirements to reach a goal without exactly specify how it should be done; it can be expressed as a function, effect or result. One example thereof is to demand a maximal level of emissions rather than specifying a type of fuel. The latter demand regarding the choice of fuel is one example of a “specific” requirement. Previous research of the public transport sector has shown that how the requirements are set can be influenced by the cost factor (Aldenius & Khan, 2017; Brammer & Walker, 2011; Guenther et al., 2013; von Oelreich & Philp, 2013). For example can functional requirements lead to lower capital and operational costs (WSP, 2014), but at the same time it has been seen to only result in the cheapest renewable fuel on the market (Aldenius, 2018). On the other hand, specific requirements can lead to higher costs, but the public sector has better control of the procured services (WSP, 2014). The award criteria refer to how sustainability can be reached by including some kind of incentives motivating the bidder to act in a preferred way. It can be done by providing points to the bus operator for sustainable initiatives in its offer, for example, regarding air pollutant emissions or using more environmental technologies in the buses. When the winner of the bid then is to be chosen, the most common way in tendering is to use “best” price as the criteria, but other criteria have entered the field in combination with the price. In cases where the firm wants to create a green supply chain, the selection of suppliers is based on criteria apart from the price, on quality, flexibility and criteria around environmental management (Tseng & Chiu, 2013).