dido:public:ra:1.4_req:2_nonfunc
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc [2021/03/25 10:46] murphy |
dido:public:ra:1.4_req:2_nonfunc [2022/05/08 15:04] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== 4.3 Non-Functional Requirements ====== | ====== 4.3 Non-Functional Requirements ====== | ||
| + | |||
| [[dido:public:ra:1.4_req | Return to Requirements]] | [[dido:public:ra:1.4_req | Return to Requirements]] | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|Non-functional requirements]] |
| - | + | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|Non-functional]] [[dido:public:ra:xapend:xapend.a_glossary:r:requirement|requirements]] | + | |
| are often incorrectly assumed rather than being explicitly defined by users. This can lead to problems towards the end of a project as the user expectations for non-functional requirements are not met. Many times, the developers dismiss non-functional requirements as non-testable and therefore not enforceable. | are often incorrectly assumed rather than being explicitly defined by users. This can lead to problems towards the end of a project as the user expectations for non-functional requirements are not met. Many times, the developers dismiss non-functional requirements as non-testable and therefore not enforceable. | ||
| Line 12: | Line 11: | ||
| Users expect new features to be added to a system and tested before they use them. Users assume the software is maintainable without an explicit declaration for “[[dido:public:ra:xapend:xapend.a_glossary:m:maintainability|maintainability]]”. In many ways, they expect it to be an unwritten requirement and or [[dido:public:ra:xapend:xapend.a_glossary:g:goal|goal]]. In other words, users expect the system to be analyzable, changeable, stable and testable(( | Users expect new features to be added to a system and tested before they use them. Users assume the software is maintainable without an explicit declaration for “[[dido:public:ra:xapend:xapend.a_glossary:m:maintainability|maintainability]]”. In many ways, they expect it to be an unwritten requirement and or [[dido:public:ra:xapend:xapend.a_glossary:g:goal|goal]]. In other words, users expect the system to be analyzable, changeable, stable and testable(( | ||
| Prolifics Testiing, __Achieving Requirements Testability__, 10 October 2018, Accessed 10 November 2020, [[https://www.prolifics-testing.com/news/achieving-requirements-testability]] | Prolifics Testiing, __Achieving Requirements Testability__, 10 October 2018, Accessed 10 November 2020, [[https://www.prolifics-testing.com/news/achieving-requirements-testability]] | ||
| - | )). For example, smartphone users will switch apps to other apps if the energy consumed by the app is not efficient. Efficiency is therefore a non-functional requirement. Energy consumption may also be a functional requirements (i.e., An application can not use more than 1040 mW (milli-Watt) per SMS message. (( | + | )). For example, smartphone users will switch apps to other apps if the energy consumed by the app is not efficient. Efficiency is therefore a non-functional requirement. Energy consumption may also be a [[dido:public:ra:xapend:xapend.a_glossary:f:funcreq|functional requirements]] (i.e., An [[dido:public:ra:xapend:xapend.a_glossary:a:application|application]] can not use more than 1040 mW (milli-Watt) per [[dido:public:ra:xapend:xapend.a_glossary:s:sms]] message. (( |
| Sai Suren Kumar Kasireddy and Vishnuvardhan Reddy Bojja, __Measurements of EnergyConsumption in MobileApplications with respect toQuality of Experience__, School of Computing, Blekinge Institute of Technology, 37179 Karlskrona, Sweden, March 2012, Acessed on 10 November 2020, [[https://www.diva-portal.org/smash/get/diva2:829733/FULLTEXT01.pdf]] | Sai Suren Kumar Kasireddy and Vishnuvardhan Reddy Bojja, __Measurements of EnergyConsumption in MobileApplications with respect toQuality of Experience__, School of Computing, Blekinge Institute of Technology, 37179 Karlskrona, Sweden, March 2012, Acessed on 10 November 2020, [[https://www.diva-portal.org/smash/get/diva2:829733/FULLTEXT01.pdf]] | ||
| )). | )). | ||
| + | The DIDO RA assumes the following non-functional requirements: | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:10_portability]] | * [[dido:public:ra:1.4_req:2_nonfunc:10_portability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:10_portability:01_adapt]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:10_portability:04_install]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability]] | * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:04_faulttolerance]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:12_recoverability]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability]] | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:analysability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:25_security]] | * [[dido:public:ra:1.4_req:2_nonfunc:25_security]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:25_security:confidentiality]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:25_security:04_data_integrity]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:25_security:authenticity]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:25_security:accountability]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]] | * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:02_types]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:04_costs]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:08_software]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:30_usability]] | * [[dido:public:ra:1.4_req:2_nonfunc:30_usability]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:30_usability:effectiveness]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:30_usability:efficiency]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:30_usability:satisfaction]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:40_performance]] | * [[dido:public:ra:1.4_req:2_nonfunc:40_performance]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:40_performance:01_platform]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:40_performance:02_application]] | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:40_performance:04_nework]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:05_interoperability]] | * [[dido:public:ra:1.4_req:2_nonfunc:05_interoperability]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:08_elasticity]] | * [[dido:public:ra:1.4_req:2_nonfunc:08_elasticity]] | ||
| * [[dido:public:ra:1.4_req:2_nonfunc:16_scalability]] | * [[dido:public:ra:1.4_req:2_nonfunc:16_scalability]] | ||
| - | |||
| ===== Creating a Trade Study ===== | ===== Creating a Trade Study ===== | ||
| Line 64: | Line 36: | ||
| Often a trade study is based on a collection of [[dido:public:ra:xapend:xapend.a_glossary:f:fom | Figure of Merits ]] with each FoM representing a single evaluation score for a single function. In the examples above, the camera resolution, or the high frequency response. An entire camera may have a FoM, but it represents the cumulative FoM of each function. A Camera may have other FoMs such as weight, battery life, size, or exchangeable lenses. | Often a trade study is based on a collection of [[dido:public:ra:xapend:xapend.a_glossary:f:fom | Figure of Merits ]] with each FoM representing a single evaluation score for a single function. In the examples above, the camera resolution, or the high frequency response. An entire camera may have a FoM, but it represents the cumulative FoM of each function. A Camera may have other FoMs such as weight, battery life, size, or exchangeable lenses. | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:HowTo | How to Use the Boiler Plate]] | + | * [[dido:public:ra:1.4_req:3_assessment:2_nonfunctional:howto| How to Use the Boiler Plate]] |
dido/public/ra/1.4_req/2_nonfunc.1616683565.txt.gz · Last modified: 2021/03/25 10:46 by murphy
