Semi-formal Requirements Specification Sample Clauses

Semi-formal Requirements Specification. 19 Machine Problem World software/ hardware Requirement what the problem is about “stakeholder” needs Figure 4.1: Problem frames and its application to the cruise control system. the vehicle, e.g., vehicle speed. The Problem Frames approach enforces that the terms used in the re- quirements are precisely defined using so called phenomena which need to be unique throughout the whole requirements document. Moreover, the Prob- lem Frames approach helped us to clearly distinguish between the require- ments, i.e., a description of the desired behaviour in terms of the environment, the environment, i.e., a description of the environment and its assumptions, and the machine, i.e., the actual cruise control system we want to built. In order to derive a semi-formal requirements specification of the cruise control system we applied the process steps shown in Figure 4.2 which schemat- ically describe our extended Problem Frames approach. Each process step answers specific questions. 4.3 shows the resulting hierarchy of problem diagrams of the cruise control system after the application of the process steps described in Figure 4.2. As you can see from Figure 4.3 the hierarchy starts with the context dia- gram Context 0 which describes the cruise control system, its environment, and the requirements from a very abstract point of view. In the first step, this abstract context diagram is elaborated into a more concrete context di- agram (Context 1 ) which itself is projected into three different subproblems, namely signal evaluation, velocity control and display. In an elaboration of 1. Identification of the System Context What is the abstract environment the machine needs to interact with? How does the environment interact with the machine? 2. Elaboration of the System Context Which domains must be considered for the description of the environment? How are these domains connected to each other and the machine? Which are the main requirements?
View Source
Semi-formal Requirements Specification. The purpose of the semi-formal requirements specification is to describe the informal requirements of the cruise control system in a semi-formal way such that they can be easily modelled with Event-B. During pilot deployment we decided to use the Problem Frames approach [Jac95, Jac01] and several extensions we developed for semi-formal require- ments engineering because it allows to structure the problem into require- ments, machine, and the physical world. Furthermore, the problem frames approach and our extensions allows us to decompose a given problem, e.g., the development of a cruise control system, into different subproblems which can be handled separately and later recombined in a subsequent phase. The development task in problem frames is to design a machine by building soft- ware that is then executed on a general-purpose computer, specialising the computer to serve a particular purpose [Jac95]. That purpose is to meet a recognised need, which is called requirement. Satisfying the requirement involves transforming the physical world around us. In Problem Frames, the part of the world to be transformed is called the environment. ▇▇▇▇▇▇▇ states that the parts of any systems engineering problem are the machine, the problem world (environment), and the requirement. Figure 4.1 shows a generalized Problem Frame diagram and its application to the cruise control system. In our application of Problem Frames to the cruise control system, the machine we want to build is the cruise control software running on the en- gine controller. The physical world around us, i.e., the problem world the cruise control software is interacting with, consists of the human machine interface, i.e., the pedals, the lever, and the ignition, as well as the vehicle including engine, engine control, and wheels which need to be controlled by the cruise control. The requirements relate phenomena controlled by the hu- man machine interface, e.g., control signals with phenomena controlled by
View Source

Related to Semi-formal Requirements Specification

  • Escrow Format Specification Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-▇▇▇▇▇-▇▇▇▇▇▇▇-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-▇▇▇▇▇-▇▇▇▇▇▇▇-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.

  • DAF Specifications Developer shall submit initial specifications for the DAF, including System Protection Facilities, to Connecting Transmission Owner and NYISO at least one hundred eighty (180) Calendar Days prior to the Initial Synchronization Date; and final specifications for review and comment at least ninety (90) Calendar Days prior to the Initial Synchronization Date. Connecting Transmission Owner and NYISO shall review such specifications to ensure that the DAF are compatible with the technical specifications, operational control, and safety requirements of the Connecting Transmission Owner and NYISO and comment on such specifications within thirty (30) Calendar Days of Developer’s submission. All specifications provided hereunder shall be deemed to be Confidential Information.

  • General specifications For the purpose of this Regulation, the vehicle shall fulfil the following requirements:

  • General Requirement Any notice, election, demand, request, consent, approval, or other communication required or permitted to be given under this Contract shall be in writing signed by an officer or duly authorized representative of the party making same and shall be delivered personally or shall be sent by certified or statutory mail, postage prepaid, return receipt requested, shall be effective as of the date on which it is received or would have been received but for the refusal of the addressee to accept delivery, and shall be addressed as shown in the Contract. The persons and addresses to which notices should be given may be changed by notice given in accordance with this Article.

  • Equipment Specifications All equipment must meet the contract specifications and all federal and State safety codes and regulations in effect at the date of manufacture. All equipment must be Original Equipment Manufacturer (OEM) equipment unless otherwise stated in the contract. All products, materials, supplies, replacement parts, and equipment offered and furnished must be new, of current manufacturer production, and must have been formally announced by the manufacturer as being commercially available, unless otherwise stated in this Contract.