IN1020 – Engenharia de Requisitos

2. IN1020 – Engenharia de Requisitos Um Estudo Sobre a Validação de Requisitos no Contexto da Engenharia de Software Por: Alberto Lima albertorlima@gmail.com

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

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

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

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

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

8. Processo de Engenharia de Requisitos • 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.

9. Processo de Engenharia de Requisitos • 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.

10. Processo de Engenharia de Requisitos • Atividades do Processo • Elicitação de Requisitos • Análise e Negociação de Requisitos • Documentação de Requisitos • Validação de Requisitos

11. Processo de Engenharia de Requisitos • Atividades do Processo • 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].

12. Processo de Engenharia de Requisitos • Atividades do Processo • 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.

13. Processo de Engenharia de Requisitos • Atividades do Processo • 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].

14. Processo de Engenharia de Requisitos • Atividades do Processo • 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.

15. Processo de Engenharia de Requisitos • Atividades do Processo • 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.

16. Validação de Requisitos

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

18. Validação de Requisitos • 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.

19. Validação de Requisitos • Em geral, a validação de requisitos é considerada uma atividade complicada por dois principais motivos: • 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. • Social e está relacionado com a dificuldade de obter um consenso entre diferentes usuários com objetivos conflitantes.

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

21. Validação de Requisitos • 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.

22. Validação de Requisitos • 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].

23. Validação de Requisitos • 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.

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

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

26. Validação de Requisitos • 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.

27. Validação de Requisitos • 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.

28. Té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: • Revisão de Requisitos • Prototipação • Testes de Requisitos

29. Técnicas de Validação de Requisitos • Revisão 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.

30. Técnicas de Validação de Requisitos • Revisão de Requisitos • Processo de Revisão de Requisitos [KOTONYA 1998]

31. Técnicas de Validação de Requisitos • 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.

32. Técnicas de Validação de Requisitos • Revisão de Requisitos • 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.

33. Técnicas de Validação de Requisitos • 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.

34. Técnicas de Validação de Requisitos • 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.

35. Técnicas de Validação de Requisitos • Revisão de Requisitos • 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.

36. Técnicas de Validação de Requisitos • Revisão de Requisitos • Atributos de qualidade dos requisitos

37. Técnicas de Validação de 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.

38. Técnicas de Validação de Requisitos • 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.

39. Técnicas de Validação de Requisitos • 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.

40. Técnicas de Validação de Requisitos • Prototipação • Processo de validação de requisitos por prototipação

41. Técnicas de Validação de Requisitos • 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.

42. Técnicas de Validação de Requisitos • Testes de Requisitos • 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.

43. Técnicas de Validação de Requisitos • 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?

44. Testes de Requisitos 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 Técnicas de Validação de Requisitos

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

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

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

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