Você está na página 1de 31

INTRODUO

A indstria de software e os prprios softwares so


caracterizados por falhas de projetos;
A maioria dos Projetos apresentam falhas devido
pobreza da elucidao e gesto dos requisitos;
As equipes reconheceram que um requisito muito mais
que apenas uma declarao.

Domingos Filipe de Oliveira

PORQUE OS REQUISITOS SO
IMPORTANTES ?
Causas de projectos falhados:
1. Requisitos incompletos (13.1%)

2.
3.
4.
5.
6.

Falta de envolvimento dos utilizadores (12.4%)


Falta de recursos (10.6%)
Expectativas irrealistas (9.9%)
Alterao de requisitos (8.7%)
Falta de planeamento (8.1%)

7. Sistema j no necessrio (7.5%)


Domingos Filipe de Oliveira

O QUE UM PROJETO DE SUCESSO ?


Satisfaz seus clientes e patrocinadores com
resultados que atendem seus objetivos dentro das
restries de tempo e custo, com produtos de
qualidade, mantendo e promovendo relaes
harmoniosas entre os envolvidos e contribuindo
pro aprendizado da organizao.
Daniel Garnier
Domingos Filipe de Oliveira

Frederick Brooks

Domingos Filipe de Oliveira

A parte mais difcil de construir


um software decidir
precisamente o que construir.
Nenhuma outra parte do trabalho
conceitual to difcil quanto
estabelecer os requisitos tcnicos
detalhados Nenhuma outra parte
danifica tanto o sistema resultante
se for feita de forma errada.
Nenhuma outra parte mais difcil
de retificar posteriormente.

CUSTO PARA SE REPARAR UM DEFEITO

ANLISE DE REQUISITOS
o 1 passo no modelo do processo;
So coisas a descobrir antes de comear a construir um
produto.
o processo de aquisio, refinamento e verificao das
necessidades do sistema.
O objetivo sistematizar o processo de definio dos
requisitos, obtendo uma especificao correta e completa
do mesmo para elaborao do Documento de Requisitos.
Domingos Filipe de Oliveira

DOCUMENTOS DE REQUISITOS
o documento oficial acerca do que pedido aos desenvolvidores do
sistema, o qual deve incluir os requisitos do utilizador como os do
sistema;

Definio de Requisitos contm uma lista de tudo o que o cliente espera que o
sistema faa. Define um entendimento entre o cliente e a equipa de
desenvolvimento sobre o que que o sistema deve fazer.

Especificao de Requisitos rescreve o documento de definio de requisitos em


termos tcnicos mais apropriados equipa de desenvolvimento e s actividades
de desenho.

Domingos Filipe de Oliveira

UTILIZADORES DO DOCUMENTO
Clientes: verificam se o que est descrito o que pretendem.
Gestores: para preparar um oramento para o desenvolvimento
e para planear o processo de desenvolvimento
Engenheiros de sistema: usam como base para o desenho do
sistema.
Engenheiros de teste: usam para desenvolver testes de
validao do sistema.
Engenheiros de manuteno: usam para compreender o
sistema e a relao entre os seus componentes.
Domingos Filipe de Oliveira

DEFINIO DE REQUISITOS
Permite estabelecer um conjunto de objetivos gerais que o
sistema deve cumprir;
Apresenta as caractersticas do que o sistema deve fazer e
no o que deve ser implementado;
Requisitos Funcionais so as declaraes das funes de
como o sistema.
Requisitos No Funcionais so restries que se coloca
sobre como o sistema deve realizar seus requisitos
funcionais
Domingos Filipe de Oliveira

DEFINIO DOS REQUISITOS


Eu quero alguma
coisa para chegar no
ISPH no menor tempo
possvel

Domingos Filipe de Oliveira

10

MUDANA NOS REQUISITOS


Mas eu quero algo
melhor! Como vou
carregar a minha
pasta ?

Domingos Filipe de Oliveira

11

RE-PROJECTO

Domingos Filipe de Oliveira

12

ENTREGA DO SISTEMAS

