Análise ou Especificação de Requisitos

1. Análise ou Especificação de Requisitos Silvia Regina Vergilio - UFPR

2. 1) Objetivos • O escopo do projeto é refinado em detalhe e será produzida uma especialização de requisitos. • Objetivos Fornecer traduzida Projeto, dados informação  procedimentos, representações para arquitetura

3. 1) Objetivos – Aspecto Fundamental • Comunicação com o Uusário “Eu sei que você acredita ter entendido o que você pensa que eu disse, mas não estou certo se você está ciente de que o que você ouviu não é o que eu queria dizer.” Cliente anônimo.

4. 1) Objetivos - Documentos Gerados • Especificação de Requisitos de Software • Manual Preliminar do Usuário • Plano de Projeto do Software (revisto).

5. 2) Extração de Requisitos • Requisito: condição necessária para a obtenção de certo objetivo ou para o preenchimento de certo fim • Requisito de software: requisitos que o produto a ser desenvolvido deve possuir

6. 2) Extração de Requisitos • Requisitos funcionais: funcionalidade, o que o software deve fazer • Requisitos não funcionais: confiabilidade (disponibilidade, integridade, segurança), acurácia, desempenho, interface HM, portabilidade, etc. • Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade

7. 2) Extração de Requisitos – Engenharia de Requisitos Processo de transformação das idéias que estão na mente do usuário (entradas) em um documento formal (saída).

8. 2) Extração de Requisitos – Dificuldades • Para conseguir informação pertinente. • Para lidar com a complexidade. (Tornar o problema manipulável; detectar omissões, inconsistências ) • Para acomodar mudanças. (Coordenar, avaliar impacto; corrigir defeitos sem gerar erros)

9. 2) Extração de Requisitos – Principais Causas • 1. Deficiências na comunicação • 2. Técnicas e ferramentas inadequadas • 3. Desconsideração de alternativas. É necessário aplicar: -princípios fundamentais de análise -métodos sistemáticos de análise

10. 2) Extração de Requisitos – O Analista • Absorver fatos a partir de fontes conflitantes ou confusas. • Entender os ambientes do usuário/cliente. • Comunicamos bem na forma verbal e escrita. • “ Enxergar a floresta apesar das árvores”

11. 2) Extração de Requisitos – Engenharia de Requisitos Passos: • Entendimento do domínio de aplicação • Extração e análise de requisitos: classificação e organização • Especificação dos requisitos – modelos • Validação – necessidades do usuário

12. 2) Extração de Requisitos – Tarefas • 1. Reconhecimento (identificação do problema ) • 2. Avaliação do problema e síntese de soluções gerais + critérios de validação. • 3. Representação dos requisitos => software • 4. Revisão da especificação reexame do Plano de Projeto de Software.

13. 2) Extração de Requisitos – Quem participa • desenvolvedor • pessoal de apoio e documentação • usuários ou potenciais usuários • outras fontes de informações: pessoas e documentos

14. 2) Extração de Requisitos – Procedimentos Genéricos • Perguntar – identificar o usuário • Observar e inferir – comportamento do usuário, inferir suas necessidades • Negociar a partir de um conjunto padrão de requisitos • Estudar e identificar problemas • Supor – se o produto é novo comparar com existentes

15. 3) Técnicas de Extração de Requisitos - Entrevistas • Identificar candidatos • Preparação para entrevista • agendar • preparar questões • Condução da entrevista

16. 3) Técnicas de Extração de Requisitos - Entrevistas • Condução da entrevista • apresentação e objetivos • esperar respostas incompletas • repetir frases do entrevistado com suas próprias palavras • perguntas do tipo sim/não – dúvidas • não se perder em detalhes • o entrevistado precisa ter o contexto

17. 3) Técnicas de Extração de Requisitos - Entrevistas • Finalização tempo, resposta à todas as perguntas consolidar informações (5min), agradecimentos • Geração de um documento escrito, planejar próximos passos

18. 3) Técnicas de Extração de Requisitos - Braimstorming • Técnica para geração de idéias • Reuniões entre desenvolvedores e usuários • Um líder é necessário • Geração e consolidação das idéias • Ausência de crítica e julgamento • Elimina dificuldades de comunicação

19. 3) Técnicas de Extração de Requisitos - PIECES • Geralmente é aplicada na análise de produtos já existentes, mas pode ser adaptada • Fornece um conjunto de categorias de questões e de problemas para o desenvolvedor extrair os requisitos

20. 3) Técnicas de Extração de Requisitos - PIECES Seis categorias: P - desempenho I - informação E - economia C - controle E - eficiência S - serviços

21. 3) Técnicas de Extração de Requisitos - JAD JAD – Joint Application Design • Princípios básicos: • dinâmica de grupo • uso de técnicas visuais • manutenção do processo organizado e racional • utilização de documentação padrão • Etapas: planejamento e projeto

22. 3) Técnicas de Extração de Requisitos - JAD Seis tipos de participantes • líder • engenheiro de requisitos • executor • representantes do usuário • representantes de produtos de sw • especialista

23. Sessão Um ou mais Encontros requisitos desenvolvidos e documentados 3) Técnicas de Extração de Requisitos - JAD Adaptação Preparar Organizar Equipe e Material Finalização Converte a informação final em um documento

24. 3) Técnicas de Extração de Requisitos - Prototipação 1. Determinar se o software é um bom candidato • Áreas de aplicação : interface, . . . • Complexidade : desenvolvimento de muito código inviabiliza a prototipação (particionável) • Característica do cliente e gerente 2. Representação Resumida de Requisitos => particionamento . 3. Um projeto rápido ( arquitetura e dados ).

