Baixe o app para aproveitar ainda mais
Prévia do material em texto
Disciplina: Analise e Projeto de Sistemas Orientado a Objetos Elicitação de Requisitos Prof. Izaac Espíndola izaac@joaquimnabuco.edu.br 27/08/2013 Requisitos • São capacidades e condições às quais o sistema – e em termos mais amplos, o projeto – deve atender [Larman]; • Não são apenas funcionalidades; • Podem ser classificados em funcionais e não- funcionais. 2 Negociação de requisitos • Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Conflitos não são falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas; • A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem; • No planejamento do processo de engenharia de requisitos, é importante deixar bastante tempo para negociação. Alcançar um compromisso aceitável pode tomar um tempo considerável. 3 • Fluxo na disciplina de Requisitos: 4 Requisitos Funcionais Descrevem a funcionalidade ou serviços do sistema Não-funcionais Também conhecidos como requisitos de qualidade; Aspectos como usabilidade, desempenho, confiabilidade, segurança, implementação, questões legais, ambiente operacional, entre outros. Definem a arquitetura do sistema 5 Classificação de Requisitos Não Funcionais • Requisitos do Produto – Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.) • Requisitos Organizacionais – Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.) • Requisitos Externos – Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.) Medidas de Requisitos (Não-Funcionais) Propriedade Medida Velocidade Transações processadas/seg Tempo de resposta do usuário/evento Tamanho K bytes No de chips de RAM Facilidade de uso Tempo de treinamento No de quadros de ajuda Confiabilidade Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Robustez Tempo de reinício após falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Portabilidade Percentual de declarações dependentes do destino No de sistemas destino Exemplos de R.F. • [RF001] Usuário Precisa estar cadastrado no banco de dados para acessar ao sistema. • [RF002]Usuário precisa de um identificador e uma senha para ter acesso ao sistema. • [RF003] A todo usuário deve ser associado um identificador único (Matricula), o qual será definido nivel de acesso para a área de armazenamento permanente da conta. Exemplos de R. N. F. • Requisitos do Produto – [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s • Requisitos Organizacionais – [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 • Requisitos Externos – [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema Levantamento de Requisitos Levantamento de requisitos • Atividade fundamental no desenvolvimento de software; • Captura os requisitos sob a visão dos usuários; • Os erros introduzidos nos requisitos se propagam por todas as outras fases. 11 Elicitação de requisitos • ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão; • Cabe à elicitação a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software. 12 Dificuldades da Elicitação de requisitos • Usuários podem não ter uma idéia precisa do sistema por eles requerido; • Usuários têm dificuldades para descrever seu conhecimento sobre o domínio do problema; • Usuários e Analistas têm diferentes pontos de vista do problema (por terem diferentes formações); • Usuários podem antipatizar-se com o novo sistema e se negarem a participar da elicitação (ou mesmo fornecer informações errôneas). 13 14 Fonte: http://engenhariaderequisitos.blogspot.com Dificuldades da Elicitação de requisitos Componentes da elicitação de requisitos 15 Domínio da aplicação Problema a ser solucionado Contexto do negócio Necessidades e restrições dos stakeholders Atividades da elicitação • Entendimento do domínio da aplicação – O conhecimento do domínio da aplicação é o conhecimento geral onde o sistema será aplicado • Entendimento do problema – Os detalhes problema do cliente onde o sistema será aplicado devem ser entendidos • Entendimento do negócio – Deve-se entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio. • Entendimento das necessidades e limitações dos stakeholders do sistema – Deve-se entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho. 16 17 Necessita entender a linguagem do usuário Técnicas de elicitação • Entrevistas e questionários; • Workshop de requisitos; • Cenários; • Prototipagem; • Estudo etnográfico. 18 Entrevistas e questionários • Técnica simples de utilizar; • Eficaz na fase inicial; • Fatores condicionantes: – Influência do entrevistador sobre o entrevistado – Relação pessoal entre os intervenientes – Predisposição do entrevistado – Capacidade de seguir um plano na entrevista 19 Workshop de requisitos • Reunião estruturada com o objetivo de obter um conjunto de requisitos bem definidos; • Integrantes: analistas e representantes do cliente • Interação entre todos os presentes; • Momentos de descontração; • Conduzido por um facilitador que promove a discussão entre os integrantes; • Decisões são tomadas de acordo com processos bem definidos; • Produz documentação que reflete os requisitos e decisões tomadas. 20 Cenários • Cenários são estórias que explicam como um sistema poderá ser usado. Eles devem incluir: – uma descrição do estado do sistema antes de começar o cenário – o fluxo normal de eventos do cenário – exceções ao fluxo normal de eventos – informações sobre atividades concorrentes – uma descrição do estado do sistema ao final do cenário • Cenários são exemplos de sessões de interação que descrevem como o usuário interage com o sistema • A descoberta de cenários expõe interações possíveis do sistema e revela as facilidades que o sistema pode precisar 21 Prototipagem • Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação; • Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar o “sistema” e mostrar os pontes fortes e fracos. Eles terão algo concreto para criticar; • O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação ; • Deve-se observar a relação custo-benefício de construção dos protótipos. 22 Estudo etnográfico • Análise social das tarefas desempenhadas numa organização; • Capaz de obter requisitos que não seriam observáveis através de outras técnicas; • Capaz de obter processos reais de trabalho; • Baseada em observação direta do desempenho das atividades das pessoas. 23 Análise de Requisitos Análise de requisitos • O objetivo da análise é descobrir problemas, incompletude e inconsistência nos requisitos elicitados. Eles normalmente são retornados aos stakeholders para resolvê-los, através de um processo de negociação; • A análise é intercalada com elicitação, pois problemas são descobertos quando os requisitos são elicitados; • Uma lista de verificação de problemas poderá ser usada para ajudar a análise. Cada requisito poderá seravaliado contra esta lista. 25 Atividades envolvidas • Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema; • Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível; • Priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos; • Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema). 26 Dificuldades da análise • Fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema); • O ambiente (econômico e/ou organizacional) em que a análise é feita é possui fatores dinâmicos, e como tal os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis). 27 Negociação de requisitos • Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Conflitos não são falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas; • A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem; • No planejamento do processo de engenharia de requisitos, é importante deixar bastante tempo para negociação. Alcançar um compromisso aceitável pode tomar um tempo considerável. 28 29 Execícios • Exercício 1 Considere o seguinte problema: Sistema de Levantamento de Produtos em Estoque Uma distribuidora possui alguns depósitos regionais que revendem vários produtos. A distribuidora deseja ter um sistema de levantamento dos produtos em estoque, dos pedidos feitos aos fornecedores e dos pedidos feitos pelos clientes através de todos os seus depósitos. O sistema deve permitir que os produtos e pedidos sejam incluídos, excluídos e acessados. Cada fornecedor pode fornecer vários produtos e um mesmo produto pode ser fornecido por mais de um fornecedor. Em cada pedido feito por um cliente, o vendedor tem uma comissão de 5%. Somente os empregados têm acesso às funcionalidades do sistema, ou seja, os clientes e os fornecedores não acessam diretamente o sistema. 30
Compartilhar