Livro:Engenharia de Requisitos: Software Orientado ao Negócio

O orçamento já foi consumido como se 90% do trabalho estivesse concluído, quando ainda restam 50% a fazer.

O livro de Engenharia de Requisitos: Software Orientado ao Negócio.O negócio identifica uma necessidade, cuja solução passa por investir no desenvolvimento de software. Após um período de espera e de investimentos, priorizados em detrimento de outras iniciativas, o software é entregue. No entanto, não atende plenamente às necessidades de negócio

 

Fosse identificado cedo, menos mal; mais facilmente haveria tempo e recursos dentro do orçamento e prazo originais para corrigir os rumos. O maior problema é descobrir apenas quando de seu teste de aceitação ou mesmo em sua transição para produção. Esse atraso traz graves consequências para o projeto, que pode ser cancelado por não mais se justificar. Também, é uma das experiências mais frustrantes para os profissionais de TI envolvidos, para os usuários não atendidos e para os gestores afetados em diferentes esferas do negócio.

 

Estar próximo à metade do caminho quando acredita-se concluído: Projetos, que incluem o desenvolvimento dos requisitos como parte de seu escopo de atividades, apresentam esse fenômeno de forma mais comum do que se pode imaginar.  Poderia se pensar, em um primeiro momento, que Isso  é motivado  por uma mudança no escopo original

Tenta-se justificar atrasos por motivos de mudança no escopo, quando trata-se de falha na Engenharia de Requisitos. O escopo em termos específicos é produto, não um insumo que limite a Engenharia de Requisitos. O escopo que limita a Engenharia de Requisitos são áreas funcionais, processos em mais alto nível e partes interessadas chave que afetam ou são afetados pelo desenvolvimento

DADOS TÉCNICOS

 

Editora: Editora Brasport Livros Técnicos e Digitais
ISBN: 978-85-7452-790-1
Ano: 2016
Edição: 01
Número de páginas: 328 páginas


 

Requisito não é sinônimo de documentação ou burocracia. É resultado de se aprender a pensar; de desenvolver a capacidade investigativa e tomar para si o protagonismo na solução

 

Resenha

Este livro é direcionado tanto para estudantes com interesse em desenvolvimento de sistemas, quanto para profissionais envolvidos em projetos de software que desejam melhorar suas habilidades com requisitos. Buscamos escrever tanto para aqueles que atuam do lado cliente do projeto (gestores, analistas de negócio, gerente de sistemas) quanto do lado fornecedor (analistas de requisitos, analistas de sistemas, analistas de testes, gerente de projetos e desenvolvedores). Propõe-se a apresentar a importância da engenharia de requisitos, seus conceitos, atividades e diversas técnicas úteis, de forma que esse conhecimento possa ser aplicado a qualquer metodologia de desenvolvimento de software disponível no mercado.

 

Cada metodologia dita os momentos em que ocorre o trabalho de requisitos, a ordem das atividades, a relação com as outras disciplinas da engenharia de software, as técnicas a se empregar, os artefatos a serem produzidos. Acreditamos que este conteúdo seja útil para aqueles que trabalham tanto com metodologias ágeis, quanto as metodologias tradicionais. Tanto para um processo iterativo-incremental, quanto um processo sequencial (ou cascata). Tanto para projetos grandes quanto pequenos. Tanto para desenvolvimento de novos produtos de software, quanto para manutenção de softwares legados.

 

A publicação é fruto de experiência profissional dos autores e da pesquisa bibliográfica que teve como insumo principal o Corpo de Conhecimento da Análise de Negócio (BABOK) do Instituto Internacional de Análise de Negócio (IIBA). Identificamos a Análise de Negócios, como definido pela IIBA, como a ligação crucial do negócio para o desenvolvimento de software. Ela é mais abrangente que a Engenharia de Requisitos; possui objetivos mais amplos. Ao longo das diversas ações de consultoria e na condução de treinamentos, percebemos que a Análise de Negócio ser abordada em toda a sua extensão por um único perfil profissional é, ainda, uma visão de futuro. Por isso, sentimos a necessidade de aprofundar os tópicos da Análise de Negócio referentes à Engenharia de Requisitos, mas sem nunca perder de vista as interfaces e a manutenção de um vínculo de comunicação contínuo relacionando o projeto de software à motivação para o conjunto de mudanças no qual ele está inserido e às mudanças nesse domínio.

 

