slides4 es requisitos&casosdeuso

1

Universidade Federal do Esprito Santo

Centro Tecnolgico

Departamento de Informtica

Prof.: Monalessa Perini Barcellos

([email protected])

Disciplina: INF 02810 Engenharia de Software

Contedo

1. Introduo

2. Processo de Software

3. Gerncia de Projetos de Software

4. Gerncia da Qualidade

5. Especificao e Anlise de Requisitos

6. Projeto de Sistema

7. Implementao e Testes

8. Entrega e Manuteno

Engenharia de Software Monalessa Perini Barcellos

2


Atividades do processo de software

Atividades de Desenvolvimento

Atividades de Gerncia

Atividades de Garantia da Qualidade

Produto de Software


espinha dorsal do

desenvolvimento do

software

Especificao de e Anlise dos Requisitos

Implementao e Teste de Unidade

Testes

Entrega e Implantao

Projeto



Que requisitos o software deve atender?

Quem so os envolvidos?

Quais so suas necessidades em relao ao software?

Mas...

O que um requisito?

Especificao e Anlise dos Requisitos

Implementao e Teste de Unidade

Testes

Entrega e Implantao

Projeto

3


Requisitos

Ou, em outras palavras...


Os requisitos de um sistema definem o que o sistema deve fazer e as

circunstncias sob as quais deve operar.

So as funes que um sistema deve incorporar e as restries que devem

ser satisfeitas.


Tipos de Requisitos

Funcionais: apontam as funes que o sistema deve fornecer e

como o sistema deve se comportar em determinadas situaes.

Ex.: O sistema deve registrar locaes, indicando o cliente, os itens locados, a data da

locao, a data de devoluo e o valor da locao.

No Funcionais: descrevem restries sobre as funes oferecidas,

tais como restries de tempo, de uso de recursos etc. Alguns

requisitos no funcionais dizem respeito ao sistema como um

todo e no a funcionalidade especfica.Ex.: A consulta ao acervo da locadora deve estar disponvel pela Internet, a partir dos

principais navegadores disponveis no mercado. (requisito de portabilidade)


4


Processo de Engenharia de Requisitos

a) Levantamento (ou Elicitao) de Requisitos

b) Anlise de Requisitos

c) Documentao de Requisitos

d) Verificao e Validao de Requisitos

e) Gerncia de Requisitos


Tratados pela

Documentao, Garantia da

Qualidade e Gerncia de

Configurao

Definem O QU o

software deve fazer.


a) Levantamento ou Elicitao de Requisitos

uma atividade complexa que no se resume somente a perguntar s pessoas o

que elas desejam e tambm no uma simples transferncia de conhecimento.

Algumas tcnicas: entrevistas, questionrios, prototipao, investigao de

documentos, observao, dinmicas de grupo etc.

Importante:

Enfoque em uma viso do cliente / usurio.

Ainda no se est procurando definir a estrutura interna do sistema, mas sim

procurando saber que funcionalidades o sistema deve oferecer ao usurio e

que restries elas devem satisfazer.


5


b) Anlise de Requisitos

Enfoca a estrutura interna do sistema (procura definir o que o

sistema tem de ter internamente para tratar adequadamente os

requisitos levantados).

uma atividade de construo de modelos.

Um modelo uma representao de alguma coisa do mundo real,

uma abstrao da realidade, e, portanto, representa uma seleo de

caractersticas do mundo real relevantes para o propsito do sistema

em questo.



Modelos so fundamentais no desenvolvimento de sistemas.

Tipicamente eles so construdos para:

possibilitar o estudo do comportamento do sistema;

facilitar a comunicao entre os componentes da equipe de

desenvolvimento e clientes e usurios;

possibilitar a discusso de correes e modificaes com o usurio;

formar a documentao do sistema.

No caso do desenvolvimento de sistemas, geralmente, so considerados trs nveis

de abstrao: conceitual, lgico e fsico.


