Análise de Sistemas 3º Bimestre (material 1)

Transcrição

1 Análise de Sistemas 3º Bimestre (material 1) Professor: José Ronaldo Leles Júnior Turma: 2º ano do curso de Sistemas de Informação UEG Universidade Estadual de Goiás Campus Posse

2 Requisitos de sistemas de software O que são? Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais (SOMMERVILLE, 2010). Refletem uma condição ou capacidade de um software que deve ser implementada por um sistema ou componente de sistema para satisfazer um contrato, padrão ou outra documentação formal.

3 Requisitos de sistemas de software Um requisito pode apresentar diferentes níveis de descrição: Requisitos de usuário Descritos de modo que eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado. 1. O sistema LIBSYS deve manter o acompanhamento de todos os dados exigidos pelas agências de licenciamento de direitos autorais no Reino Unido e em outros lugares.

4 Requisitos de sistemas de software Requisitos de sistema Adicionam detalhes e explicam como os requisitos de usuários devem ser fornecidos pelo sistema utilizado pelos desenvolvedores do sistema. 1.1 Ao solicitar um documento ao LIBSYS, deve ser apresentado ao solicitante um formulário que registra os detalhes do usuário e da sua solicitação feita. 1.2 Os formulários de solicitação do LIBSYS devem ser armazenados no sistema durante cinco anos, a partir da data da solicitação. 1.3 Todos os formulários do LIBSYS devem ser indexados por usuário, nome do material solicitado e fornecedor da solicitação....

5 Requisitos de sistemas de software Requisitos Funcionais e Não Funcionais Os requisitos são frequentemente classificados, em requisitos funcionais e não funcionais. Requisitos funcionais São as declarações de serviços que o sistema deve fornecer definem as funcionalidades do sistema. (O QUE FAZER?) 1. O sistema deve permitir que cada professor realize o lançamento de notas nas turmas nas quais lecionou ; 2. O sistema deve permitir que um aluno realize a sua matrícula nas disciplinas oferecidas em um semestre letivo ; 3. O sistema deve permitir que os coordenadores da escola possam obter o número de aprovações, reprovações e trancamentos em cada disciplina oferecida em um determinado período.

6 Requisitos de sistemas de software Esses requisitos funcionais definem recursos específicos a serem fornecidos pelo sistema. A imprecisão na especificação de requisitos é motivo de MUITOS PROBLEMAS... A especificação de requisitos funcionais deve ser completa e consistente.

7 Requisitos de sistemas de software Requisitos não funcionais Estão relacionados às propriedades emergentes do sistema; Declaram características globais do sistema (confiança, segurança, desempenho, usabilidade etc.) características de qualidade que o sistema deve possuir e que estão relacionadas às funcionalidades. (COMO FAZER?) 1. O tempo de registro de cada DVD deve ser inferior a 1 segundo ; 2. O sistema será operado em ambiente operacional Windows e Linux ; 3. O sistema só permitirá acesso aos dados, com autorização. O sistema terá um procedimento de autorização de usuários, nos quais tenham que se identificar usando um (login) e uma senha.

8 Requisitos de sistemas de software Alguns tipos de requisitos não funcionais: Confiabilidade: corresponde a medidas quantitativas de confiabilidade do sistema, tais como tempo médio de recuperação entre falhas. Desempenho: requisitos que definem tempos de respostas esperados para as funcionalidades do sistema. Portabilidade: restrições sobre as plataformas de hardware e software nas quais o sistema será implementado e sobre o grau de facilidade para transportar o sistema para outras plataformas. Segurança: limitações sobre a segurança do sistema em relação a acessos não autorizados. Usabilidade: requisitos que se relacionam ou afetam a usabilidade do sistema (facilidade de uso).

9 Requisitos de sistemas de software Requisitos normativos São declarações de restrições impostas sobre o desenvolvimento do sistema. Exemplos: a adequação a custos e prazos; a plataforma tecnológica; aspectos legais (licenciamento) limitações sobre a interface com o usuário; componentes de hardware a serem adquiridos; necessidades de comunicação com sistemas legados; etc.

10 Regras do Negócio São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização (Gottesdiener, 1999). Cada organização pode ter várias regras do negócio: O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa da entrega. Um cliente do banco não pode retirar mais de R$ 1000,00 por dia de sua conta. Senhas devem ter, no mínimo, seis caracteres, entre números e letras e devem ser atualizadas a cada três meses. O número máximo de alunos por turma é igual a 40.

11 Propriedades dos requisitos Benefício - Indicando o grau de benefício esperado com o sistema. Críticos: Caso não estejam presentes ou funcionando adequadamente, o sistema não atenderá as necessidades do cliente. Importantes: Se não implementado, pode afetar a satisfação do cliente, mas não determinará o sucesso ou fracasso do projeto. Desejáveis: Provavelmente serão pouco utilizados e que podem até não ser atendidos no projeto.

12 Propriedades dos requisitos Estabilidade - Reflete a probabilidade de o requisito sofrer alterações futuras. Alta: Probabilidade de mudanças é baixa. Média: Pendência de esclarecimentos por parte do cliente. Baixa: Cuja mudança é certa! Algumas vezes em consequência da complexidade envolvida. Ex: regras do negócio. Situação - Indicando a situação atual do requisito: Proposto, Aprovado ou Cancelado.

