Rastreabilidade de requisitos através da web Fernando dos Santos (FURB) fds@inf.furb.br Karly Schubert Vargas (FURB) karly@inf.furb.br Christian Rogério Câmara de Abreu (FURB) crca@inf.furb.br Resumo. O presente artigo apresenta uma ferramenta para o gerenciamento de requisitos via web, cuja ênfase está no uso de matrizes de rastreabilidade como forma de implementar ligações entre requisitos de software. A através destas ligações é possível apresentar ao analista as conseqüências de uma alteração ou exclusão de requisitos no projeto. Palavras-chave: Gerenciamento de Requisitos, Rastreabilidade. 1 Introdução O software de computadores tornou-se uma força motora. É o motor que dirige a tomada de decisão nos negócios. Serve de base à moderna investigação científica e às soluções de problemas de engenharia. É um fator chave que diferencia os produtos e serviços modernos. Está embutido em sistemas de todas as naturezas: de transportes, médicos, de telecomunicações, militares, de processos industriais, de produtos de escritório,... a lista é quase sem fim (Pressman, 2002, p.3). A tendência é um crescimento ainda maior, pois a busca de melhorias no desenvolvimento de produtos e serviços vem exigindo um grau cada vez maior de automação. Devido a isto o desenvolvimento de software tem se tornado mais complexo por atingir áreas que demandam de um conhecimento mais aprofundado. Com este aumento da complexidade dos projetos de software, tornou-se imprescindível um completo acompanhamento e planejamento de todas as etapas do projeto, como forma de garantir que o software atenda as necessidades levantadas. Dentro das diversas áreas da engenharia de software, destaca-se a área de engenharia de requisitos que Sommerville (2003) define como o processo de descobrir, analisar, documentar e verificar as funções e restrições de um sistema. Esta etapa é de fundamental importância, pois faz o levantamento dos objetivos do projeto, descrevendo quais as funções que o software deverá possuir, bem como as restrições de cada função. Caso ocorra algum problema nesta etapa, falhas irão ocorrer durante o desenvolvimento do software. Mas existe uma dificuldade para este acompanhamento quando as equipes de desenvolvimento e os analistas possuem uma distância geográfica que os separa. Pois uma alteração tem que ser vista por todos os envolvidos no momento em que ocorre para que seja mantida a consistência das informações. Para ajudar nisso, surge à internet como forma de interligar todas as pessoas envolvidas no projeto do software. Este artigo tem por objetivo apresentar uma ferramenta para o gerenciamento de requisitos com o diferencial de que sua utilização é feita via web, possibilitando que equipes alocadas em locais diferentes possam ter sempre a sua disposição, informações atualizadas. Além disto, a ferramenta oferece flexibilidade para a confecção das matrizes de rastreabilidade, e permite a visualização do impacto das alterações de determinados requisitos sobre os requisitos do projeto.
2 Requisitos de Software 2.1 Requisitos Segundo Peters (2001) um requisito de software é uma descrição dos principais recursos de um produto de software, seu fluxo de informações, comportamento e atributos. Em suma, um requisito de software fornece uma estrutura básica para o desenvolvimento do produto de software. Os requisitos mostram as características que o cliente deseja no produto final,. Definem os critérios de aceitação de um produto, e são captados na fase de elicitação do projeto, onde são levantadas todas as necessidades do sistema. Seu levantamento deve ser feito de forma bastante cuidadosa, consultando a todas as pessoas que estarão envolvidas no uso do produto final. Com isso é possível evitar vários problemas posteriores ao desenvolvimento do software. Porém, mesmo que seu levantamento seja feito de forma cuidadosa, um problema comum é a instabilidade dos requisitos, uma vez que os mesmos sofrem alterações no decorrer do desenvolvimento. Aqui entra a importância de haver uma ferramenta que permita uma manipulação destes requisitos, podendo haver um controle de quais são os requisitos atuais, quem é responsável pelo requisito e quais os seus atributos. Os requisitos podem ser agrupados em três principais tipos, sendo que sua nomenclatura varia de acordo com o autor (Peters, 2001): a) Funcional (ações principais): Descreve as atividades do sistema, o que ele deve fazer. b) Comportamental (atividades de controle): Descreve a hierarquia das funções e atividades do sistema, faz o controle do sistema. c) Não-Comportamental (atributos): Descreve as regras de funcionamento e condições necessárias para a execução de algumas funções. Trata também da garantia da qualidade. Independente de sua classificação, um requisito possui atributos que definem as características do requisito. Os atributos especificam a prioridade, o status do requisito e seu autor, entre outras informações. Mas não basta somente possuir a descrição dos requisitos, é preciso criar ligações entre eles. Estas ligações permitem a análise do grau de influência que uma alteração pode causar no restante do projeto. Aqui entra a rastreabilidade dos requisitos. 2.2 Rastreabilidade Existem muitas relações entre requisitos e outros requisitos entre os requisitos e o projeto do sistema. Há também elos entre os requisitos e as razões básicas da proposição desses requisitos. (Sommerville, 2003, p. 120). Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no restante do sistema. Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a alteração afeta outros requisitos. Se a alteração é proposta enquanto o sistema está em implementação, o impacto de alteração envolve verificar como a alteração afeta os requisitos, o design do sistema e sua implementação. Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também uma verificação adicional a fim de identificar como todos os stakeholders do sistema podem ser afetados pela alteração. Marquioni (2004) define alguns tipos de rastreabilidade, mostrados na tabela 1.
Tipo de rastreabilidade Requisitos Fontes Requisitos Razão Requisitos Requisitos Requisitos Arquitetura Requisitos Design Requisitos Interface Descrição Link do requisito às pessoas ou documentos que especificaram o requisito. Link do requisito com uma descrição de porque foi especificado. Pode ser uma destilação de informações de várias fontes. Link do requisito com outros requisitos que sejam, de alguma maneira, dependentes dele. Deve ser um link de mão dupla ( depende e é dependente de ). Link do requisito com os subsistemas onde estes requisitos estão implementados. Particularmente importante se os subsistemas estiverem sendo desenvolvidos por subcontratados diferentes. Link do requisito com hardware ou componentes de software específicos no sistema que são usados para implementar o requisito. Link do requisito com as interfaces de sistemas externos que serão usados na provisão dos requisitos. Tabela 1: Tipos de rastreabilidade Para facilitar este rastreamento de requisitos, freqüentemente são utilizadas tabelas de rastreabilidade, que criam associações entre os requisitos. Uma forma de visualização gráfica desta rastreabilidade é uma matriz de rastreabilidade, que mostra a ligação entre os requisitos, onde a linha é dependente da coluna e a coluna depende da linha. Está matriz demonstra de que forma um requisito influencia em outro, possibilitando uma análise do impacto de uma alteração do requisito. Na ferramenta desenvolvida, foi implementado a rastreabilidade do tipo Requisito-Requisito, e utilizada como forma de visualização a matriz de rastreabilidade, com a utilização de flechas indicando a direção da dependência. A tabela 2 apresenta um exemplo de uma matriz de rastreabilidade retirada do artigo de Marquioni (2004). R1 R2 R3 R4 R5 R6 R1 X X R2 X X R3 X X R4 X R5 X R6 Tabela 2: Matriz de rastreabilidade No exemplo, R1 é dependente de R3 e R4; R2 é dependente de R5 e R6, etc. Se for proposta uma alteração no requisito R4, a leitura da coluna R4 aponta que R1 e R3 dependem de R4. Deve ser avaliado com isso o impacto em R1 e R3 com relação à alteração proposta a R4.
O volume de dados que serão controlados pela matriz é significativo, por isso este tipo de controle não é recomendado para um projeto muito grande, nestes casos deve optar-se por outra forma de visualização, como uma lista de rastreabilidade (Marquioni, 2004). 3 Desenvolvimento da Ferramenta A ferramenta desenvolvida, denominada Requisite Online, propõe-se a auxiliar analistas de sistema no gerenciamento de requisitos de projetos de software. Para isto, a ferramenta permite o cadastramento de projetos de software. Em cada projeto, devem ser cadastrados os requisitos do mesmo. Estes requisitos são agrupados de acordo com seus tipos (por exemplo: requisitos funcionais, requisitos não funcionais,...), tipos estes que também são cadastrados pelo analista. Também é possível montar diversas matrizes de rastreabilidade para um mesmo projeto, sendo estas matrizes definidas em função dos tipos de requisitos. A ferramenta também disponibiliza ao analista um relatório com as informações cadastradas no projeto (requisitos e matrizes). Na figura 1 é apresentado o diagrama de casos de uso com a representação das funcionalidades do sistema, e na seqüência, um descritivo das mesmas. Requisitos Analista Montar matriz Efeitos alterações Projetos Visualizar Relatório Tipo de requisito Figura 1: Diagrama de casos de uso Projetos: Este é um caso de uso secundário e trata do cadastro de um novo projeto. Tipo de requisito: Este é um caso de uso secundário e trata do cadastro dos tipos de requisitos (funcionais, não funcionais, regras de negócio, etc.). O cadastro de tipos de requisitos pode ser feito de duas formas: a primeira é o cadastro de um tipo geral, que será utilizado em todos os projetos; a segunda forma é o cadastro de um tipo de requisito específico para um projeto. Requisitos: Este é um caso de uso secundário, e só ocorre após o caso de uso Projetos. Trata do cadastro dos requisitos do projeto de software e seus atributos. Montar matriz: Para este caso acontecer é necessário que tenham ocorrido os seguintes casos de uso: Projetos, Requisitos, Tipo de requisito. Trata da montagem da matriz de rastreabilidade,
feita com base nos requisitos cadastrados. O analista define quais tipos de requisitos irão compor a rastreabilidade, em seguida define a dependência entre os requisitos. A matriz pode ser visualizada após sua confecção. O analista pode montar quantas matrizes achar necessário. Efeitos alterações: Este caso só acontece após a ocorrência do caso de uso Montar matriz. Com a matriz de rastreabilidade montada, o analista pode simular alterações nos requisitos e verificar suas conseqüências. Visualizar Relatório: Este caso só ocorre após o caso de uso Projetos. Neste caso o analista pode visualizar e imprimir as informações sobre o projeto, sendo elas: nome, requisitos e matriz(es) de rastreabilidade do projeto. 3.1 Ferramentas Utilizadas Para o desenvolvimento da ferramenta, foi utilizada a linguagem de programação PHP em conjunto com JavaScript. Para persistência dos dados, utilizou-se o sistema gerenciador de banco de dados MySQL. 3.1.1 PHP Soares (2001) afirma que PHP é uma combinação de linguagem de programação e servidor de aplicações. Você pode programar em PHP como em qualquer outra linguagem, definindo variáveis, criando funções, realizando loops, enfim tudo o que é necessário no mundo da programação. Mas o que realmente difere PHP das outras linguagens de programação é a sua capacidade de interagir com o mundo WEB, transformando páginas estáticas em verdadeiras fontes de informação. As características que foram observadas para a escolha da linguagem de programação são apresentadas por Soares (2001), dentre as quais cita-se que o PHP roda no servidor, é portável, possui código nativo para muitos bancos de dados, entre eles o MySQL e pode ser embutido no HTML. 3.1.2 MySQL Conforme Soares (2001), o MySQL é um gerenciador de banco de dados mais utilizado no mundo Linux, senão for o mais utilizado, pois é uma ferramenta muito poderosa, segura e fácil de utilizar. Além disto, o MySQL é gratuito.[...] Uma das vantagens do MySQL é a sua disponibilização em várias plataformas. Os fatores determinantes na escolha do MySQL para persistência dos dados foram a sua gratuidade e facilidade de uso. A gratuidade garante que nenhum custo precise ser criado ou mantido para utilização do sistema, e a facilidade de uso permitiu que o desenvolvimento se desse de forma consistente e rápida. 3.1.3 JavaScript De acordo com Feather et al (1997), JavaScript é uma linguagem de script (ou roteiro) orientada a objetos, usada para desenvolver aplicações clientes e para Intranets/Internet. Recebe comandos de uma página HTML e, em resposta, pode executar uma ação diferente. No desenvolvimento desta ferramenta, JavaScript foi utilizado para validações em campos de entrada de dados e também para exibição de diálogos de confirmação, quando necessário.
3.2 Implementação Na figura 2, temos o diagrama entidade-relacionamento das entidades desenvolvidas para a persistência dos dados e implementação da ferramenta. CD_PROJETO DS_PROJETO DT_INICIO DT_FIM PROJETO PROJETO_PK <pi> <pi> N5 512 D D PROPOE AGREGA CD_MATRIZ DS_MATRIZ MATRIZ MATRIZ_PK <pi> <pi> I VA100 DEFINE CD_REQUISITO DS_REQUISITO DIFICULDADE ESTABILIDADE NM_REQUISITO PRIORIDADE STATUS REQUISITO REQUISITO_PK <pi> <pi> N5 1024 COMPOSICAO_LINHAS TIPO_REQ_LINHAS_MATIZ COMPOSICAO_COLUNAS TIPO_REQ_COLUNAS_MATRIZ REQ_DESTINO REQ_ORIGEM TIPO_COLUNAS TIPO_LINHAS RELACIONAMENTO REVISADO POSSUI PERTENCE TIPO_REQUISITO_PROJETO CD_TIPO_REQ DS_TIPO_REQ <pi> I VA100 TIPO_REQUISITO_PK <pi> PARTICIPA CD_AUTOR NM_AUTOR AUTOR AUTOR_PK <pi> <pi> I REVISA CD_REVISAO ETIQUETA DS_REVISAO DT_REVISAO HR_REVISAO REVISAO REVISAO_PK <pi> <pi> I D T TP_REQUISITO_SISTEMA CD_REQ DS_TIPO_REQ <pi> I VA100 TP_REQUISITO_SISTEMA_PK <pi> Figura 2: Diagrama entidade-relacionamento da ferramenta desenvolvida. Para cada projeto cadastrado, é armazenado na entidade PROJETO, seu nome, sua data de inicio, e sua data de conclusão. Um projeto agrega vários requisitos, e estes são mantidos na entidade REQUISITO. Cada requisito é composto dos seguintes atributos: nome, autor (do requisito e revisões), prioridade (nível de importância do requisito), status (estado em que o requisito se apresenta), dificuldade (dificuldade no desenvolvimento do requisito), estabilidade (estabilidade que apresenta o requisito em relação ao projeto), descrição e revisões (alterações efetuadas no requisito, se houverem).
Cada requisito cadastrado é agrupado em um determinado tipo de requisito. Um projeto pode apresentar vários tipos de requisitos, e estes são armazenados na entidade TIPO_REQUISITO_PROJETO. O analista tem ainda a possibilidade de cadastrar no sistema os tipos de requisitos que o mesmo considera padrão para todo novo projeto (criando tipos de requisitos globais). Estes tipos são salvos na entidade TP_REQUISITO_SISTEMA, e a cada novo projeto criado o sistema realiza a inserção automática destes tipos de requisitos no novo projeto. Para um projeto, o analista pode propor/montar diversas matrizes de rastreabilidade. Para cada nova matriz é criada uma entrada na entidade MATRIZ. Estas matrizes são montadas em função dos tipos de requisitos que são selecionados para suas linhas e para suas colunas (por exemplo, requisitos funcionais versus requisitos não funcionais). Estes tipos, são armazenados nas entidades TIPO_REQ_LINHAS_MATRIZ e TIPO_REQ_COLUNAS_MATRIZ, respectivamente. A implementação de matrizes de rastreabilidade desta maneira, além de permitir grande flexibilidade ao analista possibilitando a construção de diversas matrizes de rastreabilidade, elimina a necessidade de que cada novo requisito seja adicionado manualmente na(s) matriz(es), pois a mesma relaciona tipos de requisitos, e não simplesmente requisitos. 4 O Requisite Online A ferramenta desenvolvida é acessada através de um browser, sendo necessário que o usuário esteja conectado a internet durante o uso da ferramenta. O usuário, depois de conectado a ferramenta, pode navegar pelo browser e executar todas as funções do sistema. Após realizar todas as suas tarefas, o usuário pode desconectar-se da ferramenta apenas fechando o browser. O Requisite Online está disponível na internet, no seguinte endereço: http://campeche.inf.furb.br/phps/crca/requisitos/conteudo. 4.1 Começando seu uso A figura 3 mostra a tela inicial, que é vista pelo usuário assim que o mesmo abre a ferramenta. Figura 3: Tela inicial Nesta tela, o analista cria um novo projeto e define tipos de requisitos globais para os projetos. Os tipos de requisitos globais serão inseridos automaticamente em todo novo projeto. A
grande vantagem do uso destes tipos de requisitos globais, é que isto torna possível padronizar os tipos de requisitos de todos os novos projetos desenvolvidos. Para iniciar um novo projeto o analista deve selecionar Novo Projeto, informando um nome e a data de inicialização do mesmo, após este passo o projeto será criado na área de Projetos Cadastrados, podendo ser iniciada sua manipulação. 4.2 Principais Funcionalidades Nas seções a seguir, serão apresentadas as principais funcionalidades da ferramenta e de que forma elas podem ser utilizadas. 4.2.1 Cadastro de requisitos O primeiro passo de um projeto é o cadastro dos requisitos. Estes requisitos devem representar as necessidades do software que esta sendo gerenciado. Cada requisito possui um tipo específico, tendo o analista a possibilidade de cadastrar os tipos que considerar necessário, não sendo limitado aos tipos apresentados por Peters (2001). A figura 4 Apresenta a tela para o cadastro do requisito. É solicitado um nome para o mesmo, o autor do requisito, a prioridade, o status do desenvolvimento, o grau de dificuldade, a estabilidade, e uma descrição completa do requisito. A tela é a mesma para todo novo requisito, independente de tipo. Figura 4: Cadastro de requisito 4.2.2 Matriz de Rastreabilidade A forma escolhida para gerenciar os requisitos nesta ferramenta foi o uso de matriz de rastreabilidade, onde o analista cria ligações entre os requisitos. O tipo de rastreamento utilizado é
o de requisitos-requisitos, ou seja, vínculo do requisito com outros requisitos que sejam, de alguma forma dependentes dele (Marquioni, 2004). O sistema gera uma matriz de rastreabilidade simples, que permite registrar as dependências entre os requisitos. Na primeira linha e coluna desta matriz são dispostos os nomes dos requisitos. A dependência entre os requisitos é registrada com um clique na célula de intersecção dos requisitos. Para visualização das dependências, são utilizadas setas que indicam qual(is) o(s) requisito(s) que dependem de um requisito e quais o(s) requisito(s) que são dependentes deste requisito. A leitura da dependência deve ser feita em função da direção da seta. Por exemplo, se a seta parte do requisito A e aponta para o requisito B, lê-se que o requisito B é dependente do requisito A. Devido a visualização da rastreabilidade ser feita com matriz de rastreabilidade, devese somente gerenciar projetos com um número pequeno de requisitos, recomendável no máximo 250. (Marquioni, 2004). A figura 5A mostra o processo para a criação de uma matriz. É necessário um nome e quais tipos de requisitos serão rastreados. Os requisitos dos tipos escolhidos são automaticamente incluídos na matriz de rastreabilidade. A figura 5B mostra a matriz que o analista pode criar, com o relacionamento entre os requisitos. Depois de montada, é possível realizar simulações com a matriz para verificar o efeito de alteração de requisitos. (A) Figura 5: Montando Matriz de rastreabilidade A figura 6 mostra a utilização prática da matriz de rastreabilidade. Trata-se da possibilidade de verificar os efeitos de alterações em requisito(s). Para isto, o analista seleciona, a partir da lista de requisitos que compõem uma matriz, quais destes requisitos serão alterados (figura 6A). Em seguida, o sistema apresenta a visualização, na forma de matriz, dos impactos (em outros requisitos) que a alteração irá causar. Estes impactos são indicados com cores, onde a coluna/linha do requisito alterado é colorida de amarelo, e a coluna/linha do requisito dependente do alterado é colorida de vermelho. A célula de intersecção entre os requisitos é colorida de laranja (figura 6B). (B)
(A) (B) Figura 6: Simulação de alteração de requisito 5 Conclusões A linguagem PHP além de ser de fácil manipulação mostrou-se bastante eficiente e eficaz no que diz respeito ao tempo de resposta nas requisições ao banco de dados. O gerenciamento de requisitos poderá ser realizado remotamente, ou seja, o analista não depende de sua estação de trabalho para executar as atividades que necessita, não havendo portanto, limitações geográficas para uma equipe de desenvolvimento. Além da vantagem de ser independente de plataforma. A ferramenta desenvolvida possui algumas vantagens em relação a outras ferramentas disponíveis no mercado. Uma delas é o fato de sua utilização ser via web, proporcionando uma maior agilidade no gerenciamento dos requisitos. Outra vantagem é o fato de que é possível construir diversas matrizes de rastreabilidade, e suas linhas e colunas não ficam restritas a um único tipo de requisito, podendo assim, rastrear diferentes tipos de requisitos em uma única matriz, o que não é permitido na ferramenta Rational RequisitePro. Com a construção de diversas matrizes de rastreabilidade, surge a possibilidade de gerenciar um número maior de requisitos, superando o limite de 250 requisitos por projeto. O uso de uma ferramenta para o gerenciamento dos requisitos auxilia o analista na organização e controle dos requisitos. Porém é fundamental lembrar a importância da etapa de elicitação dos requisitos pois, em nada adianta uma boa ferramenta de gerenciamento se os requisitos não forem captados de forma correta, refletindo todas as funções que o sistema deve realizar.
Referências FEATHER, Stephen; CASSADY-DORION, Luke. JavaScript em exemplos. São Paulo : Makron Books, 1997. xxv, 357 p. MARQUIONI, Eduardo. Os processos típicos da engenharia de requisitos parte 5, São Paulo, 2004. Disponível em <http://www.choose.com.br/infochoose/artigos/45art03.htm>. Acessado em 8 de julho de 2004. PETERS, James F; PEDRYCZ, Witold. Engenharia de software : teoria e prática. Rio de Janeiro: Campus, 2001. xvii, 602 p. PRESSMAN, Roger S. Engenharia de software. 5.ed. São Paulo : McGraw-Hill, 2002. xxvii, 843 p. SOARES, Walace. MySQL : conceitos e aplicações. São Paulo : Érica, 2001. 294 p. SOMMERVILLE, Ian. Engenharia de software. 6.ed. São Paulo : Addison Wesley, 2003. xiv, 592 p.