Domingos Filipe de Oliveira

13

DOCUMENTO DE REQUISITOS
Requisitos Funcionais

Requisitos No Funcionais

Ambiente fsico:
funcionar ?

atributos: nome, endereo, cidade,etc.

Interfaces: a sada vai para outros sistemas?

O utilizadore deve ser capaz de buscar todo o

Funcionalidade: existem limitaes quanto


velocidade de execuo ?

Fatores humanos: haver diversos tipos de


utilizadores?

Segurana: o acesso ao sistema ou s


informaes deve ser controlado?

O sistema deve permitir a incluso, alterao


e remoo de funcionrios com os seguintes

conjunto inicial do BD ou selecionar um


subconjunto a partir dele.

O sistema fornecer telas apropriadas para o


utilizador ler documentos.

Domingos Filipe de Oliveira

onde

equipamento

14

FONTES DE REQUISITOS
Bons requisitos iniciam com boas fontes. Encontrar tais fontes a primeira
tarefa, e muito importante;
Exemplos de fontes de requisitos:

Clientes

Utilizadores

Administradores e equipe de manuteno

Parceiros

Especialistas no domnio

Analistas

Informaes sobre os concorrentes

Domingos Filipe de Oliveira

15

ANLISE DE REQUISITOS COMO


OBT-LOS
Aps a identificao das fontes, devem ser selecionadas uma ou mais tcnicas de
coleta de requisitos
Tcnicas existentes:

Entrevista

Questionrio

Observao direta (trabalhar no ambiente onde funcionar o sistemas)

Sesses brainstorming

Demonstrar prottipos para os stakeholders

...

O Analista de sistemas deve saber como e quando utilizar cada uma, assim como as
combinar.
Domingos Filipe de Oliveira

16

ENTREVISTA
Usado quanto poucas pessoas conhecem as informaes necessrias
para o desenvolvimento do sistema. deve ser preparada
antecipadamente com perguntas objetivas:

Antes: planear, identificar a posio e responsabilidade do entrevistado, marcar


horrio, escolher local sossegado.

Durante: apresente-se informando a finalidade da entrevista, explique as


anotaes que fizer, no demore mais do que 2 horas, agradea a contribuio.

Depois: documente os pontos relevantes; envie a documentao ao entrevistado


(aprovao final), envie os resultados para os utilizadores e seus gestores.

Domingos Filipe de Oliveira

17

QUESTIONRIO
Usado quanto muitas pessoas conhecem as informaes necessrias
para o desenvolvimento do sistema, deve-se preparar
antecipadamente com questes objetivas:

Desvantagem: comunicao restrita com o utilizador e no h troca de informao


face a face. A preparao exige tempo.

Preparao: identificar o tipo de informao que deseja obter. Enviar carta


acompanhando o questionrio enfatizando a sua importncia.

Identificar quem responder: nome, funo e localizao.

Distribuir com instrues detalhadas de como preencher e o prazo de


devoluo.
Domingos Filipe de Oliveira

18

OBSERVAO DIRETA
Utilizada como processamento e confirmao de outros
resultados (entrevista e questionrio).
Identificar documentos que devem ser coletados para
posterior anlise.
Observar diretamente quem desenvolve o trabalho.
Deve ter aprovao antecipada das gerncias.
Domingos Filipe de Oliveira

19

SESSES BRAINSTORMING
til para obter rapidamente informaes sobre a atual situao;
Reune pessoas com diferentes nveis de informao e
conhecimento sobre o sistema desejado;
A discusso em grupo conduzida por um mediador;
Trata-se de uma sesso em grupo, curta, onde qualquer um
pode incluir um tpico que ache importante ser discutido
Aps esse momento inicial, um facilitador ajuda o grupo a
organizar e priorizar os resultados
Domingos Filipe de Oliveira

20

WORKSHOP DE REQUISITOS
Trazer todos os envolvidos para participar de um evento onde o
objetivo a descoberta de requisitos
Durao de dois a cinco dias
Passos:
1. Classificar (ou criar) um conjunto de requisitos
2. Revisar os requisitos
3. Melhorar os requisitos

