Date post: | 06-Jul-2018 |
Category: |
Documents |
Upload: | mayk-campelo |
View: | 220 times |
Download: | 0 times |
of 32
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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;
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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;
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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,
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
14/32
14
atenda as suas necessidades. Por outro lado podemos ter modelos de
processos definidos para determinadas áreas de domínio [KOTONYA 1998].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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].
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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.
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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
8/17/2019 VALIDAÇÃO DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE
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