1 Melhoria de Processo da Engenharia de Requisitos

1

Melhoria de Processo da Engenharia de Requisitos

2© 2003 Jaelson Castro

Objetivos Introduzir a idéia de maturidade de

processo Propor um modelo de maturidade do

processo de engenharia de requisitos


1- Processo da Engenharia Requisitos

Requirementselicitation

Requirementsanalysis andnegotiation

Requirementsdocumentation

Requirementsvalidation

Requirementsdocument

User needsdomain

information,existing system

information,regulations,

standards, etc.

AgreedrequirementsSystem

specification


1- Atividades do Processo de ER Elicitação de Requisitos

Os requisitos são descobertos através da consulta com as partes interessadas

Análise e negociação de requisitos Requisitos são analisados e os conflitos resolvidos

através de negociação Documentação de requisitos

Um documento de requisitos é produzido Validação de requisitos

É checada a consistência e completude do documento de requisitos


2- Melhoria de Processo Estratégia evolucionária: ciclo de

melhoria contínuo com pequenos passos. Aplicação interativa das diretrizes sugeridas.

Melhoria do Processo não é simplesmente a introdução de novos métodos e técnicas.


2- Melhoria de Processo Questões a discutir antes de planejar

melhorias de processo:

1.Quais são os problemas do nosso processo atual?

Prazos e orçamentos estourados, qualidade dos produtos, relutância de assumir responsabilidade, muito tempo gasto em reuniões.


2- Melhoria de Processo2.Quais são os nossos objetivos de

melhoria? É importante que sejam realísticos! Orçamento estourado => evitar retrabalho.

3.Como introduzir melhorias no processo para alcançar estes objetivos?

As diretrizes o ajudarão. Melhorias específicas para cada organização.


2- Melhoria de Processo3.Como as diretrizes deveriam ser

controladas e gerenciadas? Pessoas envolvidas no processo comprometidas

com os objetivos de melhoria e envolvidas na implementação prática do processo de mudança.

Cada organização deve escolher e priorizar as diretrizes mais apropriadas para as suas necessidades.


2 - Maturidade de Processo Software Método para avaliar a maturidade das

companhias (Capability Maturity Model - CMM)

Organizações deveriam avaliar sua maturidade e então, introduzir mudanças no processo que permitirão progredir no processo de cinco níveis


SEI – Evoluindo nosníveis de maturidade esoftware

Nível 1Inicial

Nível 2Repetível

Nível 3Definido

Nível 4Gerenciador

Nível 5Otimizador

Ênfase contínua noprocesso de mediçãoe técnicas paraprevenção de erros.

Quantitativo produtividade aacompanhamento.

Instrumentos para os processosambientais.

Investimentos em tecnologiaeconomicamente justificados.

Estabelecer um processo de métrica. Estabelecer métricas quantitativas equalitativas para objetivos, planos eperformance.

Desenvolvimento de processos e definições padrão. Processo de alocação de recursos. Definição de um MDS-requisitos, projeto, inspeção, teste.

Falta de Planejamento: tamanhos, custos, prazos. Acompanhamento de performance, controle de alterações,comprometimento gerencial, controle de qualidade.

2 - Melhoria de Processo Software


2 - Melhoria de Processos de Requisitos

Nível 3 – Definido

Processo de ERexplicitamente definidobaseado na melhor prática.Processo de melhoria deprocesso.

Nível 2 - Repetível

Padrões definidos paradocumentos de requisitos eatividades de processo.Poucos problemas de requisitos,especialmente para sistemas jáconhecidos.

Nível 1 – Inicial

Não existe processo deengenharia de requisitos definido,dependendo da habilidade eexperiência dos engenheiros.Muitos problemas de requisitos.


2 - Melhoria de Processo Encontre um “evangelizador”

Convença alguém envolvido no processo do valor das mudanças propostas.

Tente mudanças em projetos pilotos Avalie vantagens/desvantagens das

mudanças.


2 - Melhoria de Processo Conceda tempo suficiente para executar a

mudança Não utilize projetos com prazos finais curtos.

Respeite as habilidades dos profissionais O objetivo das mudanças é ajudar a melhorar

a qualidade do trabalho.


2 - Melhoria de Processo A ordem pela qual as diretrizes devem ser

introduzidas depende do processo e das necessidades de melhorias identificadas.


2 - Custos de Melhoria Custo do pessoal de melhoria (dedicado) Custo de introduzir mudanças no processo Nem sempre consegue-se informações

quantitativas, avalia-se então, conversando com as pessoas envolvidas.

Se a diretriz não produziu efeito, descarte-a.


2 - Melhoria de Processo Aplicabilidade das diretrizes:

Documentos de requisitos Elicitação de requisitos Análise e negociação de requisitos Descrição de requisitos Modelos de sistemas Validação de requisitos Gerenciamento de requisitos


2- Classificação das DiretrizesTIPO Básicas

DESCRIÇÃO Diretrizes relativamente simples que proporcionam uma base para um processo de engenharia de requisitos repetível onde pode-se estimar custo, tempo e recursos necessários para engenharia de requisitos.

CUSTO Normalmente são relativamente baratas para introduzir e usar. Deveriam ser introduzidas primeiro.

Intermediárias

