Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)

7,711 views

Published on

Este conjunto de slide faz uma breve revisão e explica o que são requisitos suplementares.
Ao final é solicitada uma atividade de pesquisa sobre diagramas de classes, o próximo assunto a ser abordado.

Published in: Education
2 Comments
13 Likes
Statistics
Notes
No Downloads
Views
Total views
7,711
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
282
Comments
2
Likes
13
Embeds 0
No embeds

No notes for slide

Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)

  1. 1. Requisitos Profª.: Rosanete Grassiani dos Santos rosaneteg@gmail.com
  2. 2. Breve revisão dos requisitos
  3. 3. O que são requisitos?  Uma sentença identificando uma capacidade, uma característica física ou um fator de qualidade que limita um produto ou um processo (IEEE 1220-1994).
  4. 4. Requisitos do usuário  É algum comportamento ou característica que o usuário deseja do software ou o sistema como um todo.  O que o usuário quer.  São escritos pelo próprio usuário ou levantados por um analista de sistemas que consulta o usuário.
  5. 5. Requisitos do sistema  É algum comportamento ou característica exigido do sistema como um todo, incluindo hardware e software.  O comportamento desejado do sistema.  São normalmente levantados por engenheiros ou analistas de sistemas, refinando os requisitos dos usuários e os transformando em termos de engenharia.
  6. 6. Características de um bom requisito  Necessário: Se retirado, ele não atenderá plenamente as expectativas do usuário.  Não devem existir requisitos do tipo “seria interessante ter”.  Deve ser levado em conta que cada requisito aumenta a complexidade e o custo do projeto.  Não-ambíguo: Possui uma e apenas uma interpretação.  Verificável: Não ser vago ou geral e sendo quantificado de uma maneira que permita a verificação de uma das seguintes formas: inspeção, análise, demonstração ou teste.
  7. 7. Características de um bom requisito  Conciso: Cada requisito define apenas um requisito que deve ser feito e apenas o que deve ser feito, de maneira clara e simples.  Não inclui explicações, motivações, definições ou descrições do seu uso.  Alcançável: Realizável a um custo definido por uma ou mais partes do sistema.  Consistente: Não contradiz ou duplica outro requisito.  Ordenável: Por estabilidade e/ou importância.  Aceito: Pelos usuários e desenvolvedores.
  8. 8. Características de um bom requisito  Requisito for funcional, deverá ser também Independente da Implementação.  O requisito define o que deve ser feito, mas não como!
  9. 9. Como fazer os requisitos?  Devemos chegar ao problema:  É necessário que todos concordem com a definição do problema.  Entender as causas do problema:  O problema por trás do problema pode ser mais importante, sendo que o problema visto inicialmente é apenas um sintoma.  Identificar todos os stakeholders e usuários.  Definir a fronteira do sistema de solução.  Identificar as restrições impostas à solução.
  10. 10. Requisitos funcionais e de informação  Requisito funcional:  Representa algo que o sistema deve fazer, ou seja, uma função esperada do sistema que agregue algum valor a seus usuários.  Requisito informação:  Representa a informação que o cliente deseja obter do sistema.  São as respostas fundamentais do sistema.
  11. 11. Requisitos não funcionais  São a forma como os requisitos funcionais devem ser alcançados.  Eles definem propriedades e restrições do sistema.  Muitos requisitos não funcionais são também requisitos de qualidade, como exigências de desempenho e robustez.  Outros são restrições ou exigências de uso de tecnologia.
  12. 12. Requisitos não funcionais
  13. 13. Exemplo de Requisitos  Em um sistema médico:  O sistema deverá permitir que um paciente marque uma consulta.  O sistema deverá confirmar que a consulta foi aceita pelo paciente.  Em um sistema para condomínios:  O sistema deverá permitir que um condômino solicite a segunda via de sua conta condominial.  O sistema deverá permitir um aviso ao condômino que não pagar sua no prazo correto.  Em um sistema para controle de produtos:  O sistema deverá permitir que um fornecedor cadastre um produto no catálogo.  O sistema deverá informar ao sistema de estoques que um produto foi vendido
  14. 14. Dicas para formular os requisitos  Use sentenças e parágrafos curtos.  Use a voz ativa.  Use verbos no futuro.  Use os termos de forma consistente e mantenha um glossário.
  15. 15. Dicas para formular os requisitos  Para cada requisito, avalie se a partir de sua definição é possível determinar se ele está pronto ou não.  Garanta que todos os requisitos são verificáveis imaginando (e possivelmente documentando) uma forma de fazê-lo.  Verifique requisitos agregados e divida-os.  Mantenha um nível de detalhe único em todos os requisitos.
  16. 16. Requisitos suplementares
  17. 17. O que são requisitos suplementares?  São requisitos não funcionais.  Os requisitos suplementares são todo tipo de restrição tecnológica ou lógica que se aplica ao sistema como um todo e não apenas a funções individuais.  Exemplo:  Errado  O sistema deve ser fácil de usar.  Certo  O sistema terá ajuda on-line em todas as telas e para todas as funções.
  18. 18. Requisitos Suplementares 18 Nome Restrição S1 Tipo de Interface As interfaces do sistema devem ser Interface implementadas como formulários acessíveis em um browser html. A camada de persistência deve ser implementada Persistência de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro ( ) ( ) ( ) (x) S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as operações. 2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente). Segurança ( ) ( ) ... ... ... ... ... S2 Armazenamento de dados Profª.: Rosanete Grassiani dos Santos Categoria Desejável Permanente 18/10/2013
  19. 19. 19 Documento de Requisitos Sistema Livir Documento de Requisitos Requisitos funcionais 1. Registrar novos títulos a partir do catálogo das editoras. 2. Registrar vendas de livros. 3. Realizar encomendas de livros. 4. Registrar e autorizar pagamentos com cartão de crédito. 5. Registrar e aplicar promoções. 6. Calcular custos de entrega. 7. Emitir relatório de livros mais vendidos. 8. Emitir relatório de compradores mais assíduos. 9. Emitir sugestões de compra para compradores baseadas em compras anteriores. Requisitos suplementares 1. O sistema deve operar via interface Web 2. Todos os controles de interface devem ter um campo de ajuda associado. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  20. 20. 20 Documento de Requisitos Alternativa 2 Profª.: Rosanete Grassiani dos Santos 18/10/2013
  21. 21. Desafios da Análise de Requisitos 21  Como descobrir os requisitos.  Como comunicar os requisitos para as outras fases ou equipes do projeto.  Como lembrar dos requisitos durante o desenvolvimento e verificar se foram todos atendidos.  Como gerenciar a mudança. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  22. 22. 22 Organização dos Requisitos  Casos de Uso  Os principais processos  “Manutenção” de Conceitos  Implementação das operações de cadastro  Consultas/Relatórios  Acesso à informação que não altera a informação em si Profª.: Rosanete Grassiani dos Santos 18/10/2013
  23. 23. 23 Organizando Requisitos em Casos de Uso  O objetivo de listar os casos de uso é levantar informações sobre como o sistema interage com possíveis usuários e quais consultas e transformações são necessárias além daquelas já identificadas na fase de levantamento de requisitos. Nome Realizar venda de livros Realizar encomenda de livros Registrar e aplicar promoções Atores Cliente Gerente Gerente Descrição O cliente se identifica e identifica os livros que deseja levar efetuando ao final o pagamento com cartão de crédito. O gerente autoriza a encomenda de livros faltantes e lançamentos as editoras. Referências Cruzadas F1, F3, F5, F9, F10 O Gerente configura as promoções válidas em determinado período. F11, F12 Profª.: Rosanete Grassiani dos Santos F2, F4, F6, F7, F8 18/10/2013
  24. 24. 24 Organizando Requisitos em Casos de Uso  Para descobrir os casos de uso, devem-se identificar os atores envolvidos com o sistema. Para tanto, o analista deve responder algumas perguntas:  Quem usa o sistema?  Quem mantém e configura o sistema?  Quais os outros sistemas de informação utilizam ou são utilizados pelo sistema?  Quem busca informações no sistema?  Quem provê informações para o sistema? Profª.: Rosanete Grassiani dos Santos 18/10/2013
  25. 25. 25 Diagrama de Casos de Uso UML Profª.: Rosanete Grassiani dos Santos 18/10/2013
  26. 26. 26 Diagrama de Casos de Uso UML Profª.: Rosanete Grassiani dos Santos 18/10/2013
  27. 27. 27 Diagrama de Casos de Uso UML Profª.: Rosanete Grassiani dos Santos 18/10/2013
  28. 28. Granularidade de um Caso de Uso 28  Um caso de uso deve ser monossessão, ou seja, executado em uma única interação e não se estendendo ao longo de vários dias .  Um caso de uso deve ser interativo, com informações fluindo para dentro e para fora do sistema .  Um caso de uso deve produzir uma alteração consistente na informação armazenada. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  29. 29. 29 Organização de Requisitos em Função de Conceitos  Algumas operações relativamente simples e elementares (de um único passo), como o registro de uma fita, ou de um pagamento, não devem ser consideradas como casos de uso por si só, pois não há necessidade de se estudar seu processo interativo, que é de um único passo. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  30. 30. 30 Organização de Requisitos em Função de Conceitos  Sugere-se a criação de um modelo conceitual preliminar para facilitar esta tarefa.  Indicar apenas os conceitos e associações que constituem informação a ser armazenada pelo sistema. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  31. 31. 31 Como Encontrar Conceitos e Atributos  Verificar o texto dos casos de uso expandidos.  Selecionar termos que representam informação transmitida do e para o sistema.  Agrupar sinônimos Profª.: Rosanete Grassiani dos Santos 18/10/2013
  32. 32. 32 Cada conceito normalmente tem associadas operações de:  inserção (I)  alteração (A)  exclusão (E)  consulta (C)  Também podem ser identificadas restrições ou regras de validação para execução das operações Profª.: Rosanete Grassiani dos Santos 18/10/2013
  33. 33. 33 Tabela para Representar Operações de “Manutenção” Conceito Cliente Reserva Livro Vendas I x x x A x x x E x x x x C x x x x Profª.: Rosanete Grassiani dos Santos Observação Só é possível excluir se não houver vendas associadas Ref. Cruzadas F13 F15, F16 Só é possível excluir se não houver vendas associadas F18 A inclusão das vendas só pode acontecer através do caso de F17, F19 uso “Registrar venda de livros”. Não é possível alterar uma vendas, apenas excluir. 18/10/2013
  34. 34. 34 Modelo Conceitual Preliminar Profª.: Rosanete Grassiani dos Santos 18/10/2013
  35. 35. 35 Modelo Conceitual Preliminar Profª.: Rosanete Grassiani dos Santos 18/10/2013
  36. 36. 36 Organização de Requisitos em Consultas  A identificação das consultas/ relatórios desejados na fase de concepção pode ajudar muito no levantamento dos requisitos e na elaboração do sistema.  Não precisam ser tratados como casos de uso.  São listados para auxiliar a construção das etapas posteriores. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  37. 37. 37 Organização de Requisitos em Consultas Nome Vendas Mensais Clientes Suspensos ... Profª.: Rosanete Grassiani dos Santos Referências Cruzadas F20, F21, F22 F13, F23, F1 ... 18/10/2013
  38. 38. Planejamento do Desenvolvimento 38  Alocar o desenvolvimento em ciclos iterativos de mesma duração.  Estimativa de Esforço:  Pontos de Função  Pontos de Caso de Uso Profª.: Rosanete Grassiani dos Santos 18/10/2013
  39. 39. 39 Estabelecendo Prioridades  Casos de Uso Críticos  Casos de Uso de Apoio  Conceitos  Consultas Profª.: Rosanete Grassiani dos Santos 18/10/2013
  40. 40. Planejamento dos Ciclos Iterativos 40 Ciclo 1 2 3 4 Casos de Uso Vender Livros (550) Manutenção de Informações - Consultas Observações - Encomenda Livros (300) Reservar Livros (270) - - - Livro (100), Cliente (100) e Reserva (100) Venda (100) - Neste ciclo ainda não será implantado o mecanismo de persistência Implementar mecanismo de persistência (300 horas) - todas (400) - Profª.: Rosanete Grassiani dos Santos Esforço estimado 550 horas 600 horas 570 horas 500 horas 18/10/2013
  41. 41. 41 Cronograma de Execução  Considerar:  Tempo total estimado para o projeto (em hora/pessoa).  Tempo disponível (em semanas ou meses).  Tamanho da equipe.  Estruturação da equipe. Profª.: Rosanete Grassiani dos Santos 18/10/2013
  42. 42. 42 Planejamento com 4 equipes Dias: 1-10 11-20 Ciclo 1 análise projeto Ciclo 2 análise Ciclo 3 Ciclo 4 Implantação 21-30 implementação projeto análise Profª.: Rosanete Grassiani dos Santos 31-40 testes implementação projeto análise 41-50 51-60 61-70 70-90 testes implementação testes projeto implementação testes implantação 18/10/2013
  43. 43. 43 Planejamento com 2 equipes Dias: Ciclo 1 Ciclo 2 Ciclo 3 Ciclo 4 Implantação 1-20 análise 21-40 projeto 41-60 impl. análise Profª.: Rosanete Grassiani dos Santos 61-80 testes projeto 81-100 101-120 impl. análise testes projeto 121-140 141-160 161-180 181-200 impl. análise testes projeto impl. 201-220 testes implant. 18/10/2013
  44. 44. Dúvidas?
  45. 45. Atividade  Fazer uma pesquisa sobre diagrama de classes.  O que é?  Como funciona?  Fazer um exemplo.  Entregar em documento word ou escrito a mão.  Para o diagrama de classe deste trabalho não deverá ser utilizada ferramenta de diagramação.  Entrega no e-mail: rosaneteg@gmail.com até 25/10/2013. Não serão aceitos trabalhos após esta data!
  46. 46. Requisitos Profª.: Rosanete Grassiani dos Santos rosaneteg@gmail.com

×