Todos no workshop tentam estimar o custo e o valor para cada requisito


Um workshop propicia a aplicao de outras tcnicas, como o brainstorm
Domingos Filipe de Oliveira

21

ESTRUTURA DE UM DOCUMENTO DE
ESPECIFICAO DE REQUESITOS (IEEE-830)

Introduo

Viso

mbito

Descrio Geral

Requisitos de Negcio (incluindo servios oferecido pelo sistema e benefcios esperados)

Requisitos do Utilizador

Restries

Especificaco detalhada

Requisitos Funcionais

Requisitos No-Funcionais

Glossrio

ndices remissivos

Domingos Filipe de Oliveira

22

DOCUMENTO DE REQUISITOS
Nvel de detalhamento
Depende do tipo de sistema que est sendo
desenvolvido e do processo utilizado;
Quando o sistema for desenvolvido por um
desenvolvedor externo, as especificaes de um
sistema crtico devem ser precisas e muito
detalhadas.
Domingos Filipe de Oliveira

23

DOCUMENTO DE REQUISITOS
(CONT.)
Nvel de detalhamento
Quando houver maior flexibilidade nos requisitos e quando
um processo de desenvolvimento interno e iterativo for
usado, o documento de requisitos pode ser muito menos
detalhado.

Geralmente, o foco a definio dos requisitos de usurio


e dos requisitos no funcionais
Domingos Filipe de Oliveira

24

REQUISITOS E MTODOS GEIS


Mtodos geis argumentam que os requisitos mudam to
rapidamente que um documento de requisitos fica
desatualizado to logo seja redigido, por isso o esforo
desperdiado;
Ao invs de um documento formal, as abordagens como
XP propem que os requisitos de utilizadores sejam
escritos em cartes.

Domingos Filipe de Oliveira

25

COMO GERIR REQUISITOS ?


Devido aos inmeros problemas com o processo de gesto o
uso de ferramentas tornou-se essencial;
Exemplo: A ferramenta TIGER Pro apresenta uma abordagem
orientada objetos para a gesto de requisitos;

uma sigla para Tool to In Gest and Elucidate Requeriments


Professional;
projetado para ajud-lo a modernizar os seus requisitos e a
escrever bons requisitos;
Domingos Filipe de Oliveira

26

COMO TIGER PRO PODE


CONTRIBUIR ?
Auxiliando na boa escrita de requisitos;
Reviso rpida de documentos;
Garantindo a integridade dos requisitos de teste contido em mltiplos
pargrafos de requisitos;
Sua abordagem orienta aos objetos ajuda a adicionar novos requisitos
e gerir as falhas do projeto;
A propriedade add-on permite que o novo requisito seja adicionado
dentro do objeto de exigncia;
Alm disso, o empacotamento de processos e funcionalidades em
conjunto com os dados podem ser automatizados;
Domingos Filipe de Oliveira

27

OBSERVAO IMPORTANTE!
Na fase de anlise de requisitos no so
considerados
detalhes
de
projeto
e
implementao a preocupao com o que
ser includo no software.

Domingos Filipe de Oliveira

28

OBSERVAES IMPORTANTES
(CONT.)
Na elaborao do documento de requisitos deve-se evitar
termos vagos, como: geralmente, etc, as vezes
O documento de requisitos tem que ser completo,
consistente, preciso e sem ambiguidade.

Domingos Filipe de Oliveira

29

DUVIDAS
???
Seu trabalho vai ocupar uma grande parte da sua vida, e a nica maneira de estar verdadeiramente
satisfeito fazendo aquilo que voc acredita ser um timo trabalho.
(Steve Jobs)

Domingos Filipe de Oliveira

30

BIBLIOGRAFIA

PRESSMAN, Roger S. Engenharia de Software. Mc Graw


Hill, 6 ed, Porto Alegre, 2010.

Domingos Filipe de Oliveira

31

Você também pode gostar