| |
| Acadêmico(a): Odair José |
| Título: Ferramenta de Apoio a Documentação de Requisitos de Software |
| |
| Introdução: |
| Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa trivial. São vários os fatores que dificultam atingir os objetivos de qualidade. No entanto, nada é mais decepcionante do que produzir software que não satisfaça as necessidades dos clientes. Grandes volumes de recursos são gastos, mas em muitos casos ocorre uma grande frustração por parte dos clientes diante da forma final apresentada pelo software encomendado. Segundo Rocha (2001, p. 238) muitos desses problemas são derivados da falta de atenção para a tarefa de definir e acompanhar a evolução dos requisitos durante o processo de construção de software. Conforme Pressman (1995, p. 231) 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 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, p. 3) requisitos de um sistema definem os serviços que o sistema deve oferecer e as restrições aplicáveis à sua operação. Podem ser classificados em dois grandes grupos: requisitos funcionais e requisitos não funcionais. 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. Além de incluir declarações da funcionalidade esperada do sistema, os requisitos incluem informações adicionais, na forma de serviços e restrições. Em geral, os requisitos incluem informações genéricas do domínio, do tipo de sistema que está sendo especificado, normas que devam ser respeitadas, informações sobre outros sistemas com os quais o sistema deva interagir, entre outras. 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. O sucesso de um projeto de software é determinado pelo grau com que ele atinge os objetivos que motivaram a sua construção. 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, p. 71). Conforme Rocha (2001, p. 243) engenharia de requisitos, uma sub-área da engenharia de software, tem por objetivo tratar o processo de definição dos requisitos de software. Para isso, estabelece um processo no qual o que deve ser feito é extraído, modelado e analisado. Esse processo deve lidar com diferentes pontos de vista e usar uma combinação de métodos, ferramentas e pessoal. O produto desse processo é um modelo: o documento ‘requisitos’. A tarefa de análise de requisitos é um processo de descoberta, refinamento, modelagem e especificação. 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 no processo devem constar levantamento de requisitos e sua validação. O processo deve ainda oferecer diretrizes sobre programação das atividades, definição de responsabilidades, entradas, saídas de cada uma das atividades, entre outras. Muitos autores descrevem diferentes atividades para o cumprimento da fase inicial do ciclo de vida, conhecida como análise de requisitos. Segundo Cordeiro (2000), as atividades a serem desenvolvidas são as seguintes: a) extração de requisitos – etapa onde os requisitos são descobertos através de consultas aos envolvidos, documentos, domínio do conhecimento e estudos de mercado; b) análise e negociação – os requisitos são analisados em detalhe e recusados ou aceitos; c) documentação – onde os requisitos aceitos são documentados em um nível apropriado de detalhe; d) validação – os requisitos são checados cuidadosamente para verificação de consistência e completeza; e) gerenciamento – onde os requisitos são controlados em função da dinâmica das mudanças ambientais. Conforme Lopes (1999) um dos resultados do processo de requisitos é o documento de requisitos que é uma declaração oficial dos requisitos do sistema, destinada a usuários, clientes e desenvolvedores. Dependendo da organização, esse documento pode ser denominado: especificação funcional, ou definição de requisitos, ou especificação de requisitos de software. O documento de requisitos é o produto formal das atividades de engenharia de requisitos. Nele devem estar especificados: a) os serviços e funções do sistema; b) as restrições que devem ser observadas; c) as propriedades emergentes do sistema e suas restrições (requisitos não funcionais); d) informações sobre o domínio da aplicação; e) restrições no processo a ser utilizado no desenvolvimento do sistema. Existem várias formas para estruturar o documento de requisitos e alguns organismos reguladores propuseram normas para a produção do documento (DoD – Department of Defense / IEEE / ANSI). In Lopes (1999) esta descrita a norma IEEE/ANSI (Padrão Nro. 830-1993) que propõe que o documento seja estruturado da seguinte forma: a) introdução: propósito do documento, escopo do produto, definições, referências e resumo geral do resto do documento; b) descrição Geral: perspectiva do produto, funções, características do usuário, restrições de ordem geral, opções de projeto e dependências; c) requisitos específicos: devem ser especificados requisitos funcionais e não funcionais do sistema; d) apêndices; e) índice. Para dar apoio à engenharia de requisitos existem algumas ferramentas no mercado, mas que não são tão comuns, entre elas está o Requisite Pro da empresa Rational (Rational, 2002), cuja proposta abrange todas as fases dos processos da Engenharia de Requisitos: descobrimento, análise, validação, documentação e gestão de requisitos. A ferramenta Requisite Pro permite a visualização da informação nas fases de projeto: demanda inicial, estudo preliminar, projeto lógico, projeto físico e construção, integradas por versão. No Requisite Pro é definido e criado um projeto onde existe uma hierarquia de documentação e padronizações para definir os diferentes níveis de requisitos de um produto. A arquitetura do Requisite Pro é composta de documentos, atributos de requisitos, repositórios de requisitos e rastreabilidade. Os atributos de requisitos e ligações de rastreabilidade no Requisite Pro são usados para auxiliar a gerência do escopo e mudanças por todo o ciclo de vida do produto. Com base nessas informações desenvolveu-se uma ferramenta que permite auxiliar o processo de obtenção e documentação dos requisitos de software. Através de vários modelos de documentação de requisitos (descritos neste trabalho) a ferramenta desenvolvida auxilia o engenheiro de software na extração, armazenamento e documentação dos requisitos. A ferramenta utiliza questionários com perguntas textuais e check_list’s (perguntas com respostas prontas onde a pessoa assinala as opções desejadas) para identificar os requisitos e vários fatores que tem influência sobre eles. A ferramenta permite a geração do documento básico dos requisitos em vários formatos, bem como dos membros do projeto que geraram os requisitos e dos dados gerais do projeto de requisitos. |
| |
|
