validação de requisitos no contexto da engenharia de software

8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

1/32

UNIVERSIDADE FEDERAL DE PERNAMBUCO

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

CENTRO DE INFORMÁTICA

UUUUMMMM EEEESTUDOSTUDOSTUDOSTUDO SSSSOBREOBREOBREOBRE AAAA VVVVALIDAÇÃOALIDAÇÃOALIDAÇÃOALIDAÇÃO DEDEDEDERRRREQUISITOSEQUISITOSEQUISITOSEQUISITOS NONONONO CCCCONTEXTO DAONTEXTO DAONTEXTO DAONTEXTO DA

EEEENGENHARIA DENGENHARIA DENGENHARIA DENGENHARIA DE SSSSOFTWAREOFTWAREOFTWAREOFTWARE

AutorAutorAutorAutor

Alberto Ramos de Lima

OrientadorOrientadorOrientadorOrientador

Prof. Jaelson Freire Brelaz de Castro

Recife,Recife,Recife,Recife, marçomarçomarçomarço 2002002002008888

Universidade Federal de Pernambuco

Centro de Informática

ALBERTO RAMOS DE LIMA


2/32

2

ÍndiceÍndiceÍndiceÍndice

1

Introdução .......................................................................................3

1.1 Motivação..................................................................................3

1.2 Objetivos...................................................................................4

1.3 Organização do Trabalho...........................................................4

2

Processo de Engenharia de Requisitos ..............................................6

2.1 Visão Geral do Processo de Engenharia de Requisitos.................6

2.1.1 Entradas e Saídas do Processo .............................................7

2.2 Atividades do Processo de Engenharia de Requisitos ..................8

2.3 Gerenciamento de Requisitos...................................................12

3

Validação de Requisitos..................................................................15

3.1 Processo de Validação de Requisitos........................................15

3.2 Técnicas de Validação de Requisitos ........................................21

3.2.1 Revisão de Requisitos........................................................21

3.2.2 Prototipação......................................................................25

3.2.3 Testes de Requisitos..........................................................27

4

Considerações Finais......................................................................30

Referências Bibliográficas...........................................................................31


3/32

3

1111 IntroduçãoIntroduçãoIntroduçãoIntrodução

Este primeiro capítulo mostra a motivação de se realizar a pesquisa

deste trabalho, bom como toda sua organização.

1.11.11.11.1 MotivaçãoMotivaçãoMotivaçãoMotivação

É notório o crescimento do mercado de Tecnologia da Informação e ele

traz consigo o aumento da concorrência entre as empresas produtoras de

software, as quais precisam buscar diferenciais para agregar valor a seus

produtos e, assim, expandir seu mercado consumidor Um dos fatores, talvez

o principal, que vem se mostrando eficiente em diferenciar empresas

produtoras de software é a implantação de um processo de garantia da

qualidade de software [GOMES 2005].

Na prática, empresas bem-sucedidas da área de construção de

software têm percebido que um compromisso organizacional com a

qualidade traz melhorias no tempo de desenvolvimento, redução de custos e

permite que novas funcionalidades sejam adicionadas com maior facilidade

[IBM 2004]. Nesse aspecto, a Engenharia de Requisitos tem um papel

preponderante.

Estudos demonstram que uma grande quantidade de projetos de

software são cancelados ou fracassam por não atenderem completamente as

necessidades dos clientes e excederem o prazo e o orçamento estimados.

Não há uma explicação simples para este fenômeno, mas diversos trabalhos

apontam deficiências nos requisitos dos sistemas como uma das principais

causas de fracassos em projetos de software [ESPINDOLA 2004].


4/32

4

A Engenharia de requisitos (ER) é o processo de descoberta de

funcionalidades e restrições de um sistema, identificando stakeholders e

suas necessidades e documentando essas descobertas de uma forma que

possibilite a análise, comunicação e uma implementação futura [NUSEIBEH

2000].

E é no contexto na Engenharia de Requisitos que a atividade de

Validação de Requisitos é apresentada como fundamental na garantia do

desenvolvimento de produtos cada vez melhores, minimizando o re-trabalho

e custo e maximizando os lucros para as empresas.

1.21.21.21.2 ObjetivosObjetivosObjetivosObjetivos

Este trabalho tem como objetivo primordial a explicitação dos

conceitos relativos à Validação de Requisitos, bem como o estudo de

algumas técnicas usadas na execução desta atividade. Além disso, objetiva-

se dar uma visão geral do Processo de Engenharia de Requisitos, suas

atividades e relatar a importância da Validação de Requisitos neste contexto.

1.31.31.31.3 Organização do TrabalhoOrganização do TrabalhoOrganização do TrabalhoOrganização do Trabalho

A monografia está estruturada em capítulos que se dividem da

seguinte forma:

Capítulo 1 – introduz o trabalho, apresenta as razões pelas quais

deram motivação para esse estudo.

Capítulo 2 - apresenta uma visão geral do Processo de Engenharia de

Requisitos, descrevendo sucintamente cada uma de suas atividades.


5/32

5

Capítulo 3 – apresenta de forma mais detalhada a Validação de

Requisitos, destacando seus conceitos e algumas técnicas existentes para

facilitar a execução desta atividade.

Capítulo 4 – apresenta as considerações finais do trabalho.


6/32

6

2222 Processo de Engenharia de RequProcesso de Engenharia de RequProcesso de Engenharia de RequProcesso de Engenharia de Requisitosisitosisitosisitos

Neste capítulo apresentaremos as definições envolvidas no Processo de

Engenharia de Requisitos, explicitando suas entradas, saídas e atividades.

