Rumo ao gerenciamento de requisitos: uma experiência da Celepar

Autores:
Cristina Ângela Filipak Machado -GPT
Dante Carlos Antunes - GPT


Artigo que resume a experiência atual da CELEPAR na busca da área-chave Gerência de Requisitos do modelo CMM / Nível 2. O fato marcante que caracteriza o início desta empreitada é a publicação do GREQ - Guia de Especificação de Requisitos, que a partir deste ano passou a compor a MDS da nossa empresa.

Resumo

Este artigo descreve a experiência em andamento na CELEPAR que visa incorporar ao seu processo de desenvolvimento de sistemas um guia de especificação de requisitos que é fundamental na implantação da prática de gerência de requisitos, uma das áreas chaves do CMM nível 2.

1 Introdução

A CELEPAR - Companhia de Informática do Paraná é a empresa responsável pela gestão da informática do Governo do Estado do Paraná e tem como uma das principais linhas de produto o desenvolvimento e a gestão de sistemas de informações. Recentemente, a empresa estabeleceu como diretriz atingir o nível 2 do CMM [2]. Para ter sucesso nesta empreitada, necessariamente deverá internalizar a prática de gerenciamento de requisitos, entre outras área chaves do CMM. O gerenciamento de requisitos, por sua vez, precisa de um guia de especificação de requisitos. Em um primeiro momento o guia de especificação que está sendo proposto é informal, pois ainda estamos em uma fase de formação de cultura. Entretanto, foi estabelecido como regra que os requisitos devem ser organizados conforme a estrutura de características e subcaracterísticas de qualidade de software definidas em normas que tratam do assunto.

Este artigo descreve o guia estabelecido pela CELEPAR para a Especificação de Requisitos e os resultados alcançados. Para tanto, o artigo está dividido nas seguintes seções: a seção 2, descreve o guia de Especificação de Requisitos da CELEPAR e a seção 3, descreve uma conclusão das experiências em se utilizar o guia e as expectativas de evolução.

2 Especificação de Requisitos

A experiência de muitos anos da CELEPAR mostra que as "crises" que ocorrem durante o desenvolvimento dos projetos, se caracterizam por razões, tais como: não cumprimento de prazos, entrega de produtos que não satisfazia o cliente, comprometimento de recursos além do estimado, etc. Através da análise destas "reclamações", muitas vezes, notamos que o produto final entregue ao cliente e o produto encomendado são muito diferentes. É normal que mudanças ocorram ao longo do processo de desenvolvimento. O problema está em não registrar tais mudanças e, mais grave ainda, em não tratar adequadamente o impacto que tais mudanças provocam, que, regra geral, traduzem-se em agregar recursos adicionais ao projeto ou ampliar o seu prazo de conclusão. Fica patente, então, a necessidade de gerenciar as modificações de requisitos. É uma conclusão óbvia. Entretanto, as dificuldades práticas para adotar uma conduta de gerenciamento de requisitos são inúmeras. O primeiro desafio é internalizar um guia de especificação de requisitos adequado ao estágio organizacional da empresa e que seja efetivo.

No caso da CELEPAR, ficou definido que um guia de Especificação de Requisitos deveria apresentar, no mínimo, as seguintes características: conduzir à elaboração de um documento que seja a base do relacionamento cliente/fornecedor; agregar em um único documento todos os aspectos que o software deverá atender; ser independente de tecnologia; ser de fácil entendimento tanto pelo técnico de informática como pelo cliente; apresentar estrutura que facilite o gerenciamento de requisitos durante todo o ciclo de desenvolvimento do produto; estar em conformidade com normas internacionais que tratam do assunto; e ser facilmente integrável com os outros componentes da MDS-CELEPAR - Metodologia de Desenvolvimento de Sistemas da CELEPAR [1].

Para a definição do escopo do guia foram utilizados conceitos oriundos da descrição da área-chave do CMM-nível 2: Gerenciamento de Requisitos [2] e da Norma ISO/IEC 12207- Processos de Ciclo de Vida de Software [3]. Para a definição do guia foram utilizadas as seguintes referências: IEEE 1233 Guia para Desenvolvimento de Especificação de Requisitos de Sistemas[4] e NBR 13596 Avaliação de Produto de Software - Características de Qualidade e Diretrizes para o seu uso [5].

O guia de Especificação de Requisitos da CELEPAR possui as seguintes atividades: Identificação de Requisitos, Análise de Requisitos e Gerenciamento de Mudanças de Requisitos.

A atividade de Identificação de Requisitos tem o objetivo de identificar e descrever os requisitos que devem estar presentes no software. Para que esta atividade pudesse ser facilitada a CELEPAR elaborou uma lista que contém um conjunto de questões a serem observadas. Estas questões estão agrupadas segundo as características de qualidade proposta pela Norma NBR 13596, que são as seguintes: Usabilidade, Funcionalidade, Confiabilidade, Eficiência, Manutenibilidade. Alguns exemplos destas questões são:

 

