Qual dos 12 princípios da engenharia de software deve ser desenvolvido com passos definidos e com precisão e ainda seguidos de maneira efetiva?

Desenvolver software � uma atividade complexa por natureza. Uma das raz�es para esta afirma��o � que n�o existe uma �nica solu��o para cada cen�rio de desenvolvimento. Al�m disso, lidamos o tempo todo com pessoas, o que torna o sucesso do projeto bastante relacionado � compet�ncia da equipe e � forma como trabalham, e, para dificultar ainda mais, muitas vezes n�o fazemos uso de um processo bem definido para apoiar as atividades do projeto.

Guia do artigo:

• Engenharia de Software e Requisitos
• Requisitos
• Requisitos funcionais
• Requisitos n�o funcionais
• Requisitos de dom�nio
• Engenharia de Requisitos
• Produ��o de Requisitos
• Levantamento
• Registro
• Verifica��o
• Valida��o
• Ger�ncia de Requisitos
• Controle de Mudan�as
• Ger�ncia de Configura��o
• Rastreabilidade
• Ger�ncia de Qualidade de Requisitos

Entende-se por processo, neste contexto, como sendo um conjunto de atividades bem definidas com os respectivos respons�veis por execu��o, ferramentas de apoio e artefatos produzidos. Ou seja, define-se como a equipe dever� trabalhar para alcan�ar o objetivo: desenvolver software com qualidade dentro de prazos, custos e requisitos definidos.

A boa not�cia � que muitas empresas est�o se movimentando no sentido de definirem detalhadamente seus processos para apoiarem suas atividades de desenvolvimento. Uma recente mat�ria publicada na revista Exame relata o crescimento do n�mero de empresas que atingiram n�veis de maturidade considerando modelos como MPS.BR e CMMI. Este resultado � um forte indicador de que as empresas nacionais est�o se preocupando com a qualidade dos servi�os que oferecem, conseguindo, dessa forma, uma inser��o maior no mercado internacional de desenvolvimento de software.

Neste artigo, faremos uma introdu��o � Engenharia de Requisitos, atividade base para as demais tarefas associadas ao desenvolvimento de software.

Relacionado: Curso de Engenharia de Software

Engenharia de Software e Requisitos

Vimos na introdu��o que se busca cada vez mais o apoio dos fundamentos da engenharia de software no desenvolvimento de sistemas. Entendemos engenharia de software como sendo, de acordo com o IEEE, a aplica��o de uma abordagem sistem�tica, disciplinada e quantific�vel no desenvolvimento, opera��o e manuten��o de software. Sistem�tica por que parte do princ�pio de que existe um processo de desenvolvimento definindo as atividades que dever�o ser executadas. Disciplinada por que parte do princ�pio de que os processos definidos ser�o seguidos. Quantific�vel por que se deve definir um conjunto de medidas a serem extra�das do processo durante o desenvolvimento de forma que as tomadas de decis�o relacionadas ao desenvolvimento do software (por exemplo, melhoria de processo) sejam embasadas em dados reais, e n�o em �achismos�. Alguns de seus principais objetivos s�o:

• Qualidade de software;
• Produtividade no desenvolvimento, opera��o e manuten��o de software;
• Permitir que profissionais tenham controle sobre o desenvolvimento de software dentro de custos, prazos e n�veis de qualidade desejados.

Entretanto, o cen�rio de desenvolvimento de software atual e o cen�rio idealizado junto � engenharia de software ainda est�o distantes. V�rios fatores contribuem para isso, podemos citar dois:

• O n�o uso dos fundamentos da engenharia de software para apoiar as atividades do desenvolvimento;
• O mau uso dos fundamentos da engenharia de software para apoiar as atividades do desenvolvimento.

Isso tem diversas conseq��ncias. Gostar�amos de destacar neste artigo o crescente custo com manuten��o dos sistemas. Consideramos como manuten��o neste artigo como sendo qualquer retrabalho (em n�vel de requisitos, projeto, codifica��o, teste) causado por uma defini��o do dom�nio do problema mal elaborada nas fases iniciais do desenvolvimento.