Foi um processo gradual e nele, fomos incorporando ao conteúdo desta obra a nossa experiência profissional em projetos de software; o feedback recebido nas diferentes ações de treinamento e consultoria; as práticas de gerenciamento de projetos usadas no SCRUM; o corpo de conhecimento de gerência de projetos (PMBoK) do PMI (Project Management Institute), o Processo Unificado da Rational da IBM (RUP), o guia prático do PMI para os práticos da Análise de Negócio, os modelos de maturidade para desenvolvimento e aquisição CMMI e MPS.BR; e também a visão de vários outros autores do tema, incluindo os livros de Karl Wiegers e Ian Sommerville.

 

Buscamos também cobrir toda a ementa da certificação CPRE-FL (Certified Professional for Requirements Engineering – Foundation Level), do IREB (International Requirements Engineering Board). Buscamos escrever esta obra de maneira que o leitor sinta-se confortável em lê-la tanto de maneira sequencial quanto por capítulos separado. Estruturamos o assunto de modo que a abordagem sequencial seja a mais didática possível para aqueles que estão tendo o primeiro contato com o tema. Tão importante quanto o conteúdo teórico são os exercícios e os estudos de casos propostos, onde o leitor terá a oportunidade de praticar e refletir de maneira crítica sobre os temas apresentados. Cada capítulo contém ao final um conjunto de exercícios sobre o tema apresentado.

  • Capítulo 1 – O que é Engenharia de Requisitos 

 

Apresenta o que é a Engenharia de Requisitos (ER), o porquê do termo “engenharia”, como a ER se contextualiza dentro da Engenharia de Software e como ela se insere em um processo de software. Esclarecemos a diferença entre disciplina e fase do projeto e como a ER se apresenta em projetos com estratégia sequencial e iterativo-incremental.

 

  • Capítulo 2 – O que é Requisito

 

Apresenta a definição de requisitos da IEEE, comentando a importância de cada parte da definição. Também define o que especificação de requisitos, seu objetivo, qual seu público alvo, qual o nível de detalhe adequado para uma especificação e critérios de qualidade para a mesma.

 

  • Capítulo 3 – A Importância da Engenharia de Requisitos 

 

Aborda as consequências de um trabalho mal feito de requisitos, os riscos para o projeto, quanto retrabalho isso pode ocasionar e o seu peso dentro da meta de qualidade em software.

 

  • Capítulo 4 – Principais Dificuldades com Requisitos

 

Relata as dores mais comuns de quem está envolvido com o trabalho de requisitos. Comentamos sobre dificuldades relatadas na literatura e também vivenciadas por diversos clientes nossos. Para cada dificuldade colocamos algumas propostas de técnicas ou abordagens que ajudam a enfrentá-la.

 

  • Capítulo 5 – Tipos de Requisitos, Restrições e Premissas

 

Apresentada a definição de premissas, restrições e a classificação dos requisitos em diferentes tipos, exemplificando e mostrando a importância de cada um destes conceitos para o desenvolvimento de software.

 

  • Capítulo 6 – As Atividades da Engenharia de Requisitos

 

Trata das macroatividades da ER, mas não apenas isso, mostra também como estudos anteriores ao projeto (ex.: análise de viabilidade) exercem um papel fundamental em facilitar ou dificultar o trabalho de requisitos.

 

  • Capítulo 7 – Elicitação de Requisitos

 

Explica o que é a elicitação de requisitos, seu objetivo, suas etapas, como ela se relaciona com as demais atividades da ER e também apresenta várias técnicas que podem ser empregadas nesta atividade.

 

  • Capítulo 8 – Análise de Requisitos

 

Explica o que é a análise de requisitos, seu objetivo, suas etapas. Aborda a especificação, importância da modelagem, organização dos requisitos e os pontos de vista funcional, estrutural e comportamental sobre os requisitos. E também a verificação e validação de requisitos como papel fundamental na garantia da qualidade do trabalho de requisitos.

 

  • Capítulo 9 – Gestão de Requisitos

 