6


Para realizar a Anlise de Requisitos, preciso escolher o paradigma de

desenvolvimento a ser seguido.

Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e,

portanto, definem as caractersticas bsicas dos modelos a serem construdos.

Por exemplo:

Paradigma Estruturado: adota uma viso de desenvolvimento baseada em um

modelo entrada-processamento-sada. No paradigma estruturado, os dados

so considerados separadamente das funes que os transformam e a

decomposio funcional usada intensamente.

Paradigma Orientado a Objetos: parte do pressuposto que o mundo povoado

por objetos, ou seja, a abstrao bsica para se representar as coisas do

mundo so os objetos.



O Paradigma Orientado a Objetos

O mundo visto como sendo composto por objetos, onde um objeto uma

entidade que combina estrutura de dados e comportamento funcional.


Carro Pessoa

Turma

7


Princpios da Orientao a Objetos

a) Abstrao

Viso simplificada de algo, onde apenas os elementos relevantes so considerados.



b) Encapsulamento

Separao dos aspectos externos de um objeto, acessveis por outros objetos, de

seus detalhes internos de implementao, que ficam ocultos dos demais objetos.

Abstrao e encapsulamento so conceitos complementares: enquanto a abstrao

enfoca o comportamento observvel de um objeto, o encapsulamento oculta a

implementao que origina esse comportamento.


8


c) Modularidade

Obteno de sistemas decompostos em um conjunto de mdulos coesos e

fracamente acoplados.



Conceitos da Orientao a Objetos

a) Objetos: entidades que interagem entre si, onde cada uma delas desempenha

um papel especfico.

b) Classes: descrevem um conjunto de objetos com as mesmas propriedades

(atributos e associaes) e o mesmo comportamento (operaes).

Objetos so instncias das classes


O carro do Joo Joo

Pessoa

Joo

Maria

Cecy

Carro

Carro A

Carro B

Carro C

9


c) Ligaes e Associaes: relacionamentos entre objetos e classes (respectivamente).

d) Herana: descrevem um conjunto de objetos com as mesmas propriedades (atributos

e associaes) e o mesmo comportamento (operaes).


possui

Joo

CarroPessoa

possui

Carro A

Carro

HatchSed

Esportivo

superclasse(classe me)

subclasse(classe filha)


e) Mensagens e Mtodos: forma de comunicao entre os objetos.

d) Classes e Operaes Abstratas: classes que no possuem instncia e operaes que

no so implementadas nas classes (so apenas assinatura).


Joo

obterCarro (Joo)

Carro A

Pessoa

Pessoa Fsica

Carro

Carro A

Carro B

Carro C

=

Pessoa Jurdica

classe abstrata

obterRegistroFederalpoderia ser uma

operao abstrata

10


Levantamento e Registro de Requisitos


Requisitos so levantados junto ao cliente e por meio de diversas tcnicas (entrevistas,

questionrios, prototipao, investigao de documentos, observao, dinmicas de grupo etc)

Os requisitos devem ser registrados.

Documento de Requisitos

Introduo

Propsito do Sistema

Descrio do Minimundo

Requisitos do Usurio

Documento de Especificao de Requisitos

Introduo

Modelo de Casos de Uso

Modelo Conceitual Estrutural

Modelos Dinmicos

Dicionrio do Projeto

Entendvel pelo usurioNo mais entendvel pelo usurio comum.

voltado para a equipe do projeto.


Documento de Requisitos

Introduo (contm a organizao do documento)

Exemplo*: Este documento apresenta os requisitos de usurio para a informatizao da Vdeo Locadora

Passatempo. Essa atividade foi conduzida por meio da realizao de entrevistas com cliente e usurios. Este

documento est organizado da seguinte forma: a seo 2 contm uma descrio do propsito do sistema; a seo 3

apresenta uma descrio do minimundo apresentando o problema; e a seo 4 apresenta a lista de requisitos de

