Adaptado a partir de Gerald Kotonya and Ian Sommerville

Apresentação em tema: "Adaptado a partir de Gerald Kotonya and Ian Sommerville"— Transcrição da apresentação:

1 Adaptado a partir de Gerald Kotonya and Ian Sommerville
Análise e Concepção de Sistemas de Informação Engenharia de Requisitos Adaptado a partir de Gerald Kotonya and Ian Sommerville Carla Ferreira

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 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 propõ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 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 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 Análise de Requisitos Lista de Verificações Matrizes de Interacção Negociação de Requisitos

26 Levantamento de Requisitos
Dilbert gilbert

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 Entrevistas 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? * 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 Relatório da Entrevista
INTERVIEW REPORT Interview notes approved by: ____________ Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes: * 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. Perspectiva do contexto do trabalho This describes the context and the physical location of the work and how people use objects to carry out tasks. Therefore, in a study of a help desk (say), this would describe the objects which the helper had to hand and how these were organised. Perspectiva social e organizacional This tries to bring out the day-to-day experience of work as seen by different people who are involved. Each individual typically sees the work in a different ways and this viewpoint tries to organise and integrate all of these perceptions. Perspectiva do fluxo de trabalho This viewpoint presents the work from a series of work activities with information flowing from one activity to another.

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 - A prototype is an initial version of a system which may be used for experimentation - Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses They have something concrete to criticise - Rapid development of prototypes is essential so that they are available early in the elicitation process

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” Protótipos Evolutivos
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 Training costs - prototype development may require the use of special purpose tools Development costs - depend on the type of prototype being developed Extended development schedules - developing a prototype may extend the schedule although the prototyping time may be recovered because rework is avoided Incompleteness - it may not be possible to prototype critical system requirements

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

51 Prototipagem em papel Características Objectivos
Representar em papel a funcionalidade e aparência da interface Tem custos baixos e é fácil de preparar e alterar Objectivos Analisar diferentes representações para a interface com o utilizador Fazer o levantamento das reacções dos utilizadores Fazer o levantamento das modificações (e sugestões) requeridas pelos utilizadores

52 Prototipagem em Papel

53 Prototipagem ‘Wizard of Oz’
A method of testing a system that does not exist the voice editor, IBM 1984 The Wizard O que o utilizador vê Wizard

54 Prototipagem ‘Wizard of Oz’
O ‘wizard’ humano simula as respostas do sistema Interpreta os inputs de um utilizador segundo um algoritmo Controla computador para simular o output desejado Usa a interface real ou um “mock-up” É usado para: Simular a adição de funcionalidades complexas Testar ideias futuristicas

55 Seleção de Técnicas de Levantamento*
Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Integration Low High Low Low Low of Information User Medium High Low Low Low Involvement Cost Medium Low Low Low Low- Medium Medium * Systems analysis and design with UML

56 Exemplo 1 Considere que é o analista responsável por desenvolver um novo sistema que suporte as decisões estratégicas dos gestores séniors de uma companhia de seguros. Os gestores reúnem-se mensalmente para discutir a evolução do mercado e reajustar a estratégia da empresa. Até agora estas reuniões são suportadas por documentação (extensa) em papel. O novo sistema vem eliminar o tempo perdido a analisar detalhadamente esses documentos, permintindo que os gestores se concentrem apenas nas questões estratégicas da empresa.

57 Exemplo 2 É responsável pela especificação de requisitos de um sistema de gestão de cadastro da infra-estrutura de rede física da empresa LxGásNatural, que é uma operadora/distribuidora de gás natural na região da grande Lisboa. Ao sistema que se pretende conceber e desenvolver deu-se o nome de SIG-RedeGásNatural, e o seu objectivo geral é permitir que a gestão dos elementos físicos da rede (e.g., condutas, ramais, juntas, postos de redução) seja suportada por um sistema integrado de informação geográfica. Existe um sistema de informação legado, em funcionamento, fortemente baseado em papel e em desenhos técnicos (i.e., ficheiros CAD) guardados num servidor de ficheiros partilhados, o qual apenas é acedido e gerido por técnicos do Departamento Técnico da empresa. A cultura da empresa LxGásNatural é formal, baseada em relações hierárquicas de poder e de responsabilidades bem definidas.

