Curso de Sistemas de Informação. Karla Donato Fook DESU / DAI

Transcrição

1 Curso de Sistemas de Informação Karla Donato Fook DESU / DAI

2 Especificação Desenvolvimento Validação Evolução 4 2

3 A funcionalidade do software e as restrições sobre sua operação devem ser definidas O quê? Que dados tem que ser processados? Que função e desempenho são desejados? Que interfaces devem ser estabelecidas? Que restrições? Etapas Análise do sistema Análise 5 Analista de Sistemas 6 3

4 Apelidos do analista Analista de Sistemas Engenheiro de Sistemas Projetistas de Sistemas-Chefe Programador/Analista 7 Executa ou coordena cada uma das tarefas associadas à análise de software; Comunica-se com o pessoal do usuário/cliente a fim de conhecer as características do ambiente existente durante as tarefas de reconhecimento; Convoca o pessoal de desenvolvimento durante as tarefas de avaliação e síntese, de forma que as características do software sejam corretamente definidas; 8 4

5 É o responsável pelo desenvolvimento de uma Especificação de Requisitos de Software (geralmente); Participa de todas as revisões 9 Facilidade de comunicação Habilidades técnicas Habilidades especiais relativas ao domínio da aplicação 10 5

6 11 Para entender o que o cliente quer Para entender o problema do negócio Para documentar o escopo do projeto e definir suas restrições Para assegurar a qualidade do sistema e a satisfação do cliente Para definir critérios de aceitação e gerenciar as expectativas do cliente 12 6

7 Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos (Pfleeger 2004) As descrições das funções e das restrições são os requisitos do sistema (Sommerville 2004) 13 Um requisito é descrito como uma propriedade que o sistema deve exibir para resolver algum problema da vida real (Swebok 2004) Um condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo (IEEE) 14 7

8 Requisitos funcionais Declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações E o que o sistema não deve fazer Requisitos não funcionais Condições que o software deve atender Qualidades que ele deve ter Requisitos de desempenho, tempo real e de modificabilidade Restrições sobre os serviços ou as funções oferecidos pelo sistema Exemplos: garantia, confiabilidade (segurança), restrições físicas e operacionais 15 Requisitos do Usuário Requisitos do Negócio Para exemplificar os tipos, considere o sistema LIBSYS Uma interface única com uma série de bancos de dados antigos. Ele permite que os usuários baixem cópias de artigos publicados em revistas, jornais e periódicos científicos. 16 8

9 Requisitos do Usuário São declarações em linguagem natural e em diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar Exemplo (Considerando o LYBSYS) LIBSYS deve manter acompanhamento de todos os dados exigidos pelas agências de licenciamento de direitos autorais no Reino Unido e em outros lugares 17 Requisitos do Negócio Estabelecem detalhadamente as funções e as restrições do sistema Exemplo (Considerando o LYBSYS) 1. Ao solicitar um documento ao LIBSYS, deve ser apresentado ao solicitante um formulário que registra os detalhes do usuário e da solicitação feita 2. Os formulários de solicitação do LIBSYS devem ser armazenados no sistema durante 5 anos, a partir da data da solicitação 3. Todos os formulários devem ser indexados por usuário, nome do material solicitado e fornecedor da solicitação 4. O LIBSYS deve manter um registro de todas as solicitações feitas ao sistema 3. Para materiais aos quais se aplicam os direitos de empréstimo dos autores, os detalhes do empréstimo devem ser enviados mensalmente às agências de licenciamento de direitos autorais que se registraram no LIBSYS 18 9

10 (Sommerville) 19 Identificação dos serviços, metas a serem atingidas e restrições a serem respeitadas, através de consultas aos usuários do sistema

11 Levantamento Definição e Documentação Análise de requisitos Prototipação Especificação Revisão de requisitos Contratação (Tsui e Karan, 2013) 21 Levantamento Definição e Documentação Análise de Analistas efetuam Prototipação a identificação e o agrupamento Especificação de requisitos requisitos junto de aos requisitos usuários e clientes Revisão de requisitos Contratação (Tsui e Karan, 2013) 22 11