2.12.12.12.1 Visão Geral do Processo de Engenharia de RequisitosVisão Geral do Processo de Engenharia de RequisitosVisão Geral do Processo de Engenharia de RequisitosVisão Geral do Processo de Engenharia de Requisitos

O processo de engenharia de requisitos é um conjunto estruturado de

atividades que são seguidas para derivar, validar e manter um documento de

requisito [KOTONYA 1998]. Uma descrição completa do processo deve

incluir: (a) quais atividades são executadas; (b) a estruturação e o

cronograma delas; (c) quem é o responsável por cada uma das atividades; (d)

suas entradas e saídas; e (e) as ferramentas usadas para suportar a

engenharia de requisitos.

Podemos definir as entradas e saídas de um processo da Engenharia de

Requisitos na Figura 1 [KOTONYA 1998].

FiguraFiguraFiguraFigura 1111 –––– Processo da Engenharia de RequisitosProcesso da Engenharia de RequisitosProcesso da Engenharia de RequisitosProcesso da Engenharia de Requisitos


7/32

7

Para melhor entendimento, seguem as descrições de cada entrada e

saída que compõem o processo acima.

2.1.12.1.12.1.12.1.1

Entradas e Saídas do ProcessoEntradas e Saídas do ProcessoEntradas e Saídas do ProcessoEntradas e Saídas do Processo

De acordo com a Figura 1, temos o detalhamento de cada uma das

entradas e saídas que fazem parte do Processo de Engenharia de Requisitos

[KOTONYA 1998].

• EntradasEntradasEntradasEntradas

o Informações ExistentesInformações ExistentesInformações ExistentesInformações Existentes do Sistemado Sistemado Sistemado Sistema - Refere-se a informações

gerais sobre o sistema que será substituído ou criado e de

outros sistemas com o qual o sistema deverá interagir.

o Necessidades dos Clientes/UsuáriosNecessidades dos Clientes/UsuáriosNecessidades dos Clientes/UsuáriosNecessidades dos Clientes/Usuários - Refere-se a uma descrição

das necessidades das partes interessadas para apoiar seu

trabalho.

o Padrões OrganizacionaisPadrões OrganizacionaisPadrões OrganizacionaisPadrões Organizacionais ---- Refere-se a padrões e normas

adotadas pela empresa para o desenvolvimento de sistemas,

incluindo métodos para o desenvolvimento, práticas para

garantia de qualidade, etc..

o Regras e RegulamentosRegras e RegulamentosRegras e RegulamentosRegras e Regulamentos ---- Normas e regulamentos externos que

se apliquem ao sistema.


8/32

8

o Informações do DomInformações do DomInformações do DomInformações do Domínioínioínioínio - Informações gerais sobre o domínio

do sistema.

• SaídasSaídasSaídasSaídas

o Requisitos AgregadosRequisitos AgregadosRequisitos AgregadosRequisitos Agregados - Descrição dos requisitos levantados,

avaliados e aprovados pelas partes interessadas.

o

Especificação do SistemaEspecificação do SistemaEspecificação do SistemaEspecificação do Sistema ---- Uma especificação mais detalhada dosistema a ser desenvolvido.

o Modelos do SistemaModelos do SistemaModelos do SistemaModelos do Sistema ---- Um conjunto de modelos que descrevem o

sistema a partir de diferentes perspectivas.

2.22.22.22.2

Atividades do Processo de Engenharia de RequisitosAtividades do Processo de Engenharia de RequisitosAtividades do Processo de Engenharia de RequisitosAtividades do Processo de Engenharia de Requisitos

Diversas atividades podem ser definidas para o processo da engenharia

de requisitos. A diversidade existente entre os processos definidos por vários

autores se deve a complexidade da área, a interpretação da resolução dos

problemas ou as diferentes áreas de aplicação da engenharia de requisitos.

Com este panorama não existe um consenso sobre um modelo de processos

para a Engenharia de Requisitos, viabiliza-se assim a definição e a

modelagem de um processo de requisitos que suporte a construção de

sistemas de informação [GENVIGIR 2005].


9/32

9

Podemos relacionar como atividades da Engenharia de Requisitos as

atividades abaixo.

• Elicitação de RequisitosElicitação de RequisitosElicitação de RequisitosElicitação de Requisitos

É a atividade relacionada com a identificação dos requisitos do sistema,

a partir de consulta aos representantes de cada grupo de usuários; da análise

de documentos do domínio em questão; do conhecimento desse domínio;

e/ou de pesquisas de mercado. A finalidade geral do processo de elicitação é

identificar os fatos que compõem os requisitos do sistema, de forma a prover

o mais correto entendimento do que dele é esperado [PAIM 2003].

• Análise e Negociação dAnálise e Negociação dAnálise e Negociação dAnálise e Negociação de Requisitose Requisitose Requisitose Requisitos

Envolve atividades que visam descobrir problemas com os requisitos

de sistema e estabelecer um acordo de mudanças que satisfaça todos os

afetados. O processo de análise e negociação é caro e demorado porque

requer pessoas qualificadas e experientes para dedicar tempo à leitura

cuidadosa de documentos e identificação das implicações contidas nas

declarações presentes nesses artefatos [KOTONYA 1998). Na maioria das

vezes, atividades de análise e negociação de requisitos são executadas de

forma paralela ou intercalada, em conjunto com atividades de elicitação de

requisitos.

• Documentação de RequisitosDocumentação de RequisitosDocumentação de RequisitosDocumentação de Requisitos


10/32

10

Nesta fase, os requisitos acordados são anotados num documento que

reúne, num nível apropriado de detalhe, o escopo de requisitos que servirá

como base para o processo de desenvolvimento do software. O documento

de requisitos serve como um contrato entre usuários e desenvolvedores, e

deve ser formatado e estruturado de acordo com padrões organizacionais

