Professor: Curso: Disciplina: Aula 4-5-6

Transcrição

1 Professor: Curso: Disciplina: Aula Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Engenharia de Requisitos 03º semestre 1

2 Engenharia de Requisitos Prof. Marcos Morais de Sousa

3 Fases do Desenvolvimento de Sistemas

4 Levantamento de Requisitos Requisitos

5 Questões? Usuários e Desenvolvedores

6 Como inicia um projeto Conversa informal Necessidade de mercado Necessidade tecnológica Leis Viabilidade Etc...

7 Fases (Pressman) Concepção Planejamento (adicional) Levantamento Elaboração Negociação Especificação Validação

8 Concepção

9 Planejamento

10 Levantamento

11 Elaboração

12 Negociação

13 Especificação

14 Validação

15 Definição Existem diversas definições para requisito de software na literatura, dentre elas: Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007). Um requisito de um sistema é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006). 15

16 Definição Com base nessas e em outras definições, pode-se dizer que os requisitos de um sistema incluem especificações dos serviços que o sistema deve prover, restrições sob as quais ele deve operar, propriedades gerais do sistema e restrições que devem ser satisfeitas no seu processo de desenvolvimento 16

17 Tipos de Requisitos

18 Versões expandidas dos requisitos do usuário Tipos de Requisitos

19 Requisitos Funcionais Requisitos Funcionais: são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma interação entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007) 19

20 Requisitos Não Funcionais Requisitos Não Funcionais: descrevem restrições sobre os serviços ou funções oferecidos pelo sistema (SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004). Neste sentido, os requisitos não funcionais são muito importantes para a fase de projeto (design), servindo como base para a tomada de decisões nessa fase. 20

21 Requisitos Não Funcionais Os requisitos não funcionais têm origem nas necessidades dos usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007) 21

22 Classificação dos requisitos não funcionais Assim, os requisitos não funcionais podem ser classificados quanto à sua origem. Existem diversas classificações de requisitos não funcionais. Sommerville (2007), por exemplo, classifica-os em: Requisitos de produto Requisitos organizacionais Requisitos externos: 22

23 RN - Requisitos de produto: Requisitos de produto: especificam o comportamento do produto (sistema). Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência, portabilidade, manutenibilidade e segurança. 23

24 RN - Requisitos organizacionais: Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. Incluem requisitos de processo (padrões de processo e modelos de documentos que devem ser usados), requisitos de implementação (tal como a linguagem de programação a ser adotada), restrições de entrega (tempo para chegar ao mercado - time to market, restrições de cronograma etc.), restrições orçamentárias (custo, custo-benefício) etc. 24

25 RN - Requisitos externos: Requisitos externos : referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizações, requisitos legais (tais como requisitos de privacidade) e requisitos éticos 25

26 NOTA IMPORTANTE No que se refere aos RNFs de produto, eles podem estar relacionados a propriedades emergentes do sistema como um todo, ou seja, propriedades que não podem ser atribuídas a uma parte específica do sistema, mas que, ao contrário, só aparecem após a integração de seus componentes, tal como confiabilidade (SOMMERVILLE, 2007). 26

27 Requisitos de Domínio Sommerville (2007) considera, além de requisitos funcionais e não funcionais, requisitos de domínio. Requisitos de domínio na concepção de Sommerville são o que outros autores, tal como Wiegers (2003), chamam de regras de negócio. 27

28 Requisitos de Domínio ou regras de negócio Por exemplo, em um sistema de matrícula de uma universidade, uma importante regra de negócio diz que um aluno só pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pré-requisitos. Essas regras de negócio geralmente incluem terminologia específica do domínio e fazem referência a conceitos do domínio (SOMMERVILLE, 2007). Assim, são mais facilmente capturadas na fase de modelagem conceitual. 28

29 Requisitos de Usuário Requisitos de Usuário: são declarações em linguagem natural acompanhadas de diagramas intuitivos de quais serviços são esperados do sistema e das restrições sob as quais ele deve operar. Devem estar em um nível de abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico 29

30 Requisitos de Sistema Requisitos de Sistema: definem detalhadamente as funções, serviços e restrições do sistema. São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar, implementar e testar o sistema. Como requisitos de sistema são mais detalhados, as especificações em linguagem natural são insuficientes e para especificá-los, notações mais especializadas devem ser utilizadas. 30

31 Requisitos de Usuário e Sistema Requisitos de Usuário Será exigido do usuário uma senha e login para acessar o sistema do banco. Requisitos do Sistema Para logar no sistema o usuário deverá introduzir seu cartão do banco no leitor magnético, onde o sistema validará o mesmo e permitindo que o usuário digite o número de sua conta bancária e a senha de 6 dígitos fornecida pelo banco. Caso a senha e número de conta estejam em ordem o sistema deverá pedir as 3 letras de segurança também fornecida pelo banco. Caso o usuário erre a senha ou as letras por mais de 3 tentativas, o sistema bloqueia a conta do mesmo, onde será desbloqueada somente com seu gerente de contas. Cada vez que o usuário entrar no sistema deverá ficar registrado tal evento.

