2. Types of Software Requirements
•Functional Requirements
•Non- Functional Requirements
•Domain Requirements
•Inverse Requirements
•Design and Implementation Constraints
3. Non Functional Requirements
•NFRs are very important to capture the emergent behavior of the system in
Three Dimensions:
1. Product
• Usability, reliability, portability, efficiency (performance, space)
2. Organizational
• Standards, implementation, delivery
3. External
• Interoperability, ethical, legislative (privacy, safety)
4. Categories
Based on the dimensions under consideration NFR’s can be divided into Three
main categories; stated as follows:
•Performance Requirements
• reflecting: usability, efficiency, reliability, maintainability and reusability (note: also
security requirements)
•Design Constraints
• Platform (minimal requirements, OS, devices…)
• Technology to be used (language, DB, …)
•Commercial Constraints
• Development process (methodology) to be used
• Cost and delivery date
5. •Non-functional requirements are important
•If they are not met, the system is useless
•They are sometimes called quality requirements, quality of service, or extra-
functional requirements
•Non-functional requirements may be very difficult to state precisely (especially
at the beginning) and imprecise requirements may be difficult to verify
6. NFRs as Goals
•Goal: Conveys the intention or the objective of one or many stakeholders
•Non-functional requirements are sometimes written as general goals, which are
difficult to verify
•They should be expressed quantitatively using metrics (measures) that can be
objectively tested
•General goals must be converted into more precise and measurable NFRs
7. Example: Goal to NFR
Goal (unverifiable)
◦ The system should be easy to use by experienced controllers and should be
organized in such a way that user errors are minimized
Non-functional requirement (verifiable)
◦ Experienced controllers shall be able to use all the system functions after a
total of two hours’ training. After this training, the average number of errors
made by experienced users shall not exceed two per day
Assumption: An experienced controller has at least 2 years experience with the
old system (as stated by the stakeholder)
9. Metrics for NFRs
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
10. Metrics for NFRs
•With the help of these measures the NFRs can be verified quantitatively
•It should also be noted that the cost of quantitatively verifying each NFR may be
very high