Neste ponto, � importante analisamos os dados da Tabela 1. Perceba que o custo das atividades relacionadas � an�lise de requisitos � baixo. Por outro lado, � nesta fase que grande parte dos defeitos s�o inseridos. Podemos perceber ainda analisando a primeira linha que o custo de corre��o destes problemas nesta fase � baixo. Continuando a an�lise, percebemos que estes defeitos n�o s�o tratados no momento devido, o que pode aumentar bastante o custo com o projeto.

Embora simples, esta an�lise nos permite concluir que � importante que seja dada maior import�ncia �s atividades relacionadas � especifica��o dos requisitos do software.

Refor�ando a import�ncia que as atividades relacionadas a requisitos devem possuir na ind�stria de software, estudo realizado pelo Standish Group, considerando 350 companhias e 8.000 projetos de software, em 1995 revelou que (ver Figura 1):

• 16,2% dos projetos s�o finalizados com sucesso, ou seja, cobre todas as funcionalidades em tempo e dentro do custo previsto;
• 52.7% dos projetos s�o considerados problem�ticos, ou seja, n�o cobre todas as funcionalidades exigidas, custo aumentado e est� atrasado.
• 31,1% dos projetos fracassam, ou seja, o projeto � cancelado durante o desenvolvimento.

O Standish Group ainda fez uma an�lise sobre os fatores cr�ticos para sucesso dos projetos de software. O resultado dos dez mais lembrados pode ser visto na Tabela 2. Podemos perceber que tr�s dos principais fatores est�o relacionados �s atividades de requisitos: (1) Requisitos Incompletos; (2) Falta de Envolvimento do Usu�rio; (6) Mudan�a de Requisitos e Especifica��es.

Tabela 2. Fatores cr�ticos do sucesso

Neste ponto, sabemos que um trabalho mais criterioso na �rea de requisitos � fundamental para o sucesso de projetos de software. A partir da pr�xima se��o conheceremos a defini��o de requisitos e algumas de suas defini��es relacionadas antes de discutirmos mais profundamente a engenharia de requisitos.

Requisitos

Existem diferentes defini��es encontradas na literatura t�cnica para requisitos:

• Um requisito � uma caracter�stica do sistema ou a descri��o de algo que o sistema � capaz de realizar para atingir os seus objetivos;
• As descri��es das fun��es e restri��es s�o os requisitos do sistema;
• Um requisito � uma propriedade que o software deve exibir para resolver algum problema no mundo real;
• Uma condi��o ou uma capacidade que deve ser alcan�ada ou estar presente em um sistema para satisfazer um contrato, padr�o, especifica��o ou outro documento formalmente imposto...

Percebe-se que as cita��es encontradas definem o mesmo conceito sob diferentes perspectivas. Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente que dever�o ser atendidas para solucionar um determinado problema do neg�cio no qual o cliente faz parte. � importante estar atento para esta defini��o: embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer � o que o neg�cio precisa. Cabe � equipe de consultores identificar a real necessidade do neg�cio.

Neste contexto, requisitos s�o importantes para:

• Estabelecer uma base de concord�ncia entre o cliente e o fornecedor sobre o que o software far�;
• Fornecer uma refer�ncia para a valida��o do produto final;
• Reduzir o custo de desenvolvimento (como vimos anteriormente, requisitos mal definidos causam retrabalho).

Entendida a defini��o de requisitos, � preciso conhecer seus tipos.

Requisitos funcionais

S�o requisitos diretamente ligados a funcionalidade do software, descrevem as fun��es que o software deve executar. Alguns exemplos s�o:

• O software deve permitir o cadastro de clientes;
• O software deve permitir a gera��o de relat�rios sobre o desempenho de vendas no semestre;
• O software deve permitir o pagamento das compras atrav�s de cart�o de cr�dito.

Requisitos n�o funcionais

