Resumo Gerenciamento de Escopo

Aula 2 – Gerenciamento de Escopo – Mód. 3 e 4

• Os requisitos devem ser ESPECÍFICOS e ATÔMICOS (ou seja, sozinhos. Nunca usar a palavra “e” ou “ou”)
• AXIOMATIC DESING: os requisitos inevitavelmente começarão com as necessidades dos clientes (o que precisa ser feito), e serão decompostos gradativamente até que se entenda os detalhes de implementação (como se deve fazer). A Axiomatic Design (AD) é uma abordagem para o desenvolvimento de projetos que procura gerar a melhor solução para um determinado problema proposto (CARNEVALLI et al., 2010).
• “O primeiro passo no desenho de um sistema é determinar as necessidades dos clientes (CN) ou atributos, no domínio do cliente, que o sistema deverá satisfazer. Então, os requisitos funcionais e restrições do sistema, no domínio funcional, são determinados para satisfazer às necessidades levantadas. O próximo passo é mapear os requisitos funcionais dentro do domínio físico, ou seja, escolher os parâmetros conceituais, tomando o cuidado para não gerar conflitos com as restrições. Uma vez escolhidos esses parâmetros, passa-se para a etapa do domínio do processo, onde as variáveis dos processos serão identificadas, com o objetivo de desenvolver um novo processo de fabricação ou usar algum processo existente”
• Essas ferramentas devem ser utilizadas para produzir, como saída do processo, dois documentos:

• a) Documentação dos requisitos: onde é descrito como os requisitos individuais atendem às necessidades do negócio. Nesse documento, os requisitos não devem ser descritos de forma ambígua, ou seja, devem ser mensuráveis e passíveis de testes. Também devem ser rastreáveis, completos, consistentes e aceitáveis pelas partes interessadas.
• b) Matriz de rastreabilidade dos requisitos: uma tabela que liga os requisitos de produto desde as suas origens até as entregas que os satisfazem

• Domínio do cliente, através da identificação das necessidades dos clientes ou do negócio (as características que o cliente pretende encontrar em um objeto, seja ele um produto, um processo, ou qualquer sistema tangível ou intangível);
• Domínio conceitual, através da identificação dos requisitos funcionais do objeto (um requisito funcional descreve um comportamento que um dispositivo deve ter) e suas restrições (representam os limites de uma solução aceitável);
• Domínio físico, através de parâmetros conceituais ou requisitos técnicos (o conjunto de propriedades que descrevem fisicamente o objeto); e
• Domínio do processo, através de um esboço de como fazer o objeto concebido (ligado ao processo de manufatura).
• Requisitos funcionais devem ser coletados primeiro (especificação das capacidades) são definidos pelo cliente, não pela equipe de projetos. A equipe pode ajudar, mas o cliente precisa dizer o que ele quer!
• Os requisitos técnicos devem ser coletados após os funcionais. (Quais os requisitos técnicos para atender os requisitos funcionais?) A equipe de projetos define e valida com o cliente
• Requisitos de processo.

Exemplo: [pic 1]

• As classificações podem ser diversas. Outros exemplos de classificação: Requisitos externos, internos funcionais, interno não funcionais (confiabilidade, durabilidade, disponibilidade e segurança. Não requisitos que não dão pra “ver” não dá pra “pegar”, em geral são propriedades)
• Técnicas de coleta de requisitos: Os requisitos podem ser coletados por histórias dos usuários (as pessoas entendem melhor o que precisa ser feito quando pensam em narrativas), métodos ágeis
• Método dos 3 C: Cartão (para quem deve ser realizada? O que deve ser feito? Para que ele precisa?), Conversa (levantamento ocorre durante as conversas entre equipe cliente) e confirmação
• Verificação: equipe de qualidade, equipe de teste, foco é descobrir defeito. Depois disso vem a VALIDAÇÃO que tem o objetivo de confrontar se os requisitos foram atingidos.

• Como verificar se já coletou todas as informações da história do usuário? [pic 2]
• Definir o escopo: Foco nas entregas (agrupamento de requisitos similares). Definição de feito? Quando não falta nada? Definition of done.

Modulo 3 – Coletar requisitos

• Processo "coletar os requisitos": peculiaridades, entradas, técnicas e ferramentas (parte I)

• Traduzir as necessidades e as expectativas dos stakeholders em requisitos que sejam específicos, mensuráveis, realizáveis e compreensíveis, rastreavel;

• Conjunto de desejos das parte interessada; Muitas vezes são amplas e subjetivas;

• Frases simples e curtas. Use afirmações sempre que possível;

• Quando a gestão de requisitos é inadequada, as consequências podem ser graves, sendo piores para organizações de baixo desempenho, nas quais mais da metade das falhas em projetos se deve, principalmente, a esse fator;

Requisitos podem ser classificados de diversas formas:

Requisitos de projeto:

- De negócio:

-De gerenciamento de projetos

[pic 3]

Requisitos de produto/ Ou de solução:

- Bens tangíveis ou bens intangíveis (Funcionais ou não funcionais)[pic 4]

É um processo social e pode gerar desconfortos pelos relacionamentos interpessoal.

Coletar requisitos:

Objetivos e os benefícios do processo de coleta de requisitos;

Coletar requisitos é essencial para definir escopo; Cuidado com atributos como “Bonito/ confortável”

...