32 Requisitos Funcionais e Não Funcionais do Usuário Funcionais Será exigido do usuário uma senha e login para acessar o sistema do banco. O cliente poderá adquirir produtos do banco após estar logado no sistema. Informações sobre dados da conta do cliente deverão estar disponíveis logo após o mesmo logar no sistema. Não Funcionais Almeja-se uma interface com o usuário fácil, de modo que evite filas nos caixas eletrônicos. Alguns usuários possuem necessidades especiais, existem padrões para isso.

33 Requisitos Funcionais e Não Funcionais do Sistema Requisitos Funcionais Para logar no sistema o usuário deverá introduzir seu cartão do banco no leitor magnético, onde o sistema validará o mesmo e permitindo que o usuário digite o número de sua conta bancária e a senha de 6 dígitos fornecida pelo banco. Caso a senha e número de conta estejam em ordem o sistema deverá pedir as 3 letras de segurança também fornecida pelo banco. Requisitos Não-Funcionais Deverá ser utilizando um SGBD que permita transações seguras utilizando sistemas distribuídos. Os logs deverão ser armazenados em uma tabela que servirão para auditorias futuras, possuindo campos como: login, data, ação, etc... Requisitos de Domínio ou regras de negócio O cálculo para realizar a avaliação de risco do cliente para proporcionar empréstimo, utilizará o cálculo abaixo:...

34 NOTA IMPORTANTE É importante notar a distinção entre clientes e usuários finais. Consideram-se clientes aqueles que contratam o desenvolvimento do sistema e que, muitas vezes, não usarão diretamente o sistema. Eles estão mais interessados nos resultados da utilização do sistema pelos usuários do que no sistema em si. Usuários, por outro lado, são as pessoas que utilizarão o sistema em seu dia a dia. Ou seja, os usuários são as pessoas que vão operar ou interagir diretamente com o sistema. 34

35 Documento de Definição e de Especificação de Requisitos Uma vez que requisitos de usuário e de sistema têm propósitos e público alvo diferentes, é útil descrevêlos em documentos diferentes. Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados: Documento de Definição de Requisitos ou somente Documento de Requisitos Documento de Especificação de Requisitos 35

36 Documento de Definição e de Especificação de Requisitos Documento de Definição de Requisitos deve ser escrito de maneira que o cliente possa entender, na forma de uma listagem do quê o cliente espera que o sistema proposto faça. Ele representa um consenso entre o cliente e o desenvolvedor sobre o quê o cliente quer. 36

37 Documento de Definição e de Especificação de Requisitos Documento de Especificação de Requisitos: redefine os requisitos de usuário em termos mais técnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos. 37

38 Processo de Engenharia de Requisitos A Engenharia de Requisitos de Software é o ramo da Engenharia de Software que envolve as atividades relacionadas com a definição dos requisitos de software de um sistema, desenvolvidas ao longo do ciclo de vida de software (KOTONYA; SOMMERVILLE, 1998). O processo de engenharia de requisitos envolve criatividade, interação de diferentes pessoas, conhecimento e experiência para transformar informações diversas (sobre a organização, sobre leis, sobre o sistema a ser construído etc.) em documentos e modelos que direcionem o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998) 38

39 Processo de Engenharia de Requisitos Tomando por base o processo proposto por Kotonya e Sommerville (1998), nesta aula considera-se que um processo de engenharia de requisitos deve contemplar, tipicamente, as atividades mostradas na Figura 2.1: levantamento de requisitos, análise de requisitos, documentação de requisitos, verificação e validação de requisitos e gerência de requisitos. 39

40 Processo de Engenharia de Requisitos 40

41 Especificação da Interface

42 RUP Rational Unified Process

43 Disciplina: Requisitos (RUP)

44 Gestão de Requisitos

45 Atividade Levantar Requisitos de Usuário e Sistema (de usuário, Funcionais, Não-Funcionais e de Domínio, etc.). Sistema de Home Center Materiais de Construção Carol, André, Junior,bruno Sistema de Caixa Eletrônico Sistema de Frente de Caixa Sistema para Consultório Médico Leiliane, Samuel, Joao Heber, Alan Sistema para Comércio Eletrônico Silvano, Diego, Vinicius Sistema para Posto de Combustível ED, Luan, Igor, Melquisedeque Site de Relacionamentos Marla, Gilberto Pires, Geisa, Felipe

46 Agora comparar o que foi levantado/entregue com um caso pratico levantado junto ao comercio de sua cidade. Fazer observações importantes, tendo como base a literatura especializada. 46

47 Até a próxima Professor: Curso: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação 47