Diretrizes um pouco mais complexas que levam a um processo de engenharia de requisitos definidos. Na maior parte dizem respeito à introdução de sistemática e métodos estruturados no processo de engenharia de requisitos.

Geralmente custam mais e demoram mais para serem introduzidas que as básicas.

Avançadas Destinam-se a apoiar melhorias contínuas do processo de engenharia de requisitos. Incluem diretrizes para métodos avançados tecnicamente e diretrizes para mudança organizacional.

Variável. Algumas, baseadas em tecnologia avançada, são caras, outras são relativamente baratas mas requerem mudanças organizacional.


3 - Documento de Requisitos O documento de requisitos é usado para

apresentar os requisitos do sistema ao cliente, usuários do sistema, gerentes e desenvolvedores.

Seguindo as diretrizes relacionadas podemos melhorar a estrutura e a organização deste documento.


3 - Documento de Requisitos 3.1. Defina uma estrutura de documento padrão 3.2. Explique como utilizar o documento 3.3. Inclua um sumário de requisitos 3.4. Mostre a importância do sistema para o negócio 3.5. Defina termos especializados 3.6. Faça leiaute do documento 3.7. Ajude leitores a encontrar informações 3.8. Faça o documento fácil de alterar.


3.1-Defina uma estrutura de documento padrão Benefício principal: Melhorar a qualidade,

diminuir custos dos documentos de requisitos.

Custo de introdução: Moderado - alto Custo de aplicação: Baixo Tipo : Básica


3.1-Defina uma estrutura de documento padrão Benefícios

Facilidade de encontrar informação e entender os relacionamentos entre diferentes partes do documento.

Direcionar o processo de revisão do documento facilitando inclusive verificação se alguma seção foi esquecida.

Pode-se desenvolver um software para produzir documentos de requisitos.


3.1-Defina uma estrutura de documento padrão Implementação

Depende da organização, do tipo de sistema e do processo de desenvolvimento.

Partes estáveis Partes variantes – devem estar especificadas numa

parte introdutória.


3.1-Defina uma estrutura de documento padrão Custos e Problemas

Deve-se levar vários meses para analisar e entender os documentos existentes e extrair o padrão apropriado para eles.

O documento deve ser revisado periodicamente e atualizado quando necessário.

Uma vez definido os custos de aplicabilidade são baixos.


3.2- Explique como utilizar o documento Benefício principal: Diminuir tempo de

leitura necessário para o entendimento do documento de requisitos.

Custo de introdução: Muito baixo Custo de aplicação: Muito Baixo Tipo : Básica


3.2- Explique como utilizar o documento Deve-se incluir uma seção de introdução

explicando como deve ser utilizado, para os diferentes tipos de leitores.


3.3- Inclua um sumário de requisitos Benefício principal: Documento de

requisitos mais compreensível. Custo de introdução: Muito baixo Custo de aplicação: Baixo Tipo : Básica


3.3- Inclua um sumário de requisitos Uma seção que resume o propósito do

sistema e os requisitos principais do sistema.

Benefícios: Permite uma visão geral. Focaliza a atenção em requisitos críticos Atua como mapa de requisitos.


3.3- Inclua um sumário de requisitos

Implementação: 1 – Lista numerada 2 – Tabela 3 – Gráficos – útil para exibir relacionamentos entre os requisitos.

Custos e problemas: Tempo necessário para produzir um sumário dos requisitos

depende do tamanho do sistema. Dificuldade para grande numero de requisitos. Prazos estrangulados, a tendência é desprezar esta seção.


3.4 - Mostre a importância do sistema para o negócio Benefício principal: Propõe uma justificativa

para os requisitos do sistema. Custo de introdução: Muito baixo Custo de aplicação: Muito baixo Tipo : Básica


3.4 - Mostre a importância do sistema para o negócio Uma seção explicando a necessidade do

sistema e como ele contribuirá para os objetivos gerais do negócio da organização.

Explica as razões originais dos requisitos.


3.5 - Defina termos especializados

Benefício principal: Evita mal-entendidos. Custo de introdução: Baixo Custo de aplicação: Baixo-moderado Tipo : Básica


3.5 - Defina termos especializados

Devem ser definidos em um glossário: Termos específicos de um domínio de aplicação Termos utilizados de forma específica.

Benefícios Leitores têm diferentes experiências Evita utilizar um mesmo termo com significados

diferentes. Domínios da aplicação possuem jargões próprios.


3.6 - Faça um leiaute do documento

Benefício principal: Facilita a leitura do documento de requisitos.

Custo de introdução: Baixo Custo de aplicação: Baixo Tipo : Básica


3.6 - Faça um leiaute do documento

O leiaute do documento de requisitos deveria ser projetado de forma que facilite a leitura.

Defina o leiaute como parte do padrão do documento de requisitos.

Introduzir uma seção explicando o leiaute.


3.6 - Faça um leiaute do documento Implementação

Defina margens largas. Linhas grandes dificultam a leitura. Não justifique à direita.

Organize seções e subseções. Use a mesma técnica de ênfase para o mesmo tipo de

informação. Use tabelas, listas com bolinhas ou numeradas para conjuntos

de informações. Separe as equações do texto com espaço e utilize fonte

diferente. Use diagramas para descrever seqüências. Diagramas devem

