Requisito
Este artigo pode conter pesquisa inédita. |
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 projeto 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 dividida 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 corretos, de um ponto de vista interno e externo).[2]
Requisitos do Produto versus Requisitos do Processo
editarOs 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.
- 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).
Análise de Requisitos ou Engenharia de Requisitos
editar
Ver artigo principal: Análise de requisitosOs requisitos estão sujeitos a ambiguidade, incompletude e inconsistência. Técnicas como 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 forem descobertas em fases mais tardias 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
Características de bons requisitos
editarA depender dos autores, bons requisitos são definidos diferentemente, mas, de forma geral, há uma ênfase nos atributos mais apropriados às discussões ou ao domínio tecnológico específico sendo utilizado. Entretanto, as características a seguir são comumente desconhecidas.[3][4]
| Característica | Explicação |
|---|---|
| Unitário (coesivo) | O requisito diz respeito a um e apenas um fator. |
| Completo | O requisito é completamente inserido em um local sem informações faltando. |
| Consistente | O requisito não se contradiz com nenhum outro e é totalmente consistente com a documentação externa como um todo. |
| Indivisível (atômico) | O requisito é atômico; isto é, ele não contém conjunções. Por exemplo, "O campo de código postal deve validar códigos postais americanos e canadenses" deveria ser escrito como: (1) "O campo de código postal deve validar códigos postais americanos" e (2) "O campo de código postal deve validar códigos postais canadenses". |
| Rastreável | O requisito abrange completa ou parcialmente as necessidades de um negócio estabelecidas pelos stakeholders e pela documentação. |
| Atual | O requisito não deve se tornar obsoleto com o passar do tempo. |
Vale ressaltar que há ainda outras características concernentes a um bom requisito, e que é importante avaliar cada caso para definir por quais delas é mais importante primar. Por exemplo, para os requisitos de atualização de um sistema de informação que já tem muitos anos, a atualidade dos requisitos pode ser mais relevante que a coesão deles.
Ver também
editar- 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. Consultado em 11 de novembro de 2009. Arquivado do original em 9 de fevereiro de 2015
- ↑ Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003
- ↑ Davis, Alan Mark; Davis, Alan M. (1993). Software requirements: objects, functions, and states Revision, 4. [Dr.] ed. Englewood Cliffs, NJ: PTR Prentice Hall
- ↑ Institute of Electrical and Electronics Engineers (1998). IEEE recommended practice for software requirements specifications: approved 25 June 1998, IEEE-SA Standards Board. New York, NY: IEEE