58 Exemplo 3 A empresa de distribuição de produtos para animais “Sr. Cão” pretende adquirir um sistema de apoio à decisão de compras de produtos. O “Sr. Cão” é uma empresa familiar gerida por 2 irmãos e os seus filhos, mas que neste momento se encontra em grande expansão quer em número de vendas, quer na variedade de produtos. O sistema que está a ser usado actualmente apenas regista o stock existente em armazém para cada produto, o que dificulta a gestão eficiente do stock. O objectivo do sistema a desenvolver é permitir reduzir os custos das compras e minimizar o nível de stock a manter no armazém. Tendo em consideração estes objectivos, o novo sistema deverá definir semanalmente uma lista de produtos a adquirir, associando a para cada produto a quantidade a comprar e o fornecedor a usar.

59 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 Análise de Requisitos Lista de Verificações Matrizes de Interacção Negociação de Requisitos

60 Análise e Negociação de Requisitos
Necessity checking The need for the requirement is analysed. In some cases, requirements may be proposed which don’t contribute to the business goals of the organisation or to the specific problem to be addressed by the system. Consistency and completeness checking The requirements are cross-checked for consistency and completeness. Consistency means that no requirements should be contradictory; completeness means that no services or constraints which are needed have been missed out. Feasibility checking The requirements are checked to ensure that they are feasible in the context of the budget and schedule available for the system development. Requirements discussion Requirements which have been highlighted as problematical are discussed and the stakeholders involved present their views about the requirements. Requirements prioritisation Disputed requirements are prioritised to identify critical requirements and to help the decision making process. Requirements agreement Solutions to the requirements problems are identified and a compromise set of requirements are agreed. Generally, this will involve making changes to some of the requirements

61 Análise de Requisitos Objectivos:
Encontrar problemas, falhas e inconsistências A análise é intercalada com o levantamento de requisitos A análise é suportada por uma lista de verificação de problemas

62 Lista de Verificação (1/2)
Desenho prematuro do sistema Verificar se o requisito inclui informação prematura sobre o design ou a implementação Combinação de requisitos Verificar se a descrição do requisito descreve um único requisito ou se pode ser dividida em diferentes requisitos Requisitos desnecessários Verificar se o requisito é apenas uma adição “cosmética” ao sistema. Utilização de HW não-standard Verificar se o requisito obriga a uso de hardware que não é standard Para tomar esta decisão é necessário saber os requisitos da plataforma a supotar

63 Lista de Verificação (2/2)
Conformidade com os objectivos de negócio Verificar se o requisito é consistente com os objectivos do negócio definidos na introdução do documento de requisitos Requisitos ambíguos Verificar se o requisito pode ser lido de forma diferentes por diferentes pessoas Quais as interpretações possíveis? Requisitos realistas Verificar se o requisito é realista tendo em conta a tecnologia a ser usada para implementar o sistema Requisitos “testáveis” Verificar se os engenheiros de teste podem derivar um teste a partir da descrição do requisito que mostre que o sistema satisfaz esse requisito Is the requirement testable, that is, is it stated in such a way that test engineers can derive a test which can show if the system meets that requirement?

64 Matrizes de interação Objectivos da análise de requisitos:
Determinar as interações entre requisitos Evidenciar conflitos e sobreposições Matriz de interação de requisitos Requisitos em conflito, colocar 1 Requisitos sobrepostos, colocar 1000 Requisitos independentes, colocar 0

65 Matrizes de Interação

66 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 Análise de Requisitos Lista de Verificações Matrizes de Interacção Negociação de Requisitos

67 Negociação de requisitos
Conflitos não são falhas Refletem diferentes necessidades e prioridades Negociação de requisitos tenta encontrar uma solução de concordância A negociação de requisitos pode ser um processo demorado A planificação de processo de ER deve ter em conta o tempo dispendido na negociação

68 Reuniões de negociação
Fase de informação Explicar os problemas associados com os requisitos a negociar Fase de discussão stakeholders devem ter oportunidade de comentar os requisitos que lhes dizem respeito Usar esta fase para atribuir prioridades aos requisitos Fase de resolução Eliminar, alterar ou refinar o requisito