[PAIM 2003].

• Validação de RequisitosValidação de RequisitosValidação de RequisitosValidação de Requisitos

É definida como o processo que certifica que o modelo de requisitos

gerado esteja consistente com as necessidades e intenções de clientes e

usuários [PAIM 2003]. Essa visão da atividade de validação retrata um

processo contínuo, ocorrendo na maior parte do tempo em paralelo com as

fases de elicitação e especificação (análise, negociação e documentação). De

fato, a validação não é só aplicada ao modelo final de requisitos, mas

também a todos os modelos intermediários gerados ao longo do processo de

requisitos.

O sucesso de um projeto é diretamente afetado pela qualidade do

Documento de Requisitos. É desejável que cada requisito relacionado no

Documento de Requisitos apresente as características a seguir [SAYAO 2003]:

Univocamente identificável:Univocamente identificável:Univocamente identificável:Univocamente identificável: requisitos que referenciam tabelas ou

figuras ou que são na verdade compostos por outros devem ser

individualizados;


11/32

11

Ser necessário:Ser necessário:Ser necessário:Ser necessário: deve refletir uma funcionalidade ou característica

essencial, que não possa ser preenchida por outra existente no produto ou

processo; sua ausência implicará numa deficiência no sistema;

Ser conciso:Ser conciso:Ser conciso:Ser conciso: a definição do requisito deve ser clara e objetiva, sendo

facilmente compreensível;

Independente de implementação:Independente de implementação:Independente de implementação:Independente de implementação: esta característica indica que a

definição do requisito deve apontar para o que deve ser feito, e não para

como fazê-lo. Adequada na maior parte das vezes, esta característica no

entanto é função de requisitos não funcionais, os quais podem pré-

determinar uma série de aspectos de implementação;

Viável:Viável:Viável:Viável: claramente, a implementação do requisito deve ser possível de

ser feita, nas condições e no estado-da-arte atuais, e a um custo razoável;

Bem definido:Bem definido:Bem definido:Bem definido: a definição deve procurar ser objetiva e o mais completa

possível, não necessitando de informações adicionais para ser entendida;

Não ambíguo:Não ambíguo:Não ambíguo:Não ambíguo: muitos documentos de requisitos são escritos emlinguagem natural, que é inerentemente ambígua; nesses casos deve-se

utilizar também um glossário ou incluir o Léxico Ampliado da Linguagem na

baseline de requisitos, possibilitando a todos os envolvidos o mesmo

entendimento;

Consistente:Consistente:Consistente:Consistente: ele não deve estar em conflito ou contradição com outros

requisitos. Cada requisito deve ser consistente com todos os demais

requisitos na especificação; a consistência também deve existir entre os

vários níveis de abstração, se é utilizada a decomposição de requisitos em

níveis;


12/32

12

UnicidadeUnicidadeUnicidadeUnicidade: não deve haver duplicidade de requisitos, ou seja, não

devem existir vários requisitos correspondendo a uma mesma característica

ou funcionalidade;

Verificável/mensurável:Verificável/mensurável:Verificável/mensurável:Verificável/mensurável: deve ser possível, após o sistema estar

codificado, verificar se o requisito foi atendido (está presente no sistema) e

se a implementação está correta. Isto é particularmente importante para

requisitos não funcionais, como por exemplo desempenho, dado que é

relativamente comum encontrar definições do tipo "o tempo de resposta

deve ser adequado" ou "o usuário não deve ficar aguardando muito tempo

pela informação solicitada";

Categorizado:Categorizado:Categorizado:Categorizado: deve estar explicitamente indicado a categoria à qual ele

pertence, ou seja, se é requisito funcional, funcional, não funcional, inverso

ou de interface.

Os requisitos de um projeto devem estar claramente definidos,

possibilitando assim, após a fase de testes, a validação do software pelosclientes e a conclusão que os mesmos foram corretamente atendidos [SAYAO

2003].

2.32.32.32.3 Gerenciamento de RequisitosGerenciamento de RequisitosGerenciamento de RequisitosGerenciamento de Requisitos

Geralmente não há uma fronteira bem definida entre essas atividades e

algumas delas ocorrem de forma paralela. Além disso, o gerenciamento de

requisitos é uma atividade que ocorre durante todo o processo. Através do

gerenciamento, pode-se controlar a rationale (ou razão) dos requisitos,

através da evolução destes, além da possibilidade de realizar o rastreamento,


13/32

13

que é uma atividade muito importante para verificar impactos de mudanças

em requisitos consolidados [KOTONYA 1998].

Uma dos maiores impasses para a Engenharia de Requisitos é a

averiguação e a agregação de novos requisitos ao sistema. Isso acontece em

virtude do impacto das propostas de mudanças, a inflexibilidade dos

processos e a dificuldade de assessorar essas mudanças.

O processo de gerência de requisitos tem por objetivo resolver tais

problemas tendo como principais objetivos o gerenciamento das mudanças,

o gerenciamento entre requisitos relacionados e o gerenciamento das

dependências entre a documentação de requisitos e outros documentos

originados durante outros processos da engenharia de software [KOTONYA

1998].

Os requisitos só podem ser gerenciados efetivamente se existir uma

forma de rastrear esses requisitos. Um requisito é inteligível se existe algumaforma de descobrir quem sugeriu o requisito, por que o requisito existe, com

quem o requisito está relacionado e como o requisito relaciona outras

informações como implementação e documentação de usuário.

Um bom gerenciamento de requisitos deve manter informações entre

qual a relação dos requisitos levantados e os benefícios deste requisito ao

usuário.

Um modelo descreve as atividades existentes em um processo. Não

existe um único modelo de processo para a Engenharia de Requisitos, pelo

