Análise e Concepção de Sistemas de Informação Engenharia de Requisitos Adaptado a partir de Gerald Kotonya and Ian Sommerville Carla Ferreira [email protected] 1 Engenharia de Requisitos Introdução – – – – – – – Processo de Engª de Requisitos – – – – Requisitos Requisitos Funcionais Requisitos Não-Funcionais Problemas Métricas Documento de Requisitos Exemplo 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 ACSI/Adaptado por Carla Ferreira 2 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 ACSI/Adaptado por Carla Ferreira 3 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. ACSI/Adaptado por Carla Ferreira 4 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 ACSI/Adaptado por Carla Ferreira 5 Requisitos Funcionais* * Systems analysis and design with UML ACSI/Adaptado por Carla Ferreira 6 Requisitos Não-Funcionais* * Systems analysis and design with UML ACSI/Adaptado por Carla Ferreira 7 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 ACSI/Adaptado por Carla Ferreira 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) 8 Classificação de RNFs (2/2) Non-functional requirements Product requirements Process requirements Delivery requirements Segundo G. Kotonya e I. Sommerville Usability requirements Reliability requirements implementation requirements Safety requirements standards Efficiency requirements requirements External requirements Legal constraints Economic constraints Interoperability requirements Performance requirements Capacity requirements ACSI/Adaptado por Carla Ferreira 9 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 ACSI/Adaptado por Carla Ferreira 10 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 ACSI/Adaptado por Carla Ferreira 11 Métricas para RNFs Property Performance Reliability Availability Size Usability Robustness Portability ACSI/Adaptado por Carla Ferreira Metric 1. Processed transactions per second 2. Response time to user input 1. Rate of occurrence of failure 2. Mean time to failure Probability of failure on demand Kbytes 1. Time taken to learn 80% of the facilities 2. Number of errors made by users in a given time period Time to restart after system failure Number of target systems 12 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 ACSI/Adaptado por Carla Ferreira 13 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 ACSI/Adaptado por Carla Ferreira 14 Estrutura do Documento de Requisitos O standard IEEE/ANSI 830-1993 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 ACSI/Adaptado por Carla Ferreira 15 Estrutura do Documento de Requisitos 2. Descrição geral IEEE/ANSI 830-1993 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 ACSI/Adaptado por Carla Ferreira 16 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. ACSI/Adaptado por Carla Ferreira 17 Engenharia de Requisitos Introdução – – – – – – – Processo de Engª de Requisitos – – – – Requisitos Requisitos Funcionais Requisitos Não-Funcionais Problemas Métricas Documento de Requisitos Exemplo 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 ACSI/Adaptado por Carla Ferreira 18 Processo de ER inputs e outputs Existing systems information Agreed requirements Stakeholder needs Organisational standards Regulations Requirements engineering process System specification System models Domain information ACSI/Adaptado por Carla Ferreira 19 Actividades Gerais do Processo de ER Requirements elicitation Requirements analysis and negotiation User needs domain information, existing system information, regulations, standards, etc. ACSI/Adaptado por Carla Ferreira Requirements documentation Requirements validation Requirements document System specification Agreed requirements 20 Modelo Espiral para ER Decision point: Accept document or re-enter spiral Informal statement of requirements Requirements elicitation Requirements analysis and negotiation START Requirements document and validation report Agreed requirements Requirements validation Requirements documentation Draft requirements document ACSI/Adaptado por Carla Ferreira 21 Modelo de Maturidade do Processo de ER Level 3 - Defined Defined process based on best practice; process improvement in place Level 2 - Repeatable Standardised requirements engineering; fewer requirements problems Level 1 - Initial Ad-hoc requirements engineering; requirements problems are common ACSI/Adaptado por Carla Ferreira 22 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 ACSI/Adaptado por Carla Ferreira 23 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 ACSI/Adaptado por Carla Ferreira 24 Engenharia de Requisitos Introdução – – – – – – – Processo de Engª de Requisitos – – – – Requisitos Requisitos Funcionais Requisitos Não-Funcionais Problemas Métricas Documento de Requisitos Exemplo 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 ACSI/Adaptado por Carla Ferreira 25 Levantamento de Requisitos Dilbert ACSI/Adaptado por Carla Ferreira 26 Processo de ER Levantamento, análise e negociação de requisitos Draft statement of requirements Req uirements elicitation Req uirements analysis Req uirements problems Req uirements document Req uirements neg otiation ACSI/Adaptado por Carla Ferreira 27 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 ACSI/Adaptado por Carla Ferreira 28 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 ACSI/Adaptado por Carla Ferreira 29 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 ACSI/Adaptado por Carla Ferreira 30 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 ACSI/Adaptado por Carla Ferreira 31 Entrevistas Types of Questions Closed-Ended Questions Examples * * * Open-Ended Questions * * * Probing 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? 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? Why? Can you give me an example? Can you explain that in a bit more detail? * Systems analysis and design with UML ACSI/Adaptado por Carla Ferreira 32 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 ACSI/Adaptado por Carla Ferreira 33 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 ACSI/Adaptado por Carla Ferreira 34 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 ACSI/Adaptado por Carla Ferreira 35 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 ACSI/Adaptado por Carla Ferreira 36 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 ACSI/Adaptado por Carla Ferreira 37 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 ACSI/Adaptado por Carla Ferreira 38 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 ACSI/Adaptado por Carla Ferreira 39 Sala de reuniões ACSI/Adaptado por Carla Ferreira 40 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 ACSI/Adaptado por Carla Ferreira 41 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 ACSI/Adaptado por Carla Ferreira 42 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 ACSI/Adaptado por Carla Ferreira 43 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 ACSI/Adaptado por Carla Ferreira 44 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. ACSI/Adaptado por Carla Ferreira 45 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 ACSI/Adaptado por Carla Ferreira 46 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 ACSI/Adaptado por Carla Ferreira 47 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 ACSI/Adaptado por Carla Ferreira 48 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 ACSI/Adaptado por Carla Ferreira 49 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 ACSI/Adaptado por Carla Ferreira 50 Prototipagem em papel Características – 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 ACSI/Adaptado por Carla Ferreira 51 Prototipagem em Papel ACSI/Adaptado por Carla Ferreira 52 Prototipagem ‘Wizard of Oz’ A method of testing a system that does not exist – the voice editor, IBM 1984 O que o utilizador vê ACSI/Adaptado por Carla Ferreira Wizard The Wizard 53 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 ACSI/Adaptado por Carla Ferreira 54 Seleção de Técnicas de Levantamento* Interviews JAD Questionnaires Document Analysis Observation Type of Information As-Is Improve. To-Be As-Is As-Is Improve. Improve. To-Be As-Is As-Is Depth of Information High High Medium Low Low Breadth of Information Low Medium High High Low Integration Low of Information High Low Low Low User Medium Involvement High Low Low Low Cost LowMedium Medium Low Low LowMedium * Systems analysis and design with UML ACSI/Adaptado por Carla Ferreira 55 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. ACSI/Adaptado por Carla Ferreira 56 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 SIGRedeGá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. ACSI/Adaptado por Carla Ferreira 57 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. ACSI/Adaptado por Carla Ferreira 58 Engenharia de Requisitos Introdução – – – – – – – Processo de Engª de Requisitos – – – – Requisitos Requisitos Funcionais Requisitos Não-Funcionais Problemas Métricas Documento de Requisitos Exemplo 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 ACSI/Adaptado por Carla Ferreira 59 Análise e Negociação de Requisitos Requ irements analysis Necessity checking Unnecessary requirements Requirements discussion Consistency and completeness checking Conflicting and incomplete requirements Requirements prioritisation Feasibility checking Infeasible requirements Requirements agreement Requ irements negotiation ACSI/Adaptado por Carla Ferreira 60 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 ACSI/Adaptado por Carla Ferreira 61 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 ACSI/Adaptado por Carla Ferreira 62 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 ACSI/Adaptado por Carla Ferreira 63 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 ACSI/Adaptado por Carla Ferreira 64 Matrizes de Interação Requirement R1 R2 R3 R4 R5 R6 R1 0 0 1000 0 1 1 ACSI/Adaptado por Carla Ferreira R2 0 0 0 0 0 0 R3 1000 0 0 1000 0 1000 R4 0 0 1000 0 1 1 R5 1 0 0 1 0 0 R6 1 0 1000 1 0 0 65 Engenharia de Requisitos Introdução – – – – – – – Processo de Engª de Requisitos – – – – Requisitos Requisitos Funcionais Requisitos Não-Funcionais Problemas Métricas Documento de Requisitos Exemplo 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 ACSI/Adaptado por Carla Ferreira 66 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 ACSI/Adaptado por Carla Ferreira 67 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 ACSI/Adaptado por Carla Ferreira 68
Download
