Adaptado a partir de Gerald Kotonya and Ian Sommerville

1. Análise e Concepção de Sistemas de Informação Engenharia de Requisitos Adaptado a partir de Gerald Kotonya and Ian Sommerville Carla Ferreira carla.ferreira@dei.ist.utl.pt

2. Engenharia de Requisitos • Introdução • Requisitos • Requisitos Funcionais • Requisitos Não-Funcionais • Problemas • Métricas • Documento de Requisitos • Exemplo • Processo de Engª de Requisitos • Actividades Gerais • Modelo Espiral • Maturidade do Processo • Melhoria do Processo de Eng.ª de Requisitos • Levantamento e Análise de Requisitos • Questionários, Análise de Documentos, ... • Selecção de Técnicas de Levantamento • Exemplo • Análise de Requisitos • Lista de Verificações • Matrizes de Interacção • Negociação de Requisitos

3. FAQS sobre Requisitos (1/2) • O que é um requisito? • Uma condição sobre um serviço ou restrição de um sistema • O que é engª de requisitos? • O processo que envolve o desenvolvimento de requisitos de sistema • Quanto custa a engª de requisitos • Cerca de 15% do custo de desenvolvimento do sistema • O que é um processo de engª de requisitos? • Um conjunto estruturado de actividades que envolve o desenvolvimento de requisitos de sistema

4. FAQS sobre Requisitos (2/2) • O que acontece qdo os requisitos estão errados? • Os sistemas são entregues atrasados, sem qualidade e sem responder às necessidades dos clientes. • Existe algum processo de engª de requisitos ideal? • Não! O processo tem de ser configurada às necessidades de cada organização. • O que é um documento de requisitos? • É a definição formal dos requisitos de um sistema • Quem são os stakeholders de um sistema? • Qualquer pessoa afectada de alguma forma pelo sistema.

5. Req. Funcionais vs. Req. Não-Funcionais • Um requisito funcional está relacionado com um processo/funcionalidade que o sistema deve executar ou com informação que o sistema deve manter. • Um requisito não-funcional está relacionado com as propriedades comportamentais que o sistema deve ter: • Definem qualidades globais ou atributos do sistema

6. Requisitos Funcionais* * Systems analysis and design with UML

7. Requisitos Não-Funcionais* * Systems analysis and design with UML

8. Classificação de RNFs (1/2) Segundo o IEEE-Std 830 – 1993 • Requisitos de desempenho • Requisitos de interface • Requisitos operacionais • Requisitos de recursos • Requisitos de verificação • Requisitos de aceitação • Requisitos de documentação • Requisitos de segurança • Requisitos de portabilidade • Requisitos de qualidade • Requisitos de fiabilidade • Requisitos de manutenção • Requisitos de integridade (safety)

9. Classificação de RNFs (2/2) Segundo G. Kotonya e I. Sommerville

10. Problemas associados aos requisitos • Os requisitos não reflectem as necessidades reais do cliente • Os requisitos são inconsistentes e/ou incompletos • É caro fazer alterações aos requisitos depois destes terem sido acordados • Dificuldade de comunicação e compreensão entre clientes, analistas dos requisitos, e engs que desenvolvem e mantêm o software

11. Exercício Explicar os problemas que poderiam surgir nos seguintes requisitos da especificação de um sistema de gestão de uma biblioteca • O sistema deve providenciar uma interface gráfica fácil de usar (easy-to-use)baseada em MS Windows XP • Utilizadores acreditados devem ter acesso privilegiado aos mecanismos do catálogo do sistema • O sistema de software deve ser implementado usando módulos separados para catalogação, acesso de utilizadores e arquivo

12. Métricas para RNFs

13. Documento de Requisitos • É um documento formal usado para registar e comunicar os requisitos dos/aos stakeholders • Descreve: • Os serviços e funções que o sistema deve providenciar • As restrições nas quais o sistema deve funcionar • Todas as propriedades do sistema, i.e., propriedades emergentes • Definições de outros sistemas, com o qual o sistema alvo deverá comunicar e ou integrar-se • Informação sobre o domínio de aplicação do sistema • Restrições sobre o(s) processo(s) usado para desenvolver o sistema • Descrição das plataformas computacionais (hardware, redes, ...) sobre as quais o sistema deverá correr

14. Utilizadores do Documento de Requisitos • Clientes do sistema • Especificam os requisitos e/ou leem-nos de para validar da sua adequação às necessidades • Gestores de projecto • Usam o doc de requisitos para planear os custos e prazos, e para planear o processo de desenvolvimento adequado • Engs de sistema • Usam os requisitos para poderem entender o sistema a desenvolver • Engs de teste do sistema • Usam os requisitos para desenvolver teste de validação • Engs de manutenção do sistema • Usam os requisitos para o melhor compreender