contrário, cada organização pode implantar um processo específico que


14/32

14

atenda as suas necessidades. Por outro lado podemos ter modelos de

processos definidos para determinadas áreas de domínio [KOTONYA 1998].


15/32

15

3333 ValidaçãoValidaçãoValidaçãoValidação de Requisitosde Requisitosde Requisitosde Requisitos

Todas as atividades relativas à Engenharia de Requisitos são

fundamentais para o desenvolvimento de documentos e software que

atendam essencialmente as necessidades e restrições dos sistemas

solicitados pelos clientes. No entanto, neste trabalho, vamos nos deter a

última atividade deste processo: a validação de requisitos validação de requisitos validação de requisitos validação de requisitos , que tem como

objetivo fundamental mostrar que os requisitos definem o sistema que o

cliente deseja.

3.13.13.13.1 Processo de Validação de RequisitosProcesso de Validação de RequisitosProcesso de Validação de RequisitosProcesso de Validação de Requisitos

A Validação de Requisitos tem o objetivo de apresentar os requisitos

que definem o sistema e realizar a validação dos requisitos durante o

andamento das fases anteriores, uma vez que mudanças e ajustes ao final de

todo o processo significam aumento considerável de custos. Esta etapa é

apoiada pelo uso do documento de requisitos.

Deve haver uma cuidadosa avaliação dos requisitos, com ênfase em

sua consistência e completude. Nessa atividade devem-se identificar

possíveis problemas nos requisitos antes que o documento produzido sirva

de base para o desenvolvimento do sistema.

Validar os requisitos significa confirmar que o documento de requisitos

e suas especificações complementares refletem as reais necessidades dos

clientes e usuários finais, autenticando os artefatos que servirão de base

para as fases subseqüentes do processo de desenvolvimento. De acordo com

Kotonya [KOTONYA 1998], cuidadosas checagens deverão ser realizadas nos


16/32

16

requisitos para garantir consistência e integralidade. Em geral, a validação

deve criar os meios necessários para que ocorra um consenso entre as partes

envolvidas no projeto, geralmente com objetivos conflitantes.

Segundo Loucopoulus [LOUCOPOULUS 1995], o processo de validação

de requisitos é definido como a atividade na qual certifica que o documento

de requisitos é consistente com as necessidades dos usuários. Descrever os

requisitos de forma explícita é uma condição necessária não somente para

validar os requisitos mas também para resolver conflitos entre usuários.

De acordo com Sommerville [SOMMERVILLE 2003], é necessário que

exista validade na identificação de funções que são exigidas para atender aos

diversos usuários do sistema; consistência para verificar se os requisitos não

possuem descrições diferentes para uma mesma função no sistema;

completeza para incluir todas as funções e restrições solicitadas pelo cliente;

realismo sob ótica da tecnologia para que seja assegurada a implementação

e facilidade de verificação para que possam existir verificações queminimizem possíveis divergências entre cliente e fornecedor.

Em geral, a validação de requisitos é considerada uma atividade

complicada por dois principais motivos. Inicialmente, a própria natureza

filosófica desse processo, onde é levado em consideração o que é verdadeiro,

permite que muitos pesquisadores comparem a validação de requisitos com

o problema de validação do conhecimento científico [NUSEIBEH 2000]. O

segundo motivo é social e está relacionado com a dificuldade de obter um

consenso entre diferentes usuários com objetivos conflitantes [LAMSWEERDE

1998].


17/32

17

É certo que a validação de requisitos pode requerer várias sessões de

trabalho até que todos encontrem não somente pontos de concordância a

respeito dos requisitos, mas principalmente visualizem as implicações

futuras de suas decisões. Nesse sentido, a participação de especialistas de

domínio contribui sobremaneira para a orientação de clientes, usuários e

desenvolvedores na resolução de possíveis impasses.

A visão da atividade de validação retrata um processo contínuo,

ocorrendo na maior parte do tempo em paralelo com as fases de elicitação e

especificação (análise, negociação e documentação). De fato, a validação não

é só aplicada ao modelo final de requisitos, mas também a todos os modelos

intermediários gerados ao longo do processo de requisitos.

A validação de requisitos é um dos mais importantes na Engenharia de

Requisitos. Isto porque tal como um documento de requisitos bem definido

permite a correção de incoerências e inconformidades no desenvolvimento

de um produto de software, a validação permite minimizar o tempo gasto nadetecção dessas incoerências e inconformidades devido à sua alta eficiência

na descoberta. Também porque como é este processo que permite a

identificação destas mesmas incoerências na fase anterior à versão final do

relatório de requisitos, minimiza grandemente o risco de encontrar estas

incoerências numa fase tardia, ou até mesmo na terminação, do

desenvolvimento do sistema. É fácil entender que um erro encontrado numa

fase tardia do desenvolvimento do projeto pode ser desastroso, pois a sua

alteração poderá ser bastante custosa, se não incomportável, em termos

temporais [WIKIPEDIA 2007].


18/32

18

Fazendo uma analogia, a validação de requisitos está para o

documento de requisitos assim como a fase de testes unitários e de sistema

está para a fase de desenvolvimento de um projeto de software.

Outro grande desafio durante a validação de requisitos é demonstrar

que a especificação dos requisitos do sistema está correta. Enquanto o

projeto e a implementação possuem o documento de requisitos para verificar

seus resultados, a validação de requisitos não possui nenhuma outra

representação que pode ser usada como base. Ou seja, não existe uma forma

para demonstrar formalmente que a especificação está correta [KOTONYA

1998].

Alguns problemas, muitas vezes, só são detectados durante a

Validação de Requisitos. Dentre eles podemos citar:

• Falta de conformidade com padrões de qualidade;

•