12 Levantamento Dificuldades Stakeholders não sabem Definição o que querem e do sistema de computador, Documentação a não ser em termos gerais expressam os requisitos naturalmente em seus próprios termos e com conhecimento implícito de seu trabalho Análise de Prototipação Especificação requisitos * Diferentes stakeholders requisitos possuem diferentes, expressos de diferentes formas * Fatores políticos podem influenciar os requisitos do sistema Ex.: gerentes Revisão podem de solicitar requisitos específicos do requisitos sistema para aumentar sua influência na organização Contratação * Ambiente econômico e de negócios sobre o qual a análise é realizada é dinâmico (Tsui e Karan, 2013) 23 Levantamento Definição e Documentação Análise de requisitos Prototipação Especificação Os enunciados dos requisitos são Revisão de verificados requisitos quanto à precisão e eventuais conflitos Contratação categorizados priorizados (Tsui e Karan, 2013) 24 12

13 Levantamento Análise de requisitos Definição e Documentação Prototipação Revisão de requisitos Os requisitos devem ser definidos e documentados Se necessário, alguns devem ser prototipados Ex.: aspectos de interface Requisitos Especificação documentados devem ser requisitos revisados pelos usuários Estas três subetapas podem iterar entre elas e Contratação a etapa de análise O gerenciamento é essencial (Tsui e Karan, 2013) 25 Levantamento Definição e Documentação Envolve a produção Análise de um Documento Prototipação de Especificação requisitos de Requisitos Este documento deve ser acordado e servirá de contrato entre o cliente e a organização Revisão de de desenvolvimento de software requisitos Especificação Contratação (Tsui e Karan, 2013) 26 13

14 O Documento de Requisitos deve ser Levantamento de inteligível, requisitos o mais preciso, completo, Definição e consistente e sem ambiguidades Documentação possível analisado e confirmado pelo usuário Análise de Prototipação usado pelos requisitos desenvolvedores para a obtenção de um produto que satisfaça aos requisitos Revisão de organizado de modo que possa requisitos ser utilizado pelos clientes de sistema e pelos desenvolvedores de software Especificação Contratação (Tsui e Karan, 2013) 27 Levantamento Definição e Documentação O Documento de Requisitos é uma linha de base A partir deste Análise ponto, de qualquer mudança Prototipação deve ser gerenciada por requisitos um processo de controle de mudanças, para evitar o problema da deformação do escopo (scope creeping) scope creeping é uma das principais Revisão causas de de estouro de cronograma e custos, requisitos pois o sistema aumenta de tamanho sem que ninguém perceba Especificação Contratação (Tsui e Karan, 2013) 28 14

15 Levantamento Definição e Documentação Consequências negativas da não realização da Engenharia de Requisitos Análise de Prototipação Especificação Não há requisitos documentados de que requisitos sirvam de base para de os requisitos testes Não há requisitos acordados para controlar a deformação de escopo É muito difícil gerenciar o cronograma e os custos do projeto sem requisitos claros e documentados Revisão de requisitos Contratação (Tsui e Karan, 2013) 29 Clientes de sistema Especificam e lêem os requisitos para verificar se eles atendem às suas necessidades Os clientes especificam as mudanças nos requisitos Gerentes Usam o documento para planejar um pedido de proposta para o sistema e planejar o processo de desenvolvimento do sistema 30 15

16 Engenheiros do sistema Usam os requisitos para compreender qual sistema será desenvolvido Engenheiros de testes de sistema Usam os requisitos para desenvolver testes de validação para o sistema Engenheiros de manutenção de sistema Usam os requisitos para compreender o sistema e os relacionamentos entre suas partes. 31 Introdução Propósito Escopo do produto Definições e abreviações Referências Descrição Geral Funções do produto Características do usuário Restrições gerais Requisitos Específicos Vide Modelo 32 16

17 Leitura de artigo ES_Tecnicas_IdentificacaoRequisitos.pdf 33 Levantamento orientado a Pontos de Vista Cenários Etnografia Entrevistas Casos de uso Questionários Brainstorming Workshops JAD (Joint Application Design) Prototipagem 34 17

18 Levantamento orientado a Pontos de vista Organizam os processos de elicitação e os requisitos usando pontos de vista A abordagem reconhece várias perspectivas e permite descobrir conflitos nos requisitos propostos por diferentes stakeholders 35 Levantamento orientado a Pontos de vista Primeira etapa: identificar os possíveis pontos de vista Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema Segunda etapa: estruturação de pontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior 18