15. Estrutura do Documento de Requisitos • O standard IEEE/ANSI 830-1993propõe uma estrutura para docs de requisitos de software 1. Introdução 1.1 Propósito do documento de requisitos 1.2 Contexto do produto 1.3 Definições, acrónimos e abreviaturas 1.4 Referências 1.5 Visão geral do documento

16. Estrutura do Documento de Requisitos IEEE/ANSI 830-1993 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos utilizadores 2.4 Restrições gerais 2.5 Assunções e dependências 3. Requisitos específicos Envolve requisitos funcionais, não-funcionais e de interface 4. Apêndices Exemplo de um documento de requisitos

17. Exemplo • GamesInc • Rede de 50 lojas de venda de jogos para as várias consolas. • Actualmente a GamesInc tem um web site com informação básica sobre a empresa e cada uma das suas lojas (localização, horário de funcionamento, telefone). • A empresa pretende investir num novo site que permita aos seus clientes consultar informação, consultar disponibilidade de stock, reservar ou encomendar jogos através do web site.

18. Engenharia de Requisitos • Introdução • Requisitos • Requisitos Funcionais • Requisitos Não-Funcionais • Problemas • Métricas • Documento de Requisitos • Exemplo • Processo de Engª de Requisitos • Actividades Gerais • Modelo Espiral • Maturidade do Processo • Melhoria do Processo de Eng.ª de Requisitos • Levantamento e Análise de Requisitos • Questionários, Análise de Documentos, ... • Selecção de Técnicas de Levantamento • Exemplo • Análise de Requisitos • Lista de Verificações • Matrizes de Interacção • Negociação de Requisitos

19. Processo de ER inputs e outputs

20. Actividades Gerais do Processo de ER

21. Modelo Espiral para ER

22. Modelo de Maturidade do Processo de ER

23. Níveis de Maturidade do Processo de ER • Initial level • Não existe processo de ER • Apresenta os seguintes problemas: volatilidade de requisitos, insatisfação dos stakeholders,custos elevados de alterações • Muito dependente das capacidades e experiência das pessoas • Repeatable level • São definidas normas para os documentos de requisitos • São definidas normas de políticas e procedimentos para a gestão de requisitos • Defined level • O processo de ER está definido com base em boas práticas • Existe uma preocupação na melhoria activa do processo

24. Melhoria do Processo de ER Exemplos de boas práticas • Definir uma estrutura comum/normalizada do documento de requisitos • Identificar univocamente cada requisito • Definir políticas para gestão de requisitos • Usar checklists para análise de requisitos • Usar cenários para levantar requisitos • Especificar requisitos quantitativamente • Usar prototipagem para animar requisitos • Reusar requisitos

25. Engenharia de Requisitos • Introdução • Requisitos • Requisitos Funcionais • Requisitos Não-Funcionais • Problemas • Métricas • Documento de Requisitos • Exemplo • Processo de Engª de Requisitos • Actividades Gerais • Modelo Espiral • Maturidade do Processo • Melhoria do Processo de Eng.ª de Requisitos • Levantamento e Análise de Requisitos • Questionários, Análise de Documentos, ... • Selecção de Técnicas de Levantamento • Exemplo • Análise de Requisitos • Lista de Verificações • Matrizes de Interacção • Negociação de Requisitos

26. Levantamento de Requisitos Dilbert

27. Processo de ER Levantamento, análise e negociação de requisitos

28. Técnicas de levantamento de requisitos • Questionários • Análise de documentos • Entrevistas • JAD • Casos de Utilização (aula sobre Modelos Funcionais) • Etnografia • Prótotipagem

29. Planeamento de Questionários • Selecionar participantes • Elementos representativos dos stakeholders • Definir questionário • Seleção das questões • Administrar o questionário • Definir estratégias para obter um bom número de respostas • Follow-up do questionário • Enviar os resultados do questionário aos participantes

30. Análise de Documentos • Contém informação do sistema “as-is” • Documentos típicos: • Formulários • Relatórios • Manuais de procedimento • Procurar elementos adicionados aos formulários pelos utilizadores • Procurar elementos não utilizados

31. Planeamento da entrevista • Ler material de suporte • Estabelecer os objectivos da entrevista • Decidir quem entrevistar • Preparar o entrevistado • Decidir os tipos de questões e a sua estrutura

32. Types of Questions Examples Closed-Ended Questions * How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions * What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions * Why? * Can you give me an example? * Can you explain that in a bit more detail? Entrevistas * Systems analysis and design with UML

33. Estruturar Entrevistas • Estrutura em pirâmide • Começar com uma pergunta especifica, fechar com uma pergunta genérica • Usar com entrevistados relutantes • Estrutura em fúnil • Começar com uma pergunta genérica, fechar com uma pergunta especifica • Forma amigável de começara a entrevista • Usar quando os entrevistados tem uma relação efectiva com o assunto • Estrutura em diamante • Combina as aproximações anteriores, por isso demora mais tempo • Mantém o entrevistado interessado usando perguntas variadas

