Unidade 11: Princípios e Conceitos de Análise de Requisitos

1. Módulo III: Métodos Convencionais de Engenharia de Software Unidade 11: Princípios e Conceitos de Análise de Requisitos Prof. Dr. Marcelo Augusto Santos Turine DCT - UFMS mast@dct.ufms.br

2. Objetivos • Descreve o processo de Análise de Requisitos do Software como um processo de refinamento do produto inicial desenvolvido durante a Engenharia de Sistemas • Engenharia de Requisitos é um processo de descoberta, refinamento, modelagem e especificação • Requisitos são refinados nesta FASE!!! • Modelos de dados, fluxo de controle e informação, comportamental, Visão OO (Diagrama de Classes, Casos de Uso) são construídos

3. Objetivos • Engenheiro de Software e Clientes (ATORES) têm papel fundamental nesta fase • Cliente: reformular e refinar as descrições nebulosas em detalhes concretos • Desenvolvedor: atua como interrogador, consultor, resolvedor de problema e negociador • Comunicação é ALTA>>>>>>>

4. O ciclo de vida clássico Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção

5. Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade • Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor

6. Engenharia de Sistemas de Computador ANÁLISE DE REQUISITOS Projeto de Software Fase de Análise de Requisitos PONTE Escopo do Software • Primeiro passo técnico • Analista de Sistemas

7. Plano do Projeto Especificação do Sistema Especificação de Requisitos ANÁLISE DE REQUISITOS

8. Análise de Requisitos processo de descoberta e refinamento • ATORES: cliente e desenvolvedor • Cliente: reformula um conceito de função e desempenho (às vezes nebuloso) • Desenvolvedor: indagador e solucionador de problemas • PROBLEMA: grande propensão a mal entendidos"atividade aparentemente simples torna-se complexa"

10. Definição: Requisitos e Especificação • Glossário de Engenharia de Software (IEEE) e do Aurélio • Requisito (IEEE) • Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo • Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão

11. Requisito (Aurélio) • Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim • Especificação: • descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar • processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida

12. Exemplos • “O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior.” • “A interface do sistema deve ser gráfica, de acordo com um padrão de interface dirigida a menu.” • “Alternativamente, o sistema deve possibilitar o seu uso através de linhas de comando, para usuários avançados.”

13. Tipos de Requisitos (divisão utilizada na literatura) • Funcionais • Não Funcionais (de Qualidade) ISO -The International Organization for Standardizatized IEC - The International Electrotechnical Commition (formam o sistema especializado para padronização mais conhecido)

14. Requisitos de Software • A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: • Funcionalidade (finalidade do produto) • Usabilidade (esforço para utilizar, aprender o produto) • Confiabilidade (freqüência de falhas, recuperabilidade) • Eficiência (desempenho) • Manutenibilidade (esforço necessário para modificar) • Portabilidade (capacidade de transferir o produto para outros ambientes)

15. elementos alocados ao software estabelecimento do alcance recursos, custo cronograma revisão administrativa revisão aceitável não sim os requisitos são conhecidos? determinar domínio das informações e das funções, interfaces, restrições de projeto e critérios de validação construir protótipo para estabelecer os requisitos Plano de Desenvolvimento do Software revisão revisão técnica aceitável revisar e justificar recursos, custos e cronogramas revisão do plano de projeto do software aceitável início da fase de desenvolvimento Especificação dos Requisitos do Software fase de Análise de Requisitos

16. Dilema do Engenheiro de Software Declaração de um cliente anônimo: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer ... ”

17. ATIVIDADES de ANÁLISE: 1 - Reconhecimento do problema2- avaliação do problema e síntese da solução 3 - Modelagem 4 -Especificação dos requisitos do software 5-Revisão

18. Atividade 1 Reconhecimento do Problema A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente. Administrador do projeto analista desenvolvedores clientes Plano de projeto de software Espec. requisitos do sistema protótipo

19. Atividade 2 Avaliação do Problema e Síntese da Solução • Avaliar os problemas na situação atual • Principal Foco para o novo sistema: O QUE e não COMO: - qual o fluxo e o conteúdo de informação - quais as funções do sistema- quais dados que o sistema produz e consome - qual o comportamento do sistema- qual as características de interface- quais são as restrições do projeto

20. Avaliação do Problema e Síntese da Solução • Sintetizar uma ou mais soluções (dentro do alcance delineado no Plano de Projeto do Software) O processo de avaliação e síntese continua até que o analista e o cliente concordem que o software pode ser adequadamente especificado. É a maior área de esforço

21. Atividade 3Modelagem • Durante a atividade de avaliação e síntese devem ser criados modelos do sistema para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental, além do conteúdo da informação. • O modelo serve como fundamento para o projeto de software e como base para a criação de sua especificação

22. Atividade 4 Especificação de Requisitos • Definição de Especificação: descrição rigorosa e minuciosa das características que um material, uma obra ou um serviço deverão apresentar • descrição do fluxo e estrutura da informação • refinamento detalhado de todas as funções do software • estabelecimento das características de interface • identificação das restrições de projeto • especificação dos critérios de validação

23. Atividade 5Revisões Devem ser efetuadas revisões técnicas e revisões no Plano de Projeto de Software • as revisões são conduzidas pelo Cliente e pelo Desenvolvedor • a base para a revisão são os documentos produzidos na Especificação dos Requisitos O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise.

24. Analista de Sistemas • Engenheiro de Sistemas • Projetista de sistemas-chefe • Programador/Analista

25. Características do Analista de Sistemas - Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão. 2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas. 4- Capacidade de se comunicar bem de forma escrita e verbal. 5- Capacidade de "ver a floresta ao invés das árvores” (não se perder nos detalhes)