19 Levantamento orientado a Pontos de vista A etapa de documentação do ponto de vista: objetiva refinar a descrição dos pontos de vista e serviços identificados O mapeamento de sistema: envolve identificar objetos em um projeto orientado a objetos Levantamento orientado a Pontos de vista Tipos genéricos de pontos de vista Pontos de vista de interação: representam pessoas ou outros sistemas que interagem diretamente com o sistema. Pontos de vista indiretos: representam stakeholders que não usam o sistema diretamente, mas que influenciam o sistema de alguma forma Pontos de vista de domínio: representam características e restrições do domínio que influenciam os requisitos do sistema. Ex.: Padrões para comunicações entre os bancos, no sistema de caixa eletrônico bancário 38 19

20 Levantamento orientado a Pontos de vista Tipos mais específicos de pontos de vista Fornecedores e receptores de serviços do sistema Sistemas que devem interfacear diretamente com o sistema que está sendo especificado Regulamentos e padrões que se aplicam ao sistema Pontos de vista de engenharia que refletem requisitos de pessoas que devem desenvolver, gerenciar e manter o sistema Pontos de vista de marketing e negócios externos à organização (sistemas baseados na Web, e-commerce,...) 39 Entrevistas Há a formulação de questões para os stakeholders sobre os sistemas que eles usam e o sistema a ser desenvolvido Os requisitos são derivados das respostas 40 20

21 Entrevistas Tipos Fechadas: os stakeholders respondem a um conjunto de perguntas predefinidas Abertas: não existe um roteiro predefinido. A equipe de engenharia explora vários assuntos para desenvolver uma maior compreensão das necessidades dos usuários Em geral, os tipos são combinados 41 Entrevistas Não é uma técnica eficiente para elicitação de conhecimentos sobre os requisitos e restrições organizacionais, pois existem relacionamentos sutis de poder e influência entre stakeholders na organização Em geral, a maioria das pessoas é relutante em discutir questões políticas e organizacionais que podem afetar os requisitos 42 21

22 Entrevistas Características de entrevistadores eficientes Possuem mente aberta, evitam ideias preconcebidas sobre os requisitos e querem ouvir seus stakeholders Induzem os entrevistados a iniciar as discussões com uma questão, uma proposta ou sugerindo um trabalho conjunto em um protótipo do sistema 43 Entrevistas As informações obtidas das entrevistas complementam outras informações sobre o sistema obtidas de documentos, observações de usuários, etc. Esta técnica deve ser utilizada junto com outras para a elicitação 44 22

23 Cenários As pessoas podem compreender e criticar um cenário de como interagiriam com um sistema de software Cenários podem adicionar detalhes a um esboço da descrição O uso de cenários para descrever requisitos é parte dos métodos ágeis, como a extreme programming 45 Cenários Deve incluir Uma descrição do que os usuários esperam do sistema no início do cenário Uma descrição do fluxo normal de eventos do cenário Uma descrição do que pode dar errado e como isso é tratado 46 23

24 Cenários Deve incluir (cont.) Informações sobre outras atividades que podem ocorrer simultaneamente Uma descrição do estado do sistema no fim do cenário 47 Cenários Podem ser escritos na forma de texto, complementados por diagramas, imagens de computador, etc 48 24

25 Casos de uso Técnica baseada em cenários Notação da Linguagem de Modelagem Unificada UML (Unified Modeling Language) 49 Casos de uso Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema 50 25

26 Casos de uso Representado por - atores - casos de uso - relacionamentos entre estes elementos 51 Casos de uso Ator Representado por um boneco e um rótulo com o nome do ator Cliente 52 26

27 Casos de uso Um caso de uso é uma funcionalidade do sistema Representado por uma elipse e um rótulo com o nome Cadastrar periódico 53 Casos de uso Relacionamentos - Ajudam a descrever os Casos de Uso - Ocorrem entre Atores e Casos de Uso 54 27

28 Casos de uso Relacionamentos - Ajudam a descrever os Casos de Uso - Ocorrem entre Atores e Casos de Uso 55 Engenharia de Requisitos é um estágio crítico do processo de software, pois os erros nessa fase conduzem a problemas no projeto e implementação 56 28