Funcionalidade:

  • Identificar os usuários e clientes do software;

  • Identificar as funções necessárias para executar uma atividade/processo do usuário

  • Identificar quais são as normas e leis que o software deverá estar em conformidade;

  • Identificar como será a sistemática de segurança de acesso requerido às funções do software;

  • Identificar as aplicações com as quais o software necessita se comunicar (possuir interface).

 

(Maiores detalhes podem ser obtidos no GREQ que está disponível no Portfólio de Tecnologias da CELEPAR, no espaço reservado à MDS).

A atividade de Análise de Requisitos tem como objetivo "alocar" os requisitos identificados ao produto a ser desenvolvido. Esta análise pressupõe uma análise de riscos e de custos para a contemplação de um determinado requisito no software. Um produto comum da análise é o surgimento de novos requisitos, a identificação de dependência ou incompatibilidade de atendimento de requisitos ao mesmo tempo.

A atividade de Gerenciamento de Requisitos é fundamental tanto para o cliente quanto para a equipe técnica, pois é através desta atividade que se garante que o cliente terá a satisfação quando da entrega do produto. A grande questão é que os requisitos mudam conforme o tempo passa, e, muitas vezes, requisitos que não foram alocados inicialmente poderão ser realocados ao software. Um outro fator que contribui para a necessidade desta prática é que muitas vezes, nem todos os requisitos são identificados durante a atividade de Especificação de Requisitos, somente ficando clara a sua necessidade quando o software já está sendo desenvolvido. Nestes casos, faz-se necessário um gerenciamento organizado tanto da inclusão como da deleção de requisitos ao produto de software, pois, normalmente, modificações implicam em alteração de prazos, de recursos humanos e de máquina, de alteração de tecnologia,....

3 Conclusão

Como parte da estratégia de implantação do guia buscou-se o envolvimento das chefias das equipes de desenvolvimento, através de um exercício prático que resultou em uma maior familiarização sobre os detalhes do guia, além do próprio aperfeiçoamento do mesmo.

A abordagem utilizada para identificação e especificação baseada nas características de qualidade da Norma NBR 13596, foi considerada satisfatória, pois facilitou a identificação dos requisitos, principalmente ampliando o foco que antes se concentrava em identificar apenas funcionalidade, através da incorporação de outras questões de qualidade.

Na primeira versão do guia, decidiu-se pela formulação dos requisitos em linguagem natural. Ou seja, não se está adotando propriamente um método de representação de requisitos, dentre os propostos pela literatura [6], apenas estamos organizando sentenças segundo a estrutura das características de qualidade definidas pela Norma NBR 13596. Sabe-se dos riscos que esta opção acarreta: facilidade de se produzir ambiguidades, dificuldade de associação entre os requisitos, baixo nível de formalismo, avaliação da qualidade da especificação não objetiva. Entretanto, é a mais adequada ao estágio atual do processo de desenvolvimento da maioria das empresas e tem mais possibilidade de ser aceita pelos clientes. É na fase subseqüente à especificação de requisitos que o analista elaborará os modelos de processos e de dados do sistema, estes sim, em uma representação mais rigorosa.

Depois que ficar consolidada a prática de gerenciamento de requisitos, será buscado um aperfeiçoamento do guia de especificação de requisitos, através da incorporação de um método que se mostre mais adequado às necessidades da empresa, dentre os que estiverem disponíveis à época.

A empresa também pretende tornar disponível uma ferramenta que cubra todas as peculiaridades da Especificação e do Gerenciamento de Requisitos, de forma que este seja um instrumento que sustente clara e precisamente a relação cliente / fornecedor, desempenhado entre a CELEPAR e os órgãos do Governo do Paraná.

Referências Bibliográficas

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR/3596 : tecnologia de informação - avaliação de produtos de software - características de qualidade e diretrizes para seu estudo. Rio de Janeiro : ABNT, 1996.

[2] IEEE. IEEE standard collection of software engineering terminology. New York : IEEE, 1997.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC/2207 : information technology - software life cycle processes. Geneve : ISO, 1995.

[4] MACHADO, Cristina A. Filipak; FERNANDES, Rosane A.; OLIVEIRA, Luiz Carlos de A. Metodologia de desenvolvimento de serviços. Curitiba : CELEPAR, 1995.

[5] PAULK, Mark C. et al. Capacility maturity model for software, version 1.1. Pittsburgh : Carnigie Mellon University, 1993.

[6] KOTONYA, Gerald; SOMMERVILLE, Ian. Requeriments engineering : processes and techniques. Chichester : J. Wiley, 1998.