Apresenta o que é a gestão de requisitos, seu objetivo, suas etapas, como ela se relaciona com as demais atividades da ER e também apresenta várias técnicas que podem ser empregadas nesta atividade.

 

Anexo I

 

Traz um glossário, que contém uma breve definição dos termos e siglas mais importantes usados na ER e também de todas as técnicas apresentadas no livro.

 

Anexo II 

 

Apresenta um estudo de caso, inspirado em um caso real, com várias das dificuldades comuns em especificações de requisitos. Estes casos são usados como prática de várias das técnicas apresentadas no livro.

 

Índice

Agradecimentos
Sobre o livro
Sobre os autores
Capítulo 1 - O que é Engenharia de Requisitos 
1.1 Definição de Engenharia de Requisitos
1.2 Por que usar "engenharia" em Engenharia de Requisitos?
1.3 Engenharia de Requisitos como parte da Engenharia de Software
1.4 Engenharia de Requisitos em diferentes estratégias de desenvolvimento
1.5 OCapítulo 1 – Engenharia de Requisitos
 ambiente da Engenharia de Requisitos
1.6 O papel do analista de requisitos
Exercícios
Capítulo 2 – Requisito
2.1 Uma palavra, muitos significados
2.1.1 Necessidade
2.1.2 Propriedade
2.1.3 Especificação
2.3 Definição de requisito
2.3.1 Resumo da definição
2.4 Especificação de Requisitos
2.4.1 Especificação de requisitos para quem?
2.5. Nível de Detalhe da especificação
2.5.1 Significado de nível de detalhe
2.5.2 Delimitar o escopo
2.5.3 Descrever um item no escopo
2.5.4 Mapear os requisitos no design ou implementação
2.5.5 Equívoco comum ao detalhar
2.6 Critérios para nível de detalhe da especificação
2.6.1 Desenvolvimento interno ou externo
2.6.2 Equipe dispersa ou agrupada geograficamente
2.6.3 Casos de testes baseados nos requisitos
2.6.4 Grau de incerteza das estimativas
2.6.5 Rastreabilidade dos requisitos
2.6.6 Envolvimento dos clientes
2.6.7 Conhecimento da equipe no domínio
2.6.8 Trabalho com características similares a anteriores
2.6.9 Desenvolvimento concorrente de procedimentos
2.6.10 Solução usará pacote
2.6.11 Expectativa de rotatividade de mão de obra
2.7 Critérios de qualidade da especificação
2.7.1 Correta
2.7.2 Completa
2.7.3 Clara
2.7.4 Consistente
2.7.5 Modificável
2.7.6 Priorizada
2.7.7 Verificável (ou testável)
2.7.8 Rastreável
2.7.9 Onde usar estes critérios de qualidade?
Exercícios
Capítulo 3 – A Importância da Engenharia de Requisitos
3.1 Motivação para a Engenharia de Requisitos
3.2 Impactos negativos da falha em requisitos
3.2.1 Sonda espacial Mars Climate Orbiter
3.2.2 Míssil antibalístico Patriot
3.2.3 Foguete Ariane 501
3.2.4 HAL 9000
3.2.5 Arquivo virtual do FBI
3.3 Uma tentativa de melhoria de processo
3.3.1 Principal motivação para o fracasso de projetos
3.3.2 Uma das principais causas de defeitos em software
3.3.3 Custo do reparo de defeitos
3.4 Especificações de requisitos como um ativo
3.5 Reflexão: onde a indústria de software investe energia
Exercícios
Capítulo 4 – Dificuldades Comuns com Requisitos
4.1 Comunicação
4.2 Acesso às partes interessadas
4.3 Indecisões/Indefinições do Usuário
4.4 Requisitos implícitos, mas não ditos
4.5 Mudanças
4.6 Conflitos
4.7 Resistência à mudança
4.8 Parte interessada não domina seu negócio
4.9 Parte interessada não lê a especificação de requisitos
4.10 Partes interessadas insaciáveis com requisitos
4.11 Consistência
4.12 Necessidades vagas
4.13 Priorização
4.14 Conclusão
Exercícios
Capítulo 5 – Tipos de Requisitos, Restrições e Premissas
5.1 Domínio do problema
5.1.1 Qual é a sua importância?
5.2 Requisitos (ou necessidades) de negócio
5.2.1 O que são?
5.2.2 Qual é a sua importância?
5.2.3 Critérios de qualidade
5.2.4 Quando são elaborados?
5.2.5 Papel do analista de requisitos
5.2.6 Onde ficam registrados?
5.3 Restrições e premissas
5.3.1 Restrições
5.3.2 Premissas
5.4 Partes interessadas
5.4.1 O caminho a partir dos requisitos de negócio
5.4.2 O que são?
5.4.3 Clientes e usuários x partes interessadas
5.4.4 Autoridade e responsabilidade
5.4.5 Qual é a sua importância?
5.5 Requisitos das partes interessadas
5.5.1 Onde ficam registrados?
5.6 Requisitos da solução
5.6.1 Qual é a sua importância?
5.6.2 Processo geral de desenvolvimento dos requisitos
5.7 Requisitos de transição
5.7.1 Qual é a sua importância?
5.7.2 Papel do analista de requisitos
5.8 Requisitos do projeto de software: solução + transição
5.8.1 Onde são armazenados?
5.9 Requisitos funcionais
5.9.1 Onde são armazenados?
5.9.2 Papel do analista de requisitos
5.9.3 Nível de granularidade
5.9.4 Requisitos funcionais com objetivo de usuário
5.9.5 Requisitos funcionais com objetivo agregador
5.9.6 Requisitos funcionais com objetivo de subfunção
5.10 Requisitos não funcionais
5.10.1 Diferença entre requisitos não funcionais e restrição técnica
5.10.2 Qual é a sua importância?
5.10.3 FURPS+
5.10.4 ISO/IEC 25010
5.10.5 Papel do analista de requisitos
5.11 Requisitos Inversos
5.11.1 Qual é a sua importância?
Exercícios
Capítulo 6 – Atividades da Engenharia de Requisitos
6.1 Um único tema, diferentes pontos de vista
6.2 1º marco: definição da necessidade
6.2.1 Atividades da Engenharia de Requisitos
6.3 2º marco: consenso sobre o escopo
6.4 3º marco: detalhamento dos requisitos
6.4.1 Técnica: sentença de problema ou visão
6.4.2 Modelagem de escopo (modelagem ambiental)
6.4.3 Técnica: diagrama de contexto
6.4.4 Técnica: diagrama de casos de uso
6.4.5 Técnica: modelo de processo de negócio
6.5 Como saber com quem conversar
Exercícios
Capítulo 7 – Elicitação de Requisitos
7.1 Definindo a elicitação de requisitos
7.2 Atividades da elicitação
7.2.1 Preparação para elicitação
7.2.2 Execução da elicitação
7.2.3 Documentação dos resultados da elicitação
7.2.4 Confirmação dos resultados da elicitação
7.3 Técnica: análise de documentos
7.3.1 O que é a análise de documentos
7.3.2 Como realizar a análise de documentos
7.4 Técnica: glossário
7.4.1 Introdução
7.4.2 O que é o glossário
7.4.3 Onde encontrar
7.4.4 Quando começar
7.4.5 Como elaborar um glossário
7.4.6 Importância como produto
7.4.7 Importância como processo
7.4.8 Conclusão
7.5 Técnica: observação (etnografia)
7.5.1 O que é observação
7.5.2 Como realizar a observação
7.5.3 Vantagens
7.5.4 Desvantagens
7.5.5 Conclusão
7.6 Técnica: entrevista
7.6.1 O que é a entrevista
7.6.2 A primeira impressão é a que fica
7.6.3 Diretrizes para o entrevistador
7.6.4 Como realizar a entrevista
7.6.6 Finalização
7.6.7 Conclusão
7.7 Técnica: pesquisa/questionário
7.7.1 O que é a pesquisa/questionário
7.7.2 Como realizar a pesquisa
7.7.3 Vantagens
7.7.4 Desvantagens
7.7.5 Conclusão
Exercícios
Capítulo 8 – Análise de Requisitos
8.1 Um problema: A descoberta tardia de que ainda falta muito
8.2 Visão geral da análise de requisitos
8.2.1 O que é análise de requisitos?
8.2.2 Por que análise de requisitos?
8.2.3 Como realizar a análise de requisitos?
8.3 Organizar a partir do exame, decomposição e síntese
8.3.1 Exame para identificar ou descrever tarefas
8.3.2 Decomposição da informação
8.3.3 Síntese da informação
8.4 Modelar e usar modelos para refinar a informação
8.4.1 O que é modelagem?
8.4.2 Por que modelagem?
8.4.3 Como realizar a modelagem?
8.5 Especificar para documentar os requisitos
8.5.1 O que é especificação?
8.5.2 Por que especificação?
8.5.3 Quando elaborar uma especificação?
8.5.4 Como elaborar uma especificação?
8.6 Verificação de requisitos
8.6.1 O que é verificação?
8.6.2 Quem realiza a verificação?
8.6.3 Por que verificação?
8.6.4 Quando realizar a verificação?
8.6.5 Como realizar a verificação?
8.7 Validação de requisitos
8.7.1 Técnicas úteis à validação
8.8 Técnica: Histórias do usuário
8.8.1 Por que histórias de usuário?
8.8.2 Como elaborar uma história do usuário?
8.9 Técnica: modelagem de processos
8.9.1 O que é um processo?
8.9.1 O que é modelagem de processo?
8.9.2 Diagrama, mapa e modelo de processos
8.9.3 Por que modelagem de processos?
8.9.4 Como realizar a modelagem de processos?
8.10 Técnica: decomposição funcional
8.10.1 Como aplicar a decomposição funcional?
8.10.2 Por que aplicar a decomposição funcional?
8.11 Técnica: modelagem de domínio
8.11.1 Como realizar a modelagem de domínio?
8.11.2 Conceito de negócio
8.11.3 Checklist para organizar o modelo de domínio
8.11.4 Relacionamentos entre conceitos
8.11.5 Representações para o modelo de domínio
8.11.6 Por que realizar modelagem de domínio?
8.12 Técnica: modelagem de casos de uso
8.12.1 O que é um caso de uso?
8.12.2 Diagrama de casos de uso
8.12.3 Especificação de caso de uso
8.12.3 Por que casos de uso?
8.13 Técnica: listas de verificação
8.13.1 O que são listas de verificação?
8.13.2 Porque listas de verificação?
8.14 Técnica: prototipação
8.14.1 O que é prototipação?
8.14.2 Como aplicar a prototipação?
8.14.3 Por que prototipação?
Exercícios
Capítulo 9 – Gerência de Requisitos
9.1 Gerência de requisitos no CMMI-DEV
9.1.1 Ciclo de vida da gerência de requisitos
9.2 Plano de gerenciamento de requisitos
9.2.1 Quem é responsável pela gerência de requisitos?
9.3 Gestão das mudanças
9.4 Obter aprovação sobre os requisitos
9.4.1 Como apresentar os requisitos para aprovação?
9.5 Técnica: controle de questões
9.5.1 O que é o controle de questões
9.5.2 Elementos do controle de questões
9.6 Rastreabilidade de requisitos
9.6.1 O que é a rastreabilidade de requisitos
9.6.2 Benefícios da rastreabilidade
9.6.3 Tipos de rastreabilidade
9.6.4 Matriz de rastreabilidade
9.7 Priorizar requisitos
9.7.1 Técnica: timeboxing/budgeting
9.7.2 Técnica: votação
9.7.3 Técnica: análise moscow
9.7.1 Diretrizes para a priorização Moscow
9.8 Gerência de requisitos depende de ferramenta?
Exercícios
Bibliografia
Glossário
Anexo A – Estudo Preliminar SRRO – Sistema de Registro de Responsabilidade de Obras
A.1Objetivo
A.2 Justificativa
A.3 Prazo de entrega
A.4 Valor contratado
A.5 Responsáveis pelo projeto
A.6 Objeto
A.7 Quantidade estimada de pontos de função
A.8 Recebimento
Anexo I - Documento de Visão
1) Contextualização
2) Requisitos
3) Cronograma das atividades de projeto
4) Da divulgação e treinamento
5) Da análise de custos
  

