IN1020 – Engenharia de Requisitos

CIn/UFPE – IN1029 – Engenharia de Requisitos - Prof. Jaelson Brelaz 1


IN1020 – Engenharia de Requisitos

Um Estudo Sobre a Validação de Requisitos no

Contexto da Engenharia de Software

Por:

Alberto [email protected]


Roteiro

• Introdução Motivação

Objetivos

• Processo de Engenharia de Requisitos

• Validação de Requisitos Processo de Validação de Requisitos

Técnicas de Validação de Requisitos

• Revisão de Requisitos

• Prototipação

• Testes de Requisitos

• Considerações Finais


Motivação

• Empresas precisam buscar diferenciais para agregar valor a seus produtos e, assim, expandir seu mercado consumidor;

• Garantir a qualidade;

• Deficiências nos requisitos dos sistemas como uma das principais causas de fracassos em projetos de software;

• Papel importante da Engenharia de Requisitos;

• Validação de Requisitos contribui para a garantia da qualidade.


Objetivos

• Apresentar os principais conceitos relativos à Validação de

Requisitos;

• Estudar algumas técnicas usadas na execução desta

atividade;

• Apresentar uma visão geral do Processo de Engenharia de

Requisitos, suas atividades e relatar a importância da

Validação de Requisitos neste contexto.


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: Quais atividades são executadas; A estruturação e o cronograma delas; Quem é o responsável por cada uma das atividades; Suas entradas e saídas; As ferramentas usadas para suportar a engenharia de

requisitos.



• Entradas e saídas de um processo da Engenharia de Requisitos [KOTONYA 1998]:



• Entradas Informações Existentes do 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.

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

das necessidades das partes interessadas para apoiar seu trabalho.

Padrõ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..

Regras e Regulamentos - Normas e regulamentos externos que se

apliquem ao sistema.

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

sistema.


• Saídas Requisitos Agregados - Descrição dos requisitos

levantados, avaliados e aprovados pelas partes interessadas.

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

Modelos do Sistema - Um conjunto de modelos que descrevem o sistema a partir de diferentes perspectivas.




• Atividades do Processo

Elicitação de Requisitos Análise e Negociação de Requisitos Documentação de Requisitos Validação de Requisitos




Elicitaçã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 de 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 Requisitos• 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 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].

• 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.




Gerenciamento de Requisitos• É uma atividade que ocorre durante todo o processo.

• Controlar a rationale (ou razão) dos requisitos, através da evolução destes, além da possibilidade de realizar o rastreamento, que é uma atividade muito importante para verificar impactos de mudanças em requisitos consolidados [KOTONYA 1998].

• Tem como objetivo 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.

• Manter informações entre qual a relação dos requisitos levantados e os benefícios deste requisito ao usuário.


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.

• Etapa apoiada pelo uso do documento de requisitos.

• Cuidadosa avaliação dos requisitos, com ênfase em sua consistência e completude.

• Identificar possíveis problemas nos requisitos antes que o documento produzido sirva de base para o desenvolvimento do sistema.

• A validação deve criar os meios necessários para que ocorra um consenso entre as partes envolvidas no projeto, geralmente com objetivos conflitantes.



• 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.

Completude para incluir todas as funções e restrições solicitadas pelo cliente.

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

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



• Em geral, a validação de requisitos é considerada uma atividade complicada por dois principais motivos:

1. A própria natureza filosófica do 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.

2. Social e está relacionado com a dificuldade de obter um consenso entre diferentes usuários com objetivos conflitantes.



• 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. 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.



• 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 na detecção dessas incoerências e inconformidades devido à sua alta eficiência na descoberta.

• Minimiza bastante o risco de encontrar estas incoerências numa fase tardia, ou até mesmo no término do desenvolvimento do sistema.

• Um erro encontrado numa fase tardia do desenvolvimento do projeto pode ser desastroso, pois a sua alteração poderá ser bastante custosa.



• 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.

• 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.



• Entradas e saídas no Processo de Validação de Requisitos



• Entradas Documento 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.

Padrões Organizacionais (Organisational Standards) – O processo de validação de requisitos deve verificar a conformidade em relação a padrões organizacionais.

