Análise de Requisitos. Tema 4. Análise de Requisitos Profa. Susana M. Iglesias

Transcrição

1 Análise de Requisitos Tema 4. Análise de Requisitos Profa. Susana M. Iglesias

2 Análise e uma ponte entre a engenharia de sistemas e o desenho do software Engenharia de Sistema Análise de Requisitos de Software Desenho de Software

3 Análise de Requisitos A análise de requisitos é uma tarefa da engenharia de software que preenche o vazio entre o nível de sistema e o desenho de software. Permite ao engenheiro de sistema especificar funções e performance, indicar a interface de software com outros elementos e estabelecer as restrições que o software vai a encontrar Permite ao engenheiro de software (analista) refinar a alocação e construir modelos dos dados. Provê o design do software com modelos que podem ser traduzidos em dados, arquitetura, interface e desenho procedimental. Provê ao desenvolvedor e ao cliente com médios para avaliar qualidade uma vez que o software este feito.

4 Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo para atender as necessidades ou restrições da organização ou de outros componentes do sistema.

5 Requisitos Requisitos do usuário Declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes. Requisitos do sistema Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor. Especificação de software Especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento.

6 Análise de requisitos Áreas de esforço Reconhecimento do problema Avaliação e síntese Modelação Especificação Revisão Para fazer isto o analista estuda as especificações do sistema, se não existem o Plano de projeto

7 Reconhecimento do problema Entender o software no contexto do sistema e revisar o escopo do software que foi usado no plano de projeto Depois a comunicação para a análise deve ser estabelecida, e é então que o reconhecimento do problema é assegurada O objetivo do analista é reconhecer os elementos básicos do problema como é percebido pelo usuário /cliente

8 Avaliação e Síntese O analista deve definir todos os objetos de dados externos visíveis, avaliar o fluxo e o conteúdo da informação Definir e elaborar todas as funções do software Entender o comportamento do software no contexto dos eventos que afetam o sistema Estabelecer as características da interface do sistema Descobrir as restrições adicionais do desenho Estas tarefas servem para descrever o problema como é as aproximações gerais ou a solução deve ser sintetizada.

9 Exemplo: Sistema de controle de inventário é requerido por provedor de auto partes O sistema manual atual tem os seguintes problemas Inabilidade de obter o status de um componente rapidamente Dois ou três reviravoltas na hora de atualizar a ficha do produto Múltiplas re-ordens para o mesmo fabricante porque não existe maneira de associar fabricantes com componentes e assim vai... Que parte da análise de requisito...?

10 Uma vez que o problema é identificado a o analista determina que informações devem ser produzidas pelo novo sistema e que dados devem ser providos para o sistema. Por exemplo: O usuário deseja um relatório que partes tem sido pegues do estoque e quantas similares ainda restam. O usuário indica que o balconista do estoque deve registrar o número de identificador de cada parte que sai do estoque. Que parte da análise de requisitos...?

11 Na avaliação (input/output) o analista começa a sintetizar uma o mais soluções. Para começar os dados, as funções de processamento e o comportamento do sistema são definidos em detalhe Definição da arquitetura básica é considerada Uma aproximação cliente-servidor, mais se encaixa no plano de software Um gerenciado de banco de dados deve ser necessário pero para a necessidade do usuário se justifica? O processo de avaliação e síntese continua até que analista e cliente/usuário estejam confortáveis e saibam que o software pode ser adequadamente especificado e continuar com os passos no desenvolvimento

12 Primeiro foco do analista nestes passos WHAT não HOW Que dados o sistema produze e consume? Que funções o sistema deve executar? Que interfaces devem ser definidas? Que restrições devem ser aplicadas?

13 Problemas que podem aparecer Os envolvidos* não sabem o que eles realmente querem. Se expressam num vocabulário diferente dos desenvolvedores. Os envolvidos podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os requisitos. Novos requisitos podem surgir durante o processo de levantamento/análise/especificação. Novos envolvidos podem vir a participar do processo. Podem haver mudanças

14 Como descrever os requisitos? A especificação dos requisitos deve ser: Completa deve descrever tudo o que é necessário Consistente não deve haver conflitos e contradições Não-ambígua não deve levar a interpretações diferentes por desenvolvedores e usuários. Difícil de atingir considerando que existem diferentes tipos de envolvidos. Depende da precisão da linguagem utilizada Linguagem natural, informal apropriada para os requisitos do usuário e do sistema. Linguagens gráficas, semi-formais apropriada para os requisitos do sistema e do software. Linguagens formais apropriada para uma especificação formal de software em métodos formais.