Sobre os Autores

Os dois autores são sócio sêniores da FATTO Consultoria e Sistemas na qual atuam como consultores e instrutores.

 

Carlos Eduardo Vazquez (carlos.vazquez@fattocs.com) é um profissional versátil com mais de 25 anos de experiência em desenvolvimento, manutenção e gestão de sistemas corporativos. Consultor em governança e gestão de TI com ênfase no alinhamento da TI aos objetivos estratégicos de negócio. Especializado em métricas, requisitos e analytics, que aplica desde a concepção de uma visão até a efetiva operacionalização. Graduado tecnólogo em processamento de dados pela PUC Rio em 1990, desde 1991 atua em consultoria, mentoringcoaching e conduz treinamentos corporativos.  Em1996, foi um dos primeiros brasileiros a obter a Certificação de Especialista em Pontos de Função – CFPS – concedida pelo  IFPUG, instituição da qual é associado corporativo com direito a voto, tendo em 2010, participado no esforço de tradução para o português da última versão (4.3.1) de seu Manual de Práticas de Contagem. Está também entre os primeiros certificados no método COSMIC e é certificado como Engenheiro de Requisitos pelo IREB. Foi professor na UFES e fundou a FATTO com o objetivo melhorar as práticas de software nacional a partir das interfaces entre cliente e fornecedor de soluções de TI, internos e externos. Escreveu o livro "Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software", livro atualmente em sua 13ª edição e o mais vendido sobre o assunto. Desenvolveu o conteúdo de vários dos cursos presenciais e à distância da FATTO. Formou uma equipe de especialistas no assunto e é responsável pela organização e qualidade dos serviços por eles prestados. Perfil no Linkedin disponível em http://br.linkedin.com/in/cvazquezbr.

 

 