Requisitos ambíguos;• Erros em modelos do sistema ou do problema;

• Conflitos entre requisitos não detectados durante a análise.

Esses problemas devem ser solucionados antes da aprovação do

documento de requisitos e usado como base para o desenvolvimento do

sistema. Em muitos casos, os problemas serão simplesmente problemas de

documentação e podem ser corrigidos para melhorar a descrição dos

requisitos. Em outros casos, os problemas resultam de falhas na elicitação,

análise e modelagem de requisitos [KOTONYA 1998].


19/32

19

O principal problema da validação de requisitos é que não existe um

documento que pode ser base para a validação. Um projeto ou um programa

pode ser validado de acordo com a especificação. Por outro lado, não há uma

maneira de demonstrar que uma especificação de requisitos esteja correta

com respeito a alguma outra representação do sistema.

A Figura 2 apresenta as entradas e saídas do Processo de Validação de

Requisitos [KOTONYA 1998].

FiguraFiguraFiguraFigura 2222 –––– Entradas e Saídas do Processo de Validação de RequisitosEntradas e Saídas do Processo de Validação de RequisitosEntradas e Saídas do Processo de Validação de RequisitosEntradas e Saídas do Processo de Validação de Requisitos

• EntradasEntradasEntradasEntradas

o DocumDocumDocumDocumento de Requisitos (Requirements Document)ento de Requisitos (Requirements Document)ento de Requisitos (Requirements Document)ento de Requisitos (Requirements Document) – Deve ser

uma versão completa do documento ao invés de um rascunho

não finalizado. Deve estar formatado e organizado de acordo

com padrões organizacionais.

o Padrões Organizacionais (Organisational Knowledge)Padrões Organizacionais (Organisational Knowledge)Padrões Organizacionais (Organisational Knowledge)Padrões Organizacionais (Organisational Knowledge) – O

processo de validação de requisitos deve verificar a

conformidade em relação a padrões organizacionais. Todos


20/32

20

padrões relevantes para o documento de requisitos deve ser

entrada para o processo de validação.

o Conhecimento Organizacional (Organisational StanConhecimento Organizacional (Organisational StanConhecimento Organizacional (Organisational StanConhecimento Organizacional (Organisational Standards)dards)dards)dards) –––– Não é

uma entrada tangível, mas, na prática, é muito importante. As

pessoas envolvidas na validação de requisitos podem conhecer a

organização, sua terminologia particular e suas práticas e o

perfil das pessoas envolvidas no desenvolvimento e uso do

sistema.

• SaídasSaídasSaídasSaídas

o Lista de Problemas (Lista de Problemas (Lista de Problemas (Lista de Problemas (ListListListList of Problems)of Problems)of Problems)of Problems) – Lista de problemas com o

documento de requisitos. Idealmente, deve ser organizada por

tipo de problema (ambigüidade, incompletude, etc). Na prática é

difícil classificar problemas dessa maneira.

o Ações Acordadas (Agreed Actions)Ações Acordadas (Agreed Actions)Ações Acordadas (Agreed Actions)Ações Acordadas (Agreed Actions) )))) – Lista de ações em

resposta a problemas com requisitos que devem ser aceita em

comum acordo por aqueles envolvidos no processo de validação.

Não é necessário haver uma correspondência 1:1 entre

problemas e ações.

Há sempre uma tendência natural de tornar mais rápido o processo de

validação para se começar a fase de implementação. Esse tipo de

pensamento acontece especialmente quando os prazos estão curtos. Por


21/32

21

outro lado, esse procedimento pode ser danoso, pois qualquer atropelo

poderá incorrer em fases de revisão e re-análise, aumentando as métricas e

o tempo do processo.

3.23.23.23.2 Técnicas de Validação de RequisitosTécnicas de Validação de RequisitosTécnicas de Validação de RequisitosTécnicas de Validação de Requisitos

Existe uma variedade de técnicas que podem ser aplicadas para apoiar

o processo de validação. Dentre elas podemos destacar:

3.2.13.2.13.2.13.2.1 Revisão de RequisitosRevisão de RequisitosRevisão de RequisitosRevisão de Requisitos

Segundo Naddeo [NADDEO 2002], a principal técnica utilizada na

validação de requisitos é basicamente aquela utilizada também em outras

atividades do processo de software: revisões. Revisões envolvem um grupo

de pessoas lendo e analisando a documentação de requisitos à procura de

possíveis problemas. A revisão de requisitos constitui-se de uma reunião

formal na qual um engenheiro de requisitos apresenta cada um dos

requisitos para crítica e identificação de inconsistências pelo grupo. As

inconsistências encontradas são registradas para posterior discussão. O

grupo de revisão deve então tomar decisões que se materializam em ações a

serem executadas para corrigir os problemas identificados [WIKIPEDIA 2007].

Apesar de se ter pouco publicado sobre revisão de requisitos e como

essa deve ser conduzida, tem-se evidencia que a inspeção de programas são

eficientes para a descoberta de problemas com código e várias formas de se

organizar os processos de inspeção do programa foram propostas [SANTOS

2007]

A Figura 3 representa um processo de revisão de requisitos.


22/32

22

FiguraFiguraFiguraFigura 3333 –––– Processo de Revisão de RequisitosProcesso de Revisão de RequisitosProcesso de Revisão de RequisitosProcesso de Revisão de Requisitos

Os principais estágios no processo de revisão de requisitos são

descritos da seguinte forma [KOTONYA 1998]:

• Revisão de PlanoRevisão de PlanoRevisão de PlanoRevisão de Plano – a equipe de revisão é selecionada, assim como um

local para reunião.

• Distribuição de documentosDistribuição de documentosDistribuição de documentosDistribuição de documentos – os documentos de requisitos e outros

