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/06/08 22:10] char |
dido:public:ra:1.4_req:2_nonfunc [2022/05/08 15:04] (current) nick |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|Non-functional]] [[dido:public:ra:xapend:xapend.a_glossary:r:requirement|requirements]] | + | [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|Non-functional 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 11: | 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]] | ||
| )). | )). | ||
| Line 36: | 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.1623204613.txt.gz · Last modified: 2021/06/08 22:10 by char