possuir menos que 12 elementos. É melhor utilizar vários diagramas simples que um complexo.


3.7 - Ajude leitores a encontrar informação

Benefício principal: Torna o documento mais utilizado como uma referência do sistema.

Custo de introdução: Muito baixo Custo de aplicação: Baixo-moderado Tipo : Básica


3.7 - Ajude leitores a encontrar informação

Utilize facilidades de documentação como índices remissivos e analíticos que facilite ao leitor encontrar informação.


3.8 - Faça o documento fácil de alterar

Benefício principal: Redução nos custos de alteração de requisitos.

Custo de introdução: Baixo Custo de aplicação: Muito baixo Tipo : Básica



Não deveria ser necessário emitir um novo documento completamente cada vez que uma alteração é feita.

Alguma técnicas gerais: Produza em encadernadores de folhas soltas ao menos para uso

interno. Alguns processadores de texto marcam as linhas que foram

alteradas. Evite referências para os números das páginas.



Rotule sempre as figuras e as referências apenas pelo rótulo.

Faça capítulos curtos. Comece novos capítulos em paginas separadas. Evite numerar páginas em relação aos capítulos ou

fazendo referência ao total de páginas do documento. Alguns processadores de texto trocam as referências

a figuras automaticamente(Ex: Framemaker).



Para garantir que o documento está atualizado pode-se utilizar papéis coloridos e imprimir no cabeçalho ou rodapé a data da última revisão.

Listas de revisões deveriam ser emitidas periodicamente.


4 - Elicitação de Requisitos Processo de descobrir os requisitos para um

sistema através de comunicação com clientes, usuários do sistema e todos os envolvidos.

Requer domínio da aplicação e conhecimento organizacional tanto quanto conhecimento do problema específico.


4 - Elicitação de Requisitos As diretrizes são: 4.1. Avalie se o sistema é viável 4.2.

Seja sensível a considerações organizacionais e políticas

4.3. Identifique e consulte stakeholders do sistema

4.4. Registre fontes de requisitos 4.5. Defina o ambiente de operação do sistema


4 - Elicitação de Requisitos 4.6. Utilize objetivos do negócio para conduzir a elicitação

de requisitos 4.7. Localize as restrições do domínio 4.8. Registre a justificativa do requisito 4.9. Colete requisitos de vários pontos de vistas 4.10. Elabore protótipo dos requisitos dos requisitos que não

estão claros 4.11. Use cenários para elicitar requisitos 4.12. Defina processos operacionais 4.13. Reutilize requisitos


4.1 - Avalie se o sistema é viável

Benefício principal: Revela se o sistema é realmente necessário e realístico tecnologicamente.

Custo de introdução: Baixo Custo de aplicação: Baixo a moderado Tipo : Básica



Consiste de três fases: Decida pela informação que você precisa Obtenha esta informação das fontes principais Produza um relatório

Exemplos de perguntas elaboradas para descobrir as informações críticas necessárias:

O sistema é realmente necessário? Quais as conseqüências se não o desenvolvermos?



Quais as contribuições diretas e indiretas para os objetivos do negócio?

Quais processo críticos o sistema deve suportar? Quais processo críticos não necessitam ser

suportados pelo sistema? Como o sistema afetará os outros sistemas já

instalados? Quais as limitações tecnológicas? Pode ser desenvolvido no orçamento disponível?


Benefício principal: Ajuda a entender o porquê dos requisitos sugeridos.

Custo de introdução: Baixo Custo de aplicação: Muito baixo Tipo : Básica

4.2 - Seja sensível a considerações organizacionais e políticas


Exemplos de inferências organizacionais e políticas nos requisitos:

Objetivos conflitantes - tente descobrir objetivos pessoais

Perda ou transferências de responsabilidade - aqueles que perderão responsabilidade poderão sugerir requisitos impossíveis ou muito caros para implementar.



A cultura organizacional - se departamentos são competitivos, seus requisitos exibirão uma margem de competitividade.

Atitudes gerências e moral da organização - em período de demissão pessoas podem ser hostis à gerência e não se envolver no processo de engenharia de requisitos.

Diferenças departamentais - diferentes culturas refletirão nos requisitos.



4.3 - Identifique e consulte stakeholders do sistema

Benefício principal: Descoberta de todas as fontes de requisitos.

Custo de introdução: Muito baixo Custo de aplicação: Baixo Tipo : Básica



STAKEHOLDER DO SISTEMA - qualquer pessoa que se beneficiará direta ou indiretamente com o sistema a ser desenvolvido.

Podem ser identificados: Descobrindo os potenciais usuários Descobrindo as pessoas envolvidas nos processo do

negócio que o sistema possuirá



Perguntando ao gerente quem será afetado. Considerando os clientes da organização que

utilizarão o sistema. Considerando pessoal responsável por desenvolver e

manter o sistema. Considerando autoridades externas, como autoridades

de regulamentos e certificações.

Devem ser explicitados os stakeholders e seus respectivos objetivos.


4.4 - Registre as fontes de requisitos

Benefício principal: Encontrar as fontes originais de requisitos.



4.4 - Registre as fontes de requisitos

Fonte de requisitos é um elo para informações nas quais os requisitos são baseados.

Identifique a fonte principal.


4.5 - Defina o ambiente de operação do sistema