S�o requisitos que expressam condi��es que o software deve atender ou qualidades espec�ficas que o software deve ter. Em vez de informar o que o sistema far�, os requisitos n�o-funcionais colocam restri��es no sistema. Alguns exemplos s�o:

• O software deve ser compat�vel com os browsers IE (vers�o 5.0 ou superior) e Firefox (1.0 ou superior);
• O software deve garantir que o tempo de retorno das consultas n�o seja maior do que 5 segundos.

Requisitos de dom�nio

S�o requisitos derivados do dom�nio da aplica��o e descrevem caracter�sticas do sistema e qualidades que refletem o dom�nio. Podem ser requisitos funcionais novos, restri��es sobre requisitos existentes ou computa��es espec�ficas. Dois exemplos de requisitos do dom�nio s�o:

• O calculo da m�dia final de cada aluno � dado pela f�rmula: (Nota1 * 2 + Nota2 * 3)/5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pr�-requisitos.

A partir da pr�xima se��o apresentaremos os conceitos envolvidos na engenharia de requisitos.

Engenharia de Requisitos

Existem diferentes defini��es encontradas na literatura t�cnica para engenharia de requisitos:

• Termo usado para descrever as atividades relacionadas � investiga��o e defini��o de escopo de um sistema de software;
• Processo sistem�tico de desenvolvimento de requisitos atrav�s de um processo cooperativo de an�lise onde os resultados das observa��es s�o codificados em uma variedade de formatos e a acur�cia das observa��es � constantemente verificada;
• Processo de descobrir, analisar, documentar e verificar as fun��es e restri��es do sistema.

Embora coerentes, estas defini��es podem ser melhoradas. Perceba que elas referem-se apenas �s atividades relacionadas � produ��o de requisitos. Entretanto, nada � dito a respeito da ger�ncia destas atividades, tamb�m conhecida como ger�ncia de requisitos. Com isto em mente, podemos evoluir a defini��o de engenharia de requisitos para: termo usado para descrever as atividades relacionadas � produ��o (levantamento, registro, valida��o e verifica��o) e ger�ncia (controle de mudan�as, ger�ncia de configura��o, rastreabilidade, ger�ncia de qualidade dos requisitos) de requisitos. A Figura 3 representa essa defini��o.

Desta forma, os dois conceitos base (produ��o e ger�ncia) devem ser considerados em conjunto ao se definir estrat�gias de trabalho com requisitos nas organiza��es (ver Figura 4).

Neste ponto podemos citar alguns dos principais objetivos da engenharia de requisitos:

• estabelecer uma vis�o comum entre o cliente e a equipe de projeto em rela��o aos requisitos que ser�o atendidos pelo projeto de software;
• registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento;
• documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de software;
• manter planos, artefatos e atividades de software consistentes com os requisitos alocados.

Para apoiar o alcance destes objetivos, � importante que se tenha um processo de engenharia de requisitos bem definido. Um processo de engenharia de requisitos � um conjunto estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos. Poucas organiza��es t�m um processo de ER explicitamente definido e padronizado. Entretanto, sugere-se que cada organiza��o deva desenvolver um processo adequado � sua realidade. A Figura 5 apresenta um modelo gen�rico de atividades que pode descrever a maioria dos processos de engenharia de requisitos. Perceba que ele est� concentrado nas atividades de produ��o dos requisitos.

Apesar do aparente fluxo entre as atividades, n�o existe uma fronteira expl�cita elas. Na pr�tica existe muita sobreposi��o e intera��o entre uma atividade e outra.

Como entradas para o processo s�o consideradas:

• Descri��es do que os stakeholders necessitam para suportar suas atividades;
• Informa��es a respeito do sistema que ser� substitu�do ou de qualquer sistema com o qual o sistema sendo definido ter� que interagir;
• Padr�es vigentes na organiza��o a respeito de pr�ticas de desenvolvimento de sistemas, ger�ncia de qualidade, etc.;
• Regulamentos externos, tais como leis, regulamentos de seguran�a ou sa�de;
• Informa��es gerais sobre o dom�nio de aplica��o.