documentos relevantes são distribuídos para os membros da equipe de

revisão.

• Preparação para RevisãoPreparação para RevisãoPreparação para RevisãoPreparação para Revisão – os Revisores lêem os documentos de

requerimento e identificam conflitos, omissões, inconsistências,

desvios dos padrões e outros problemas derivados.


23/32

23

• Reunião de RevisãoReunião de RevisãoReunião de RevisãoReunião de Revisão – os comentários individuais e os problemas são

discutidos e uma série de ações estabelecidas para sanar os

problemas.

• Atividades FollowAtividades FollowAtividades FollowAtividades Follow----upupupup – Os responsáveis pela revisão averiguam se as

ações foram postas em prática para solucionar tais problemas

elencados.

• Revisão de documentosRevisão de documentosRevisão de documentosRevisão de documentos – os documentos são revistos para refletir

sobre as ações acordadas. Nesse ponto, os requisitos podem ser

aceitos ou simplesmente solicitada uma nova revisão.

A Revisão de Requisitos deve ser conduzida por alguém que não esteve

envolvido produzindo os requisitos que estão sendo validados. Durante o

encontro, um membro do grupo deve fazer a ata dos requisitos conflitantes.

Na inspeção do programa, é uma prática comum reportar os erros paraa equipe responsável pela programação. Todavia, é a equipe de revisão que

decide que ações ou mudanças devem ser tomadas na correção dos erros.

Diferentemente dos erros de programação, tais problemas requerem

discussão e negociação para se chegar a um denominador comum. As ações

devem compreender o seguinte [KOTONYA 1998]:

• Clarificação dos reqClarificação dos reqClarificação dos reqClarificação dos requisitosuisitosuisitosuisitos – os requisitos podem estar expressos

inadequadamente ou podem ter sido omitidos acidentalmente. Nesse

ponto, deve-se buscar reescreve-los.


24/32

24

• Informação nãoInformação nãoInformação nãoInformação não----relacionadarelacionadarelacionadarelacionada – algumas informações podem faltar no

documento de revisão. É responsabilidade dos engenheiros executar a

revisão dos documentos para descobrir quaisquer incongruências dos

documentos, seja dos stakeholders do sistema, seja de outras fontes.

• Conflito de requisitosConflito de requisitosConflito de requisitosConflito de requisitos – Conflitos devem ser negociados entre

stakeholders e a equipe.

• RequRequRequRequisitos não realistasisitos não realistasisitos não realistasisitos não realistas – às vezes alguns requisitos requerem uma

tecnologia não disponível para aquele sistema. Desse modo, os

stakeholders devem ser consultados sobre a modificação ou exclusão

de tais requisitos para andamento do sistema.

3.2.1.13.2.1.13.2.1.13.2.1.1 Checklist para RChecklist para RChecklist para RChecklist para Revisãoevisãoevisãoevisão

O uso de checklists que caracterizam e descrevem os erros

frequentemente são usados no processo de inspeção. Essa abordagem

funciona bem tanto na validação quanto na programação.

Essa técnica revela-se produtiva nas empresas e recomenda-se o

desenvolvimento de um conjunto de perguntas-padrão para o contexto em

tela, conforme observamos na Tabela 1 [KOTONYA 1998].

TabelaTabelaTabelaTabela 1111 –––– Atributos de qualidade do requisitosAtributos de qualidade do requisitosAtributos de qualidade do requisitosAtributos de qualidade do requisitos

Atributo de qualidadeAtributo de qualidadeAtributo de qualidadeAtributo de qualidade DescriçãoDescriçãoDescriçãoDescrição

Compreensibilidade

Os leitores do documento podem compreender o que os requisitos

significam? Esse é provavelmente o mais importante atributo do

documento de requisitos – se ele não pode ser compreendido, os


25/32

25

requisitos não podem ser validados.

Redundância

Há alguma informação desnecessariamente repetida? Algumas

vezes a redundância melhora a compreensão. Deve haver um

equilíbrio em remover toda a redundância e tornar o documento

de difícil compreensão.Completude

O revisor tem conhecimento de algum requisito falante ou de

alguma informação falante na descrição dos requisitos?

Ambigüidade

Os requisitos são expressos utilizando termos claramente

definidos? Leitores com diferente graus de conhecimento podem

ter diferentes interpretações dos requisitos?

Consistência

As descrições de diferentes requisitos possuem contradições? Há

contradições entre requisitos individuais ou nos requisitos gerais

do sistema?

Organização

O documento está estruturado da maneira apropriada? As

descrições dos requisitos estão agrupadas de forma que requisitos

relacionados estão agrupados? Poderia ser utilizada uma outraestrutura de mais fácil entendimento?

Conformidade a

padrões

O documento e os requisitos individuais estão de acordo com os

padrões definidos? Se existem divergências em relação a padrões,

as mesmas possuem justificativa?

Rastreabilidade

Os requisitos são identificados de maneira não-ambígua, incluindo

ligações com requisitos relacionados e com as razões que

justificam a inclusão do requisito?

3.2.23.2.23.2.23.2.2

PrototipaçãoPrototipaçãoPrototipaçãoPrototipação

É a simulação das telas de uma aplicação a qual permite ao usuário

visualizar a aplicação que ainda não foi produzida.

Se um protótipo foi desenvolvido para fins de elicitação de requisitos,

faz sentido usá-lo posteriormente para a validação desses requisitos. Porém,

protótipos para validação devem ser mais completos e conter requisitos

suficientes para garantir que facilidades projetadas para o sistema estejam

de acordo com o uso prático esperado por seus usuários. Protótipos de

elicitação normalmente apresentam funcionalidades ausentes e podem não