15 Requisitos Funcionais Descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça Casos de Uso Exemplos: "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". "o software deve emitir relatórios de compras a cada quinze dias" "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

16 Requisitos Não Funcionais Propriedades de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras São exemplos de requisitos não-funcionais: "a base de dados deve ser protegida para acesso apenas de usuários autorizados". "o tempo de resposta do sistema não deve ultrapassar 30 segundo". "o software deve ser operacionalizado no sistema Linux" "o tempo de desenvolvimento não deve ultrapassar seis meses".

17 Requisitos não funcionais Requisitos não funcionais Requisitos do produto Requisitos Organizacionais Requisitos Externos Requisitos de usabilidade Requisitos de confiabilidade Requisitos de portabilidade Requisitos de interoperabilidade Requisitos éticos Requisitos de legislação Requisitos de eficiência Requisitos de entrega Requisitos de implementação Requisitos de Standards Requisitos de desempenho Requisitos de espaço Requisitos de privacidade Requisitos de segurança

18 Requisitos A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros o que determina uma maior dificuldade no processo. Por exemplo, o requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos). Devido à esta complexidade, faz-se necessário que as atividades associadas aos requisitos sejam gerenciadas durante todo o ciclo de vida do sistema.

19 Requisitos mudam sempre! Requisitos precisam ser levantados, analisados, especificados, rastreados, verificados e documentados. Estas atividades ocorrem ao longo de todo o ciclo-de-vida do software. A Engenharia de Requisitos propõe modelos, métodos, técnicas e ferramentas para a realização destas atividades

20 Engenharia de requisitos Estudo de viabilidade Levantamento Análise Especificação Gerenciamento Rastreamento Verificação e Validação Documentação

21 Engenharia de requisitos Fonte Ian Sommerville

22 Estudo de viabilidade Decide se o sistema proposto é vantajoso e lucrativo. Deve verificar se: O sistema contribui para os objetivos organizacionais. O sistema pode ser construído com a tecnologia corrente e com o orçamento disponível. O sistema pode ser integrado com os outros sistemas em utilização. Questões a serem respondidas por clientes e usuários: E se o sistema não for implementado? Quais os problemas atuais? Como o sistema irá ajudar? Quais serão os problemas de integração? Novas tecnologias são necessárias? Quais habilidades? Quais facilidades deve ser providas pelo sistema proposto?

23 Levantamento de requisitos Obter os requisitos dos especialistas no domínio clientes e usuários Principal problema: comunicação Usuários e especialistas não compartilham o mesmo vocabulário Técnicas de Comunicação Entrevistas Observação direta Encontros

24 Técnicas de levantamento de requisitos Entrevistas: é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas Observação in loco: os analistas devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários. Encontros: reuniões envolvendo analistas, clientes e usuários que têm por objetivo exclusivamente realizar o levantamento de informações, a descrição dos problemas atuais e indicar metas futuras e requisitos do sistema. Os encontros devem ser realizados em um local neutro (fora da organização), coordenados por um moderador que também não deve pertencer ao grupo dos envolvidos (stakeholders) e normalmente duram de 1 a 3 dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em painéis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.

25 Análise de requisitos A análise possui dois propósitos: Permite julgamentos sobre a qualidade dos requisitos do sistema Elaborar um modelo de alto-nível do sistema com os principais componentes e suas interfaces Abordagens para a análise Análise Estruturada OMT UML: Casos de Uso e Diagramas de classes