Guilherme Siqueira Simões (guilherme.simoes@fattocs.com) é graduado em Ciência da Computação pela UFES – Universidade Federal do Espírito Santo, pós-graduado em Gestão Empresarial também pela UFES, especialista em pontos de função (CFPS) certificado pelo IFPUG, gerente de projetos (PMP - Project Management Professional) certificado pelo PMI - Project Management Institute e engenheiro de requisitos (CPRE-FL – Certified Professional for Requirements Engineering – Foundation Level) pelo IREB - International Requirements Engineering Board. Tem mais de 20 anos de experiência em desenvolvimento de sistemas e é, atualmente, sócio sênior da FATTO Consultoria e Sistemas, onde atua como consultor e instrutor em serviços e cursos de medição, estimativas e requisitos de projetos de software. Atuou no desenvolvimento de toda a linha de serviços da FATTO e treinou centenas de profissionais da América Latina em requisitos e pontos de função. Participou da equipe de tradução para o português das versões 4.2 e 4.3 do Manual de Práticas de Contagem, do IFPUG. É ainda autor do livro Análise de Pontos de Função – Medição, Estimativas e Gerenciamento de Projetos de Software. Perfil no Linkedin disponível em  http://www.linkedin.com/in/guilhermesimoes

 

FALE COM OS AUTORES

 

