120 likes | 280 Views
Lecture 5.2c: Non-Functional Requirements. Dr. John MacCarthy UMBC CMSC 615 Fall, 2006. Summary. Non-functional Requirements: Requirements not specifically concerned with the (principal/user) functionality of the system.
E N D
Lecture 5.2c: Non-Functional Requirements Dr. John MacCarthy UMBC CMSC 615 Fall, 2006
Summary • Non-functional Requirements: • Requirements not specifically concerned with the (principal/user) functionality of the system. • They often specify constraints or restrictions on the system of interest and/or its development
Some Major Types of Non-Functional Requirements • Performance • Interface • External • Internal • Data Structures • Verification • Logistics/Sustainment • RAM • Other • Constraints
Conclusions • Functional Requirements are those that identify what the system is supposed to do to directly accomplish the primary user goals. • Non-functional requirements are constraints or elaborations on the functional requirements • Generally when they apply to the “System” as a whole or a large set of functional requirements they are included in the “Non-Functional” sections of the Spec. • Generally if they pertain to a single function, they are included in the functional requirements section of the Spec.
IEEE-Std 830 – 1993: 13 non-functional requirements Not the only standard Not the only list Other lists/hierarchies exist Performance Requirements: specifies how well a system performs a functional requirement (or set of them) Interface Requirements: specifies who the system must interface and how Operational Requirements Resource Requirements Verification Requirements Acceptance Requirements Documentation Requirements Security Requirements: Physical Information Assurance Portability Requirements Quality Requirements Reliability Requirements Maintainability Requirements Safety Requirements Logistics Requirements Training Requirements … Classification of Non-Functional Requirements
Product Requirements (constraints on the behavior of the executing system): Performance Reliability, Availability, Maintainability (RAM or RMA) Design constraints (e.g., memory usage, language, hardware, algorithm, etc.) External Requirements Data structures Data values Interfaces Process Requirements (constraints on the development of the system): Development Standards/ Processes (e.g. ISO 9000) Tools Plans Reporting … More on Categorization Note: Most of what K&S specify here should be in a project plan (or SEP), not be in a requirements document. Note: some of these may be included in the functional section of the spec.
Difficulties: Some constraints are related to the design solution and hence unknowable at the requirements stage Some are highly subjective and require complex empirical evaluations Many relate to one or more functional requirements. Separating makes it difficult to see this Stating them together makes it difficult to separate functional from non-functional Non-functional requirements often contradict/conflict with one another It is often hard to determine when some non-functional requirements are met (e.g., information assurance) Often expressed by the customer as “vague concerns” Enterprise Goal Decomposition Approach Essentially functional/ scenario decomposition Deriving Non-Functional Requirement Way to handle non-functional requirements (NFR) depends on the type of NFR and its level.
Performance: Response Times Throughput Timing Correctness/error rate Effectiveness Reliability: Mean Time to Failure Failure Rate Availability : Time (or percent of time) that the system is available to be used (e.g., 24/7, with probability of 0.99999) Security: Prevent unauthorized access Physical Security Information Assurance Access Permissions Backup Encryption Etc. Useability: Required level of user education/ experience/training Training Requirements Handling Requirements (user error rates) Likeability (survey) Safety: “Shall Nots” System Critical Non-Functional Requirements Useability is often hard to quantify.
Many requirements failures can lead to unsafe conditions: Reliability Failure Security Failure Performance Failure Interface Failure Training Failure => Need for Safety Analysis: Fault Tree Analysis Exception Analysis General Process: Identify safety considerations Identify hazardous state Determine how system can reach a hazardous state Analyze risk associated with hazard Derive safety requirements Types of safety-related requirements: Avoidance: ensure cannot occur Prevention: does not result in damage Protection: limit scale of damage Safety-Related Requirements Engineering