Benefício principal: Menos problemas na instalação.




Informações a serem coletadas: Informações da plataforma – características da

máquina, do sistema operacional e das bibliotecas instaladas incluindo versões.

Informações de interface – se o sistema interage com outros, por exemplo banco de dados deve-se especificar a interface fornecida por este sistema.

Dependências de software – o sistema depender de outro sem precisa de interface. Por exemplo, ao disponibilizar um processador de texto deve-se especificar a versão a ser instalada.



Deve-se ficar em um capítulo separado e prever possíveis mudanças durante a vida do sistema.


4.6 - Utilize objetivos do negócio para conduzir elicitação de requisitos

Benefício principal: Requisitos são focalizados nas necessidades principais do negócio.

Custo de introdução: Baixo (com envolvimento de gerente senior)

Custo de aplicação: Baixo Tipo : Básica


Objetivos abstratos de alto nível que devem ser satisfeitos.

Deveriam ser cinco ou menos, como por exemplo, serviços para clientes, confiabilidade, segurança e custo,

sendo posteriormente mais detalhados em posteriores decomposições.

4.6 - Utilize objetivos do negócio para conduzir elicitação de requisitos


4.7 - Localize as restrições do domínio

Benefício principal: Restrições de domínio freqüentemente servem para identificar requisitos críticos.

Custo de introdução: Baixo Custo de aplicação: Moderado Tipo : Intermediária


4.7 - Localize as restrições do domínio

Restrições de Domínio - São os requisitos que vêm do domínio da aplicação do sistema.

Devemos estudar o domínio e entender estas restrições como parte do processo da elicitação de requisitos.


4.8 - Registre a justificativa do requisito

Benefício principal: Melhorar o entendimento do requisito.

Custo de introdução: Baixo Custo de aplicação: Baixo-moderado Tipo : Intermediária


4.8 - Registre a justificativa do requisito

A justificativa de um requisito é a informação que resume as razões pela qual este requisito foi especificado.


4.9 - Colete requisitos de vários pontos de vistas Benefício principal: Melhorar a abrangência

do requisito. Custo de introdução: Moderado Custo de aplicação: Moderado-alto Tipo : Intermediária


4.9 - Colete requisitos de vários pontos de vistas

Serve para priorizar requisitos.

Requisitos que são sugeridos de vários pontos de vista devem ter uma prioridade alta.


4.10 - Elabore protótipo dos requisitos que não estão claros Benefício principal: Melhorar o entendimento

da real necessidade dos usuários do sistema.

Custo de introdução: Moderado Custo de aplicação: Alto Tipo : Intermediária


4.10 - Elabore protótipo dos requisitos que não estão claros

Quando se tem um vago entendimento do requisito, devemos considerar o desenvolvimento de um protótipo o qual deve simular a necessidade do usuário final que poderá refinar as idéias sobre este requisito.


4.11 - Use cenários para elicitar requisitos Benefício principal: É fácil entender cenários

e descrever os requisitos associados. Custo de introdução: Alto Custo de aplicação: Baixo Tipo : Intermediária


4.11 - Use cenários para elicitar requisitos Usuários simulam interação com o sistema

utilizando cenários.

Explicam para os engenheiros de requisitos o que estão fazendo e que desejam do sistema.


4.12 - Defina processos operacionais Benefício principal: Revisão dos requisitos do

processo e restrições dos requisitos. Custo de introdução: Alto Custo de aplicação: Moderado Tipo : Intermediária


4.12 - Defina processos operacionais Devemos analisar,

entender e documentar

os processos como parte do processo de elicitação de requisitos.


4.13 - Reutilize requisitos Benefício principal: Baixo custo, elicitação

mais rápida de requisitos. Custo de introdução: Moderado-alto Custo de aplicação: Moderado Tipo : Avançada


4.13 - Reutilize requisitos

No desenvolvimento de requisitos para um novo sistema devemos sempre que possível utilizar requisitos de outros sistemas desenvolvidos na mesma área.


5 - Análise e negociação de requisitos

Após um levantamento inicial dos requisitos, devemos analisar conflitos, omissões, inconsistências e sobreposições entre os requisitos.

Quando as informações desta análise estiverem disponíveis, os stakeholders do sistema devem entrar num acordo.

Conflitos devem ser resolvidos e requisitos priorizados.



As diretrizes para esta fase são: 5.1. Defina os limites do sistema 5.2. Use “checklists” para análise de requisitos 5.3. Utilize software para manter negociações 5.4. Planeje-se para conflitos e resolução de

conflitos 5.5. Priorize requisitos



5.6. Classifique requisitos usando uma estratégia multi-dimensional

5.7. Use matrizes para encontrar conflitos e sobreposições

5.8. Avalie os riscos dos requisitos


5.1 - Defina os limites do sistema

Benefício principal: Elimina requisitos desnecessários.



5.1 - Defina os limites do sistema

Diferencie os requisitos do sistema, os dos processos operacionais associados ao sistema e os que estão fora do escopo do sistema.

Deve-se preparar argumentos técnicos e/ou econômicos baseados nos objetivos do negócio e no estudo de viabilidade.


5.2 - Use “checklists” para análise de requisitos

Benefício principal: Análise de requisitos mais rápida e mais completa.

