Modelagem e Levantamento de Requisitos

1. Modelagem e Levantamento de Requisitos ►METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala e-mail: abdala@das.ufsc.br

2. Objetivos Apresentar técnicas para levantamento de requisitos; Demonstrar como levantar requisitos de usabilidade usando prototipação de interfaces; Discutir a decomposição de requisitos Apresentar como levantar requisitos de interação por meio de casos de uso.

3. Plano Problemas relacionados ao levantamento de requisitos Documento de descrição do projeto Decomposição de requisitos Classificação de requisitos Especificação de interfaces do usuário Diagrama de Casos de Uso

4. Levantamento de Requisitos • Em que pé estamos? • Sabemos quais os tipos de requisitos existentes • Sabemos que requisitos podem ser definidos em vários níveis de detalhamento • Sabemos como descrever os requisitos usando diagramas e tabelas • E agora? • Ao tentarmos especificar os requisitos nos deparamos com problemas e incertezas. • Solução – Precisamos de uma metodologia para levantamento de requisitos!

5. Descrição textual do sistema • Um bom ponto de partida para a identificação dos elementos que comporão o sistema • Texto escrito pelo cliente e/ou usuário descrevendo como eles imaginam o sistema; • Precisa ser minerado para a extração de requisitos • A extração de requisitos via a descrição textual do sistema fornece uma maneira prática de levantar muitos requisitos. No entanto aspectos dinâmicos da execução do sistema podem não ser capturados corretamente.

6. Exemplo – Jogo de Damas O sistema consiste em um programa que permite 1 ou 2 pessoas jogar damas. Uma interface gráfica representado o tabuleiro é apresentada em estado inicial com as peças dispostas a cada início de partida. O jogador pode clicar na peça que deseja mover e em seguida na casa para a qual a peça deve ser movida. O sistema testará se o movimento é válido e se este for o caso, a peça será movimentada. O jogador pode também disputar uma partida contra o computador. O computador poderá jogar no modo “fácil”, “normal”, “avançado”, “impossível”.

7. “Dissecando” o Exemplo O sistema consiste em um programa que permite 1 ou 2 pessoas jogar damas. Uma interface gráfica representado o tabuleiro é apresentada em estado inicial com as peças dispostas a cada início de partida. O jogador pode clicar na peça que deseja mover e em seguida na casa para a qual a peça deve ser movida. O sistema testará se o movimento é válido e se este for o caso, a peça será movimentada. O jogador pode também disputar uma partida contra o computador. O computador poderá jogar no modo “fácil”, “normal”, “avançado”, “impossível”.

8. Observações Permite a identificação de funcionalidades, restrições e entidades do sistema; Ótimo ponto de partida para a especifica-ção inicial dos requisitos Problemas para a identificação de requisi-tos dinâmicos Serve como base para “entender” o objetivo do sistema e planejar as entrevis-tas subseqüentes de levantamento de requisitos

9. Especificação de Interfaces Maneira útil de definir requisitos de interação com o usuário Fornece uma base para discussão de funcionalidades com o usuário Parte visível do sistema, geralmente mais suscetível a críticas e pedidos de alteração

10. Exemplo de Protótipo de Interface

11. Decomposição de Requisitos Muitas vezes a descrição inicial de um requisito pode ser muito extensa englobando diversas funcionalidades; Requisitos Funcionais e Não Funcionais tendem a se misturar, principalmente na etapa de elaboração de requisitos do usuário; Decompor requisitos significa dividir requisitos complexos em dois ou mais requisitos.

12. Exemplo: Decomposição de Requisitos Registrar Cliente O Sistema deve ser capaz de registrar Contas para Clientes, recolhendo seus dados pessoais, de modo a identificá-los. Ele deve exigir do Cliente um Login único e uma Senha, para que ele possa ter uma Conta. Registrar Cliente O Sistema deve ser capaz de registrar Contas para Clientes, recolhendo seus dados pessoais, de modo a identificá-los Cadastrar Conta O Sistema deve exigir do Cliente um Login único e uma Senha, para que ele possa ter uma Conta.

