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

9 bytes removidos ,  06h48min de 8 de fevereiro de 2010
m
corrigindo afluentes + ajustes, utilizando AWB
m (Bot: Adicionando: it:Requisito)
m (corrigindo afluentes + ajustes, utilizando AWB)
{{Traduçãoem tradução}}
No âmbito da [[engenharia]], um '''Requisito''' consiste da definição documentada de uma [[propriedade]] ou [[comportamento]] que um [[produto]] ou [[serviço]] particular deve atender.
 
Na abordagem clássica de engenharia, conjuntos de requisitos são tipicamente utilizados como informações fundamentais para a fase de [[projeto]] de um produto ou serviço, especificando as propriedades e [[funções]] necessárias (ou desejáveis) a serem consideradas no desenvolvimento do projeto em questão.
O conceito de requisito é também utilizado formalmente na [[ciência de computação]], [[engenharia de software]] e [[engenharia de sistemas]], referindo-se à definição de uma [[característica]], [[atributo]], [[habilidade]] ou [[qualidade]] que um sistema (ou qualquer um de seus [[módulo de um sistema|módulo]]s e [[subrotina]]s) deve necessariamente prover para ser útil a seus [[usuário]]s.
 
A fase de desenvolvimento de requisitos de um projecto de engenharia pode ser precedida por um [[estudo de viabilidade]], ou uma fase de análise conceptual do projecto. A fase de desenvolvimento de requisitos é normalmente devidida em [[levantamento de requisitos]] (recolha, compreensão, revisão e articulação das necessidades dos [[Stakeholder|stakeholdersstakeholder]]s),<ref>{{cite book | last=Stellman | first=Andrew | last2=Greene | first2=Jennifer | title=Applied Software Project Management | url=http://www.stellman-greene.com/aspm/ | page=98 | publisher=O'Reilly Media | year=2005 | isbn=978-0-596-00948-9 }}</ref>, [[análise de requisitos|análise]] (modelação, verificação de consistência e completude), especificação de requisitos (documentação e ou modelação dos requisitos) e validação de requisitos (garantir que os requisitos especificados estão correctos, de um ponto de vista interno e externo).<ref>Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003</ref>.
 
=== Requisitos do Produto versus Requisitos do Processo ===
Os Projectos estão sujeitos a três tipos de requisitos:
 
* '''Requisitos do Negócio''' descrevem em termos do negócio ''o que'' deve ser entregue ou conseguido para fornecer valor.
Os Projectos estão sujeitos a três tipos de requisitos:
* '''Requisitos do NegócioProduto''' descrevem empropriedades termosde doum negóciosistema ''oou produto (que'' devepoderá ser entregueuma oude conseguidovárias paramaneiras fornecerde valor.conseguir satisfazer um conjunto de requisitos de negócio.)
* '''Requisitos do Processo''' descrevem actividades efectuadas ou a efectuar pela organização de desenvolvimento. Por exemplo, requisitos de processo podem especificar as metodologias específicas que devem ser seguidas, e as restrições a que a organização deve obedecer.
* '''Requisitos do Produto''' descrevem propriedades de um sistema ou produto (que poderá ser uma de várias maneiras de conseguir satisfazer um conjunto de requisitos de negócio.)
* '''Requisitos do Processo''' descrevem actividades efectuadas ou a efectuar pela organização de desenvolvimento. Por exemplo, requisitos de processo podem especificar as metodologias específicas que devem ser seguidas, e as restrições a que a organização deve obedecer.
 
Requisitos de produto e de processo estão intimamente ligados. Os requisitos de processo especificam tipicamente as actividades que serão executadas para satisfazer um requisito de produto. Por exemplo, um requisito sobre a facilidade de manutenção futura de um produto (um requisito de produto) pode ser endereçado através da imposição de requisitos para que sejam seguidos determinados estilos de desenvolvimento, guias de estilo ou processos de revisão técnica formal (requisitos de processo).
 
<!--
===Requirements in systems and software engineering===
 
=== Requirements in systems and software engineering ===
In systems engineering, a '''requirement''' can be a description of ''what'' a system must do, referred to as a ''[[Functional requirements|Functional Requirement]]''. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called ''[[Non-functional requirements]]'', or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include usability, availability, reliability, supportability, testability, maintainability, and (if defined in a way that's verifiably measurable and unambiguous) ease-of-use.
 
In software engineering, the same meaning of requirements apply, except that the focus of interest is the software itself.
 
== Product Requirements ==
=== Types of product requirements ===
 
Requirements are typically placed into these categories:
 
 
=== Characteristics of good requirements ===
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.<ref>Boehm, B.W. and Papaccio, P.N., 1988, Understanding and controlling software costs, IEEE Trans of Software Engineering, 14(10), 1462-1477</ref><ref>Bridges, W., 1995, Managing Transitions, Making the most of change, Nicholas Brealey Publishing, UK.</ref><ref>[[Sjaak Brinkkemper]] 1996, Method engineering: engineering of information systems development methods and tools, Inf. Software Technol., 38(4), 275-280.</ref><ref>Davis, A.M., 1993, Software Requirements: Analysis and Specification, Prentice Hall, second Edition, 1993.</ref>.
 
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged<ref>Boehm, B.W. and Papaccio, P.N., 1988, Understanding and controlling software costs, IEEE Trans of Software Engineering, 14(10), 1462-1477</ref><ref>Bridges, W., 1995, Managing Transitions, Making the most of change, Nicholas Brealey Publishing, UK.</ref><ref>[[Sjaak Brinkkemper]] 1996, Method engineering: engineering of information systems development methods and tools, Inf. Software Technol., 38(4), 275-280.</ref><ref>Davis, A.M., 1993, Software Requirements: Analysis and Specification, Prentice Hall, second Edition, 1993.</ref>.
 
{| class="wikitable"
| The requirement is fully stated in one place with no missing information.
|-
| Consistent
| The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
|-
| The requirement meets all or part of a business need as authoritatively stated by stakeholders.
|-
| Current
| The requirement has not been made obsolete by the passage of time.
|-
Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent; however they may traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from [[Backdoor (computing)|backdoor]]s may be satisfied by replacing it with a process requirement to use [[pair programming]]. Other non-functional requirements will trace to other system components and be verified at that level. For example system reliability is often verified by analysis at the system level. [[Avionics software]] with its complicated safety requirements must follow the [[DO-178B]] development process.
 
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 ====
{{Ver artigoArtigo principal|[[Análise de requisitos]]}}
 
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.
{{Ver artigo principal|[[Análise de requisitos]]}}
 
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
 
# 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]].
Requirements generally change with time. Once defined and approved, requirements should fall under [[change control]]. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to [[requirements management]] studies and practices.
 
== Disputes regarding the necessity of rigour in software requirements ==
Some modern software engineering methodologies like [[extreme programming]] question the need for rigorously describing software requirements, which they consider a moving target. Instead, they describe requirements informally using [[user story|user stories]] (short summaries fitting on an index card explaining one aspect of what the system should do), and compose a series of [[acceptance test]] cases for this user story.
-->
 
{{Referências}}
== Ver também ==
 
== {{Ver também}} ==
* [[FURPS]] - acrónimo de categorias de requisitos chave
* [[Análise de requisitos]]
* [[Caso de Uso]]
 
== Referências{{Ligações externas}} ==
<references/>
 
== Ligações externas ==
{{Wiktionary}}
* [{{Link||2=http://www.sie.arizona.edu/sysengr/publishedPapers/requirements.pdf ''|3=Discovering System Requirements'']}}
* [{{Link||2=http://theiiba.org ''|3=The International Institute for Business Analysis and The IIBA's Business Analysis Body of Knowledge'']}}
 
[[Categoria:Engenharia]]
5 065

edições