Custo de introdução: Baixo-moderado Custo de aplicação: Baixo Tipo : Básica ou intermediária



CHECKLIST - Lista de questões utilizada para avaliar cada requisito.

Desenvolva uma lista de problemas de requisitos e a utilize na análise sistemática de requisitos.



A lista é apenas um guia para descobrir problemas, não deve-se limitar a ela.

Não deve possuir mas de 10 itens e não deve ser usada para atividade de gerenciamento de qualidade.


5.3 - Utilize software para manter negociações

Benefício principal: Resolução mais rápida de problemas de requisitos.

Custo de introdução: Moderado Custo de aplicação: Moderado Tipo : Intermediária


5.3 - Utilize software para manter negociações

Em organizações no nível de maturidade básica pode-se utilizar correio-eletrônico ou “bulletin board”, enquanto que nas de nível intermediário groupware ou sistemas de conferência são mais adequados.


5.4 - Planeje-se para conflitos e resoluções de conflitos

Benefício principal: Resolução mais rápida de problemas de requisitos.



5.4 - Planeje-se para conflitos e resoluções de conflitos

Antecipe-se a conflitos, sobreposições e omissões no conjunto de requisito e planeje encontros de negociação para discutir e resolver os problemas.

Não se recomenda utilizar correio-eletrônico, pois perde-se o histórico das negociações.


5.5 - Priorize requisitos Benefício principal: Focaliza atenção nos

requisitos mais importantes. Custo de introdução: Baixo Custo de aplicação: Baixo Tipo : Básica


5.5 - Priorize requisitos Deveriam ser atribuídas prioridades a requisitos

individuais para refletir sua importância para stakeholders e para o sucesso geral do sistema.

Classifique em essenciais, úteis e desejáveis.


5.6 - Classifique requisitos usando uma estratégia multi-dimencional

Benefício principal: Ajuda a descobrir conflitos e inconsistências entre os requisitos.

Custo de introdução: Baixo-moderado Custo de aplicação: Moderado Tipo : Intermediária


5.6 - Classifique requisitos usando uma estratégia multi-dimencional

Classificar requisitos para identificar requisitos relacionados.

Classificação multi-dimensional - derivar de diferentes modos de classificação os requisitos para análise.

Cada requisitos pode cair em um número diferente de classes.


5.7 - Use matrizes de interação para encontrar conflitos e sobreposições

Benefício principal: Descobrir requisitos conflitantes e sobrepostos.

Custo de introdução: Baixo Custo de aplicação: Moderado-alto Tipo : Intermediária


5.7 - Use matrizes de interação para encontrar conflitos e sobreposições

Matriz de interação linhas e colunas são rotuladas com os

identificadores dos requisitos. Os elementos são preenchidas com o valor que

indica se é ou não conflitante, sobreposto ou independente.

é adequada para poucos requisitos.


5.8 - Avalie os riscos dos requisitos

Benefício principal: Identificação de problemas nos requisitos.

Custo de introdução: Moderado Custo de aplicação: Moderado Tipo : Avançada


5.8 - Avalie os riscos dos requisitos

Para cada requisito ou conjunto de requisitos relacionados, realizar uma análise de risco que indiquem possíveis problemas que podem aparecer na implementação destes requisitos e o efeito que estes problemas teriam.


6 - Descrição dos requisitos As descrições individuais dos requisitos

devem ser concisas, fáceis de entender e não devem ser ambíguas.

O foco das diretrizes para esta fase é “como escrever estas descrições”:


6 - Descrição dos requisitos 6.1. Defina templates padrões para definir

requisitos 6.2. Use linguagem simples, consistente e

concisa 6.3. Use adequadamente diagramas 6.4. Suplemente a linguagem natural com

outras descrições de requisitos 6.5. Especifique quantitativamente os

requisitos


6.1 - Defina templates padrões para definir requisitos

Benefício principal: Requisitos são apresentados de forma mais consistente e mais fácil de entender.

Custo de introdução: Moderado Custo de aplicação: Baixo Tipo : Básica



O template deveria incluir campos para coletar informações detalhadas necessárias para especificar completamente o requisito.

Deve-se definir vários templates para atender a diferentes tipos de requisitos.



Pode-se incluir campos para atender a outras diretrizes, tal como: Número de referência do requisito (9.1) Fontes do requisito (4.4) Razões do requisito (4.8)


6.2 - Use linguagem simples, consistente e concisa

Benefício principal: Requisitos mais fáceis de ler e entender.

Custo de introdução: Muito baixo Custo de aplicação: Baixo-moderado Tipo : Básica


6.2 - Use linguagem simples, consistente e concisa

Evite construções de sentenças complexas, parágrafos e sentenças longos e terminologia ambígua.

Defina um guia de estilo curto e de fácil leitura.


6.3 - Utilize adequadamente diagramas

Benefício principal: Diagramas são especialmente úteis para documentar relacionamentos de requisitos.




Diagramas podem ser usados para exibir informações na descrição dos requisitos, resumir informações numéricas e descrever seqüências de eventos.



Diagramas o mais simples possível utilizar caixas e linhas simples, nomeadas estar em apenas 1 página não devem ter “conectores” para outros diagramas possuir um número e título utilizar cores ou sombras para distinguir diferentes

partes ou enfatizar.