34. Estruturar Entrevistas Quantas devoluções de encomendas ocorrem por semana? Como é que se pode melhorar o processamento de encomendas? * Systems analysis and design with UML

35. INTERVIEW REPORT Interview notes approved by: ____________ Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes: Relatório da Entrevista * Systems analysis and design with UML

36. Joint Application Design (JAD) • Pode substituir uma série de entrevistas com a comunidade de utilizadores • Permite ao analista efectuar o levantamento de requisitos com os utilizadores

37. Quando usar JAD? • Se os utilizadores querem algo novo • Se a cultura organizacional suporta a resolução de problemas em grupo • A utilização do JAD provoca um aumento de ideias geradas • O workflow organizacional permite que empregados essenciais se ausentem para assistir às reuniões JAD

38. Quem está envolvido nas sessões JAD? • Analista • Pelo menos 1, mas deve ter um papel passivo • Utilizadores • De 8 a 12 utilizadores • Moderador • O moderador para a sessão deve ser escolhido com base no seu poder de comunicação e não deve ser o analista • Supervisor do moderador da sessão não deve pertencer ao grupo de utilizadores JAD • 1 ou 2 técnicos especializados que assumem um papel passivo • Um dos participantes deve registar o conteúdo da sessão • Executivo • Escolher um executivo como patrocinador que irá introduzir e concluir a sessão JAD

39. Onde realizar as sessões JAD? • Organizar entre 2 a 3 sessões de um dia fora do local do trabalho para minimizar interferências • Reservar uma sala para 20 pessoas • Planear a comida e as bebidas • Só realizar as reuniões se todos os participantes podem estar presentes

40. Sala de reuniões

41. Vantagens do JAD • Menos 15% do tempo em comparação com as entrevistas individuais • Desenvolvimento rápido de sistemas • Os utilizadores sentem-se integrados no desenvolvimento do sistema • Desenvolvimento criativo de designs

42. Desvantagens do JAD • Exige que os vários participantes tenham tempo disponível para todas as sessões • Se a preparação for insuficiente, a sessão pode não ter sucesso • Se o relatório de uma sessão estiver incompleto pode por em risco a próxima sessão • A cultura organizacional pode não ser compatível com a aproximação JAD

43. Etnografia • É difícil descrever como que se realizam tarefas • Solução: Observar como as tarefas são realizadas • Etnografia – técnica desenvolvida na área das ciências socias • Útil para determinar o método de trabalho • Divergência entre os métodos de trabalho usados e a sua definição formal

44. Etnografia e ER • Procurar métodos pouco usuais de trabalho • Estabelecer uma relação de confiança com os utilizadores • Manter notas detalhadas sobre os métodos de trabalho. • Combinar observação com entrevistas abertas • Organisar sessões regulares de esclarecimento • Usar outras técnicas de levantamento de requisitos

45. Etnografia • Perspectiva do contexto do trabalho • Descreve o contexto e a localização fisíca do trabalho e como as pessoas usam os objectos para realizar tarefas • Perspectiva social e organizacional • Cada individuo tem uma percepção única sobre o trabalho • Perspectiva do fluxo de trabalho • Descrever as actividades que formam um trabalho/tarefa e o fluxo de informação entre essas actividades.

46. Prototipagem • Protótipo • Versão inicial de um sistema para experimentação • Permite aos utilizadores identificar os pontos fortes e fracos do sistema • Algo concreto que pode ser criticado • Protótipos devem estar disponíveis durante o levantamento de requisitos

47. Vantagens da Prototipagem • Utilizadores podem experimentar “o sistema” • Estabelece a fiabilidade e utilidade do sistema • Essencial para definir o “look and feel” da interface com o utilizador • Pode ser usado nos testes do sistema e no desenvolvimento de documentação • Obriga a estudar com detalhe os requisitos • Encontrar inconsistências e omissões

48. Tipos de Protótipos • Protótipos “Throw-away” • Objectivo: Ajudar o levantamento e desenvolvimento dos requisitos • Suportar os requisitos mais difíceis de perceber • Protótipos Evolutivos • Objectivo: desenvolvimento rápido de uma versão inicial do sistema • Suportar os requisitos bem definidos e conhecidos

49. Desvantagens da Prototipagem • Custos de aprendizagem • Custos de desenvolvimento • Estende a planificação do desenvolvimento • São incompletos • Pode não ser possível protótipar requisitos críticos

50. Abordagens à prototipagem • Prototipagem em papel • Representação em papel do interface do sistema • Prototipagem ‘Wizard of Oz’ • Uma pessoa (wizard) simula as respostas do sistema de acordo com as entradas do utilizador • Prototipagem executável • Utilização de uma ambiente de desenvolvimemto rápido para desenvolver um protótipo executável