Categories and Functional Requirements

Transcription

1 Categories and Functional Requirements CS/SE 3RA3 Ryszard Janicki Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada Ryszard Janicki Categories and Functional Requirements 1/10

2 Previous Lecture Categories of requirements Types of statement: descriptive vs. prescriptive Scope of statements: Environment, Software, Environment Software, Environment \ Software, Software \ Environment Types of statement: system requirements, software requirements Types of statement: domain properties, assumptions, definitions Four Variable Model: monitored variables, input variables, output variables, controlled variables Mapping software reqs to system reqs: SOFREQ, ASM, DOM = SYSREQ. Ryszard Janicki Categories and Functional Requirements 2/10

3 Functional requirements: prescribe what services the software-to-be should provide capture intended software effects on environment, applicability conditions capture intended software effects on environment, applicability conditions units of functionality resulting from software operations For example: The software shall control the acceleration of all trains Non-functional requirements: constrain how such services should be provided Quality requirements: safety, security, accuracy, time/space performance, usability,... Others: compliance, architectural, development reqs For example: Acceleration commands shall be issued every 3 seconds to every train

4 A possible taxonomy (from the textbook) of non-functional requirements A (ie. one of many) taxonomy of non-functional requirements Non-Functional Requirement Quality of Service Compliance Architectural Constraint Development Constraint Accuracy Safety Security ReliabilityPerformance Interface Installation Distribution Cost Maintainability ConfidentialityIntegrity Availability Time Space Subclass link Cost User Device Software interaction interaction interoperability Usability Convenience DeadlineVariability See definitions and examples in the book No clear-cut boundaries, possible overlaps Functional/non-functional: e.g. functional reqs for firewall management are security-related Non-functional overlaps: e.g. high frequency of train commands is related to performance and safety

5 We look at those requirements that are there because of the product fundamental reason for existence The functional requirements specify what the product must do They relate to the actions that the product must carry out in order to satisfy the fundamental reasons for its existence. For example: The product shall determine which road sections pass through areas that are predicted to freeze. It describes an action that the product must take if it is to carry out the work for which it is intended. Ryszard Janicki Categories and Functional Requirements 5/10

6 Functional requirements are: Specifications of the products functionality; Actions the product must take - check, calculate, record, retrieve; Derived from the fundamental purpose of the product; Not a quality - for example, fast is a quality, and therefore it is a non-functional requirement. Think of the functional requirements as the business requirements Ryszard Janicki Categories and Functional Requirements 6/10

7 The functional requirements are a specification of the real work, or business, independent of the way that work will be carried out The functional requirements must fully describe the actions that the intended product can perform So a requirement for the requirements is that the products builder be able to use them to construct the product desired by your client. At their discovery stage they are not necessarily rigorous nor complete Ryszard Janicki Categories and Functional Requirements 7/10

8 The writing activity formalizes each requirement The product shall show the weather for the next twenty-four hours. The product shall show all roads predicted to freeze. Anything has the potential to be ambiguous Continually minimize that risk by clarifying the context A problem to be discussed in details: Shut off the pumps if the water level is above 100 meters for 4 seconds. Ryszard Janicki Categories and Functional Requirements 8/10

9 Shut off the pumps if the water level is above 100 meters for 4 seconds. There are several reasonable interpretations: 1 Shut off the pumps if the mean water level over the past 4 seconds was above 100 meters. 1 4 t t 4 WL(t)dt > Shut off the pumps if the median water level over the past 4 seconds was above 100 meters. (max [t 4,t] (WL(t)) + min [t 4,t] (WL(t)))/2 > Shut off the pumps if the minimum water level over the past 4 seconds was above 100 meters. min [t 4,t] (WL(t)) > 100

10 Example (Sample of Functional Requirements for Elevator Systems) The doors must not open when the elevator is moving. The doors must be able to open when the elevator is fully arrived at each floor of the hotel. The elevator will not move or close its doors if the combined weight of the passengers exceeds the maximum limit. When an elevator has no requests, it should go to and stay at a predefined holding floor for that elevator. Floor buttons will illuminate immediately when they are pushed, and will turn off immediately upon the elevator stopping at the indicated floor. Each elevator has an emergency button, which when pressed sends an immediate warning signal to the site manager. The elevator is then deemed out of service. Each elevator has a mechanism to cancel its out of service status. Ryszard Janicki Categories and Functional Requirements 10/10