13 Propriedades dos requisitos Risco - Indica o grau de risco de implementação. Pode ser classificado como alto, médio e baixo. Requisito com alto risco é aquele que possui baixa estabilidade, alta complexidade e envolve pendências externas ao projeto e/ou envolve novidades tecnológicas.

14 Mudança contínua Requisitos sempre mudam Temos que aceitar a instabilidade dos requisitos como um fato da vida, e não condená-la como o resultado de um raciocínio mal conduzido. Coloque dois ou mais interessados em uma sala e pergunte a eles que tipo de sistema eles desejam. Provavelmente obterá três ou mais opiniões diferentes.

15 Negociação Usuários pedem mais do que pode ser conseguido; Usuários diferentes possuem requisitos de acordo com seus interesses. O analista de requisitos deve negociar requisitos que não possam ser atendidos, devido ao cronograma e custo. Não deve haver ganhador e nem perdedor em uma negociação efetiva.

16 Quais são as fontes de requisitos? Usuários; Documentos; Especificações técnicas; Legislações; Clientes; Sistemas legados; Patrocinadores; Especialistas do domínio (especialista em uma ou mais área do negócio); Etc.

17 Quais problemas podem ser encontrados? Envolvidos Possuem uma ideia pré-concebida da solução Não sabem o que eles realmente desejam São inabilitados em articular o que eles desejam Pensam que sabem o que eles Desejam, mas não os reconhecem quando eles são entregues Todo mundo enxerga as coisas do seu próprio ponto de vista Acredita que tudo é motivado politicamente (a equipe comercial deseja a implementação de requisitos que atraem mais clientes e a financeira requisitos que tornem os gastos menores) Analistas Pensam que eles entendem os problemas do usuário melhor do que o usuário.

18 Documento de Requisitos O documento de requisitos de um projeto tem o objetivo de documentar o escopo do sistema a ser desenvolvido. Deve ser elaborado de maneira precisa, completa, consistente e, principalmente, compreensível aos stakeholders (isto é, os principais interessados no sistema). Ele é o produto da fase de levantamento de requisitos.

19 Itens de um Documento de Requisitos 1. Introdução (Contém a organização do documento) Exemplo: Este documento apresenta os requisitos de usuário para a informatização da Vídeo Locadora Passatempo. Essa atividade foi conduzida por meio da realização de entrevistas com cliente e usuários. Este documento está organizado da seguinte forma: a seção 2 contém uma descrição do propósito do sistema; a seção 3 apresenta uma descrição do minimundo apresentando o problema; e a seção 4 apresenta a lista de requisitos de usuário levantados junto ao cliente.

20 Itens de um Documento de Requisitos 2. Propósito do Sistema (contém o propósito do sistema descrito de forma bastante objetiva) Exemplo: A vídeo locadora necessita de um sistema de informação para apoiar a realização de suas atividades principais, a saber: empréstimo e devolução de itens e reserva de filmes. Para que essas atividades sejam apoiadas, é necessário controlar as informações acerca de filmes e clientes, dentre outros. Além disso, devem ser fornecidas facilidades de consulta ao acervo da locadora, permitindo consultas por diversas informações dos filmes.

21 Itens de um Documento de Requisitos 3. Descrição do Minimundo (visão geral do domínio, do problema a ser resolvido, bem como as principais ideias do cliente sobre o sistema a ser desenvolvido) Exemplo: A Vídeo Locadora Passatempo deseja um sistema de informação para gerenciar o atendimento aos seus clientes. O negócio principal da locadora é a locação de vídeos (ou filmes). De um dado filme, a locadora pode possuir vários itens, em diferentes mídias, tais como DVD, VHS, Blu-Ray, HD-DVD. Os filmes são classificados nos seguintes gêneros: ação, animação, aventura, comédia, documentário, drama, ficção, guerra, musical, policial, romance, suspense e terror. O prazo para devolução é de um dia para lançamentos e três dias para filmes do catálogo. Contudo, o valor a ser efetivamente pago e a data de devolução prevista de um item locado podem ser alterados pelo atendente da locadora para aplicar descontos individualizados ou ampliar prazos de devolução. ( )

22 Itens de um Documento de Requisitos 4. Requisitos de Usuário Três tipos de requisitos devem ser registrados: Requisitos Funcionais

23 Itens de um Documento de Requisitos Requisitos Não Funcionais

24 Itens de um Documento de Requisitos Regras de Negócio

25 Resumo O documento de requisitos serve como um termo de consenso entre a equipe técnica(desenvolvedores) e clientes; Ele constitui a base para as atividades subsequentes do desenvolvimento do sistema e fornece um ponto de referência para qualquer validação futura do software construído; Estabelece o escopo do sistema(isto é, o que faz parte do sistema e que não faz parte do sistema).

26 Bibliografia Bezerra, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, Sommervile, lan. Engenharia de Software. 8º ed. São Paulo: Pearson Addison Wesley, Engholm Júnior, Hélio. Análise e Design: orientados a objetos. São Paulo: Novatec, 2013.