Análise e Modelação de Sistemas

Transcrição

1 Análise e de Sistemas AulaT03 - Engenharia de Requisitos Referências: 1 Conceptual Modeling of Informa5on Systems (Secção 1.4) 2 Nuseibeh, B. and Easterbrook, S Requirements engineering: a roadmap. ACM, New York, NY, 35-46, DOI= hup://doi.acm.org/ / IEEE Std IEEE Recommended Prac5ce for SoYware Requirements Specifica5ons 4 Aulas AMS do IST

2 2 Engenharia de Abordagem sistemá>ca à documentação, validação e gestão de Processo de Engenharia de Elicitação de Análise de Requisitos Negociação de Especificação/documentação de Validação de

3 3 Requisitos e Stakeholders Requisitos Condição ou capacidade que deve ser sa5sfeita pelo sistema Originada de Decisões ou pedidos dos stakeholders Impostas por standards, regulamentos, leis, etc. Stakeholders Qualquer um envolvido no ciclo de vida do sistema Análise, desenho, desenvolvimento, manutenção, Qualquer capaz de impor requerimentos ao sistema Dono, u6lizador É qualquer um interessado no sistema ou afectado por ele

4 4 Importância dos Requisitos Mudam Diferentes interpretações do problema Problemas de comunicação Qualidade dos sistemas de informação Funcionalidade ( funcionais) Usabilidade e experiência de u5lização ( não funcionais) U5lidade (alinhamento - objec5vos do negócio)

5 5 de Sistemas e Requisitos Necessidade Objec5vos do Sistema Requisitos Gerais do sistema do comportamento do subsistema da estrutura Requisitos Específicos do comportamento da estrutura do subsistema do comportamento da estrutura do subsistema do comportamento da estrutura

6 6 Processo Geral da engenharia de Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e Negociação de Especificação de Validação de Documento de Especificação do sistema

7 Processo geral da engenharia de 7 Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e negociação de Documentação de Validação de conceptual Documento de Especificação do sistema

8 8 Tipos de Requisitos funcionais Especifica as funções do sistema e das suas componentes Relacionada com as capacidades específicas do sistema Representados no desenho do sistema Requisitos não funcionais Refere- se ao comportamento geral do sistema na realização das suas funções Tipos de requisito não funcionais: Performance; Escalabilidade; Disponibilidade; Confiabilidade; Facilidade de Manutenção; Segurança; Sa5sfacção de regulamentos; Usabilidade, Interoperabilidade, Flexibilidade, Extensibilidade Representados na arquitectura do sistema

9 9 Tipos de Requisitos (Eng. Software) Requisitos de u>lizador. Estes foram escritos segundo pontos de vista dos u5lizadores finais, normalmente expressados na forma narra5va. Abrangem funcionais e não funcionais de tal forma que sejam compreendidos pelos u5lizadores que não tenham conhecimento técnico detalhado. Requisitos de sistema. Estes são especificações detalhadas descrevendo as funções que o sistema será capaz de executar. Só funcionais Requisitos não funcionais: Os não funcionais descrevem qualidades do sistema (como o sistema é) ao invés das suas funcionalidades (o que ele faz).

10 10 Exemplos (funcionais). (exemplo de Systems analysis and design with UML ISBN: )

11 11 Exemplos (não funcionais) (exemplo de Systems analysis and design with UML ISBN: )

12 12 Norma IEEE para documentos de IEEE/ANSI propõe uma estrutura para os documentos de especificação de

13 Processo Geral da engenharia de Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e Negociação de Especificação de Validação de Documento de 13 Especificação do sistema

14 14 Elicitação de Processo de descoberta de para um sistema através da comunicação com os stakeholders Este processo apoia- se em várias técnicas: Ques5onários Análise de documentos Entrevistas Workshops/Seminários Observação Técnicas etnográficas (inserção no ambiente onde o sistema vai funcionar) Proto5pagem

15 15 Relevantes para: Processo Questionários Alto número de stakeholders da mesma natureza e com as mesmas necessidades Foco em funcionais Seleccionar par5cipantes Definir as perguntas e 5po de respostas (abertas, fechadas, escalas) Definir estratégias para assegurar um alto número de respostas de qualidade Comunicar resultados aos stakeholders Para validar e mo5var

16 16 Análise de documentos Quando já há processos ou sistemas operando (cenário as- is ), mas há a necessidade de mudar o processo e/ou sistema (cenário to- bo ) Documentos Opicos Formulários Relatórios Manuais de processos Manuais de sistema Manuais de u5lizador

17 17 Entrevistas Relevantes Processo Número reduzido e bem iden5ficado de stakeholders, par5cularmente com poder de decisão, altamente especializados e com diferentes visões do sistema Foco em funcionais Prepare- se cuidadosamente Defina claramente os objec5vos da entrevista Seleccione os stakeholders e forneça detalhes com antecedência de forma a eles poderem preparar- se também Formule as suas perguntas de forma clara e concisa

18 18 Relevantes para Processo Seminários/Workshops Sistemas novos cujos dependem de grupos heterogéneos de stakeholders que representam diferentes classes de u5lizadores ou decisores Requer um ambiente organizacional flexível e relaxado (será que existe??) Prepare vários workshops (2, 3, ) num local apropriado e com o tempo suficiente (1 dia completo), 8 a 12 par5cipantes é a dimensão ideal Um par5cipantes deve registar as decisões tomadas Um par5cipante deve agir como moderador (com habilidades de comunicação) 1 o 2 membros da equipa de desenho devem estar presentes (num papel PASSIVO, só a ouvir) Contar com o suporte de um alto execu5vo para efeitos de credibilidade e sensação de compromisso