6.4 - Suplemente a linguagem natural com outras descrições de requisitos

Benefício principal: Descrições de requisitos mais concisas e menos ambíguas.

Custo de introdução: Muito baixo Custo de aplicação: Baixo Tipo : Básica


6.4 - Suplemente a linguagem natural com outras descrições de requisitos

Alguns requisitos são melhores descritos utilizando-se notações especializadas como: fórmulas matemáticas; tabelas de decisão; notações de projeto; linguagens de programação


6.5 - Especifique quantitativamente os requisitos

Benefício principal: Não apresentar ambigüidade nos requisitos.

Custo de introdução: Baixo-moderado Custo de aplicação: Baixo-moderado Tipo : Intermediária


6.5 - Especifique quantitativamente os requisitos

Sempre que possível você deve especificar quantidades em valores para os requisitos do sistema.

Isto é mais aplicável para requisitos não funcionais.

Devemos ser capaz de especificar intervalos ou limites aceitáveis.


7 - Modelagem de Sistema Diretrizes relacionados ao desenvolvimento de

modelos sistemas abstratos que devem fazer parte da especificação detalhada do sistema.

Modelos essenciais deveriam sempre ser produzidos, incluindo um modelo do ambiente do sistema e em modelo da arquitetura do sistema.


7 - Modelagem de Sistema 7.1. Desenvolva modelos complementares do

sistema 7.2. Modele o ambiente do sistema 7.3. Modele a arquitetura do sistema 7.4. Use métodos estruturados para modelar

sistemas 7.5. Use um dicionário de dados 7.6. Documente os links entre os requisitos do

stakeholders e o sistema


7.1 - Desenvolva modelos complementares do sistema

Benefício principal: Revela erros e inconsistências na especificação.

Custo de introdução: Baixo-moderado Custo de aplicação: Moderado Tipo : Básica


7.1 - Desenvolva modelos complementares do sistema

Exibem diferentes aspectos da especificação do sistema.

Deve-se desenvolver no mínimo um modelo comportamental e um estrutural.

Exemplos de tipos de modelos. Outros sistemas que fazem ou farão interface. Outros sistemas que podem coexistir e interagir. Por

exemplo: correio eletrônico. Processos do negócio no qual o sistema é usado.


7.2 - Modele o Ambiente do Sistema

Benefício principal: Documentar os sistemas externos cujas interfaces devem ser especificadas.



7.2 - Modele o Ambiente do Sistema

Modelo ambiental - modelo do contexto no qual o sistema é usado.

Deveria incluir: Outros sistemas que fazem ou farão interface Outros sistemas que podem coexistir ou interagir. Por

exemplo: correio-eletrônico Processos do negócio no qual o sistema é usado


7.3 - Modele a Arquitetura do Sistema

Benefício principal: Ajuda a particionar os requisitos do sistema.

Custo de introdução: Baixo-moderado Custo de aplicação: Moderado Tipo : Básica


7.3 - Modele a Arquitetura do Sistema

Modelos arquiteturais são usualmente apresentados como simples diagramas de bloco exibindo os subsistemas principais e os relacionamento entre eles.

Exemplos de padrões arquiteturais: cliente-servidor camadas baseados em repositório pipeline


7.4 - Use métodos estruturados para modelar sistemas

Benefício principal: Modelos de sistemas são documentadas de forma padronizada.

Custo de introdução: Moderado-alto Custo de aplicação: Moderado Tipo : Intermediária


7.4 - Use métodos estruturados para modelar sistemas

Métodos estruturados - sistemáticas que aproximam análise e projeto.

Incluem notações, diretrizes e regras

para definir modelos de sistemas e o processo usado para desenvolver e validar estes modelos.


7.5 - Use um dicionário de dados Benefício principal: Evita duplicação de

nomes e desentendimentos. Custo de introdução: Moderado Custo de aplicação: Baixo Tipo : Intermediária


7.5 - Use um dicionário de dados Modelos de grandes sistemas são

geralmente desenvolvidas por várias pessoas que precisam inventar nomes para diferentes componentes.

O dicionário de dados facilita o processo e garante a consistência entre os requisitos, o projeto e o sistema implementado.


7.6 - Documente links entre os requisitos do stakeholder e o sistema.

Benefício principal: Torna-se mais fácil encontrar quais requisitos e modelos são afetados por mudanças.



7.6 - Documente links entre os requisitos do stakeholder e o sistema.

Devemos sempre documentar os relacionamentos entre a linguagem natural do requisito do stakeholder e o modelo mais detalhado de especificação do sistema.


8 - Validação de Requisitos Após o documento de requisitos ter sido

padronizado, os requisitos devem ser formalmente validados.

Está relacionado com a verificação de requisitos de omissão, conflitos e ambigüidades.

Garantir que os requisitos seguem um padrão de qualidade.


8 - Validação de Requisitos As diretrizes para a etapa de validação são:

8.1. Verifique se o documento de requisitos satisfaz seus padrões

8.2. Organize inspeções formais de requisitos 8.3. Use equipes multi-disciplinares para revisar

requisitos 8.4. Defina listas de validação


8 - Validação de Requisitos

8.5. Use protótipos para demonstrar requisitos 8.6. Escreva um esboço do manual do usuário 8.7. Proponha casos para testes de requisitos 8.8. Parafrasear modelos do sistema