26. Papel do Analista de Sistemas 1- Coordenar cada uma das atividades da Análise de Requisitos de Software - comunicação com cliente - convoca pessoal de desenvolvimento durante avaliação e síntese 2- Responsável pelo desenvolvimento do documento de Especificação de Requisitos do Software e participa de todas as revisões

27. Áreas Problemas 1. Aquisição da Informação 2. Tamanho do Sistema (complexidade dos problemas) 3. Alterações (mudanças que ocorrem durante e após a análise)

28. Áreas Problemas 1. Aquisição da informação • que informação deve ser coletada e como ela deve ser representada? • quem fornece as informações? • que técnicas e ferramentas estão disponíveis para facilitar a coleta de informações?

30. Áreas Problemas 2. Tamanho do sistema • como eliminar inconsistências na especificação de grandes sistemas? • é possível detectar omissões? • pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrável?

31. Áreas Problemas 3. Alterações • como as alterações efetuadas em outros elementos do software são coordenadas com os requisitos do software? • como se determina o impacto de uma alteração em outras partes do software aparentemente não relacionadas? • como se corrige erros na especificação para que não se gere efeitos colaterias?

32. Causas dos Problemas • comunicação ineficiente • técnicas e ferramentas inadequadas (especificação inadequada e imprecisa) • tendências de se eliminar a tarefa de Especificação dos Requisitos • falhas ao considerar alternativas antes que o software seja especificado

33. Abordagem de Engenharia de Software • Aplicação de técnicas de comunicação sólidas • Princípios de análise fundamentais • Métodos de análise sistemáticos reduzirão o impacto dos problemas

35. Responde ao pedido de ajuda do cliente Problema cuja solução é baseada em computador

36. Princípios Fundamentais de Análise... • Vários métodos de modelagem de Análise foram desenvolvidos • Cada método tem suas vantagens e pontos de vista, porém, cinco princípios são comuns: • O domínio de informação do problema deve ser representado e compreendido • As funções que o software deve realizar devem ser definidas • O comportamento do software (conseqüência de eventos externos) deve ser representado • Os modelos (informação, função e comportamento) devem ser particionados em uma hierarquia • O processo de análise deveria iniciar a partir de informações básicas para detalhes de implementação

37. Princípios Fundamentais de Análise • domínio de informaçãodo problema representado e compreendido (para que a função possa ser entendida + completamente) • modelosque descrevam a informação, a função e o comportamento do sistemadesenvolvidos(para que a informação possa ser comunicada compactamente)

38. Princípios de Análise • modelos (e o problema) particionados, de maneira que revele os detalhes em forma de camadas (ou hierarquicamente) (para reduzir a complexidade) • processo de análise mover-se da informação essencial para os detalhesde implementação (para acomodar as restrições lógicas impostas por requisitos de processamento e as restrições físicas impostas por outros elementos do sistema) = (Concepções lógicas e físicas)

39. 1 princípio:Domínio da Informação Todo software é construído para processar dados e eventos. Dados: software embutido de tempo real para controlar o fluxo de combustível no motor de automóvel Eventos: um sensor de pressão detecta que a pressão ultrapassa determinado valor de segurança e envia um sinal de alarme para o software de monitoração

40. 1 princípio:Domínio da Informação Os dados e itens de controle residem no domíniode informação de um problema. Encerra 3 diferentes pontos de vista: Fluxo Conteúdo Estrutura da informação

41. 1 princípio: Domínio da Informação Fluxo da Informação:maneira pela qual os dados e o controle se modificam à medida que cada um se movimenta pelo sistema Conteúdo da Informação:os dados e os itens de controle individuais que compreendem certo item de informação mais amplo. - o conteúdo do item de dados cheque de pagamento é definido pelos itens que são necessários para criá-lo: nome do recebedor, quantidade líquida a ser paga, pagamento bruto, etc. Estrutura da Informação: a organização interna de vários itens de controle e de dados

43. 2. princípio:Modelagem • Modelos: melhor compreensão da entidade real a ser construída • Entidade é física (prédio): modelo idêntico, mas em escala menor • Entidade é software: • o modelo deve ser capaz de modelar a informação que o software transforma • as funções (ou subfunções) que possibilitam que as transformações ocorram • o comportamento do sistema quando a transformação está se desenvolvendo.

44. 2. princípio:Modelagem Os modelos concentram-se naquilo que o sistema deve fazer, não em como ele faz. • Modelos fazem uso de notação gráfica e textual • Os métodos de análise discutidos nos capítulos seguintes são métodos de modelagem • Atividade de Modelagem é fundamental ao bom trabalho da análise

45. 2. princípio:Modelagem Papéis importantes do Modelo: 1) ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa + fácil e sistemática. 2) torna-se o ponto focal para a revisão e, portanto, a chave para a determinação da completitude, consistência e precisão da especificação. 3) torna-se a base para o projeto, fornecendo ao projetista uma representação essencial do software, a qual pode ser "mapeada" num contexto de implementação.

47. 3. princípio:Particionamento (decomposição) Os problemas freqüentemente são grandes demais e muito complexos para serem compreendidos como um todo. O particionamento divide o problema em partes mais facilmente entendidas Através das interfaces estabelecidas entre as partes a função global do software pode ser executada.

48. 3 princípio: Particionamento Particionamento horizontal Particionamento Horizontal: decomposição funcional do problema Particionamento Vertical: expõe detalhes crescentes

50. 4 princípio:Visões essenciais e de implementação A visão essencial dos requisitos do software apresenta as funções a serem realizadas sem tratar dos detalhes de implementação. Ao se concentrar atenção na essência do problema nas primeiras etapas da análise de requisitos, deixa-se as opções abertas para especificar detalhes de implementação durante as últimas etapas de especificação dos requisitos e projeto de software.