Requisito: diferenças entre revisões
Conteúdo apagado Conteúdo adicionado
Sem''' ''' |
|||
| Linha 3: | Linha 3: | ||
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. |
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]] |
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 (corporate)|stakeholders]])<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>. |
|||
<!-- |
|||
===Product versus process requirements=== |
|||
Projects are subject to three sorts of requirements: |
|||
* '''Business requirements''' describe in business terms ''what'' must be delivered or accomplished to provide value. |
|||
* '''Product requirements''' describe properties of a system or product (which could be one of several ways to accomplish a set business requirements.) |
|||
* '''Process requirements''' describe activities performed by the developing organization. For instance, processes requirements could specify specific methodologies to be followed, and constraints that the organization must obey. |
|||
Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement for the product to be maintainable (a Product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., [[object-oriented programming]]), style-guides, or a review/inspection process (process requirements). |
|||
===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. |
|||
A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements generally avoids saying ''how'' the system should implement the requirements, leaving such decisions to the system designer. Describing how the system should be implemented may be known as [[implementation bias]] or "solution engineering". However, ''implementation constraints'' (aka solution requirements) on the solution may be validly expressed by the future owner, for example for communality reasons with other owned products. |
|||
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: |
|||
* [[Functional requirements]] describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. |
|||
* [[Non-functional requirements]] are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as quality requirements or ilities. |
|||
* [[Constraint requirements]] are the ones that act to constrain the solution. No matter how the problem is solved the constraint requirements must be adhered to. |
|||
Non-functional requirements can be further classified according to whether they are usability requirements, look and feel requirements, humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements, or one of many other types of requirements. |
|||
In [[software engineering]] this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system. For example, in a computer system reliability is related to hardware failure rates, performance controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software. For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. See [[FURPS]]. In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable. For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code. |
|||
=== 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>. |
|||
{| class="wikitable" |
|||
|- |
|||
! Characteristic |
|||
! Explanation |
|||
|- |
|||
| Cohesive |
|||
| The requirement addresses one and only one thing. |
|||
|- |
|||
| Complete |
|||
| 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. |
|||
|- |
|||
| Correct |
|||
| 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. |
|||
|- |
|||
| Externally Observable |
|||
| The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. |
|||
|- |
|||
| Feasible |
|||
| The requirement can be implemented within the constraints of the project. |
|||
|- |
|||
| Unambiguous |
|||
| The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited. |
|||
|- |
|||
| Mandatory |
|||
| The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. |
|||
|- |
|||
| Verifiable |
|||
| The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test. The expected methods are usually test or demonstration. The inspection or analysis are done just in special cases. |
|||
|} |
|||
==== Verification ==== |
|||
All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration or inspection or review of design). |
|||
Certain requirements, by their very structure, are not verifiable. These include requirements that say the system shall ''never'' or ''always'' exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable. |
|||
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. |
|||
==== 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. |
|||
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they |
|||
#take a long time to produce |
|||
#limit the implementation options available |
|||
#are costly to produce |
|||
=== 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]]. |
|||
=== Changes in requirements === |
|||
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. |
|||
--> |
|||
== Ver também == |
|||
* [[FURPS]] - acrónimo de categorias de requisitos chave |
|||
* [[Análise de requisitos]] |
|||
* [[Gestão de requisitos]] |
|||
* [[Rastreio de requisitos]] |
|||
* [[Caso de Uso]] |
|||
== Referências == |
|||
<references/> |
|||
== Ligações externas == |
|||
{{Wiktionary}} |
|||
* [http://www.sie.arizona.edu/sysengr/publishedPapers/requirements.pdf ''Discovering System Requirements''] |
|||
* [http://theiiba.org ''The International Institute for Business Analysis and The IIBA's Business Analysis Body of Knowledge''] |
|||
[[Categoria:Engenharia]] |
[[Categoria:Engenharia]] |
||
[[en:Requirement]] |
|||
[[de:Anforderung (Informatik)]] |
|||
[[es:Requerimiento (sistemas)]] |
|||
[[fr:Exigence (ingénierie)]] |
|||
[[nl:Requirement]] |
|||
[[ja:要求仕様]] |
|||
[[pl:Wymaganie w inżynierii]] |
|||
[[vi:Yêu cầu (kỹ thuật)]] |
|||
Revisão das 11h37min de 11 de novembro de 2009
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ódulos e subrotinas) deve necessariamente prover para ser útil a seus usuários.
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 stakeholders)[1], 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)[2].
Ver também
- FURPS - acrónimo de categorias de requisitos chave
- Análise de requisitos
- Gestão de requisitos
- Rastreio de requisitos
- Caso de Uso
Referências
- ↑ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. [S.l.]: O'Reilly Media. p. 98. ISBN 978-0-596-00948-9
- ↑ Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003
