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

Requisitos Profª.: Rosanete Grassiani dos Santos

[email protected]

mailto:[email protected]

Breve revisão dos requisitos

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).

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.

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.

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.


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.


Requisito for funcional, deverá ser também Independente da

Implementação.

O requisito define o que deve ser feito, mas não como!

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.

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.

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.

Requisitos não funcionais

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

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.

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.

Requisitos suplementares

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.

Requisitos Suplementares

18/10/2013 Profª.: Rosanete Grassiani dos Santos

18

Nome Restrição Categoria Desejável Permanente

S1 Tipo de Interface As interfaces do sistema devem ser

implementadas como formulários acessíveis em um browser html.

Interface ( ) ( )

S2 Armazenamento de

dados

A camada de persistência deve ser implementada

de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro

Persistência ( ) ( 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 ( ) ( )

... ... ... ... ...

Documento de Requisitos


19

Sistema Livir


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.


Alternativa 2


20

Desafios da Análise de Requisitos

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.


21

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


22

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.


23

Nome Atores Descrição Referências Cruzadas

Realizar venda de livros

Cliente O cliente se identifica e identifica os livros que deseja levar efetuando ao final o pagamento com cartão de crédito.

F1, F3, F5, F9, F10

Realizar encomenda de livros

Gerente O gerente autoriza a encomenda de livros faltantes e lançamentos as editoras.

F2, F4, F6, F7, F8

Registrar e aplicar promoções

Gerente O Gerente configura as promoções válidas em determinado período.

F11, F12

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?


24

Diagrama de Casos de Uso UML


25



26



27

Granularidade de um Caso de Uso

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.


28

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.


29


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.


30

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


31

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


32

Tabela para Representar Operações

de “Manutenção”


33

Conceito I A E C Observação Ref. Cruzadas

Cliente x x x x Só é possível excluir se não houver vendas associadas F13

Reserva x x x x F15, F16

Livro x x x x Só é possível excluir se não houver vendas associadas F18

Vendas x x A inclusão das vendas só pode acontecer através do caso de uso “Registrar venda de livros”. Não é possível alterar uma vendas, apenas excluir.

F17, F19

Modelo Conceitual Preliminar


34

Modelo Conceitual Preliminar


35


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.


36


Consultas


37

Nome Referências Cruzadas

Vendas Mensais F20, F21, F22

Clientes Suspensos F13, F23, F1

... ...

Planejamento do Desenvolvimento

Alocar o desenvolvimento em ciclos iterativos de mesma duração.

Estimativa de Esforço:

Pontos de Função

Pontos de Caso de Uso


38

Estabelecendo Prioridades

Casos de Uso Críticos

Casos de Uso de Apoio

Conceitos

Consultas


39

Planejamento dos Ciclos Iterativos


40

Ciclo Casos de

Uso Manutenção de Informações

Consultas Observações Esforço estimado

1 Vender Livros (550)

- - Neste ciclo ainda não será implantado o mecanismo de persistência

550 horas

2 Encomenda Livros (300)

- - Implementar mecanismo de persistência (300 horas)

600 horas

3 Reservar Livros (270)

Livro (100), Cliente (100) e Reserva (100)

- - 570 horas

4 - Venda (100) todas (400) - 500 horas

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.


41

Planejamento com 4 equipes


42

Dias: 1-10 11-20 21-30 31-40 41-50 51-60 61-70 70-90

Ciclo 1 análise projeto implementação testes




Implantação implantação

Planejamento com 2 equipes


43

Dias: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220

Ciclo 1 análise projeto impl. testes




Implantação implant.

Dúvidas?

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: [email protected] até 25/10/2013. Não serão aceitos trabalhos após esta data!


Requisitos Profª.: Rosanete Grassiani dos Santos

[email protected]


Education

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