1 / 10

Lecture 5.2c: Non-Functional Requirements

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.

nimrod
Download Presentation

Lecture 5.2c: Non-Functional Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 5.2c: Non-Functional Requirements Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

  2. 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

  3. Some Major Types of Non-Functional Requirements • Performance • Interface • External • Internal • Data Structures • Verification • Logistics/Sustainment • RAM • Other • Constraints

  4. 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.

  5. BACKUP

  6. 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

  7. 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.

  8. 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.

  9. 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.

  10. 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

More Related