26 Análise Estruturada Utiliza uma notação que é própria ao método de análise estruturada para com a finalidade de retratar o fluxo e o conteúdo das informações utilizadas pelo sistema, dividir o sistema em partições funcionais e comportamentais e descrever a essência daquilo que será construído. Modelo Ambiental: O modelo ambiental descreve o ambiente no qual o sistema se insere, ou seja, descreve o contexto do sistema, que deve ter 3 componentes: Definição de Objetos--> Finalidade de sistema; Lista de Eventos--> Os acontecimentos que ocorrem no exterior e que interagem com o sistema; Diagrama de contexto--> Representa o sistema como um único processo e as suas interações com o meio ambiente; Modelo Comportamental: O modelo comportamental descreve as acções que o sistema deve realizar para responder da melhor forma aos eventos definidos no modelo ambiental. Técnicas utilizadas: Diagrama de Fluxos de Dados (DFD) Dicionário de Dados (DD) Diagrama de Entidades e Associações (ou Relacionamentos) (DER Diagrama de entidade-relacionamento ou MER Modelo de Entidade-relacionamento Especificação de Processos (EP) - (DESENHO) Diagrama de Transição de Estados (DTE

27 Object-Modeling Technique (OMT) é uma lingagem de modelação orientada a objeto para disenho e modelagem de software. (Rumbaugh,, Blaha, Premerlani, Eddy and Lorensen, 1991) Método para desenvolver sistemas orientados a objeto e dar suporte a POO Objetivos Testar entidades físcas antes de construídas (simulações), Comunicação com clientes, Visualização (forma alternativa de apresentação da informação) e Redução da complexidade. Modelos: Object model : Representa a mais estática e estable del dominio do modelo. Dynamic model : Representa a transição de estados com ações Functional model : Manipula a perpectiva do processo (DFD) OMT é um predecessor da Unified Modeling Language (UML.)

28 OMT (Diagrama de Objeto)

29 OMT diagrama de estado

30 UML- colagem

31 Unified Modeling Language (UML) é uma linguagem de modelagem standard de propósito geral. UML inclui um grupo de técnicas de notações gráficas para criar modelos visuais.

32 Diagramas da UML 2.0 Diagramas Estruturais Diagrama de classes Diagrama de objetos Diagrama de componentes Diagrama de instalação Diagrama de pacotes Diagrama de estrutura Diagramas Comportamentais Diagrama de Caso de Uso Diagrama de transição de estados Diagrama de atividade Diagramas de Interação Diagrama de seqüência Diagrama de Interatividade Diagrama de colaboração ou comunicação Diagrama de tempo

33

34 Especificação de requisitos Descrição objetiva, precisa e completa dos requisitos do software A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz Requisitos funcionais podem ser descritos por Diagramas de Casos de Uso UML Requisitos não-funcionais são descritos textualmente.

35 Verificação e validação Validação Estamos construindo o sistema certo? Verificação Estamos construindo certo o sistema? Consistência Os requisitos não devem ser contraditórios. Completeza Os requisitos devem considerar todas as necessidades e restrições do envolvidos. Viabilidade Existe tecnologia e recursos suficientes?

36 Documento de especificação de requisitos Resultado final da etapa de análise e da fase de definição. Deve ser apresentado ao cliente para validação Usado também no desing e programação Cada desenvolvedor usa modelo específico Muitas vezes depende do método que esta sendo utilizado Deve ser textual, usando a menor quantidade de termos técnicos e ilustrando com modelos gráficos

37 Gerenciamento de requisitos Requisitos mudam durante e depois do desenvolvimento (média de 1%/mês) Causas: Novas necessidades de clientes e usuários Mudanças na tecnologia utilizada Mudanças em leis, normas ou padrões As mudanças nos requisitos podem causar impacto nos requisitos relacionados As técnicas de gerenciamento visam rastrear e controlar estas mudanças

38 O processo de levantamento análise especificação - validação.

39 Documentação Normas e padrões ANSI/IEEE STD MIL-STD-2167A e MIL-STD-498 Tópicos comuns Descrição geral Interfaces externas Requisitos funcionais Requisitos de desempenho Restrições de design Atributos de qualidade

40 Modelos (Pressman) I. Introdução 1. Referências do Sistema 2. Descrição Geral 3. Restrições de projeto do software II. Descrição da Informação 1. Representação do fluxo de informação a. Fluxo de Dados b. Fluxo de Controle 2. Representação do conteúdo de informação 3. Descrição da interface com o sistema III Descrição Funcional 1. Divisão funcional em partições 2. Descrição funcional a. Narativas b. Restrições/limitações c. Exigências de desempenho d. Restrições de projeto e. Diagramas de apoio 3. Descrição do controle a. Especificação do controle b. Restrições de projeto IV. Descrição Comportamental 1. Estados do Sistema 2. Eventos e ações V. Critérios de Validação 1. Limites de desempenho 2. Classes de testes 3. Reação esperada do software 4. Considerações especiais VI. Bibliografia VII Apêndice

41 Modelos (Farley) Visão geral do produto e Sumário Ambientes de desenvolvimento, operação e manutenção Interfaces Externas e Fluxo de Dados Requisitos Funcionais Requisitos de Desempenho Tratamento de Exceções Prioridades de Implementação Antecipação de mudanças e extensões Dicas e diretrizes de Design Critérios de aceitação Índice Remissivo Glossário