vault backup: 2023-09-20 10:21:49
This commit is contained in:
parent
b0e59ea280
commit
045d0f04b6
1 changed files with 6 additions and 4 deletions
|
@ -71,13 +71,15 @@
|
||||||
>[!help]+ Ex. 3.4 (Naveda and Seidman, 2006, pp. 57–58)
|
>[!help]+ Ex. 3.4 (Naveda and Seidman, 2006, pp. 57–58)
|
||||||
>Which of the following arguments is the most solid/strong to justify the specification of the non-functional requirements of a system?
|
>Which of the following arguments is the most solid/strong to justify the specification of the non-functional requirements of a system?
|
||||||
>
|
>
|
||||||
>1. acceptance/validation procedures
|
>1. The non-functional requirements should only be considered in development contexts subject to tight restrictions (resources, budget, or deadlines).
|
||||||
>2. delivery plans
|
>2. The non-functional requirements are only external characteristics of the system and can be obtained later.
|
||||||
>3. quality attributes
|
>3. If a functionality is present in the system, the non-functional requirements determine how usable and useful it is.
|
||||||
>4. activities to guarantee the quality
|
>4. The non-functional requirements take less time to specify than the functional requirements.
|
||||||
>
|
>
|
||||||
>>[!hint]- Resolução
|
>>[!hint]- Resolução
|
||||||
|
>>Option 3. is the best justification..
|
||||||
>>
|
>>
|
||||||
|
>>Non-functional requirements appear to be an enumeration of restrictions to the functional requirements being defined by a developing system. Non-functional requirements are the buffer of quality of the product - these cannot be defined later. Their determination may take even more time
|
||||||
>>
|
>>
|
||||||
>>
|
>>
|
||||||
>>
|
>>
|
||||||
|
|
Loading…
Reference in a new issue