Em paralelo � execu��o das atividades definidas no processo da Figura 5, est� o processo de ger�ncia dos requisitos, voltado ao endere�amento de modifica��es nos requisitos. Os aspectos relacionados �s atividades de ger�ncia podem ser vistos na Figura 3.

A partir de agora conheceremos cada um dos conceitos que, em conjunto, definem a engenharia de requisitos.

Produ��o de Requisitos

A cada fase do ciclo de vida do software produzimos um documento contendo uma representa��o distinta do software a ser constru�do. Cada um desses documentos representa o software em um determinado n�vel de abstra��o. A tend�ncia � diminuirmos o n�vel de abstra��o atrav�s da inclus�o de mais e mais detalhes, at� que, sua �ltima representa��o seja o c�digo fonte na linguagem escolhida.

Um dos artefatos produzidos no in�cio do processo de desenvolvimento de software � a sua especifica��o de requisitos. Ele � base para as demais atividades de desenvolvimento e sua qualidade � fundamental para o sucesso do projeto. Uma especifica��o de requisitos bem elaborada � pr�-requisito para um software de qualidade, embora n�o seja garantia disso. Desta forma, durante a produ��o de requisitos devemos possuir, al�m das atividades essenciais de levantamento e especifica��o, atividades relacionadas � garantia da qualidade. Conheceremos nesta se��o as quatro atividades base relacionadas com a produ��o de requisitos.

Levantamento

Esta atividade relaciona-se � obten��o dos requisitos do software. Para isto, analistas e engenheiros de software trabalham com clientes e usu�rios finais para descobrir o problema a ser resolvido, os servi�os do sistema, o desempenho necess�rio, restri��es de hardware e outras informa��es.

Existem algumas t�cnicas que apoiam as atividades de levantamento de requisitos. Uma breve descri��o de algumas delas �:

• Entrevista: esta t�cnica resume-se em �conversas� realizadas com o usu�rio (entrevistado) para levantar os requisitos do sistema a ser desenvolvido. Podemos decompor esta t�cnica nas seguintes atividades:
  • Ler material de suporte;
  • Estabelecer os objetivos da entrevista;
  • Decidir quem entrevistar;
  • Preparar o entrevistado;
  • Decidir os tipos de quest�es e a sua estrutura.
• Uma entrevista pode ser estruturada de tr�s diferentes formas:
  • Estrutura em pir�mide: iniciamos as entrevistas com perguntas mais especificas sobre o sistema e fechamos com perguntas mais gen�ricas. Geralmente utilizadas com usu�rios mais relutantes;
  • Estrutura em funil: iniciamos as entrevistas com perguntas mais gen�ricas sobre o sistema e fechamos com perguntas mais especificas. Geralmente utilizadas com usu�rios que tem uma rela��o mais afetiva com o assunto;
  • Estrutura em diamante: esta estrutura combina as duas estruturas anteriores e � utilizadas para manter a usu�rio entrevistado interessado no assunto e para isto se utiliza de perguntas variadas.
• Prototipa��o: � uma vers�o inicial de um sistema para experimenta��o. Permite aos utilizadores identificar os pontos fortes e fracos do sistema por ser algo concreto que pode ser criticado. Temos dois tipos de prot�tipos:
  • Prot�tipos �Throw-away�: ajudam o levantamento e desenvolvimento dos requisitos e suportam os requisitos mais dif�ceis de perceber;
  • Prot�tipos Evolutivos: ajudam o desenvolvimento r�pido de uma vers�o inicial do sistema e suportam os requisitos bem definidos e conhecidos.

Algumas das desvantagens da prototipa��o s�o os custos de aprendizagem e os custos de desenvolvimento.

• JAD (Joint Application Development): � uma t�cnica que permite a intera��o entre pessoas que necessitam tomar decis�es que afetem m�ltiplas �reas de uma organiza��o. Esta t�cnica envolve atividades de prepara��o para as reuni�es, sess�es de workshop com os participantes, agenda para as reuni�es, participantes assumindo papeis de facilitador / condutor e documentador al�m de facilidades visuais, como a utiliza��o de flipchart, quadro negro.