Clique aqui para falar com os autores. Ou se inscreva no grupo de discussão do livro: https://br.groups.yahoo.com/neo/groups/engenharia-requisitos/info.

 

Palestras

 

No intuito de intensificar a disseminação da Engenharia de Requisitos como instrumento de melhoria nas relações entre clientes e provedores do desenvolvimento de sistemas, os autores colocam-se à disposição dos setores acadêmicos, governamentais e corporativos para ministrar palestras de difusão da Engenharia de Requisitos (um hora de duração abordando uma visão geral do tema e seus benefícios).

 

Qualquer organização interessada pode solicitar a palestra (gratuita) através do Fale Conosco, informando local e período desejado.

 

Buscaremos combinar uma data que concilie também com as agendas dos autores.

 

Eventuais despesas de viagem deverão ser arcadas pelo solicitante.

 

 

Participe do Grupo de Leitores

Participe do grupo de leitores do livro para a discussão de dúvidas, acesso ao histórico de dúvidas já respondidas, críticas ao conteúdo, sugestão de melhorias e divulgação de erratas. Oportunidade de interação direta com os autores. Você pode cadastrar-se diretamente na página do grupo: https://br.groups.yahoo.com/neo/groups/engenharia-requisitos ou enviar um e-mail para engenharia-requisitos-subscribe@yahoogrupos.com.br.

 

 

 

.

 

.