O Que São Requisitos?
Engenharia de requisitos e análise de sistemas Há sobreposição entre análise de sistemas e engenharia de requisitos. O descobridor de requisitos usa modelos de análise para auxilia-lo a encontrar os requisitos, e o analista de sistemas usa os requisitos como entrada no processo de desenho de funções e dados. No início do desenvolvimento, há muito mais engenharia de requisitos do que análise de sistemas. Esta proporção se inverte à medida em que o trabalho avança. A funcionalidade identificada na engenharia de requisitos é modelada para provar sua correção, isto é, para provar que as funções e os dados funcionarão corretamente, resultando no que o cliente espera. O produto da análise de sistemas serve como entrada para o projeto do produto, e daí para a sua construção e uso. Os requisitos evoluem a partir destas etapas, num processo impossível de prever com precisão. A engenharia de requisitos precisa levar em conta esta evolução. A técnica de análise de sistemas é bem documentada, o que não é verdade para a engenharia de requisitos.
Por que especificar requisitos?
Se não há uma especificação dos requisitos, um produto não pode ser construído. Ou, pelo menos, um produto não pode ser construído corretamente sem os requisitos corretos. Há relatos de que 60% dos erros já existem em tempo de projeto, e de que até 60% dos erros têm origem nas atividades de engenharia de requisitos e análise de sistemas. Embora os desenvolvedores tenham a oportunidade de quase eliminar a maior categoria de erros, escolhem (ou pior: seus gerentes escolhem) precipitar-se a construir o produto errado (para depois pagar muitas vezes em retrabalho o preço de uma boa análise). O que é um requisito? Um requisito é algo que um produto deve fazer, ou uma qualidade que deve ter. O primeiro caso é o de requisitos funcionais, por exemplo: "o produto deve acionar o monitor de segurança quando um cliente classe A faz um saque em horário não-comercial (no local do saque) superior à sua média mensal de retiradas". Neste caso, os clientes do produto são funcionários de um banco que precisam ser alertados sobre movimentações pouco usuais de alguns clientes do banco.
Engenharia de requisitos e análise de sistemas Há sobreposição entre análise de sistemas e engenharia de requisitos. O descobridor de requisitos usa modelos de análise para auxilia-lo a encontrar os requisitos, e o analista de sistemas usa os requisitos como entrada no processo de desenho de funções e dados. No início do desenvolvimento, há muito mais engenharia de requisitos do que análise de sistemas. Esta proporção se inverte à medida em que o trabalho avança. A funcionalidade identificada na engenharia de requisitos é modelada para provar sua correção, isto é, para provar que as funções e os dados funcionarão corretamente, resultando no que o cliente espera. O produto da análise de sistemas serve como entrada para o projeto do produto, e daí para a sua construção e uso. Os requisitos evoluem a partir destas etapas, num processo impossível de prever com precisão. A engenharia de requisitos precisa levar em conta esta evolução. A técnica de análise de sistemas é bem documentada, o que não é verdade para a engenharia de requisitos.
Por que especificar requisitos?
Se não há uma especificação dos requisitos, um produto não pode ser construído. Ou, pelo menos, um produto não pode ser construído corretamente sem os requisitos corretos. Há relatos de que 60% dos erros já existem em tempo de projeto, e de que até 60% dos erros têm origem nas atividades de engenharia de requisitos e análise de sistemas. Embora os desenvolvedores tenham a oportunidade de quase eliminar a maior categoria de erros, escolhem (ou pior: seus gerentes escolhem) precipitar-se a construir o produto errado (para depois pagar muitas vezes em retrabalho o preço de uma boa análise). O que é um requisito? Um requisito é algo que um produto deve fazer, ou uma qualidade que deve ter. O primeiro caso é o de requisitos funcionais, por exemplo: "o produto deve acionar o monitor de segurança quando um cliente classe A faz um saque em horário não-comercial (no local do saque) superior à sua média mensal de retiradas". Neste caso, os clientes do produto são funcionários de um banco que precisam ser alertados sobre movimentações pouco usuais de alguns clientes do banco.
No comments:
Post a Comment