Esta t�cnica deve ser utilizada nos casos onde existe a necessidade de consenso entre diversos usu�rios, pois possibilita a todos os envolvidos ter uma vis�o global do sistema, ajudando a consolidar interesses de diversos usu�rios quanto ao sistema a ser desenvolvido.

O objetivo desta t�cnica � aumentar o comprometimento e participa��o do usu�rio e obter subs�dios para elaborar o documento de Especifica��o de Requisitos para o sistema com consenso de todos de forma a ser uma valida��o formal dos requisitos do sistema.

O JAD � divido quem quatro fases. A Figura 6 apresenta estas fases e os artefatos produzidos por cada uma delas.

A atividade de levantamento de requisitos n�o � trivial. Existe um conjunto grande e variado de fatores que a tornam complexa, por exemplo:

• Falta de conhecimento do usu�rio das suas reais necessidades
• Usu�rio com vaga no��o do que precisa e do que um produto de software pode oferecer.
• Falta de conhecimento do desenvolvedor do dom�nio do problema
• Desenvolvedor sem conhecimento adequado do dom�nio, o que leva a decis�es erradas.
• Dom�nio do processo de levantamento de requisitos pelos desenvolvedores
• Desenvolvedor n�o ouve o que os usu�rios t�m a dizer e for�a suas pr�prias vis�es e interpreta��es.
• Comunica��o inadequada entre os desenvolvedores e usu�rios
• Usu�rios incapazes de expressar suas necessidades apropriadamente;
• Significados diferentes a termos comuns.
• Dificuldade do usu�rio tomar decis�es
• Falta de entendimento sobre as conseq��ncias das decis�es ou as alternativas poss�veis.
• Problemas de comportamento
• O levantamento de requisitos � um processo social;
• Conflitos e ambiguidades nos pap�is que os usu�rios e desenvolvedores desempenham.
• Quest�es t�cnicas
• Complexidade crescente dos sistemas atuais.

Registro

Uma vez identificados e negociados, os requisitos devem ser documentados para que possam servir de base para o restante do processo de desenvolvimento.

Entre os muitos problemas que enfrentamos na documenta��o de requisitos, certamente, administrar o grande volume de informa��es gerado pelo processo de requisitos � um dos principais.

Os requisitos s�o documentados em um n�vel apropriado de detalhe. Em geral � produzido um documento de especifica��o de requisitos, de forma que todos os stakeholders possam entend�-lo.

O registro dos requisitos num documento pr�prio facilita o controle de altera��es de todos os envolvidos na manuten��o dos requisitos, bem como a gera��o de vers�es do documento e a facilidade de acesso por todos os envolvidos.

Verifica��o

Esta atividade examina a especifica��o do software, de forma a assegurar que todos os requisitos foram definidos sem ambiguidades, inconsist�ncias ou omiss�es, detectando e corrigindo poss�veis problemas ainda durante a fase de defini��o dos requisitos.

Neste contexto, sabe-se que o custo da corre��o de defeitos aumenta na medida em que o processo de desenvolvimento progride. Revis�es de artefatos de software t�m se mostrado uma abordagem eficiente e de baixo custo para encontrar defeitos logo ap�s terem sido introduzidos, reduzindo o retrabalho e melhorando a qualidade dos produtos. N�o � em v�o que modelos de maturidade de processo de software, como o CMMI e o MPS BR exigem a condu��o de revis�es.

Um tipo particular de revis�o de software s�o as inspe��es. Inspe��es possuem um processo de detec��o de defeitos rigoroso e bem definido. Os benef�cios de se aplicar inspe��es s�o maiores para artefatos desenvolvidos no in�cio do processo, como o documento de requisitos. Conheceremos um pouco mais sobre inspe��o de software em um segundo artigo a ser publicado na segunda edi��o da Engenharia de Software Magazine.

Valida��o