25. 3) Técnicas de Extração de Requisitos - Prototipação 4. Protótipo é criado e testado. • Técnicas de quarta geração • Reutilização de Software • Ferramentas de Videoconferência • Especialização formal + ambientes interativos. 5. Teste pelo usuário - sugestões (+importante). 6. Repetição de 4 e 5 até que todos os requisitos sejam formalizados; ou que o protótipo tenha evoluído.

26. 4) Modelos para Especificação • Representam a realidade • Ajudam a organização e especificação mas não na extração • Utilizam os princípios de abstração e decomposição – lidar com complexidade • Existem diferentes tipos de especificação ao longo do desenvolvimento e em vários níveis.

27. 4) Modelos para Especificação – Especificação pode ser • Especificação dos requisitos – cliente e desenvolvedor • Especificação de projeto geral – projetista e implementador • Especificação de módulos – programadores que utilizam e implementam os módulos

28. 4) Modelos para Especificação Princípios - Boa Especificação • Separar funcionalidade de implementação • Deve abranger o sistema do qual o sw é um componente • Deve ser operacional (utilizável) • Tolerante a incompleteza • Consistente

29. 4) Modelos para Especificação Princípios - Boa Especificação • Realista • Fracamente acoplada e localizada • localizada: para que um único elemento tenha que ser modificado • fracamente acoplada: permitir que adições e remoções sejam feitas facilmente

30. 4) Modelos para Especificação • Permitem a aplicação dos princípios de ES. • Geralmente cobrem três dimensões do sistema • dados (que dados ele mantém) • funções (o que o sistema faz) • comportamento (como ele se comporta – estados e eventos)

31. 5) Diagrama de Fluxo de Dados – Modelo de Função

32. 5) Diagrama de Fluxo de Dados – Modelo de Função O DFD é um modelo que nos permite mostrar como a informação (dados) flui através de um sistema (ou seja, como ela vai sendo transformada ou organizada) • são recebidos • podem ser armazenados • podem fluir de um processo a outro • podem ser transferidos para o ambiente externo

33. 5) Diagrama de Fluxo de Dados – Modelo de Função ______

34. 5) Diagrama de Fluxo de Dados (DFD) - Exemplo Agente de Viagem Preparação de Bilhete Horário, dia, destino Dados do vôo Bilhete Sistema de Reserva Informação sem vôos Custo Sistema de Cobrança Cliente Conta Diretórios de vôo Dados contábeis Arquivo de Contabilidade

35. 5) Diagrama de Fluxo de Dados (DFD) – Como construir

36. 5) Diagrama de Fluxo de Dados (DFD) – Como construir

37. 5) Diagrama de Fluxo de Dados (DFD) – Como construir • Particionar as funções em sub-funções: • uma bolha deve ser particionada por vez • rótulos dos fluxos, bolhas e arquivos devem ser significativos • a continuidade da informação deve ser mantida

38. 5) Diagrama de Fluxo de Dados (DFD) – Como construir A B F x A f4 z B y x z y

39. 5) Diagrama de Fluxo de Dados (DFD) – Quando parar • O DFD mostra as transformações de todas as entrada em saídas • Os sub-processos não particionados podem ser considerados elementares • Cada bolha está conectada corretamente ao resto da rede • As conexões foram minimizadas

40. 5) Diagrama de Fluxo de Dados (DFD) O DFD não mostra: • descrição dos fluxos • nem mecanismos de sincoronização • comportamento

41. 5) Diagrama de Fluxo de Dados – Extensão Tempo Real Fluxo de dados que não é contínuo temp - max  temp - medida. Transforma controle ou eventos. Representa eventos. Armazena itens de controle ou eventos.

42. 5) Diagrama de Fluxo de Dados – Extensão Tempo Real Monitora ph Processo de Controle ph no nível desejado Inicia Pára Ativa/Desativa Muda ph ph ativa Controle da Válvula de entrada Mantém ph constante Ativa/Desativa

43. 6) Modelo Entidade Relacionamento (MER) • Dados descrevem coisas do mundo real. • Itens de dados relacionados devem ser agrupados • Ex: nome, endereço, RG são informações do sistema relacionados a uma entidade do mundo real que é o cliente. • Ainda podemos ter relacionamentos entre entidades

44. 6) Modelo Entidade Relacionamento (MER) DER – Diagrama Entidade Relacionamento

45. 6) Modelo Entidade Relacionamento (MER) DER – Diagrama Entidade Relacionamento Exemplo

46. 6) Modelo Entidade Relacionamento (MER) • Existem muitas ferramentas • Fácil de entender • Não diz como se forma o atributo CIC • Não fica claro

47. 7) Máquina de Estados Finitos (MEF) • Os modelos de comportamento do sistema devem mostrar estados eventos que alteram esses estados • Eventos são condições e ações para se mudar de estado.

48. 7) Máquina de Estados Finitos (MEF) Uma MEF é dada por: (S, s0, I, ), S – conjunto finito e não vazio de estados S0S – estado inicial I – conjunto finito de entradas (A (ações) e C (condições)) que podem ser nulas :SxI  S - função de transição de estados

49. 7) Máquina de Estados Finitos Diagrama de Estados (DTE)

50. 7) Máquina de Estados Finitos Diagrama de Estados (DTE)