8.1 - Verifique se o documento de requisitos satisfaz os padrões

Benefício principal: Descoberta rápida se não está de acordo com os padrões.



8.1 - Verifique se o documento de requisitos satisfaz os padrões

Antes de distribuir o documento de requisitos para a revisão geral, uma pessoa deveria executar uma validação rápida para garantir que a estrutura do documento e os requisitos definidos estão consistentes com o padrão definido.


8.2 - Organize inspeções formais de requisitos

Benefício principal: Encontra uma alta porcentagem de problemas de requisitos.

Custo de introdução: Moderado Custo de aplicação: Moderado Tipo : Básica


8.2 - Organize inspeções formais de requisitos

Um grupos de pessoas deve verificar os requisitos, discutir os problemas encontrados e como solucioná-los.

Exemplos de ações a serem tomadas Esclarecimento de requisitos Perdas de informação Conflito de requisitos Requisitos pouco realistas


8.3 - Use equipes multi-disciplinares para revisar requisitos

Benefício principal: Aumenta a probabilidade de encontrar problemas nos requisitos.



8.3 - Use equipes multi-disciplinares para revisar requisitos

Deveria incluir: usuário final ou representante, representante do cliente, especialista do domínio, engenheiro responsável pelo projeto e

implementação, engenheiro de requisitos.


8.4 - Defina listas de validação Benefício principal: Ajuda a focalizar o

processo de validação. Custo de introdução: Baixo a moderado Custo de aplicação: Baixo Tipo : Básica


8.4 - Defina listas de validação Devem identificar o que leitores deveriam procurar

quando estiverem validando os requisitos do sistema.

Lista de análise de requisitos requisitos individuais

Lista de validação propriedades de qualidade do documento como um todo relacionamentos entre requisitos individuais.


8.4 - Defina listas de validação Questões que podem ser incluídas:

Os requisitos são completos? Os requisitos são consistentes, incluem contradições? Os requisitos são compreensíveis? Os requisitos são ambíguos? O documento está estruturado? Existe uma alternativa

mais fácil de ser entendida? Requisitos incluem links para requisitos relacionados? O documento como um todo e os requisitos individuais

estão conforme o padrão?


8.5 - Use protótipos para demonstrar requisitos

Benefício principal: Demonstrar requisitos para validação.

Custo de introdução: Moderado-alto Custo de aplicação: Moderado-alto Tipo : Intermediária


8.5 - Use protótipos para demonstrar requisitos

Implementar um protótipo de um sistema o qual pode ser usado por experiência.

Stakeholders podem testar o sistema, verificar se estão de acordo com a necessidade, sugerir melhorias.


8.6 - Escreva o esboço do manual do usuário.

Benefício principal: Descobrir problemas de uso nos requisitos.



8.6 - Escreva o esboço do manual do usuário.

Escrever um esboço inicial do manual do usuário do sistema.

Isto deve cobrir todos os aspectos das funcionalidades do sistema.

Podemos fazer suposições sobre a interface do sistema.


8.7 - Proponha casos para testes de requisitos

Benefício principal: Revelar ambigüidades e inconsistências nos requisitos.



8.7 - Proponha casos para testes de requisitos

Para cada requisito propor um ou mais teste possíveis que pode ser usado para verificar se o sistema está de acordo com o requisito.


8.8 - Parafrasear modelos do sistema

Benefício principal: Permitir que mais stakeholders participem de validação de requisitos.

Custo de introdução: Moderado-alto Custo de aplicação: Moderado Tipo : Avançada


8.8 - Parafrasear modelos do sistema

Se você tem um modelo de sistema gráfico ou na notação formal, você deve sistematicamente converter a especificação descrita por modelo para a linguagem natural.

Stakeholders muitas vezes não têm tempo para aprender estas notações.


9 - Gerenciamento de Requisitos

Está relacionado com todos os processos envolvidos em mudanças de requisitos do sistema.



9.1. Identifique unicamente cada requisito 9.2. Defina políticas para gerenciamento de requisitos 9.3. Definir políticas de rastreamento 9.4. Mantenha um manual de rastreamento 9.5. Usar uma base de dados para gerenciar requisitos 9.6. Definir políticas de gerenciamento de mudanças



9.7. Identifique requisitos globais do sistema 9.8. Identifique requisitos voláteis 9.9. Registre requisitos rejeitados


9.1 - Identifique unicamente cada requisito

Benefício principal: Possibilita referências não-ambiguas a requisitos específicos.

Custo de introdução: Muito baixo Custo de aplicação: Muito baixo Tipo : Básica


9.1 - Identifique unicamente cada requisito

Deve-se atribuir um identificador único ou um número de referência que pode ser usado para se referir aquele requisito.


9.2 - Defina políticas para gerenciamento de requisitos

Benefício principal: Fornece um guia para todos os envolvidos no gerenciamento de requisitos.

Custo de introdução: Moderado Custo de aplicação: Baixo Tipo : Básica


9.2 - Defina políticas para gerenciamento de requisitos

Define objetivos para o gerenciamento de requisitos, os procedimentos que deveriam ser seguidos e os padrões que deveriam ser usados.