19 19 Observação e Etnografia Observação dos u5lizadores no seu local de trabalho e registar manualmente (limitado), ou com gravadores de audio ou vídeo (caro) A etnografia é uma prá5ca de observação os aspectos de uma cultura dentro da cultura. O observador é membro do grupo observador. Técnica relevante para elicitar sociais e organizacionais mas relacionados com a forma em que as pessoas realmente trabalham (e porquê), em vez da forma em os documentos ou processos indicam como deveriam trabalhar

20 20 Processo Geral da engenharia de Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e Negociação de Especificação de Validação de Documento de Especificação do sistema

21 21 Correctos Bons (ISO Std 830): Não ambíguos Completos Consistentes Ordenados pela sua importância e/ou estabilidade Vericáveis Suscepvveis de modificação Rastreáveis

22 22 Análise de O propósito da análise de é encontrar problemas, falhas, inconsistências, etc. A análise de deve estar interligada com a elicitação É importante manter check lists

23 23 Check list de Cada requisito deve ser avaliado em relação a se: Inclui informação (prematura) de desenho ou implementação? É um único requisito ou pode ser decomposto em vários É um requisito real ou desejo cosmé5co? Implica tecnologia não standard? Está alinhado com os objec5vos do negócio? É suscepvvel de uma ou várias interpretações? É realista face à tecnologia, custos, ou outras restrições? É possível desenhar testes para avalia- lo?

24 24 Matriz de interacção de Técnica que ilustra a interacção entre, e mostra conflictos e sobre posições 0 => Requisitos independentes 1 => Requisitos em conflicto 100=> Requisitos sobrepostos (dizem ou mesmo) Nota: a sobreposição pode ser total ou parcial R e q u i r e m e n t R 1 R 2 R 3 R 4 R 5 R 6 R R R R R R

25 25 Processo Geral da engenharia de Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e Negociação de Especificação de Validação de Documento de Especificação do sistema

26 26 Negociação de Encontrar soluções para questões como os em conflicto ou sobrepostos, mas também outros problemas como não realistas. Requer tempo, paciência e consensos (como imaginam é um trabalho que o computador não pode fazer) Processo: Informar: colocar as questões aos stakeholders relevantes Discussão: ouvir aos stakeholders; definir prioridade dos Solução: tomar decisões Implica apagar, mudar, refinar,. os em questão

27 27 Processo Geral da engenharia de Objectivos do negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre sistemas existentes Leis, regulações, standards, Elicitação de Análise e Negociação de Especificação de Validação de Documento de Especificação do sistema

28 28 Especificação de : Use Cases Especifica funcionais relacionado- os com cenários de u5lização/comportamentais Descrevem a interacção entre o sistema e en5dades externas (um actor) Descrição provista do ponto de vista do actor. Desta forma descreve quem faz o quê e como é afectado pelo sistema

29 29 Especificação de : Use Cases II No documento de podem ser apresentados antes que a lista de, porque facilitam uma rápida compreensão da funcionalidade requerida Os use cases são úteis para ligar o documento de com a modelação detalhada do comportamento do sistema

30 30 Validação dos Validação: mostrar que os definem com exac5dão o sistema pretendido Técnicas: Revisão de : análise sistemá5ca dos por um ou mais revisores Proto5pagem: validar com potenciais u5lizadores Generação de casos de teste: assegurar que os são verificáveis Os são expressados em ferramentas que incluem funções para verificar a consistência

31 31 Algumas ferramentas hup://easyweb.easynet.co.uk/~iany/other/vendors.htm hup:// hup:// cid=93 hup://soyware.forbes.com/requirements- management- soyware hup:// review.com/tools/rms/read.php

32 32 Exercício: Funcional vs Não funcional 1 A apresentação da lista de todos os clientes em ordem alfabé5ca não pode demorar mais de 5 segundos (Não funcional Performance) 2 Listar todos os clientes em ordem alfabé5ca (Funcional) 3 O sistema de gestão de base de dados deve ser sempre a versão aprovada de MySQL mais recente (Não funcional ambiente operacional) 4 Cada vez que se cria um novo u5lizador, deve enviar- se uma no5ficação por ao departamento de marke5ng (Funcional)

33 33 Exercício: Funcional vs Não funcional 5 Todas as interfaces devem ser bilingues (Português e Inglês) (Não funcional- usabilidade) 6 O cliente coloca pedidos através do sistema (Funcional) 7 O cliente coloca pedido até 2 min depois de registar- se (Não funcional performance) 8 O sistema deverá estar indisponível entre 24h00 e 1h00 para os backups (Não funcional - disponibilidade ) 9 A auten5cação far- se- á via disposi5vos biométricos (não funcional segurança)

34 34 Exercício Check list de Quais elementos da checklist falham os seguintes? 1 O u5lizador introduz pedidos através de uma interface web Introduz informação prematura 2 O u5lizador gere os seus pedidos Pode ser decomposto em vários, é suscepvvel de várias interpretações 3 O u5lizador pode visualizar a sua encomenda em três dimensões É requisito cosmé5co

35 35 Exercício Check list de Quais elementos da checklist falham os seguintes? 4 O u5lizador introduz os seus pedidos através de uma brain computer interface (u5liza tecnologia não standard) 5 O u5lizador analisa os pedidos (suscepvvel de várias interpretações) 6 O u5lizador visualiza os seus pedidos (sobre- posto com 5) 7 O sistema organiza os pedidos do u5lizador Pode ser decomposto em vários, é suscepvvel de várias interpretações