contemplar mudanças acordadas durante o processo de análise dos


26/32

26

requisitos. É, portanto, necessário dar continuidade ao desenvolvimento do

protótipo durante a etapa de validação [KOTONYA 1998].

É usualmente mais fácil para os stakeholders conseguirem identificar

exatamente o que querem de uma forma visual e aproximada do que poderá

ser o produto final. Dessa forma, através do protótipo visual é mais fácil

detectar inconsistências e problemas nos requisitos.

Melhorias na comunicação entre usuários e desenvolvedores são

frequentemente vistas com a implantação da prototipação.

Devem-se notar pequenas desvantagens na utilização desta técnica:

• A implementação de um prototipo poderá levar a desilusões para os

utilizadores finais, quando as interfaces da versão final não

correspondem exatamente às do protótipo.

• Também se deverá ter em conta o tempo gasto na implementação do

protótipo e medir se este tempo no final será compensado pelasvantagens trazidas.

• Projetistas e usuários podem focar-se demais no projeto da interface e

pouco na produção de um sistema que atenda as necessidades do

processo de negócio.

A Figura 4 apresenta o processo de validação de requisitos por

prototipação [KOTONYA 1998].


27/32

27

FiguraFiguraFiguraFigura 4444 –––– Validação de Requisitos por PrototipaçãoValidação de Requisitos por PrototipaçãoValidação de Requisitos por PrototipaçãoValidação de Requisitos por Prototipação

As atividades visualizadas na Figura 4 são detalhadas abaixo:

• Escolha dos testadores de prototipaçãoEscolha dos testadores de prototipaçãoEscolha dos testadores de prototipaçãoEscolha dos testadores de prototipação – a escolha dessa equipe é

fundamental, pois deverá se relacionar com os usuários finais do

sistema. Os melhores testadores são usuários que não estão bem

familiarizados com o sistema ou que apenas estão abertos a descobrir

um sistema novo.

• Desenvolvimento de cenários de testeDesenvolvimento de cenários de testeDesenvolvimento de cenários de testeDesenvolvimento de cenários de teste – a prototipação deve ocorrer de

forma sistemática. Isso requer planejamento para elaboração de

cenários. Cobrindo assim todas as possibilidades de situações partindo

dos requisitos.

• Execução de cenáriosExecução de cenáriosExecução de cenáriosExecução de cenários – os usuários do sistema geralmente trabalham

por conta própria executando os cenários planejados. Essa perspectiva

é a melhor, pois usando o sistema por conta própria leva o usuário a

uma situação mais realista.

• Problemas de documentaçãoProblemas de documentaçãoProblemas de documentaçãoProblemas de documentação – todos os problemas encontrados devem

ser cuidadosamente documentados para analise posterior. O ideal é

definir um template padrão eletrônico para constantemente atualizar

os erros e sugerir mudanças no sistema.

3.2.33.2.33.2.33.2.3 Testes de RequisitosTestes de RequisitosTestes de RequisitosTestes de Requisitos

Nesta técnica, cada requisito funcional no documento de requisitos

deve ser analisado e um teste deve ser definido que possa objetivamente


28/32

28

averiguar se o sistema satisfaz o requisito. O objetivo dos casos de teste

propostos para requisitos é validar o requisito e não o sistema. Para definir

casos de teste para um requisito, devem-se fazer as seguintes perguntas

[KOTONYA 1998]:

• Que cenário deve ser usado para averiguar o requisito? Isso definirá o

contexto onde será aplicado.

• O requisito por si só inclui informação suficiente para permitir um

teste ser definido? Se não, que outros requisitos devem ser

examinados para encontrar essa informação?

• É possível checar o requisito usando um teste único ou testes

múltiplos?

• O requisito pode ser re-escrito de modo que os testes tornem-se mais

óbvios?

Uma tabela de registro de teste deve ser projetada e preenchida com a

informação necessária, de cada item testado, incluindo a seguinteinformação:

• Identificador de requisitos – um por cada requisito

• Requisitos relacionados

• Descrição do teste

• Problemas de Requisitos

• Comentários e Recomendações

A Figura 5 apresenta um modelo de formulário de teste de requisitos.


29/32

29

FiguraFiguraFiguraFigura 5555 –––– Formulário de Teste de RequisitosFormulário de Teste de RequisitosFormulário de Teste de RequisitosFormulário de Teste de Requisitos


30/32

30

4444 Considerações FinaisConsiderações FinaisConsiderações FinaisConsiderações Finais

Com o decorrer do tempo, as empresas tornam-se mais dependentes

dos seus sistemas de informação. A construção desses sistemas em tempo

hábil, com qualidade e menores custos é o desafio que todos os

desenvolvedores têm enfrentado.

Para que as empresas conquistem os níveis competitivos exigidos pelo

mercado, não basta apenas a utilização de ferramentas isoladas para

melhoria da qualidade e/ou produtividade. É necessária a estruturação da

empresa por meio de um sistema gerencial que coordene o uso das técnicas

e ferramentas disponíveis e garanta condições necessárias ao planejamento,

controle e melhorias de cada um dos processos.

Instituições que implementam processos de engenharia de requisitos

obtém grandes benefícios. O maior deles talvez seja a redução do re-

trabalho durante os estágios seguintes do processo de desenvolvimento e

durante toda a fase de manutenção do software.

É nesse sentido que a atividade de Validação de Requisitos torna-se

mais um meio de garantir documentos de requisitos com qualidade e que

venham a gerar produtos condizentes com as necessidades de seus clientes

e usuários, através do uso de técnicas como as descritas neste trabalho.


31/32

31

ReferênciasReferênciasReferênciasReferências BibliográficasBibliográficasBibliográficasBibliográficas

