1 / 21

Non-Functional Requirements

Non-Functional Requirements . Non-Functional requirements mostly define the overall attributes of the “resulting” system Most of the time these turn out to be “constraints” on how the (functional) requirements are to be met. (e.g.) Response time must be .xyz second per screen

chick
Download Presentation

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. Non-Functional Requirements • Non-Functional requirements mostly define the overall attributes of the “resulting” system • Most of the time these turn out to be “constraints” on how the (functional) requirements are to be met. • (e.g.) Response time must be .xyz second per screen • Sometimes the functional requirements may have to be “sacrificed or increased” in order to meet the non-functional requirements • (e.g.) in order to satisfy security requirements, we can not let everyoneaccess the system --- sacrificing some flexibility • (e.g.) in order to satisfy the reliabilityrequirements, we may add a duplicative functionality to provide another path to achieve the desired result • Some non-functional requirements may not address the attributes of the resulting system (product), but something else • (e.g.) the system must be developed with a very risk averse process such as Spiral or the system must be developed with Visual Basic language

  2. IEEE Standard 830 – 1993 • List of 13 non-functional requirements: • Performance • Interface • Operational • Resource • Verification • Acceptance • Documentation • Security • Portability • Quality • Reliability • Maintainability • Safety Examples? Some of these also overlap - - - - - -

  3. IEEE Standard 830 – 1993 • List of 13 non-functional requirements Examples: • Performance: 100 transactions per minute • Interface: capable of importing data with EDI format • Operational: must not require more than 1 megabyte of main memory • Resource: will use wireless encryption algorithm that is “better” than WEP • Verification: all data updates must be traceable • Acceptance: must pass a user defined system test bucket • Documentation: user manual is needed for novice users only • Security: user request to access any data must be authorized first • Portability: the system must operate with “any” relational db systems • Quality: the system must install with zero defect • Reliability: the system must be accessible 99.9 % of the time • Maintainability: the system must be modifiable (e.g. designed with exits) • Safety: the system must not perform “chemical material discard” functions without “explicit” user authorization. There may be others that are important such as meeting legal standards that Is not mentioned in this list

  4. Sommerville’s Classification ofNon-Functional Requirements Process Oriented Product Related External Directed Delivery/Updates Usability Legal rules Implementation Reliability Economics Safety Interoperability Process standards Efficiency Performance Capacity

  5. These are constraints placed on various activities related to the development and delivery of the software product. For example: 1.The development organization must be CMM level 3 or above. 2. The system must use some specific tool. 3. There must be a disaster recovery plan for the system 4. There must be an agreed to product delivery plan Process Oriented Delivery/Updates Implementation Process standards Why do we have these requirements? Large organizations such as fortune 500 companies or government agencies are experienced with quality, maintenance, and delivery problems from past. These requirements are meant to minimize those problems.

  6. These are constraints which specify the desired “attributes” that the system must possess. Note: - Some can be specified quantitatively and precisely; others are difficult to quantify and are informally specified. - Sometimes these requirements may be mutually conflicting (e.g. reliability versus efficiency) Examples: 1.The system must process 100 transactions per minute 2. The system must not require 1 meg of main memory 3. The mean time between failure must be 3 months 4. The average user learning time must be less than 1 day 5. The system must be available 99.99% of time Product Related Usability Reliability Safety Efficiency Why do we have these requirements? Many organizations have critical needs; Aviation or Health Systems may have safety, reliability, and performance needs beyond the normal processing environment Performance Capacity

  7. These are constraints which may be placed on both the product and/or process. For example: 1.The system must abide to HIPAA (Health Insurance Portability and Accountability Act) privacy rules 2. The system must meet European Sales Tax laws 3. The system must use Automotive EDI for B2B e-commerce Externally Directed Legal rules Economics Interoperability Why do we have these requirements? Many countries have specific financial laws, privacy protection laws, etc. that the system must abide to. Some industries have their own business rules to conduct commerce.

  8. Difficulties in Specifying Non-functional Requirements • The difficulties in gathering Non-Functional Requirements may be attributed to many reasons - - - - - mostly because people tend to focus on the functions and services that they need: • Certain non-functional requirements are sometimes hard to quantify and therefore hard to express without some “trial and error prototyping”. • e.g. : usability • Certain non-functional requirements are hard to differentiatebetween functional and non-functional • e.g. security • Certain non-functional requirements are difficult to specify because they can not be well understood or validated until much later • e.g. reliability or quality • Certain non-functional requirements may be conflicting • e.g. performance .vs. security .vs. reliability • Certain non-functional requirements may be difficult to express and validate; may require more refinements • e.g. when to stop prototyping usability if the users do not clearly signal satisfaction similar

  9. Understanding the Goals and Objectives • Many have suggested that non-functional requirements be derived from understanding the: • Business Goals • Objectives that the system should meet to satisfy these Goals • Concerns about the system meeting the objectives This is not very easy for most technical people who have no business experience. Try an example of a Business Goal? Objective?, Concern?

  10. Class Discussion on Goal-Objective-Concern Suppose one of the business goals is to improve sales with an on-line order taking and inventory system. • Then what system objectives should we be thinking about - - - along with the customers? • Performance? • Reliability? • Security? • Usability? • What would be our concerns ? Which one is the top concern? • What if the business goal also said that sales improvement needs to happen within 18 months? - - - does that also place a requirement on development schedule (another non-functional requirement)

  11. “Critical” Systems • Critical systems are systems whose failure causes significant economic, human or organizational damage: • Business Critical System • e-commerce systems such as stock trading, reservations, etc. • Mission Critical System • Aircraft control, manufacturing process control, etc. • Safety (life) Critical system • Medical Device control, hazardous materials management, etc.

  12. Requirements for System Criticality • Most of the requirements for these “business,” “mission,” and “safety” criticality deals with non-functional requirements of the a) “complete” system, not just software and b) may be expressed in general ways that need to be decomposed further: • Performance • Reliability • Security • Usability • Safety Again, these may be “conflicting” - - - - so what do you do? Must prioritize the requirements, especially when there are conflicts

  13. PerformanceRelated Requirements • These requirements mostly addresses the constraints of speed and sometimes capacity: • System Response time to end-user such as 1 second response to user requests • System throughput such as # of transactions per minute (time interval) • System timing such as collection of data and responding to it within sub-second for real-time system. • System capacity such as number of simultaneous users that may access an application (instantaneous time) These should be specified quantitatively.

  14. Reliability Related Requirements • These requirements addresses constraints on run-time behavior of the system: • System Availability such as the system is up certain percentage of the time. • System Failure rate such as average mean time betweensystem failures to deliver the user service. These should also be specified quantitatively.

  15. Security Related Requirements • These requirements addresses the issues related to unauthorized access: to the system, to specific function, to data: • System Access protection such as firewall requirement • Application Functional Access &Usage protection such as authorization and authentication requirement • Data Access and Usage protection such as authorization and encryption requirement Security is also an important factor for other requirement such as safety. A little hard to specify these quantitatively.

  16. Usability Related Requirements • These requirements addresses the user interface looks and user inter-actionswith the system • Entry and beginners-level knowledge assumption to use the system • Learning time and experience needed such as hours or number of lessons to learn the system • Handling and usage such as time to complete certain tasks or number of errors made before completing certain tasks • Likeness and delight experienced from using the system such as availability of context sensitive help text or “re-do” capability Some of these requirements can be and should be specified Quantitatively; delight and likeness are a bit hard to define.

  17. Safety Critical System Requirements • These requirements addresses everything with the safety of the system and of the usage of the system. • These requirements deal mostly with the “shall not” requirements such as: • The system shall not allow - - - - • The system will not operate without - - - Note that safety may be dependent on many of the other requirements: - insecure system may be open to malicious danger - unreliable system may fail unpredictably and hurt someone - non-responsive system may miss critical data and damage something - difficult to use system may create a critical human error

  18. Requirements Engineering for Safety-Related System • Safety-related requirements engineering needs a “safety-analysis” Step: • Safety requirements discovery: • Hazard identification • Risk analysis • Safety Validation • Analysis of the discovered requirements to ensure that there is no conflict with other requirements

  19. 1. Safety Requirements Discovery • Identify potential hazard • This may be as simple as listing the hazards and placing “priorities” based on some damage value • One may use some form of a tree to help generate and classify the hazards. • The identified hazards may be viewed through some risk assessment and analysis to generate requirements in stages: • Avoidance requirements to ensure that the hazard will not occur in the first place • Prevention requirements to ensure that if the hazard occurs then it does not result in a damage • Protection requirements address the situation where if the accident does occur it only causes limited damage.

  20. 2. Requirements Conflict Resolution Reliability Performance Safety Related Requirements Usability Security . . . . . . . .

  21. Paper “cutting” system discussion (page 207 of text --- guillotine paper cutter) • What are the potential hazards? • What is the priority of these - - - in terms of ? 3. What would you consider as: • Avoidance requirements • Prevention requirements • Protection requirements

More Related