Conhecimento Organizacional (Organisational Knowledge) – 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ídas Lista de Problemas (List 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.

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 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.



• Existe uma variedade de técnicas que podem ser aplicadas para apoiar o processo de validação. Dentre elas podemos destacar:

Revisão de Requisitos

Prototipação

Testes de Requisitos




Principal técnica utilizada na validação de requisitos.

Envolve um grupo de pessoas lendo e analisando a documentação de requisitos à procura de possíveis problemas.

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.




Processo de Revisão de Requisitos [KOTONYA 1998]



• Revisão de Requisitos Os principais estágios no processo de revisão de

requisitos são descritos da seguinte forma:

• Planejamento de Revisão – a equipe de revisão é selecionada, assim como um local para reunião.

• Distribuiçã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ão – os revisores lêem os documentos de requerimento e identificam conflitos, omissões, inconsistências, desvios dos padrões e outros problemas derivados.




• Reuniã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 Follow-up – os responsáveis pela revisão averiguam se as ações foram postas em prática para solucionar tais problemas elencados.

• Revisã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.



• Revisão de Requisitos A Revisão de Requisitos deve ser conduzida por alguém

que não esteve envolvido produzindo os requisitos que estão sendo validados.

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

As ações devem compreender o seguinte:

• Clarificação dos requisitos – os requisitos podem estar expressos inadequadamente ou podem ter sido omitidos acidentalmente. Nesse ponto, deve-se buscar reescreve-los.



• Revisão de Requisitos• Informação não-relacionada – 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 requisitos – Conflitos devem ser negociados entre stakeholders e a equipe.

• Requisitos 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.




Checklist para Revisão

• Uso de checklists que caracterizam e descrevem os erros frequentemente são usados no processo de inspeção.

• Essa técnica revela-se produtiva nas empresas e recomenda-se o desenvolvimento de um conjunto de perguntas-padrão para o contexto.



• Revisão de Requisitos Atributos de qualidade dos requisitos



• Prototipaçã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.

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.



• Prototipação É 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.



• Prototipação Desvantagens na utilização da técnica:

• A implementação de um protótipo 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 pelas vantagens 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.



• Prototipação Processo de validação de requisitos por prototipação



• Prototipação Atividades

• Escolha dos testadores de prototipação – a escolha dessa equipe é fundamental, pois deverá se relacionar com os usuários finais do sistema.

• Desenvolvimento de cenários de teste – a prototipação deve ocorrer de forma sistemática. Isso requer planejamento para elaboração de cenários.

• Execução de cenários – os usuários do sistema geralmente trabalham por conta própria executando os cenários planejados.

• Problemas de documentação – todos os problemas

encontrados devem ser cuidadosamente documentados para analise posterior.




Cada requisito funcional no documento de requisitos deve ser analisado e um teste deve ser definido que possa objetivamente averiguar se o sistema satisfaz o requisito.

O objetivo dos casos de teste propostos para requisitos é validar o requisito e não o sistema.



• Testes de Requisitos 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 seguinte informação:

• Identificador de requisitos – um por cada requisito

• Requisitos relacionados• Descrição do teste• Problemas de Requisitos• Comentários e

Recomendações


Considerações Finais

• As empresas estão cada vez mais dependentes dos seus sistemas de informação.

• A construção desses sistemas em tempo hábil, com qualidade e menores custos é o desafio.

• Instituições que implementam processos de engenharia de requisitos obtém grandes benefícios. Redução do re-trabalho durante os estágios seguintes do

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


Considerações Finais

• A atividade de Validação de Requisitos torna-se mais um meio de garantir documentos de requisitos com qualidade.

• Geração de produtos condizentes com as necessidades de seus clientes e usuários.

• Através do uso de técnicas de validação.


Referências

• [ESPINDOLA 2004] Espindola, R., Majdenbaum, A. e Audy, J., Uma Análise Crítica dos Desafios para Engenharia de Requisitos em Manutenção de Software. Faculdade de Informática, PUC-RS, 2004.

• [GENVIGIR 2005] Genvigir, E., Sant’Anna, N., Borrego, L. e Cereja, M., Uma Abordagem para os Processos da Engenharia de Requisitos. INPE – Instituto Nacional de Pesquisas Espaciais, 2005.

• [GOMES 2005] GOMES, M., Um Processo de Avaliação da Portabilidade de Unidades de Software. Centro de Informática, Universidade Federal de Pernambuco, 2005.

• [IBM 2004] IBM Corporation. The Business value of Software Quality – A technical discussion of software quality. 2004.

• [LAMSWEERDE 1998] Lamsweerde, A., Darimont, R. e Letier, E., Managing Conflicts in Goal-Driven Requirements Engineering. IEEE Transactions on Software Engineering, Special Issue on Managing Inconsistency in Software Development. Nov. 1998.

• [LOUCOPOULOS 1995] Loucopoulos, P. e Kavakli, V., Enterprise Modelling and Teleological Approach to Requirements Engineering, International Journal of Intelligent and Cooperative Information Systems, 1995.

• [KOTONYA 1998] Kotonya, G., Sommerville, I., Requirements Engineering: Processes and Techniques. John Willey & Sons Ltd, 1998.

• [PAIM 2003] Paim, F., Uma Metodologia para Definição de Requisitos em Sistemas Data Warehouse. Dissertação de Mestrado, Centro de Informática, UFPE, 2003


Referências

• [NADDEO 2002] Naddeo, P., Uma Taxonomia na Área de Engenharia de Requisitos. 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: A Roadmap. The Future of Software Engineering, Anthony Finkelstein, ACM Press, 2000

• [SANTOS 2007] Santos, M., Estudo Comparativo dos Processos Utilizados na• Engenharia de Requisitos. Escola Politécnica, USP, São Paulo, 2007.

• [SAYAO 2003] Sayao, M., Staa, A., Leite, J., Qualidade 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 Engenharia de Requisitos, 2005.

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

• [THAYER 1993] Thayer, R., Dorfman, M., Software Requirements Engineering, IEEE Computer Society Press, 1993.

• [WIKIPEDIA 2007] Validação de Requisitos. Disponível em: http://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos , 2007.

IN1020 – Engenharia de Requisitos

Documents

Transcript of IN1020 – Engenharia de Requisitos