A valida��o representa a atividade em que obtemos o aceite do cliente sob determinado artefato. No cen�rio de engenharia de requisitos, esta atividade significa aprovar junto ao cliente os requisitos que foram especificados. Embora aparentemente simples, esta atividade pode ser bastante dificultada pelo cliente ou mesmo por um processo de valida��o inadequado utilizado pela empresa.

Ger�ncia de Requisitos

Requisitos s�o por natureza vol�teis. Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudan�as externas no ambiente (mudan�as de legisla��o, mudan�as no mercado, mudan�a no posicionamento estrat�gico da empresa), erros incorridos no processo de requisitos, entre outros. Todos esses fatores fazem com que seja necess�rio alterar os requisitos. Tais altera��es precisam ser conduzidas de forma ordenada para que n�o se perca controle sobre o prazo e o custo do desenvolvimento.

Denominamos a atividade de administrar os requisitos ao longo do tempo de gerenciamento de requisitos. Os benef�cios desta atividade s�o percebidos no m�dio prazo, sendo que s�o necess�rios investimentos no curto prazo. Assim, a atividade �, muitas vezes, tida como um fardo desnecess�rio � condu��o do processo. Contudo, sua n�o implementa��o faz com que as economias de curto prazo sejam logo suplantadas pelas despesas no longo prazo, verificadas com supera��o de custo e prazo nos projetos conduzidos.

Veremos a partir de agora algumas das atividades que devem ser consideradas durante a ger�ncia dos requisitos.

Controle de Mudan�as

Conforme foi citado anteriormente, os requisitos s�o vol�teis e, portanto sofrem mudan�as ao logo do tempo, para conduzir estas mudan�as recomenda-se preparo e planejamento. Uma das maneiras bastante utilizadas para organizar estas mudan�as � a �baseline� de requisitos que nos permite diferenciar o que era o requisito original, o que foi introduzido e o que foi descartado. Al�m disto, � interessante estabelecer um �nico canal para controle de mudan�as, bem como utilizar um sistema para este controle.

Apresentamos a seguir uma sugest�o de passos que devem ser seguidos para um processo de controle de mudan�a:

• Checar validade da solicita��o de mudan�a;
• Identificar os requisitos diretamente afetados com a mudan�a;
• Identificar depend�ncias entre requisitos para buscar os requisitos afetados indiretamente;
• Assegurar com solicitante a mudan�a a ser realizada;
• Estimar custos da mudan�a;
• Obter acordo com usu�rio sobre o custo da mudan�a.

Ap�s a realiza��o desta an�lise, podemos aceitar ou rejeitar a mudan�a, conforme os impactos e custos que ela pode ter no sistema.

Ger�ncia de Configura��o

Durante o ciclo de vida do desenvolvimento, o software passa por uma s�rie de modifica��es, desde a especifica��o dos requisitos at� a implanta��o do sistema. A ger�ncia de configura��o de software existe no intuito de definir crit�rios que permitam realizar tais modifica��es mantendo-se a consist�ncia e a integridade do software com as especifica��es, minimizando problemas decorrentes ao processo de desenvolvimento, atrav�s de um controle sistem�tico sobre as modifica��es.

A cria��o de um plano de ger�ncia de configura��o consiste em estabelecer normas, ferramentas e templates que permitam gerenciar de maneira satisfat�ria os itens de configura��o de um sistema, que s�o definidos por Pressman como: �cada um dos elementos de informa��o que s�o criados durante o desenvolvimento de um produto de software, ou que para este desenvolvimento sejam necess�rios, que s�o identificados de maneira �nica e cuja evolu��o � pass�vel de rastreamento�.

Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configura��o deve ser estabelecido. A este conjunto � dado o nome de baselines. Estas baselines servem como marco no processo de desenvolvimento, pois ao final de cada fase � estabelecida uma nova baseline e, portanto, todos os itens de configura��o est�o sob total controle de seus desenvolvedores. Desta forma, nesta baseline � guardada �uma foto� dos artefatos criados at� aquele momento:

• tornando mais f�cil realizar modifica��es nos artefatos de maneira controlada;
• possibilitando ter um controle sistem�tico sobre todos os itens de configura��o abordados em cada fase do ciclo de vida do software, e;
• tornando poss�vel que sejam realizadas, mais facilmente, avalia��es sobre seu grau de evolu��o.

Rastreabilidade

No centro da atividade de gerenciamento de requisitos est� a rastreabilidade. Esta � definida como a habilidade de se acompanhar a vida de um requisito em ambas as dire��es (por exemplo: partindo de requisitos e chegando a projeto ou, partindo de projeto e chegando a requisitos) do processo de software e durante todo o seu ciclo de vida.

A dificuldade envolvida com a rastreabilidade est� no grande volume de informa��es gerado. As informa��es do processo de requisitos devem ser catalogadas e associadas aos outros elementos de forma que possam ser referenciadas atrav�s dos diversos itens de informa��o registrados. � um trabalho extenso que, sem o aux�lio de ferramentas adequadas, muito provavelmente n�o poder� ser feito

Para implementar a rastreabilidade, usualmente � confeccionado em conjunto com a especifica��o de requisitos um artefato chamado matriz de rastreabilidade, que tem como objetivo mapear os rastros dos requisitos descritos na especifica��o.

Os rastros dos requisitos podem ser de dois tipos:

• Pr�-rastreabilidade: os rastros (artefatos: plano de negocio, atas de reuni�o com o usu�rio) que fundamentaram a cria��o do requisito.
• P�s-rastreabilidade: os rastros (artefatos: c�digo, documentos) que se formaram a partir do requisito criado.

Ger�ncia de Qualidade de Requisitos

Segundo o padr�o IEEE 830, devemos considerar alguns crit�rios de qualidade ao trabalharmos com requisitos:

• Corre��o: um documento de requisitos � considerado correto se todos os requisitos representam algo que deve estar presente no sistema que est� sendo desenvolvido, ou seja, os requisitos reais do usu�rio devem coincidir com os requisitos identificados. Esta n�o � uma tarefa trivial e parte de seu sucesso est� associada a uma boa atividade de valida��o dos requisitos.
• N�o ambiguidade: um conjunto de requisitos � n�o amb�guo quando somente pode ser interpretado por todos os envolvidos em um projeto de uma �nica maneira.
• Completude: um conjunto de requisitos � dito completo quando descreve todas as demandas de interesse dos usu�rios. Estas demandas incluem requisitos funcionais, de desempenho, restri��es, atributos e interfaces externas.
• Consist�ncia: um conjunto de requisitos � dito consistente se nenhum subconjunto destes requisitos entra em conflito com os demais requisitos do sistema.
• Verificabilidade: um requisito � verific�vel se existe uma forma efetiva, em termos de tempo e custo, para que pessoas ou ferramentas indiquem se um sistema cumpre o requisito (IEEE). Em quase todas as situa��es, � dif�cil provar de forma conclusiva que um requisito � cumprido por um software. Entretanto, escrever bem o requisito pode ajudar a aumentar a confian�a na avalia��o.
• Modificabilidade: um conjunto de requisitos � modific�vel quando seu estilo e estrutura � tal que as altera��es podem ser realizadas de forma simples e consistente com os demais requisitos.

A ger�ncia, neste cen�rio, � respons�vel por manter uma infra-estrutura necess�ria para atividades de verifica��o que tornem poss�vel investigarmos a qualidade dos requisitos que estamos definindo.

Conclus�o

A engenharia de requisitos define, sem d�vida, um dos mais importantes conjuntos de atividades a serem realizadas em projetos de desenvolvimento de software. Embora n�o garanta a qualidade dos produtos gerados, � um pr�-requisitos b�sico para que obtenhamos sucesso no desenvolvimento do projeto. Este artigo � apenas uma breve introdu��o ao tema, que dever� ser bastante explorado em edi��es futuras da Engenharia de Software Magazine.

Confira tamb�m

• Levantamento de Requisitos

Confira outros conte�dos: