Diferenças entre edições de "Requisito"

151 bytes adicionados ,  12h05min de 13 de novembro de 2009
sem resumo de edição
 
Verifiability is necessary for a requirement but there are other important issues. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized.
-->
 
==== Análise de Requisitos ou Engenharia de Requisitos ====
==== Requirements analysis or Requirements engineering====
{{seemain|Requirements analysis}}
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous [[software inspection|inspection]] have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues.
 
{{seemain|Análise de requisitos}}
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they
Os '''requisitos''' estão sujeitos a ambiguidade, incompletude e inconsistência. Técnicas como [[Inspecção de software|inspecções]] rigorosas têm sido usadas para ajudar a lidar com questões de ambiguidade. Questões de ambiguidade, incompletude e inconsistência que sejam resolvidas durante a fase de engenharia de requisitos custam tipicamente várias ordens de magnitude menos para corrigir do que se foram descobertas em fases mais tardias do desenvolvimento do produto. A [[análise de requisitos]] esforça-se pode endereçar estes assuntos.
 
Tem que haver um compromisso em engenharia, no sentido em que os atributos não devem ser demasiado vagos, mas também não devem ser tão detalhados que
#take a long time to produce
#limit the implementation options available
#are costly to produce
 
#demorem demasiado tempo a produzir
#limitem as opções possíveis de implementação
#a sua produção fica demasiado cara.
 
>!--
=== Documenting requirements ===
Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system shall do. Example: 'The contractor shall deliver the product no later than xyz date.' Other ways include [[use cases]] and [[user stories]].
221

edições