| |
| Acadêmico(a): Luciano Marquardt |
| Título: Ferramenta Web para Gerenciamento de Requisitos de Software |
| |
| Introdução: |
Desenvolver produtos de software com qualidade nem sempre é uma tarefa simples. É altamente frustrante entregar um produto que não atenda às expectativas do cliente. Segundo Castro (1995), o nível de aceitação dos sistemas de informação comerciais é da ordem de 40%, enquanto que para sistemas de tempo real, este índice sobe para cerca de 75%. Este fato, em sua maioria, relaciona-se a erros e inadequações na produção do produto final, por falhas ocorridas durante as fases de análise e especificação de requisitos. Nota-se que nos sistemas de tempo real, devido a sua própria natureza, a análise e a especificação dos requisitos são feitas obrigatoriamente com mais cuidado e precisão, demandando mais tempo e atenção, o que justifica o alto índice de aceitação dos mesmos. Segundo Rocha (2001), uma má definição de requisitos nos estágios iniciais do processo de desenvolvimento pode resultar em altos custos de manutenção do sistema, pois diversas tarefas do ciclo de desenvolvimento de software deverão ser refeitas.
De acordo com Castro (1995), cerca de 40% do percentual de erros detectados nos sistemas devem-se as especificações mal feitas, notando-se também que aproximadamente 66% do total do custo de correção de erros refere-se a erros gerados na fase de especificação dos requisitos (Figura 1).
Figura 1 – Custo com a correção de erros nas fases de desenvolvimento de software
Para Alencar (1999), um processo de requisitos inadequado faz com que os usuários percam a confiança na equipe de desenvolvedores. Conforme Pressman (1995), uma compreensão completa dos requisitos de software é fundamental para um bem-sucedido desenvolvimento de software. Não importa quão bem projetado ou quão bem codificado seja, um programa mal analisado e especificado desapontará o usuário e poderá trazer problemas ao desenvolvedor. Conforme Macaulay (1996 apud Zanlorenci e Burnett 1998), requisitos simplesmente podem ser definidos como “algo que um cliente necessita”. Entretanto, do ponto de vista de um desenvolvedor, requisito pode também ser definido como “algo que necessita ser projetado”. Para Lopes (1999), requisitos de um sistema definem os serviços que o sistema deve oferecer e as restrições aplicáveis a sua operação. São em geral descritos de forma textual e sua especificação depende de diversos fatores, entre eles da pessoa que está escrevendo os requisitos, das pessoas para quem os requisitos estão sendo escritos, das práticas gerais da organização que está desenvolvendo os requisitos e do domínio da aplicação do sistema.
No final da década de oitenta, com a incumbência de definir processos formais para orientar o estudo da descoberta do problema e do levantamento dos requisitos do software a ser construído, surgiu a engenharia de requisitos. A engenharia de requisitos é o processo de identificação desses objetivos, determinando os usuários do produto a ser desenvolvido e suas necessidades e documentando essas informações de maneira adequada. A engenharia de requisitos é um processo multidisciplinar e centrado em pessoas (NUSEIBEH, 2000). Segundo Kotonya e Sommerville (1998 apud JOSÉ 2002), o processo de Engenharia de Requisitos é um conjunto estruturado de atividades que devem ser seguidas para que se consiga definir, validar e manter um documento de requisitos do sistema. Nas atividades previstas devem constar o levantamento de requisitos, a análise e negociação dos mesmos e a sua validação.
Segundo Sommerville (2003, p. 95), o produto do gerenciamento de requisitos é o documento de especificação de requisitos, que é a declaração oficial das funcionalidades e restrições do sistema a ser desenvolvido. Um formato bastante difundido para este documento foi proposto pelo Institute of Electrical and Electronic Engineers (IEEE) e American National Standards Institute (ANSI) e é conhecido como padrão IEEE/ANSI 830-1993 (SOMMERVILLE, 2000).
As ferramentas disponíveis no mercado que apóiam o gerenciamento de requisitos são completas, porém geralmente são de um custo mais elevado e normalmente agregadas a outros produtos. Assim, muitas vezes são financeiramente inviáveis. Nesse sentido, tenciona-se desenvolver uma ferramenta simplificada, mas funcional, com foco para uso acadêmico.
|
| |
|
