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/16 14:00] murphy [The Stakeholder's Focus Group] |
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]] | ||
| - | |||
| - | ===== Assessing the Alternatives ===== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | ||
| - | |||
| - | Non-Functional requirements are by nature, hard to measure and hard to assess for compliance. The complexity of the assessment problem is compounded because products or systems as well as the environment they operate within are not static. Therefore, an assessment that is done today, may no longer be accurate in the future. When assessing [[dido:public:ra:xapend:xapend.a_glossary:c:cots]], [[dido:public:ra:xapend:xapend.a_glossary:g:gots]], [[dido:public:ra:xapend:xapend.a_glossary:m:mots]] or [[dido:public:ra:xapend:xapend.a_glossary:n:nots]] or the inclusion of [[dido:public:ra:xapend:xapend.a_glossary:o:oss]] the potential for changes (particularly enhancements) needs to be assed also. | ||
| - | |||
| - | One way to accomplish this is to provided an assessment which is weighted for the "ease of implementation" for new features. For example, a system or product may not have done much to support [[dido:public:ra:1.4_req:2_nonfunc:25_security:confidentiality]], but the vendor of the product might determine that it is an easy upgrade to add it to the product. On the other hand, the support for **Confidentiality** might be extremely difficult. Sometimes, the feature may be easy to solve but requires time and money to accomplish. As a potential stakeholder, they can direct resources to help overcome this shortfall. | ||
| - | |||
| - | |||
| - | <figure AssessOverview> | ||
| - | {{ :dido:public:ra:1.4_req:screen_shot_2021-03-12_at_3.42.04_pm.png?700 |}} | ||
| - | <caption>An overview of the Assessment Process</caption> | ||
| - | </figure> | ||
| - | |||
| - | |||
| - | ==== The Vendor's Assessment ==== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | ||
| - | |||
| - | The Vendor's assessment team will discuss with each other and use the DIDO-RA workbook to determine the weight of the requirement. | ||
| - | <figure > | ||
| - | {{ :dido:public:ra:1.4_req:screen_shot_2021-03-12_at_3.57.17_pm.png?600 |}} | ||
| - | <caption>The Vendor's Assessment Team Activities</caption> | ||
| - | </figure> | ||
| - | |||
| - | This is done by weighing each property, related to the Requirement, by giving a score between 1-100. 1 representing an easy development process, and 100 being impossible now, merely very difficult in a couple years. | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_143502.png?900 |}} | ||
| - | </figure> | ||
| - | <figure> | ||
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_144655.png?500 |}} | ||
| - | </figure> | ||
| - | |||
| - | Publish the assessment, and notify the vendor.. | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | ==== The Stakeholder's Focus Group ==== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | ||
| - | |||
| - | The Vendor's stakeholder assessment team now can create a focus group of stakeholder's. This group is used in conjunction with the stakeholder assessment team to determine the importance of the Requirement. | ||
| - | |||
| - | <figure > | ||
| - | {{ :dido:public:ra:1.4_req:screen_shot_2021-03-12_at_4.41.49_pm.png?600 |}} | ||
| - | <caption>The Stakeholder's Focus Group Activities</caption> | ||
| - | </figure> | ||
| - | |||
| - | This is done by rating each property related to the requirement with either a '+' option representing a 'more important' status, or a '-' option representing a 'less important' status. On the Coefficient sheet choosing a '+' will cause a '-' to be put in the opposite cell in the table. EX: cell(1,2)='+' means cell(2,1)='-'. Also properties can't be compared to themselves, these cells have lines drawn through them to represent this. | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_143441.png?1000 |}} | ||
| - | </figure> | ||
| - | |||
| - | At the end of filling out each table. Each row is counted for '+', the number of '+' in a row is equal to the coefficient for that property. | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_143419.png?800 |}} | ||
| - | </figure> | ||
| - | |||
| - | When completed publish the assessment and notify the stakeholder's. | ||
| - | ==== The Stakeholder's Assessment Team ==== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | ||
| - | |||
| - | Once the assessments and importance coefficients are set, the DIDO-RA is passed to the stakeholder's assessments team. Here they will take the factor weighting and the coefficients to create the Figures of Merit(FOM). These figures are then published to assessment reports that are given to the Vendor, and/or given back to the stakeholder's assessment team for further review. | ||
| - | |||
| - | <figure > | ||
| - | {{ :dido:public:ra:1.4_req:screen_shot_2021-03-12_at_4.46.33_pm.png?600 |}} | ||
| - | <caption>The Stakeholder's Assessment Team Activities</caption> | ||
| - | </figure> | ||
| - | |||
| - | |||
| - | ==== The Stakeholder's Award Team ==== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc | Return to Top]] | ||
| - | |||
| - | The stakeholder's receive the Assessment Reports as well, if they deem the results satisfactory they will choose the product just reviewed. | ||
| - | |||
| - | |||
| - | <figure > | ||
| - | {{ :dido:public:ra:1.4_req:screen_shot_2021-03-12_at_4.47.40_pm.png?600 |}} | ||
| - | <caption>The Stakeholder's Award team Activities</caption> | ||
| - | </figure> | ||
| - | |||
| ===== Creating a Trade Study ===== | ===== Creating a Trade Study ===== | ||
| Line 147: | 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:3_assessment:2_nonfunctional:howto| How to Use the Boiler Plate]] | |
| - | + | ||
| - | + | ||
| - | Now that each Coefficient/Factor Weighting sheet is filled out, they are then sent to the corresponding sheets containing the evaluation of the specific Requirement. | + | |
| - | + | ||
| - | <figure> | + | |
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_145741.png?600 |}} | + | |
| - | </figure> | + | |
| - | + | ||
| - | This data is then used to create the FOM(Figures of Merit). The formula to calculate the FOM = (C1)(FW1) + (C2)(FW2)+ (Cn)(FWn) for each property. These Property FOMs are then added into a Requirement FOM. | + | |
| - | <figure> | + | |
| - | {{ :dido:public:ra:1.4_req:screenshot_2021-03-05_152036.png?900 |}} | + | |
| - | </figure> | + | |
| - | + | ||
| - | <color #FF0000>NOTE: Comparing Requirement FOMs from one vendor to another will cause a skewed comparison. To compare between vendors you must break the Requirement FOMs into its components. The components of Requirement FOM are the Property FOMs.</color> | + | |
| - | + | ||
| - | + | ||
| - | * [[dido:public:ra:1.4_req:2_nonfunc:HowTo | How to Use the Boiler Plate]] | + | |
dido/public/ra/1.4_req/2_nonfunc.1615917615.txt.gz · Last modified: 2021/03/16 14:00 by murphy