usurio levantados junto ao cliente.

Propsito do Sistema (contm o propsito do sistema descrito de forma bastante

objetiva tipicamente, em um pargrafo)

Exemplo: A vdeolocadora necessita de um sistema de informao para apoiar a realizao de suas atividades

principais, a saber: emprstimo e devoluo de itens e reserva de filmes. Para que essas atividades sejam apoiadas,

necessrio controlar as informaes acerca de filmes e clientes, dentre outros. Alm disso, devem ser fornecidas

facilidades de consulta ao acervo da locadora, permitindo consultas por diversas informaes dos filmes.


Documento de

Requisitos

Fonte: Pgina da disciplina Projeto de Sistemas do prof. Ricardo de Almeida Falbo, 2011/01 (http://www.inf.ufes.br/~falbo/node/10).

11


Descrio do Minimundo (viso geral do domnio, do problema a ser

resolvido, bem como as principais ideias do cliente sobre o sistema a ser desenvolvido)

Exemplo*: A Vdeo Locadora Passatempo deseja um sistema de informao para gerenciar o

atendimento aos seus clientes. O negcio principal da locadora a locao de vdeos (ou filmes). De um dado filme,

a locadora pode possuir vrios itens, em diferentes mdias, tais como DVD, VHS, Blu-Ray, HD-DVD. Os

filmes so classificados nos seguintes gneros: ao, animao, aventura, comdia, documentrio, drama, fico,

guerra, musical, policial, romance, suspense e terror. Alm disso, a locadora faz distino entre filmes de catlogo e

lanamentos.

Os valores padro das locaes so dados pelo tipo de mdia do item sendo locado. Atualmente, so cobrados os

seguintes valores: DVD, VHS e HD-DVD R$ 5,00; Blu-Ray R$ 7,50, sendo que lanamentos tm um

acrscimo de 50% nos valores acima mencionados. O prazo para devoluo de um dia para lanamentos e trs

dias para filmes do catlogo. Contudo, o valor a ser efetivamente pago e a data de devoluo prevista de um item

locado podem ser alterados pelo atendente da locadora para aplicar descontos individualizados ou ampliar prazos

de devoluo.

()


Documento de

Requisitos


Requisitos de Usurio (requisitos de usurio em linguagem natural)

Trs tipos de requisitos devem ser registrados:

Requisitos Funcionais (o que o sistema deve fazer?)

()


Documento de

Requisitos

12


Regras de Negcio (regras que devem ser obedecidas pelo sistema)

()


Documento de

Requisitos


Tipos de regras de negcio

Fatos ou invariantes

Ex.: Todo pedido tem uma taxa de remessa.

Restries

Ex.: Um aluno s pode tomar emprestado, concomitantemente, de um a trs livros.

Ativadores de Aes

Ex.: Se a data para retirada do livro ultrapassada e o livro no retirado, ento a reserva

cancelada.

Inferncias

Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido, ento ele torna-se um usurio

inadimplente.

Computaes

Ex.: Aplica-se um desconto progressivo se mais do que 10 unidades forem adquiridas. De 10 a 19,

o desconto de 10%. Acima de 19, o desconto de 25%.


Documento de

Requisitos

13


Restries de Integridade em Modelos de Dados (tambm so regras de negcio)

Modelo:

Significa que:

(i) um aluno cursa um curso

(ii) um aluno pode se matricular em nenhuma ou vrias turmas

(iii) um curso possui um conjunto de disciplinas em sua matriz curricular

(iv) uma turma de uma disciplina especfica.

Restrio de integridade:

Um aluno s pode ser matricular em turmas de disciplinas que compem a grade

curricular do curso que esse aluno cursa.


Documento de

Requisitos


Requisitos No Funcionais (tipicamente, restries a serem obedecidas em relao a: segurana, portabilidade, desempenho, usabilidade, interoperabilidade,)

()


Documento de

Requisitos

14


Como escrever requisitos?

Diretrizes gerais:

- Identificar os requisitos pelo seu tipo e nmero (ex.: RF01, RNF02, RN05)

- Usar frases do tipo:

O sistema deve. (funo ou caracterstica requerida)

O sistema pode. . (funo ou caracterstica desejada)

O sistema no deve

- Escrever frases completas, com a gramtica, ortografia e pontuao correta. Procurar

manter frases e pargrafos curtos e diretos.

- Usar os termos consistentemente. Defina-os em um glossrio.

- Preferir a voz ativa (o sistema deve fazer alguma coisa) voz passiva (alguma coisa

deve ser feita).


Documento de

Requisitos


- Sempre que possvel, identificar o tipo de usurio. Ex.: se o usurio

no caso for o caixa do banco, indicar claramente o caixa do banco

deve [...].

- Evitar termos vagos, que conduzam a requisitos ambguos e no testveis,

tais como rpido, adequado, fcil de usar etc.

- Escrever requisitos em um nvel consistente de detalhe.

- Escrever requisitos individualmente testveis. Um requisito bem escrito deve

permitir a definio de um pequeno conjunto de testes para verificar se o

requisito foi corretamente implementado.

- Evitar longos pargrafos narrativos que contenham mltiplos requisitos.

Divida um requisito desta natureza em vrios menores.


Documento de

Requisitos

15


Observaes sobre as Regras de Negcio

- Ao contrrio de requisitos funcionais e no funcionais, regras de negcio

no so passveis de serem capturadas por meio de perguntas simples e diretas, tal

como Quais so suas regras de negcio?

- Normalmente surgem quando est se tentando entender os requisitos.

- Muitas s vo surgir quando os requisitos forem detalhados.

- Algumas questes que podem ajudar:

Polticas: Por que necessrio fazer isso desse jeito?

Regulamentaes: O que o governo requer?

Frmulas: Como este valor calculado?

Modelos de Dados: Como essas entidades de dados esto relacionadas?

Ciclo de Vida de Objetos: O que causa uma mudana no estado desse objeto?

Decises de Atores: O que o usurio pode fazer a seguir?

Decises de Sistema: Como o sistema sabe o que fazer a seguir?

Eventos: O que pode (e no pode) acontecer?


Documento de

Requisitos


Documento de Especificao de Requisitos

Introduo: breve introduo ao documento, descrevendo seu propsito e estrutura.

Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema, incluindo os

diagramas de casos de uso e as descries de casos de uso associadas.

Modelo Estrutural: apresenta o modelo estrutural do sistema, incluindo os diagramas de

classes do sistema.

Modelo Dinmico: apresenta os modelos comportamentais dinmicos do sistema,

incluindo os diagramas de estados, diagramas de interao e diagramas de atividades.

Dicionrio do Projeto: apresenta as definies dos principais conceitos capturados pelos

diversos modelos e restries de integridade a serem consideradas, servindo como um

glossrio do projeto.


Documento de

Especificao de

Requisitos

16


Diviso de um Sistema em Subsistemas

Diagrama de Pacotes

Mostra a decomposio de um sistema (ou modelo) em unidades menores e suas

dependncias.


Documento de

Especificao de

Requisitos


Modelagem de Casos de Uso

Diagramas de Casos de Uso so diagramas que mostram os potenciais usurios do

sistema (atores) e as funcionalidades que lhes so teis (casos de uso).

Descries dos Casos de Uso: para cada caso de uso modelado nos Diagramas de Casos

de Uso deve haver uma descrio especificando o comportamento do sistema.


Caso de Uso 1

Ator 1

Caso de Uso 2

Casos de de uso representam funcionalidades requeridas externamente.

Um usurio uma pessoa que utiliza o sistema, enquanto um ator representa um

papel especfico que um usurio pode desempenhar.

A associao entre um ator e um caso de uso indica que o ator e o caso de uso se

comunicam entre si, cada um com a possibilidade de enviar e receber mensagens.

17


Notao Bsica


Atores

Casos de Uso

Associaes


Um exemplo de diagrama de casos de uso


18


Descrio de Casos de Uso

Nome: nome do caso de uso, capturando a sua essncia.

Escopo: nome do sistema / subsistema do qual o caso de uso faz parte.

Propsito: uma descrio sucinta do caso de uso, descrevendo o objetivo do caso de uso.

Ator : nome do ator.

Pr-condies: o que deve ser verdadeiro antes da execuo do caso de uso.

Ps-condies: o que deve ser verdadeiro aps a execuo do caso de uso, considerando que

o fluxo de eventos normal realizado com sucesso.

Fluxo de Eventos Normal: descreve os passos do caso de uso realizados em situaes

normais.

Fluxo de Eventos Alternativos: descreve formas alternativas de realizar certos passos do

caso de uso (fluxos variantes e fluxos de exceo)

Requisitos Relacionados: listagem dos identificadores dos requisitos (funcionais, no

funcionais e regras de negcio) tratados pelo caso de uso

Classes / Entidades: classes necessrias para tratar o caso de uso sendo descrito.



Um exemplo de descrio de caso de uso (com descrio do fluxo em texto corrido)


Nome: Efetuar Saque

Escopo: Sistema de Caixa Automtico

Propsito: Este caso de uso permite que um cliente do banco efetue um saque, retirando dinheiro de sua conta bancria.

Ator : Cliente

Pr-condies: O caixa automtico deve estar conectado ao sistema bancrio.

Ps-condies: O saque efetuado, debitando o valor da conta do cliente e entregando o mesmo valor para o cliente em espcie.

Fluxo de Eventos Normal

O cliente insere seu carto no caixa automtico, que analisa o carto e verifica se ele aceitvel. Se o carto aceitvel, o caixa automtico solicita que o cliente informe a senha. O cliente informa a senha. O caixa automtico envia os dados do carto e da senha para o sistema bancrio para validao. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transao a ser efetuada. O cliente seleciona a opo saque e o caixa solicita que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. Se o saque autorizado, as notas so preparadas e liberadas.

Fluxos de Eventos de Exceo

O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada.

Senha incorreta: Se a senha informada est incorreta, uma mensagem mostrada para o cliente que poder entrar com a senha novamente. Caso o cliente informe trs vezes senha incorreta, o carto dever ser bloqueado.

Saque no autorizado: Se o saque no for aceito pelo sistema bancrio, uma mensagem de erro exibida e a operao abortada.

No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada.

Cancelamento: O cliente pode cancelar a transao a qualquer momento, enquanto o saque no for autorizado pelo sistema bancrio.

Requisitos Relacionados: RF01, RN01, RNF01, RNF02

Classes: Cliente, Conta, Carto, Transao, Saque.

19


Um exemplo de descrio de caso de uso (com descrio do fluxo de forma enumerada)


Nome: Efetuar Saque

()

Fluxo de Eventos Normal

1. O cliente insere seu carto no caixa automtico.2. O caixa automtico analisa o carto e verifica se ele aceitvel. 3. O caixa automtico solicita que o cliente informe a senha. 4. O cliente informa a senha.5. O caixa automtico envia os dados do carto e da senha para o sistema bancrio para validao. 6. O caixa automtico solicita que o cliente informe o tipo de transao a ser efetuada. 7. O cliente seleciona a opo saque.8. O caixa automtico solicita que seja informada a quantia. 9. O cliente informa a quantia a ser sacada. 10. O caixa automtico envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada.11. As notas so preparadas e liberadas.

Fluxos de Eventos de Exceo

2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada e se retorna ao passo 1.5a Senha incorreta:

5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente. Retornar ao passo 3.5a.2 3 tentativa: bloquear o carto e abortar a transao.

10a - Saque no autorizado: Uma mensagem de erro exibida e a operao abortada.11a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada.1 a 9: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no for autorizado pelo sistema bancrio. A transao abortada.()


Um exemplo de fluxos variantes


Nome: Efetuar Compra

Fluxo de Eventos Normal(...)6. De posse do valor a ser pago, o atendente informa a forma de pagamento. 7. Efetuar o pagamento:

7a. Em dinheiro7b. Em cheque7c. Em carto

8. O pagamento registrado.

Fluxos de Eventos Variantes

7a Pagamento em Dinheiro:7a.1 O atendente informa a quantia em dinheiro entregue pelo cliente.7a.2 O sistema informa o valor do troco a ser dado ao cliente.

7b Pagamento em Cheque:7b.1 O atendente informa os dados do cheque, a saber: banco, agncia, conta e valor.

7c Pagamento em Carto:7c.1 O atendente informa os dados do carto e o valor da compra.7.c.2 O sistema envia os dados informados no passo anterior, junto com a identificao da loja para o servio de autorizao do Sistema de Operadoras de Carto de Crdito.7c.3 O Sistema de Operadoras de Carto de Crdito autoriza a compra e envia o cdigo da autorizao.

20


Outras formas de descrever Casos de Uso

Casos de Uso Cadastrais (tambm chamados CRUD : Create, Read, Update and Delete)

Formato:


Exemplo:


Casos de Uso de Consultas

Formato:


Exemplo:

21


Demais Casos de Uso

Formato:


(exemplo)

22


(continuao

exemplo)



Relacionamentos entre Casos de Uso

Incluso

O comportamento definido no caso de uso de incluso incorporado ao comportamento do

caso de uso base.


23


Caractersticas Gerais da Incluso

Usada para extrair um comportamento comum a vrios casos de uso em uma

nica descrio, evitando que esse comportamento precise ser descrito

repetidamente.

O caso de uso base sabe que um comportamento de outro caso de uso ser

incorporado a ele. ele quem chama o caso de uso includo.

Um caso de uso includo pode ser executado dentro de outro (o caso de uso

base) ou pode ser executado sozinho.

Anloga utilizao de uma subrotina na programao.



Extenso

O comportamento definido no caso de uso de extenso

pode ser inserido dentro do comportamento definido no

caso de uso base.


ou

24


Caractersticas Gerais da Extenso

Usada para extrair um comportamento que, normalmente, s ocorre se uma

determinada condio for satisfeita.

O caso de uso de extenso geralmente um fragmento, ou seja, ele no aparece

sozinho como uma sequncia de comportamentos.

Diz-se que o caso de uso base apenas sabe que existe um ponto de extenso,

mas no est ciente de qual comportamento ser incorporado nele, ou seja, no

sabe quantos casos de uso de extenso existem e qual comportamento

modelado por cada um. Nesse caso, o caso de uso de extenso que sabe onde

vai ser inserido.



Generalizao/Especializao

O caso de uso filho herda o comportamento e o significado do caso

de uso pai, acrescentando ou sobrescrevendo seu comportamento.


25


Caractersticas Gerais da Generalizao/Especializao

Aplicvel quando um caso de uso possui diversas variaes. O comportamento

comum pode ser modelado como um caso de uso abstrato e especializado para as

diferentes variaes.

Mas, preciso avaliar se no fica mais simples e direto descrever essas variaes

como fluxos alternativos variantes na descrio de casos de uso.

Quando forem poucas e pequenas as variaes, muito provavelmente ser mais

fcil captur-las na descrio, ao invs de criar hierarquias de casos de uso.




Especializaes transformadas em Fluxos Variantes

26

Universidade Federal do Esprito Santo

Centro Tecnolgico

Departamento de Informtica

Prof.: Monalessa Perini Barcellos

([email protected])

Disciplina: INF 02810 Engenharia de Software

slides4 es requisitos&casosdeuso

Documents