[ESPINDOLA 2004] Espindola, R., Majdenbaum, A. e Audy, J., Uma AnáliseUma AnáliseUma AnáliseUma Análise

Crítica dos Desafios para Engenharia deCrítica dos Desafios para Engenharia deCrítica dos Desafios para Engenharia deCrítica dos Desafios para Engenharia de Requisitos em Manutenção deRequisitos em Manutenção deRequisitos em Manutenção deRequisitos em Manutenção deSoftwareSoftwareSoftwareSoftware.... Faculdade de Informática, PUC-RS, 2004.

[GENVIGIR 2005] Genvigir, E., Sant’Anna, N., Borrego, L. e Cereja, M., UmaUmaUmaUma

Abordagem para os Processos da Engenharia de RequisitosAbordagem para os Processos da Engenharia de RequisitosAbordagem para os Processos da Engenharia de RequisitosAbordagem para os Processos da Engenharia de Requisitos. INPE – Instituto

Nacional de Pesquisas Espaciais, 2005.

[GOMES 2005] GOMES, M., Um Processo de Avaliação da PortabilidadUm Processo de Avaliação da PortabilidadUm Processo de Avaliação da PortabilidadUm Processo de Avaliação da Portabilidade dee dee dee de

Unidades deUnidades deUnidades deUnidades de Software.Software.Software.Software. Centro de Informática, Universidade Federal dePernambuco, 2005....

[IBM 2004] IBM Corporation. The Business value of Software QualityThe Business value of Software QualityThe Business value of Software QualityThe Business value of Software Quality – A

technical discussion of software quality. 2004.

[LAMSWEERDE 1998] Lamsweerde, A., Darimont, R. e Letier, E., ManagingManagingManagingManaging

Conflicts in GoalConflicts in GoalConflicts in GoalConflicts in Goal----Driven Requirements EngineeringDriven Requirements EngineeringDriven Requirements EngineeringDriven Requirements Engineering. IEEE Transactions on

Software Engineering, Special Issue on Managing Inconsistency in Software

Development. Nov. 1998.

[LOUCOPOULOS 1995] Loucopoulos, P. e Kavakli, V., EnterpriseEnterpriseEnterpriseEnterprise ModellingModellingModellingModelling

and Teleological Approach to Requirements Engineeringand Teleological Approach to Requirements Engineeringand Teleological Approach to Requirements Engineeringand Teleological Approach to Requirements Engineering, International

Journal of Intelligent and Cooperative Information Systems, 1995.

[KOTONYA 1998] Kotonya, G., Sommerville, I., Requirements Engineering:Requirements Engineering:Requirements Engineering:Requirements Engineering:

Processes and TechniquesProcesses and TechniquesProcesses and TechniquesProcesses and Techniques. John Willey & Sons Ltd, 1998.

[PAIM 2003] Paim, F., Uma Metodologia para Definição de Requisitos emUma Metodologia para Definição de Requisitos emUma Metodologia para Definição de Requisitos emUma Metodologia para Definição de Requisitos em

Sistemas Data Warehouse.Sistemas Data Warehouse.Sistemas Data Warehouse.Sistemas Data Warehouse. Dissertação de Mestrado, Centro de Informática,

UFPE, 2003


32/32

[NADDEO 2002] Naddeo, P., Uma Taxonomia na Área de Engenharia deUma Taxonomia na Área de Engenharia deUma Taxonomia na Área de Engenharia deUma Taxonomia na Área de Engenharia de

RequisitosRequisitosRequisitosRequisitos. Dissertação de Mestrado, Instituto de Matemática e Estatística da

Universidade de São Paulo. São Paulo, SP, 2002.

[NUSEIBEH 2000] Nuseibeh, B. e Easterbrook, S., Requirements Engineering: ARequirements Engineering: ARequirements Engineering: ARequirements Engineering: A

RoadmapRoadmapRoadmapRoadmap. The Future of Software Engineering, Anthony Finkelstein, ACM

Press, 2000

[SANTOS 2007] Santos, M.,.,.,., Estudo Comparativo dos Processos Utilizados nEstudo Comparativo dos Processos Utilizados nEstudo Comparativo dos Processos Utilizados nEstudo Comparativo dos Processos Utilizados naaaa

Engenharia de Requisitos.Engenharia de Requisitos.Engenharia de Requisitos.Engenharia de Requisitos. Escola Politécnica, USP, São Paulo, 2007.

[SAYAO 2003] Sayao, M., Staa, A., Leite, J., Qualidade em RequisitosQualidade em RequisitosQualidade em RequisitosQualidade em Requisitos,

Monografia em Ciência da Computação, Departamento de Informática, PUC-

Rio, 2003.

[SOARES 2005] Soares, A., Introdução, Identificação e Análise em EngenhariaIntrodução, Identificação e Análise em EngenhariaIntrodução, Identificação e Análise em EngenhariaIntrodução, Identificação e Análise em Engenhariade Requisitosde Requisitosde Requisitosde Requisitos, 2005.

[SOMMERVILLE 2003] Sommerville, I., Engenharia de SoftwareEngenharia de SoftwareEngenharia de SoftwareEngenharia de Software. 6ª Edição,

Makron Books, 2003

[THAYER 1993] Thayer, R., Dorfman, M., Software Requirements EngineeringSoftware Requirements EngineeringSoftware Requirements EngineeringSoftware Requirements Engineering,

IEEE Computer Society Press, 1993.

[WIKIPEDIA 2007] Validação de RequisitosValidação de RequisitosValidação de RequisitosValidação de Requisitos. Disponível em:

http://pt wikipedia org/wiki/Valida%C3%A7%C3%A3o de requisitos 2007

validação de requisitos no contexto da engenharia de software

Documents