Administração de Projetos Aula4 - UEZO

Prévia do material em texto

Administração de Projetos
Levantamento de Requisitos
Objetivo
Explicar o processo de Coletar requisitos:
� O levantamento de requisitos
� Definição de Requisitos
� Requisitos Funcionais e Não funcionais 
� Técnicas de levantamento de requisitos
� Definição 
Uma condição ou capacidade necessitada por um usuário para resolver 
um problema ou alcançar um objetivo
– Condição necessária para a obtenção de certo objetivo, ou para o 
preenchimento de certo fim
- Uma condição ou capacidade que deve ser satisfeita por um sistema 
para satisfazer um contrato ou um padrão.
- Tudo o que o sistema deve fazer para implementar uma necessidade 
de automação requerida pela solução.
O LEVANTAMENTO DE REQUISITOS
Gerência de requisitos
Conceituação
• Requisito é uma condição ou capacitação necessária a 
um usuário / cliente / mercado para solucionar um 
problema ou alcançar um objetivo.
• É uma condição ou capacitação que um produto ou 
serviço precisa atender ou ter para satisfazer um 
contrato, padrão, especificação ou outro documento 
formalmente estabelecido.
Gerência de requisitos
Conceituação
• Requisito é uma função, restrição ou outra 
propriedade que precisa ser fornecida, 
encontrada ou atendida para satisfazer às 
necessidades do usuário do futuro sistema.
• A importância dos requisitos: 
� O que está contratado
� O que o cliente / mercado precisa
� O que deve ser obedecido
� O que é essencial no fornecimento
Gerência de requisitos
Conceituação
• Aos requisitos estão associados os principais problemas do 
desenvolvimento de projetos.
• Quando não refletem as reais necessidades dos usuários, estão 
incompletos e /ou inconsistentes, haverá mudanças em 
requisitos já acordados e a dificuldade para conseguir um 
entendimento comum entre usuários e executores são as 
principais dificuldades relatadas, provocando retrabalho, 
atrasos no cronograma, custos ultrapassados e a insatisfação 
dos clientes.
Regras de negócio
• São as decisões que regem uma organização, 
compreendidas por políticas recomendadas e 
obrigatórias que governam a interação entre 
empregados, clientes, fornecedores e sistemas 
automatizados.
• Expressões em diferentes níveis
� Informal ou textual
“Todo cliente deve que ter mais de 18 anos.”
� Técnico
Idade.cliente >= 18
Requisitos funcionais
• Requisitos funcionais especificam o que o produto 
deve ser capaz de executar:
� do ponto de vista dinâmico: comportamento quando 
executado em circunstâncias determinadas
� do ponto de vista estático: funções desempenhadas por cada 
entidade e a maneira como elas interagem 
• Abordam O QUE o sistema deve fazer :
1. O sistema deve permitir que cada professor realize o 
lançamento de notas das turmas nas quais lecionou.
2. O sistema deve permitir que o aluno realize a sua matrícula 
nas disciplinas oferecidas em um semestre. 
Requisitos funcionais
• É importante ressaltar que os requisitos 
descrevem “o que o produto deve fazer” - e 
também “o que ele não deve fazer” - sem dizer “o 
como fazer”.
• Quando o requisito é expresso em termos do seu 
comportamento, este item deve ser possível de 
ser percebido por um observador externo ao 
ambiente. 
Requisitos não Funcionais
Esses requisitos declaram características de qualidade que o sistema deve 
possuir e que estão relacionadas às suas funcionalidades. Temos 
algumas divisões dentro desse tipo de requisitos.
Confiabilidade
Nada mais do que medidas quantitativas da confiabilidade do sistema, como por 
exemplo, o tempo médio entre falhas, recuperação de falhas, erros por milhares 
de linhas de código.
Portabilidade
Aqui tratamos da facilidade de migrar o sistema para outras plataformas. Que 
devemos dar uma atenção, para que o sistema rode em qualquer lugar.
Segurança
Aqui são descritas as particularidades sobre acessos ao sistema, segurança 
extra em login, restringir acesso de algumas pessoas, entre outros.
Usabilidade
Aqui são descritos os requisitos que se relacionam ou afetam a usabilidade do 
sistema. Coisas relacionadas à facilidade de uso, sobre a necessidade de 
treinamentos para os usuários.
Requisitos não Funcionais
Requisitos de usabilidade
Como o próprio nome diz, estes são requisitos relacionados à como usar o 
sistema, qual será a experiência do usuário quando estiver utilizando o 
sistema. Em resumo podemos dizer que são requisitos que definam a 
facilidade no uso do sistema
Exemplos: 
- Pelo menos 90% dos relatórios e consultas devem exibir seus dados em até 
dois cliques
- Os campos de consulta por período devem já vir preenchidos com a consulta 
de hoje à +30d
- A validação de campos número deve ser executada de forma imediata após o 
preenchimento do campo.os usuários.
Requisitos inversos
� Significam o que o produto não deve fazer;
�A questão da ambiguidade das funcionalidades
�A questão dos limites e a importância de não se deixar 
uma expectativa falsa sobre o que o produto vai fazer.
Restrições de projeto e de 
implementação
�São condições que limitam como o produto poderá ser 
implementado
�Representam condições que deverão ser obedecidas 
pelos projetistas e na implementação do projeto
�Estas restrições podem ser de limitações do tempo, 
espaço, custo, ambiental, equipamento, processos, 
legislação, ética, tecnologia, etc.
Requisitos não técnicos
� Acordos
� Condições contratuais
� Representam limitações para a gerência 
do projeto, como prazo, recursos 
humanos e orçamento do projeto, datas, 
legislação, etc.
Ambiguidade na definição dos 
requisitos
�Requisitos incompletos
�Palavras de significado impreciso
�Custo da ambiguidade (exemplo para SW):
• Requisitos 1
• Projeto 3-6
• Fabricação 10
• Testes de desenvolvimento 15-40
• Testes de aceitação 30-70
• Operação 40-1000
� Fonte: Barry Bohem - Software Engineering Economics
Documentação 
�Uma vez compreendidos, analisados e aceitos, os 
requisitos devem ser documentados com um nível de 
detalhamento adequado, produzindo a especificação.
�São boas práticas da documentação de requisitos a 
adoção de formulários adequados para coleta de dados 
e registro da especificação dos requisitos; 
�a identificação das fontes de informação; 
�a atribuição de um rótulo para todos os requisitos e o 
registro das regras de negócio.
Validação
� Após terem sido documentados, é necessário que os 
requisitos sejam cuidadosamente validados, 
principalmente quanto à consistência e a completude. 
� Esta atividade visa identificar problemas nos 
requisitos, antes do início da construção. 
� A importância desta atividade é caracterizada pelo 
fato de que a correção de um erro nesta fase possui 
um custo muito inferior do que a correção nas fases 
mais adiantadas do processo de desenvolvimento.
Validação
� Na validação dos requisitos podem ser utilizadas 
técnicas para inspeção e revisão da especificação de 
requisitos; redigidos casos de testes a partir dos 
requisitos e definidos os critérios de aceitação do 
produto.
� prazo?
� custo?
� qualidade?
Boas práticas
� Seleção de um modelo de ciclo de vida 
apropriado, 
� Elaboração do plano do projeto com base nos 
requisitos - é comum começarem sem sequer terem 
escopo definido; 
� Renegociação dos compromissos tão logo se 
perceba que eles não possam ser cumpridos,
� Gerenciamento dos riscos associados a requisitos 
e a criação de condições para que os requisitos 
possam ser rastreados ao longo do projeto.
Questões Úteis
� Quem é o cliente?
� O que uma solução muito bem-sucedida significa 
para este cliente?
� Qualé a razão real para desejar solucionar este 
problema?
� Devemos usar uma equipe de projeto com quais 
características?
� Qual o prazo que temos para fazer o projeto?
� Onde mais pode ser obtida solução para este 
problema?
Algumas reflexões ...
� Podemos copiar algo existente?
� Que problemas este produto resolve?
� Que problemas este produto pode criar?
� Que ambiente este produto provavelmente 
encontrará?
� Qual o grau de precisão necessário ou desejado ao 
produto?
� Quais os aspectos relevantes do problema a resolver?
� Quem são as pessoas certas para responder as 
perguntas?
Algumas Reflexões...
� As respostas dadas são oficiais?
� Os requisitos estão sendo documentados 
e obtidas as aprovações de quem os 
forneceu?
� É possível ver o local onde se processam 
as ações do processo?
� Existe algo mais que possa ser 
perguntado para esclarecer o 
funcionamento do processo e evitar 
ambiguidades?
� Há incoerências entre as respostas?
Algumas reflexões ....
�Quais os outros processos que se relacionam com 
esse?
�Como este processo é relacionado com outros?
�Quais os resultados do projeto que são 
fundamentais para sua avaliação positiva?
�Quais os indicadores do processo?
�Quais os produtos intermediários do processo?
Só para lembrar ...
SMART
� Specific (específico)
� Mesurable (mensurável)
� Achievable (alcançável)
� Realistic (realista)
� Time bound (limitado pelo tempo)
Processo de Requisitos
Técnicas
Principais técnicas para levantar requisitos
� Entrevistas/Observação
� Grupos focais
� Workshops facilitados
� Técnicas criativas de grupo
� Técnicas para tomada de decisão
� Questionários e pesquisas
� Protótipos
Técnicas Utilizadas
Brainstorming
Técnica para geração de idéias. Ela consiste em uma ou várias reuniões que permitem 
que as pessoas sugiram e explorem idéias.
As principais etapas necessárias para conduzir uma sessão de brainstorming são:
· Seleção dos participantes: Os participantes devem ser selecionados em função das 
contribuições diretas que possam dar durante a sessão. A presença de pessoas 
bem informadas, vindas de diferentes grupos garantirá uma boa representação;
· Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os 
conceitos básicos de brainstorming e as regras a serem seguidas durante a 
sessão;
· Produzir uma boa quantidade de idéias: Os participantes geram tantas idéias
quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming.
Os participantes são convidados, um por vez, a dar uma única idéia. Se alguém 
tiver problema, passa a vez e espera a próxima rodada.
Documento de Requistos
Itens do documento de requisito
� Descrição: Uma sentença descritiva do significado do requisito
� Justificativa: Por que este requisito é considerado importante ou 
necessário?
� Fonte: Quem levantou este requisito?
� Critério de aceitação: Uma quantificação do requisito usada para 
determinar se a solução atende ou não ao requisito.
� Dependências: Outros requisitos que o afetam
� Conflitos: Requisitos que o contradizem.
� Materiais de apoio: Referência a informação de apoio.
� Histórico: Origem e mudanças feitas neste requisito
Objetivo
Matriz de rastreabilidade
Demonstração da planilha que correlaciona em uma tab
os Requisitos com os Casos de Uso, em outra tab os 
Casos de Uso com os Módulos do Sistema e com os 
casos de teste
Matriz de rastreabilidade
Matriz de rastreabilidade