Políticas descrevem o que deveria ser feito e padrões como a política ser implementada em uma situação particular.


9.2 - Defina políticas para gerenciamento de requisitos Deveriam incluir:

Objetivos para o processo de gerenciamento de requisitos e motivo associado a cada objetivo.

Os relatórios que deveriam ser produzidos e as atividades esperadas para produzir tais relatórios.

Os padrões para documentos de requisitos e descrições de requisitos que deveriam ser utilizadas.

Gerenciamento de mudanças e políticas de controle para requisitos (diretriz 9.6)

Políticas de revisão e validação de requisitos. Relacionamentos entre gerenciamento de requisitos e outras atividades

de engenharia


9.3 - Defina políticas de rastreamento

Benefício principal: Informação de rastreamento consistente em todos os sistemas.

Custo de introdução: Moderado Custo de aplicação: Moderado-alto Tipo : Básica-intermediária



INFORMAÇÃO DE RASTREAMENTO é informação que permite encontrar dependências entre requisitos, e entre os requisitos e o projeto, componentes e documentação do sistemas.



Políticas de rastreamento deveriam definir Informação de rastreamento Técnicas básicas utilizadas para manter

informação de ratreamento Descrição de quando a informação de

rastreamento deve ser coletada, as pessoas responsáveis para mantê-las e um gerente.

Descrição de como gerenciar exceções.


9.3 - Defina políticas de rastreamento Tipos de informações de rastreamento

Fontes de requisito - liga o requisito a pessoas ou documentos que especificaram requisito

Razão do requisito - liga o requisito com o porquê de Ter sido especificado Requisitos de requisitos - liga requisitos com outros requisitos que eles dependem Requisitos de arquitetura - liga requisitos com os subsistemas onde estes

requisitos são implementados Requisitos de projeto - liga requisitos com componentes específicos que serão

utilizados para implementar o requisito. Pode ser componentes de hardware ou software. Importante para sistemas críticos.

Requisitos de interface - liga requisitos com as inte.rfaces de sistemas externos.



LISTAS DE RASTREAMENTO Para cada requisito, é mantido uma lista de

requisitos relacionados. Mais compacta. Difícil de verificar o relacionamento inverso.

Requisito Depende deR1 R2, R3R3 R1



Técnicas básicas utilizadas para manter informação de rastreamento:

TABELAS DE RASTREAMENTO Matriz de referência cruzada. Não indicado quando a quantidade de requisitos é muito

grande. Verifica a possibilidade de separar a matriz em grupos.


9.4 - Mantenha um manual de rastreamento

Benefício principal: Atua como um registro central de todas as informações de rastreamento especificado do projeto.

Custo de introdução: Baixo Custo de aplicação: Moderado-alto Tipo : Básica


9.4 - Mantenha um manual de rastreamento

Um manual de rastreamento é um complemento do documento de requisitos que inclui a política de rastreamento específica usada no

projeto e todas as informações de rastreamento de

requisitos. É usado pelos engenheiros de requisitos e

desenvolvedores de sistema


9.5 - Use uma base de dados para gerenciar requisitos

Benefício principal: Tornar mais fácil o gerenciamento de um número maior de requisitos.

Custo de introdução: Moderado-alto Custo de aplicação: Moderado Tipo : Intermediária


9.6 - Definir uma política para gerência de mudanças

Benefício principal: Fornecer uma estrutura para avaliação sistemática das mudanças propostas.

Custo de introdução: Moderado-alto Custo de aplicação: Baixo-moderado Tipo : Intermediária


9.6 - Definir uma política para gerência de mudanças

Devemos definir políticas para gerenciar mudanças dos requisitos as quais estabelecem como mudanças são formalmente propostas, analisadas e revisadas.

Mudanças aceitas são então implementada para criar uma versão do documento de requisitos


9.7 - Identifique requisitos globais do sistema

Benefício principal: Encontrar os requisitos que são provavelmente mais caros para mudar.

Custo de introdução: Baixo Custo de aplicação: Baixo Tipo : Intermediária


9.7 - Identifique requisitos globais do sistema

Requisitos globais de sistemas são requisitos definidos como convenientes ou propriedades essenciais para o sistema como um todo.

Estes requisitos devem ser explicitamente identificados e documentados como parte do processo de gerenciamento dos requisitos.


9.8 - Identifique requisitos voláteis

Benefício principal: Simplificar o gerenciamento das mudanças de requisitos.



9.9 - Registre requisitos rejeitados

Benefício principal: Evitar análise quando requisitos rejeitados são propostos novamente após o sistema estar em uso.



As 10 Diretrizes mais Importantes

Tão importantes que deveriam ser implementadas em todas as organizações:

3.1 - Defina uma estrutura de documento padrão 3.8 - Faça o documento fácil de alterar 9.1 - Identifique unicamente cada requisito 9.2 - Defina políticas para gerenciamento de

requisitos 6.1 - Defina templates padrões para definir requisitos


As 10 Diretrizes mais Importantes

6.2 - Use linguagem simples, consistente e concisa 8.2 - Organize inspeções formais de requisitos 8.4 - Defina listas de validação 5.2 - Use “checklists” para análise de requisitos 5.4 - Planeje-se para conflitos e resoluções de conflitos

Documents

1 Melhoria de Processo da Engenharia de Requisitos