13. Decomposição de Requisitos • Requisitos são a posteriori mapeados em artefatos de software • Requisitos bem definidos com escopo específico são: • mais simples de serem implementados • Pertencerão a mesma unidade lógica • Permitirão a adoção de uma arquitetura sólida para o sistema

14. Classificação de Requisitos • Sistemas reais tendem a ter centenas ou até mesmo milhares de requisitos • Classificar os requisitos auxilia a: • Organizar os requisitos em subsistemas (pacotes) • Executar o rastreamento de alterações • Geralmente apenas requisitos não-funcionais são classificados, no entanto também é possível aplicar algum tipo de classificação aos requisitos funcionais

15. Requisitos Não-Funcionais

16. Casos de Uso Casos de Uso (CdU) incluem tipicamente um ou mais cenários que descrevem as interações que ocorrem entre os atores e o sistema. CdUs também documentam as exceções que ocorrem do ponto de vista do usuário Cada CdU representa uma única interação repetível que um usuário ou ator vivencia ao utilizar o sistema Casos de uso podem incluir outros casos de uso como parte de um padrão de interação mais complexo. Eles também podem ser utilizados por outros casos de uso para lidar com situações excepcionais Diagrama UML (UnifiedModelingLanguage)

17. Elementos dos CdUs Casos de uso Atores Relacionamentos envolvendo esses elementos

19. Finalidade do Diagrama de Casos de Uso • Modelar as funcionalidades do software (os casos de uso) • O que o software faz (e não como faz) • Modelar os elementos externos que interagem com o software (atores)

20. Casos de Uso • Uma funcionalidade do software • Atômica, completa (não uma fração) • Externamente perceptível • EX: cada uma das opções do menu de um caixa eletrônico de banco • emissão de extrato de conta corrente

21. Representação de um Ator • Associado à noção de que um software interage com o meio externo • Representa uma entidade externa que interage com o software sob modelagem • Pessoa • Equipamento (hardware) • Outro software • Função de um ator • Representa a interação com um elemento externo • Faz parte do sistema (elemento interno) • Modela a interface com cada elemento externo

22. Representação de um Caso de Uso Apenas a identificação de uma funcionali-dade, sem qualquer referência a como ela é executada

23. Relacionando Atores a Casos de Uso • UML prevê três tipos de relacionamentos • Extensão • Inclusão • generalização

24. Extensão Estabelece uma relação em que um dos casos de uso ou atores tem seu comportamento estendido através do comportamento definido em outro caso de uso. Freqüentemente expressa um fluxo alternativo

25. Inclusão • Estabelece que parte do comportamento inerente a um caso de uso está definida em outro caso de uso • Um caso de uso contém o comportamento definido em outro caso de uso • Permite evitar repetições na modelagem

26. Generalização • Estabelece uma relação de especiali-zação entre dois casos de uso, onde • Um corresponde a um comportamento genérico • O outro, a uma especialização deste para alguma situação específica

27. Outros Tipos de Relacionamento Utilização – indica que um elemento requer o outro para ser utilizado. Relacionamento básico dos CdUs; Associação – representa uma associação entre dois elementos do diagrama; Implementação – o elemento origem implementa o elemento destino ; Invocação – CdU A em algum ponto faz com que CdU B seja executado; Precedência – CdU A deve ser executado antes que CdU B o seja.

28. Considerações sobre CdU Diagrama de CdU fornece um resumo da interação Detalhamento da interação deve existir em forma textual em um documento associado ao CdU

29. Pontos Chave Documento de descrição auxilia na identifi-cação de requisitos; Prototipação de Interfaces auxilia na identi-ficação de requisitos de usabilidade; Requisitos devem ser decompostos para que representem apenas funcionalidades ou restrições atômicas; Requisitos dinâmicos podem ser melhor levantados por meio de casos de uso.

30. Referências R. S. Pressman, Engenharia de Software, McGraw Hill, 6a Ed., 2002. Chap. 12. I. Sommerville. Software Engineering. 7th Ed. Addison-Wesley, 2004. Chap. 7,16.