Análise e Gestão de Requisitos D

 

Análise e Gestão de Requisitos de Software Onde Nascem os Sistemas

 

1

Análise e Gestão de Requisitos de Software Onde Nascem os Sistemas

 

2

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 

3

Felipe Nery Rodrigues Machado

Análise e Gestão de Requisitos de Software Onde Nascem os Sistemas

2ª Edição Revisada

www.editoraerica.com.br 

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

4

Dados Internacionais de Catalogação na Publicação (CIP) (Câmara Brasileira do Livro, SP, Brasil) Machado, Felipe Nery Rodrigues  Análise e gestão de requisitos de software: onde nascem os sistemas/Felipe Nery Nery Rodrigues Machado. -2. ed. rev. -- São Paulo: Paulo: Érica, 2014. Bibliografi a. ISBN 978-85-365-0969-3 1. Administração Administração de projetos 2. Análise Análise de sistemas 3. Sistemas - Projetos Projetos - Metodologia 4. Software - Desenvolvimento I. Título. 14-01046

CDD-004.21

Índices para catálogo sistemático: 1. Projeto de software: Desenvolvimento de sistemas: Análise e gestão: Ciência da computação 2. Software: Desenvolvimento: Projetos: Análise e gestão: Ciência da computação

004.21 004.21

Copyright © 2011  2011 da Editora Érica Ltda. Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem prévia autorização da Editora Érica. A violação dos direitos autorais é crime estabelecido na Lei no 9.610/98 e punido pelo Artigo 184 do Código Penal.

Coordenação Editorial: Capa:  Avaliação Técnica: Técnica: Ilustração:

Rosana Arruda da Silva Maurício S. de França Adilson da Silva Lima Flavio R. Pereira

Editoração e Finalização:

Daniela Veronica Lima Carla de Oliveira Morais Marlene Teresa Teresa S. Alves Rosana Ap. A. dos Santos  Adriana Santoro Dalete R. de Oliveira Lívia Vilela de Lima

O Autor e a Editora acreditam que todas as informações aqui apresentadas estão corretas e podem ser utilizadas para qualquer fim legal. Entretanto, não existe qualquer garantia, explícita ou implícita, de que o uso de tais informações conduzirá sempre ao resultado desejado. Os nomes de sites e empresas, porventura mencionados, foram utilizados apenas para ilustrar os exemplos, não tendo vínculo nenhum com o livro, não garantindo a sua existência nem divulgação. Eventuais erratas estarão disponíveis para download no site da Editora Érica. Conteúdo adaptado ao Novo Acordo Ortográfico da Língua Portuguesa, em execução desde 1 o de janeiro de 2009.  A Ilustração Ilustração de de capa e algumas algumas imagens imagens de de miolo foram foram retiradas retiradas de , empresa empresa com a qual qual se mantém mantém contrato contrato ativo na data de publicação do livro. Outras foram obtidas da Coleção MasterClips/MasterPhotos© da IMSI, 100 Rowland Way, 3rd floor Novato, CA 94945, USA, e do CorelDRAW X5 e X6, Corel Gallery e Corel Corporation Samples. Copyright© 2013 Editora Érica, Corel Corporation e seus licenciadores. Todos os direitos reservados. T odos os esforços foramnão feitos creditar devidamente os detentores dos direitos daspróximas imagensedições, utilizadasbastando neste livro. omissões de crédito e copyright sãopara intencionais e serão devidamente solucionadas nas queEventuais seus proprietários contatem os editores.

Seu cadastro é muito importante i mportante para nós  Ao preencher e remeter a ficha ficha de cadastro constante no no site da Editora Érica, você passará passará a receber informações sobre sobre nossos lançamentos em sua área de preferência. Conhecendo melhor os leitores e suas preferências, vamos produzir títulos que atendam suas necessidades.

Contato com o editorial: [email protected] 

Editora Érica Ltda. | Uma Empresa do Grupo Saraiva Rua São Gil, 159 - Tatuapé CEP: 03401-030 - São Paulo - SP Fone: (11) 2295-3066 - Fax: (11) 2097-4060 www.editoraerica.com.br 

 

5

Dedicatória À minha esposa Maria Cristina P. Vaz Machado, companheira de todas as horas, que dedica tanta atenção às minhas realizações e é a maior incentivadora. A Minha Motivação de todos os dias é você. Com todo o meu amor,

Felipe Nery Machado

Vigiai sempre e orai para escapardes a tudo que há de vir e comparecerdes diante do filho do homem.  Lucas - 21

 

6

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 Agradecimentos À Caroline Carbonell Cintra, mais que colaboradora, uma artífice de ideias, sem a qual não seria possível esta realização. A Eduardo Meira Peres pela honra de prefaciar este livro, e avaliá-lo com seu vasto conhecimento do assunto. À minha adorável esposa Cristina, por me assumir na vida, cobrindo responsabilidades minhas, e assim permitindo que me dedicasse à construção deste livro. li vro.

 

7

Motivação Fazer um bom levantamento e uma especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento pode não garantir que o software contemple todas as reais necessidades dos usuários, mas tende a antecipar o surgimento dos erros de entendimento e inconsistências, aprimorando o processo de desenvolvimento de produtos de software. A qualidade do processo de análise é importante, porque um erro de concepção resolvido na fase de análise tem um custo, na fase de projeto tem custo maior, na fase de implementação maior ainda, e na fase de implantação do sistema tem um custo relativamente astronômico. A ausência de materiais e de literatura nacional, baseada nas nossas situações reais, com uma amplitude que atinja os estudantes e profissionais da área de análise de sistemas, foi a motivação de elaborar um livro que trouxesse nossas experiências, coletasse o conhecimento espalhado pelas universidades do País e agrupasse um material de referência não só acadêmico, mas também profissional. Foram cinco anos de pesquisa, leitura de livros li vros diversos de autores conceituados e também de TCCs de alunos de universidades brasileiras, de aulas de professores, que buscamos juntar em uma única fonte de informação, disponível a todos interessados. Esperamos contribuir de forma efetiva na formação de profissionais mais qualificados, mais satisfeitos e conscientes de que projetar sistemas é simples; basta paciência, observação e dedicação. Análise de requisitos envolve 10% de esforço físico e 90% de inspiração e observação do que existe. Nesta 2ª edição 2ª edição revisada, o autor mostra como a utilização de métodos ágeis pode utilizada conceitos de de etimologia, não se limitandoser à ideia de terconcomitantemente somente um usuárioaos confiável, além levar os trabalhos de análise para o ambiente do usuário. Nesta edição, também foi acrescentado um apêndice de exercícios práticos para que você vá a campo realizar a aplicação das técnicas e métodos apresentados em um pequeno projeto de sistemas. O autor

"Habilidade é o que você é capaz de fazer.  Motivação determina o que você faz.  Atitude determina a qualidade do que você faz." faz." Lou Holtz

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

8

Sobre o Autor Felipe Nery Rodrigues Machado, consultor com mais de trinta anos de vivência na área de desenvolvimento de sistemas atuando como analista de sistemas e de negócios. Com formação em Engenharia Mecânica, possui vasta experiência no

projetodededesenvolvimento, sistemas para banco de dadoseeimplementação profundos conhecimentos logias modelagem de processosem demetodonegócio financeiro, industrial e em logística, entre outras verticais de negócio, com utilização de sistemas automatizados, processos, frameworks e modelagem de dados. Especialista em projetos de bancos de dados para aplicações transacionais e gerenciais, com vasta experiência no desenvolvimento de projetos de bancos de dados para as mais diversas áreas de negócio, tais como indústria metalúrgica, indústria de alimentos, varejo e atacado, jornais e televisão, distribuição de produtos, logística, concessionárias de automóveis, órgãos públicos diversos, hospitais e companhias aéreas. Sua experiência abrange o ciclo completo de negócios de uma organização, tendo já desenvolvido igualmente aplicações com arquitetura de Data Warehouse, processos de ETL, com grande ênfase em modelagem multidimensional e arquitetura de processos OLAP. Foi professor universitário de disciplinas de Bancos de Dados e Metodologias de Desenvolvimento, e pós-graduação em Gerência de Projetos de Sistemas no Rio de Janeiro, dedica-se à pesquisa e divulgação das técnicas e metodologias do estado da arte em desenvolvimento de aplicações. Autor dos livros Tecnologia e Projeto de Data Warehouse, Banco de Dados: Projeto e Implementação e Projeto de Banco de Dados - Uma Visão Prática, todos publicados pela Editora Érica e adotados nas principais universidades de informática do País. Colaboradora: Caroline Carbonell Cintra

Profissional com mais de dez anos de carreira em TI, com um sólido background técnico em todo o ciclo de vida de desenvolvimento de software. Também possui extenso conhecimento em metodologia de processos, modelos e frameworks, atuante em projetos de construção e modelagem de processos de software para certificação CMMI. É mestre em Ciência da Computação e IBM Certified Specialist - Rational Unified Process. Apresentou a proposta de um processo de engenharia de requisitos com base no ProcessodeUnificado Rational (RUP), alcançando nível 3incluindo de maturidade da integração modelos da de capacidade e maturidade (CMMI), a utilização de práticas de métodos ágeis para a obtenção do grau de mestre em Ciência de Computação, e que serviu de base inicial nas pesquisas para a construção deste livro.

 

9

Sumário Capítulo 1 - Introdução ................................................................................................19 Mas o que é um Requisito? ................. ................................... .................................... .................................... .................................... .......................24 .....24 Requisitoo ...................................................................................................................... Requisit ........................................................................................................................... ..... 28 Capítulo 2 - Requisitos - Conceituação .................................. ..................................................................... ................................... 29 Desenvolvimento de Software ................. ................................... .................................... .................................... ...................................29 .................29 Processo e Modelo de Processo Processo ................................................................................... ....................................................................................... 29 Metodologia ......................................................................................................................30 Metodologia  ...................................................................................................................... 30 Terminologia  ................................................................. Terminologia .................................................................................................................... ................................................... 30 Stakeholder ...........................................................................................................30 ........................................................................................................... 30 Cliente................................... ...................................................................... ..................................................................... .............................................. ............31 31 Elicitar................................... ...................................................................... ..................................................................... .............................................. ............31 31 Cenário ..................................................................................................................31 .................................................................................................................. 31 Disciplina .............................................................................................................. Disciplina  ..............................................................................................................31 31 Artefato .................................................................................................................31 ................................................................................................................. 31 O que são Requisitos ................. ................................... ..................................... ..................................... .................................... ................................ ..............32 32 Necessidades, Características e Requisitos de Software  Software ................ .................................. ............................. ...........33 33 Requisitos Requisit os Funcion Funcionais ais .............................................................. ..................................................................................................... ....................................... 34 Requisitos Requisit os de Informa Informação ção ............................................................................................... ............................................................................................... 34 Requisitos Requisit os Não Funcion Funcionais ais ............................................................................................. ............................................................................................. 34 Requisitos de Processos de Negócios .................. .................................... .................................... .................................... ....................... .....36 36 Processos .............................................................. ........................................................................................................................... ............................................................. 36 Missão do Processo.............................. ................................................................. ................................................................ .............................37 37 Eventos ..................................................................................................................37 .................................................................................................................. 37 Softwares “Fast Food” .................. .................................... ..................................... ..................................... .................................... ............................. ...........38 38 Resumo: 10 Grandes Armadilhas da Análise de Requisitos  Requisitos  .................. .................................... ....................41 ..41 Exercícios ................ .................................. .................................... .................................... ..................................... ..................................... ...................................42 .................42 Capítulo 3 - Modelos de Capacidade e Maturidade (CMMI) ............................... 43 Introdução ................. ................................... .................................... ..................................... ..................................... .................................... ................................ ..............43 43 Definição Defi nição e Objet Objetivos ivos ...................................................................................................... 43 Modelos de Processo Integrados  Integrados ................................................................................... ................................................................................... 44 Objetivos ...............................................................................................................44 Representaçõe Represe ntaçõess e Corpos de Conhe Conhecimento cimento............................................................ ................................................................ .... 44 Representação Contínua .....................................................................................44 Representação por Estágios  Estágios............................................................................................46  ............................................................................................ 46 Aplicação em Organizações  Organizações ............................................................... ........................................................................................... ............................ 49 Conceitos Utilizados ............................................................................................49 Utilizados ............................................................................................49 Áreas de Processo ...................................................................... ............................................................................................................ ...................................... 51 CMMI em Estágios e os Níveis de Maturidade ................ .................................. .................................... ..........................52 ........52

Nível de Maturidade 1: Inicial  ....................................................................................... ........................................................... ............................ 53 2: Inicial  Gerenciado Gerenciado.............................................................................. .............................................................................. Nível de Maturidade 3: Definido  Definido ................................................................. .................................................................................. ................. 53 Nível de Maturidade 4: Gerenciado Quantitativamente  Quantitativamente ........................................... 53 Nível de Maturidade 5: Em Otimização  Otimização ....................................................................... ....................................................................... 54

 

10

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Níveis de Maturidade do CMMI ................................ .................................................. .................................... ..................................54 ................54 Nível de Maturidade 2: Gerenciado................................................................. Gerenciado.............................................................................. ............. 54 Áreas de Processo ................................................................................................55 Meta Genérica - (GG2) Institucionalizar um Processo Gerenciado Gerenciado  ..............56 ............. 56 Nível de Maturidade 3: Definido  Definido .................................................................... .................................................................................. .............. 57 Áreas de Processo ................................................................................................57 ................................................................................................ 57 Meta Genérica - (GG3) Institucionalizar um Processo Gerenciado  Gerenciado. ......................... 60 Exercícios ................. ................................... .................................... .................................... .................................... ..................................... ................................... ................60 60 Capítulo 4 - O Processo Unificado da Rational (RUP) .............................. ........................................... .............61 61 Práticas do RUP  RUP ............................................................... ............................................................................................................... ................................................ 63 Desenvolver Software Iterativamente  Iterativamente ............................................................. .......................................................................... ............. 64 Gerenciar os Requisitos  Requisitos .............................................................. .................................................................................................. .................................... 65 Usar Arquiteturas Baseadas em Componentes  Componentes ............................................... .................................. .............66 66 Modelar Software Visualmente ......................................................................... Visualmente .........................................................................66 66 Verificar a Qualidade do Software Continuamente Continuamente .......................................  .......................................67 67 Controlar as Mudanças no Software  Software ................................................................. .................................. ...............................67 67 Características do RUP.................................................................................................... RUP....................................................................................................67 67

Estrutura do RUP  RUP .................................................................. ................................ ................................................................. ...............................69 69 Aspectos Estáticos ................................................................. Aspectos Dinâmicos  Dinâmicos ..................................................................... ........................................................................................................ ................................... 71 Customização do RUP  RUP ................................................................. .................................................................................................... ................................... 73 Exercícios ................. ................................... .................................... .................................... .................................... ..................................... ................................... ................74 74 Capítulo 5 - Métodos Ágeis .........................................................................................75 O Manifesto pelo Desenvolvimento Ágil de Software ................. ................................... ............................... .............76 76 Extreme Programming (XP).................................................................. (XP) ........................................................................................... ......................... 78 Valores de XP  XP ................................................................... ................................................................................................................... ................................................ 78 Princípios de XP............................................................... XP ............................................................................................................... ................................................ 79 Práticas de XP .......................................................................................................81 XP .......................................................................................................81 Atividades de XP ................................................................................................. XP .................................................................................................83 83 Resumo do Método XP  XP  .......................................................................................84 Modelagem Ágil  Ágil .............................................................. .............................................................................................................. ................................................ 85 Valores da Modelagem Ágil...............................................................................85 Ágil...............................................................................85 Princípios da Modelagem Ágil .......................................................................... Ágil ..........................................................................86 86 Práticas da Modelagem Ágil .............................................................................. Ágil ..............................................................................87 87 Resumo da Modelagem Ágil  Ágil..............................................................................90  ..............................................................................90 Integração de Metodologias de Desenvolvimento de Software  Software.................................92  .................................92 RUP & CMMI  CMMI .................................................................... ................................................................................................................... ............................................... 92 RUP & Métodos Ágeis  Ágeis ................................................................. .................................................................................................... ................................... 95 CMMI e Métodos Ágeis............................................................... Ágeis .................................................................................................. ................................... 96 Exercícios ................. ................................... .................................... .................................... .................................... ..................................... ...................................99 ................99 Capítulo 6 - Engenharia de Requisitos ...................................................................101 Elicitação de Requisitos .................... ....................................... ..................................... .................................... .................................... .......................102 .....102 Análise e Negociação de Requisitos  Requisitos ................................................................ ........................................................................... ........... 104

 

11

Documentação de Requisitos  Requisitos ....................................................................................... ....................................................................................... 104 Validação de Requis Requisitos itos........................................................... ................................................................................................ ..................................... 105 Gerência de Requisitos  Requisitos .................................................................................................. .................................................................................................. 105 Gerência de Escopo  Escopo .................................................................. ....................................................................................................... ..................................... 106 Gerência de Mudanças............................................................. Mudanças .................................................................................................. .....................................106 106 Problemas Problem as Clássicos e Soluçõe Soluçõess Adotad Adotadas as................................................................. 107 Constantes Solicitações Mudança ................................... .............................................................. ...........................107 107 Falta de Consenso Entrede Stakeholders ............................................................ ................................. ...........................107 107 Pouco Conhecimento do Domínio do Problema  Problema ........................................... ................................. ..........108 108 Pouca Qualidade da Documentação e Comunicação  Comunicação ................................... ............................... ....108 108 Engenharia de Requisitos no CMMI ................ .................................. .................................... .................................... ........................109 ......109 Área de Processo: Gerência de Requisitos  Requisitos ............................................................... ................................................................... 109 Níveis de Requisitos RUP e CMMI .................................................................109 CMMI .................................................................109 Meta: Gerenciar Requisitos  Requisitos  ..............................................................................110 Área de Processo: Desenvolvimento de Requisitos  Requisitos ...................................... .................................. ....111 111 Meta: Desenvolver Requisitos do Cliente ......................................................112 Cliente ......................................................112 Meta: Desenvolver Requisitos do Produto ....................................................112 Produto ....................................................112 Meta: Analisar e Validar Requisitos  Requisitos ................................................................ ................................ ................................113 113 A Engenharia de oRequisitos no RUP  RUP  ............................................................ .......................................................................... .............. Fluxo de Trabalh Trabalho de Requi Requisitos sitos ................................................................................. ................................................................... .............. 114 115 Analisarr o Problem Analisa Problemaa ........................................................................................ ...................................................................................................... .............. 116 Objetivos .............................................................................................................116 ............................................................................................................. 116 Atividades Envolvidas .............................. ................................................................. ........................................................ .....................117 117 Compreender as Necessidades dos Stakeholders............................... ......................................... ..........118 118 Atividades Envolvidas ......................................................................................118 Definir o Sistema  Sistema ............................................................................................................ ............................................................................................................ 119 Objetivos .............................................................................................................119 Atividades Envolvidas ......................................................................................120 Gerenciar o Escopo do Sistema  Sistema .................................................................................... .................................................................................... 120 Objetivos .............................................................................................................120 Atividades Envolvidas ......................................................................................121 Refinar a Definição do Sistema  Sistema .................................................................................... .................................................................................... 122 Objetivos .............................................................................................................122 Atividades Envolvidas ......................................................................................122 Gerenciar Requisições de Mudança  Mudança ............................................................................ ............................................................................ 123 Objetivos .............................................................................................................123 ............................................................................................................. 123 Atividades Envolvidas .............................. ................................................................. ........................................................ .....................123 123 Distribuição das Atividades por Fase de Desenvolvimento .......................124 Desenvolvimento .......................124 Métodos Ágeis e a Engenharia de Requisitos  Requisitos ........................................................... 124 1. Cartões .............................................................................................................125 2. Conversação ...................................................................................................125 3. Confirmação  Confirmação  ...................................................................................................125 Exercícios ................ .................................. .................................... .................................... ..................................... ..................................... ................................. ...............126 126 Capítulo 7 - Técnicas para Análise de Requisitos ................................................127 Processo de Levantamento e Análise de Requisitos ................. ................................... ................................. ...............127 127

 

12

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Técnicas de Levantamento de Requisitos .................. .................................... .................................... ................................129 ..............129 Levantamen Levan tamento to Orientado a Pontos de Vista .............................................................. .............................................................. 129 Conceitos-Chave ................................................................................................130 ................................................................................................ 130 Hierarquias de Pontos de Vista .......................................................................131 ....................................................................... 131 Estudo Etnográfico  Etnográfico ..................................................................... ........................................................................................................ ................................... 132 Os Dados Etnográficos são Informais  Informais ............................................................. ................................ .............................135 135 Vantagens  Vantagens  ............................................................................................................ ............................................................................................................ Desvantagens  Desvantagens   .....................................................................................................139 ..................................................................................................... 139 139 Investigação ........................................................................................................140 Investigação  ........................................................................................................140 Análise de Documentos Quantitativos  Quantitativos ........................................................... ............................... ............................140 140 Workshops  ...................................................................................................................... Workshops ...................................................................................................................... 142 Prototipagem................................................................... Prototipagem .................................................................................................................. ............................................... 143 Entrevistas Entrevi stas ............................................................. ...................................................................................................................... ......................................................... 143 O Planejamento ..................................................................................................145 Tipos de Questões ..............................................................................................145 Questões ..............................................................................................145 Problemas na Elaboração de Questões  Questões ....................................................................... ....................................................................... 146 Registro da Entrevista  Entrevista ................................................................................................... ................................................................................................... 147 Recomendações Gerais  Gerais ................................................................ ................................................................................................. ................................. 148 Relatório Relató rio da Entrevista.................................................................................................. Entrevista............................. ..................................................................... Questionários Questionários   ................................................................... ................................................................................................................. .............................................. 149 Brainstorming  ................................................................................................................. Brainstorming ................................................................................................................. 150  JAD  ...................................................................................................................................  JAD ................................................................................................................................... 151 Síntese ..................................................................................................................153 .................................................................................................................. 153 Enfoque e Recomendação ...................................... ........................................................ .................................... .................................... ....................154 ..154 Exercícios ................. ................................... .................................... .................................... .................................... ..................................... .................................154 ..............154 Capítulo 8 - Requisitos e Modelo de Negócios .....................................................155 O Problema ................ .................................. .................................... .................................... .................................... ..................................... ..............................155 ...........155 Método de Mac Knight para Elicitação de Requisitos de Software a Partir do Modelo de Negócio .................. .................................... ..................................... ..................................... .................................... ................................ ..............163 163 Objetivo Objet ivo ................................................................. ........................................................................................................................... .......................................................... 165 Detalhamento do Método........................................................... Método ............................................................................................. ..................................166 166 Fase 1: Visão Geral do Problema ..................................................................... Problema .....................................................................166 166 Etapa 1: Identificar o Contexto da Solicitação Solicitação ...............................................  ...............................................166 166 Etapa 2: Identificar Necessidades dos Processos .......................................... Processos ..........................................166 166 Etapa 3: Identificar os Impactos das Necessidades  Necessidades ....................................... .................................. .....167 167 Fase 2: Visão Geral da Solução ........................................................................ Solução ........................................................................167 167 Etapa 4: Identificar as Funcionalidades e Restrições do Sistema  Sistema ................168 ............... 168 Etapa 5: Identificar as Fronteiras do Sistema Si stema  ................................................. ................................. ................168 168 Conclusão sobre Abordagem de Processos de Negócios na Elicitação de Requisitos de Software ................ .................................. .................................... .................................... ..................................... ........................ .....168 168 Capítulo 9 - Gestão do Conhecimento e Requisitos .................................. ............................................. ...........171 171

O Conceito dedoGestão do Conhecimento .................................... .................. ................................. .............. 1175 171 71 Classificação Conhecimento em Análise e Gestão..................................... de Requisitos.................. Requisitos ....................... .....175 A Utilização de Repositórios de Conhecimento em Projetos  Projetos  .................................. 177 Conclusão................................. .................................................................... ...................................................................... ........................................ .....178 178 Exercícios ................. ................................... .................................... .................................... .................................... ..................................... ................................. ..............178 178

 

13

Capítulo 10 - Especificação de Requisitos com Casos de Uso ............................ 179 Introdução ................. ................................... .................................... ..................................... ..................................... .................................... .............................. ............179 179 Casos de Uso ................. ................................... .................................... .................................... .................................... .................................... ...........................180 .........180 Diagramas de Casos de Uso  Uso ......................................................................................... ......................................................................................... 182 Notação Básica da UML para Modelos de Caso de Uso Uso ..............................  ..............................183 183 Descrição de Casos de Uso  Uso ........................................................................................... ........................................................................................... 185 Cenários...............................................................................................................185 Cenário de Eventos Principal............................... ................................................................. ............................................ ..........187 187 Cenários Alternativos........................................................................................187 Alternativos........................................................................................ 187 Associações entre Casos de Uso  Uso .......................................................... .................................................................................. ........................ 188 Cenário ou Curso Normal ................................................................................189 Cenários ou Cursos Alternativos.....................................................................189 Cenário ou Curso Normal ................................................................................190 Cenários ou Cursos Alternativos.....................................................................190 Casos de Uso Agrupados em Pacotes  Pacotes ............................................................. ................................... ..........................193 193 Notações para Casos de Uso em UML  UML ........................................................... ....................................................................... ............ 195 Detalhar Precondições e Pós-Condições ........................................................ Pós-Condições ........................................................196 196 Regras de Negócio ............................................................................................. Negócio .............................................................................................196 196 Orientação Sobre a Especificação de Casos de Uso de Relatórios .............. Relatórios ..............197 197 Lembretes e Dicas para Detalhar um Caso de Uso  Uso ....................................... .............................. .........198 198 Modelo de Casos de Uso  Uso ..................................................................... .............................................................................................. ......................... 199 Integração Modelo x Interface  Interface ........................................................... ..................................................................................... .......................... 200 Identifique as Fontes de Informação  Informação ............................................................... .............................. .................................203 203 Exercícios ................ .................................. .................................... .................................... ..................................... ..................................... .................................204 ...............204 Capítulo 11 - O que é SCRUM? ................................................................................205 Conceitos ................ .................................. .................................... .................................... ..................................... ..................................... .................................205 ...............205 Os Papéis no SCRUM ................. ................................... .................................... .................................... .................................... .............................. ............207 207 O que São Sprints ....................... ......................................... ..................................... ..................................... .................................... ..............................208 ............208 Product Backlog  Backlog ............................................................................................................. ............................................................................................................. 210 User Story  ........................................................... ....................................................................................................................... ............................................................ 210 O Story  Dilema das User Stories ................................................................................210 Stories ................................................................................210 Qual o Tamanho da User Story?  Story? .................................................................. ............................... ....................................... ....212 212 SCRUM Funciona ................. ................................... .................................... ..................................... ..................................... ....................................214 ..................214 Sprint Planning  Planning ............................................................ .............................................................................................................. .................................................. 216 Documentação em SCRUM  SCRUM .......................................................................................... .......................................................................................... 218 Documentação não Substitui Comunicação ..................................................219 Comunicação ..................................................219 Documentação não pode ser Perecível ...........................................................219 Perecível ...........................................................219 Documente o Necessário, e não mais do que Isso Isso ........................................220  ........................................220 Documentar tem de ser Fácil  Fácil  ...........................................................................220 Documentação faz Parte do “Definition of Done”  Done”  ........................................ ............................... .........220 220 Documentação no Código pode ser um “Code Smell”  Smell” ................................220 ................................ 220

Dicas Smells Casos de de Cod Uso Smells ..........................................................................................221 x User ..........................................................................................221 Stories .............................................................................222 Stories .............................................................................222

 

14

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Capítulo 12 - Problemas Comuns aos a os Projetos............................... ...................................................... .......................223 223 Introdução .................. .................................... .................................... .................................... .................................... ..................................... .............................. ...........223 223 Armadilhas dos Requisitos e Boas Práticas.................. .................................... .................................... .............................224 ...........224 Boas Práticas ................. ................................... ..................................... ..................................... .................................... .................................... .......................... ........227 227 Check List ................ .................................. .................................... .................................... .................................... ..................................... ................................. ..............227 227

Capturar Requisitos não Funcionais ............................ .............................................. ..................................... ..............................228 ...........228 Capítulo 13 - Um Processo com Requisitos............................... ............................................................ ............................. 229 Metodologia de Concepção do Processo Proposto  Proposto ................. ................................... ...................................229 .................229 Contextualiza Conte xtualização ção do Processo ..................................................................................... ..................................................................................... 229 Objetivos Objet ivos e Caracte Características rísticas Fundam Fundamentais entais ................................................................. ................................................................. 230 Evoluçãoo do Processo................................................................... Evoluçã .................................................................................................... ................................. 231 Elementos Básicos ................. ................................... ..................................... ..................................... .................................... ................................... .................232 232 Papéis.......................................................... Papéi s............................................................................................................................... ..................................................................... 232 Artefatos Artefat os................................................................. .......................................................................................................................... ......................................................... 233 Atividades Ativida des Recorren Recorrentes tes................................................................................................. ................................................................................................. 236 Gerenciar Requisitos  Requisitos ................................................................... ..................................................................................................... .................................. 236 Objetivos, Papéis e Artefatos ...........................................................................236 ........................................................................... 236 Manter Atributos dos Requisitos ................................... ..................................................................... .................................. 237 Manter Rastreabilidade................................. .................................................................... .................................................... .................239 239 Priorizar Requisitos ...........................................................................................241 Assegurar uma Visão Comum.............................................................. Comum..................................................................................... ....................... 241 Objetivos, Papéis e Artefatos ...........................................................................241 Realizar Análise de Requisitos em Grupos  Grupos .................................................... ................................... .................243 243 Revisar Artefatos................................................................................................244 Obter Aprovações ..............................................................................................244 Manter Glossário ................................................................................................245 Glossário ................................................................................................245 Definir o Escopo do Sistema .................. ..................................... ..................................... .................................... ................................... .................246 246 Compreender Compr eender os Requisit Requisitos os do Cliente........................................................... ...................................................................... ........... 247 Objetivos, Papéis e Artefatos ...........................................................................247 ........................................................................... 247 Identificar os Fornecedores de Requisitos......................................................248 Requisitos......................................................248 Entender o Problema .........................................................................................249 Definir os Limites do Sistema ..........................................................................250 Sistema ..........................................................................250 Documento de Visão - Perspectiva do Produto ............................................251 Produto ............................................251 Identificar as Necessidades e Restrições dos Stakeholders Stakeholders .........................252  .........................252 Definir as Características do Sistema  Sistema .............................................................. ................................. .............................253 253 Compreender Compr eender os Requisitos do Produto .................................................................... 254 Objetivos, Papéis e Artefatos ...........................................................................254 Identificar Requisitos Funcionais e Não Funcionais.....................................254 Funcionais.....................................254 Documentar Requisitos de Software  Software ............................................................... .................................. .............................255 255 Índice do Modelo de Documento ERS  ERS ............................................................ ................................ ............................256 256 Gerenciar Requisitos  Requisitos ................................................................... ..................................................................................................... .................................. 256 Assegurar Visão Comumo .....................................................................................257 Comum..................................................................................... Resumoo douma Resum Fluxo de Trabalh Trabalho ..................................................................................... .............................................................. ....................... 257 257 Refinar Requisitos de Software ................ .................................. .................................... ..................................... .................................258 ..............258 Especificar Requisitos de Software  Software ................................................................. ............................................................................. ............ 259

 

15

Objetivos, Papéis e Artefatos ...........................................................................259 Detalhar Requisitos de Software ..................................................................... Software .....................................................................260 260 Refinar Modelos de Análise ............................................................................. Análise .............................................................................261 261 Atualizar Artefatos Sobre Requisitos................................... .............................................................. ...........................262 262 Modelar Interface........................................................................................................... Interface...........................................................................................................262 262 Objetivos, Papéis e Artefatos ...........................................................................262 ........................................................................... 262 Analisar o Domínio  Domínio .................................................................. ....................................................................................................... ..................................... 262 Objetivos, Papéis e Artefatos ...........................................................................262 ........................................................................... 262 Gerenciar Requisitos  Requisitos ................................................................ ..................................................................................................... ..................................... 263 Assegurar uma Visão Comum..................................................................................... Comum.....................................................................................263 263 Resumo do Fluxo de Trabalh Trabalhoo ........................................................... ..................................................................................... .......................... 263 Gerenciar Mudanças .................. .................................... ..................................... ..................................... .................................... .............................. ............264 264 Submeter Subme ter Solicitaçã Solicitaçãoo de Mudan Mudança ça .............................................................................. .............................................................................. 266 Objetivos, Papéis e Artefatos ...........................................................................266 ........................................................................... 266 Complementa Comple mentarr Solicitaçã Solicitaçãoo de Mudan Mudança................................ ça..................................................................... ..................................... 268 Objetivos, Papéis e Artefatos ...........................................................................268 ........................................................................... 268 Complementar a Descrição da Mudança ....................................................... Mudança .......................................................268 268 Analisar o Impacto da Mudança .............................. ................................................................. ....................................... ....269 269 Analisa Analisar r Solicitaçã Solicitação o dee Mudan Mudança ça ................................................................................ ....................................................... ......................... 270 270 Objetivos, Papéis Artefatos ........................................................................... ...........................................................................270 Resumo do Fluxo de Trabalho .................................. ..................................................................... ....................................... ....271 271 Orientações sobre Práticas Ágeis .................. ..................................... ..................................... .................................... ........................... .........271 271 Análise das Possibilidades de Utilização  Utilização ................................................................... ................................................................... 271 Propostas de Inserção de Práticas Ágeis no Processo Proposto ............................. Proposto ............................. 273 Apêndice - Exercício Prático Geral ..........................................................................275 Bibliografia.................................... Bibliografia.................. .................................... ..................................... ..................................... .................................... ...........................279 .........279 Índice Remissivo ................. ................................... .................................... ..................................... ..................................... ....................................285 ..................285

 

16

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 

17

Prefácio A importância dos requisitos no resultado final de um projeto de software é fortemente reconhecida, teorizada e debatida nas áreas de gerenciamento de projetos e engenharia de software. Sabemos que para garantir a qualidade de um software, é essencial que seus requisitos sejam compreendidos. Em outras palavras, como o autor deste livro nos alerta, se não compreendermos os requisitos adequadamente, serão grandes as chances de o software resultante não atingir o resultado esperado. Por muito tempo a questão principal nessa área foi a definição de técnicas e padrões para a documentação de requisitos, como se eles estivessem disponíveis, apenas aguardando um redator de requisitos. Hoje percebe-se que tão importante, e eu diria mais importante, quanto o processo de documentação de requisitos é o processo de compreensão ou descoberta dos requisitos, o qual exige uma habilidade muito grande dos envolvidos para a identificação do real problema a ser resolvido com o desenvolvimento de um software. Esta ideia também está expressa no conceito moderno de qualidade de software, que afirma que a qualidade não é resultante apenas da conformidade do produto com os requisitos especificados, mas, acima de tudo, do atendimento das necessidades e expectativas dos clientes ou usuários. Por isso é importante termos clareza de que não são condições suficientes para o sucesso de um projeto que os requisitos sejam documentados usando técnicas rigorosas, nem que os requisitos sejam tratados como contratos formais com assinaturas dos usuários nem tampouco que fique comprovado que o software resultante contempla exatamente tudo o que está documentado. Nada disso será relevante se as expectativas não tiverem sido identificadas e compreendidas. Muitas vezes, ao não compreender a relevância do gerenciamento das expectativas, equipes tecnicamente bem preparadas acabam por construir ótimas soluções... pena que para problemas inexistentes. A concepção deste livro está e stá fundamentada na experiência prática do autor, o que justifica a utilização de uma linguagem despojada de rigor formal para apresentação dos temas. Por isso o leitor não precisa assustar-se com os capítulos iniciais sobre os conceitos de engenharia e gestão de requisitos, CMMI, RUP e métodos ágeis. Estes conceitos estão apresentados de forma suave e não extensiva, apenas no limite da necessidade para o desenvolvimento subsequente do tema, de forma fluente, nos capítulos seguintes. A receita do autor para cativar o leitor utiliza comoporções ingredientes iniciais os conceitos básicos de requisitos, acrescenta pouco a pouco na medida certa de introdução a processos e técnicas, recheia com muitas dicas, frutos de sua própria experiência, e dá um toque final com a exemplificação e xemplificação de um processo no qual

 

18

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

estão integrados de forma consistente todos os elementos utilizados. Felipe Nery mostrou-se um chef de requisitos. E é desta forma que o livro colabora no preenchimento de uma lacuna importante no ensino de conceitos, métodos e técnicas de gerenciamento e engenharia de requisitos de software, lacuna esta decorrente da escassa literatura disponível em língua portuguesa e danos carência formação, em especial cursosdededisciplinas graduação.com foco nesse tema nos cursos de Por seu caráter abrangente, o livro pode ser utilizado como apoio em disciplinas de cursos de graduação e lido l ido por analistas de sistemas iniciantes. Os conceitos apresentados com certeza auxiliam os profissionais na realização de suas tarefas com qualidade. Um bom exemplo são as técnicas para planejamento, realização e avaliação de entrevistas propostas. Não são poucas as vezes em que vi analistas de sistemas realizarem entrevistas com os fornecedores de requisitos sem nenhuma preparação prévia, seja quanto aos objetivos a serem alcançados, seja quanto às questões a serem formuladas. Muitas vezes as entrevistas mais parecem um bate-papo despretensioso, uma conversa de bar. E a situação pode ser pior, quando o registro conversa é feito mentalmente pelo entrevistador, pois ele não leva nem materialda para registrar anotações. Também os analistas de negócio e de sistemas experientes vão encontrar no livro boas referências e práticas para melhoria de seu trabalho, o qual propicia a eles a percepção de um quadro geral e atualizado sobre o tema. Não pense que a ausência de um viés acadêmico resulta em uma obra restrita. O autor consegue, com boa desenvoltura, lidar com temas complexos, como a integração de perspectivas supostamente antagônicas de modelos formais como o CMMI com as abordagens ágeis de desenvolvimento. Neste contexto, é importante o destaque dado no livro ao ciclo de vida dos requisitos nas abordagens ágeis de desenvolvimento. Finalmente, cabe um alerta aos leitores: a proposta deste livro não é apresentar uma receita de bolo a ser aplicada em seus projetos para obtenção de sucesso rápido e seguro, muito menos que todas as questões abordadas venham as ser incorporadas indiscriminadamente às suas metodologias de desenvolvimento. Como o próprio autor destaca, não existe bala de prata. O que vocês vão encontrar neste livro é uma visão abrangente do assunto requisitos de software, com maior ou menor profundidade em alguns temas específicos. A partir do contexto de cada organização, de suas reais necessidades, será possível a identificação de pontos a serem explorados ou aprofundados em outras referências bibliográficas, muitas delas citadas pelo próprio autor. Para quem ficou com água na boca para devorar este livro, bom apetite! Eu recomendo.  MSc Eduardo Eduardo Meira Peres

Professor da Faculdade de Informática/PUCRS

 

1

 

Introdução

“As tecnologias de informação e de negócios estão se tornando, inevitavelmente, inevitavelmente, uma coisa só. Não creio que alguém possa falar sobre um sem falar sobre o outro.” (Bill Gates)

Nos últimos anos a evolução das técnicas para processos de desenvolvimento desenvolvimento de software é uma constante na busca da construção de sistemas mais confiáveis, dentro de prazos razoáveis, e com qualidade que satisfaça as necessidades necessidades do cliente final. Esse mesmo cliente também evolui cada dia mais, em termos de conhecimentos conheci mentos de Tecnologia da Informação, e seu nível de exigência, para que os sistemas efetivamente suportem suas atividades operacionais, de negócios e estratégicas. Estes fatores fazem com que cada dia a análise de requisitos funcionais e operacionais de um projeto de sistemas torne-se fator vital ao sucesso e satisfação final desta realização. Entretanto, temos visto o advento das certificações CMMI, PMI, ETIL, entre outras e os sistemas desenvolvidos continuam a mesma coisa: falhos, fora de prazo, fora de custos. As siglas continuam a proliferar, mas o resultado continua o mesmo: sistemas sistemas falhos, analistas considerados fracos, formação universitária deficiente. É sabido que as universidades se esforçam para manter currículos atualizados atualizados e dentro do estado da arte, porém os processos burocráticos governamentais que regem currículos programáticos continuam dando pouco apoio efetivo, deixando dei xando lacunas que os professores e as universidades buscam suprir por sua conta e com pouco apoio. Pouco se ensina sobre negócios e técnicas de análise e levantamento de requisitos para a formação em cursos de ciência da computação, engenharia da computação, em função do tempo de aulas e das dificuldades em trazer experiências experiências diversas para dentro da sala de aula. Somente ensinam-se linguagens, técnicas estruturadas ainda dependentes de conceitos americanos não aplicáveis à nossa cultura empresarial. e mpresarial.

 

20

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Nada se ensina sobre “processos de negócios”, e como se aplicam sistemas automatizados a esses processos. Temos então uma massa de “pseudoanalistas de sistemas” que não entendem enten dem nada de negócios, não possuem ferramentas e aprendem poucas técnicas de como obter esse conhecimento. Sabem criar por exemplo, casos de uso, user stories, mas com um único objetivo: determinar como serão realizadas programações em linguagens para atender “aquele requisito”, sem ideia clara do que ele significa em termos de negócios, em função da distância do mundo real onde acontecem os fatos. Iniciativa, formas de obter o conhecimento de um negócio, técnicas para levantamentos de requisitos, técnicas de abstração e análise de negócios, conhecimentos de processos de negócios são muito difíceis de ensinar à imensa quantidade de mão de obra de Tecnologia da Informação nas universidades, em parte pela escassez de material de estudo e pesquisa.  O que serão dos “analistas de sistemas ou de informação” que ouvem, mas não têm fonte de informação e formas de ver a realidade dos serviços de análise de sistemas na prática? Pobres alunos, sonhadores em realizar alguma coisa benfeita, e que limitados limita dos à burocracia de documentação dos processos de desenvolvimento aderentes ao CMMI (todos os níveis), às técnicas de métodos ágeis como SCRUM, entre outros, continuam a criar sistemas que não atendem às exigências operacionais das organizações, não por sua culpa, mas pelas pressões da indústria, que não permite permi te espaço para observação e aprendizado prático. Que alguém demonstre um sistema que hoje funcione de forma satisfatória, sem falhas associadas ao gerenciamento e à análise de requisitos, porque não existe. Sofremos diariamente com esse paradigma. A formação universitária em maior volume nos dias atuais, assim como a especialização em atividades segmentadas do processo de desenvolvimento, traz como consequência uma dificuldade para o entendimento das reais necessidades à construção de sistemas que funcionem corretamente. A chamada visão sistêmica é pouco desenvolvida em comparação com a forte formação em linguagens, componentes, arquiteturas e tecnologias. É evidente que temos de apoiar com mais ênfase, didática e publicações a formação de analistas de negócios em cursos de ciência da computação ou da engenharia de software, passando nossas experiências em análise e gestão de requisitos, em áreas de administração, produção e comércio, entre e ntre outras, pois os formandos conhecem muito de tecnologia e necessitam aplicá-la a requisitos deprofissionais. negócios, para enfrentarem um mercado de trabalho disputado e carente de bons Coloca-se a questão: como resolver este problema e conseguir entender requisitos de negócio para projetar um sistema?

 

21

Introdução

Esta dificuldade traz como consequência direta problemas na especificação e modelagem de um sistema. Embora a preocupação com a engenharia de software seja evidente na literatura, com inúmeros estudos relacionados a processos de desenvolvimento, o panorama dos projetos de software continua enfrentando sérios problemas na busca pelo desenvolvimento bem-sucedido ainda nos dias de hoje. Há muito estamos assistindo palestras, apresentações sobre desenvolvimento desenvolvimento de software, apregoando a adoção de processos de desenvolvimento, sobre a organização desses processos, e nelas apresentam-se dados, sempre de grandes fontes (Gartner etc.) de acordo com os quais “de 80 a 90% do software não atinge seus objetivos de performance, 80% dos sistemas são entregues atrasados e fora do prazo, cerca de 40% do desenvolvimento falha ou é abandonado, menos de 25% dos sistemas é integrado  propriamente ao negócio, e apenas de 10 a 20% atinge seus critérios de sucesso”.

A partir destes dados apresentam-se processos organizados de desenvolvimento desenvolvimento de software, com cuja importância de existência e utilização concordamos, concor damos, porém gostaríamos de salientar outros aspectos neste livro, além da existência exis tência de um processo.

Figura 1.1: Desempenho do desenvolvimento de sistemas de 1994 a 2004. Fonte: Chaos Report 2004

Os números apresentados na Figura 1.1 não mudaram muito, mesmo com a evolução dos processos processos de desenvolvimento de software no Brasil, que é o que nos interessa. Nada leva a acreditar, vendo e observando os sistemas implementados nos últimos três anos, digamos assim, que esses números da figura tenham se modificado sensivelmente. Observe que em 2004 passou a ser de 29% o valor relativo a projetos com sucesso. Mas veja bem, pois são dados dos EUA, não nossos. Logo, imagine o que esperar se houvesse uma pesquisa exclusiva do Brasil. Que resultados resultados teríamos!

 

22

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Continuamos, infelizmente, com tristes números de baixo sucesso, com raras exceções. O Chaos Report 2009, um relatório famoso sempre apresentado em palestras palestras de gerenciamento de projetos e metodologias (relatório anual do desempenho dos projetos de desenvolvimento de software feito pelo Standish Group), que mostra taxas de sucessos e de falhas dos projetos, indica que pouca coisa mudou (mesmo no contexto global) nos números referentes ao sucesso de projetos, pois eles não evoluíram significativamente.

Figura 1.2: Desempenho do desenvolvimento de sistemas. Fonte: Chaos Report 2009

Como podemos observar nos dados, tivemos: 32% sucesso (no prazo, dentro do orçamento e com escopo completo)   44% mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo)  24% falharam (cancelados ou nunca usados) Segundo o relatório, nós estamos piores do que estávamos em 2004. A correção de um erro identificado durante a fase de especificação de requisitos tenderia a custar entre 50 a 200 vezes mais se identificado somente nas etapas posteriores do desenvolvimento. Para atingir os objetivos de um projeto, todas as atividades de desenvolvimento devem ser criteriosamente elaboradas e trabalhadas, seja usando uma abordagem mais rica em documentação, como o UP (Unified Process) ou as excelentes metodologias ágeis (XP, SCRUM etc.), além dos padrões de certificação como CMMI e MPS-BR.

 

Introdução

23

Assim sendo, em qualquer uma delas encontraremos com maior ou menor rigor e formalização atividades de análise e engenharia de requisitos, design, definição de arquitetura, codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja, identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deve resolver é a base de um projeto de software de sucesso. Muita ênfase é dada pelos profissionais de T.I. às atividades de pro jetoo e cod  jet codific ificaçã ação. o. Isso se deve em boa parte parte à for formaç mação ão ofereci oferecida da aos profissionais de T.I. pelas universidades (infelizmente), que focam as grades curriculares principal principalmente mente em disciplinas técnicas e científicas. Hoje, percebemos que o processo de compreensão ou descoberta dos requisitos é tão importante quanto o processo de documentação de requisitos, ou ainda mais, pois exige maior habilidade e envolvimento operacional dos analistas e interessados na aplicação (stakeholders) para a identificação do real problema a ser resolvido por meio do desenvolvimento de um software, principalmente no que se refere à análise dos processos de negócio e a sua compreensão e domínio. Além desse enfoque na análise e na elicitação de requisitos, estudando as técnicas e entendendo a relação entre os requisitos e o modelo de negócios, apresentamos neste livro as técnicas para análise de requisitos (Capítulo 7), com os conceitos dos estudos etnográficos, que consistem em uma análise de componente social das tarefas desempenhadas em dada organização e, com forte foco em processos de negócios, apresentamos o método de Mac Knight (Capítulo 8) para elicitação de requisitos de software com base em um Modelo de Negócios. Tem muito a ver também com o perfil pessoal e cultural dos profissionais que atuam na área em geral, formada eminentemente por técnicos, bastante interessados em bits e diretamente bytes e pouco assuntos administrativos, dedo, professores oriundos deafeitos bancosa universitários (graduação, além mestra mestrado, doutorado) sem vivência real e prática no mundo dos negócios. Toda metodologia de desenvolvimento de software  ou processo de desenvolvimento de software propõe uma série de fases e atividades dentro do seu ciclo de vida e o encadeamento entre elas. Independentemente do nome dado a cada fase, é extremamente recomendável recomendável que o processo contemple ao menos dois grandes grupos de atividades referentes a requisitos, que poderíamos chamar de:    ngenharia de requisitos: são todas as atividades realizadas para identificar, E Engenharia analisar, especificar e definir as necessidades de Requisitos negócio que deve prover para solução do problema levantado. Requi sitos queum nãoaplicativo refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes, mudanças em requisitos que já foram previamente acordados e a dificuldade para

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

24

chegar a um acordo entre profissionais de T.I. e usuários são os maiores problemas enfrentados no grupo de atividades de especificação de requisitos.   Gestão de requisitos: preocupa-se com a documentação, versionamento, Gestão versionamento, controle de mudanças e qualidade dos requisitos levantados na fase de especificação de requisitos. Todo requisito apresenta um ciclo de vida único que acompanha a dinâmica dos negócios associados. Assim sendo, não se pode esperar que um requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o requisito se desprende é dinâmico. dinâ mico. Além disso, formou-se a percepção de que os processos de desenvolvimento desenvolvimento de software precisam submeter-se a mudanças e refinamentos contínuos para que aumentem sua capacidade de lidar com requisitos e expectativas de todos os stakeholders. Essas mudanças e refinamentos são feitos através da avaliação e melhoria de processos. Veja bem que novamente se fala em processo, porém em processo de desenvolvimento e não em PROCESSO DE NEGÓCIO. Há pouco investimento no ponto principal, que é a capacidade de abstração abstração e compreensão básica de conceitos de negócios fundamentais ao entendimento entendimento desses requisitos. Somente com utilização de novos e melhores processos não é ainda possível atingir um grau de qualidade q ualidade de detalhamento de requisitos que garanta sucesso total a um projeto de desenvolvimento de sistemas. No contexto das abordagens de desenvolvimento de software, uma das áreas de estudo que tem se destacado é a engenharia de requisitos. Os requisitos são o ponto de partida para toda a definição de um sistema e, consequentemente, são fatores decisivos no desenvolvimento do produto final de um projeto de software. Apresentamos as técnicas de engenharia de requisitos com conhecimento de negócios e entendimento de processos, valorizando detalhes do processo de negócio, inclusive por meio de situações básicas, como uma planilha eletrônica utilizada pelos interessados no sistema - a qual todo analista deveria conhecer -, o que facilita o trabalho de identificar e especificar requisitos de negócios.

Mas o que é um Requisito? Os requisitos expressam as características e restrições do produto de software  do de vista de satisfaçãona das necessidades do usuário e, em geral, independemponto da tecnologia empregada construção da solução, sendo a parte mais crítica e propensa a erros no desenvolvimento de software.

 

25

Introdução

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software. Umnecessária conjunto de definido condição capacidade querequisitos o softwarepode  deve ser possuir paracomo que ouma usuário possaou resolver um problema ou atingir um objetivo ou para atender as necessidades ou restrições restrições da organização ou dos outros componentes do sistema. Infelizmente esta é uma definição clássica, mas muito genérica e impalpável, impalpável, ou seja, diz muito e não diz nada. Então, antes de seguir, vejamos uma simples visão. Um software é baseado na seguinte premissa apresentada graficamente a seguir:

Figura 1.3

Então, tudo que possa compor as caixinhas do desenho, na realidade, compõe com põe um software:   O que entra, como dados, informações, eventos, seja o que for, é um requisito.   O processamento em si a ser realizado tem regras, fórmulas, normas, critérios, arquivos, tabelas etc. para que seja executado. A saída desse processamento também é composta de dados e informações, informações, ou   de disparo de eventos, ou outra coisa qualquer. Olhando assim, vemos que há uma infinidade de objetos envolvidos que são requisitos de software, os quais devem ser classificados em dois grandes grupos: os requisitos FUNCIONAIS e os NÃO FUNCIONAIS. Os requisitos FUNCIONAIS são os que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem de ser feito pelo sistema, assim como o que deve sair do sistema Os requisitos NÃO FUNCIONAIS são aqueles que expressam como deve ser feito (não confundir requisitos não funcionais com design). Em geral se relacionam relacionam com padrões de qualidade como confiabilidade, performance, robustez etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa a que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado.

 

26

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Neles também são apresentadas restrições e especificações de uso para os requisitos funcionais. O objetivo do livro especificamente são os requisitos funcionais, que consideramos o calcanhar de aquiles em projetos de software. Um exemplo prático para definir requisito funcional é utilizar a seguinte frase: O sistema deve...    Depois você coloca um verbo e o complemento, como, por exemplo, ............. realizar o cadastramento de funcionários. Mas atenção pois a partir deste ponto devemos mudar, ou melhor, acres acrescentar centar uma nova forma de ver o objetivo para o qual vamos construir um sistema. sis tema.   O processo de negócio consiste em: Informações cujo significado é ..........     O tratamento dessas informações é realizado da seguinte forma ........ Grave bem este detalhe, pois vamos utilizar essa consideração no decorrer deste livro e nos casos práticos.   A análise de requisitos tem por objetivo tratar do processo dos requisitos de software  e sua aderência e atendimento dos requisitos de PROCESSOS DE NEGÓCIOS. Todas as atividades precisam ser criteriosamente elaboradas el aboradas e desenvolvidas. desenvolvidas. É essencial que a equipe compreenda exatamente o que é o NEGÓCIO, como ele funciona, quais suas informações, o que se espera do aplicativo a ser construído e também o que o não é esperado e sperado nem desejado.

Figura 1.4

Isso pode parecer óbvio, mas existe o fator de desconhecimento do negócio do cliente, que faz com que nem sempre fique claro para todos os envolvidos do pro jeto qual será o alcance da aplicação. aplicação.

 

27

Introdução

Este é o objetivo primordial deste livro, uma coletânea de situações e pro processos cessos de negócios e de análise de requisitos, que se baseia nessas situações e processos, com a aplicação das técnicas para identificação i dentificação de requisitos de forma objetiva e concreta. Busca auxiliar a formação desses profissionais de análise de sistemas e de negócios além do código e da linguagem. Ajuda a projetar aplicações que sejam a especificação da automatização dos processos de negócios de uma organização através da tecnologia da informação. Você vai conhecer um pouco os Modelos de Capacidade e Maturidade ( (CMMI),  CMMI), o Processo Unificado da Rational ( ( RUP), RUP), o que são Métodos Ágeis e a Integração de Metodologias de Desenvolvimento de Software, para que possamos nos situar no contexto aplicado hoje no País em desenvolvimento de software. Concluindo, podemos afirmar que sem uma correta DEFINIÇÃO e gestão dos requisitos do aplicativo é praticamente certo que o projeto TERÁ O SEU SUCESSO COMPROMETIDO, frustrando as expectativas do cliente e comprometendo comprometendo as metas e planos da empresa contratante do projeto.

Finalmente apresentamos um processo de Engenharia e Gestão de Requisitos Requisitos adequado à CMMI e com base em RUP, além de uma visão de adequação dos Métodos Ágeis, em que se destaca a importância da estruturação da disci disciplina plina de Engenharia e Gestão de Requisitos. Então vamos estudar e conhecer um pouco deste universo, e detalhar bastante as técnicas necessárias para a identificação, entendimento dos processos de negócios e como realizar a Especificação de Requisitos. Certamente a frase a seguir vai ajudá-lo a não se repetir: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...”

OUVIR NÃO BASTA, É NECESSÁRIO OBSERVAR E POSSUIR TÉCNICA PARA ENTENDER. Figura 1.5

 

28

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A figura indicada a seguir, que você já deve ter visto inúmeras vezes, deve ser parte da história da construção de sistemas.

Requisito balanço feito corda e que seja amarrado num galho da árvore, e queEueuquero possaum ficar sentado node meio dele.

Figura 1.6 Fonte: Adaptado do site http://www.projectcartoon.com/ 

 

2

Requisitos - Conceituação

“Não tenhamos pressa, mas não percamos tempo.” (José Saramago)

Desenvolvimento de Software Antes de apresentar os detalhes sobre requisitos e abordagens técnicas, vamos estabelecer parte da terminologia envolvida nos próximos capítulos, através de definições dos elementos que compõem as abordagens, encontradas na literatura.

Processo e Modelo de Processo Um processo é um conjunto de práticas executadas para atingir determinado determinado objetivo; pode incluir ferramentas, métodos, materiais e pessoas. Um modelo de processo é uma coleção estruturada de elementos que descreve características de processos efetivos. O CMMI é um modelo de processos processos cuja utilização é comprovadamente efetiva, através de um histórico amplo de projetos utilizado como base para sua criação. Modelos de processo são utilizados para definir objetivos e prioridades de melhoria de processo; para contribuir com a garantia de que um processo é estável, capaz e maduro; como orientação para a melhoria de processos de um projeto ou de uma organização; ou ainda como uma forma de declarar o estado dos esforços de melhoria de uma organização, empregando uma metodologia de avaliação. É importante notar, ainda, que modelos são abstrações da realidade e, por isso, não devem ser empregados diretamente como foram definidos, mas sim adaptados de acordo com a realidade e cultura da organização, o domínio de aplicação, o projeto realizado etc. A qualidade de um sistema é altamente influenciada pela qualidade do processo utilizado em sua obtenção, desenvolvimento e manutenção.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

30

 Metodologia Metodologia Uma metodologia é uma coleção recomendada de fases, procedimentos, regras, técnicas, ferramentas, documentação, gerência e treinamento utilizados para desenvolver um sistema. Existe filosofia por trás da um conjunto de crenças e suposições que uma a apoiam, explicando pormetodologia, que a metodologia funciona da forma como funciona. Essa filosofia pode ser representada por meio de valores, princípio ou práticas fundamentais da metodologia.

Terminologia Stakeholder

O stakeholder é qualquer pessoa materialmente afetada pelo resultado do pro jeto: clientes, usuários diretos e indiretos, investidores, acionistas, fornece fornecedores, dores, supervisores, gerentes, compradores, pessoal de suporte e manutenção, redatores técnicos (que documentam o sistema). organização Stakeholders pertencem a diversos grupos distintos dentro de uma organização e, assim, apresentam diferentes pontos de vista a respeito do sistema. Alguns estão tão envolvidos com o sistema a ponto de suas carreiras dependerem dele. Outros são envolvidos apenas indiretamente pelos resultados de negócio que o sistema influencia. Alguns têm força decisiva sobre o sistema, outros apenas colaboram com informações e experiência. Algumas definições incluem a equipe de desenvolvimento como possíveis stakeholders: projetistas, testadores, programadores, demais desenvolvedores. A literatura também menciona os conceitos de stakeholder relevante, aquele com poder de decisão e cuja colaboração com o projeto é significativa, e represen representante tante de stakeholder , uma pessoa que substitui o stakeholder quando ele não está disponível. A compreensão de quem são os stakeholders e suas necessidades particulares particulares são elementos-chave no desenvolvimento de uma solução efetiva de sistema siste ma de software. Os stakeholders estão diretamente envolvidos na orientação, forma e escopo do projeto.

 

Requisitos - Conceituação

31

Cliente

É um tipo especial de stakeholder . Ele representa o responsável pelo orça orçamento mento do projeto. Neste livro, este termo é utilizado para representar os stakeholders do pro jeto que tema.interagem com a equipe de desenvolvimento para definir os requisitos do sisElicitar

Significa extrair, obter, identificar, produzir os requisitos do sistema. Pode utilizar uti lizar técnicas sistemáticas como protótipos ou entrevistas estruturadas, estrutura das, para identificar e documentar proativamente as necessidades dos stakeholders. Cenário

Sequência deser eventos que podem ocorrer durante a utilização sistema. Cenários podem usados para explicitar necessidades e specíficasdedeum específicas clientes ou para contribuir com a definição de um caso de uso. Vamos ver mais detalhes de cenários no capítulo sobre Casos de Uso.  Disciplina Disciplina

É um corpo de conhecimento disponível, relacionado a um modelo de processo. Agrupa as atividades de um processo de desenvolvimento de software, de acordo com sua natureza.  Artefato

É uma porção de informação que é produzida, modificada ou utilizada por um processo. Artefatos são os produtos tangíveis de um projeto. As coisas que o projeto produz ou usa enquanto trabalha rumo ao produto final. Podem ser modelos, como, por exemplo, diagramas de classe, elementos de modelos como as próprias classes, documentos, código-fonte, código executável. Também podem ser compostos por outros artefatos. Visto este pequeno glossário com as terminologias utilizadas no livro, podemos então seguir com o contexto.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

32

O que são Requisitos Os requisitos são o ponto de partida para toda a definição do sistema e, consequentemente, são fatores decisivos no desenvolvimento do produto final. A literali teratura relacionada à engenharia de requisitos oferece diversas definições do conceito de requisito. Acompanhe:   Uma condição ou capacidade com a qual o sistema deve estar em conformidade.   Uma especificação do que deve ser implementado ou uma restrição de algum tipo do sistema.   Por fim, a definição que é padronizada pela IEEE em seus Padrões, Guidelines e Exemplos sobre Engenharia de Requisitos de Sistemas e de Software é a seguinte: • Uma condição ou capacidade necessária a um usuário para resolver um problema ou alcançar um objetivo. • sistema Uma condição ou capacidade serpara alcançada ou possuída por um ou por um componenteque de deve sistema satisfazer um contrato, padrão, especificação ou outros documentos formalmente formalmente expostos. • Uma representação documentada de uma condição ou capacidade como a dos itens 1 ou 2. Neste livro vamos utilizar todas estas definições, mas com ênfase à última como referência por considerá-la a mais abrangente. Contudo, o termo usuário deve ser substituído por interessado (stakeholder ),), já que o cliente e suas diversas equipes envolvidas na definição e utilização do sistema também devem fornecer requisitos a este sistema. 





  



Partindo destas definições, alguns exemplos de requisitos seriam: “O sistema deve fornecer informações sobre todas as ações executadas por seus usuários em qualquer período de tempo.” “O sistema deve estar integrado ao sistema bancário XXY utilizado pela organização.” “O sistema deve oferecer ao cliente a compra menos custosa que satisfaça seus parâmetros de definição do produto.” “Precisamos diminuir as vendas que resultam em fraude no pagamento.” “O sistema deve seguir um processo de desenvolvimento baseado em RUP.” “O sistema deve gerar relatórios sobre vendas por período, evidenciando eviden ciando os parâmetros de avaliação dos envolvidos.” Observe que vamos insistir nesta tecla, na lista anterior, que é um padrão técnico de mercado. Podemos colocar em cada uma as seguintes questões:

 

Requisitos - Conceituação

33

Que ações? Quais são essas ações?   O que é estar integrado ao sistema bancário? O que faria essa integração? integração? Que processo é este, e que processos envolve?   Compra? Como é feita a compra? O que é o processo de compra de um cliente? Que são parâmetros de definição de produto?   Venda? Como é o processo de venda? O que é fraude de pagamento nesse processo? Pagamento é outro ou o mesmo processo? Seguir RUP? Isso é um processo da empresa? De que área?     Relatórios sobre vendas por período, evidenciando os parâmetros de avaliação dos envolvidos? Que parâmetros são estes? Como são obtidos? Fazem parte do processo de venda? Como é tratado período nesse processo? O que é período nesse processo de venda? As colocações de exemplos anteriormente destacadas, e que colocamos em xeque, vamos salientar durante o estudo da análise de requisitos, para atrelar uma visão por função quando da análise de requisitos, pois esta visão leva a uma distorção na interpretação de processos e, consequentemente, a uma errônea ou falha definição de requisitos de um projeto.  



Necessidades, Características e Requisitos de Software Requisitos são de natureza variável. Eles podem ser uma descrição de funcionalidade no nível do usuário, uma especificação detalhada do comportamento comportamento esperado de um sistema, uma propriedade genérica de um sistema, uma restrição técnica do sistema, uma restrição no processo de desenvolvimento, informações sobre como realizar determinado cálculo ou uma informação que se deseja obter, etc. Os requisitos podem ser classificados em diferentes níveis, de forma que o requisito em um nível dá origem a um ou mais requisitos no nível seguinte (requisitos derivados). O Processo Unificado da Rational (RUP) divide os requisitos requisitos em:    Necessidades: reflexões de problemas de negócio, pessoais ou operacionais operacionais que devem ser endereçadas para justificar o desenvolvimento de um novo sistema. O RUP na sua essência trata do Processo de Negócios. Negócios. Vamos recuperar essa potencialidade.     Características: Características: serviços observáveis externamente através dos quais o sistema satisfaz uma ou mais necessidades dos interessados. Novamente Novamente se destaca sem ser explícito que estamos lidando com Processos de Negócios. Os requisitos, de modo geral, podem ser classificados em dois grandes grupos: 



Requisitos que especificam como o sistema interage com o contexto à sua volta (Requisitos Funcionais). Requisitos que expressam atributos de qualidade da solução (  (  Requisitos Requisitos Não Funcionais).

 

34

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Requisitos Funcionais Estes são os requisitos com os quais desejamos trabalhar neste livro, pois acreditamos que neles residem a maior dificuldade e o índice de falhas nos projetos de sistemas. Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquele que descreve as funcionalidades, quais se espera que o sistema forneça. Elespassado dependem tipo de sendo desenvolvido, do conhecimento pelosdousuários software queasestá sobre o negócio em si e do que deve fazer o software que se espera desenvolver. A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais funções o sistema efetivamente terá para satisfazer satisfazer aquilo que os usuários querem, ou melhor, que o proces processo so de negócio exige.

Requisitos de Informação Como parte dos requisitos funcionais existem os requisitos de informação, que representam a informação que se espera obter do sistema. Eles também são atendidos ou fornecidos por algum comportamento esperado do sistema. Muitas vezes o cliente expressa requisitos de informação de modo funcional. Outras vezes está preocupado em conseguir uma informação, mas não sabe como descrevê-la na forma de um requisito funcional. Em todo caso, é preciso levantar todos os requisitos de informação, pois eles representam as respostas fundamentais do sistema em análise.

Requisitos Não Funcionais Os requisitos não funcionais não estão ligados diretamente com as funções fornecidas pelo sistema.

 

35

Requisitos - Conceituação

Em geral se preocupam com padrões de qualidade como confiabilidade, desempenho, robustez, segurança, usabilidade, portabilidade, legibilidade, qualidade, manutenibilidade, entre outros. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer. Um sistema ineficiente certamente não será usado. São exemplos de requisitos não funcionais:   “A base de dados deve ser protegida para acesso apenas de usuários autorizados.”   “O tempo de resposta do sistema não deve ultrapassar 30 segundos.”   “O software deve ser operacionalizado no sistema Linux.”   “O tempo de desenvolvimento não deve ultrapassar seis meses.” É preciso destacar novamente que o objetivo principal do livro é aprender e passar experiências em requisitos funcionais.

Figura 2.1: Tipos de requisitos não funcionais.

Com isso queremos afirmar que o problema não é se o .NET, Java ou outras tecnologias e ferramentas são instrumentos limitados para a construção de softwares. Pesquisadores como Sueli Fiorini, no livro Engenharia de Software com CMM , define ainda outros três tipos de requisitos, que são requisitos inversos, que descrevem o que o software não deve fazer; requisitos de design e implementação, implementação, que são condições que limitam como o software pode ser implementado, e ainda requisitos não técnicos, que se referem a acordos, condições ou termos contratuais que afetam e determinam as atividades de gerência de um projeto de software.

 

36

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Requisitos de Processos de Negócios O propósito a partir deste instante é associar os processos de negócio à definição de requisito. Requisito Processo de Negócio aqueles que estão diretamente ligados ligados ao processo dede negócio, ao como se faz, são aos conceitos de subprocesso, de tarefas de um processo. Esses requisitos somente são obtidos através da observação observação detalhada da execução do processo e do estudo da documentação de normas nor mas e processos de uma organização. Você deve estar questionando como entender a observação da execução de um processo sem ter conhecimento técnico de regras que regem esse processo, sejam elas normas legais ou técnicas inerentes ao negócio. Este é um dos objetivos objetivos que vamos explorar repetidamente através de exemplos de quatro situações ou estudo de casos. Adotaremos a forma de, sempre que necessário, repetir as definições descritivas do desem casos, para você ter de manter a leitura eoocaso estudo sequência estudo no livro, necessidade de condições voltar páginas para entender emem estudo.

Processos Em primeiro lugar é preciso entender o que é processo. Como definição clássica temos que processo é uma série de atividades executadas sequencialmente sequencial mente para produzir um produto ou serviço. Não podemos nos atrelar a uma visão por função quando da análise de requisitos, pois essa visão leva a uma distorção na interpretação de processos que nos induz a erros no entendimento deles, assim como leva as organizações a lapsos administrativos e à criação de uma visão por silos de informação. A visão por função não mostra como um valor é agregado a um processo ou por um processo. Isso equivale a realizar levantamento de requisitos baseado nas pessoas e nos setores por onde o fluxo dele ocorre. Vamos analisar tudo sobre o enfoque da visão de processos que traz a definição de processo: Qualquer atividade ou um conjunto de atividades, disparado ou inicializado inicia lizado por um evento externo, provendo resultados de negócio, através da transformação de insumos em produtos e serviços, objetivando sempre a satisfação satisfação do cliente desse processo. Um processo é caracterizado pelo seguinte:   Missão do processo Fatores críticos de sucesso  

 

Requisitos - Conceituação

37

Restrições Decomposição de suas atividades    



Missão do Processo

Identifica a razão de existência do processo no ciclo dos produtos e/ou serviços da empresa. Define os objetivos permanentes que devem ser alcançados pelo processo e a forma como ele agrega valor a produtos, serviços e controles da empresa.  Eventos Eventos

Eventos são acontecimentos externos ou não ao processo que, de alguma forma, estimulam a execução de uma ação por parte dele em resposta ao evento. Os eventos podem ser classificados da seguinte forma: 

Quanto à natureza do evento • Eventos Externos Programados • Eventos Temporais • Eventos Externos Ad Hoc   Quanto à cronologia do processo • Eventos Iniciais • Eventos Finais   Exemplos de Eventos:  

• Eventos Externos Programados • Chegada de uma nota fiscal e materiais de um fornecedor. • Emissão de uma nova previsão de vendas.   Eventos Temporais • Todo dia 5 de cada mês é feita a apuração de resultados. • Todos os dias às 20h encerra-se a inclusão de pedidos de venda.   Eventos Externos Ad Hoc • Mudanças inesperadas na legislação • Mudanças repentinas de mercado • Quanto à cronologia do processo

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

38

  Fatores  Fatores Críticos de Sucesso (FCS)



• Qualquer tipo de aspecto que ponha em risco a missão do processo. • Os FCS podem dizer respeito a qualquer tipo de recurso (material, humano, tecnológico etc.) ou a aspectos de qualidade quanto a entradas entradas e controles. • Ao serem analisados, os FCS devem ser acompanhados das medidas a serem tomadas para a sua garantia.   Restrições • Restrições significam limites de atuação ou alcance do processo. • São em geral estabelecidas pelas políticas e regras de negócio ou por procedimentos que devem ser executados em resposta a eventos Ad Hoc.   Atividades • Os processos também são caracterizados pela relação de suas atividades. atividades. • As atividades são as ações tomadas pelo processo em resposta a eventos. • As atividades utilizam-se das entradas, regras, políticas e recursos para a produção de saídas específicas (produtos do processo). • Atividades observadas em níveis de abstração diferentes podem ser classificadas segundo uma hierarquia de processos, o que q ue permite uma organização eficaz deles com o objetivo de melhor entender o seu desempenho e a qualidade necessários. Você deve estar se perguntando por que estamos detalhando tanto esta questão dos processos e seus eventos, mas a justificativa baseia-se que estamos tratando de observação, levantamento e identificação de requisitos, localizados nos processos da organização; logo, é um ponto essencial para a realização da análise de requisitos. Mas se pararmos para pensar, veremos que isso tudo é o ambiente em que vivenciamos o levantamento de requisitos normalmente, porém sem esse enfoque enfoque organizado e voltado para o processo em si. Vistas as observações que servirão de base a todo nosso estudo, vamos seguir com nossas conceituações e nos situar no mundo de desenvolvimento de aplicações de TI que nos envolve.

Softwares “Fast Food” Hoje existe uma preocupação acentuada com desenvolvimento com qualidade em prazos cada vez menores, com iterações de entregas em curtíssimo espaço de tempo. Desenham-se métodos e processos, mas ainda continuamos pecando no entendimento da realidade de negócios para a qual estamos desenhando dese nhando uma solução de software.

 

Requisitos - Conceituação

39

Em primeiro lugar, é importante identificar o que não contribui para o fracasso no desenvolvimento de software. Jim Johnson, do The Standish Group, afirma que “quando um projeto falha, raramente a causa é técnica”. Com isso pode-se afirmar que o problema não é se o .NET, Java ou outras tecnologias e ferramentas sejam instrumentos limitados para a construção de soluções de T.I. A raiz da maioria das falhas está na (ausência de) utilização de metodologias metodo logias de desenvolvimento adequadas e como elas interagem com os stakeholders em um projeto de software, e principalmente pela dificuldade do entendimento dos conceitos básicos dos processos de negócio. Por “metodologia de desenvolvimento” entende-se o conjunto das atividades, atividades, responsabilidades, artefatos (documentos, diagramas, código-fonte etc.), orientações e boas práticas usadas para planejar, construir e implantar software. Muitas organizações e profissionais utilizam os termos “  “processo”  processo” ou “  “ fra   mework  framew ork” no lugar de “metodologia”, entretanto podemos considerar que estes termos possuem outro significado e vamos discuti-los em momento mais específico específico no livro. André Furtado, em seu artigo Pontas de Iceberg do Caos no Desenvolvimento Desenvolvimento de Software, coloca: Infelizmente, esse é um aspecto da Engenharia de Software com o qual precisamos lidar: alguns de seus termos não possuem uma padronização universal, podendo ser interpretados de maneira diferente quando em contextos distintos. Portanto, cabe res-

saltar que não existe um único conjunto correto de definições. Uma METODOLOGIA estabelece um caminho único no desenvolvimento de sistemas novos ou na evolução de sistemas já existentes. Ela introduz uma consistência ao longo do desenvolvimento de vários projetos de sistemas, provendo pro vendo uma lista de todas as atividades a serem realizadas, estabelecendo pontos de verificação para auditoria e controle do projeto. Então vejamos algumas situações que temos de enfrentar: “Estou precisando de um website...

Ótimo, podemos fazê-lo. Gostaria de marcar uma reunião para fazermos o briefing do que precisa, conhecer alguns detalhes de design, tipo de hospedagem... Não, não, você não está entendendo, é para ontem!”

Quem ainda não encontrou ou sempre encontra uma situação como esta? Para o caso recomendamos lembrar algumas frases de referência: QUEM VOA É AVE E AVIÃO, A VIÃO, PROJETO DE SISTEMAS NÃO. Se você não tem estas características, não tente nem se estresse tentando definir requisitos de sistemas em prazos absurdos que não permitam o seu correto correto entendimento e especificação.

 

40

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

SÓ DEUS FAZ MILAGRES E NEM SEMPRE.

Em primeiro lugar, sistemas não são feitos da noite para o dia. Eles englobam englobam muito mais que linhas de programação. Horas de testes, manuais, documentação documentação e treinamento fazem parte do que chamamos de “software”. Seeodemonstre cliente exige prazo absurdamente curto, rediscuta ou não o do faça. Saliente queum o resultado da pressa é proporcional à qualidade resultado de sistema. NÃO SE ESTÁ EM DOIS LUGARES AO MESMO TEMPO.

Se o cliente do projeto de sistema quer que q ue você converse, faça levantamento levantamento de requisitos em curto espaço de tempo, com agendas apertadas, lembre-se de que você não tem como estar levantando informações e necessidades necessidades de um grupo de usuários ao mesmo tempo em que de outro, de áreas distintas, ou operações distintas.

NÃO BASTA TECNOLOGIA.

Conhecer e dominar uma linguagem de programação é bom, mas não é tudo. Dominar ou ter uma certificação de processo de desenvolvimento como CMMI nível 3,4 ou 5,ou MPS-Br não é garantia nenhuma para criar sistemas robustos e com qualidade. É preciso mais do que um bom processo ou boa linguagem linguagem e bons analistas e programadores. A necessidade de estabelecer os requisitos de maneira e de forma precisas é crítica à medida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros, logo não podemos realizar análises de necessidades sem buscar sempre o entendimento do todo. Isso é o que chamamos de ter Visão Sistêmica e de Processo, enxergar e abstrair de cada necessidade a sua implicação com as outras dentro do contexto operacional opera cional do negócio. Então, vemos que análise de requisitos e análise de processos estão intimamente ligadas. PROJETO E CODIFICAÇÃO PERFEITOS SÃO DE POUCA UTILIDADE UTILIDADE QUANDO EXISTEM ERROS NOS REQUISITOS.

 

Requisitos - Conceituação

41

Resumo: 10 Grandes Armadilhas da Análise de Requisitos 1. Requisitos confusos: não permitem o seu correto entendimento e especificação. Ausência de técnica para descrever um requisito. 2. Envolvimento inadequado do cliente: o cliente não está envolvido integralmente com o processo de análise ou não tem interesse pelo processo do desenvolvimento. Isso geralmente provoca muitas distorções em relação ao que o cliente imagina e aquilo que ele recebe. 3. Requisitos vagos ou ambíguos: por serem mal elicitados, vários requisitos podem descrever a mesma tarefa ou serem ambíguos, vagos quanto ao que devem realmente significar. 4. Requisitos sem prioridades: todo requisito deve ser categorizado quanto ao seu nível de prioridade, pois orienta os desenvolvedores sobre quais requisitos devem ser implementados primeiro, suas interpelações, além da atenção especial para os pontos críticos do sistema; priorizar é dar ênfase ao que realmente interessa, à estrutura básica de um sistema e seus afluentes, digamos assim. 5. Requisitos inúteis não aplicáveis: a construção de requisitos que estão fora do escopo do processo em análise, que são funções que o cliente imagina serem necessárias. A política de análise e identificação de um requisito deve ser sempre: tudo o que não é necessário é desnecessário. 6. Interrupções na análise:  um projeto deve avançar mesmo que toda a análise não tenha sido concluída, porém sempre blocos de análise de um processo de negócio devem ser fechados, concluídos. A interrupção da análise é normal, mas mas erros aparecem quando quando o projeto estiver sendo efetivamente desenvolvido. Alteração do escopo: 7.  jeto  a adição de novosnarequisitos durante fase do proou codificação é sinal de problema análise, mas comoa veremos em metodologias ágeis, a alteração do escopo deixou de ser um problema para ser uma necessidade e ser tratada corretamente. 8. Processo de mudanças: a necessidade, como veremos, da existência e tratamento da gestão de mudanças é fundamental, pois devemos saber quais procedimentos devem ser feitos quando mudanças acontecerem. Lembre-se de que processos de negócio estão sempre em evolução. 9. Análise de impacto: quais serão os reais efeitos de uma mudança de requisitos dentro do projeto de software, quais requisitos são afetados. Aqui novamente destacamos a gestão de mudanças, como veremos neste livro.

10. Controle de versões: ter sistemas de controle de versão adequados evita refazer trabalho perdido ou sobrescrito por um colega. No desenvolvimento de aplicações para Web este conceito é ainda mais importante.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

42

Exercícios 1) Estudo de caso

 

O gerente de uma pousada deseja um sistema para gerenciar as reservas.

 

Quando um cliente potencial deseja fazer uma reserva, o sistema verifica se existem quartos disponíveis no período; e em caso positivo, o sistema solicita os dados do cliente (nome, endereço, telefone). O sistema também deve armazenar, na reserva, a data prevista para entrada, a data prevista para saída, o valor do desconto concedido e o número dos quartos. Cada quarto possui um preço e uma descrição. Não há frigobar nem serviços de quarto.

 

As reservas são garantidas por meio de pagamento de uma diária. Caso o cliente não efetue o pagamento até três dias antes da data prevista de entrada, a reserva é cancelada pelo sistema. Um relatório de reservas canceladas é gerado pelo sistema diariamente. Outros relatórios diários são o de reservas não pagas e o de reservas a serem efetivadas no dia. O gerente também deseja que o sistema imprima um relatório de reservas, dado um determinado período.

 

a) Liste quais requisitos funcionais é possível identificar.

 

b) Identifique requisitos não funcionais claros na situação exposta.  c) Crie um conjunto de perguntas perguntas que visem esclarecer o maior número de de dúvidas, omissões e ambiguidades da situação exposta e xposta pelo stakeholder .

2)  Classifique em requisito funcional ou requisito não funcional:

 

a) A interface deve seguir os padrões do ambiente Windows.  b) O acesso pela Internet deve ser disponibilizado para os clientes da empresa.

 

c) O valor máximo do pedido de venda deve ser de 1.000 unidades.

 

d) Todo pedido deve ter prazo de entrega de no máximo cinco dias.  e) Cada vendedor pode ter pedidos atendidos e em aberto, e deve ser possível visualizar as vendas por dia e os pedidos atendidos por dia para cada vendedor.

 

3

Modelos de Capacidade e Maturidade (CMMI)

“Se você não for melhor amanhã do que você foi hoje, então qual a sua serventia para amanhã?” (Rabbi Nahman of Breslov)

Introdução Este capítulo o CMMI, sua estrutura e seus objetivos, os conceitos utilizados em sua descreve elaboração, organização, classificação e composição de seus elementos. A fonte primária das informações apresentadas nestas seções é o relatório técnico que define o CMMI para Engenharia de Software, de autoria do SEI/CMU.

Definição e Objetivos Com o objetivo de criar condições para a evolução das boas práticas da engenharia de software software,, o Instituto de Engenharia de Software da Universidade de Carnegie Mellon (SEI/CMU), em Pittsburg, Estados Unidos, promoveu uma série de estudos que resultou na documentação de um conjunto de melhores práticas para processos de desenvolvimento de software, descritas no Modelo de de Capacidade Capacidade e  Maturidade, o CMM (Capability Maturity Model).

Dependendo da área de aplicação, diferentes modelos foram criados, tais como Software-CMM (CMM para Software) e SA-CMM (CMM para Aquisição de Software). O CMMI (Capability Maturity Model Integration), ou Integração de Modelos de Ca pacidade e Maturidade Maturidade, representa a integração e a evolução desses modelos em um volume único, que substituiu os múltiplos modelos de CMM previamente previamente defini-

dos. O CMMI é um modelo de referência que contém práticas ( Genéricas ou Espe( Systems Engineering cíficas) necessárias à maturidade em disciplinas específicas (Systems cíficas) (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura es-

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

44

tabelecer um modelo único para o processo de melhoria corporativo, integrando

diferentes modelos e disciplinas.

Modelos de Processo Integrados As pesquisas e todas as atividades envolvidas no estudo modelos pelo SEI possuem o apoio do Departamento de Defesa dos Estadosdesses Unidos.

Objetivos O objetivo do CMMI é melhorar os processos da organização que o adota, assim como sua habilidade de gerenciar o desenvolvimento, aquisição e manutenção manu tenção

de produtos ou serviços. Neste sentido, o CMMI busca servir como uma estruturação de práticas e abor-

dagens de sucesso comprovado. Tais práticas visam contribuir com a organi organização zação através da disponibilização de orientações sobre: 

Como avaliar sua maturidade organizacional e sua capacidade por área de processo.



Como estabelecer prioridades para melhora.



Como implementar tal melhora.

O CMMI é formado por um pacote de produtos que reúne múltiplos modelos de processo, associados a seus manuais, material de treinamento e de avaliação. Os modelos que integram o CMMI têm o objetivo de integrar o gerenciamento geren ciamento de qualidade, as melhores práticas aplicadas a determinados domínios e a práticas

de mudança da organização. CMMI fornece um segundo mecanismo de avaliação estabelecido de popular maturidadeOde processo. Ainda, Smith, o CMMI sebem tornou um veículo para a determinação da maturidade do processo de desenvolvimento de software

de organizações em diversos domínios.

Representações e Corpos de Conhecimento Os modelos CMMI variam de acordo com a representação e com o corpo de conhecimento (body (body of knowledge) knowledge) escolhido pela organização.

Existem duas representações, sendo contínua ou em estágios.

Representação Contínua

Possibilita à organização utilizar a ordem de melhoria que melhor atende

os objetivos de negócio da empresa. É caracterizada por Níveis de Capacidade (Capability Levels):

 

Modelos de Capacidade e Maturidade (CMMI)

45

  Nível 0: Incompleto (Ad hoc)



  Nível 1: Executado (definido)



  Nível 2: Gerenciado



Nível 3: Definido   Nível 4: Quantitativamente gerenciado/Gerido quantitativamente   Nível 5: Em otimização (ou otimizado) 

Nesta representação a maturidade é medida por processos separadamente, em que é possível ter um processo com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa.   No nível 1 (um) o processo é executado de modo a completar o trabalho necessário para produzir o trabalho necessário.







No nível 2 (dois) é sobre planejar a execução e confrontar o executado contra o que foi planejado. No nível 3 (três) o processo é construído sobre as diretrizes do processo exis-

tente, e é mantida uma descrição do processo. 



No nível 4 (quatro) é quando o processo é gerenciado quantitativamente quantitativamente atra-

vés de estatísticas e outras técnicas. No nível 5 (cinco) o processo gerido quantitativamente é alterado e adaptado adaptado para atender às necessidades negociais/estratégicas da empresa.

Figura 3.1: Fonte - Carnegie Mellon University, © 2005.

A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

46

Na representação contínua, as áreas de processo encontram-se organizadas

por categoria: Tabela 3.1

Categoria

Áreas de Processo

Enfoque no Processo Organizacional Definição do Processo Organizacional

 Gestão de Processo Gestão

Formação Organizacional Desempenho de Processo Organizacional

Inovação e Implementação Organizacional

Gestão de Projeto

Engenharia

Planejamento de Projeto Monitorização e Controle de Projeto Gestão do Acordo com o Fornecedor Gestão Integrada do Projeto Gestão de Risco Integração de Equipes Gestão Integrada de Fornecedore Fornecedoress Gestão Quantitativa do Projeto Gestão  G estão de Requisitos Desenvolvimento Desenvolvimen to de Requisitos Solução Técnica Integração do Produto Verificação

Validação Gestão de Configurações

Suporte

Garantia da Qualidade do Processo e do Produto Medição e Análise Análise das Decisões e Resolução Ambiente Organizacional para Integração Análise e Resolução Causal

Representação por Estágios A representação por estágios ou segmentada foca as melhores práticas que a organização pode utilizar para melhorar mel horar os processos das áreas de processo que se encontram no nível de maturidade escolhido para alcançar. Antes de iniciar a utilização do modelo CMMI para a melhoria dos processos, processos,

eles devem ser mapeados com os da organização, as áreas de processo do CMMI. Esse mapeamento permite controlar a melhoria do processo da organização, organização, através da possibilidade de analisar o nível de conformidade da organização organização em rela-

ção ao modelo CMMI utilizado. Não é pretendido que todas as áreas de processo do CMMI mapeiem de um para um os processos da organização.

 

47

Modelos de Capacidade e Maturidade (CMMI)

Essa representação disponibiliza uma sequência predeterminada para melhoria melhoria baseada em estágios que não deve ser des-

considerada, pois cada estágio serve de base para o próximo, começando com prá-

ticas de gerência e progredindo progredindo ao longo de um caminho com níveis sucessivos predefinidos, cada um servindo como base para

o próximo. É caracterizado por Níveis de Maturidade ( Maturity  Maturity Levels).

Figura 3.2

Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os processos pro cessos forem nível três, mas apenas um deles estiver no nível dois, a empresa não conse-

guirá obter o nível de maturidade três. As áreas de processo existentes por cada nível de maturidade são as seguintes: Tabela 3.2

Nível de Maturidade

Nível 2 - Gerido

Áreas de Processo

Gestão  G estão de Requisitos Planejamento de Projeto Monitorização e Controle de Projeto Gestão do Acordo com o Fornecedor Medição e Análise Garantia da Qualidade do Processo e do Produto Gestão de Configurações

Desenvolvimento de Requisitos Desenvolvimento Solução Técnica Integração do Produto Verificação

Validação Enfoque no Processo Organizacional Nível 3 - Definido

Definição do Processo Organizacional

Formação Organizacional Gestão Integrada do Projeto Gestão de Risco Integração de Equipes Gestão Integrada de Fornecedore Fornecedoress Ambiente Organizacional para Integração Análise das Decisões e Resolução

Nível 4 - Gerido

Performance do Processo Organizacional

Quantitativamente

Gestão Quantitativa do Projeto Inovação e Desenvolvimen Desenvolvimento to Organizacional Análise e Resolução Causal

Nível 5 - Otimizado

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

48

As diferenças entre as estruturas contínua e estagiada são sutis, mas signifi-

cativas. A representação segmentada usa níveis de maturidade para caracterizar o estado geral da organização de processos relativos ao modelo como um todo, en-

quanto a representação contínua utiliza níveis de capacidade para caracterizar o estado da organização de processos relativos a uma área de processo individual. individual. Observe nas imagens essas diferenças.

Figura 3.3: Representação contínua.

Quanto aos corpos de conhecimento, eles representam domínios de aplicação, aplicação,

cada um com seu modelo de processo correspondente.

Figura 3.4: Representação estagiada.

Os modelos definidos no CMMI atualmente correspondem aos seguintes corpos de conhecimento, também chamados de disciplinas: 

completo  Engenharia de Sistemas: práticas relacionadas ao desenvolvimento completo de sistemas (de software ou qualquer outro tipo de sistema).

 

Modelos de Capacidade e Maturidade (CMMI)

 





49

 Engenharia de Software:  práticas relacionadas ao desenvolvimento de sistemas de software.  Desenvolvimento Integrado de Produto e Processo (IPPD): abordagem sistemática relacionada à colaboração dos envolvidos.



fornecedores.  Fornecedor Externo: práticas Externo: práticas relacionadas à subcontratação de fornecedores. Está prevista, ainda, a possibilidade de inclusão de novas disciplinas no CMMI ao longo do tempo. O livro tem como objetivo a representação do CMMI em estágios, a disciplina disciplina de Engenharia de Software Software,, e detalha até o nível 3 de maturidade do CMMI.

 Aplicação em Organizações A adoção ou implantação de um modelo CMMI deve ser feita observando as particularidades da organização, do ambiente de negócios e das demais circunstâncias envolvidas. Assim, evidencia-se o conceito do framework do framework CMMI, que repre-

senta um conjunto completo de modelos que será customizado de acordo com as necessidades da organização previamente à sua adoção. Antes de aplicar um modelo CMMI para melhorar os processos de uma or-

ganização, é preciso mapear os processos da organização  para áreas de processo processo (PAs) do CMMI. Esse mapeamento permite determinar o nível de conformidade ao modelo CMMI atingido pela organização. Nem todos os processos da organização terão um mapeamento direto para uma área de processo CMMI, já que as metas de uma PA (Process Area) podem estar sendo satisfeitas pelo conjunto de processos da organização.

Conceitos Utilizados Alguns conceitos básicos utilizados na construção de modelos CMMI, ilustrados na figura a seguir, são: 

 Nível de Maturidade: Maturidade: representa um estágio evolucionário definido, que pode ser atingido por uma organização que utiliza elementos dos modelos CMMI de forma completa ou parcial. Os níveis são uma forma de priorizar as ações de melhoria de tal forma que se aumente a maturidade do processo de software. Por exemplo, no nível 2 são tratados tratados aspectos gerenciais dos projetos, e no ní-

vel 3 são tratados aspectos técnicos de desenvolvimento.  



  apacidade de Processo: descreve Capacidade C Processo: descreve o conjunto de resultados esperados e que podem ser alcançados, por seguir o processo de software capacidade de prosoftware.. A capacidade cesso de software de uma organização provê os meios de predizer os resultados esperados para o próximo projeto da organi organização. zação.

 

50

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 

 uma área de processo é o agrupamento  Áreas de Processo (Process Areas): Areas): uma de práticas relacionadas a determinado contexto que, quando executadas executadas de forma coletiva, satisfazem uma série de metas consideradas importantes para



alcançar uma melhora significativa naquele contexto (ou seja, atingir um certo nível de maturidade). 



 Metas Específicas: descrevem características a serem implementadas para saEspecíficas: descrevem  

tisfazer uma área de processo.  Práticas Específicas: atividades consideradas importantes para alcançar uma determinada meta específica.



prá ticas Subpráticas: descrições detalhadas que orientam a interpretação de práticas específicas ou genéricas.



 são rotuladas de “genéricas” porque podem aparecer em  Metas Genéricas: Genéricas: são mais de uma área de processo. Atingir uma meta genérica em uma área de processo significa obter uma melhora no controle do plane jamento e da implementação de processos associados àquela área de processo. Essa melhora



indica que tais processos são provavelmente efetivos, passíveis de repetição e duradouros.  Práticas Genéricas: boas práticas a serem executadas com o objetivo de alcançar as metas genéricas. Fornecem orientações para que os processos processos associados a uma área de processo sejam efetivos, passíveis de repetição e duradouros. As práticas genéricas são classificadas em diferentes diferentes categorias, chamadas de características comuns.



práticas Características Comuns: Comuns:   agrupamentos utilizados para apresentar práticas genéricas. Existem apenas na representação por estágios (níveis de maturida-

de) do CMMI. As características comuns são: 





 agrupa práticas relacionadas à criação de políCompromisso com a Execução: ticas organizacionais e à garantia de apoio ao processo por parte dos diversos membros da organização, sobretudo a direção.  Habilidade para a Execução: Execução: as práticas dessa característica garantem a disponibilidade dos recursos necessários para execução do processo.  Direcionamento da Implementação: agrupa práticas genéricas que orientam a execução do processo através do controle de seu desempenho, desempenho, da gerência da integridade de produtos de trabalho e do envolvimento de stakeholders re-

levantes. 



Verificação da Implementação:  categoria de práticas relacionadas à revisão pela gerência sênior e à avaliação objetiva de aderência ao processo definido

pela organização. a tividade: artefatos, do Produtos de Trabalho: resultados de saída de alguma atividade: cumentos, planilhas, listas, avaliações, gráficos etc.

 

Modelos de Capacidade e Maturidade (CMMI)

 



51

adoção  Institucionalização:  este conceito representa a definição, promoção, adoção e avaliação de processos definidos ao longo de toda a organização. Institucionalizar um processo significa criar políticas organizacionais para tal processo, planejar sua utilização, divulgar esse planejamento, criar formas de estimulação do uso do processo, quantificar seus resultados resul tados e criar bases históricas em um repositório para futuras consultas. Para cada nível de maturidade, a insti-

tucionalização de processos possui possui características e requisitos próprios.

Figura 3.5: Componentes de modelos CMMI.

 Áreas de Processo Uma área de processo é um conjunto de práticas relacionadas a determinado determi nado contexto que, quando executadas de forma coletiva, satisfazem uma série de objetivos considerados importantes para alcançar uma melhora significativa naquele

contexto. Há quatro categorias de área de processo nos modelos CMMI, sendo Gerenciamento de Processo, Gerenciamento de Projeto, Engenharia e Suporte Suporte.. A tabela seguinte apresenta essas categorias associadas às áreas de processo que as compõem. com põem. Nota-se que as áreas de processo discutidas neste trabalho não incluem aquelas relacionadas ao modelo IPPD (Desenvolvimento Integrado de Produto e Processo) ou

à Gerência de Fornecedores, já que o foco do livro são os modelos relacionados à Engenharia de Software.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

52

Tabela 3.3: Áreas de processo do CMMI por categoria. c ategoria.

Categoria

Área de Processo

Foco no Processo Organizacional (Organizational Process Focus) Definição do Processo Organizacional Organizational al Process Definition) (Organization

Gerenciamento de Processo

Treinamento da Organização (Organizational Training) Desempenho de Processo Organizacional (Organizational Process Performance)

Implementação e Inovação Organizacional (Organization Organizational al Innovation and Deployment)

CMMI em Estágios e os Níveis de Maturidade Conforme foi descrito anteriormente, a representação do CMMI em estágios está gios define uma sequência comprovada de melhorias, progredindo ao longo de um caminho com níveis sucessivos de maturidade organizacional.

Cada nível serve como base para o próximo, de forma a priorizar as ações de melhoria conforme o que se observou ser uma ordem eficiente de execução dessas

ações. Os níveis sucessivos de maturidade são estágios evolucionários que variam do 1 (Inicial) ao 5 (Em Otimização). Cada nível de maturidade trabalha determinado determinado grupo de áreas de processo. processo. Para cada área de processo, são definidas metas e práticas específicas, seguidas seguidas de

metas e práticas genéricas.

Uma organização atinge um determinado nível de maturidade quando alcan-

ça as metas e emprega as técnicas estipuladas para as áreas de processo daquele nível. Os cinco níveis de maturidade do CMMI são descritos nas seções a seguir. O processo de engenharia de requisitos proposto neste trabalho se insere em um processo global de desenvolvimento de software que visa atingir o nível 3 de maturidade organizacional. Assim,deve no que se características refere às áreasdescritas de processo relacionadas a requisitos, a organização ter as a seguir correspondentes aos níveis 2 (Gerenciado) e 3 (Definido).

 

Modelos de Capacidade e Maturidade (CMMI)

53

Nível de Maturidade 1: Inicial Neste nível se enquadram organizações que não possuem um processo definido, também considerado o nível do caos.

Neste caso, os resultados de cada projeto são imprevisíveis e em geral só são positivos quando os envolvidos apresentam desempenho classificado (SEI, 2002) como heroico. Outras características comuns dessas organizações são a tendência a criar com-

promissos que não conseguem cumprir, o estouro de orçamento e a incapacidade incapa cidade de reproduzir resultados bem-sucedidos.

Nível de Maturidade 2: Gerenciado Em organizações deste nível de maturidade, os projetos possuem um gerenciamento satisfatório de requisitos e os processos utilizados são planejados, execu-

tados, mensurados e controlados. Diferente do que acontece no nível de maturidade Inicial, em organizações

de nível Gerenciado os processos definidos não são abandonados em momentos

de crise. Requisitos, processos, produtos e serviços são gerenciados e seu status é visível para a gerência em pontos de checagem claramente definidos (marcos ou

milestones).

Nível de Maturidade 3: Definido Neste estágio, além dos processos estarem bem definidos e entendidos, há

uma descrição formal destes, envolvendo padrões, procedimentos, ferramentas e métodos. Os processos são estabelecidos e melhorados ao longo do tempo.

Cada projeto utiliza a descrição padrão de processos da organização como um  framework, e o configura com o objetivo de adaptar o processo padrão às caracte framework,

rísticas do projeto. A configuração é feita seguindo regras definidas no processo padrão, o que

garante que diferentes projetos não apresentem variações muito grandes entre si, aumentando, assim, o controle dos resultados.

Nível de Maturidade 4: Gerenciado Quantitativamente Partindo da descrição padrão de processos da organização caracterizada no item anterior, organizações com nível 4 de maturidade selecionam subprocessos-chave para melhoria de desempenho nos resultados dos projetos.

Esses subprocessos são então controlados por meio de técnicas estatísticas e quantitativas.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

54

O controle desses subprocessos é feito da seguinte forma:  

São definidos objetivos quantitativos para qualidade e desempenho.

Durante a execução do subprocesso, seus resultados são medidos por técnicas mencionadas anteriormente.

  Processos de gerenciamento utilizam-se dos objetivos e das medidas durante o andamento do subprocesso para assegurar resultados positivos positivos (pode-se identificar, por exemplo, causas de variações nos índices de desempenho e então corrigi-las).



Medidas de qualidade e desempenho de processos são armazenadas no repo-

sitório corporativo para sedimentar futuras decisões.

Nível de Maturidade 5: Em Otimização Neste nível de maturidade, os processos da organização são continuamente melhorados com base na interpretação quantitativa das causas comuns de varia-

ção inerentes aos processos. Essas melhorias são feitas com o objetivo de alcançar metas definidas pela em-

presa e constantemente revisadas. A habilidade da organização de responder a mudanças e oportunidades rapidamente é alavancada pela utilização de formas de acelerar e compartilhar o conhecimento. Todos os participantes estão envolvidos na melhoria de processos.

Figura 3.6: Níveis de Maturidade CMMI.

Níveis de Maturidade do CMMI Nível de Maturidade 2: Gerenciado Esta seção descreve os requisitos que classificam uma organização como per-

tencente ao nível 2 de maturidade do modelo CMMI.

 

Modelos de Capacidade e Maturidade (CMMI)

55

 Áreas de Processo Conforme foi mencionado anteriormente, cada nível de maturidade trabalha traba lha

determinadas áreas de processo. 

As áreas de processo consideradas para o nível 2 de maturidade do CMMI são:  Gerência de Requisitos  (REQM - Requirements Management): é responsável responsável Gerência pela manutenção dos requisitos. Descreve atividades para manter e controlar mudanças nos requisitos e para fazer com que outros dados e planos relevantes estejam sempre atualizados. Provê rastreabilidade de requisitos do cliente ao produto e aos componentes de produtos. Como as mudanças em requisitos podem afetar todas as outras áreas da Engenharia, a área de processo de Gerência de Requisitos é uma sequência sequência de



eventos dinâmica e geralmente recursiva.   desenvolvimento  Planejamento de Projeto  (PP - Project Planning): inclui o desenvolvimento de um plano de projeto, o envolvimento dos stakeholders do pro jeto da forma apropriada, obtenção de compromisso com o plano de projeto e manutenção do plano. O planejamento inicia com os requisitos que definem o produto e o projeto. O plano de projeto cobre as diversas atividades de gerenciamento gerenciamento e engenharia

que serão executadas no projeto. Ao definir seu plano específico, um projeto leva em conta outros planos que



também o afetam, tais como planos de avaliação de processos, de avaliação de produto, de gerenciamento de configuração e de análise e medida.    Monitoramento e Controle de Projeto  (PMC - Project Monitoring and Control): inclui o monitoramento de atividades e a tomada de ações corretivas. O plano de projeto especifica o nível apropriado de monitoramento, a frequên-

cia das revisões de progresso e as medidas a serem usadas para monitorar o progresso. Quando o status corrente do processo apresenta diferenças significativas significativas com



relação ao estimado no plano, as ações corretivas apropriadas são tomadas (o que pode incluir replanejamento). Gerência de Acordo com Fornecedor   (SAM - Supplier Agreement Management Management): essa área endereça as necessidades de um projeto de adquirir partes de trabalho produzidas por fornecedores. Uma vez que um componente de produto é identificado e seu fornecedor fornecedor sele-

cionado, um acordo com o fornecedor é estabelecido e mantido.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

56

Esse acordo serve para gerenciar a interação com o fornecedor. O progresso pro gresso e o desempenho do fornecedor são gerenciados. Testes e revisões de aceitação 

são conduzidos no componente adquirido. processo dá  Análise e Medida  ( MA  MA - Measurement and Analysis ): essa área de processo suporte a todas as outras áreas, fornecendo práticas específicas que orientam projetos e organizações no alinhamento das necessidades e objetivos de me-

dição. Isso é feito utilizando-se uma abordagem que forneça resultados objetivamente objetivamente mensuráveis que possam ser usados para a tomada de decisões decisões e de ações cor

retivas apropriadas.  Garantia de Qualidade de Processo e de Produto (PPQA - Process and Product Garantia Quality Assurance): responsável por fornecer práticas específicas para avaliar objetivamente o desempenho de processos, produtos de trabalho e serviços, comparando-os com as correspondentes descrições de processo, padrões e

procedimentos. Caso essa comparação evidencie algum problema, essa área



de processo também é responsável por garantir garantir que esses problemas sejam endereçados. responsável por Gerência de Configuração  Configuração  (CM - Configuration Management): responsável estabelecer e manter a integridade de produtos de trabalho utilizando recursos como identificação de configuração, controle de configuração, relatórios de status de configuração e auditorias. Os produtos de trabalho colocados sob a gerência de configuração incluem produtos que são entregues ao cliente, produtos de trabalho internos selecionados, produtos adquiridos, ferramentas e outros itens utilizados na criação e descrição dos produtos de trabalho mencionados, mencionados, como planos, descrições de processos, requisitos, dados de pro jetos, desenhos desenhos,, especificação especificação de de produtos, produtos, código, código,

compiladores, arquivos arquivos de dados e publicações técnicas sobre produtos. Cada uma das áreas de processo possui metas específicas e define práticas comprovadas para alcançar essas metas. O livro mantém o foco nas áreas de processo de engenharia de requisitos.

Assim, dentre as áreas de processo do nível 2, o interesse está na Gerência de Requisitos, que está descrita em detalhes no capítulo sobre Processos de Práticas da ). Engenharia de Requisitos (seção Engenharia de Requisitos no CMMI ).

Meta Genérica - (GG2) Institucionalizar um Processo Gerenciado Para atingir os requisitos do nível de maturidade 2 do CMMI, ou seja, Proces-

so Gerenciado, todas as áreas de processo da organização têm a meta genérica de institucionalizar um processo gerenciado, referenciado pela sigla GG2 (Generic Goal 2).

 

Modelos de Capacidade e Maturidade (CMMI)

57

Para atingir essa meta genérica, é necessário pôr em prática uma série de ações (práticas genéricas) que resultam na institucionalização do processo. 

As práticas genéricas associadas a essa meta são listadas em seguida:  Estabelecer uma política organizacional: organizacional: aderir a políticas organizacionais.

estabelecidos.  Planejar o processo: seguir processo: seguir descrições de planos e processos estabelecidos. financeiros,   Fornecer recursos: prover recursos adequados (incluindo recursos financeiros, pessoal e ferramentas) para a execução do processo adotado.   Designar responsabilidade: designar responsabilidade e autoridade para executar o processo.   Treinar pessoal: treinar pessoal: treinar o pessoal que executa e dá suporte ao processo. 



Gerenciar configurações: colocar configurações: colocar produtos de trabalho selecionados sob níveis apropriados de gerenciamento de configuração.



 Identificar e envolver stakeholders relevantes: relevantes:   identificar e envolver indivíindiví-





duos-chave para o desenrolar do processo de desenvolvimento.  Monitorar e controlar o processo:  monitorar e controlar o desempenho do

processo, comparando os resultados obtidos com os planejados e tomando tomando ações corretivas quando necessário.  Avaliar aderência objetivamente:  avaliar o processo objetivamente, verificando a aderência de produtos de trabalho e de serviços às descrições de pro-



cesso, objetivos e padrões e resolvendo problemas de não conformidade. conformidade.  revisar as atividades, status  Revisar status com o alto escalão da gerência: gerência: revisar e resultados do processo com o alto escalão de gerenciamento e tomar ações corretivas.

Nível de Maturidade 3: Definido A seguir, estão descritas as características de uma organização com matu-

ridade de nível 3 do CMMI. De acordo com a descrição de nível 3 apresentada anteriormente, organizações neste estágio possuem uma descrição formal de seus processos, que podem ser adaptados por cada projeto que os utiliza.

 Áreas de Processo Organizações com nível de maturidade Definido alcançaram as metas das se-

guintes áreas de processo:   Desenvolvimento de Requisitos  (RD - Requirements Development): identifica Development): identifica necessidades do cliente a as traduz em requisitos do produto. O conjunto de

 

58

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

requisitos do produto é analisado para produzir uma solução solução conceitual de alto nível. Após isso, o conjunto de requisitos é alocado em um conjunto de requisitos requisitos de componentes de produto. Outros requisitos que ajudam a definir o produto são então identificados identifi cados e

também traduzidos em requisitos de componentes de produto.

Os requisitos descrevem o produto em termos de funcionalidade, desempenho, desempenho, características, requisitos de verificação, e outros, de forma que o desenvolve

dor compreenda sua utilização. produto, Solução Técnica  (TS - Technical Solution): parte dos requisitos do produto, identificados pela área de processo de Desenvolvimento de Requisitos, Requi sitos, para convertê-los na arquitetura do produto, no projeto de seus componentes e no próprio componente (através de codificação, fabricação fabricação ou aquisição).

Uma das atividades dessa área é a investigação de soluções alternativas com o objetivo de selecionar o melhor projeto (design ( design)) com base em critérios critérios estabelecidos.



Tais critérios dependem do tipo de produto, ambiente operacional, requisitos de performance e de suporte, e cronogramas de entrega e de liberação de recursos.  Integração do Produto Produto (PI - Product Integration): Integration): a partir dos requisitos do produto, identificados pela área de processo de Desenvolvimento de Requisitos,

e dos componentes em si, gerados pela área de Solução Técnica, combina os componentes e certifica-se de que as interfaces satisfazem os requisitos. Para realizar essa integração, estuda-se a melhor sequência das atividades atividades de 

integração e de entrega do produto para o cliente. Verificação  (VER - Verification Verificação ): assegura que os produtos de trabalho selecioVerification): nados alcançam os requisitos especificados. Inclui a seleção de métodos de verificação e configura um processo incremental, iniciando com a verificação de componentes do produto e culminando na verificação verificação de todos os compo-

nentes e produtos completamente montados montados e integrados. As revisões por pares ( peer  peer reviews), reviews), em que um profissional revisa o trabalho de outro profissional de perfil semelhante, também fazem parte parte dessa área de processo. Esse tipo de verificação é um método comprovado com provado para a remoção 

de defeitos em estágios iniciais do desenvolvimento. desenvolvimento. ): valida o produto, comparando-o às necessidades necessidades Validação (VAL - Validation Validation): do cliente, édeum forma incremental. A coordenação comdeo cliente na validação de requisitos dos elementos essenciais dessa área processo. O escopo da área de processo de Validação inclui a validação de produtos, de componentes de produtos, de produtos de trabalho intermediários inter mediários seleciona-

 

Modelos de Capacidade e Maturidade (CMMI)

59

dos e de processos. Tais validações podem incluir a necessidade de revalidação (e inclusive de reverificação).

Problemas encontrados durante a validação podem incorrer em alterações alterações nas áreas de Desenvolvimento de Requisitos e Solução Técnica. 

 Foco no Processo Organizacional  (OPF - Organizational Process Focus): ajuda a organização a planejar e implementar melhorias de processo organizacional baseado na compreensão de seus atuais pontos fortes e das atuais fraquezas de seus processos e recursos. Há vários meios de identificar possíveis melhorias nos processos organizacionais, tais como propostas de melhoria de processo, medições dos pro-



cessos, lições aprendidas durante a implementação dos processos e resultados de atividades de avaliação deles.  Definição do Processo Organizacional Organizacional  (OPD - Organization Organizational al Process Definition): estabelece e mantém o conjunto de processos padrão e outros itens relevantes relacionados ao processo da organização, tais como descrições e elementos de  guidelines) para processo, descrições de modelos de ciclo de vida, orientações ( guidelines a customização de processos, demais documentações e dados relacionados a processos, experiências relatadas e produtos de trabalho, dados de medição de



processo coletados coletados durante sua execução, artefatos e lições aprendidas. Tais itens são baseados nas necessidades e objetivos do processo organizacional. Treinamento da Organização  (OT - Organizational Training): Training): identifica necessidades de treinamento estratégico da organização e necessidades de treina-

mento comuns em vários projetos e grupos de apoio. Também é organizado treinamento destinado a desenvolver habilidades necessárias necessárias para executar os

processos padrão da organização. Fazem responsabilidades dessa área de processo itens como a definição departe um das programa gerenciado de treinamento e a preparação de pessoal com conhecimento e mecanismos apropriados para medir a efetividade do 

programa de treinamento. Gerência de Riscos (RSKM - Risk Management): Management): embora a identificação e o monitoramento de riscos sejam cobertos nas áreas de processo de Planejamento de Projeto e Controle e Monitoramento de Projeto, a área de processo de Ge-

renciamento de Riscos toma uma abordagem mais contínua e com visão de mais longo prazo para gerenciar riscos com atividades atividades que incluem a identifi-

cação de parâmetros de risco, a estimativa estima tiva e a avaliação de riscos e resolução deles. 

- Decision Analysis and Resolution): Resolution): forne ce um processo  Análise e Resoluçã Resolução de Decisã Decisão o (DARque de oavaliação formal garante a comparação de alternativas em busca da melhor escolha para alcançar os objetivos de todas as outras áreas

de processo.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

60

No contexto de interesse deste trabalho, a área de processo de Desenvolvimento de Requisitos será caracterizada e analisada em detalhes no capítulo sobre Processos de Práticas da Engenharia de Requisitos (seção Engenharia de Requisitos no ). CMMI ).

Meta Genérica - (GG3) Institucionalizar um Processo Gerenciado Uma organização com o processo de desenvolvimento gerenciado adota práticas que estabelecem a descrição de um processo definido para os projetos e unidades organizacionais e mantém uma coleção de produtos de trabalho, medidas e informações para melhoria derivadas do planejamento e execução de um processo definido. As práticas genéricas associadas à meta de Institucionalizar Institucionalizar um Processo

Gerenciado são: 

 elaborar e manter a descrição de um pro Estabelecer um Processo Definido: Definido: elaborar cesso em nível organizacional, que pode ser adaptado em diferentes instâncias, de acordo com características específicas dos projetos. A definição de um processo padrão faz com que os artefatos, os dados e a aprendizagem de um projeto possam ser reutilizados (ainda que parcialmente) em outros projetos e diminui a variação vari ação no desempenho dos projetos.



e xeColetar Informações de Melhoria: os Melhoria: os produtos de trabalho resultantes da execução do processo são armazenados para que possam ser reutilizados reutilizados nos pró-

ximos projetos, tanto na execução como no planejamento de atividades. Acreditamos que o objetivo de apresentar ao leitor os conceitos principais do CMMI tenha sido atingido suficientemente com este capítulo.

Exercícios

1)  Quantos e quais são os níveis CMMI? 2)  Quais são são as áreas de de processo do CMMI? CMMI? 3)  Cite os os tipos de representação representação do CMMI. CMMI. 4)  Quais são as principais disciplinas do CMMI? CMMI? 5)  O que são práticas genéricas no contexto do CMMI? Descreva-as. 6)  O que é Área de Processo Processo (Process Area) no no CMMI? CMMI? 7)  Descreva o Nível Nível de Maturidade 2: Gerenciado.

diferenças entre os níveis 2 e 3 do CMMI? 8)  Quais as principais diferenças

 

4

O Processo Unificado da Rational R ational (RUP)

“Inspiração vem dos outros. Motivação vem de dentro de nós.” (Autor Desconhecido Desconhecido))

O capítulo anterior descreve, em linhas gerais, o modelo de processos do CMMI, estrutura, áreas de processo, níveis de maturidade e metas genéricas. Basicamente, o modelo do CMMI é definido sobre metas genéricas e específicas, que descrevem os objetivos do processo, e práticas recomendadas para al-

cançar cada uma das metas. As metas representam filosofias encontradas em projetos de software  de sucessoftware de so comprovado ao longo do tempo. Quando uma organização decide adotar o modelo de processos do CMMI, ainda assim precisa definir o processo de desenvolvimento a ser utilizado. Ou seja, ao adotar a filosofia pretendida, é preciso organizar as práticas recomendadas, recomendadas, definindo atividades a serem executadas, artefatos a serem gerados e papéis a serem

desempenhados. O CMMI fornece orientação através de metas e práticas, mas o processo define quem faz o que, como e quando. O Processo Unificado da Rational (RUP - Rational Unified Process) pode ser utilizado para suprir esta necessidade de definição do processo de desenvolvimento. O RUP descreve: 

Papéis ou perfis de trabalho que definem quem é responsável por cada tarefa.

  que representam os produtos do processo, o que será gerado durante    Artefatos



o processo de desenvolvimento. 



 Atividades executadas durante o processo de desenvolvimentos, que descrevem como os representantes de cada papel trabalham para atingir os objetivos do projeto e construir o sistema de software. Fluxos de atividades, atividades, que orientam a execução das atividades, definindo quando

esta deve ocorrer.

 

62

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Os elementos descritos são organizados em um  framework de processo de desenvolvimento de software software.. Isso significa que o RUP define um catálogo de elementos de processo que deve ser instanciado.

Figura 4.1: Representação do framework de processo e uma instância.

A instanciação é a escolha dos elementos que serão utilizados para compor o processo de desenvolvimento a ser utilizado em um projeto específico. Essa escolha é feita a partir das características da organização e do projeto em que o processo será utilizado. O RUP foi intencionalmente desenvolvido para uma ampla aplicabilidade, ajustando-se a variações de tamanho do projeto, domínio da aplicação (sistemas de negócio, sistemas técnicos), tecnologia utilizada (linguagens, plataformas) e contexto de negócio (desenvolvimento interno, desenvolvimento de produto, contratos de desenvolvimento). O RUP é baseado em um modelo de processos que, à semelhança do CMMI, reconhece práticas observadas em projetos de sucesso comprovado.

 

O Processo Unificado da Rational R ational (RUP)

63

A identificação dessas práticas é resultado do trabalho feito, por mais de dez anos, pelos consultores da empresa originalmente chamada Rational  Software  Corporation,, agora integrada à IBM formando a IBM Rational. Corporation As seções a seguir descrevem diversos aspectos do RUP, caracterizando sua

metodologia de desenvolvimento.

As principais fontes consultadas para essa caracterização são o livro The Rational Unified Process, An Introduction, escrito por Philippe Kruchten, o arquiteto líder responsável pelo RUP, e a própria ferramenta comercial RUP, em sua

versão de 2001.

Práticas do RUP As práticas recomendadas pelo RUP foram definidas de forma a aumentar as chances de sucesso de um projeto. Durante a definição do processo RUP, foram identificados alguns sintomas comuns e recorrentes da falha de projetos, como entendimento impreciso das necessidades do usuário; falta de habilidade para lidar com mudanças nos requisitos; problemas de integração em módulos do sistema; dificuldade de manutenção e de evolução; descoberta tardia de sérias falhas do projeto; má qualidade qualidade do software; performance inaceitável do software software;; falta de rastreabilidade, no sentido de saber que membros da equipe alteraram que parte do sistema; processo pro cesso de liberação de versões de software não confiável. Com base nos sintomas apresentados, procurou-se descobrir as razões desses problemas, chegando-se à lista de causas a seguir: 

Falta de uma definição formal de um processo de gerenciamento de mudan-



ças; Propagação de mudanças descontrolada;



Comunicação ambígua e imprecisa;



 Arquiteturas não robustas; Arquiteturas



Alta complexidade;



Inconsistências não detectadas em requisitos, no projeto (design)  design) e na imple-

mentação; 

Testes insuficientes do sistema;

 

Controle subjetivo do status do projeto; Falha ao atacar riscos do projeto;



Automação insuficiente.

 

64

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Esta lista representa os principais fatores endereçados pelos autores do RUP com a definição das melhores práticas dessa metodologia. Outras abordagens de desenvolvimento, como o CMMI ou os métodos ágeis, ambos discutidos neste trabalho, são baseadas em conclusões que apresentam apresentam algumas comalguns relaçãopontos à percepção de causas de problemas em projetos, emboradiferenças compartilhem em comum. De qualquer forma, as práticas recomendadas pelo RUP foram identificadas identificadas em um grande número de projetos de sucesso e sua falta foi verificada em um grande número de projetos fracassados.

As práticas são ilustradas na Figura 4.2, e detalhadas a seguir.

Figura 4.2: Práticas de RUP RUP..

Desenvolver Software Iterativamente vida proposto pelo RUP é baseado no modelo em espiral e consiste con siste O ciclo adeconstrução em dividir do software  em iterações, cada uma resultando em uma software em liberação de versão executável do sistema. Essa abordagem resulta em descoberta, criação e implementação contínuas de requisitos.

O desenvolvimento de software  de forma iterativa soluciona ou minimiza vásoftware de rios dos problemas que possam surgir. Os usuários recebem as liberações de versão de cada iteração, o que facilita seu retorno sobre o software  produzido, apontando o que foi mal entendido e esclaresoftware produzido, cendo os demais requisitos.

Além disso, os usuários stakeholders têm evidências concretas do andamento andamento do sistema. As porções do sistema que oferecem maior risco são desenvolvidas primeiramente, e possíveis problemas já podem começar a ser solucionados.

 

65

O Processo Unificado da Rational R ational (RUP)

O status do projeto é determinado objetivamente, analisando os artefatos que foram concluídos até uma determinada data. A carga de trabalho da equipe é distribuída de maneira uniforme ao longo do projeto. Por fim, a equipe pode utilizar as lições aprendidas em cada iteração para

melhorar o processo de desenvolvimento continuamente. O ciclo de vida iterativo do RUP é ilustrado na Figura 4.3.

Figura 4.3: Ciclo de vida do RUP RUP..

Gerenciar os Requisitos A gerência de requisitos é sempre uma atividade desafiadora no desenvolvimento de software software.. Isso ocorre porque os requisitos de um sistema são extremamente dinâmicos, com diversos fatores internos e externos ao projeto, contribuindo para sua alteração constante. Exemplos de fatores de mudança de requisitos são alterações no ambiente de negócio, uma melhor compreensão do sistema pelos desenvolvedores e a observa-

ção do sistema pelos usuários. No RUP, a gerência de requisitos consiste em elicitar, organizar e documentar docu mentar a funcionalidade e as restrições requeridas pelo sistema; avaliar mudan mudanças ças nesses requisitos e estimar seu impacto; e registrar e documentar decisões. Com esta prática, o RUP pretende atacar riscos de projeto utilizando uma abordagem disciplinada para a gerência de requisitos, comunicando esses requisitos claramente aos envolvidos e oferecendo uma forma de priorização, seleção e rastreamento de requisitos.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

66

Usar Arquiteturas Baseadas em Componentes De acordo com os autores do RUP, a arquitetura é um dos produtos de trabalho mais importantes de um sistema, descrevendo a organização do software e a seleção dos elementos estruturais que compõem o sistema; o comportamento, conforme o especificado pela colaboração entreem esses elementos; a composição desses elementos estruturais e comportamentais subsistemas progressiva progressivamente mente maiores. Uma possível abordagem para a composição da arquitetura arquite tura de um sistema é o desenvolvimento baseado em componentes. Nessa abordagem, o sistema é organizado em módulos coesos e fracamente acoplados uns aos outros, e então são estudadas possibilidades de aquisição de

cada um desses módulos. Cada módulo do sistema pode ser adquirido de um fabricante, desenvolvido desenvolvido pela equipe ou reutilizado de outros projetos (com maior ou menor esforço de adaptação). Os objetivos do desenvolvimento de uma arquitetura baseada em componentes são: promover a criação de arquiteturas estáveis e robustas, através de utilização de componentes cuja qualidade é comprovada por sua utilização em outros sistemas; dividir o sistema em módulos de forma que sua evolução possa ser feita de forma isolada (alterações (al terações em um módulo não precisarão envolver todo o sistema); facilitar o reúso; facilitar a gerência de configuração.

Modelar Software Visualmente Um modelo é uma simplificação da realidade que descreve um sistema de

acordo com uma perspectiva particular. Modelos são usados para compreender melhor um problema ou uma solução, para comunicar uma ideia, para descrever uma abordagem ou alternativas alternativas de resolução de questões relacionadas ao sistema; para documentar essas alternativas

ou a decisão tomada em prol de uma das alternativas. Todas essas abstrações do sistema permitem que a equipe de desenvolvimento desenvolvimento construa o sistema por partes, mantendo o foco na perspectiva que está sendo ana-

lisada. Assim, a modelagem melhora a habilidade da equipe de gerenciar a complexidade do software.

Através da visualização dos modelos, comportamentos do sistema podem ser descritos de forma não ambígua, detalhes podem ser abstraídos quando necessário, inconsistências e problemas de arquitetura podem ser encontrados mais facilmente (em oposição à análise de código ou de descrições textuais).

 

O Processo Unificado da Rational R ational (RUP)

67

 Verificar  Veri ficar a Qualidade do Software Software Continuamente

Como o software é desenvolvido iterativamente no RUP, ele pode ser verificado constantemente. A verificação se dá por meio de testes em cenários de uti-

lização do sistema. Desta forma, é um processo contínuo de avaliação qualitativa (testes executados com sucesso) e quantitativa (número de testes realizados, número de cenários ainda não testados, número de testes cujo resultado foi bem-sucedido etc.). A verificação contínua de qualidade faz com que o acompanhamento do status do projeto seja mais objetivo, as inconsistências em requisitos, projeto e implementações sejam evidenciadas, os riscos mitigados, os defeitos encontrados precoce-

mente. Controlar as Mudanças no Software A principal motivação para esta prática é a crença em que ““manter manter a rastreabilidade entre os elementos de cada versão liberada e entre os elementos ao longo de liberações múltiplas e paralelas é essencial para avaliar e gerenciar ativamente o impacto de mudanças”. Embora esta crença seja questionada pelos métodos ágeis, descritos mais adiante neste trabalho, é certo que as alterações realizadas em um sistema precisam ser organizadas de alguma forma, utilizando critérios para originar essas mudanças, priorizá-las, escolher seu momento de implantação e avaliar os resultados resultados

de cada mudança. O controle de mudanças em RUP fornece uma sequência de atividades claramente descritas e padronizadas para execuções repetidas. São definidas as Requisições de Mudança (Change (Change Requests), Requests), documentos des-

crevendo criteriosamente as mudanças.

A propagação de mudanças é controlada pelo processo e é passível de verificação.

Características do RUP Além das práticas apresentadas anteriormente, o RUP tem ainda três características que norteiam sua utilização: 

É um processo de desenvolvimento orientado a casos de uso.



um framework de processo que pode ser adaptado e estendido pela or  Define um framework ganização que o adota.



Utiliza largamente o suporte de ferramentas automatizadas.

 

68

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 Casos de uso são cenários de utilização do sistema por usuários. Sua principal Casos meta, no contexto do RUP, é a de caracterizar um fluxo de execução do sistema. O conceito de casos de uso é utilizado pelo RUP para organizar o desenvolvimento do sistema, sendo refletido em diversas atividades e artefatos. Conforme explicado anteriormente, o fato de ser um  framework de processo adaptável faz com que o RUP possa ser utilizado de formas diferentes, de acordo com fatores como a organização que o adota, o tamanho do projeto, a necessidade neces sidade de integração com outros sistemas internos ou externos à organização etc. As possibilidades de configuração do RUP são modificações, customizações, customi zações, adições ou exclusões em artefatos, atividades, papéis e fluxos de execução execu ção de atividades, assim como manuais de orientação e modelos de artefatos, Figura 4.1. O suporte de ferramentas automatizadas do RUP é muito extenso, o que é esperado, já que esta é uma metodologia criada comercialmente, por uma empresa empresa interessada em difundir suas ferramentas de suporte ao desenvolvimento de pro jetos de software. O próprio framework do RUP é documentado como um produto comercial, representado por uma base de conhecimento disponível via navegador navega dor web. As ferramentas têm o objetivo de aumentar a produtividade em cada atividade atividade do processo e de facilitar as práticas do RUP. As práticas e características apresentadas servem como base de fundamentação do framework  de processo do RUP, cuja estrutura é descrita a seguir.  framework de

Figura 4.4: Estrutura de processo do RUP. RUP.

 

69

O Processo Unificado da Rational R ational (RUP)

Estrutura do RUP A Figura 4.4 ilustrou a estrutura do RUP. O processo possui duas dimensões, sendo o eixo horizontal, que representa os aspectos dinâmicos do processo, e o eixo vertical, que representa os aspectos

estáticos. A parte dinâmica diz respeito à evolução do projeto ao longo do tempo, é dividida em fases e iterações e planejada de acordo com cada projeto específico. A parte estática descreve as disciplinas do processo, que agrupam atividades atividades logicamente de acordo com sua natureza; é a parte do processo que descreve quem faz o que, como e quando isso é feito. Os gráficos, no centro, representam a carga de trabalho estimada para cada

disciplina.  Aspectos Estáticos

Com relação ao processo estático do RUP, seus componentes são descritos da seguinte forma:

Figura 4.5: Componentes estáticos do RUP.

  : a descrição do comportamento e das responsabilidades de um indiví   Papéis:  Papéis



duo ou grupo de indivíduos trabalhando juntos em uma equipe de desenvol-

vimento.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

70

O comportamento é definido em termos de atividades que o papel executa, executa, e cada papel é associado a um conjunto de atividades coesas. As responsabilidades de um papel são definidas em relação aos artefatos artefatos que devem ser criados, modificados ou controlados. Uma mesma pessoa pode desem-

penhar vários papéis ao longo do projeto.

Exemplos de papéis são o Analista o  Analista de Sistemas , o Projetista, o Projetista de Teste 

etc. 

  Artefatos Artefatos:: um artefato é uma porção de informação que é produzida, modifi-

cada ou utilizada por um processo. Artefatos são os produtos tangíveis de um projeto, como as coisas que o pro jeto produz ou usa enquanto trabalha rumo ao produto final. Artefa Artefatos tos são usados como entrada por indivíduos que desempenham papéis para executar

uma atividade. São usados também como saídas (resultados) de atividades. Podem ser modelos, como, por exemplo, diagramas de classe, elementos de modelos mode los como as próprias classes, documentos, código-fonte, código executável. execu tável. Artefatos também podem ser compostos por outros artefatos. 

  Atividades Atividades:: definem o trabalho a ser executado por cada pessoa que produz um resultado significativo no contexto do projeto. Cada atividade é associada a um papel específico. A atividade tem um propósito claro, e geralmente inclui criar ou atualizar artefatos. Exemplos Exem plos de atividades são o Planejamento de uma Iteração (Papel: Gerente de Projeto), Projeto), Encontrar Casos de Uso e Atores (Papel: Analista de Sistema), Sistema), Revi Revisar sar o Projeto (Papel: Revisor de Projeto) Projeto) etc.  plinas do Atividades relacionadas entre siasão agrupadas em Disci plinas processo deintimamente desenvolvimento, por exemplo, disciplina de Requisitos .



atividades que   Fluxos de Execução de Atividades Atividades  (Workflows):  Workflows): sequências de atividades produzem resultados de valor observável. São representadas como diagramas de atividades. Um exemplo é exibido exibido na Figura 4.6. Cada disciplina do RUP descreve um fluxo de execução de atividades.

 

O Processo Unificado da Rational R ational (RUP)

71

Figura 4.6: Fluxo de atividades da disciplina de requisitos.

 Aspectos Dinâmicos Os aspectos dinâmicos do RUP, definidos de acordo com as características e necessidades de cada projeto, são fases, iterações e marcos (milestones). A ideia por trás das iterações é a seguinte: dividir a construção de um grande sistema em um conjunto de sistemas menores, cuja complexidade será menor, o controle e a gerência de riscos facilitados, o feedback dos stakeholders  e desenvolstakeholders e vedores recebido a tempo de gerar alterações no planejamento que garantam garantam o sucesso do projeto. Cada iteração do projeto inclui atividades de análise de requisitos, projeto (são d design), geração e uma versão do sistema, mesmo que essa ver  esign), aindaimplementação seja incipiente ee incompleta.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

72

Para organizar e orientar as iterações de forma a assegurar convergência para o sistema final resultante, o RUP define os marcos do ciclo de vida do projeto. Os marcos são pontos ao longo do desenvolvimento do sistema que possuem pos suem um objetivo definido que aproxima o sistema em desenvolvimento de sua finali-

zação.

São intimamente relacionados às fases do processo, listadas a seguir:



Iniciação  Iniciação ou Concepção ( Inception  Inception): durante essa fase, é definida a visão geral

do produto a ser desenvolvido; a principal preocupação é uma compreensão abrangente dos requisitos do sistema e a determinação determi nação do escopo do projeto. A Iniciação termina quando o marco de Objetivo do Ciclo de Vida é alcançado: os stakeholders concordam com uma definição de escopo para o projeto, e com as estimativas de custo e prazo; os requisitos estão compreendidos e documentados; existe credibilidade credibilidade quanto às estimativas de custo e prazo, e quanto a 

prioridades, riscos e o processo de desenvolvimento.   ( Elaboration):  Elaboração  Elaboration): o foco dessa fase engloba três aspectos, sendo o planejamento das atividades e recursos necessários ao projeto, a especificação detalhada dos requisitos e o projeto da arquitetura do sistema. As atividades de geração de código desta fase são voltadas à criação de um protótipo da arquitetura, à mitigação de riscos técnicos através da experimentação de possíveis soluções e ao treinamento em ferramentas e técnicas específicas. O marco que sinaliza a finalização da Elaboração é a  Arquitetura do Ciclo de pro duto, e a conVida,, que garante a estabilidade da visão e da arquitetura do produto, Vida cordância dos envolvidos quanto aos planos para a entrega do sistema.



Construção  C onstrução (Construction): é responsável pela evolução do sistema e de sua arquitetura, até que o sistema esteja pronto para entrega à comunidade comuni dade de usuários. As principais preocupações são o projeto (design) d  esign) e a implementação

do sistema.

O marco final da Construção é a Capacidade Operacional Inicial, Inicial, atingido quando há uma versão estável e madura para entrega e quando os stakeholders estão prontos para a execução dessa entrega. 

 Transição (Transition): nessa fase, o sistema é repassado a seus usuários. Transição usuá rios. São treinamen to, suporte e resolvidas as questões de empacotamento, entrega, treinamento, manutenção.

A conclusão da Transição se dá quando o marco da Liberação do Produto (Product Release) Release) é alcançado, o que significa que o cliente está satisfeito com o sis-

tema entregue.

Dentro de cada fase, são definidas uma ou mais iterações. O foco das atividades atividades executadas dentro de cada iteração varia de acordo com os objetivos da fase.

 

O Processo Unificado da Rational R ational (RUP)

73

Customização do RUP O RUP define quatro fases, nove disciplinas, mais de 40 papéis e mais de 100 artefatos; o produto comercial RUP possui mais de mil páginas de orientação. orien tação. Além disso, ainda é possível encontrar processos para adicionar funcionalidades funcionalidades e conteúdo à versão padrão. Com toda esta bagagem, RUP é considerado por muitos como muito pesado (heavyweight heavyweight)) já que ele prescreve muitas atividades e artefatos a ser desenvolvidos

ao longo do processo.

O RUP disponibiliza um mecanismo de configuração de processo cujo objetivo é justamente definir o subconjunto de artefatos, papéis e atividades que realmente

são necessários. Na própria definição do RUP (IBM, 2003), menciona-se que nenhum projeto proje to pode, por si só, beneficiar-se da utilização do do framework  RUP completo.  framework RUP A utilização de todos os papéis, artefatos, atividades e orientações do RUP padrão em um único projeto provavelmente resultaria em um ambiente de desenvolvimento ineficiente, em que seria difícil manter o foco nas atividades e artefatos

mais importantes. O RUP pode ser modificado de forma a melhor atender às necessidades do projeto ou da organização que o adota. Essa adaptação pode ser feita em dois níveis: 

Nível de organização aplica ções, organização:: considerando questões como domínio de aplicações, práticas de reúso e tecnologias dominadas pela organização, o RUP é modificado e configurado levando em conta processos utilizados por toda a organi-

zação. 

Nível de  projeto tamanho,  projeto:: mantendo o foco em um projeto específico, seu tamanho, possibilidades de reúso a partir de repositórios da organização, o fato de ser um projeto novo ou uma nova versão de um sistema já construído, construído, a instância do RUP adotada pela organização é refinada para o projeto.

De acordo com a literatura, o RUP pode sofrer três tipos de adaptação, sendo envolvem uma extensão, configuração ou instanciação instanciação.. A extensão e a configuração envolvem modificação do processo padrão. Estender o RUP significa adicionar pontos ao processo que enderecem necessidades específicas do projeto ou da organização que não são tratadas a contento pelo RUP padrão. Configurar o RUP envolve tomar decisões como a seleção de componentes relevantes do processo, a eliminação de elementos desnecessários, a definição de

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

74

recursos para a geração de artefatos pela organização e a definição de visões diferentes do processo para cada equipe envolvida no processo.

Instanciar o RUP significa definir um processo, a partir do framework do  framework RUP,  RUP, a ser utilizado em determinada organização ou em determinado projeto, definindo os serãode produzidos, coletandoetc. e customizando orientações, orientações, definindo artefatos o modeloque de ciclo vida a ser utilizado Neste livro, o termo instância do RUP será utilizado para se referir a um modelo do RUP estendido, configurado e instanciado conforme as necessidades da

organização.

Exercícios 1)  Quais são os elementos descritos pelo RUP? 2)  Quais são as principais práticas do RUP? 3)  O que significa desenvolver software  iterativamente? software iterativamente? 4)  Quais são as fases do RUP? 5)  Cite as disciplinas do RUP. 6)  O que é um artefato para o contexto do RUP? 7)  Defina a fase de transição do RUP. 8)  A análise e o levantamento de requisitos são realizados em qual fase? 9)  Quantos papéis existem no RUP?

 

Métodos Ágeis

5

“Nunca é tarde para tentar o desconhecido. Nunca é tarde  para ir mais mais além.” (Gabriele D Annunzio)

Até agora, foram apresentados dois enfoques utilizados como fundamentação fundamentação teórica na definição do processo de engenharia de requisitos proposto neste trabalho, CMMI, um modelo paraemelhoria processos de metas esendo práticas de desenvolvimento, RUP, um framework umde  de descrito processoatravés de desen framework de volvimento que contém orientações sobre aspectos dinâmicos (iterações, fases e marcos) e aspectos estáticos (atividades, artefatos, papéis e fluxos de atividades) de um projeto. O terceiro enfoque estudado neste trabalho são os métodos ágeis, uma série de enfoques de desenvolvimento de software  que possuem, como uma de suas princisoftware que pais características, a possibilidade de flexibilizar a delimitação de escopo de pro jetos de software software,, abrindo mão da definição e documentação do conjunto completo de requisitos do sistema em uma etapa inicial do projeto. A motivação para o desenvolvimento dos métodos ágeis é a realidade de negócios do século 21, caracterizada pela globalização, por um grande número de fusões e aquisições, e por um ambiente com mudanças frequentes em objetivos, objeti vos, mercados e estrutura das organizações, além do panorama tecnológico, em constante e acelerada evolução. O cenário descrito evidencia problemas nos processos de desenvolvimento de  cuja premissa é a de que os requisitos do sistema podem ser definidos em software cuja software uma etapa prévia à sua construção. Esse tipo de processo de desenvolvimento tende a trabalhar com requisitos e planos desatualizados, mesmo em pequenos espaços de tempo. Há, ainda, a questão de requisitos desconhecidos por todos os interessados no projeto pela ignorância das implicações das novas tecnologias e da aplicação sendo construída sobre estas. Exemplos deste cenário são aplicações de voz sobre IP, gerência de redes convergentes de dados, voz e imagens, aplicações convergentes de telefones móveis,

 

76

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

integração de sistemas de Enterprise Resource Planning (ERP) a sistemas legados de grandes corporações etc. Exemplos dos métodos, criados a partir da metade da década de 1990, são (WILLIAMS; COCKBURN, 2003): Método Dinâmico de Desenvolvimento de Sistemas (DSDM - Dynamic Systems Method) (DSDM 2005), Desenvolvimento GuiadoDevelopment por Funcionalidade (FDD - CONSORTIUM, Feature-Driven Development) (PALMER; FELSING, 2002), Extreme Programming (XP) (BECK, 2000), Crystal (COCKBURN, 2004), Desenvolvimento de Software  Adaptativo (AdapSoftware Adaptativo tive Software Development) (HIGHSMITH, 1999) e SCRUM (SCHWABER, 2004). Os criadores dos métodos ágeis debateram os princípios que utilizaram na definição de seus processos e perceberam que todos partiram de uma base comum co mum de ideias. Então, formalizaram essas ideias no Manifesto pelo Desenvolvimento Ágil de Software.. Software

O Manifesto pelo Desenvolvimento Ágil de Software O Manifesto for Agile Software Development, ou simplesmente Manifesto Ágil, formaliza os princípios básicos que dão suporte aos métodos ágeis de desenvolvimento de software software.. O termo ágil (agile) foi adotado pelos criadores desses métodos, que q ue formaram formaram a Aliança Ágil (Agile Alliance), e disponibilizaram suas ideias, bem como diversos recursos relacionados a elas, em um web site (AGILE ALLIANCE, 2005). O Manifesto Ágil resume-se às linhas do quadro apresentado em seguida: MANIFESTO PELO DESENVOLVIMENTO ÁGIL DE SOFTWARE Nós estamos descobrindo melhores formas de desenvolver software enquan-

to o fazemos e enquanto ajudamos os outros a fazê-lo. Através deste trabalho nós viemos a valorizar: Indivíduos e interações sobre processos e ferramentas

Software funcionando sobre documentação abrangente Colaboração do cliente sobre negociação contratual Responder a mudanças sobre seguir um plano 

seja, embora haja valor nos itens à direita, nós damos mais valor aos itensOu à esquerda. Os princípios fundamentais que dão suporte aos métodos ágeis, também

publicados, publi cados, são os seguintes:

 

Métodos Ágeis

77

1. A maior prioridade é satisfazer o cliente através da entrega pronta pronta e contínua de software  com valor agregado. software com 2. Receba bem as as alterações alterações em requisitos, mesmo tarde no desenvolvimento. Processos ágeis suportam mudanças para a vantagem competitiva do cliente. Responder a mudanças mais do que seguir um plano. Rápida adaptação às mudanças. 3. Entregue software  funcionando frequentemente, de algumas semanas a alsoftware funcionando guns poucos meses, com preferência para a escala de tempo mais curta.  curta.  4. Interessados na aplicação (stakeholders (stakeholders)) e desenvolvedores devem trabalhar  juntos diariamente ao longo do projeto. Cooperação constante entre pessoas que entendem do ‘negócio’ e desenvolvedores. 5. Construa projetos ao redor de indivíduos indivíduos motivados. motivados. Dê a eles o ambiente e o suporte que eles precisam, e confie neles para que façam o serviço. 6. um O método eficiente e eficaz conduzir informações para e dentro de time demais desenvolvimento é a de comunicação face a face. Indivíduos e interações mais do que processos e ferramentas ferra mentas.  funcionando é a medida principal de progresso. 7. Software Software funcionando 8. Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Colaboração com clientes mais do que negociação de contratos. 9. Atenção contínua à excelê excelência ncia técnica e ao bom projeto aumenta a agilida agilidade. de. 10. Simplicidade - a arte de maximizar a quantidade de trabalho não não realizado - é essencial. 11. As melhores arquiteturas, requisitos e projetos surgem de times auto-orgaauto-organizados. 12. Em intervalos regulares, o time reflete sobre como pode ser tornar mais eficaz, então melhora e ajusta seu comportamento de acordo com isso. Os valores e princípios do Manifesto Ágil são a fundamentação dos métodos méto dos ágeis. Nas próximas páginas são brevemente descritos dois desses métodos, sendo Extreme Programming (XP) e Modelagem Ágil (AM - Agile Modeling). O objetivo da descrição desses métodos é exemplificar a utilização das práticas práticas e princípios ágeis em processos de desenvolvimento de software software.. A Modelagem Ágil, especificamente, discute diversas práticas que podem ser

empregadas no processo de engenharia de requisitos proposto neste trabalho.  

78

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Extreme Programming (XP) Extreme Programming (XP), ou Programação Extrema, é um método ágil para desenvolvimento de software software,, caracterizado por:  Iterações curtas, com entrega de software  aos usuários, cuja avaliação do sistesoftware aos ma e necessidades de negócio são usadas como entrada para o planejamento pla nejamento da iteração seguinte. Flexibilidade e habilidade para acomodar mudanças de negócio; utilização utilização de   testes automatizados para monitorar o progresso do sistema.  Foco na comunicação entre todos os envolvidos no projeto.  Constante evolução da arquitetura ao longo do desenvolvimento do sistema. Assim como outras iniciativas de desenvolvimento de software  ágil, XP baseiasoftware ágil, -se em um conjunto sucinto de valores, princípios e práticas fundamentais que orientam as atividades realizadas durante o desenvolvimento. “Inicia-seconcretos com um Scott Ambler descreve abordagem seguinte forma: conjunto de valores de altoessa nível, define-seda uma coleção de princípios baseados nesses valores, e então formulam-se práticas para esses valores e princípios que devem ser aplicadas no trabalho”. Uma das razões pelas quais XP tem despertado grande atenção ultimamente ultimamente é a associação feita entre seu nome, Programação Extrema, e o desenvolvimento desenvolvi mento de  sem planejamento e sem preocupações com projeto (design) (design) de software software sem software software..  Na verdade, esta é uma associação errônea. A palavra “Extrema” se refere à utilização dos princípios e práticas de XP em níveis extremos e não à atividade específica da programação.

Osdescrição valores, princípios e práticas de XP sãoeste apresentados breve das atividades que integram método. a seguir, seguidos de A principal fonte de informação utilizada é o livro Extreme Programming Explained, do criador de XP, Kent.

 Valores  V alores de XP Os valores são conceitos básicos que orientam o método a ser seguido; resumem a filosofia de trabalho e a orientação a ser utilizada na tomada de decisões. O XP possui quatro valores:  interessados Comunicação:: o andamento do projeto é comunicado a todos os interessados Comunicação constantemente. Os primeiros sinais de problemas são repassados repassados a todos, assim como as dúvidas e preocupações. O conhecimento do sistema cresce con juntamente com a interação de todos os integran integrantes tes da equipe (desenvolvedo-

res e clientes).

 

Métodos Ágeis

 



79

“coisa mais simSimplicidade: há uma preocupação extrema com a procura da “coisa Simplicidade: ”. Especificações e código complexos são desencoraja ples que possa funcionar ”. dos, na busca por soluções de fácil entendimento, implementação implementação e manutenção.





 possível. Quando  não (Feedback ): todas as teorias sãouma testadas tãocação cedosem quanto  Retroalimentação  Retroalimentação  Feedback): se pode mais compreender especificação especifi implementá-la, parte-se para o código. Quando a implementação implementação de uma funcionalidade requisitada pelo usuário é terminada, o usuário usuário deve validá-la. Estas estratégias são utilizadas para garantir que o projeto caminhe sempre para o ponto esperado por todos. Coragem:: práticas ágeis de desenvolvimento de software são inovadoras e reCoragem querem alta confiança no processo para ser empregadas corretamente. corretamente. O valor da coragem representa o compromisso necessário com o método para aplicá-lo nos diversos cenários do cotidiano. Esses valores básicos são utilizados para definir os princípios de conduta a se-

rem adotados pelo método de XP.

Princípios de XP Com base nos valores, são definidos princípios concretos de XP que ajudam no momento de tomar decisões entre abordagens alternativas. Se existem duas soluções possíveis para um problema, escolhe-se a que melhor preserva os princípios envolvidos. 







Os princípios básicos de XP são:  Retroalimentação rápida (rapid feedback): feedback): quanto mais cedo se obtém o retorno sobre algo que foi feito, melhor se avalia se o resultado obtido foi satisfatório. Assim, quanto mais rápida for a retroalimentação, mais efetivo será o aprendizado. pos sível  Assumir simplicidade simplicidade:: deve-se procurar pela solução mais simples possível para cada problema. Projetos simples são mais fáceis de implementar implementar e podem ser alterados em caso de necessidade.   implemen tadas rapi Mudanças incrementais:: pequenas mudanças podem ser implementadas incrementais damente e com baixo risco. Problemas advindos de mudanças pequenas são encontrados com facilidade quando a alteração é limitada. limita da. Mudanças, em XP, são feitas aos poucos, em uma série de pequenos esforços.  Mudanças são bem-vindas bem-vindas:: durante o desenvolvimento de software software,, diversas mudanças ocorrem em vários âmbitos. A forma mais produtiva produ tiva de trabalhar nesse ambiente dinâmico é encarar as mudanças como bem-vindas e incorporá-las ao processo de desenvolvimento.

 

80

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Trabalho de qualidade: qualidade: esse princípio tem efeito em praticamente todas as atividades realizadas em um projeto de software software.. A qualidade do código produzido facilita seu entendimento, teste e manutenção. O trabalho trabalho de qualidade contribui, ainda, com o bem-estar da equipe, melho mel horando rando sua produtividade e sua satisfação com o processo. Além dos princípios listados anteriormente, existem princípios complemencomple mentares de XP, que ajudam na orientação a ser seguida durante as atividades do processo de desenvolvimento:   Ensinar a aprender : em vez de definir as ações a serem tomadas em cada situação do projeto, XP promove o ensino de estratégias de decisão, decisão, a partir dos valores, princípios e práticas do método.   Investimento inicial pequeno pequeno:: iniciando com um pequeno investimento (por exemplo: poucos membros na equipe, apenas as ferramentas e máquinas necessárias para a primeira liberação), pode-se manter o foco do projeto mais definido, sem maiores necessidades de gerenciamento.  









desenvolvimento,  Jogar para vencer : quando se está confiante no processo de desenvolvimento, todas as atividades são feitas da forma correta, sem a queima de etapas como testes ou preocupação com qualidade para cumprir as metas metas estipuladas. principalmente pela  Experimentos concretos: concretos: a experimentação, representada principalmente implementação e pelo teste, diminui consideravelmente o risco de calcar o projeto em premissas falsas. Comunicação aberta e honesta: honesta: a comunicação é sempre incentivada, seja para informar novas funcionalidades necessárias, seja para relatar que um prazo não será cumprido, seja para expressar suspeitas de que certa porção de código foi escrita de forma que resultará em problemas futuros.



Trabalhar com os instintos das pessoas , não contra eles: eles: os interesses de longo prazo do projeto são traduzidos em interesses de curto prazo para os desenvolvedores. A comunicação de requisitos, por exemplo, é feita através do planejamento, dos testes de aceitação, da conversação informal com o cliente, que são recursos utilizados instintivamente, e não através de extensa documentação.   Responsabilidade   identificadas e lisaceita: as tarefas a serem executadas são identificadas aceita: tadas, e cada membro da equipe requisita suas próprias tarefas, ficando responsável por sua estimativa de esforço. e sforço.   Adaptação local: processo de local: cada organização tem sua própria cultura, e um processo



desenvolvimento que se insira nessa cultura local deve ser criado para seus projetos. Carregar pouca bagagem (travel bagagem (travel light): light): os artefatos do projeto devem ser pou-

cos, simples e importantes.

 

Métodos Ágeis

81

Alguns documentos podem ser criados apenas para compreender ou comunicar um problema ou solução, e podem ser descartados após cumprirem seu propósito.   Medidas honestas: honestas: estimativas são baseadas em experiências prévias e em explorações feitas com protótipos. O cronograma pode não ser exato, mas deve conter valores com embasa embasamento mento concreto e não palpites ou prazos resultantes de determinações externas ao projeto. Com esses princípios em mente, definem-se as ações a serem postas em prática durante o desenvolvimento.

Práticas de XP Com base nos princípios descritos anteriormente, são criadas práticas, hábitos que devem ser exercitados durante o desenvolvimento de software  em XP: software em  O Jogo do Planejamento (The Planejamento (The Planning Game): Game): é a principal forma de gerência de XP, e define regras sobre como fazer o planejamento do projeto. As regras permitem dois tipos de decisão: a equipe técnica determina a complexidade das funcionalidades requisitadas para o sistema e estima seu custo (em termos de tempo de desenvolvimento); já a equipe de negócio, ou seja, o cliente, decide quais são as necessidades do negócio em termos de escopo, prioridade prio ridade e datas de entrega de versões.  Pequenas Liberações: cada liberação de versão tem o menor escopo possível que resolva um conjunto relevante de requisitos de negócio. A primeira versão do sistema deve conter apenas suas principais funcionalidades. Após essa, as próximas versões agregam valor ao sistema em ciclos tão curtos quanto possível.  Metáfora: todo o desenvolvimento é guiado por uma metáfora, uma história que explica como o sistema funciona. O objetivo da metáfora é servir como orientação para decisões arquiteturais arquite turais sem a necessidade de uma documentação extensa e custosa dessas decisões.  Projeto  Simples: uma inovação de XP com relação a outras abordagens de desenvolvimento de software  é uma busca pelo projeto mais simples possível. software é Para que o sistema evolua quando necessário, é colocada em prática a refatoração, descrita a seguir. 

Teste: para assegurar a correção do sistema, programadores escrevem testes unitários continuamente. Um desenvolvedor só implementa a próxima funcionalidade quando todos os testes executarem sem erros para o que acabou de ser desenvolvido. desen volvido.

 

82













 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Clientes escrevem testes funcionais para confirmar que requisitos do sistema foram satisfeitos.  Refatoração ( Refactoring  Refatoração  Refactoring ): uma das práticas de XP é o projeto simples. Essa prática mantém o foco das atividades de projeto (design) (design) nas funcionalidades de cada versão do sistema, sem prever possíveis necessidades necessidades futuras. Quando as funcionalidades de uma determinada versão evidenciam que o projeto deveria ter sido mais elaborado, esse projeto deve evoluir. A evolução controlada do projeto do sistema, adicionando flexibilidade sem alterar o comportamento corrente, é chamada de refatoração refatoração.. Programação em Pares: o código é produzido por pares de programadores, programadores, cada par utilizando uma mesma máquina. Cada par tem dois papéis; um programador escreve o código e o outro observa a linha de programação adotada, avaliando o projeto escolhido, imaginando que outros testes poderiam ser construídos etc. Os programadores alternam os papéis constantemente. Os pares também tam bém são alterados de forma bastante dinâmica. Propriedade Coletiva do Código-Fonte: “qualquer um pode alterar qualquer parte do código a qualquer momento”. Essa prática apoia-se firmemente em outras como os testes automáticos, a integração contínua e a utilização de padrões de codificação, que tornam seguro o fato de um programador alterar código que não foi criado por ele. Integração Contínua: o sistema é integrado várias vezes ao dia, após a conclusão de cada tarefa. Após integrar seu código recém-terminado ao restante do sistema, o desenvolvedor executa os testes automáticos. Se algum problema for sinalizado, o programador o corrige antes de passar à próxima tarefa. Semana de 40 horas: estar bem-disposto influi diretamente na capacidade capaci dade de trabalho, produtividade e criatividade de cada um. XP aconselha aconse lha que se procure não extrapolar o limite de carga de trabalho, embora admita que uma quebra desta regra pode ser necessária uma vez ou outra (nunca por mais de uma semana seguida). Cliente Presente: um cliente do sistema faz parte da equipe e pode ser consultado a qualquer momento. Esse cliente utilizará o sistema quando estiver pronto e deve estar preparado preparado para tomar decisões sobre funcionalidades, para escolher entre possíveis estratégias de apresentação das funcionalidades, ou para priorizar priorizar necessidades. Essa prática procura reduzir um dos riscos clássicos de projetos, o de não sa-

tisfazer as necessidades de seus usuários.

 

Métodos Ágeis

83

  Padrões de Codificação: além de ser uma boa prática de programação, a utili-



zação de padrões fornece uma identidade comum ao código, favorecendo práticas como a posse coletiva, a comunicação através do código e a refatoração. As práticas complementam e promovem umas às outras, compensando desvantagens que cada prática isolada pode trazer.

 Atividades de XP  Juntamente com as práticas, as atividades definem como se dará o desenvolvimento do software software.. Diferente de metodologias tradicionais, XP não define um conjunto amplo de atividades, papéis, artefatos, pontos de sincronização, entradas e saídas. Mantendo o valor da simplicidade, apenas estas quatro atividades são definidas, sem orientações sobre seu encadeamento durante o processo de desenvolvimento:    odificar: além de ser o objetivo principal em um projeto de desenvolvimento C Codificar desenvolvimento de software enten der, aprender, software,, o código é também uma excelente forma de entender, comunicar e testar. A possível solução de um problema pode ser compreendida implementandoimplemen tando-se algumas versões de código dessa solução. Uma maneira de explicar uma ideia aos outros é mostrar como o código se pareceria.





Para atestar a correção de uma funcionalidade, pode-se implementar testes automáticos que a comprovem. Testar: os testes são criados principalmente para comprovar que o código código construído está correto. Porém, há muitos outros benefícios que podem ser obtidos em função da construção dos testes. Construir os testes antes da implementação dá ao desenvolvedor uma ideia geral do que deve ser construído; um sistema que possui testes automáticos pode ser alterado sem que isso gere ge re insegurança, já que basta comprovar que os testes continuam indicando uma execução correta para saber que as alterações foram bem-sucedidas. Após algum tempo cultivando o hábito de criação extensiva de testes, a produtividade de um desenvolvedor acaba aumentando, já que o tempo tempo de correção (e identificação) de defeitos diminui. Ouvir: para que se tenha certeza de que o software  produzido atende às necessoftware produzido sidades, é preciso ouvir o que seus usuários têm a dizer. Sendo assim, essa atividade encoraja a compreensão das necessidades do cliente, bem como o retorno dado por ele ao avaliar cada funcionalidade funcionalidade de-

senvolvida no sistema.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

84

  Projetar ( Designing   Designing ):



essa atividade tem o objetivo de organizar a lógica lógi ca do sistema de forma que este se torne estável e flexível. Utilizar boas práticas de projeto é a única forma de garantir que o software pode evoluir sem causar sérios efeitos colaterais.

Resumo do Método XP A figura a seguir resume os valores, princípios, práticas e atividades de XP.

Figura 5.1: Valores, princípios, práticas e atividades do XP.

 

Métodos Ágeis

85

Modelagem Ágil A Modelagem Ágil é uma abordagem de desenvolvimento baseada em práticas para a modelagem e documentação efetiva de sistemas de software  calcada da nos software calca princípios promovidos pela Aliança Ágil. Segundo Ambler (2002), modelos são utilizados para dois fins, sendo para entender e desenvolver conhecimento mais amplo sobre determinado problema ou solução e para comunicar esse entendimento a outros. A proposta da Modelagem Ágil é definir práticas e orientações para mode modelar lar de forma eficaz e eficiente, com os seguintes objetivos:  Definir e orientar a utilização de valores, princípios e práticas para modelagem eficaz e leve (lightweight técni cas de modelightweight).). A inovação não estaria nas técnicas lagem, já que estas já são utilizadas por diversos outros métodos, mas sim na forma de aplicá-las.  Tratar o problema da aplicação de técnicas de modelagem em projetos de software utilizando uma abordagem ágil, seguindo as orientações de  Aliança  Ágil..  Ágil Sugerir como processos que são instâncias de RUP podem ser configurados configurados  de forma a adotar princípios ágeis no que diz respeito a atividades ativida des de modelagem. A forma de definição da Modelagem Ágil é inspirada em XP, e muitos conceitos, valores, princípios e práticas são simplesmente iguais aos definidos em XP (ver seção sobre Extreme Programming). Programming). As próximas seções descrevem alguns detalhes da modelagem ágil, seus valores, princípios e práticas e suas formas de aplicação. Essas informações foram obtidas de Ambler (2002).

 Valores  V alores da Modelagem Ágil Os valores que dão suporte à Modelagem Ágil são comunicação, simplicidade, simplicidade, retroalimentação (feedback), coragem e humildade. Comparando-os aos valores de XP, percebe-se que a inovação nessa abordagem é a inclusão do valor da humildade. O objetivo desse valor é lembrar ao desenvolvedor que todos podem cometer enganos, que é possível que uma abordagem sugerida por outra pessoa seja melhor para resolver determinado problema, que é possível aprender com todos os outros envolvidos no processo (outros desenvolvedores e stakeholders stakeholders,, por exemplo). Outro efeito da humildade como valor é o fato de respeitar outros pontos de vista sobre o sistema, já que cada envolvido terá suas próprias experiências e prioridades.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

86

O cultivo da receptividade com outros melhora mel hora a cooperação e a comunicação comunicação no âmbito geral do projeto. Da mesma forma que com XP, esses valores são conceitos abstratos que servem como fundamentação para os princípios da abordagem Modelagem Ágil, apresentados a seguir.

Princípios da Modelagem Ágil Alguns princípios da Modelagem Ágil são adotados entre os princípios de XP, e estão descritos na sessão de Princípios de XP, como carregar pouca bagagem bagagem (travel light), light), assumir simplicidade, mudanças são bem-vindas, mudanças incrementais, efetuar um trabalho de qualidade. Além destes, a abordagem da Modelagem Ágil utiliza, ainda, os seguintes princípios:  O software é o objetivo principal: esse princípio é inspirado no valor do Manifesto Ágil “software “software   funcionando sobre documentação abrangente” abrangente” e no princípio derivado desse valor “software “software funcionando  funcionando é a medida principal de progresso”. O principal artefato a ser entregue ao cliente é o software software..



O investimento em modelos e documentação é válido em diversas situações, mas o sistema em funcionamento é indispensável. Habilitar o próximo esforço é o objetivo secundário: o próximo esforço esforço pode ser o desenvolvimento da próxima versão do sistema ou apenas ape nas operar e fornecer manutenção à última versão construída. Para isso, não basta apenas desenvolver software  de qualidade. software de



É preciso disponibilizar o mínimo de documentação necessária ao pessoal pessoal que realizará manutenção, ou à própria equipe que dará seguimento seguimento à construção da nova versão do sistema; é preciso transferir o conhecimento entre equipes do projeto ou até mesmo motivar a equipe atual a continuar suas atividades.  Modelar com um objetivo: quando um modelo está sendo criado, deve estar Modelar claro qual será sua audiência e qual seu motivo de criação. A audiência pode ser outros desenvolvedores, gerentes, membros de outros projetos que serão integrados ao software descrito pelo modelo, a equipe de manutenção etc. O motivo pode ser explicar uma abordagem a um colega, compreender melhor uma solução, documentar o sistema para o próximo esforço. A audiência e o motivo de criação de um documento são usados para definir o nível de detalhamento, a tolerância de inconsistências e outros fatores como

estes.

 

Métodos Ágeis

87

Outro aspecto a ser levado em conta na criação de modelos é o fato de que, quando eles atingem seus objetivos, deve-se encerrar o trabalho no modelo. Este é provavelmente o ponto ótimo de custo/benefício que esse modelo modelo pode atingir. Utilizar múltiplos modelos em paralelo: diversas técnicas de modelagem modelagem de sistemas disponibilizam um amplo número de modelos para serem usados por desenvolvedores.

Existem os modelos da UML (Unified Modeling Language) como diagramas diagramas de casos de uso, diagramas de classe e de sequência, modelos de dados, protótipos de interface de usuário, modelos navegacionais e muitos outros. A Modelagem Ágil sugere que vários desses modelos sejam construídos e utilizados em paralelo.



Por exemplo, ao criar diagramas de casos de uso, é possível definir as classes (com seus métodos e atributos) que darão suporte a determinado determinado caso de uso, além de diagramas de sequência que representam os diversos cenários possíveis para o caso de uso. Atualizações em um modelo mo delo evidenciam as necessidades dos demais. Maximizar o investimento dos stakeholders stakeholders:: um dos princípios básicos da modelagem ágil é a maximização do investimento dos stakeholders stakeholders.. Os stakeholders do projeto estão investindo recursos - tempo, dinheiro, logística etc. - para que seja desenvolvido um sistema que supra suas necessidades. Logo, têm o direito de investir seus recursos da melhor forma possível. Isso significa que os stakeholders devem tomar a decisão final sobre investir investir ou não seus recursos em uma determinada atividade ou artefato. Aplicado à modelagem e à documentação, o poder de decisão dos stakeholders significa que eles (e não os desenvolvedores) é que devem decidir que modelos e documentos serão mantidos, quais serão atualizados, atualizados, que ferramentas serão utilizadas e assim por diante.

Com base nestes princípios, são definidas as práticas, que serão executadas ao longo das atividades do desenvolvimento do sistema.

Práticas da Modelagem Ágil As práticas da modelagem ágil são divididas em quatro categorias: 

Modelagem Incremental : aplicar os artefatos criar vários modelos em Iterativa paralelo, eiterar para outro artefato, modelarcorretos, em pequenos pequenos incrementos.

 

88

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

  Trabalho em Equipe (Teamwork):





modelar com os demais, adotar participação ativa dos stakeholders stakeholders,, praticar a posse coletiva, exibir os modelos publicamente. Simplicidade: criar conteúdo simples, descrever os modelos de forma sim-

ples, usar as ferramentas mais simples. Validação: considerar a habilidade de fazer testes, provar com código. A maioria dessas práticas não representa uma novidade, mas sim um conjunto de melhores práticas seguido por desenvolvedores ao longo dos anos em seus projetos. 

A contribuição da Modelagem Ágil é reunir essas práticas de forma estruturada e orientar sua utilização de forma que seja formada uma sinergia em prol da modelagem eficaz de sistemas de software software.. A seguir, cada prática é comentada em separado:  Aplicar os artefatos corretos: cada modelo tem uma área específica de atuação, uma situação ideal de utilização. Essa prática orienta que os artefatos sejam escolhidos de acordo com o problema a ser modelado. Não se deve usar sempre o mesmo conjunto de modelos, ditados por algum método de desenvolvimento, mas sim os que se adequarem ao sistema e à solução que está sendo criada.  Criar vários modelos em paralelo: inspirada no princípio de utilizar múltiplos modelos em paralelo, essa prática é utilizada juntamente com “Iterar para outro artefato”. O principal objetivo é utilizar o que cada modelo tem a contribuir para a solução de um problema, construindo vários pontos de vista sobre a mesma solução. Não deve ser esquecido, porém, que não é necessário desenvolver todos os modelos possíveis em um único projeto. Cada modelo utilizado deve ter um motivo relevante rele vante para ser criado. Iterar para outro artefato: durante a construção de um artefato de modelagem,   este é desenvolvido até que não se possa pensar em mais nenhuma informação a ser adicionada. Porém, quando se passa a desenvolver outro modelo, é comum encontrar pequenos problemas ou notar a ausência de algumas informações no primeiro artefato. Assim, se dois (ou mais) modelos são desenvolvidos iterativamente, um complementa complementa o outro, tornando a modelagem mais completa e eficiente.  Modelar em pequenos incrementos: a ideia básica é dividir um amplo esforço em pequenas porções que são entregues ao longo do tempo, idealmente em incrementos de poucas semanas ou poucos meses. Isso faz com que o software software   seja entregue aos usuários rapidamente, e permite que aseretroalimentação (feedback) também sejamais recebida logo. A próxima iteração alimenta dos resultados da iteração atual, e do conhecimento do sistema promovido por ela.

 

Métodos Ágeis

89

  Modelar com os outros: o principal objetivo dessa prática é promover a retroa-



limentação (feedback) imediata, a troca de ideias e experiências entre desenvolvedores e, principalmente, a comunicação. Além disso, essa prática favorece a criação de um vocabulário comum entre os envolvidos no projeto. 









Adotar participação ativa dos stakeholders : a participação dosna stakeholders: stakehol se traduz no compartilhamento de informações sobre o ativa negócio; tomaders se ders da de decisões relevantes sobre o escopo do sistema e sobre as prioridades dos requisitos de forma rápida e condizente com as necessidades do projeto; em realmente fazer parte da equipe de desenvolvimento, conhecendo as possibilidades, tecnologias, dedicação e qualificação da equipe. Praticar a posse coletiva (collective ownership): qualquer um pode alterar qualquer artefato a qualquer momento, desde que esteja certo de que sua contribuição fará com que o artefato ilustre melhor suas informações. Essa prática estimula a retroalimentação, a utilização de melhores práticas, a comunicação e o aprendizado coletivo da equipe. Exibir : este é(feedback). mais um passo a favor da comunicação eosdomodelos estímulopublicamente à retroalimentação O local de exibição pode variar de uma parede a um web site com os modelos mais relevantes. Exibindo os modelos, não apenas os desenvolvedores, mas também os stakeholders stakeholders,, podem ter uma ideia do que está sendo criado e em que termos. Criar conteúdo simples: todos os tipos de modelos do sistema, desde os que retratam requisitos até os relacionados à análise e ao projeto, devem ser feitos tão simples quanto possível enquanto ainda cumprirem cumprirem seus objetivos. A definição de um modelo simples é sugerida em Beck (2000) como sendo um modelo que comunica tudo o que é necessário, necessário, não contém informação duplicada e utiliza o mínimo possível de elementos para isso. Descrever os modelos de forma simples: “conteúdo é mais importante do que a forma de apresentação”.

Apesar de diversas abordagens de modelagem oferecerem inúmeras i númeras possibilidades de expressão e diversas notações, a maioria dos modelos criados utiliza um subconjunto limitado dessas notações. Assim, a Modelagem Ágil aconselha os desenvolvedores a utilizarem apenas esse subconjunto bem conhecido de elementos suficientes para descrever a maior parte das soluções. Esse hábito aumenta a produtividade na criação e na leitura dos modelos, mode los, além de eliminar complexidade geralmente desnecessária.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

90

  Usar as ferramentas mais simples: equipes adeptas da Modelagem Ágil criam



modelos usando lápis e papel em desenhos à mão livre, desenhos em quadros brancos, fotos de esboços criados durante sessões de modelagem. Outras equipes tendem a utilizar utili zar ferramentas CASE (Computer Aided Software Engineering) extremamente elaboradas para qualquer atividade de modelagem. Isso faz com que se desacelere o processo de criação de modelos, carregando essas ferramentas em memória, utilizando formatos de difícil compartilhamento, utilizando tempo considerável das sessões de modelagem na organização de layout dos modelos. Muitas vezes, porém, um simples desenho poderia ser suficiente para expres sar as informações sendo modeladas. Na Modelagem Ágil, ferramentas CASE também são utilizadas, mas apenas apenas quando sua utilidade está justificada, por exemplo, quando for utilizada alguma funcionalidade da ferramenta para a geração automática de código, ou engenharia reversa. 



Considerar a habilidade de efetuar testes: durante a modelagem, deve haver uma preocupação constante com a forma pela qual o software  será testado. Os software será testes devem ocorrer desde a primeira iteração e com grande frequência. Algumas abordagens de desenvolvimento promovem promovem essa prática, como XP, por exemplo, com seu desenvolvimento orientado a testes. Provar com código: um modelo é uma abstração da solução sendo desenvolvida. Para saber se o modelo está realmente de acordo com as necessidades, deve-se implementá-lo, submetê-lo aos testes e entregá-lo aos usuários para receber retroalimentação (feedback). Esta é a base do desenvolvimento iterativo e incremental.

Resumo da Modelagem Ágil A Figura 5.2 ilustra valores, conceitos e práticas da Modelagem Ágil. Existem outros princípios e práticas que complementam os descritos neste trabalho e são chamados de princípios e práticas suplementares. Essa abordagem de desenvolvimento mantém o foco de suas orientações nas atividades de modelagem, e não define processos ou papéis a serem executados execu tados em seus projetos.

 

Métodos Ágeis

91

Figura 5.2

A equipe de desenvolvimento deve seguir algum outro processo para definir defi nir e coordenar suas atividades. Esse processo pode ser leve e focado em resultados resul tados imediatos como XP ou mais formal e prescritivo como RUP. Nem todos os processos de desenvolvimento de software software   podem acomodar a Modelagem Ágil. Para concluir se determinado processo comporta essa meto-

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

92

dologia, deve-se comparar as definições de tal processo com os valores, princípios princípios e, principalmente, com as práticas da Modelagem Ágil. Se houver discordância com esses conceitos, a metodologia pode ser adotada parcialmente. Porém, os ganhos com a utilização da Modelagem Ágil serão provavelmente as práticas.reduzidos, uma vez que não se pode contar com a sinergia entre todas

Integração de Metodologias de Desenvolvimento de Software Este ponto do capítulo descreve três enfoques de desenvolvimento de software software::   Integração dos Modelos de Capacidade e Maturidade (CMMI): CMMI):   um modelo para melhoria de processos, descrito através de metas e práticas de desenvolvimento.    Processo Unificado da Rational (    um um framework  RUP):   RUP):    framework de processo de desenvolvimento que contém orientações sobre aspectos dinâmicos (iterações, (iterações, fases e marcos) e aspectos estáticos (atividades, artefatos, papéis e fluxos de atividades) de um projeto.   Métodos   Ágeis:   um conjunto de metodologias que compartilham valores e Ágeis: princípios fundamentais, descritas a partir desses valores e princípios e complementadas por práticas, atividades e estratégias diversas. Estes três enfoques não são necessariamente incompatíveis. Na verdade, diversos estudos apontam para a existência de pontos de sinergia, assim como pontos de incompatibilidade entre eles. A seguir, são sumarizadas algumas análises feitas sobre a utilização destes enfoques em conjunto.

RUP & CMMI Alguns estudos afirmam que RUP e CMMI são abordagens complementares, complementares,  já que trazem contribuições em diferentes perspectivas e podem ser utilizadas utilizadas con juntamente para ajudar uma organização a alcançar seus objetivos de negócios e de maturidade de processos. Como RUP é um processo de desenvolvimento de software software,, é possível avaliá-lo com relação a um modelo de referência para melhoria de processos como o CMMI, um modelo de avaliação de processo já reconhecido na comunidade comunidade de engenharia de software software.. Afirma-se que é possível estender RUP criando uma instância que inclua práticas-chave descritas pelos modelos de CMM, e assim chegar a um modelo de pro-

cesso que satisfaz a ambas as abordagens.

 

Métodos Ágeis

93

Os conceitos de RUP e do modelo CMMI, segundo a análise de conceituados conceitua dos autores, apresentam a seguinte correspondência: Tabela 5.1: Correspondência entre conceitos de RUP e de CMMI.

Conceito de RUP

Conceito de CMMI

• Disciplina

• Agrupamento de elementos de processo logicamente associados

• Papel

• Comportamento e responsabilidades de um indivíduo em um projeto

• Workflow

• Sequência de atividades com algum significado, realizada para alcançar algo de valor observável

• Atividade

• Unidade de trabalho que um indivíduo pode executar

• Artefato  Artefato,, Modelo (Template Template))

• Produtos de Trabalho

• Guideline Guideline,, Conceito Conceito,, Orientação de Ferramenta (Tool Mentor )

• Orientação Informativa (Informational Guidance)

A correspondência apresentada pode ser usada para auxiliar a avaliação de RUP com relação aos objetivos e práticas do CMMI. Em Smith (2000), são apresentadas justificativas para considerar-se que RUP satisfaz todos os critérios necessários para representar um processo aderente aderen te ao CMMI níveis 2 e 3. Em Manzoni e Price (2001), afirma-se que o estudo de Smith foi feito com foco apenas nos objetivos de cada área de processo e não nas práticas a serem executadas em cada uma dessas áreas. O trabalho de Manzoni e Price documenta a comparação entre RUP e CMM, considerando cada uma das práticas recomendadas, e identifica carências no modelo RUP com relação a práticas dos níveis de maturidade 2 e 3 do CMM. As áreas de RUP em que foram observadas as carências com relação ao CMM são controle de qualidade, foco no processo da organização, coordenação entre times, treinamento e gerência de subcontratação de serviços. Em um estudo posterior, os mesmos autores afirmam que a não satisfação das práticas-chave do RUP resulta, em geral, da falta de uma descrição sobre como recursos humanos e financeiros adequados são fornecidos para dar seguimento segui mento a atividades do processo, e da falta de mecanismos que assegurem treinamento treinamento adequado para que os desenvolvedores executem suas atividades.

 

94

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Os autores Gallagher e Brownsword (2001), membros do Instituto de Engenharia de Software  da Universidade de Carnegie Mellon (CMU-SEI), responsável responsável Software da pelo CMMI, relatam uma análise detalhada do suporte fornecido por RUP para o Modelo de Capacidade e Maturidade Integrado de Sistemas/Engenharia de  (CMMI-SE/SW). Software (CMMI-SE/SW). Software Neste estudo investiga-se o suporte fornecido por fluxos de atividades e artefatos de RUP para cada uma das práticas específicas do CMMI-SE/SW. As áreas de carência de RUP encontradas em Gallagher e Brownsword (2001) são acentuadas em três áreas de processo:   No Planejamento de Projeto, RUP não fornece auxílio para classificar e medir atributos de projetos não relacionados a software software,, como trabalho, materiais, máquinas etc.  Com relação ao Monitoramento e Controle de Projeto, o  framework  RUP pa framework RUP drão não assegura o endereçamento explícito da gerência de dados. 

A área de Gerência de Acordo com Fornecedor está praticamente ignorada, já que RUP não lida explicitamente com a gerência de trabalho trabalho vindo de fornecedores externos ao projeto. Em Manzoni e Price (2001), apontam-se propostas para estender o RUP de forma a satisfazer as áreas de processo do SW-CMM (Software ( Software CMM)  CMM) de níveis 2 e 3 de maturidade. Essas propostas descrevem:  A inclusão de atividades para estimativa de recursos e fundos;  A inclusão de atividades relacionadas ao controle de qualidade do sistema;  A inclusão de uma disciplina para gerência de subcontratação; 

A inclusão de um fluxo de atividades relacionado a treinamento de pessoal; pessoal; A inclusão de atividades relacionadas à melhoria de processos. As extensões do RUP com o objetivo de atender os requisitos do CMMI Nível 2 descritas em (REITZIG, 2003) são:  Criar políticas organizacionais que orientem o planejamento e o desempenho desem penho de processos do CMMI nível 2.  Criar padrões e procedimentos detalhados que enderecem o desempenho desempenho de atividades do cotidiano.  Realizar revisões orientadas a processo. 



Gerenciar fornecedores. A seguir analisa-se a possibilidade de inserção de métodos ágeis em instâncias instâncias de RUP.  

 

Métodos Ágeis

95

 RUP & Métodos Ágeis RUP Conforme descrito anteriormente, RUP é um framework um  framework para  para processo de desenvolvimento de software  que pode ser modificado, ajustado e expandido pela orsoftware que ganização que o utiliza para acomodar as necessidades, características, restrições restrições e histórico específicos de uma organização, cultura e domínio. Ainda se observa um claro alinhamento da filosofia de RUP com os princí princípios pios e práticas da modelagem ágil, ao afirmar que: “Um processo não deve ser seguido cegamente, gerando trabalho inútil e produzindo  produzindo artefatos que são de pouco valor agregado. agregado.   Ao invés disso, o processo deve ser feito tão leve quanto possível de forma a satisfazer satisfazer sua missão de produzir rapidamente software previsivelmente de alta qualidade.” qualidade.” Uma descrição detalhada da relação de todas as práticas da modelagem ágil com as práticas utilizadas nas disciplinas de RUP indica as vantagens de utilização das práticas ágeis em cada contexto. Analisando essa relação, percebe-se que o conceito-chave a ser utilizado na integração das práticas de modelagem ágil a um processo de desenvolvimento nos moldes de RUP é manter o foco na agilidade do processo. Algumas decisões em prol da agilidade são feitas sem dificuldades, como a inserção de stakeholders  em papéis de modelagem, adoção de apenas um subconjunto subconjunto stakeholders em de artefatos por projeto e criação de protótipos para execução de modelos. modelos. Boa parte dessas decisões já está incorporada nas próprias práticas de RUP. Outras decisões, contudo, se mostram um tanto mais desafiadoras, como o ajuste de padrões e diretrizes ( guidelines)  guidelines) de forma a eliminar trabalho desnecessário, a adoção de práticas de abandono de modelos intermediários de projeto (design) e sincronização de artefatos apenas sob demanda. É importante esclarecer que agilidade, para uma organização de desenvolvimento de software software,, é a habilidade de se adaptar e reagir rápida e apropriadamente a mudanças em seu ambiente e a demandas impostas por esse ambiente. Um processo ágil adota e dá suporte a esse tipo de adaptabilidade. Assim, o mais importante não é o tamanho do processo ou sua velocidade de entrega, mas sim sua flexibilidade. RUP possui nove disciplinas, dentre as quais três podem ser claramente aplicadas às práticas de Modelagem Ágil: Modelagem de Negócio;   Requisitos;  





 Análise e Projeto. Análise

 

96

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

No contexto deste trabalho, a disciplina de Requisitos é de especial interesse, interesse,  já que o processo proposto é para engenharia engenharia de requisitos. A integração da Modelagem Ágil à disciplina de Requisitos de RUP contribui para aumentar a produtividade e facilitar a manutenção dos modelos, através da execução das práticas e princípios da Modelagem Ágil. Essa integração é comentada no próximo capítulo, Processos e Práticas da Engenharia de Requisitos, na seção Métodos Ágeis e a Engenharia de Requisitos. Um dos maiores desafios na implantação de práticas ágeis em projetos que utilizam RUP é a cultura da organização à qual pertencem os projetos. Para adotar estratégias ágeis, desenvolvedores devem afastar-se da forma prescritiva de desenvolvimento, frequentemente calcada em produção de documentação, para que possam se aproximar de valores ágeis como simplicidade e maximização do investimento dos stakeholders stakeholders,, mantendo foco no sistema a ser produzido e tratando todas as outras atividades como meios para a produção de código que atenda às necessidades do cliente. A próxima área de investigação da utilização conjunta de abordagens de desenvolvimento de software  é a avaliação de processos que utilizam métodos ágeis, software é comparando-os com os modelos do CMMI.

CMMI e Métodos Ágeis Os modelos do SW-CMM consideram tanto questões relacionadas à implementação de processos eficazes e eficientes quanto a melhoria sistemática de processos.  Já os métodos ágeis, em geral representam conjuntos de práticas específicas cujo contexto ideal de aplicação é o de projetos de tamanho pequeno ou médio, com times localizados em um mesmo local e cujos requisitos estão sofrendo alterações continuamente. Diversos estudos afirmam que essas duas categorias de métodos (CMMI ou CMM e métodos ágeis) podem ser empregadas conjuntamente, criando uma sinergia que possibilita que as organizações que os utilizam se beneficiem das vantagens trazidas por ambos. Ron Jeffries, um dos idealizadores da Aliança Ágil, afirma que XP, um dos métodos ágeis considerados neste livro, possui algumas características em comum comum com todos os níveis de maturidade do CMM, inclusive o nível 5.  Jeffries faz faz a ressalva de de que seria necessário necessário muito mais documentação documentação e comprovações do que o sugerido por XP para considerar um projeto que utiliza essa abordagem como aderente a qualquer nível de maturidade do CMM.

 

Métodos Ágeis

97

Ainda neste estudo, comenta-se que as práticas de XP, claramente definidas definidas e documentadas, representariam uma forma de alcançar o objetivo genérico de Institucionalizar um Processo Gerenciado. Sugere-se que deveria haver um empenho do Instituto de Engenharia de Universidade de Carnegie Mellon (CMU/SEI), orientação órgão quepara elabora Software Software da divulga  da os requisitos do CMMI, no sentido de disponibilizar orga-e nizações interessadas em adotar os modelos do CMMI com a inclusão de práticas dos métodos ágeis. Tal empenho facilitaria a transição para abordagens como XP e ainda poderia poderia trazer a organizações que já comprovaram ter atingido níveis de maturidade altos as vantagens da agilidade, como, por exemplo, o aumento da produtividade. produtividade. Um esforço neste sentido é o artigo de Mark Paulk, membro da equipe do SEI, analisando as contribuições que XP pode trazer a organizações que procuram procu ram alcançar os objetivos do modelo SW-CMM. Nesse artigo, Paulk analisa cada uma das áreas de processo do SW-CMM e discute práticas e mecanismos de XP que dão suporte àquela prática. A tabela seguinte, baseada na tabela de satisfação de áreas-chave de processo pro cesso apresentada por Paulk, resume a discussão do suporte de XP a áreas de processo do nível 2 de maturidade. Tabela 5.2: Satisfação das áreas-chave de processo do SW-CMM por XP XP..

Nível Mat.

2

Área-Chave de Processo

Gerência de Requisitos

Índice de Satisfação

Satisfaz Amplamente

Mecanismos de Suporte

Histórias do Usuário Cliente Presente Integração PriorizaçãoContínua de histórias pelo cliente

2

Planejamento de Projeto de Software

Satisfaz Amplamente

 Jogo do Planejamento Planejamento Pequenas Releases Estimativas feitas pelos desenvolvedore desenvolvedoress (compromisso) Priorização de histórias pelo cliente

2

Acompanhamento e Supervisão de Projeto de Software

Satisfaz Amplamente

Acompanhamento de medidas (exemplo: velocidade de projeto)

2

Gerência de Subcontratação de Software

2

Garantia  G arantia de Qualidade de

Não satisfaz

Não há suporte A ocorrência de subcontratação de software em usando XP é provavelmente umaprojetos raridade

Satisfaz Parcialmente

Programação em Pares (embora em times maiores exista a necessidade de uma maior

Software

formalização das métricas de qualidade)

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

98

Nível Mat.

2

Área-Chave de Processo

Gerência de

Índice de Satisfação

Satisfaz Parcialmente

Foco no Processo Organizacional

3

Definição do Processo Organizacional

Propriedade Coletiva de Código (arriscada em projetos maiores) Pequenas IntegraçãoReleases Contínua

Configuração 3

Mecanismos de Suporte

Satisfaz Parcialmente

Escolha da forma de adoção de XP (todas as práticas ou uma de cada vez?)

Satisfaz Parcialmente

Parcialmente endereçadas pelos diversos livros, artigos, cursos e web sites associados a XP.

3

Treinamento da Organização

Não satisfaz

Parcialmente endereçadas pelos diversos livros, artigos, cursos e web sites associados a XP.

3

Gerência de  Integrada Software Integrada Software

Não satisfaz

Recursos organizacionais estão fora do escopo de XP.

3

Engenharia de Satisfaz Amplamente Produto de Software Software  

Metáfora Projeto Simples Refatoração Padrões de Código Testes Unitários e Funcionais

3

Coordenação Intergrupos

Cliente Presente Programação em Pares

3

Revisões por Pares Satisfaz Amplamente

Satisfaz Amplamente

Revisão por Pares

O principal elemento ausente em XP e fundamental para o SW-CMM é o conceito de institucionalização, ou seja, no XP não há a formalização do processo seguido pela organização, prática que o SW-CMM considera necessária. Outro estudo afirma que as práticas do XP, claramente definidas e documentadas, representariam uma forma de alcançar o objetivo genérico de Institucionalizar um Processo Gerenciado. Ainda na comparação feita por Paulk, aponta-se que projetos maiores oferecem dificuldades consideráveis para a aplicação de algumas práticas do XP, como, por exemplo, a propriedade coletiva do código. Nas análises estudadas sobre métodos ágeis e CMM ou CMMI, a principal contribuição dos métodos ágeis parece ser em sua filosofia. Logo, mesmo que não se adotem especificamente as técnicas e atividades propostas pelos métodos ágeis, organizações que buscam a conformidade com CMMI podem e devem incorporar diversas práticas ágeis, tais como a procura pela sim-

plicidade e a retroalimentação (feedback).

 

Métodos Ágeis

99

Exercícios 1)  Nos métodos ágeis, é mais importante importante seguir um plano ou atender solicitações de mudanças? 2)  Qual o papel dos stakeholders  nos métodos ágeis? Explique. stakeholders nos 3)  Qual é a medida principal de progresso em métodos ágeis? 4)  Cite três dos principais valores do XP. 5)  Retroalimentação rápida é um princípio ou um valor do XP? 6)  O que é metáfora metáfora no XP? Explique. 7)  Defina propriedade coletiva do código-fonte. 8)  Qual a vantagem de de modelar com os outros, proposta proposta pelo XP? 9)  Qual a forma de validação validação proposta proposta pela modelagem ágil? 10) Qual a correspondência de artefato do RUP no CMMI?

 

 Anotações

 

Engenharia de Requisitos

6

“O olho do observador interfere interfere no objeto observado.” (Autor Desconhecido Desconhecido))

A engenharia de requisitos pode ser descrita como “o ramo da engenharia de software que se preocupa com os objetivos, funções e restrições dos sistemas de software”. A Engenharia de Requisitos pode ser definida como o processo sistemático de desenvolvimento de requisitos através de um processo iterativo cooperativo de análise do problema, documentação das observações resultantes em variados formatos de representação e a verificação da precisão do ganho compreendido. Apesar de fornecer as definições anteriores, a literatura relacionada a requisitos evidencia uma falta de consenso na definição de termos como engenharia de requisitos, gerência de requisitos ou análise de requisitos. Estes termos podem aparecer como sinônimos, ou como componentes uns dos outros, dependendo da referência. De acordo comdea definição a Engenharia de Requisitos é dividida em Desenvolvimento Requisitosadotada, e Gerência de Requisitos. O Desenvolvimento de Requisitos preocupa-se com a descoberta, busca da qualidade (correção, completude, consistência, possibilidade de verificação, ordenação e rastreamento, facilidade de modificação e clareza), detalhamento, documentação, revisão e verificação dos requisitos do sistema. Essas preocupações são endereçadas pelas subdivisões de Elicitação, Análise, Aná lise, Especificação e Verificação.  Já a Gerência de Requisitos compreende a gerência de mudanças e o acompanhamento do desenvolvimento e implementação dos requisitos. Uma lista das principais causas de risco de falha em projetos de software menciona fatores relacionados à engenharia de requisitos da terceira à sexta colocação:

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

102

Desenvolvimento de funções e propriedades erradas;  Desenvolvimento da interface com o usuário errada;    Gold-plating (desenvolvimento de requisitos supérfluos);  





Fluxo constante de mudanças nos requisitos. Uma lista semelhante cita requisitos incertos como a principal fonte de risco em projetos de desenvolvimento de software. Tamanha relevância atribuída aos resultados da engenharia de requisitos se explica pelo fato de que, caso os requisitos do sistema não sejam compreendidos compreen didos corretamente, o tempo e os recursos financeiros gastos com a correção do sistema podem fazer com que este seja entregue com atraso e com custo maior do que o originalmente estimado. Caso esta correção não seja feita, o cliente e os usuários finais podem não ficar satisfeitos com o sistema entregue e podem até mesmo deixar dei xar de usá-lo. Para que a engenharia de requisitos seja propriamente desenvolvida em um projeto de software, o processo utilizado no desenvolvimento deve ser descrito descrito claramente, com todas as suas fases, atividades e produtos de trabalho trabalho, ou seja, entradas e saídas do processo.

 Elicitação de Requisitos Elicitação A elicitação de requisitos é um processo de descobrimento dos requisitos de um sistema; a descrição de um produto de software específico. Desenvolvedores, engenheiros, colaboradores e usuários trabalham juntos para descobrir o problema a ser resolvido, os serviços do sistema, o desempenho necessário, as restrições de hardware , entre outras informações. Nessa fase ocorre o levantamento ou extração dos requisitos. O termo elicitação de requisitos sugere que o processo seja uma simples transferência do conhecimento em que os engenheiros de requisitos fazem o levantamento e a documentação do conhecimento do cliente. Na realidade esse processo é bem mais complexo, pois raramente se tem uma visão clara dos requisitos; diferentes pessoas têm requisitos conflitantes; usuários têm entendimento incompleto de suas necessidades; usuários conhecem pouco sobre a capacidade e limitações de computadores; analistas têm pouco conhecimento sobre o domínio do problema; usuários e analistas falam “línguas” diferentes; ocorre a omissão de informações “óbvias”; requisitos frequentemente vagos e não testáveis; entre outras.

 

103

Engenharia de Requisitos

Outro problema é a volatilidade dos requisitos, que, com, o tempo, evoluem, evo luem, por mudanças no negócio, mudanças tecnológicas ou, até mesmo, para uma maior clareza pelo usuário do sistema. A saída do processo de elicitação de requisitos é um conjunto de esboços de documentos que representam os requisitos do sistema. Existem quatro dimensões na atividade de elicitação dos requisitos. São elas:   Entendimento do domínio da aplicação: entendimento geral da área onde o sistema será aplicado.   Entendimento do problema: entendimento dos detalhes do problema específico a ser resolvido com o auxílio do sistema a ser desenvolvido. Entendimento do contexto do negócio: entendimento da contribuição do sis  tema para que sejam atingidos os objetivos gerais da organização.   Entendimento das necessidades e das restrições dos stakeholders: entendidetalhado das necessidades de apoio a serem pelo sistema àmento realização do trabalho e aos interesses de cada um providas dos stakeholders , e dos processos de trabalho a serem apoiados pelo sistema e do papel de eventuais sistemas existentes na execução e condução dos processos de trabalho.

Figura 6.1: Dimensões da atividade de elicitação de requisitos. (KOTONYA; 1998)

O processo de elicitação de requisitos resulta em um grande volume de informações que devem ser organizadas para serem entendidas.

Podem ser utilizados para estruturação dessas informações alguns mecanismos como:

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

104

r elações de agrega  Particionamento: consiste em organizar o conhecimento em relações



ção, compondo entidades mais complexas a partir de entidades mais simples.    Abstração: baseia-se no estabelecimento de relações de generalização e espeAbstração cialização, organiza o conhecimento através de estruturas abstratas que representam as instâncias específicas identificadas. pers pectivas.   Projeção: a organização do conhecimento adquirido baseia-se em perspectivas. É necessário registrar, durante o processo de levantamento de requisitos, a perspectiva a que se refere o requisito, ou seja, organizar as informações a partir de diferentes pontos de vista.

 Análise e Negociação de Requisitos Os documentos produzidos na fase de elicitação necessitam ser analisados para que sejam verificados requisitos faltantes, conflitantes, ambíguos, sobrepostos ou fora da realidade, os quais devem ser apresentados, discutidos, negociados e modificados pelos stakeholders. Neste ponto entra a fase de análise e negociação, na qual os documentos de requisitos produzidos são verificados, procurando identificar se todos os problemas são resolvidos com os requisitos descritos, bem como se eles não entram em conflito ou se sobrepõem. Ocorre também a negociação e análise de viabilidade de execução do que fora solicitado. Além da resolução de conflitos e sobreposição, o resultado dessa etapa é um documento de requisitos acordado entre os stakeholders.

Documentação de Requisitos Os requisitos aprovados devem ser documentados em um nível apropriado de detalhamento. Em geral, é necessária a criação de um documento de requisitos claro, numa linguagem que eles possam ser claramente compreendidos por todos os stakeholders. É recomendável que os requisitos sejam documentados em uma linguagem natural e acompanhados de diagramas explicativos, para melhor entendimento. Esse documento deve retratar o conhecimento do problema, em conformidade conformidade com a satisfação dos stakeholders e os padrões de qualidade relacionados ao que se pretende produzido de com Tecnologia da Informação para solução de problemas problemas ou como oportunidade negócio. O documento de requisitos é formal e obrigatório, utilizado para comunicar comunicar

os requisitos aos clientes, engenheiros e gerentes, e ele deve descrever:

 

Engenharia de Requisitos

105

Os serviços e funções que o sistema deve prover. Limitações sobre as quais o sistema deve operar; propriedades gerais do siste ma, isto é, limitações nas propriedades emergentes.  Definições de outros sistemas com os quais o sistema deve se integrar.  Informações sobre o domínio da aplicação do sistema. Limitações nos processos usados para desenvolver o sistema; descrições do   hardware no qual o sistema irá executar. Adicionalmente, o documento de requisitos deve sempre conter um capítulo capítulo introdutório que provê um resumo do sistema, necessidades de negócio suportadas pelo sistema e um glossário que explica a terminologia utilizada.  



São usuários do documento de requisitos os clientes do sistema que especificam os requisitos e os leem, para verificar se eles satisfazem suas necessidades, e os gerentes de projeto, que utilizam os documentos de requisitos para plane jarem plane jarem uma proposta para o sistema e o processo de desenvolvimento do sistema. Também são usuários desses documentos os analistas de sistema, que utilizam os requisitos para entenderem o sistema em construção; analistas de teste do sistema, que utilizam os requisitos para desenvolverem planos de testes de validação do sistema e desenvolvedores de sistema, que q ue utilizam os requisitos para entenderem o sistema a ser desenvolvido.

 Validação  V alidação de Requisitos Após a documentação dos requisitos, inicia-se o processo de validação deles. Essa fase consiste na verificação do documento de requisitos, buscando verificar se todos estão corretos, completos, consistentes e descritos de forma apropriada, procurando eliminar problemas de ambiguidade, inconsistência e falta de completeza. Ocorre também uma validação quanto à qualidade do documento de especificação dos requisitos.

 Gerência de Requisitos Gerência É um processo que estabelece e mantém acordos entre o cliente e a equipe do projeto sobre a evolução dos requisitos. A gerência de requisitos monitora status o desenvolvimento e implementação requisitos, registrando seus atributos, e dependências, com o objetivodos de controlar o andamento e as mudanças realizadas.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

106

Um conceito da disciplina de Planejamento que está relacionado à gerência de requisitos é a gerência de escopo.

Gerência de Escopo O conjunto de requisitos que serão entregues ao final do projeto de desenvolvimento representa o escopo do sistema. Ao longo de um projeto de desenvolvimento de software, os requisitos do sistema são identificados e documentados mediante a utilização de diversas técnicas técnicas de elicitação, análise e especificação de requisitos. Contudo, nem todos os requisitos encontrados fazem parte do escopo sistema. A escolha dos requisitos que devem fazer parte do sistema é chamada de gerência de escopo, a qual leva em conta fatores como a importância de cada requisito para os clientes; a relevância técnica de cada requisito, ou seja, o quanto cada requisito é importante para a definição da arquitetura do sistema; a dependência depen dência entre recur sos e prazos. requisitos; as restrições do projeto em termos de orçamento, recursos Estes fatores são levados em conta para decidir que requisitos fazem parte do escopo do sistema.

Gerência de Mudanças O conjunto de requisitos que fazem parte do escopo de um sistema muda ao longo de seu desenvolvimento. Alguns fatores responsáveis pelas mudanças são: 









Mudanças negócio, resultando em alterações nas necessidades cliente que trazemno novos requisitos ou invalidam requisitos formalizadosdo formalizados anteriormente. Aumento da complexidade de requisitos, identificado após investigação investigação detalhada do requisito. Alteração estrutural no requisito necessária para melhor integrá-lo ao sistema ou porque sua estrutura original não configurava uma solução correta. Evolução da percepção do sistema pelos fornecedores de requisitos, após a visualização de protótipos ou a execução dos primeiros testes de validação. A descoberta de falhas no entendimento e na especificação de requisitos e a consequente necessidade de correção. As mudanças nos requisitos demandam um replanejamento do projeto, pos-

sivelmente necessitando de negociações envolvendo variáveis como custo, prazos ou escopo do sistema.

 

Engenharia de Requisitos

107

Se uma dessas variáveis é alterada, as outras sofrem consequências. Se o escopo aumenta (por causa do levantamento de novos requisitos, por exemplo), o tempo pode ter de aumentar e o orçamento provavelmente também aumentará. Por outro lado, se o orçamento, recursos e tempo não podem variar, então o escopo deve ser diminuído, deixando alguns requisitos de menor prioridade fora do sistema. O papel da gerência de requisitos, neste contexto, é o de oferecer subsídios como a estimativa de esforço, estratégias de priorização e análise de impacto de mudanças sobre os requisitos. A análise de impacto utiliza fortemente as relações entre requisitos, ou seja, a rastreabilidade documentada entre os requisitos (consultar seção sobre Rastreabilidade).

Problemas Clássicos e Soluções Adotadas A engenharia de requisitos possui alguns problemas clássicos, observados na maioria dos projetos de software. Esses problemas são comentados em seguida, assim como algumas soluções soluções ou estratégias de contorno.

Constantes Solicitações de Mudança Conforme descrito na seção anterior, o conjunto de requisitos sobre mudanças mudanças ao longo do projeto, por uma série de razões. Assim, é imprescindível, para qualquer processo de desenvolvimento de software, que seja definido um mecanismo de tratamento de mudanças nos requisitos. A falta deste resulta em diversos problemas, como, por exemplo, e xemplo, a entrega de um sistema que não satisfaz as necessidades de seus clientes cli entes e usuários ou a falha na entrega do sistema devido a mudanças constantes. O mecanismo de tratamento de mudanças deve identificar os pontos de origem de solicitações de mudanças, como essas mudanças devem ser registradas, registradas, como analisar o impacto de sua execução, quais os critérios de aprovação de mudanças e como elas devem ser inseridas no planejamento do sistema.

Falta de Consenso Entre Stakeholders Sistemas de software geralmente têm uma comunidade heterogênea de usuá-

rios, com requisitos e prioridades diferentes e às vezes até mesmo conflitantes. conflitantes.

 

108

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Além disso, os responsáveis pelo orçamento do sistema raramente são os seus usuários. Os responsáveis impõem requisitos ao sistema que são decorrentes decorrentes de restrições organizacionais ou financeiras as quais, frequentemente, entram em conflito com as necessidades operacionais dos usuários. requisitos do sistema são, inevitavelmente, um acordo as partes.  ParaOs chegar a essefinais acordo, é fundamental que se identifiquem todosentre os stakeholders relevantes para o projeto, incluindo responsáveis pela operação do sistema, equipes envolvidas na visão estratégica da empresa, clientes encarregados encar regados de aprovar o orçamento e qualquer outro envolvido, cuja participação na definição do sistema seja importante para a aceitação final, utilização e bom funcionamento do sistema.

Pouco Conhecimento do Domínio do Problema Em diversos sistemas, os desenvolvedores não possuem conhecimento do domínio do problema que o sistema deve resolver. Nestes casos, os desenvolvedores adquirir e evoluir evol uir seu conhecimento conheci mento do domínio e das áreas de atuação dosdevem usuários e das opções e questões tecnológicas mais relevantes envolvidas na solução. Da mesma forma, os stakeholders devem acompanhar a elaboração do novo sistema, evoluindo sua percepção dele e a melhor maneira de endereçar os seus problemas. Essas necessidades apontam para duas estratégias de solução, sendo uma relacionada ao processo utilizado e outra relacionada à equipe de desenvolvimento. desenvolvimento. Com relação ao processo, a utilização de protótipos e desenvolvimento iterativo e incremental, em que cada iteração contribui para uma crescente compreensão do sistema, e da realidade de negócios que q ue o cerca, é uma linha de ação promissora. Com relação à equipe, identifica-se a necessidade de contratação de pessoal experiente, consultores proficientes no negócio, tutores versados no domínio e no processo de desenvolvimento do sistema.

Pouca Qualidade da Documentação e Comunicação Se a documentação dos requisitos não é de boa qualidade e a comunicação entre os stakeholders, os analistas e os responsáveis pela implementação do sistema sistema é deficitária, as chances de que o sistema final realmente satisfaça as necessidades necessidades dos stakeholders são drasticamente prejudicadas. Os métodos ágeis, apresentados neste livro, apostam na intensificação da comunicação, especialmente face a face, na qualidade da equipe, na prototipação, na implantação rápida de partes essenciais do sistema, na refatoração e nas demais

 

109

Engenharia de Requisitos

práticas ágeis como forma de melhorar a compreensão geral da equipe sobre os requisitos do sistema.

Engenharia Requisitosanteriormente, no CMMI os modelos do CMMI são descritos em Conformede mencionado termos de áreas de processo, metas e práticas. Áreas de processo são conjuntos de práticas relacionadas de uma determinada determinada área que, quando executadas coletivamente, satisfazem um conjunto de metas consideradas importantes para causarem uma melhoria significativa naquela área. Nas próximas seções, são descritas as áreas de processo relacionadas à engenharia de requisitos no CMMI: Gerência de Requisitos e Desenvolvimento de Requisitos. Para cada área de processo são apresentadas suas metas e as práticas que devem ser executadas para que se alcancem as metas.

 Área de Processo: Gerência de Requisitos Essa área de processo controla todos os requisitos do sistema, desde as necessidades do cliente até os requisitos técnicos derivados de restrições impostas im postas por escolhas de arquitetura e até mesmo restrições no processo de desenvolvimento desenvolvimento do sistema. A organização desses requisitos está ilustrada na figura a seguir.

Figura 6.2: Requisitos do cliente e requisitos do produto.

Níveis de Requisitos RUP e CMMI Também faz parte da gerência de requisitos certificar-se de que os requisitos requi sitos mencionados estão coerentes entre si e em conformidade com os planos de execução do projeto.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

110

A gerência de requisitos envolve, ainda, o controle de mudanças em requisitos, utilizando mecanismos de suporte a análises de impacto que possam ser necessárias em função das mudanças. A tabela seguinte ilustra a meta da Gerência de Requisitos no CMMI e as práticas a serem executadas para o alcance dessa meta. Tabela 6.1: Área de processo de gerência de requisitos.

Área de Processo: Gerência de Requisitos ( Requirements Management  Management ) Meta

Práticas

(SP1.1) Compreender os requisitos. (SG1) Gerenciar Requisitos

(SP1.2) Obter comprometimento com os requisitos.

(SP1.3) Gerenciar mudanças nos requisitos. “Os requisitos são gerenciados e inconsistências inconsistên cias com planos de projeto e (SP1.4) Manter rastreabilidade bidirecional dos produtos de trabalho são identificadas.” requisitos. (SP1.5) Identificar inconsistências entre os resultados do projeto e os requisitos.

Meta: Gerenciar Requisitos A gerência de requisitos, neste contexto, inclui a documentação das dependências entre requisitos, o controle de mudanças sobre estes e a identificação e correção de inconsistências entre os requisitos e os artefatos do projeto (por exemplo: documentos, código, planos do projeto, outros requisitos). 





As práticas executadas para alcançar a meta da gerência de requisitos são: Compreender os requisitos: identificar os fornecedores de requisitos; obter aprovação desses fornecedores sobre os requisitos documentados no projeto para assegurar-se de que existe uma visão comum destes; estabelecer critérios objetivos de aceitação dos requisitos. Obter comprometimento com os requisitos: certificar-se de que os participantes do projeto estão comprometidos com as atividades que precisam ser executadas para que os requisitos sejam desenvolvidos. Ou seja, certificar-se de que os planos de projeto incluem atividades correspondentes aos requisitos identificados, identificando os responsáveis responsáveis por essas atividades. A atividade pode envolver a realização de avaliações de impacto e negociações para a acomodação de mudanças. Gerenciar mudanças nos requisitos: levando em conta o fato de que a mudan-

ça é inevitável, deve-se fornecer meios para a identificação da necessidade de

 

111

Engenharia de Requisitos

mudanças,  m udanças, sua documentação, análise de impacto, decisão decisão sobre a implementação ou não da mudança e ajustes decorrentes dela, antes de sua execução. As características da mudança e os argumentos argumentos para sua aprovação ou rejeição devem ser registrados para avaliações avaliações futuras. 



Manter rastreabilidade bidirecional dos requisitos : manter rastreabili rastreabilidade bidirecional entre os requisitos e os artefatos do projeto (requisitos de dade mais baixo nível, documentos, arquivos, código, testes, planos de trabalho). Identificar inconsistências entre os resultados do projeto e os requisitos requisitos: encontrar inconsistências entre os requisitos e os artefatos do pro jeto, pro jeto, inclusive nos planos de desenvolvimento dos requisitos, e iniciar a ação corretiva para resolvê-las.

 Área de Processo: Desenvolvimento de Requisitos O Desenvolvimento de Requisitos compreende a investigação, análise, validação, documentação e comunicação de requisitos do cliente e a tradução em requisitos de produto e de componente de produto. O desenvolvimento desenvolvi mentodestes de requisitos se distribui ao longo do ciclo de vida do projeto. A tabela a seguir resume as metas e práticas da área de processo de Desenvolvimento de Requisitos, descritas nas seções seguintes. Tabela 6.2: Área de processo de desenvolvimento de requisitos.

Área de Processo: Desenvolvimento Desenvolvimento de Requisitos ( Requirements  Requirements Development  Development ) Meta

Práticas

(SG1) Desenvolver requisitos do cliente

(SP1.1) Elicitar necessidades.

“Necessidades, expectativas, restrições e interfaces dos stakeholders são levantadas e traduzidas em requisitos do cliente.”

(SP1.2) Desenvolver os requisitos do cliente.

(SG2) Desenvolver Requisitos do Produto

(SP2.1) Estabelecer requisitos de produto e de componentess de produto. componente

“Requisitos do cliente são refinados e elaborados (SP2.2) Alocar requisitos de componente de produto. para desenvolver requisitos de produto e de (SP2.3) Identificar requisitos de interface. componentess de produto.” componente

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

112

Área de Processo: Desenvolvimento Desenvolvimento de Requisitos ( Requirements  Requirements Development  Development ) Meta

Práticas

(SP3.1) Estabelecer conceitos operacionais e cenários. (SG3) Analisar e Validar Requisitos

(SP3.2) Estabelecer uma definição de funcionalidade requerida.

“Os requisitos são analisados e validados, e uma definição de funcionalidade requerida requerida é desenvolvida.”

(SP3.3) Analisar requisitos. (SP3.4) Analisar requisitos para alcançar equilíbrio. (SP3.5) Validar requisitos com métodos abrangentes.

Meta: Desenvolver Requisitos do Cliente Desenvolver requisitos do cliente significa listar, definir, analisar e refinar as necessidades e restrições informadas pelos stakeholders do sistema. Para que essa meta seja alcançada, o CMMI recomenda as seguintes práticas:   Elicitar necessidades: obter, elaborar e documentar as necessidades, expectaElicitar tivas e restrições dos stakeholders para todas as fases do ciclo de vida do sistema; refinar essas informações, analisando suas necessidades necessidades implícitas.  Desenvolver os requisitos do cliente: traduzir as necessidades levantadas levantadas em requisitos do cliente; refinar ainda mais a lista de necessidades, necessidades, resolvendo conflitos e completando lacunas nas definições obtidas dos stakeholders; incluir restrições do cliente com relação à verificação veri ficação (conformidade do sistema com relação aos requisitos definidos) e validação (conformidade do sistema com relação às necessidades do usuário).

Meta: Desenvolver Requisitos do Produto Esta meta trata da definição de requisitos mais detalhados e precisos, isto é, requisitos de produto e de componentes de produto. São derivados das necessidades dos stakeholders e complementados com requisitos decorrentes de restrições técnicas, de escolhas de arquitetura da solução solução e de outras considerações semelhantes. Esses requisitos são relacionados a funções, objetos, processos, testes e inclusive pessoas, em um processo chamado de alocação de requisitos. Após a execução desse processo, os requisitos são definidos como alocados. As práticas que garantem o alcance da meta de desenvolvimento de requisitos requisitos do produto são:

 

Engenharia de Requisitos

113

  Estabelecer requisitos de produto e de componentes de produto :







consiste con siste em traduzir os requisitos do cliente em um conjunto de requisitos de produto, descritos em terminologia técnica, que podem ser utilizados, utili zados, por exemplo, para decisões de projeto (design). Esses requisitos podem originar-se não apenas de requisitos do cliente, mas também de restrições técnicas, necessidade de conformidade com padrões para conexão de sistemas etc. Essa atividade também se preocupa em definir a relação entre os requisitos (rastreabilidade) para que possa ser realizada realizada uma análise de impacto quando houver uma possível requisição de mudança, no futuro. requisitos Alocar requisitos de componente de produto: significa alocar os requisitos a funções, componentes de produto e restrições de projeto (design). ( design). Também inclui a tarefa de relacionar esses requisitos entre si. Identificar requisitos de interface: identificar interfaces entre funções e entre objetos, entre produtos e entre componentes de produtos. Essas interfaces passam a fazer parte da definição da arquitetura do sistema.

Meta: Analisar e Validar Requisitos Esta meta dá suporte às duas metas anteriores, ou seja, suas práticas apoiam o desenvolvimento de requisitos do cliente, de produto e de componente de produto. Os objetivos são a definição da funcionalidade requerida, a determinação do impacto do ambiente operacional definido sobre a habilidade de satisfazer as necessidades dos stakeholders, a validação dos requisitos com o intuito de aumen aumentar tar a probabilidade de que o sistema resultante funcione como o cliente espera. 



As práticas necessárias para alcançar esta meta são: Estabelecer conceitos operacionais e cenários: o conceito operacional define a interação entre o produto, o usuário e o ambiente, satisfazendo necessidades operacionais, de manutenção e de suporte. Um cenário é uma sequência de eventos que podem ocorrer durante o uso de um sistema, que q ue é utilizada para explicitar necessidades dos stakeholders. Essa prática recomenda estabelecer e manter (desenvolver, documentar, utilizar e refinar) o conceito operacional e seus cenários associados. Estabelecer uma definição de funcionalidade requerida: desenvolver, documentar, utilizar e revisar uma definição de funcionalidade requerida requerida do sistema. A funcionalidade requerida é representada por informações in formações que descrevam como o produto será usado (por exemplo: ações, sequências, entradas, saídas etc.). Exemplos de representação dessa arquitetura podem ser casos de uso detalhados ou diagramas de atividade.



Analisar requisitos: com o maior detalhamento do sistema, existe exi ste uma melhor compreensão de seus produtos e componentes de produtos. A melhor com-

 

114





 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

preensão pode levar a um refinamento dos requisitos. A prática de análise de requisitos inclui esse refinamento, a análise da rastreabilidade de requisitos para verificar se todos os requisitos identificados identi ficados são necessários e suficientes ao sistema, analisar a qualidade dos requisitos (consultar seção Qualidades do Conjunto de Requisitos) e a identificação de requisitos-chave, que serão utilizados para medir o progresso do desenvolvimento do sistema. Analisar requisitos para alcançar equilíbrio: essa atividade se refere ao exercício de balanceamento que deve ser feito pelo cliente com o apoio da equipe do projeto. Ao definir suas necessidades e restrições, o cliente pode manifestar requisitos contraditórios. As dependências entre requisitos requisitos e as alternativas para resolução de seus conflitos de forma vantajosa devem ser apresentadas ao cliente para que ele decida como ajustá-los. Estratégias comuns executadas nesta prática são as simulações simulações e a prototipação. Uma avaliação de riscos nos requisitos pode ser utilizada para auxiliar esta prática.  Validar requisitos com métodos abrangentes: os requisitos devem ser validaValidar dos, ou seja, é preciso os requisitos documen documentados tadosser correspondem realmente àsassegurar-se necessidadesdedoque cliente. Essa verificação verifica ção deve feita através de técnicas comprovadas, como simulações e o uso de protótipos para que o cliente e os usuários do sistema verifiquem verifiquem o significado dos requisitos acordados.

 A Engenharia de Requisitos no RUP O método proposto no livro baseia-se fortemente nas atividades de RUP voltadas para a engenharia de requisitos. Assim, esta seção apresenta uma descrição des crição em alto nível dos objetivos e atividades de RUP relacionados à engenharia de requisitos. A engenharia de requisitos é tratada, em RUP, através da disciplina de Requisitos, que possui os seguintes objetivos (IBM, 2003):  Estabelecer e manter um acordo com os clientes e outros stakeholders sobre o que o sistema deve fazer.  Fornecer, aos desenvolvedores do sistema, um melhor entendimento dos requisitos do sistema. Definir os limites do sistema: o que faz parte do sistema e o que não faz.   Fornecer uma base para o planejamento do conteúdo técnico das iterações itera ções do processo de desenvolvimento. 

Fornecer uma base para a estimativa de custo e de tempo para o desenvolvimento do sistema.

 

115

Engenharia de Requisitos

Definir uma interface com o usuário do sistema, com foco nas necessidades necessidades e objetivos dos usuários. Para alcançar esses objetivos, a disciplina de Requisitos de RUP segue o fluxo de trabalho ilustrado no diagrama de atividades da figura apresentada em seguida.  



Figura 6.3: Fluxo de trabalho de requisitos.

Fluxo de Trabalho Trabalho de Requisitos Req uisitos O fluxo de trabalho apresentado na figura anterior possui os seguintes subfluxos:  

Analisar o problema; Compreender as necessidades dos stakeholders;



Definir o sistema;

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

116

 

  

Gerenciar o escopo do sistema; Refinar a definição do sistema; Gerenciar mudanças nos requisitos.

Cada um destes subfluxos possui objetivos específicos e contéme atividades executadas para alcançar esses objetivos. Os subfluxos, seus objetivos atividades atividades são brevemente descritos a seguir. Note que diversas atividades são executadas executadas repetidamente, ao longo de mais de um subfluxo. Isso acontece porque uma mesma atividade pode ter diferentes objetivos, dependendo do status geral do projeto. Assim, a execução de uma atividade se dá com foco diferenciado, dependendo dependendo do subfluxo a que pertence.

Figura 6.4: Representação do subfluxo - analisar o problema.

 Analisar o Problema Objetivos Os objetivos do subfluxo Analisar o Problema são relacionados à obtenção de uma visão uniforme do sistema por todos os envolvidos e uma descrição clara, detalhada e concisa dessa visão. Tais objetivos são:  Obter um acordo quanto ao problema que está sendo resolvido e suas causas. Ou seja, certificar-se de que todas as partes interessadas concordam concordam quanto ao problema a ser resolvido. também se preocupa em desenvolver uma terminologia comumEste paraobjetivo utilização ao longo da documentação do sistema.

 

Engenharia de Requisitos

 







117

Identificar os stakeholders. Conforme descrito nas seções de definição deste trabalho, identificar os stakeholders é uma tarefa essencial no desenvolvimento desenvolvimento de uma solução efetiva. Definir os limites do sistema. Os limites do sistema são a fronteira entre o que faz parte dacom solução e o que está e stá ao redor dela, ou seja, entidades externas que interagem o sistema. Identificar restrições impostas ao sistema. Conforme mencionado anteriormente neste trabalho, restrições limitam o grau de liberdade que se tem no desenvolvimento de uma solução. As restrições podem ser de ordem econômica, política, técnica ou ambiental e podem estar relacionadas relacionadas a prazos, recursos ou orçamento.

 Atividades Envolvidas As atividades necessárias para alcançar os objetivos do subfluxo Analisar o Problema são: Capturar um Vocabulário Comum: definir um vocabulário comum que pos sa ser utilizado em todas as descrições textuais do sistema, especialmente especial mente na descrição de casos de uso.  Desenvolver o Plano de Gerência Ger ência de Requisitos: desenvolver um plano para a documentação de requisitos, seus atributos e orientações para rastreabilidade e gerência de requisitos do produto. Esse plano especifica mecanismos de informação e controle que serão coletados e utilizados para medir, relatar e controlar mudanças nos requisitos do produto.  Encontrar Atores e Casos de Uso: delinear a funcionalidade do sistema, utilizando a modelagem de casos de uso; definir o que será tratado pelo sistema e o que será tratado fora dele; definir quem (pessoas) e o que (sistemas, dispositivos) estará interagindo com o sistema; dividir o mo modelo delo em pacotes com atores e casos de uso; criar diagramas de modelos de casos de uso; desenvolver a descrição inicial dos casos de uso do modelo.  Desenvolver a Visão: obter um acordo sobre que problemas precisam ser resolvidos; identificar os stakeholders do sistema; definir os limites do sistema; descrever as principais características do sistema.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

118

Compreender as Necessidades dos Stakeholders

Figura 6.5: Compreender necessidades dos stakeholders.

O principal objetivo desse subfluxo é obter informações de todos os stakeholders  do projeto, de forma a compreender suas necessidades, para que elas sejam usadas como base para a definição das características do sistema. As características do sistema são guardadas no documento de Visão. As necessidades dos stakeholders podem ser representadas por regras de negócio, requisitos de melhoria, listas de requisições. O levantamento dessas informações pode ser feito de formas variadas, incluindo o recebimento de documentos produzidos pelos stakeholders, a realização de entrevistas e workshops de requisitos, a condução de reuniões entre os envolvidos e outras técnicas de elicitação de requisitos. É importante observar que, embora esse subfluxo seja executado principalmente nas fases de Iniciação e Elaboração, suas atividades também são importantes durante o decorrer do projeto, já que novas necessidades de negócio podem gerar mudanças (controladas) no escopo do sistema.

 Atividades Envolvidas 



As atividades necessárias para alcançar estes objetivos são: Capturar um Vocabulário Comum: continuar a definição de um vocabulário vocabulário comum que possa ser utilizado em todas as descrições textuais do sistema, incluindo conceitos aprendidos ao longo das demais atividades atividades do projeto.  Elicitar os Requisitos dos Stakeholders: compreender quem são os stakeholders   Elicitar

do projeto e quais são seus pontos de vista; listar os requisitos requi sitos e necessidades

 

119

Engenharia de Requisitos







dos stakeholders e as consequentes características que o sistema deve apresentar; priorizar esses requisitos. Desenvolver a Visão: complementar e refinar as principais características caracterís ticas do sistema, definidas no subfluxo Analisar o Problema. Encontrar Atores e Casos de Uso: continuar a procura atores e casos de uso; refinar os modelos já criados, complementando e melhorando descrições de atores e principalmente a descrição inicial dos fluxos de execução de casos de uso; ajustar interações entre esses elementos, de acordo com a compreensão atual do sistema (que fica mais elaborada ao longo de cada fase do projeto).  Gerenciar Dependências: gerenciar o escopo do projeto e as mudanças nos Gerenciar requisitos; essa gerência é feita com base em atributos especiais dos requisitos (importância, complexidade, tamanho etc.) e também leva em conta a rastreabilidade entre os requisitos, ou seja, a influência que cada requisito tem sobre os demais.

Definir o Sistema Objetivos Os objetivos do subfluxo de definição do sistema são a uniformização do conhecimento e o refinamento da definição de funcionalidades que o sistema deve apresentar.

Figura 6.6: Definir o sistema.

Assim, as atividades desse subfluxo devem alinhar o conhecimento da equipe sobreatributos; o sistemadescrever em desenvolvimento; refinar osde requisitos já registrados seus os fluxos de execução alguns casos de uso e,(Visão) por fim,e avaliar os resultados parciais.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

120

 Atividades Envolvidas 







As atividades necessárias para alcançar os objetivos descritos anteriormente anteriormente são: Desenvolver a Visão: complementar e refinar as características do sistema sistema documentadas até a execução: gerenciar desse subfluxo.  Gerenciar Dependências Gerenciar o escopo do projeto e as mudanças nos requisitos; essa gerência é feita com base em atributos especiais dos requisitos (importância, complexidade, tamanho etc.) e também leva em conta a rastreabilidade entre os requisitos, ou seja, a influência que cada requisito tem sobre os demais. Capturar um Vocabulário Comum: continuar a definição de um vocabulário vocabulário comum que possa ser utilizado em todas as descrições textuais do sistema, incluindo conceitos aprendidos ao longo das demais atividades atividades do projeto. Encontrar Atores e Casos de Uso: continuar a procura atores e casos de uso; refinar os modelos já criados, complementando e melhorando descrições des crições de atores e principalmente de casos de uso; ajustar interações entre esses e sses elementos, de acordo com a compreensão atual do sistema (que fica mais elaborada ao longo de cada fase do projeto). O foco principal prin cipal desta atividade dentro do subfluxo Definir o Sistema é descrever os fluxos de execução dos casos de uso.

Gerenciar o Escopo do Sistema Objetivos O subfluxo Gerenciar o Escopo do Sistema tem a tarefa de assegurar que os objetivos do projeto serão alcançados.

Figura 6.7: Gerenciar o escopo do sistema.

 

Engenharia de Requisitos

121

As atividades executadas levam à seleção dos requisitos do sistema a serem desenvolvidos em cada iteração. Os requisitos são escolhidos de forma a balancear balancear as variáveis de escopo e recursos (tempo, pessoal, orçamento etc.). Os requisitos selecionados para o projeto (ou para uma iteração específica) representam seu escopo. A seleção é feita com base nos atributos dos requisitos, que incluem importância e impacto para o negócio, complexidade, impacto na arquitetura, estabilidade, risco etc. A definição e o refinamento dos atributos de requisitos, bem como a compreensão da rastreabilidade desses requisitos, também são objetivos desse subfluxo.

 Atividades Envolvidas As atividades necessárias para alcançar os objetivos desse subfluxo são: 





Priorizar P riorizar Casos dedefinir Uso: definir  em os casoscasos de uso cenários qrios ue serão analisados cada iteração; os principais deeuso e cenários cenáque que são significativos do ponto de vista das funcionalidades do sistema, do ponto de vista da arquitetura e em contextos específicos como performance, adaptabilidade ou outro ponto importante em termos termos de restrições do sistema. Desenvolver a Visão: complementar e refinar as características do sistema sistema documentadas até a execução desse subfluxo. É importante destacar destacar que mudanças feitas na documentação de Visão fora da etapa de Iniciação devem ser tratadas como requisições de mudança, ou seja, devem de vem seguir o processo de verificação de impacto, incluindo atividades como Gerenciar Dependências e Gerenciar Requisições de Mudança. Gerenciar Dependências: gerenciar o escopo do projeto e as mudanças nos requisitos; essa gerência é feita com base em atributos especiais dos requisitos (importância, complexidade, tamanho etc.) e também leva em conta a rastreabilidade entre os requisitos, ou seja, a influência que cada requisito tem sobre os demais.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

122

Figura 6.8: Representação do subfluxo.

Refinar a Definição do Sistema Objetivos Os objetivos desse fluxo de trabalho levam ao refinamento da solução descrita para o sistema. Nesse subfluxo, os requisitos levantados inicialmente são detalhados o suficiente para que seu projeto possa ser iniciado. Os objetivos são:  Detalhar o fluxo de execução dos casos de uso. Detalhar especificações suplementares, referentes a requisitos que não se en caixam nas descrições de casos de uso.  Desenvolver especificações de requisitos de software, quando necessário.   Modelar e prototipar a interface de usuário do sistema. Modelar

 Atividades Envolvidas 

As atividades necessárias para alcançar estes objetivos são: Detalhar um Caso de Uso: descrever detalhadamente um caso de uso que  já tenha sido identificado em atividades anteriores. O caso de uso também já deve ter sido brevemente descrito e seus principais passos identificados. A descrição detalhada inclui uma explicação minuciosa do fluxo de execução (principais prérelacionadas e pós-condições, pós-condi fluxos de erro e fluxos al-é ternativos epassos demaise iterações), informações relacio nadas ções, ao caso de uso. A descrição

utilizada para verificar que a equipe equipe e o cliente compreendem o funcionamen to desejado do sistema da mesma forma.

 

Engenharia de Requisitos

123

  Detalhar os Requisitos de Software: recolher, detalhar e organizar o conjunto de artefatos que descreve, de forma completa, os requisitos de software do sis-



tema. Os principais artefatos são os atributos dos requisitos, requisitos, as especificações suplementares (restrições que não se aplicam ao contexto específico de um





caso de e a especificação de requisitos de software , listando todos os requisitos douso) sistema (geralmente uma lista de casos de uso).  Modelar a Interface com o Usuário: construir um modelo de interface do sisModelar tema com o usuário, considerando os atores, os fluxos de eventos dos casos de uso e requisitos de usabilidade; identificar classes de interface ( boundary classes) entre o sistema e seus usuários; descrever a interação entre essas classes e complementar os demais modelos do sistema a partir das novas definições feitas.  Prototipar a Interface com o Usuário: criar um protótipo de interface do sisPrototipar tema com o usuário, partindo do projeto de elementos da interface interface (por exemplo: janelas, páginas web) até sua implementação; avaliar os resultados com os usuários.

Gerenciar Requisições de Mudança Objetivos Ao longo do projeto, mudanças nas necessidades dos stakeholders  são esperadas. Tais mudanças ocorrem em vista de novas necessidades de negócio, melhor compreensão do sistema por parte de todos os envolvidos, problemas e soluções encontrados nas primeiras iterações do desenvolvimento de software. 







A gerência dessas mudanças tem os seguintes objetivos: Avaliar requisições de mudança submetidas formalmente e determinar seu impacto no conjunto de requisitos existente. O histórico das alterações altera ções de um requisito é uma parte de grande importância nessa avaliação. avaliação. Assim, as decisões tomadas devem ser devidamente registradas, assim como os argumentos utilizados na tomada de decisão. Estruturar o modelo de casos de uso, atualizando-o de acordo com as mudanças aceitas. Definir atributos e rastreabilidade entre requisitos de forma apropriada ao escopo corrente. Verificar formalmente que os resultados da disciplina de Requisitos estão de acordo com a visão que o cliente tem do sistema.

 Atividades Envolvidas

As atividades necessárias para alcançar os objetivos do subfluxo Gerenciar Requisições de Mudança são:

 

124

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

  Estruturar o Modelo de Casos de Uso : refinar o modelo de casos de uso, ex-



traindo comportamento comum para casos de uso abstratos e definindo relações “include” ou “extend”; “extend”; procurar novos atores abstratos abstratos que definam papéis compartilhados por vários atores. 



Gerenciar G erenciar Dependências: gerenciar o escopo do projeto e as mudanças nos  requisitos; essa gerência é feita com base em atributos especiais dos requisitos (importância, complexidade, tamanho etc.) e também leva em conta a rastreabilidade entre os requisitos, ou seja, a influência que cada requisito tem sobre os demais. Revisar os Requisitos: verificar formalmente que os resultados da disciplina de Requisitos estão de acordo com as expectativas do cliente; revisar o estado atual dos requisitos e as requisições de mudança.

Distribuição das Atividades por Fase de Desenvolvimento As atividades da disciplina deConstrução Requisitos ede RUP sãodedistribuídas longo das fases de Iniciação, Elaboração, Transição acordo comao o plane jamento do projeto e de cada uma de de suas iterações. O fluxo de execução da disciplina de Requisitos e as características específicas específicas de cada atividade levam a um certo posicionamento da atividade dentro das fases de RUP. O processo de engenharia de requisitos proposto no livro, apresentado mais adiante, utiliza essa tendência de posicionamento de atividades para simplificar simplificar os subfluxos utilizados. Tal processo define a maioria de suas atividades de forma a serem execu executadas tadas em subfluxo.em Issopontos faz com que o foco da atividade fique mais claro, já queapenas ela nãoum é executada variados do processo, facilitando sua compreensão pela equipe de trabalho.

Métodos Ágeis e a Engenharia de Requisitos Embora os métodos ágeis sejam caracterizados pelo foco em princípios, valores e práticas, e não em uma definição rigorosa de processos, esses métodos oferecem diversas orientações sobre como executar atividades da engenharia de requisitos. O elemento básico da engenharia de requisitos em diversos métodos ágeis é a história do usuário, definida como parte do método de XP. Uma história do usuário é uma funcionalidade, um requisito de alto nível do sistema, detalhado apenas o suficiente para permitir que os desenvolvedores pos-

sam estimar o esforço necessário para implementá-la.

 

Engenharia de Requisitos

125

Podemos caracterizar e descrever três aspectos básicos das histórias do usuário:

1. Cartões São utilizados como meio de armazenamento das histórias do usuário. O objetivo dos cartões é registrar a história com o mínimo de informações que permitam identificá-la durante o processo de desenvolvimento. Inicialmente, o cartão pode conter apenas o nome da história. Em sessões de planejamento, podem ser registrados sua prioridade e seu custo estimado. O cartão será entregue ao programador no momento da implementação.

2. Conversação O conteúdo da história é definido através da conversação, ao longo do tempo, geralmente durante o planejamento, ao estimar o esforço e ao planejar a implementação. Embora a descrição do requisito seja feita verbalmente, os detalhes podem ser registrados em documentos, storyboards, planilhas etc. 3. Confirmação

É alcançada através da realização dos testes de aceitação, que são criados pelo cliente e podem ser implementados pela equipe de desenvolvimento. Os testes contêm quesitos a serem verificados para que se considere a história do usuário implementada. Diversos autores têm apresentado um conjunto de melhores práticas ágeis para a engenharia de requisitos. Algumas dessas práticas são elencadas a seguir:  Os stakeholders participam ativamente, levantando, definindo e priorizando priorizando os requisitos, e são inclusive convidados a modelar e documentar documentar os requisitos  juntamente com os desenvolvedores. Para que essa prática seja facilitada, é importante ensinar, aos stakeholders, as técnicas utilizadas na engenharia de requisitos e favorecer a utilização de recursos recursos simples, preferencialmente lápis, papel e quadros, em vez de ferramentas ferramentas que possam excluir a participação dos stakeholders. A abordagem ideal para modelagem é iniciar com uma noção geral do sistema  e depois partir para o detalhamento dos requisitos.



A documentação dos requisitos deve seguir o princípio da simplicidade, simplicidade, ge rando apenas os documentos necessários, com o mínimo conteúdo conteúdo que seja su-

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

126



ficiente para as demais atividades do processo de desenvolvimento. desenvolvimento. O objetivo é implementar requisitos, não documentá-los. O apoio da gerência interna e externa, ou seja, da própria organização e da equipe do cliente é vital para a aplicação de práticas ágeis de forma bem-su-

cedida. Schwaber, um dos pais do SCRUM, descreve estratégias de engenharia de requisitos em processos ágeis. A colaboração entre stakeholders e desenvolvedores é mencionada novamente novamente e o desenvolvimento iterativo é citado como forma de assegurar o sucesso do pro jeto, implementando partes do sistema para para validação pelo cliente. Também é recomendada a realização de reuniões diárias, para disseminar o status do projeto e orientar as atividades da equipe, eq uipe, que se auto-organiza da forma que acredita ser a mais efetiva. Por fim, afirma-se que a arquitetura, a estrutura da equipe e os requisitos devem emergir ao longo do projeto. Para projetos maiores, contudo, a arquitetura arquite tura do sistema é detalhada logo no início do projeto, simplificando a coordenação coorde nação de múltiplos times. Vamos ver um pouco mais sobre histórias de usuário (argh, lá vem o termo ter mo “usuário” de volta) no capítulo sobre SCRUM.

Exercícios 1)  Defina engenharia de requisitos. 2)  Como se divide a engenharia de requisitos? atividades. 3)  O processo de elicitação de requisitos tem quatro dimensões de atividades. Quais são elas? 4)  Definições de outros sistemas aos quais o sistema deve integrar-se fazem parte parte da documentação de requisitos? 5)  A gestão de mudanças mudanças faz parte da gestão de requisitos? Justifique. 6)  A engenharia engenharia de requisitos no CMMI abrange abrange quais áreas de processo? 7)  Explique o que significa estabelecer requisitos de produto e de componentes de de produto. 8)  Onde está a engenharia engenharia de requisitos no RUP? Explique.

9)  Qual o objetivo de refinar a definição do do sistema?

 

Técnicas para Análise de Requisitos

7

“Errar é humano, colocar a culpa no computador é mais humano ainda.”

 Processo de Levantamento e Análise de Requisitos Processo O início para toda a atividade de desenvolvimento de software  é o levantamento de requisitos, sendo essa atividade repetida em todas as demais etapas da engenharia de requisitos.

Um processo genérico de levantamento e análise contém as seguintes atividades: com preensão   Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação.   Coleta de requisitos: é o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio desenvolve-se mais durante essa atividade;   Classificação: essa atividade considera o conjunto não estruturado dos requi-

sitos e os organiza em grupos coerentes.

 

128

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

  Resolução de conflitos: quando múltiplos stakeholders estão envolvidos, os re-



quisitos apresentam conflitos. Essa atividade tem por objetivo solucionar solucionar esses conflitos.   Definição das prioridades:  em qualquer conjunto de requisitos, alguns são mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes.   Verificação de requisitos: os requisitos são verificados para descobrir se estão e stão completos e consistentes e se estão em concordância com o que os stakeholders  desejam do sistema. O levantamento e a análise de requisitos formam um processo iterativo, com uma contínua validação de uma atividade para outra, conforme exemplificado exemplifi cado pela figura seguinte. O problema de não saber especificar corretamente o que o sistema deve fazer é muito antigo.

Figura 7.1: Processo de levantamento e análise de requisitos.

Um velho colega Pompilho (1995) cita um exemplo do relatório produzido por McKinsey, em 1968, e mencionado por B. Langefords e B. Sundgren em que se afirmava que dois terços das empresas estudadas estavam desapontados com o atendimento recebido em sistemas de informação. Após mais de 40 anos da elaboração do relatório a situação não é muito diferente. Algumas das razões para o baixo grau de satisfação dos usuários para os sis-

temas destacam se em seguida: A fase de levantamento de requisitos do projeto, em que não é utilizada uma   técnica adequada para extrair os requisitos do sistema.  

Técnicas para Análise de Requisitos

129

As falhas e as dificuldades dos analistas em entender e não descrever os requisitos do sistema de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto.   Entre as dificuldades encontradas na fase de levantamento de requisi req uisitos tos estão: • O interessado principal do sistema não sabe o que quer que o sistema sistema faça ou sabe e não consegue transmitir para o analista. • Requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes. • Um stakeholder  errado   errado afeta em perda de tempo e dinheiro para ambas as partes relacionadas ao desenvolvimento do sistema. Identifica-se um levantamento de requisitos adequado através da boa definição do projeto, da efetividade do projeto, de informações necessárias a um perfeito diagnóstico e de soluções inteligentes.  



Quanto levantamento requisitos inadequado, o resultado um diagnóstico pobreaocom conclusõesde comprometidas, não identificação das écausas dos problemas, custos elevados, prazos vencidos ou comprometedores, omissão de processos fundamentais e descréditos. De nada adiantam as técnicas de diagramação UML, a utilização de RUP ou mais o que for, se esse passo, que é o mais importante de todos, não for realizado rea lizado com sucesso e corretamente.

Técnicas de Levantamento de Requisitos As técnicas de levantamento de dificuldades requisitos têm por objetivo sistemas e negócios a superar essas relativas a estaajudar fase. analistas de Vamos apresentar inicialmente as técnicas para depois nos centrarmos em casos de exemplo para estudo e aprendizagem. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.

Levantamento Orientado a Pontos de Vista Para qualquer sistema, de tamanho médio ou grande, normalmente há diferentes tipos de interessado final. Muitos stakeholders têm algum tipo de interesse nos requisitos do sistema.

Por esse motivo, mesmo para um sistema relativamente simples, existem muitos pontos de vista diferentes que devem ser considerados.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

130

Os diferentes pontos de vista a respeito de um problema significam que pessoas ‘veem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que possuem requisitos comuns. Este é um ponto de perigo no processo de análise e levantamento de requisitos. As abordagens orientadas a ponto de vista, na engenharia de requisitos, req uisitos, reconhecem esses diferentes pontos de vista e os utilizam para estruturar e organizar organizar o processo de levantamento e os próprios requisitos. Uma importante capacidade da análise orientada a pontos de vista é que ela reconhece a existência de várias perspectivas e oferece um  framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. Conceitos-Chave Ponto de vista: uma perspectiva para examinar o sistema.

Por exemplo, dodinheiro. ponto de vista do cliente, o sistema de caixa eletrônico (ATM) permite retirada de Do ponto de vista do gerente, o sistema permite limitar o montante de dinheiro retirado.   pontos de vista de interação (cliente); pontos de vista indiretos (gerente);     pontos de vista de domínio (comunicação interbancos). Serviço: funcionalidade propiciada pelo sistema, neste caso a retirada de dinheiro e limitação do montante retirado. Nessa técnica em sessões ao de sistema. brainstorming analistas e stakeholders procu  procuram ram as “palavras-chave” associadas Destas sessões, os pontos de vista e serviços são identificados.

Figura 7.2: Exemplos de pontos de vista, serviços serv iços e requisitos não funcionais.

O método VORD (Viewpoint-Oriented Requirements Definition - definição de requisitos orientada a ponto de vista) foi projetado como um  framework orien  orientado tado

a serviço para o levantamento e análise de requisitos.

 

131

Técnicas para Análise de Requisitos

A primeira etapa da análise de ponto de vista é identificar os possíveis pontos de vista. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.

Figura 7.3: Levantamento orientado a pontos de vista.

Hierarquias de Pontos de Vista

A segunda etapa é a estruturação de pontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior.

 

132

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A etapa de documentação do ponto de vista tem por objetivo refinar a descrição dos pontos de vista e serviços identificados. O mapeamento de sistema conforme ponto de vista envolve identificar objetos, no caso de um projeto orientado a objetos, utilizando as informações de serviços que estão encapsuladas nos pontos de vista. A figura seguinte exemplifica a técnica de levantamento orientado a ponto de vista.

Figura 7.4: Fluxo da técnica de ponto de vista.

Uma importante capacidade da análise orientada a pontos de vista é que ela reconhece a existência de várias perspectivas e oferece um  framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. É importante salientar que o mapeamento de sistema conforme ponto de vista depende da aplicação de técnicas de brainstorming.

Estudo Etnográfico A etnografia é um ramo da antropologia que lida com o estudo de culturas humanas. Grego

ethnos == escrita nação graphein

A escrita de uma cultura

 

133

Técnicas para Análise de Requisitos

Foi recentemente expandido para outras áreas, como é o caso da Interação Homem-Máquina ou atividades de levantamento de requisitos, como uma metodologia que pretende obter uma descrição qualitativa do comportamento e necessidades de utilizadores, no seu ambiente natural. A etnografia pode ser definida da seguinte forma: “Método em que o observador participa da vida quotidiana das pessoas em estudo, quer assumindo o papel de investigador, quer assumindo um papel inserido na comunidade.” Os estudos etnográficos são uma análise de componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que ela sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário, é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais.

Figura 7.5: Universo da etnogafia.

 

134

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Essa observação pode ser acompanhada de registros de áudio/vídeo, todavia não convém usá-los em demasia, visto que o tempo necessário para os processar pode ser demasiado. Busca-se obter o ponto de vista dos observados.

O objetivo principal do analista é observar através do ponto de vista das pessoas que estão sendo observadas. Com isso em mente, é facilitada ao analista a compreensão da verdadeira importância das observações. Nessa técnica assume-se que o representante do cliente observado desempenha desem penha as suas funções “corretamente”, pelo que convém ter algum cuidado na sua escolha. A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional, bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. Osum cientistas sociais ecompleto antropólogos usam técnicas de observação para desenvolver entendimento e detalhado de culturas particulares. Nessa técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais formais em que as pessoas estão envolvidas. Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos: requisitos:   Os requisitos derivados da maneira como as pessoas realmente trabalham, trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar.   Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas. Alguns itens importantes que devem ser executados antes, durante e depois de pois do estudo de observação: Antes, é necessário identificar as áreas de usuário a serem observadas, obter a aprovação das gerências apropriadas para executar as observações, obter os nomes e funções das pessoas-chave que estão envolvidas no estudo de observação obser vação e explicar a finalidade do estudo. Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado.

Para isso é preciso observar os agrupamentos organizacionais atuais, as facilidades manuais e automatizadas, coletar amostras de documentos e procedimentos procedimentos

 

Técnicas para Análise de Requisitos

135

escritos que são usados em cada processo específico que está sendo observado, e acumular informações estatísticas a respeito das tarefas, como frequência, fre quência, estimativas de volumes, tempo de duração para cada pessoa que está e stá sendo observada. Além de observar as operações normais de negócios apresentadas anteriormente, é importante observar as exceções. Depois, é necessário documentar as descobertas resultantes das observações observações feitas. Para consolidar o resultado, é preciso rever os resultados com as pessoas observadas e/ou com seus superiores. A análise de observação tem algumas desvantagens, como consumir bastante bastante tempo e o analista ser induzido a erros em suas observações; então entram e ntram as questões de conhecimentos básicos de caminhos e processos de negócios que insistimos que o analista deve possuir ou ter um mínimo de informações antecipadas. antecipadas. Muitas vezes observamos solicitações de contratação de analista com experiência na área Financeira, em Logística, em Planejamento de Produção, em área Comercial etc., mas isso decorre do fato de a formação universitária, além de não oferecer expertise mínima nas áreas de negócio, não ensinar esses métodos que acabamos de apresentar. Mas em geral a técnica de observação é muito útil e frequentemente usada não só para complementar descobertas, como para obtê-las sem outras técnicas. Os Dados Etnográficos são Informais

Os dados que resultam de uma investigação etnográfica provêm de diversas diversas fontes e chegam de diversas formas, desde descrições manuscritas de comportamentos ou procedimentos até descrições detalhadas de conversas ou processos. O volume de dados que se obtém e a sua importância relativa, antes de se realizar uma avaliação mais cuidada, tornam difíceis a formalização e a estruturação estrutu ração de toda a informação. É necessário entender o mundo sob a ótica destas pessoas. A seguir apresentamos uma lista dos tipos de dados que é possível captar, acompanhados de prováveis questões para o estudo etnográfico de levantamento de requisitos:   Descrições de comportamentos • Como as pessoas interagem? • Que tipo de interação ocorre?

Com que frequência frequência essa interação acontece? • Que sutilezas sutilezas existem nas tarefas das pessoas?

 

136

 



 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Descrições de conversas • Que tipos de discussões discussões as pessoas têm? • São discussões discussões relacionadas com alguma alguma tarefa? tarefa?

• Quem fala com quem? Esquemas do local de trabalho   • Como estão agrupadas as pessoas no local de trabalho? • Estão próximas ou afastadas? • Cada pessoa tem seu espaço definido ou estão agrupadas em cubículos? • Existe alguma área, local onde as pessoas se encontram?   Repercussões das tarefas nas pessoas • As tarefas parecem ser extenuantes extenuantes ou ou aborrecidas? aborrecidas? • Existe alguém que trabalhe mais que os outros? • As pessoas cooperam ativamente entre si? • Essa cooperação ajuda de algum modo o trabalho delas?   Conclusões que os dados sugerem • Que revelações contêm os dados? • Existe alguma generalização que possa ser feita? • O que de mais importante importante pode ser tirado das observações observações realizadas? realizadas? Contrariamente ao que se podia pensar, não existem receitas nem métodos (nem os anteriormente descritos) que se apliquem de tal maneira que uma investigação etnográfica tenha sucesso garantido. Assim sendo, e mais importante que todo o conhecimento teórico que se possa ter nessa área, qualquer pessoa que se aventure num estudo etnográfico deve ter certas qualidades e valências principalmente de foro humano e social. Essa pessoa deve se apresentar na sua área de trabalho, junto com as pessoas pes soas que deve observar, de modo educado, amável e não ameaçador, demonstrando demons trando que se preocupa com o trabalho das pessoas, porque está interessado nelas e as respeita. Deve saber ouvir os outros, encorajando-os, sem nenhum sentido de competição, interessado no que as pessoas fazem e dizem. Deve ser extremamente paciente, ter tolerância, e talvez o mais importante,

criar no observado uma sensação de confiança na sua pessoa, demonstrando que a sua função é ajudar a melhorar o seu trabalho e não colocá-lo em risco.

 

Técnicas para Análise de Requisitos

137

O primeiro passo para um estudo desta natureza, depois de interiorizado o que foi dito anteriormente, consiste em ter acesso ao local de trabalho onde se dará a observação. O significado de “ter acesso” não passa pela permissão dada por alguém responsável para iniciar uma investigação. O fundamental é conseguir ser aceito pelas pessoas que vão contribuir para a investigação, ser bem recebido (aspecto que parte muito do etnógrafo) para que as pessoas se sintam confortáveis e quase (voluntariamente) forçadas a colaborar. A etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:   Aqueles derivados da maneira como as pessoas realmente trabalham, em vez da maneira como as definições de processo dizem que elas deveriam trabalhar; Aqueles derivados da cooperação e conscientização das atividades de outras   pessoas. Um outro aspecto prático a ter em conta consiste em realizar o estudo em alinhamento com os interesses e necessidades da organização em causa. Isso pode parecer óbvio, mas existe um pormenor que não se pode descurar. O estudo não deve perturbar o normal funcionamento da organização, ou seja, é necessário, de algum modo, ser invisível na aplicação da Etnografia, sabendo recolher as informações necessárias, sendo minimamente intrusivo, cansativo can sativo e presente. A característica onipresente da etnografia, o elevado tempo gasto na sua execução, pode limitar alguns estudos etnográficos. e tnográficos. Não se deve, e de alguma maneira é bastante difícil, conhecer toda a organização quanto a processos e tarefas de uma vez só. É preferível realizar pequenos estudos etnográficos bastante focados em pequenas áreas de ação, do que um estudo gigantesco que, além de requerer uma imensidão de tempo e recursos, pode não trazer os melhores resultados. Hugh Beyer e Karen Holtzblatt foram os pioneiros na aplicação de uma técnica de "entrevistas etnográficas", a qual eles denominaram contextual inquiry (investigação contextual). Essa técnica rapidamente se tornou uma referência na indústria de software. Seu método foi baseado no modelo mestre-aprendiz, isto é, o entrevistador observava e fazia perguntas como se fosse um principiante, e o usuário, seu mestre. Princípio: o projeto do sistema deve dar suporte à prática de trabalho dos usuários e ampliá-la.

 

138

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A seguir, citamos dois complicadores do trabalho de levantamento de requisitos:   As pessoas não estão conscientes de sua própria prática de trabalho; todo o seu conhecimento é tácito. Isso é especialmente verdadeiro nas situações em que as pessoas estão fora do contexto de seu ambiente cotidiano. É o que acontece muitas vezes em reuniões para levantamento de requisitos com usuários em uma sala que nada tem a ver com seu ambiente rotineiro.   Os usuários somente se tornam conscientes de sua própria prática de trabalho quando estão imersos em seus contextos normais de uso - o que fazem em detalhes e por que o fazem -, o que justifica a razão de estarmos imersos com eles em seu ambiente normal de trabalho em um estudo etnográfico. As equipes de projeto raramente têm a habilidade crítica de ver a estrutura do trabalho feito por outros, o que consiste em olhar além da superfície a fim de compreender as intenções de detalhes, estratégias e motivações de controlar a forma como o trabalho é feito. Além disso, metodologías de desenvolvimento típicas fazem muito pouco para encorajar essa perspectiva. Como isso é extremamente importante, realizarmos um Design Contextual com modelos de trabalho usados para capturar o trabalho de indivíduos e organizações em diagramas. Cinco modelos diferentes podem e devem ser utilizados, resultando em cinco perspectivas sobre a forma como o trabalho é feito: Um modelo de fluxo (workflow) captura a comunicação e a coordenação entre as pessoas para realizar determinado trabalho. Revela os grupos de trabalho formais e informais, e os padrões de comunicação críticos para a realização do trabalho. Mostra, ainda, como um trabalho é dividido em papéis formais e informais, e responsabilidades. Um modelo cultural captura as políticas e restringe o modo como o trabalho é realizado. Mostra como as pessoas são limitadas e como elas operam com essas limitações para garantir que o trabalho seja feito. Um modelo de sequência de atividades apresenta os passos detalhados para realizar cada tarefa importante para a execução de um trabalho. Mostra as diferentes estratégias e métodos que as pessoas usam, as metas ou as intenções nas etapas da tarefa estão tentando realizar, e os problemas que encontram pelo caminho. Um modelo físico mostra como o ambiente físico facilita ou atrapalha o trabalho que está sendo realizado. Isso envolve a descoberta de planilhas eletrônicas, anotações em papel, agendas, calculadoras etc. Também mostra como as pessoas organizam seu ambiente para tornar o trabalho mais fácil. Um modelo de artefatos mostra os artefatos que são criados e usados para fa-

zer o trabalho (observe bem a utilização de planilhas eletrônicas). Esses artefatos

 

Técnicas para Análise de Requisitos

139

revelam o que as pessoas pensam de seu trabalho - quais conceitos elas usam e como os organizam para desempenhar suas atividades de forma satisfatória. Vantagens e Desvantagens

qualquer a etnografia apresenta e desvantagensComo que ajudam os metodologia, analistas em certas situações, mas quevantagens podem limitar a sua ação em outras. Assim, temos:  Vantagens  V antagens

Um dos objetivos principais do estudo etnográfico é possibilitar aos investigadores analisar o sistema através do ponto de vista do utilizador. Esta perspectiva é extremamente útil para criar um sistema que se adapte às reais necessidades do utilizador. Todo o “trabalho de campo” que implica uma investigação etnográfica permite ao analista desvendar e compreender todas as tarefas e relacionamentos profissionais e sociais que formam o trabalho de um utilizador. O Desenvolvimento Ágil se encaixa muito bem no design centrado no usuário. Muitas vezes, porém, equipes ágeis lutam para incluir um cliente considerado de confiança, algo que métodos ágeis supõem que podem fazer. As tentativas de substituir as partes interessadas ou os proprietários do produto interno para o usuário final único têm mostrado apenas a obtenção de uma única voz crítica de um usuário. O Projeto Contextual fornece técnicas comprovadas para coleta e uso do conhecimento dos usuários, que q ue também podem ser adotadas por equipes ágeis. Com o conhecimento que o analista ganha através do “trabalho de campo” que realiza próximo dos utilizadores, ele poderia desempenhar o papel de utilizador final na avaliação de um sistema. A característica natural e informal da etnografia pode ser útil na descoberta de formas de interação com um determinado sistema por parte dos utilizadores. Essas situações de interação podem ser bastante difíceis de descobrir, se apenas se utilizar outro tipo de metodologia, com uma característica mais quantitativa. quantitativa. Desvantagens

Para criar uma visão bastante completa dos problemas e necessidades de um utilizador relativamente umestudo sistema, é necessário despendero grandes des de tempo no processoa de etnográfico. Geralmente, desenhoquantidados siste-

mas tem prazos relativamente curtos, o que dificulta a realização de uma investigação etnográfica nas melhores condições.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

140

A natureza essencialmente qualitativa dos dados recolhidos pode às vezes dificultar a sua apresentação e descrição, de um modo que seja compreendida pelos designers do sistema. A grande maioria dos estudos etnográficos utiliza um pequeno número de participantes e um ambiente relativamente reduzido. O simples fato de tentar realizar um estudo que abranja uma população de maiores dimensões pode aumentar em muito os custos, o nível de comunicação exigido ou tempo necessário neces sário para concluir tal estudo. Cada trabalho de campo deve ser convenientemente preparado, para que se torne um sucesso, uma vez que esse tipo de trabalho não deve ser categorizado categori zado como tentativa e erro. Uma falha numa sessão pode condicionar o desempenho das sessões seguintes. Por mais que o analista-etnógrafo consiga se “infiltrar” na organização em estudo, ele não pertence à organização, sendo por isso necessário que a sua presença seja a mais harmoniosa possível. Investigação

Muitas vezes, algumas informações são difíceis de serem obtidas através de entrevistas ou observação. Tais informações revelam, tipicamente, um histórico da organização e sua direção. Nestes casos, devemos utilizar investigação, isto é, análise de documentos. Através de investigação, podemos obter mais facilmente informações, tais como tipos de documentos e problemas associados, informação financeira e contextos da organização. Tais informações são difíceis de serem obtidas por outras técnicas de levantamento de requisitos, tais como entrevistas ou observação.  Análise de Documentos Quantitativos

Documentos com formato predeterminado, como relatórios e formulários, trazem informações muito úteis a um analista de sistemas. Esses documentos têm um propósito específico e um público-alvo. Relatórios Relató rios de desempenho, por exemplo, podem mostrar metas de uma organização, a distância em relação à meta e a tendência atual. Relatórios usados no processo de tomada de decisão mostram informações compiladas e podem incorporar algum conhecimento sobre a estratégia da organização. organização. Registros em formulários impressos proveem atualizações periódicas do que

está ocorrendo no negócio. Um engenheiro de software pode inspecionar um registro em formulário impresso para:  

Técnicas para Análise de Requisitos

 

  

141

Verificar erros em quantidades e totais. Procurar oportunidades de melhorar o desenho do formulário. Observar número e tipos de transações.



Procurar onde a introdução do sistema pode simplificar o trabalho (cálculos, instância por exemplo). Formulários são muito úteis para o levantamento de requisitos. Devem ser inspecionados tanto formulários oficiais quanto não oficiais em uso.  

Exemplares de formulários em branco devem ser coletados, procurando observar o tipo, propósito e o público-alvo. Deve-se, ainda, verificar quem realmente recebe o formulário. 

Ao examinar formulários preenchidos, observar se: Existem itens não preenchidos.

Existem formulários nunca usados. Existem formulários não oficiais usados regularmente.     Os formulários são preenchidos pelas pessoas certas. Na investigação de formulários preenchidos, é possível detectar problemas como:  A informação não flui como planejado. Existem pontos de gargalo no processamento de formulários.   Existe trabalho duplicado desnecessariamente. 



Existe de visão do fluxo global da informação, isto é, porque um formulário é falta preenchido e quem o utilizará. Documentos sem formato predeterminado, tais como memorandos, quadros qua dros de aviso e manuais, também são úteis para o levantamento de requisitos, uma vez que mostram como os membros de uma organização são engajados nos processos dela. A análise de documentos qualitativos deve envolver as seguintes tarefas:   Examinar documentos para identificar como os elementos da organização organi zação são referenciados e, assim, conhecer a organização.   Identificar disputas (entre departamentos ou com outras empresas) e, assim, importante: conhecer a política da organização. “ Aqui vale uma observação muito importante: é normal encontrarmos disputas entre departamentos em uma empresa, mas nunca

explicite que você, analista, identificou a disputa. Busque somente conhecer as políticas da organização.”

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

142

Identificar termos que aparecem repetidamente em documentos e caracterizem caracterizem o que é “bom” ou “ruim” para a organização.   Reconhecer a existência de senso de humor nos documentos, o que pode indicar o tipo dos membros da organização (por exemplo, conserva conservadores...). dores...).   Ao analisar memorandos (inclusive os eletrônicos, ou e-mails), dê pre preferência ferência àqueles enviados para toda a organização.  Observe quem enviou e quem recebeu. Memorandos tipicamente fluem horizontalmente ou de cima para baixo e pro veem uma ideia clara de valores, crenças e atitudes dos membros da organização.   Na investigação de sinais e quadros de aviso, procure indícios que apontem apontem a cultura da organização. Exemplo: Segurança em Primeiro Lugar. Finalmente, ao analisar manuais e políticas organizacionais, procure identi  





ficar as ser coisas deveme funcionar, metasestão estratégicas da organizaçãocomo devem atingidas verifique secomo essesaspassos sendo seguidos ou não. Tanto na análise de dados qualitativos quanto de dados quantitativos, procure observar não só os documentos correntes, mas também documentos documentos arquivados.

Workshops Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos. Ao contrário das reuniões, em que existe pouca interação entre todos os elementos presentes, o workshop tem o objetivo de acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador. Uma técnica usada em workshops é o brainstorming. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Alguns aspectos considerados: a postura condutor do seminário deve serimportantes de mediadora eserem observador; a convocação devedo possuir dia,

hora, local, horário de início e de término; assunto a ser discutido e a documentação documentação do seminário.

 

Técnicas para Análise de Requisitos

143

Prototipagem Protótipo  P rotótipo tem por objetivo explorar aspectos críticos dos requisitos de um produto, implementando de forma rápida um pequeno subconjunto de funcionalidades desse produto. O protótipo é indicado para estudar as alternativas de interface do usuário, problemas de comunicação com outros produtos e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias, como interface de usuário, relatórios textuais, relatórios gráficos, entre e ntre outras. Alguns dos benefícios do protótipo são as reduções dos riscos na construção cons trução do sistema, pois o usuário-chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos, é preciso levar em conta a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo protó tipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção. A prototipagem somente tem sentido quando já temos um mínimo de domínio do processo de negócio para o qual estamos realizando um projeto, sem o que é uma fantasia falar ou discutir a realização de um protótipo, pois somente se pode prototipar aquilo que já se conhece.

 Entrevistas Entrevistas A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. As seguintes diretrizes podem ser de grande auxílio na direção de entrevistas entrevistas bem-sucedidas com o usuário:  Desenvolver um plano geral de entrevistas.   Certificar-se da autorização para falar com os usuários. 

   

Planejar a entrevista para fazer uso eficiente do tempo. Utilizar ferramentas automatizadas que sejam adequadas.

Tentar descobrir a informação na qual o usuário está mais interessado.   Usar um estilo adequado ao entrevistar. 

 

144

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Para planejar a entrevista, é necessário que antes dela sejam coletados e estudados todos os dados pertinentes à discussão, como formulários, relatórios, documentos e outros. Isto é, exista o processo de investigação executado anteriormente. anteriormente. Desta forma, o analista estará bem contextualizado e terá mais produtividade produtividade nos assuntos a serem discutidos na entrevista. É importante determinar um escopo relativamente limitado, focalizando uma pequena parte do sistema para que a reunião não se estenda por mais de uma hora. O usuário tem dificuldade de concentração em reuniões muito longas, por isso é importante focalizar a reunião no escopo definido. Após a entrevista é necessário validar se o que foi documentado pelo analista ana lista está de acordo com a necessidade do usuário, se o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações. A atitude do analista em relação à entrevista é determinar seu fracasso ou sucesso. Uma entrevista não é uma competição. Deve-se evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma tentativa de persuasão. O modo como o analista fala não deve ser muito alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os termos ele disse isso ou aquilo na reunião para o outro entrevistado. O modo melhor para agir seria, por exemplo, dizer: O João vê a solução para o projeto dessa forma. E o senhor André, qual é a sua opinião? Em uma entrevista o analista nunca deve criticar a credibilidade do entrevistado. O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema. Para elaborar perguntas detalhadas, é necessário solicitar que o interessado:   Explique o relacionamento entre o que está em discussão e as demais partes do sistema.   Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido. Descreva informalmente a narrativa do item em que o analista deseja obter   informações. 

 

Esclareça separa o item em poder discussão depende, para comuns a sua existência, de formanalguma outra coisa, assim juntar os requisitos do sistema,

do um escopo conciso. Pode-se utilizar a confirmação. Para tanto, o analista deve dizer ao interessado interessado o que acha que ouviu ele dizer.  

Técnicas para Análise de Requisitos

145

Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito. O Planejamento

O planejamento de uma entrevista envolve os seguintes passos: 1. Estudar material existente sobre os entrevistados e suas organizações.

Procure dar atenção especial à linguagem usada pelos membros da organização, buscando estabelecer um vocabulário comum a ser usado na elaboração elabo ração das questões da entrevista. Esse passo visa, sobretudo, otimizar o tempo despendido nas entrevistas, evitando perguntar questões básicas e gerais. 2. Estabelecer objetivos.

De maneira geral, há algumas áreas sobre as quais um engenheiro de software  desejará fazer perguntas relativas ao processamento de informação e ao comportamento na tomada de decisão, tais como fontes de informação, formatos da informação, frequência na tomada de decisão, estilo da tomada de decisão etc. 3. Decidir quem entrevistar.

É importante incluir na lista de entrevistados pessoas-chave de todos os níveis da organização afetados pelo sistema. A pessoa de contato na organização pode ajudar nessa seleção. Quando necessário, use amostragem. 4. Preparar a entrevista.

Uma entrevista deve ser marcada com antecedência e deve ter uma duração dura ção entre 45 minutos e uma hora. 5. Decidir sobre os tipos de questões e a estrutura da entrevista.

O uso de técnicas apropriadas de questionamento e o “coração” de uma entrevista. 6. Decidir como registrar a entrevista.

Entrevistas devem ser registradas para que informações obtidas não sejam perdidas logo em seguida. Os meios mais naturais de registrar uma entrevista incluem anotações e o uso de gravador. Tipos de Questões

Questões podem ser de três tipos básicos:   Questões subjetivas: permitem respostas “abertas”. Exemplo: O que você acha de...? Explique como você...

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

146

Vantagens

Proveem riqueza de detalhes. Revelam novos questionamentos. Colocam o entrevistado à vontade. Permitem maior espontaneidade. Desvantagens

Podem resultar em muitos detalhes irrelevantes. Perda do controle da entrevista. Respostas muito longas para obter pouca informação útil. Podem dar a impressão de que o entrevistador está perdido, sem objetivo.   Questões objetivas: limitam as respostas possíveis. Exemplo: Quantos...? Quem...? Quanto tempo...? Qual das seguintes informações...? Vantagens

Ganho de tempo, uma vez que vão diretamente ao ponto em questão. q uestão. Manter o controle da entrevista. Levam a dados relevantes. Desvantagens

Podem ser maçantes para o entrevistado. Podem falhar na obtenção de detalhes importantes. Não constroem uma afinidade entre entrevistador e entrevistado. permitem explorar  os detalhes de uma questão. Podem ser subjetivas ou objetivas.

 Questões de aprofundamento:   Questões



Exemplo: Por quê? Você poderia dar um exemplo? Como isso acontece?

Problemas na Elaboração de Questões   Questões capciosas: tendem a levar o entrevistado a responder de uma forma



específica, isto é, são tendenciosas. Exemplo: Sobre este assunto, você está de acordo com os outros diretores, diretores, não

esta? Opção mais adequada: O que você pensa sobre este assunto?

 

Técnicas para Análise de Requisitos

147

  Duas questões em uma: o entrevistado pode responder a



 



 



 



 



apenas uma delas, ou pode se confundir em relação à pergunta que está respondendo. respondendo. Exemplo: O que você faz nesta situação e como?

Diz respeito à organização dasa sequência questões em sequência lógica. Há quatro formas básicas de estabelecer dasuma questões:  Estrutura de Pirâmide Pirâmide   (Abordagem Indutiva): inicia com questões bastante detalhadas, geralmente objetivas e, à medida que a entrevista entrevista progride, questões mais gerais, subjetivas, são colocadas. Útil para situações em que o entrevistado parece relutante em abordar um assunto determinado ou se o engenheiro de software deseja obter uma finalização do assunto.  Estrutura de Funil Funil   (Abordagem Dedutiva): inicia com questões gerais subjetivas e, à medida que a entrevista avança, perguntas mais específicas, usando questões objetivas, são feitas. Essa estrutura estrutura provê um meio fácil e não ameaçador para começar uma bateria de entrevistas. Permite levantar bastante informação detalhada, sendo desnecessárias longas sequências de questões ob jetivas e de aprofundamento.  Estrutura de Diamante: combinação das duas anteriores: começa com questões específicas, passa a questões gerais e fecha a entrevista novamente com questões específicas. Frequentemente, é a melhor forma de estruturar uma entrevista, já que mantém o interesse do entrevistado em uma variedade de questões. Contudo, tende a ser mais longa.  Entrevista Não Estruturada: Não há uma definição da sequência das questões. De acordo com o andar da entrevista, caminhos possíveis possíveis são avaliados e a sequência é estabelecida. Requer mais tempo. Vale ressaltar que, ainda que a sequência das questões não seja definida a priori, as questões devem ser definidas antecipadamente, antecipadamente, ou seja, o planejamento é necessário. 1. Começa com uma questão questão genérica e termina com uma ques questão tão geral. 2. Começa com questões genéricas e termina com questões espe específicas. cíficas. 3. Inicia com questões específicas. 4. Examina questões gerais. 5. Fecha com questões genéricas.

Registro da Entrevista É importante registrar os principais aspectos de uma entrevista durante a sua

realização. No planejamento, deve-se definir como isso será feito. Há duas formas principais, cujas vantagens e desvantagens são apresentadas a seguir:

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

148

  Gravador: requer a permissão do entrevistado e normalmente provoca muita



resistência. Vantagens

Registro completo da entrevista. Rapidez e melhor desenvolvimento. Reprodução para outros membros da equipe. Permite que a equipe participe do entendimento do problema ou da solução com maior interação; Desvantagens

Deixar o entrevistado sempre pouco à vontade. Constrange. Pode deixar o entrevistador distraído. Pode haver necessidade de transcrever a fita. 

  Anotações Vantagens

Manter o entrevistador alerta. Pode ser usado para fornecer um roteiro para a entrevista. Mostra interesse e preparação do entrevistador. Desvantagens

Perda do andamento da conversa. Excessiva atenção a fatos e pouca a sentimentos e opiniões.

Recomendações Gerais Um dia antes, entre em contato com o entrevistado para confirmar o horário horário e o local da entrevista. Chegue um pouco antes do horário marcado. Apresente-se e esboce brevemente os objetivos da entrevista. Relembre o entrevistado que você vai registrar pontos importantes. Se for usar gravador, coloque-o em local visível. Diga ao entrevistado o que será feito com as informações coletadas e também tam bém reassegure seu aspecto confidencial.

Lembre-se de que a entrevista deve durar entre 45 minutos e uma hora.

 

Técnicas para Análise de Requisitos

149

Quando estiver incerto sobre uma questão, peça para o entrevistado dar definições ou outros esclarecimentos. Use questões de aprofundamento. Ao término da entrevista, pergunte se há algo mais sobre o assunto que o entrevistado ache importante você saber. Faça um resumo da entrevista e de suas impressões globais. Informe o entrevistado sobre os passos seguintes. Pergunte se há outra pessoa com a qual você deveria conversar. Quando for o caso, marque nova entrevista.

Relatório da Entrevista O relatório ou ata da entrevista deve capturar a essência da entrevista. Escreva o relatório tão rápido quanto possível para assegurar qualidade. Registre entrevistado, entrevistador, data, assunto e objetivos. Diga se os objetivos foram alcançados e aponte objetivos para entrevistas futuras. Registre, ainda, os pontos principais da entrevista e sua opinião.

 Questionários Questionários O uso de questionário é indicado, i ndicado, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais geograficamente diferentes. caso, elaboram-se pesquisasem específicas depareça acompanhamento com usuários Neste selecionados, que a contribuição potencial mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais. Para a elaboração de questionários, é óbvio que é preciso possuir domínio bem elevado do processo de negócio, para viabilizar a sua elaboração de forma coerente com o negócio, processo e projeto que pretendemos construir. Existem vários tipos de questionários que podem ser utilizados. Entre eles podemos citar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em em sua resposta. Na fase de preparação do questionário deve ser indicado o tipo de informação informação

que se deseja obter. Assim que os requisitos forem definidos, o analista deve elaborar o questionário com perguntas simples, claras e concisas, deixar espaço suficiente para

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

150

as respostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado de uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização. organização. Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes, é feita uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com essas informações para o participante, como forma de consideração pelo tempo dedicado à pesquisa. Pairam dúvidas sobre bons resultados de conteúdo com a utilização de questionários, aplicação conjunta muitos casos de umdeestudo etnográfico,visto sem oque queimpede não temos a garantia de umem projeto com acurácia informações do mundo real.

Brainstorming Brainstorming é uma técnica para geração de ideias. Em muitas situações, após a aplicação de um estudo etnográfico, partindo para um brainstorming com os interessados, o analista consegue obter excelentes resultados decorrentes de sua facilidade de interação e condução objetiva com os participantes. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram sugiram e explorem ideias. As principais etapas necessárias para conduzir a 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, garante ga rante 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 seguidas durante a sessão. Produzir uma boa quantidade de ideias: os participantes geram tantas ideias   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 ideia. Se alguém

tiver problema, passa a vez e espera a próxima rodada.

 

Técnicas para Análise de Requisitos

151

No brainstorming as ideias que a princípio pareçam não convencionais, são encorajadas, pois elas frequentemente estimulam os participantes, o que pode levar a soluções criativas para o problema. O número de ideias geradas deve ser bem grande, pois quanto q uanto mais ideias forem propostas, maior será a chance de aparecerem boas ideias. Os participantes também devem ser encorajados a combinar ou enriquecer as ideias de outros. Para isso, é necessário que todas as ideias permaneçam visíveis visíveis a todos os participantes. Nessa técnica é designada uma pessoa para registrar todas as ideias em uma lousa branca ou em papel. À medida que cada folha de papel é preenchida, ela é colocada de forma que todos os participantes possam vê-la. Analisar as ideias é a fase final do brainstorming. Nessa fase é realizada uma revisão das ideias, uma de cada vez. As consideradas valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.

 JAD    JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os interessados a formular problemas e explorar soluções. Desta forma, os interessados ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto. A técnica JAD tem quatro princípios básicos: 1. Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, interessados e gerentes, para despertar a força e a criatividade dos participantes. O resultado final a princípio será a determinação dos objetivos e requisitos do sistema. 2.

Uso de técnicas visuais: para aumentar comunicação e entendimento.

3.

Manutenção do processo organizado e racional: o JAD emprega a análise

top down e atividades bem definidas. Possibilita, assim, a garantia de uma análise completa, reduzindo as chances de falhas lacunas nodepende projeto edacada nível de detalhe recebe ae devida atenção, masou certamente organização da condução de um

acentuado foco nos objetivos do projeto pelos participantes.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

152

4.

Utilização de documentação padrão: preenchida e assinada por todos os

participantes. Esse documento garante a qualidade esperada do pro jeto e promove a confiança dos participantes. A técnica é composta de duas etapas principais: • Planejamento, que tem por objetivo elicitar e especificar requisitos. • Projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases, sendo adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a reunião, ou seja, orga organizar nizar a equipe, identificar claramente o processo e sua relação com o produto a ser construído e preparar o material. Na fase de reunião ou sessão são realizados um ou mais encontros estruturados, com a participação de desenvolvedores e interessados em que os requisitos requi sitos são discutidos, discutidos, desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos humano inteligível, o que significa não técnico), para aprovação dos interessados e participantes. participantes. Há um conjunto de seis tipos de participantes, embora nem todos participem parti cipem em todas as fases. São eles: e sforço, sendo o facilitador facilitador dos   Líder da sessão: é responsável pelo sucesso do esforço, encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança.   Analista de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um analista experiente para entender as questões técnicas, detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza.   Executor: é o responsável pelo produto a ser construído. Deve fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, como alocação alocação de recursos, que podem afetar os requisitos e o projeto do novo produto.   Representantes Representant es dos interessados: são as pessoas na empresa que vão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas-chave dentro da empresa, que têm uma visão melhor do todo e de como ele será usado, mas não necessariamente, pois muitas vezes pessoas não chave dentro da empresa têm a visão mais clara das necessidades e requisitos.

 

Técnicas para Análise de Requisitos

153

  Analistas de software: são

os profissionais que estão bastante familiarizados familiarizados com as capacidades dos produtos e ferramentas de software. Seu papel é ajudar os interessados a entender o que é razoável ou possível que o novo produto faça.   Especialista de negócios: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico dentro de um processo de negócios, negócios, ou nos processos de negócio da empresa. O conceito do JAD de abordagem e dinâmica de grupo pode ser utilizado para diversas finalidades, como: • Planejamento de atividades atividades técnicas para um grande grande projeto; • Discussão do escopo e objetivos de um projeto; • Estimativa da quantidade de horas necessárias para desenvolver sistemas sistemas grandes e complexos. A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. 

Para um sistema grande e complexo podem e devem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema. Síntese

Um analista de sistemas precisa de mais do que apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos. O analista de sistemas tem a função de projetar e analisar sistemas de ótimo desempenho. Logo, para que esse objetivo seja alcançado, é necessário dotar o analista de sistema de capacidade para:   Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão.   Conhecer conceitos básicos de diversos processos de negócio, através de auxílio de profissionais de cada área.   Absorver fatos pertinentes de fontes conflitantes ou confusas. Entender os ambientes do interessado/cliente.     Ser treinado e dotado de técnicas de observação como a etnografia que já apresentamos e ainda vamos explorar mais neste livro.  Aplicar elementos do sistema de hardware  e/ou software  aos elementos do usuário/cliente.   Comunicar-se bem nas formas escrita e verbal e entender o objetivo global do software. Isso é essencial a um bom analista.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

154

Enfoque e Recomendação Entendemos, depois de quase 40 anos de experiência, que o ideal na aplicação aplicação de técnicas de levantamento e análise de requisitos segue uma ordem que permite melhores resultados com nível de satisfação, segurança dos requisitos de sistema e, consequentemente, melhores projetos: Estudo etnográfico     Levantamento orientado a pontos de vista    Entrevistas Entrevistas User story - detalhes no capítulo 11 sobre SCRUM    Brainstorming    JAD   Acreditamos que, apesar de aparentemente utilizado nenhuma técnica de diagramação até o momento, estamos nonão quetermos é definido como Elicitação Elici tação de Requisitos, em que o tempo gasto evitará custos maiores no projeto em si, mais à frente, em que mudar qualquer coisa custa sempre muito mais caro.

Exercícios 1)  Cite três técnicas que você considera importantes para para levantamento levantamento de requirequi-

sitos. 2)  O levantamento orientado a pontos de vista estabelece dois dois conceitos-chave.

Quais são e qual a diferença entre eles? 3)  Defina etnografia.

análise de ponto de de vista? Explique. 4)  Etnografia é compatível com análise 5)  Liste os dados possíveis de obter pela observação etnográfica. 6)  Cite três vantagens da utilização utilização de etnografia para para levantamento levantamento de requisitos. 7)  Documentos com formato predeterminado, predeterminado, como relatórios e formulários, de-

vem ser usados em que técnica de levantamento de requisitos? 8)  Cite cinco pontos para para realizar realizar uma boa entrevista. entrevista. 9)  Uma entrevista de três horas é uma boa entrevista? entrevista? 10) Cite três desvantagens das entrevistas no levantamento l evantamento de requisitos.

 

Requisitos e Modelo de Negócios

8

“Muitas coisas acontecem alheias às nossas vontades, e muitas outras continuarão acontecendo se continuarmos alheios.”

O Problema Se perguntarmos para alguns analistas de sistemas:

Vocês realizaram a modelagem dos processos de negócio antes de definir a especificação do sistema que sua equipe está desenvolvendo? Por incrível que pareça, a resposta será: “Veja bem, ...”; ou seja, será apresentada uma infinidade de desculpas plausíveis de não ter sido realizada essa atividade. Apesar de a razão indicar que o conhecimento dos processos de negócio é condição “sine qua non” para o desenvolvimento de sistemas que automatizem os processos de uma empresa, a maioria das empresas de desenvolvimento de software, e as equipes internas de desenvolvimento de sistemas, insiste em desprezar esse conhecimento, ou os usuários não se envolvem para apresentar o modelo de negócios e seus processos. O problema do desenvolvimento de software  continua sendo como dissemos dissemos software continua no início deste livro:

 

156

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Por que não conseguimos entregar softwares nos prazos e custos combinados combinados com os clientes? Por que não conseguimos entregar softwares que realmente atendam as necessidades dos clientes? Continuamos a desenvolver softwares que devem apoiar processos de negócio, negócio, mas sem ao menos conhecê-los em uma mínima parte. Como classificar este fato: imaturidade, insanidade ou loucura? Em pesquisas vimos que muitos pesquisadores já se preocupam com essa abordagem e ela vem gradativamente ganhando adeptos e métodos para que tenha soluções práticas e metodológicas que resolvam definitivamente este problema. Muitas promessas de solução através de processos de desenvolvimento, técnicas de modelagem, ferramentas, surgiram e continuam sendouma utilizadas, como se resolvessem tudo. Formam linda sopa de letrinhas. O professor Osvaldo Kotaro Takai, em sua apresentação Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas Software, define como promessas que matam até lobisomem, mas se prestarmos atenção nos detalhes, veremos que sempre se pula por cima dos aspectos relativos aos processos processos de negócio. Basta ver os pontos do manifesto ágil que já referenciamos:   Interessados na aplicação (stakeholders) e desenvolvedores devem trabalhar trabalhar  juntos diariamente ao longo do projeto. Cooperação constante entre pessoas que ENTENDEM do ‘negócio’ e desenvolvedores. Esta é a bala de prata que mata lobisomem.

Então por que não colocamos foco em modelar ou obter o modelo dos processos de negócio?

 

Requisitos e Modelo de Negócios

 



 



157

Diversas desculpas já foram alegadas, como: Nunca precisamos modelá-los (analista autossuficiente?). Clientes não nos pagam para isso (falta de visão).

    

Não está no contrato (esta é clássica). Não dá! Já estamos atrasados! (ridículo, busca o prazo e esquece a qualidade). qualidade). Fazer o certo é muito acadêmico e muito demorado.   Mas a verdade é que os analistas de sistemas não são preparados e a bem da verdade “não sabem fazer isso”. Não basta apenas reunir desenvolvedores e clientes para que a mágica aconteça (Manifesto Ágil). Não basta utilizar uma notação padrão, como BPM, as extensões providas pelo RUP e UML. É preciso SABER e buscar ajudar os clientes a formalizarem o seu conhecimento. Devemos buscar uma orientação mais pragmática, porque mais importante do que a notação e frameworks, com certeza é: Saber identificar os processos de negócio. Saber detalhá-los sem a interferência tecnológica, premissa antiga, mas que nunca se utiliza com efetividade, sempre tem alguém pensando na tecnologia da solução. Interferência direta de requisitos não funcionais. Saber detalhar processos de negócio, considerando os dados consumidos ou gerados por eles. Vamos apresentar um exemplo muito interessante da palestra do professor Takai, que abstrai e mostradeuma modelagem bem pragmática identificação de processos e atividades negócio e a abordagem de análisepara e descoberta de requisitos.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

158

Dos eventos listados, vamos observar o primeiro deles: Cliente encomenda livros

Numa notação de DFD teríamos:

Figura 8.1: DFD.

E numa visão já mais orientada a objetos, um diagrama de classes surgiria daqui:

Figura 8.2: Diagrama de classes.

Se observarmos a classe encomenda, teríamos um diagrama de estados como

a seguir:

 

159

Requisitos e Modelo de Negócios

Figura 8.3: Diagrama de estados.

Importante destacar que um objeto em análise pode ser visualizado, entendido sob diversas perspectivas. Por exemplo, com a notação de Business Use Cases:

Figura 8.4: Bussines Use Cases.

 

160

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Temos ainda o diagrama de atividades:

Figura 8.5: Diagrama de atividades.

Temos assim um macromodelo de processos de negócio para um dos eventos eventos do processo Venda de Livros. Com notação BPMN teríamos um detalhamento maior das atividades, como mostra a figura a seguir.

 

161

Requisitos e Modelo de Negócios

Figura 8.6: Atividades em notação BPM.

Importante observar o quanto ganhamos em riqueza de informações e subsídios para a análise de requisitos com a visualização do processo e suas atividades.

Veja agora o detalhamento da atividade Receber um pedido:

 

162

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Figura 8.7: Diagrama de atividades.

Segundo o próprio professor Takai, para a obtençãode dos funcionais, nais, agora que temos o modelo de processos e as atividades umrequisitos processo,funcio para cada atividade identificada devemos perguntar: O que o sistema deve fazer pelo “worker “worker desta atividade” para ele executar executar a atividade?

A resposta deve ser registrada num formato: O sistema deve permitir que o worker faça...

Vamos agora seguir a explanação de um dos principais métodos de abordagem da análise de requisitos de software orientada, baseada em processos de negócio. Não podemos neste capítulo explanar e apresentar a imensidão de métodos mé todos de elicitação de requisitos baseados em modelos de negócio, visto que poderiam po deriam

ser objetos de um único livro se fosse o caso.

 

163

Requisitos e Modelo de Negócios

Então, optamos por apresentar o método a seguir por possuir uma simplicidade de entendimento, além de demonstrar a importância que damos à análise de negócios para a identificação de requisitos de software.

Método de Mac Knight para Elicitação de Requisitos de Software Sof tware a Partir do Modelo de Negócio O método para elicitação de requisitos de software a partir do modelo de negócio foi proposto por Débora Mac, defendida em 2004, no Núcleo de Computação Compu tação Eletrônica (NCE) da Universidade Federal do Rio de Janeiro. A abordagem considera as informações provenientes do entendimento do negócio como fonte de auxílio para identificação das necessidades do negócio diretamente relacionadas ao sistema a ser desenvolvido. A partir desse entendimento, concepção da autora, torna-se possível estabelecer os requisitos que atenderãonaàquelas necessidades. A autora emprega o termo modelo de negócio para designar o produto desenvolvido a partir da tarefa de modelagem de negócio, que pode ser definido com um conjunto de conceitos, modelos e técnicas. O modelo de negócio, ainda na visão da autora, indica o ambiente em que a organização se insere e a forma como se dá sua relação com esse ambiente.

Figura 8.8: Modelo de negócios.

O modelo de negócio é aquele que permite melhor visualização “do que são seus processos, como são executados, quais são suas metas, como cada processo pro cesso

 

164

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

auxilia para alcançá-las, quais são suas unidades organizacionais, quem são os envolvidos em cada atividade, quais as localidades entre as quais a organização organização está distribuída e quais os eventos que deflagram seus processos e atividade”. O modelo do negócio, na abordagem da autora, é formado por um con junto con junto de outros modelos que representam conceitos do negócio. Esses modelos são mostrados na figura seguinte.

Figura 8.9: Conceitos do modelo de negócio.

A solução proposta por Knight prevê a utilização do modelo de negócio como informação de entrada. Parte do princípio de que existe uma solicitação de suporte à execução de atividades dos processos através de um sistema de informação infor mação a ser construído, algo que a autora define como solicitação de automação. O método contempla as atividades de análise do problema, elicitação dos requisitos de negócio e requisitos de usuário.

 

165

Requisitos e Modelo de Negócios

Figura 8.10: Método Knight.

Objetivo

O método tem como objetivo servir de guia para a equipe de desenvolvimento desenvolvimento de software  durante a elicitação de requisitos. software durante Seu uso é indicado em situações em que a automação de tarefas e os serviços servi ços necessários à organização são solicitados, auxiliando os analistas de sistemas a obterem os requisitos do novo sistema. Um aspecto que recebe especial atenção do método é a colaboração entre os analistas de sistemas e pessoas da organização, lembrando muito este ponto do Manifesto Ágil. Essa colaboração se dá através de reuniões, cujo envolvimento de pessoas que possuem os conhecimentos necessários a cada etapa do método permite complementar o entendimento do problema e da solução, fazendo com que o resultado final seja o mais completo possível. As etapas propostas no método servem como guia, indicando as tarefas necessárias para a identificação de cada informação. Outro aspecto levado em consideração é a rastreabilidade dos requisitos identificados pelo método. A relação entre cada necessidade de negócio e cada funcionalidade ou restrição do sistema deve ser mantida, permitindo a identificação do que deve ser alterado caso o negócio sofra alguma alteração. Por fim, é esperado que o método seja capaz de considerar o modelo de negó-

cio de uma organização, descrito em qualquer notação.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

166

Para tanto, deve-se identificar os conceitos sobre a estrutura organizacional, organizacional, processos de negócio, atividades, objetivos de negócio, eventos e localização geográfica. O documento final do método lista os requisitos de usuário, estando as demais etapas do desenvolvimento do software fora do escopo do método.

Detalhamento do Método O método é dividido em duas fases, sendo a visão geral do problema e a visão geral da solução. Cada fase é composta por etapas e passos. Fase 1: Visão Geral do Problema

A primeira fase do método engloba as três primeiras etapas do método, e tem o objetivo de dar aos engenheiros de software uma visão do que é o negócio, da organização, e quais partes destes devem ser consideradas para atender à solicitação feita. Etapa 1: Identificar o Contexto da Solicitação

O objetivo desta etapa é definir o escopo da área de negócio envolvido com a solicitação. Espera-se como premissa que já exista um modelo de negócio, definido em qualquer linguagem ou notação. No primeiro passo, deve-se analisar o modelo de processos com o objetivo de identificar os processos envolvidos com a solicitação, baseando-se na sua descrição. Existindo subprocessos, eles também devem ser avaliados. No segundo passo, analisa-se cada processo identificado, buscando dentre as atividades que o compõem, aquelas que devem ser consideradas no contexto da solicitação. O resultado da primeira etapa é a lista de processos e atividades dentro do contexto da solicitação. Etapa 2: Identificar Necessidades dos Processos P rocessos

O objetivo desta etapa é especificar as necessidades existentes em cada ati-

vidade dos processos no contexto da solicitação. No primeiro passo, identificam-se as dificuldades existentes em cada atividade dos processos, através de entrevistas com os seus executantes.

 

Requisitos e Modelo de Negócios

167

Dificuldades são quaisquer obstáculos que devem ser superados para a execução das atividades. No segundo passo, analisam-se as dificuldades com o objetivo de entender suas causas. No terceiro passo são identificados os resultados insatisfatórios gerados pelos processos, através de uma análise que busca avaliar se as atividades são executadas da forma adequada e se produzem resultados satisfatórios - percebendo percebendo pontos de melhoria nos processos e problemas que podem gerar impactos em clientes, além de questões como segurança e velocidade de processamento. Desta forma, o resultado da segunda etapa é a lista de necessidades de negócio existentes em cada atividade dos processos. Etapa 3: Identificar os Impactos das Necessidades

O objetivo dessa etapa é obter uma visão dos impactos das necessidades identificadas. No primeiro passo, identificam-se as consequências de cada necessidade como a existência da atividade afeta as atividades e processos. No segundo passo, analisa-se cada uma das consequências para identificar os objetivos de negócio afetados. No terceiro passo, identificam-se as pessoas envolvidas com o negócio que sofrem as consequências das necessidades existentes, através da análise dos papéis que se relacionam com os objetivos que sofrem os impactos das consequências. consequências. Por fim, é necessário relacionar as pessoas afetadas com os objetivos do passo anterior.  Já no quarto passo, definem-se quais necessidades serão atendidas pelo sistema, e as prioridades de cada uma. Assim, o resultado da etapa é uma tabela que mostra as necessidades existentes relacionadas com suas consequências, objetivos, pessoas afetadas e prioridades. Fase 2: Visão Geral da Solução

A segunda fase do método tem o objetivo de criar a visão da solução que atenda às reais necessidades da solicitação, identificando funcionalidades e restrições res trições do sistema. Assim, no final desta fase, os engenheiros de software terão um resumo das

principais características do sistema, de acordo com o que o negócio exige. Ao mesmo tempo, no final da fase, a organização será capaz de perceber as mudanças que ocorrerão em seus processos com a criação do sistema.

 

168

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Etapa 4: Identificar as Funcionalidades e Restrições do Sistema

O objetivo desta etapa é identificar as principais funcionalidades e restrições restri ções que o sistema deve possuir para atender às necessidades verificadas anteriormente. anteriormente. No primeiro passo,para os próprios analistas devem identificar funcionali funcionalidades dades e restrições do sistema que atenda aos processos dentro doascontexto, que podem ser restrições ou funções específicas que o sistema deve prover. No segundo passo, deve-se analisar cada necessidade de negócio, agora em reunião com os gerentes, com o objetivo de identificar o que deve ser feito para que seja suprida, listando necessidades, funcionalidades e restrições adicionais. O resultado da quarta etapa é a lista de todas as funcionalidades e restrições restrições identificadas para o sistema. Essa lista torna possível a relação das atividades e processos com as funcionalidades e restrições geradas no sistema. Etapa 5: Identificar as Fronteira Fronteirass do Sistema

O objetivo desta etapa é identificar os pontos em que o sistema troca informações com outros recursos do negócio. No primeiro passo, é feita uma busca nos modelos pelos papéis que executam executam as atividades identificadas, procurando saber se continuarão sendo executadas executadas por estes ou se passarão a ser totalmente executadas pelo sistema. Caso o sistema apenas apoie essas atividades, haverá então a interação por parte desses papéis, sendo necessária a definição dos usuários e permissões de cada um. No segundo passo, avalia-se a possibilidade de haver interação com outros sistemas, identificando se ela será executada com apoio de algum outro sistema e, principalmente, se ela continuará a ser apoiada por esse sistema após a implantação do novo. Em caso positivo, deve-se verificar se as informações manipuladas são relevantes, de modo que se identifique se o novo sistema deve interagir com o antigo ou não.

Conclusão sobre Abordagem de Processos de Negócios na Elicitação

de Requisitos de Software O tema regras de negócio, abordado neste capítulo, torna-se importante para a elicitação de requisitos, porque além da influência direta no negócio, essas regras também têm estreita relação com os sistemas de informação, principalmente principal mente em

 

Requisitos e Modelo de Negócios

169

ambientes de rápidas e constantes mudanças, em que não só o negócio como também os Sistemas de Informação que o suportam são afetados. As regras servem como orientação, influenciando o comportamento coletivo cole tivo dos membros de uma organização, controlando ou influenciando a execução dos processos de negócio e sua estrutura de recursos, restringindo ou condicionando con dicionando a execução de certas atividades e dos sistemas de informação que as suportam. Identificar, representar, gerenciar e usar as regras de negócio como fonte de informações na elicitação de requisitos de sistema torna-se importante para gerar softwares mais aderentes às reais necessidades do negócio. É possível tecer algumas colocações gerais para orientar futuras proposições propo sições para a tarefa de elicitação de requisitos de sistema a partir dos processos de negócio, a saber: Futuras proposições metodológicas devem definir o conceito de processo de negócio e dos elementos que o compõem (atividades, insumos e produtos, executores etc.), principalmente no que tange ao fluxo lógico e temporal das informações, calcado no arcabouço conceitual da EPN ( Engenharia Engenharia de Processos de Negócio), pois os processos são os responsáveis pelo fornecimento da visão processual. A modelagem de processos de negócio, segundo as diretrizes do arcabouço conceitual da EPN (Engenharia de Processos de Negócio), deve ser aplicada com rigor. Para tal, é preciso atentar para aspectos como qualidade e padronização dos modelos de processos, usando, assim, princípios de modelagem consistentes. Além disso, a modelagem deve ser empregada para desenvolver modelos que capturem as diversas características do negócio, principalmente no que se refere ao fluxo de informações, executores, regras de negócio, recursos etc., viabilizando viabilizando também outras ações da EPN (reengenharia, análises e reestruturações organizacionais etc.). A modelagem dos processos de negócio deve ser sistematizada por uma metodologia preparada para tal e não por metodologias originalmente concebidas concebidas para a modelagem de sistemas, como é o caso da UML. Com isso, espera-se que os processos de negócio modelados não estejam limitados ao provimento de informações para o desenvolvimento de sistemas de informação, mas também para ajudar em outras análises e aplicações da EPN. Proposições futuras, além dos aspectos apresentados, também devem buscar bus car a operacionalização da tarefa de modelagem dos processos através de ferramentas ferramentas computacionais. Essas ferramentas devem fornecer suporte à metodo metodologia logia de modelagem selecionada, promovendo a rastreabilidade dos modelos e permitindo

também outras ações da EPN (Engenharia de Processos de Negócio). A modelagem de processos, aliada à metodologia e ferramenta específicas, deve também considerar a elaboração de diretrizes que orientem na determinação determinação

 

170

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

dos níveis de agregação dos processos necessários à tarefa de elicitação de requisitos de sistema. Embora não existam regras exatas, o estabelecimento dessas diretrizes se torna fundamental para descrever claramente o fluxo de informação (materiais/documentos associados), bem como detectar os problemas ou informações relevantes rele vantes para a definição dos requisitos de sistema, o que não é conseguido quando quando os processos estão agregados demais. Com as diretrizes para definição dos níveis de detalhamento dos processos, torna-se possível ainda estabelecer correlações entre as atividades dos processos e as funcionalidades identificadas para os sistemas, gerando correspondências entre requisitos de negócio e de sistemas. Aliadas ao conceito de processos de negócio, as proposições futuras de métodos que elicitem requisitos a partir dos processos de negócio modelados não devem deixar de abordar também o conceito de regras de negócio. Isso porque as regras de muitas negóciovezes estãofontes diretamente relacionadas aos processos propara cessos de negócio, tornando-se de informação importantes geração de funcionalidades do sistema a ser desenvolvido. Não basta apenas definir como essas regras são identificadas, mas é preciso também estabelecer critérios que orientem o procedimento de transformação dessas regras em requisitos de sistema, ou indiquem como essas informações contribuem para a construção desses requisitos. Propostas futuras de transformação das informações dos processos de negócio em requisitos de sistema devem contemplar, além dos itens citados anteriormente, anteriormente, o emprego de metodologia, técnica ou notação apropriada para a representação dos requisitos gerados, estabelecendo a devida granularidade dos requisitos de sistema em correspondência aos processos de negócio. Essa questão está fortemente relacionada à definição dos níveis de detalhamento dos processos que, portanto, devem estar bem definidos em abordagens futuras. Além disso, a forma de documentar os requisitos deve também subsidiar o entendimento e o aproveitamento daqueles nas demais etapas do ciclo de vida de software e garantir a rastreabilidade e a gestão deles. A observância desses aspectos na construção de futuras proposições de métodos de elicitação de requisitos, a partir de processos de negócio, torna-se importante para a geração de funções de sistema bem definidas, completas e mais aderentes às reais necessidades do negócio.

 

Gestão do Conhecimento e Requisitos

9

“Se o conhecimento pode criar problemas, não é através da ignorância que podemos solucioná-los solucioná-los.” .” (Isaac Asimov)

O Conceito de Gestão do Conhecimento Gestão do Conhecimento (Knowledge Management) refere-se à criação, iden-

tificação, integração, recuperação, compartilhamento e utilização do conhecimento conhecimento dentro da empresa. O “KM”, como é conhecido, é considerado um sistema de gerenciamento corporativo. As empresas passaram por três etapas, sendo era industrial clássica, era industrial neoclássica e era da informação. A Tecnologia da Informação aliada à Gestão do Conhecimento torna-se um meio e não um fim para o sucesso de uma estratégia. Ao contrário do que acontecia antigamente, em que as empresas guardavam guar davam seus conhecimentos a sete chaves, com a Gestão do Conhecimento, toda informação deve ser transformada em conhecimento e distribuída a todos os interessados. O segredo está em divulgá-lo em toda organização, e não mais detê-lo. O conhecimento passa a ser ativo da empresa, portanto motivar, recompensar e reter as pessoas que têm conhecimento é um foco das empresas bem-sucedidas, assim como transportar esse conhecimento para os sistemas corporativos, principalmente na sua elaboração, transformando conhecimento em requisitos de sistema. Conhecimento é uma realidade no mundo dos negócios. O conhecimento

numa empresa não a torna mais competitiva, e sim o seu gerenciamento faz a diferença. Esse conhecimento tem de ser encapsulado nas especificações de uma aplicação de software, pois sem ele não conseguimos realizar uma aplicação que agregue valor à organização.

 

172

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Com a Gestão do Conhecimento temos a “venda” do projeto de sistema para todos os colaboradores; a importância do treinamento, a educação; todos participantes ativos ou receptivos serão beneficiados pela estratégia; a premiação, premia ção, como forma de reconhecimento; e a comunicação clara, atingindo todos os níveis afetados, e com isso obtendoa oentender atendimento das necessidades dos interessados interes (), além de levar o colaborador a importância de sua atividade, desados seu conhecimento para todos e para o processo da empresa. É uma mudança de comportamento para agregar valores. O segredo está nas pessoas. Nada mais é que criação de valor a essa realidade, muitas vezes desconsiderada. O conhecimento deriva da informação, assim como esta, dos dados. Não é puro nem simples, mas é uma mistura de elementos; é fluido e formalmente estruturado; é intuitivo e, portanto, difícil de ser colocado em palavras ou de ser plenamente entendido em termos lógicos. Ele existe dentro das pessoas e por isso é complexo e imprevisível. Conceitos Básicos de Gestão do Conhecimento Os autores Nonaka e Takeushi classificaram o conhecimento humano em dois tipos, sendo conhecimento tácito e conhecimento explícito. Conhecimento explícito é o que pode ser articulado na linguagem formal, inclusive em afirmações gramaticais, expressões matemáticas, especificações, manuais etc., facilmente transmitido, sistematizado e comunicado. Ele pode ser transmitido formal e facilmente entre os indivíduos. Esse foi o modo dominante de conhecimento na tradição filosófica ocidental. Este é o conhecimento que conseguimos trabalhar em entrevistas, brainstorming etc., quando realizamos o levantamento de requisitos. O conhecimento tácito é difícil de ser articulado na linguagem formal, porém é um tipo de conhecimento muito importante quando de um processo de levantal evantamento de requisitos. É o conhecimento pessoal incorporado à experiência individual e envolve fatores intangíveis, como, por exemplo, crenças pessoais, perspectivas, sistema de valor, insights, intuições, emoções, habilidades. É considerado como uma fonte importante de competitividade entre as organizações. Só pode ser avaliado por meio da ação. estudo etnográfico,

Agorasuas entraatividades, o trabalhode decomo resolvem situações, observações de comoesse as pessoas pes soas executam como utilizam conhecimento nas operações do dia a dia.

 

Gestão do Conhecimento e Requisitos

173

O valor deste conhecimento é claro na cultura ocidental quando um colaborador se afasta da empresa. Somente desse momento em diante é que o conhecimento tácito do colaborador começa a fazer falta. Um projeto de sistema não pode ter conhecimento tácito, deve sempre ter um contexto de contingência, logo não podemos ter requisitos que dependem do conhecimento tácito de um colaborador. Todo o conhecimento tácito necessita passar a ser explícito em um software. Objetos de conhecimento Os objetos de conhecimento são compostos por itens que podem ser agrupados em quatro partes básicas, que são:   A descrição do problema; GoalITEM.   A lista de metadados; DescriptorITEM.     

O restritor de acesso; RestrictionITEM. A solução para o problema descrito. Todo item de um objeto de conhecimento possui dois atributos, sendo element, que representa o elemento encapsulado pelo item; e elementSchema, que contém uma ontologia com todas as informações necessárias para recriar o elemento em outro contexto. O item GoalITEM encapsula o objetivo do objeto de conhecimento. O objetivo objetivo é representado por uma ontologia que descreve os conceitos envolvidos no problema cujo conhecimento encapsulado no objeto almeja solucionar. É com o uso dessa ontologia que são feitas as verificações de similaridade entre os objetos de conhecimento disponíveis e as necessidades de conhecimento. O objetivo também está associado a uma ou mais sentenças, que possibilitam possibilitam a verificação da satisfação alcançada com o uso do objeto de conhecimento.  

 

 



Para fazer a avaliação da satisfação, é necessário: Recuperar as informações sobre a execução do agente. Recuperar os critérios para verificação da realização do objetivo. Calcular a classificação da execução através da comparação dos valores obtidos durante a realização do objetivo com os valores indicados i ndicados nas sentenças. Para o desenvolvimento de um cenário de exemplo, foram criados dois obje-

tos de conhecimento com diferentes estratégias de venda para o objetivo Vender Carro”. O objetivo de um dos objetos de conhecimento (que será chamado “OC1”) está ilustrado na figura a seguir (a ontologia está representada em notação UML).

 

174

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A verificação da satisfação alcançada com o uso desse objeto de conhecimento conheci mento é feita através da verificação de duas sentenças, conforme código apresentado apresentado em seguida. kogoal.addVerificationSentence(“carroVendido”, kogoal.addVerificationSentence(“ carroVendido”, “=”, true); kogoal.addVerificationSentence(“valor”, kogoal.addVerificationSentence(“ valor”, “>=”, 10); O critério utilizado para a verificação das sentenças atribui um valor entre 1 e 5 para o alcance do objetivo, considerando a porcentagem de sentenças verdadeiras (quanto maior a porcentagem de sentenças verdadeiras, mais favorável favorá vel é o resultado da execução). Assim, se um carro é vendido a um valor maior ou igual a seu valor mínimo míni mo acrescido de 10%, o objetivo “Vender Carro” é considerado plenamente satisfeito satisfeito e, na escala de 1 a 5 considerada, atribui-se o valor 5 ao seu alcance.  Já se a compra é concluída com um valor menor do que o valor mínimo do carro acrescido de 10%, atribuiu-se o valor 3 ao alcance do objetivo. No caso de compra não concluída (o que torna as duas sentenças falsas), é atribuído o valor 1.

Figura 9.1

A etnografia é importante no entendimento e observação desses conheci-

mentos.

 

Gestão do Conhecimento e Requisitos

175

Unindo a observação, inserindo-se no ambiente, acompanhando a execução execu ção dos processos de negócio, adquirimos uma visão dos requisitos de um pro jeto pro jeto de forma segura, pois ao perceber e entender o processo através do conhecimento conhecimento tácito dos colaboradores de uma empresa, estamos mais qualificados à execução de outras técnicas de levantamento e elucidação desses requisitos. A gestão do conhecimento implica na existência de um repositório onde se registra esse conhecimento. O conhecimento em projeto armazenado nos repositórios proporciona um mecanismo eficiente e efetivo de captura do conhecimento em um projeto. Considere-se que o registro de suas observações de análise, de operações, de quem faz e como faz, aquelas simples anotações em uma folha de caderno, deve ir para dentro desse repositório. São registros do conhecimento, mesmo sendo considerado sob o ponto de vista de quem fez a observação. Uma vez que cada projeto é único e cada equipe é diferente, essa abordagem aborda gem permite flexibilidade na adoção de processos de gerência de requisitos e padrões que sejam adequados à realidade de cada projeto. Por exemplo, uma equipe em um determinado projeto pode utilizar um sistema de automação de workflow para o acompanhamento das requisições de alteração de requisitos, enquanto outra pode simplesmente utilizar trocas de e-mails entre os stakeholders para a mesma finalidade. Também é possível evitar, com essa abordagem, a perda de informações que são relevantes apenas para um determinado projeto, mas que não agregam valor ao aprendizado organizacional ou não se enquadram nos padrões globais da organização. A priorização dos requisitos, por exemplo, é uma informação relevante durante a execução de um projeto, mas perde seu sentido ao término dele, entre entretanto tanto historicamente a manutenção dessa informação em repositório de conhecimento conhecimento do projeto não é justificável, visto ser descartável ao término dele.

Classificação do Conhecimento em Análise e Gestão de Requisitos O conhecimento gerado por projetos pode ser categorizado como conhecimento em projetos, conhecimento sobre projetos e conhecimento proveniente de projetos. O conhecimento em projetos compreende informações detalhadas que são ge-

radas e utilizadas em cada projeto individual. Os envolvidos no projeto necessitam dessas informações para saber quando, quando, o quê, quem, como, onde e por quê algo é feito, visando promover uma coordenação coordenação eficiente e efetiva das atividades.

 

176

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

O conhecimento sobre projetos compreende informações que a organização necessita para saber que projetos estão sendo conduzidos em qualquer momento. Essas informações contribuem para o planejamento e controle dos recursos utilizados nesses projetos.  Já o conhecimento proveniente de projetos compreende as principais informações geradas com a execução do projeto. Esse conhecimento é determinante do sucesso futuro do projeto e contribui para o aprendizado organizacional. O primeiro passo na aplicação da abordagem de gestão de conhecimento à Especificação e Gestão de Requisitos consiste em aplicar essa categorização às informações relevantes para a Especificação de Requisitos e, em particular, para a Gerência de Requisitos. Desta forma, é possível elaborar uma lista de informações informações para cada categoria. Durante projeto, sãodos necessárias várias informações detalhadas sobre aosexecução requisitosdee um as requisições . Dentre essas informastakeholders ções, as seguintes podem ser destacadas e exemplificadas como conhecimento conheci mento em projeto:   Novos requisitos e seus respectivos estados, tais como “proposto”, “aprovado” ou “rejeitado”; Requisições de alteração de requisitos e seus respectivos estados;     Relatórios de análise de impacto i mpacto das alterações requisitadas;   Estimativas de custo e esforço para novos requisitos ou requisições de alteração em requisitos já existentes; Informações sobre a priorização dos requisitos;     Controle de versão e controle de alteração de todos os requisitos do software. De uma perspectiva mais ampla, a organização necessita de várias informações sobre a alocação de suas necessidades em requisitos de software software   e o andamento dos respectivos projetos. Essas informações são úteis para garantir o alinhamento dos esforços de T.I. com as estratégias da organização, contribuindo assim para o planejamento e controle dos recursos de T.I. Sob esta perspectiva podemos destacar as seguintes informações como co-

nhecimento sobre projetos: Projetos em andamento e as necessidades organizacionais sendo tratadas tratadas por   eles;   Produtos de software sendo criados ou modificados por cada projeto;

 

Gestão do Conhecimento e Requisitos

 

Stakeholders envolvidos em cada projeto;

 

Localidades, setores, departamentos (sites) envolvidos em cada projeto; Indivíduo ou equipe responsável por requisitos em cada projeto;

 

 



177

Métricas relacionadas aos requisitos de cada projeto.  Já o conhecimento proveniente proveniente de projetos inclui inclui as informações geradas pelos processos de Especificação de Requisitos após a execução dos projetos.  



Muitas informações evoluem durante a execução desses processos e atingem atin gem um estado estável e definitivo somente ao término do projeto, quando os requisitos  já estão implementados e o processo de gerência de mudanças mudanças já está encerrado. encerrado.  



 



 



 



Nesta categoria podemos destacar: Produtos de software criados ou modificados pelo projeto; Features implementadas; Versão final dos requisitos; Informações de rastreabilidade.

 A utilização de repositórios de conhecimento conhecimento em projetos O uso de um repositório centralizado para o conhecimento sobre e prove proveniente niente de projetos propicia a padronização e estruturação do conhecimento de longo prazo sobre os requisitos das aplicações. Os padrões estabelecidos para a publicação da especificação de requisitos no repositório centralizado podem garantir que os requisitos sejam documentados documen tados de formapela homogênea. Como de possíveis padrõesapode-se o idioma exigido organização paraexemplo os documentos publicados, técnica citar de especifica casos de uso, linguagem natural etc.), sistema ção de requisitos utilizada (casos sistema métrico utilizado e glossário unificado de termos. Além disso, o uso de um repositório centralizado pode viabilizar a especificação dos requisitos com foco no produto de software, evitando que os requisitos sejam documentados para o escopo de cada projeto individual, e que informações informações específicas de um determinado contexto possam prejudicar a interpretação da especificação do produto de software em projetos futuros ou por outras equipes. Um índice centralizado para o conhecimento em projeto, que permanece armazenado nos repositórios distribuídos, oferece um mecanismo eficiente de coor-

denação e comunicação entre as equipes distribuídas. O conhecimento em projeto armazenado armazenado em um repositório centralizado proporciona um mecanismo eficiente e efetivo de captura do conhecimento em projeto.

 

178

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Uma vez que cada projeto é único e cada equipe pode ser diferente, essa abordagem permite flexibilidade na adoção de processos de gerência de requisitos requi sitos e padrões que sejam adequados à realidade de cada caso. Por exemplo, uma equipe responsável pela execução de um projeto de manutenção em um determinado produto de software  pode localizar a especificação de requisitos que descreve o seu funcionamento em um determinado momento. Pode também encontrar um índice para os demais projetos realizados sobre o mesmo produto de software, permitindo interagir diretamente com as equipes responsáveis por eles e obter informações mais detalhadas de seus repositórios sobre o conhecimento em projeto, seus requisitos, soluções adotadas, mudanças operacionais etc. Conclusão

Este pequeno capítulo destaca a importância que deve ser dada aos conhecimentos explícitos e principalmente tácitos dos colaboradores de uma empresa, quando do levantamento de requisitos, buscando extrair o conhecimento tácito no maior volume possível. As surpresas que acontecem nas implantações de software  derivam em sua grande maioria da existência de conhecimento tácito que não foi explicitado durante o processo de Análise de Requisitos.

Exercícios 1) 

Quais são os tipos de de conhecimento que devemos observar e descobrir no no levantamento de requisitos? 2)  Cite três informações que podem ser destacadas e exemplificadas como conhecimento em projeto de software.

 

Especificação de Requisitos com Casos de Uso

10

“Para alcançar conhecimento, adicione coisas todo dia. Para alcançar sabedoria, elimine coisas todo dia.” (Lao Tsé)

Introdução Quando um novo sistema precisa ser construído, surge uma importante questão: como caracterizar os requisitos do sistema de um modo adequado para a Engenharia de Software, uma vez que é necessário identificar os objetos/entidades objetos/entidades relevantes, como eles se relacionam e como se comportam no contexto do sistema.

Além disso, é preciso especificar e modelar o problema de maneira que seja possível criar um projeto efetivo. O desenvolvimento de sistemas é um processo de construção de modelos, que tipicamente começa com um modelo de requisitos e termina com um modelo de implementação (código).

Modelos de objetos (diagramas de classes, diagramas de interação etc.) e modelos estruturados (diagramas de entidades e relacionamentos, diagramas de fluxo de dados etc.) incluem detalhes, tais como a estrutura interna dos objetos/entidades, suas associações, como eles interagem dinamicamente e como invocam invo cam o comportamento dos demais.

Essas informações são necessárias para projetar e construir um sistema, mas não são suficientes para comunicar requisitos. Elas não capturam o conhecimento das tarefas do domínio e, portanto, é difícil verificar se um modelo desse tipo realmente corresponde ao sistema que tem de ser construído.

Assim, o primeiro modelo do sistema a ser construído deve ser passível de

compreensão tanto por desenvolvedores, analistas, projetistas, programadores e testadores, como pela comunidade usuária, clientes e stakeholders stakeholders..

Modelos estruturados e de objetos são muito complexos e, portanto, não servem para esse propósito.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

180

Esse modelo inicial deve descrever o sistema, seu ambiente e como sistema e ambiente estão relacionados. Em outras palavras, ele deve descrever o sistema segundo uma perspectiva externa. Modelos caso de nome uso (caso (caso de usos estruturar visão. externa. Comodeo próprio sugere, um) são caso uma de usoforma é uma de maneira de usaressa o sistema. sistema Os stakeholders interagem Os stakeholders  interagem com o sistema, interagin interagindo do com seus casos de uso.

Tomados em conjunto, os casos de uso de um sistema representam tudo que os stakeholders podem fazer com esse sistema. Casos de uso são os “itens” que um desenvolvedor vende a seus clientes. Deve-se notar que modelos de caso de uso são independentes dos métodos e técnicas de análise a serem utilizados.

Desenvolvedores devem modelar os casos de uso explicitamente bem no início dode desenvolvimento de software. Em todo projeto, para que seja bem-sucedido, bem-sucedido, casos uso devem ser identificados. Em suma, o processo de desenvolvimento de software software   começa pelo entendimento de como o sistema será usado.

Uma vez que as maneiras de usar o sistema tenham sido definidas, a modelagem pode, então, ser iniciada.

Casos de Uso Nenhum sistema computacional existe isoladamente. Todo sistema interage inte rage com atores humanos ou outros sistemas, que utilizam esse sistema para algum propósito e esperam que o sistema se comporte de acordo com as maneiras ma neiras previstas.

Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa, e é uma descrição de um conjunto de sequências de ações realizadas pelo sistema para produzir um resultado de valor observável por um ator. Em essência, um caso de uso (caso de uso) é uma interação típica entre um ator (stakeholder  (stakeholder  humano,   humano, outro sistema computacional ou um dispositivo) e um sistema.

Um caso de uso captura alguma função visível ao ator e, em especial, busca

atingir uma meta do stakeholder . Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os stakeholders finais do sistema e com os espe-

 

Especificação de Requisitos com Casos de Uso

181

cialistas do domínio. Além disso, servem para ajudar a validar e verificar o sistema sistema à medida que ele evolui durante seu desenvolvimento. Assim, os casos de uso não apenas representam o comportamento desejado do

sistema, principalmente mas também podem ser de utilizados como base de casos de teste para o sistema, os testes integração e dea sistema.  



Casos de uso têm dois importantes papéis: Eles capturam os requisitos funcionais de um sistema. Um modelo de caso de uso define o comportamento de um sistema (e a informação associada) através de um conjunto de casos de uso. O ambiente do sistema sis tema é definido pela descrição dos diferentes stakeholders utilizam o sistema através de um stakeholders,, os quais utilizam número de casos de uso.

 



Eles oferecem uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, é comum apresentar os modelos do sistema

em um número de diferentes visões. Em uma abordagem guiada por casos de uso, pode-se construir uma visão para cada caso de uso, isto é, em cada visão são modelados apenas aqueles elemen-

tos que participam de um caso de uso específico. Um particular elemento pode, é claro, participar de vários casos de uso.

Isso significa que um modelo do sistema completo só é visto através de um conjunto de visões - uma por caso de uso. Encontram-se todas as responsabilidades de um elemento de modelo, olhando todos os casos de uso em que este tem um papel.

Além de ser uma ferramenta essencial na captura dos requisitos de um sistema, casos de uso têm um papel fundamental no planejamento e controle de projetos iterativos.

A captura dos casos de uso é a primeira atividade a ser realizada no desenvolvimento propriamente dito.

A maioria dos casos de uso é normalmente gerada durante a fase de levantamento de requisitos, mas outros casos de uso podem ser identificados à medida que a análise ocorre. Todo caso de uso é um requisito potencial e, enquanto um requisito não é

identificado, não é possível planejar como tratá-lo.

Usualmente, em primeiro lugar, casos de uso são listados e discutidos, para só então se realizar alguma modelagem.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

182

Em alguns casos, a modelagem conceitual ajuda a descobrir casos de uso. Um caso de uso pode ser capturado através de conversas com stakeholders  típicos, disstakeholders típicos,

cutindo as várias coisas que eles querem fazer com o sistema.

Cadaum uma dessas interações umuena caso (não de uso. Devemos especificar nome e escrever umadiscretas descriçãoconstitui textual pequena peq mais do que uns poucos parágrafos). Não tente capturar todos os detalhes de um caso de uso logo no início.

Os objetivos do stakeholder  podem  podem ser o ponto de partida para a elaboração dos casos de uso.

Proponha um caso de uso para satisfazer cada um dos objetivos do stakeholder . A partir deles, estude as possíveis interações do stakeholder  com  com o sistema e refine o modelo de casos de uso.

Diagramas de Casos de Uso Diagramas de casos de uso especificam as funcionalidades que um sistema tem de oferecer, segundo diferentes perspectivas dos stakeholders stakeholders.. Basicamente, um diagrama de casos de uso apresenta dois elementos, sendo sen do os atores e os casos de uso. Um ator é um papel que um stakeholder , outro sistema ou dispositivo desempenha com respeito ao sistema.

Casos de uso representam funcionalidades requeridas externamente. Uma associação entre um ator e um caso de uso significa que estímulos podem ser enviados entre atores e casos de uso. Os atores podem estar conectados aos casos de uso somente por meio de associações. A associação entre um ator e um caso de uso indica que o ator e o caso de uso

se comunicam entre si, cada um com a possibilidade de enviar e receber mensagens.

A figura a seguir mostra a notação básica da Linguagem de Modelagem Unificada (UML) para diagramas de casos de uso.

 

Especificação de Requisitos com Casos de Uso

183

Figura 10.1: Notação de casos de uso.

Notação Básica da UML para Modelos de Caso de Uso Um ator representa qualquer coisa que precise interagir com o sistema, tais como stakeholders  e outros sistemas que se comunicam com o sistema em questão. stakeholders e Atores são externos ao sistema; os casos de uso comportam os elementos de

modelo que residem no sistema. Assim, ao definir fronteiras entre atores e casos de uso, delimita-se o escopo do sistema.

Por estarem fora do sistema, atores estão fora do controle das ferramentas de modelagem e não precisam ser descritos em detalhes.

Atores representam tudo que tem necessidade de trocar informação com o sistema.

Nada mais externo ao sistema deve ter impacto sobre o sistema. . Um  é uma  é stakeholder  É importante a diferença atorrepresenta e stakeholder  pessoa que utiliza realçar o sistema, enquantoentre um ator um papel especí fico específico que um stakeholder  pode  pode desempenhar. Vários stakeholders stakeholders   em uma organização podem interagir com o sistema da

mesma forma e, portanto, desempenham o mesmo papel. Um ator representa determinado papel que equivale ao a o que diversos stakeholders stakeholders   podem desempenhar. Assim, atores podem ser pensados como classes, isto é, descrições de um comportamento, enquanto stakeholders  podem desempenhar diversos papéis e servir stakeholders podem

como instâncias de diferentes classes de atores.

Ao lidar com atores, é muito importante abstrair-se e pensar em termos de pa-

péis executados por pessoas, desconsiderando a pessoa em si.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

184

Um bom ponto de partida para a identificação de atores é verificar por que o sistema deve ser desenvolvido, procurando observar que atores o sistema se propõe a ajudar. Quando um ator interage com o sistema, normalmente ele realiza uma se-

quência comportamentalmente relacionada de ações em um diálogo com o sistema. Tal sequência compreende um caso de uso. Um caso de uso é, de fato, uma maneira específica de utilizar o sistema por meio da execução de alguma parte de sua funcionalidade. Cada caso de uso constitui um curso completo de eventos com um ator e espe-

cifica a interação que acontece entre o ator e o sistema. O conjunto de todas as descrições de casos de uso especifica todas as maneiras maneiras de usar o sistema e, consequentemente, a sua funcionalidade completa. Um bom caso de uso compreende uma sequência de transações realizadas pelo sistema, que produz um resultado de valor observável para um particular ator. Por produzir um resultado de valor observável, queremos dizer que um caso de uso tem de garantir que um ator realize uma tarefa que tem um valor identificável. Isso é de grande importância para obter casos de uso que não sejam muito pequenos.

Por outro lado, a identificação de um ator em particular é importante na obtenção de casos de uso que não sejam muito grandes. Uma boa fonte para identificar casos de uso são os eventos externos. Pense e observe bem todos os eventos do mundo externo para os quais o sistema deve reagir. Identificar esses eventos pode ajudá-lo a identificar os casos de uso.

Para sistemas grandes pode ser difícil propor uma lista de casos de uso. Nestas situações, é mais simples buscarmos identificar primeiramente uma lista de atores e então procurar elaborar os casos de uso para cada ator. Para cada curso completo de eventos com um ator, um caso de uso é identificado. Nem sempre está claro qual funcionalidade deve ser colocada em casos de uso separados ou aquilo que é na realidade apenas uma variante de um caso de uso.

A princípio, se as diferenças forem pequenas, elas podem ser descritas como

variantes do caso de uso; caso contrário, devem ser descritas como casos de uso separados.

 

Especificação de Requisitos com Casos de Uso

185

Qualquer que seja a abordagem utilizada, devemos sempre identificar os atores de um caso de uso, descobrir o objetivo real do stakeholder  e  e considerar modos alternativos de satisfazer esses objetivos.

Descrição de Casos de Uso Um caso de uso deve descrever algo que um sistema faz. Geralmente é óbvio ób vio que um diagrama de casos de uso somente é insuficiente para este propósito. Assim, deve-se especificar o comportamento de um caso de uso através de uma descrição textual de seu fluxo de eventos, de modo que alguém de fora possa compreendê-lo. Cenários

Ao escrever o fluxo de eventos, deve-se incluir como e quando o caso de uso inicia e termina, quando o caso de uso interage com os atores e outros casos de

uso e as informações transferidas, assim como quais são o fluxo básico e os fluxos alternativos do comportamento (cenários).

Como temos observado ao longo do tempo, este é um passo no qual muitos analistas sentem dificuldade de identificar quando da especificação de um caso de uso. Um caso de uso descreve uma sequência de passos/operações que um stakeholder   realiza quando interage com um sistema visando realizar uma determinada determinada tare-

fa/objetivo. Assim, o aspecto comportamental de um sistema a ser desenvolvido pode ser descrito. No entanto, a descrição de caso de uso não trata a questão de como a interação será implementada. Fases posteriores à etapa de engenharia de requisitos, como Projeto e Im-

plementação, focalizarão este aspecto. Um caso de uso pode gerar vários cenários. Cenários estão para caso de uso as-

sim como instâncias estão para classes, significando que um cenário é basicamente basi camente uma instância de um caso de uso. Um caso de uso envolve um caso de utilização do sistema por um ator. Neste

caso de utilização/uso, vários caminhos podem ser seguidos, dependendo do contexto na execução do sistema.

Esses caminhos são os possíveis cenários do caso de uso.

Considera-se que o caminho básico para realizar um caso de uso, sem problemas e sem erros em nenhum dos passos da sequência, é denominado de cená cenário rio primário. Veja bem, sem problemas e sem erros.

 

186

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Nesse tipo de cenário, a execução dos passos para realizar a funcionalidade básica do caso de uso é obtida com sucesso. Por outro lado, caminhos alternativos, bem como situações de erro, podem ser representados através de cenários secundários.

Cenários secundários descrevem sequências alternativas e de erros que podem po dem

ocorrer em um cenário primário associado com um caso de uso. Eles podem ser descritos separadamente ou como extensão da descrição de um cenário primário. primário.

Se um cenário secundário é bastante complexo e inclui um conjunto bastante bastante grande de passos, é conveniente descrevê-lo separadamente. Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um deles deve ser descrito em mais detalhes.

Primeiramente é preciso descrever o fluxo de eventos principal (ou curso básico), isto é, o curso de eventos mais importante, que normalmente ocorre.

Variantes do curso básico de eventos e erros que possam vir a ocorrer devem devem ser descritos em cursos alternativos. Normalmente, um caso de uso possui apenas

um único curso básico, mas diversos cursos alternativos. Tomemos como exemplo um caixa automático de banco, cujo diagrama de casos de uso é mostrado na figura a seguir.

Figura 10.2: Exemplo de um modelo de caso de uso.

O caso de uso Efetuar Saque poderia ser descrito da seguinte maneira:

 

Especificação de Requisitos com Casos de Uso

187

Cenário de Eventos Principal 

Uma mensagem de saudação está sendo mostrada na tela.



O cliente insere seu cartão no caixa automático, que lê o código da tarja mag-

 

nética e checa se ele é aceitável.  



 

 

 

   



Se o cartão é aceitável, o caixa pede ao cliente para informar a senha e fica aguardando até que ela seja informada. O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transação e fica aguardando. O cliente seleciona a opção saque.

O caixa mostra uma tela para que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisição para o sistema bancário para que seja efetuado um saque na quantia especificada. e specificada. Se o saque é autorizado, as notas são preparadas para serem entregues, o car-

tão é ejetado, um recibo é emitido emi tido e as notas liberadas. Cenários Alternativos O cartão não é aceitável: 

Se o cartão não é aceitável porque sua tarja magnética não é passível de leitura ou é de um tipo incompatível, o cartão é ejetado com um bip. Senha incorreta:



Se a senha informada está incorreta, uma mensagem deve ser mostrada para o cliente que pode entrar com a senha correta.



Caso o cliente informe três vezes senha incorreta, o cartão deve ser confiscado. confiscado. Saque não autorizado:



Se o saque não for aceito pelo Sistema Bancário, uma mensagem informando informando o cliente é mostrada por dez segundos e o cartão é ejetado. Cancelamento:



O cliente pode sempre cancelar a transação em qualquer momento que lhe l he seja

perguntada alguma informação. Isso resulta na ejeção do cartão e no término da transação.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

188

Como visto pelo exemplo anterior, um caso de uso pode ter um número de

cursos alternativos que podem levar o caso de uso por diferentes fluxos. Tanto quanto possível, esses cursos/fluxos/cenários  cenários alternativos, frequentemente cursos de exceção, devem ser anotados durante a especificação de um caso do uso.

 Associações entre Casos de Uso Uma vez que um modelo de caso de uso expressa apenas a visão externa do sistema, comunicações internas entre elementos do sistema não devem ser modeladas.

Para permitir uma descrição mais apurada dos casos de uso em um diagrama, diagrama, três tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritos como versões especializadas de outros casos de uso (relacionamento de generalização/especialização); casos de uso podem podem ser incluídos como parte de outro caso de uso (relacionamento de inclusão); ou casos

de uso podem estender o comportamento de outro caso de uso básico (relacionamento de extensão).

O objetivo desses relacionamentos é tornar um modelo mais compreensível, compreensível, evitar redundâncias entre casos de uso e permitir descrever casos de uso em camadas.

O relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso. O local em que esse comportamento é incluído deve ser indicado na descrição descrição

do caso de uso base, através de uma referência explícita à chamada ao caso de uso incluído.

Um relacionamento de inclusão é empregado quando há uma porção de com-

portamento que é similar ao longo de um ou mais casos de uso e não se dese ja dese ja repetir a sua descrição.

Para evitar redundância e assegurar reúso, extrai-se essa descrição e compartilha-se entre diferentes casos de uso. Um relacionamento de inclusão é representado por uma dependência, estereotipada este reotipada como inclui (include), como apresentado a seguir.

do caixa automático, podemos perceberinicial que osdo três casos de uso têm No em exemplo comum uma porção que diz respeito à transação cartão. Neste caso, um relacionamento inclui deve ser empregado, como mostra a figura seguir.

 

Especificação de Requisitos com Casos de Uso

189

Figura 10.3: Relacionamento de inclusão.

O relacionamento inclui descreve compartilhamento entre casos de uso.

O caso de uso Validar poderia ser descrito da seguinte forma: Cenário ou Curso Normal  

Uma mensagem de saudação está sendo mostrada na tela.

 

O cliente insere seu cartão no caixa automático, que lê o código da tarja mag-

 

nética e checa se ele é aceitável.  



 



Se o cartão é aceitável, o caixa pede ao cliente para informar a senha e fica aguardando até que ela seja informada. O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transação e fica aguardando.

 Cenários ou Cursos Alternativos Cenários O cartão não é aceitável: 

Se o cartão não é aceitável porque sua tarja magnética não é passível de leitura ou é de um tipo incompatível, o cartão é ejetado com um bip. Senha incorreta:



Se a senha informada está incorreta, uma mensagem deve ser mostrada para o cliente que pode entrar com a senha correta.



Caso o cliente informe três vezes uma senha incorreta, o cartão deve ser bloqueado para uso.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

190

Cancelamento: 

O cliente pode sempre cancelar a transação em qualquer momento que lhe seja perguntada alguma informação.

 



Isso resulta na ejeção do cartão e no término da transação. Com essa identificação isolada do caso de uso de Validar Cliente, o caso de uso Efetuar Saque passaria a apresentar a seguinte descrição: Cenário ou Curso Normal  

O cliente realiza o caso de uso Validar Cliente.



 

O cliente seleciona a opção saque.



O caixa mostra uma tela para que seja informada a quantia. O cliente informa



a quantia a ser sacada. 

O caixa envia uma requisição para o sistema bancário para que seja efetuado um saque na quantia especificada. Se o saque é autorizado, as notas são preparadas para serem entregues, o cartão é ejetado, um reci recibo bo é emitido e as notas liberadas.

 Cenários ou Cursos Alternativos Cenários Saque não autorizado:  



Se o saque não for aceito pelo Sistema Bancário, uma mensagem informando informando o cliente é mostrada por dez segundos e o cartão é ejetado. Cancelamento:

O cliente pode sempre cancelar a transação em qualquer momento que lhe seja perguntada alguma informação.  Isso resulta na ejeção do cartão e no término da transação. O relacionamento de generalização entre casos de uso significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai. 

O caso de uso filho deve acrescentar ou sobrescrever o comportamento de seu pai e pode ser substituído em qualquer local no qual o pai apareça. Voltando ao exemplo do sistema de caixa automático, suponha que haja duas formas adotadas para validar o cliente: a primeira através de senha, como descrito

anteriormente, e a segunda por meio de análise da retina do cliente. Neste caso, podem ser criadas duas especializações do caso de uso Validar Cliente, como mostra a Figura 10.4.

 

Especificação de Requisitos com Casos de Uso

191

Figura 10.4: O relacionamento de generalização/especialização entre casos de uso.

Um relacionamento de extensão entre casos de uso significa que o caso de uso base incorpora implicitamente o comportamento de outro caso de uso em um local especificado em sua descrição, como sendo um ponto de extensão. O caso de uso base pode permanecer isolado, mas sob certas circunstâncias, seu comportamento pode ser estendido pelo comportamento de outro caso de uso. Um relacionamento de extensão é utilizado para modelar uma parte de um caso de uso que o stakeholder  considera  considera como opcional.

Desse modo, separa-se o comportamento opcional do comportamento obrigatório.

Um relacionamento de extensão também pode ser empregado para modelar mode lar um subfluxo separado, que é executado somente sob determinadas condições. Assim como o relacionamento de inclusão, o relacionamento de extensão é representado como uma associação de dependência, agora estereotipada como estende (extend).

O relacionamento estende permite capturar os requisitos funcionais de um sistema complexo de forma incremental. Inicialmente, as funções básicas são entendidas, para só então a complexidade complexidade ser introduzida.

Na modelagem de casos de uso, devemos primeiramente descrever os casos casos

de uso básicos, para só então estendê-los para permitir descrever casos de uso mais avançados.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

192

O caso de uso no qual a nova funcionalidade é adicionada deve ter um curso de eventos completo e significativo por si próprio. Assim, sua descrição deve ser completamente independente.

Suponha deseja-se dados estatísticos sobre oque, usono da exemplo transaçãodo decaixa saqueautomático, para alimentar o caixacoletar eletrônico com as notas mais adequadas para saque.

Para tal, poderíamos estender o caso de uso Efetuar Saque, de modo que, quando necessário, outro caso de uso, denominado Coletar Informações Estatísticas de Saque, contasse e acumulasse o tipo das notas entregues em um saque. A Figura 10.5 ilustra este caso.

Figura 10.5: O relacionamento estende entre casos de uso.

O relacionamento estende é usado, então, para modelar extensões a outros casos de uso completos e é utilizado para modelar:  

Partes opcionais de casos de uso;

 

Cursos complexos e alternativos;

 

Subsequências que são executadas apenas em certos casos; ou A inserção de diversos casos de uso diferentes em outro.   A quebra de um caso de uso em vários pode ocorrer tanto na fase de levantamento de requisitos quanto na fase de análise e projeto.  



Na fase de levantamento de requisitos, é interessante desmembrar aqueles casos de uso que se apresentam muito complicados. Entretanto, há casos de uso cuja

complexidade global não deve ser detalhada antes da fase de projeto. Para utilizar os relacionamentos de inclusão e extensão, aplique as seguintes seguintes regras:

 

193

Especificação de Requisitos com Casos de Uso

 

Utilize o relacionamento estende quando estiver descrevendo uma variação va riação de um curso normal.

 

Utilize o relacionamento inclui quando houver repetição em dois ou mais ca-





sos de uso separados e for desejável evitar a repetição.

Durante a análise e descrição detalhada dos casos de uso, o sistema é cuidadosamente analisado.

Uma vez que, geralmente, os casos de uso enfocam uma particular funcionalidade, é possível analisar a funcionalidade total do sistema de maneira incremental conforme a progressão dos trabalhos de análise de requisitos. Deste modo, casos de uso para áreas funcionalmente diferentes podem e devem ser desenvolvidos independentemente, mas sem perder a visão corporativa corporativa e,

mais tarde, reunidos para formar um modelo de requisitos completo. Com isso, permite-se enfocar um problema de cada vez, abrindo caminho para um desenvolvimento incremental.

À medida que os modelos crescem, é importante dividi-los para facilitar a leitura e o entendimento. Dividir um sistema complexo em subsistemas é sempre uma boa opção. Para dividir e reunir casos de uso em grupos relacionados conceitual e semanticamente, a UML oferece como ferramenta de modelagem os pacotes. A figura a seguir mostra um exemplo no contexto de um sistema bancário. Neste exemplo:  





O sistema bancário não está mais sendo considerado outro sistema, mas um subsistema do mesmo sistema do caixa automático. A associação de dependência entre os pacotes mostrada na Figura 10.6 indica que o pacote caixa automático solicita serviços do pacote contas.

Figura 10.6: Pacotes.

Casos de Uso Agrupados em Pacotes

Sendo a funcionalidade do sistema capturada nos casos de uso, ela deve ser alocada a diferentes elementos de modelagem.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

194

Um elemento de modelagem, obviamente, pode ser comum a diversos casos de uso. Basicamente, o mapeamento de um caso de uso em elementos de modelo pode ser apoiado pelos seguintes princípios:

As funcionalidades dos casos de uso que lidam com o registro e a manipulação manipulação de informação são mapeadas diretamente para elementos em um modelo mode lo de análise.

As funcionalidades diretamente dependentes do ambiente do sistema representam funcionalidades requeridas pela interface do sistema e, portanto, são tratadas na fase de projeto, especificamente no projeto da interface do sistema. Finalmente, funcionalidades que tipicamente envolvem o controle de uma aplicação devem ser mapeadas em elementos no projeto do controle do sistema. No processo de construção de casos de uso o analista deve se preocupar em descrever “o quê” acontece entre o stakeholder  e   e o sistema, sem, entretanto, informar “como” essa interação ocorre.

O processo de construção de caso de uso inicia com a descoberta dos atores do sistema e prossegue com a descoberta do(s) caso(s) de uso associado(s) com esses atores.

Para cada ator são encontrados todos os casos de uso relacionados a ele.

Figura 10.7: Notações UML para casos de uso.

 

Especificação de Requisitos com Casos de Uso

195

Notações para Casos de Uso em UML Isso ocorre porque cada ator requer do sistema algumas funcionalidades. Os passos necessários para obter essas funcionalidades são descritos em casos de uso. O segundo passo consiste em definir os caminhos básicos (cenários primários) primários)

e posteriormente os caminhos alternativos (cenários ( cenários secundários) para cada um dos casos de uso.

O terceiro passo envolve revisar descrições de aspectos comportamentais de casos de uso encontrando relacionamentos do tipo , > e . Esse processo é geralmente realizado adotando o princípio de desenvolvimento de software  iterativo e incremental. software iterativo

Após definidos todos os casos de uso e atores do sistema, desenvolve-se um modelo de caso de uso utilizando as notações apresentadas na figura anterior. À medida que é detalhado o fluxo principal, deve-se identificar os fluxos alternativos. Para auxiliar a identificação, observe as seguintes questões:   Existem respostas diferentes, dependendo da ação do ator? (por exemplo, exem plo, o ator informa um número de cartão inválido enquanto utiliza um caixa eletrônico).  



Quais operações de negócio podem afetar a operacionalização do caso de uso? (o ator requisita ao caixa eletrônico mais dinheiro do que está disponível na sua conta).

 



O que poderia dar errado? (o cartão foi inserido de forma incorreta, não há

conexão de rede disponível quando é necessária uma transação). estrutura, Para esclarecer onde um fluxo de eventos alternativo se encaixa na estrutura, é necessário descrever:  



Onde o comportamento alternativo pode ser inserido no fluxo de eventos eventos principal.

 

Qual a condição que precisa ser atendida para que o comportamento alternativo inicie.

 

Como e onde o fluxo de eventos principal é retomado, ou como o caso de uso





termina.

Tanto o fluxo de eventos principal quanto os fluxos de eventos alternativos

devem ser estruturados em passos e subfluxos.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

196

Detalhar Precondições e Pós-Condições

Uma precondição é uma restrição sobre quando um caso de uso pode começar co meçar e não é o evento que inicia o caso de uso. Uma precondição num caso de uso descreve o estado, e não ações, em que o sistema deve estar para que possa ser iniciado. Exemplo: “O cartão tem de estar inserido para leitura”. A situação mais comum, que sinaliza uma precondição, é a necessidade de o stakeholder  já  já ter sido autenticado. Uma pós-condição lista os possíveis estados, e não ações, em que o sistema

pode apresentar quando finalizado. O sistema deve estar num desses estados. As pós-condições são asserções que se aplicam ao final da execução do caso de uso. Elas mostram o estado que o sistema pode apresentar após o seu término. té rmino.

Regras de Negócio

As regras de negócio são tipos especiais de obrigações, são requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao negócio, como um todo, ou mesmo, específico para um determinado caso de uso. As regras de negócio devem ser claras, evidenciando onde e quando devem de vem ser aplicadas.

Podem ser classificadas de várias formas, embora seja comum separá-las em regras de restrição e de derivação.   Regras de restrição:



 



especificam políticas e condições que restringem o comportamento e a estrutura de objetos. Regras de estímulo e resposta: restringem o comportamento especificando especificando quando e se as condições devem ser verdadeiras para que o comportamento

seja disparado. Esse tipo de regra afeta o fluxo de tra trabalho balho de um caso de uso. É possível mostrar um caminho condicional ou alternativo através dos fluxos do caso de uso.

Exemplo: quando um pedido é cancelado, ele deve ser finalizado retornando retornando a situação do Estoque.   Regras de restrição de operação:



especificam as condições que devem ser

verdadeiras antes apósdeuma operação para égarantir que esta seja executadae corretamente. Essee tipo regra geralmente convertido em precondições pós-condições ou em um caminho condicional ou alternativo alternativo em um fluxo de trabalho. Exemplo: enviar o pedido somente se o cliente possui endereço de entrega. entrega.

 

Especificação de Requisitos com Casos de Uso

197

  Regras de restrição de estrutura:



determinam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados. violados. Esse tipo de regra afeta as relações entre instâncias de classes conceituais. conceituais. Elas são expressas pela existência de uma associação entre classes; classes; às vezes como uma multiplicidade na associação.

 



 



Exemplo: um pedido se refere a um produto no mínimo. Regras de derivação: definem políticas ou condições para deduzir ou calcular fatos de outros fatos. Regras de dedução: especificam que se determinados fatos são verdadeiros, verda deiros, uma conclusão pode ser deduzida. Esse tipo de regra implica em um método

que precisa ser refletido em um estado de atividade do fluxo fl uxo e eventualmente em uma operação.

Exemplo: um Cliente é um Bom Cliente se e somente se as faturas não pagas, enviadas a esse Cliente, têm menos de 30 dias. O resultado da avaliação dos alunos deve ser classificado da seguinte maneira: O Aluno é considerado aprovado se atingir média igual ou superior a 7.0. O Aluno é considerado em Recuperação se atingir média maior ou igual a 5.0

e inferior a 7.0. O Aluno é considerado reprovado se atingir média menor que 5.0.   Regras de cálculo:



derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução. Esse tipo de regra é semelhante à regra de dedução, contudo o método deve ser mais formal e semelhante a um algoritmo.

Exemplo: o preço líquido de um Produto é calculado da seguinte maneira: maneira: preço do produto * (1+porcentagem de imposto/100). A avaliação dos alunos deve ser calculada calcula da pela média aritmética de suas notas.

Orientação Sobre a Especificação de Casos de Uso de Relatórios

A Especificação de Caso de Uso de relatórios não difere de uma Especificação Especificação de Caso de Uso de uma interface. Essa especificação deve abordar o que ocorre quando o caso de uso é acionado, acionado, descrevendo mecanismo de seleção do relatório (se houver), quais informações infor mações

esse relatório apresentará e o layout desejado. Na Especificação de Caso de Uso também deve ser esclarecido o tipo do relatório (operacional/on-line ou analítico/batch ). batch).

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

198

Se for analítico, informar se o relatório será agendado por data ou se será um agendamento repetitivo.  



Para agendamento por data, informar a data e a hora em que o relatório deve ser disparado.

Para agendamento repetitivo, informar a periodicidade (DIÁRIO, SEMANAL, SEMANAL, MENSAL) e o horário a ser disparado. Independente do tipo de agendamento, deve-se também informar como o relatório será recuperado - através de alguma funcionalidade ou encaminhamento encaminhamento por e-mail. No caso de relatórios enviados por e-mail, configurar também o assun 



to do e-mail, geralmente colocando o nome do relatório e a data de geração.

Os relatórios analíticos gerados ficam disponíveis no servidor por 15 dias (tempo padrão), mas este prazo pode ser configurado de acordo com a necessidade necessidade da aplicação. Sendo assim, se o tempo necessário for maior que o padrão, ele deve ser informado na Especificação de Caso de Uso. Lembretes e Dicas para Detalhar um Caso de Uso  



Escreva os passos numa sequência lógica, conforme acontece a interação interação ator/ sistema.

 



Use gramática simples. Uma sentença mal formulada torna o passo difícil de entender.

 

Mantenha os passos curtos e objetivos. Escrever com muito detalhe, em tudo, deixa o caso de uso extenso e a leitura le itura cansativa e confusa. Numere os passos, isso clarifica a especificação e facilita a comunicação.

 

A cada passo, cite quem vai realizar a ação. Exemplo:

 



 

• 1 Ator: informa os dados solicitados. • 2 Sistema: verifica e valida as informações.  



Relacione, se for o caso, as regras de negócio com os passos. Exemplo: • 1 Ator: informa o valor para a retirada. • 2 Sistema: verifica saldo [R1]. Regras de Negócio

[R1] - É necessário haver fundos, em conta, suficientes para a retirada.

sistema deve   A especificação de caso de uso de análise deve dizer “o quê” o sistema



fazer (quais serviços são disponibilizados pelo sistema), e não “como” será implementado (chamadas de métodos).

 

199

Especificação de Requisitos com Casos de Uso

 



 



 



 



Lembre-se de que um ator tem um objetivo e o sistema deve ajudá-lo a atingir esse objetivo. Inicie a especificação do fluxo principal com o cenário de sucesso, escreva escreva todos os passos que levam odeator a alcançar esse objetivo. Depois inclua i nclua todas as exceções (possibilidades falhas). Importante: identifique todas as possibilidades de falha antes de iniciar a construção, pois identificá-las durante a programação é mais oneroso para o pro jeto. Verifique se cada especificação de caso de uso possui sua correspondência correspon dência no Modelo de Casos de Uso.

 



Independente do passo que está sendo especificado, cenário principal, subfluxo ou o cenário alternativo, será descrita uma uma das seguintes seguintes ações: • Uma interação entre o ator e o sistema (“Ator informa o CPF”). • Uma validação (“Sistema valida o CPF”). • Uma mudança/atualização interna (“Sistema atualiza os dados do cadastro”).

Figura 10.8

Modelo de Casos de Uso  

Descreve quem são os stakeholders  e o que eles precisam do sistema. stakeholders e

 

Especifica a interface com o stakeholder . Descreve como o sistema é utilizado, como aparência, utilização, sonorização, sonorização,

 

 



animação.

 



Na realidade, esses dois modelos são complementares e devem ser de-

senvolvidos conjuntamente.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

200

Integração Modelo x Interface Acadêmica  



Devem ser completamente separados, para evitar a imposição de restrições restrições de

um modelo sobre o outro. Prática  

Um protótipo da interface é incluído nas especificações detalhadas de casos de uso.

 

A descrição dos casos de uso não deve incluir referências a componentes componentes de interface.





Figura 10.9

 

201

Especificação de Requisitos com Casos de Uso

Um modelo de especificação de caso de uso - cenário principal

Figura 10.10

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

202

Um modelo para um cenário alternativo

Figura 10.11

Como encontrar atores?  

Iniciar pelos atores primários.

 

A quem o sistema oferece algo de valor?

 

Sem eles, o sistema não seria necessário!

 

Definir os papéis desses stakeholders stakeholders..

   

 

Papéis = atores.

 

Não esquecer dos atores auxiliares.

 

Para tomar decisões.

  

 

Especificação de Requisitos com Casos de Uso

 

Realizar serviços específicos do sistema.

 

 Atores nem sempre são pessoas. Atores

 

Equipamentos, sensores e outros sistemas.

  

Identifique as Fontes de Informação

O Sistema tem as informações para tratar um vento gerado por um ator? Não! Então quem a fornece? Outro ator? Atores ou não? Exemplos:

Banco de dados?  

Não

Sistema operacional?  

Não

Impressora?  

Não

Sensor de calor num sistema de monitoramento de incêndio?  

Sim

203

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

204

Exercícios Considere a seguinte descrição de sistema de empréstimo de publicações da biblioteca de uma universidade: As publicações disponíveis são livros e revistas. Quando um aluno quer requisitar uma publicação, preenche um formulário por cada publicação, indicando o título e os autores (no caso de ser um livro), e entrega-o a um funcionário. Cada aluno pode efetuar até três empréstimos. A biblioteca bibli oteca também deve fazer o controle dos empréstimos atrasados, avisando os leitores por e-mail quando forem ultrapassados os sete dias de atraso. Os alunos devem poder pesquisar as publicações existentes na biblioteca. No caso de uma publicação já estar requisitada, é mostrada a data esperada para entrega. Quando chega uma nova publicação, ela é encaminhae ncaminhada ao responsável pela catalogação, quando será analisada e então definida a sua área de conhecimento. Existem várias áreas á reas de conhecimento, podendo ser criadas

outras. Os leitores, professores e alunos interessados em consultar publicações não existentes na biblioteca podem apresentar uma proposta ao responsável para sua aquisição. 1) 

Identifique os atores no problema descrito.

2) 

Identifique os estados de publicação.

3)  Faça um diagrama de caso de uso para este sistema. 4)  Explique o cenário principal do caso de uso, digamos digamos chamado de Registrar

empréstimo de publicação.

 

O que é SCRUM?

11

“Saber é compreendermos as coisas que mais nos convêm.” (Friedrich Nietzsche)

Conceitos O SCRUM é um  framework  framework   (diga-se um conjunto de ferramentas e técnicas) usado para o desenvolvimento ágil de software  de forma iterativa e incremental. software de As origens do SCRUM foram em 1986, quando Hirotaka Takeuchi e Ikujiro

Nonaka descreveram uma nova abordagem veloz e flexível para os projetos de desenvolvimento, fazendo analogia ao movimento no rugby (futebol americano). A equipe tenta percorrer uma determinada distância como uma unidade (todo mundo junto) passando a bola entre eles (todos colocam a “mão na massa”). O nome SCRUM vem de uma jogada ou formação do rugby, em que oito jo-

gadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida.

Figura 11.1: SCRUM - movimento no rugby.

Percebe-se logo onde já entra a primeira grande questão num modelo ágil? O trabalho em equipe é o ponto principal e talvez o mais importante.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

206

É fundamental e crucial que se tenha um olhar de time para entender o que é ser ágil e praticar no dia a dia. SCRUM é um processo empírico para o desenvolvimento de software  de alto software de valor agregado de ciclos sucessivos de incrementos ao produto. O trabalho é realizado comatravés prazo fixo , de forma colaborativa e autônoma e baseado em uma lista dinâmica de requisitos. O processo SCRUM foi estabelecido por Ken Schwaber e Jeff Sutherland e está baseado no manifesto ágil, que defende os seguintes pontos:  



 



q ue processos e ferramentas. ferramentas. Pessoas e suas interações são mais importantes do que Software  funcionando é mais importante do que documentação extensa e abrangente.

 

Colaborar com o cliente é mais importante do que negociar contratos.

 

Responder  às mudanças essenciais com agilidade e flexibilidade é mais im-

 

portante do que seguir um plano.

Quando se diz que ele é incremental e iterativo, indica que temos períodos definidos que se repetem até que o produto final fique pronto (iterativo), e que ao fim de cada período deste temos um bloco funcional do produto final entregue (incremental). No tocante ao assunto do livro, o grande aspecto a considerar no framework no  framework e  e técnicas do SCRUM é o conceito que os requisitos mudam ao longo do processo de desenvolvimento, e tem como estratégia iterações curtas, que permitem uma avaliação dos requisitos periodicamente.

No Guia do SCRUM, Schwaber (2009) explica que SCRUM não é um processo pro cesso nem uma técnica, é um framework um  framework com objetivo de transparecer a eficácia, em que se pode empregar diversos processos e técnicas. um frameworkk, o que significa que SCRUM SCRUM não é uma metodologia, é um framewor

não vai dizer exatamente o que fazer. Ele é baseado em processos empíricos, possui uma abordagem iterativa e incremental, o que permite maior previsibilidade e controle dos riscos. Ao assumir que o objetivo do projeto é o produto e não a documentação, pois critérios e processos de desenvolvimento baseados num rigor documentacional documenta cional não garantem nem qualidade e muito menos produtividade, o SCRUM busca ge-

rar apenas a documentação suficiente e necessária para atingir o objetivo de entre-

gar um produto que dê ao cliente cli ente um retorno rápido do seu capital investido. i nvestido. Ao defender que abraçar as mudanças é mais importante do que seguir um plano, SCRUM vem de encontro às metodologias tradicionais de desenvolvimento desenvolvimento

 

O que é SCRUM?

207

de software, exigindo muita disciplina e organização para que se tenha a habilidade

de ser flexível com estabilidade.

O SCRUM consiste em equipes ou times de SCRUM com seus papéis associados, eventos com duração fixa e artefatos. O framework possui também regras, que vão delimitar a atuação a tuação dos diferentes diferentes

papéis e eventos, descritas ao longo deste capítulo. Schwaber explica que os times de SCRUM devem ter como objetivo a flexibilidade e produtividade e para isso eles necessitam ser auto-organizados, interdisciplinados e trabalhar em iterações.

Os Papéis no SCRUM Os times de SCRUM têm pelo menos três papéis: 

O ScrumMaster;



Product Owner;

 



O Time ou Equipe.

Product Owner (PO) é o dono do produto. Ele possui a visão do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog (lista de requisitos), planejar releases, priorizar requisitos e passar ao time uma visão clara dos objetivos do projeto.

É indicado então que o PO seja um profissional do lado do cliente, lembra l embra vagamente o Patrocinador (Sponsor) de um projeto, porém sua interatividade com o projeto e participação constante fazem deste papel um diferencial muito importante. O ScrumMaster é a pessoa responsável por garantir que o processo seja enten-

dido e seguido. Ele deve verificar se a equipe ou time de SCRUM está aderindo aderindo aos valores, princípios, práticas e regras do SCRUM. Apesar de o ScrumMaster não gerenciar a equipe ou time de SCRUM (visto não ser um gerente de projeto), pois esse time deve ser auto-organizado, ele deve fazer com que o time de SCRUM entenda e use autogerenciamento e interdisciplinaridade. No nosso mundinho real o ScrumMaster acaba sendo um papel

exercido pelo gerente de projetos.

A responsabilidade do ScrumMaster é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e o Product Owner. O conceito de gerenciamento no SCRUM é dividido entre os membros do Time, ScrumMaster e Product Owner. Este é um ponto muito forte e é requisito para buscar a agilidade: o autogerenciamento. Ao contrário das chamadas meto-

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

208

dologias tradicionais, que seguem um modelo definido de desenvolvimento de e mpírico, ou seja, software baseado em fases e atividades, o SCRUM é um processo empírico, você não me diz como eu devo fazer, somente o que quer como resultado. esse modelo de completo autogerenciamento só pode ser realizadoInfelizmente se estivermos com um time composto de profissionais de nível sênior; caso contrário, torna-se uma missão quase impossível de ser realizada. Necessita-se de uma voz de comando.

Depois disso, nós aprendemos durante o processo e evoluímos com esse aprendizado, buscando juntos o objetivo a ser alcançado. A responsabilidade de gerenciar o Backlog do Produto (lista de requisitos) que será desenvolvido é do Product Owner. Ele também é responsável por garantir que o trabalho realizado pelo Time tenha valor, garantindo uma priorização priorização correta dos itens do Backlog. Seu sucesso depende que haja respeito com relação às suas decisões. A Equipe/Time de SCRUM é formada pelos analistas, desenvolvedores e testadores de software software,, que a cada Sprint, baseados nas prioridades do Backlog, devem entregar alguma parte do software  pronto. software pronto.

O que São Sprints No SCRUM, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades atividades

deve ser executado.

Metodologias ágeis de desenvolvimento de software  são iterativas, ou seja, o software são trabalho é dividido em iterações, que q ue são chamadas de Sprints no caso do SCRUM. Times também precisam tomar a decisão de como realizar a tarefa de entregar o Software  Pronto dentro do prazo, e para isso precisam ser auto-organizados Software Pronto e interdisciplinares. No SCRUM há avaliações diárias do andamento do projeto. A cada dia de um Sprint, a equipe faz uma breve reunião, chamada Daily SCRUM Meeting. SCRUM Meeting. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior,

identificar impedimentos e priorizar o trabalho do dia que se inicia.

Essa reunião é utilizada para que a equipe relate o que foi feito desde a última

reunião, o que será feito até a próxima reunião e para informar a causa para determinados atrasos.

 

209

O que é SCRUM?

Figura 11.2

Com essas informações o ScrumMaster reavalia o projeto e toma medidas para contornar os problemas relatados. Há também as reuniões de planejamentos de sprints, reuniões de revisão de sprint e reuniões de retrospectiva de sprints, ou seja, em intervalos pequenos (dias, semanas e meses) a viabilidade de atingir as metas do projeto é reavaliada, considerando mudança de requisitos, com a presença do cliente cli ente nessas reuniões.

Em vez de etapas e atividades definidas no início do projeto, o ciclo de vida de um projeto SCRUM é composto por iterações de software  funcionando. software funcionando.

O ciclo de vida é representado pela figura seguinte, conhecidíssima de vários artigos na web, mas que vale a pena apresentar:

Figura 11.3: Ciclo de vida do SCRUM.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

210

Product Backlog O product backlog (lista de requisitos) é o coração do SCRUM. É aqui que tudo começa. Ele é basicamente uma lista de requisitos, histórias. Coisas que o cliente deseja, descritas utilizando a terminologia do cliente. Nós as chamamos de histórias ou algumas vezes apenas de itens do backlog.

Aí é que estão os requisitos que desejamos entender e para os quais vamos projetar o sistema.

User Story User stories são descrições simples que representam uma funcionalidade. O recomendável é que essas user stories sejam escritas do ponto de vista de uma necessidade dos usuários. No SCRUM, as user stories são escritas em cartões (de papel) em conjunto com o cliente, a equipe de desenvolvimento orça as horas gastas para desenvolver desen volver cada user stories e então, em conjunto com o cliente, elas são priorizadas (o que ajuda a

selecionar as funcionalidades mais importantes e eliminar o excesso exces so de funcionalidades inúteis). Normalmente não se vê um use case ser realmente entendido pelo cliente, o que já acontece com as user stories (histórias), que o próprio cliente escreve.

Antigamente o mesmo ocorria com os DFDs, havendo uma exigência que fossem realizados para o sucesso de um projeto, só que da mesma forma os interessados não entendiam nada, e muito menos os desenvolvedores.

É interessante o uso de user stories para manter o foco do projeto, mas a língua portuguesa ainda continua sendo um obstáculo. O Dilema das User Stories Como as user stories devem ser escritas pelo cliente, com certeza encontraremos problemas para compreender o cliente. Se escrevermos o que entendemos, voltamos ao problema inicial do levantamento de requisitos que é entender o que o cliente deseja/necessita, pois, na

maioria vezes, o cliente não sabe explicar suas necessidades. Para que este dilema não ocorra, esse contato próximo com o cliente é um pon-

to forte e fundamental. Desta forma, a realização das user stories acaba sendo um “contrato inicial” entre a equipe e o cliente.

E como sabemos que requisitos mudam, esse tipo de artefato deixa o processo processo transparente para todos, além de distribuir a responsabilidade entre cliente e empresa.

 

O que é SCRUM?

211

No desenvolvimento ágil, a “user story” é um substituto leve e mais ágil para o que tem sido os nossos meios tradicionais para especificação de requisitos de software, como, por exemplo, especificações de casos de uso e assim por diante. De fato, um argumento que pode ser feito para a “user story” é que ela é o mais importante artefato em desenvolvimento ágil, porque é um contêiner que

transporta principalmente o fluxo de valor para o usuário, e em desenvolvimento ágil, isto é, tudo para uma entrega rápida. A user story é uma breve declaração de intenções que descreve algo que o sistema precisa fazer para o usuário. Vale lembrar que 82% do custo envolvido em retrabalho surge devido à má

definição de requisitos e 56% dos projetos entregues e considerados falhos são ocasionados por problemas nessa etapa do desenvolvimento, segundo pesquisa de James Martin. devemosuma nos preocupar constantemente com ae forma como os sistemasPor são isso, requisitados, vez que quanto mais detalhada tangível a requisição requi sição for, melhor será o entendimento pelas outras partes do projeto Utilizando práticas de engenharia de requisitos, mantemos as user stories bastante simples e alinhadas ao negócio, melhorando a especificação do que deve ser

feito e, consequentemente, aumentando a velocidade e a confiança da equipe sobre o que está sendo desenvolvido. Outro ponto a ressaltar é que o SCRUM não prega como obrigação seguir a

user story. Ela é bastante utilizada devido à sua grande facilidade neurolinguística neurolinguística de capturar necessidades e comprovar a sua real utilidade.

Devemos observar que, ao melhorar a execução das user stories com diversas diver sas técnicas de análise de requisitos, não transformamos o  framework do o framework  do SCRUM. No XP, user stories são frequentemente escritas e scritas pelo cliente, integrando assim o cliente diretamente no processo de desenvolvimento. Em SCRUM, o Product Owner muitas vezes escreve as user stories com a entrada dos clientes, stakeholders  e do time. stakeholders e

Na prática, qualquer membro da equipe com conhecimento do domínio (Negócio) é suficientemente capaz de escrever user stories, mas cabe ao Product Owner aceitar e dar prioridade a essas histórias em potencial para o product backlog.

User stories são uma ferramenta para definir o comportamento de um sistema de uma forma que seja compreensível tanto para os desenvolvedores e usuários. Elas fornecem uma abordagem efetiva para o gerenciamento de requisitos para um sistema.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

212

Uma user story capta uma breve declaração de uma função em um cartão, ou

talvez com uma linha, por exemplo: Tenho de entrar no meu portal de monitoramento de energia web Quero ver o meu consumo de energia diária

Confira a minha taxa de faturamento atual de eletricidade No desenvolvimento ágil, é o trabalho do desenvolvedor falar a língua do interessado, e não o trabalho do interessado falar a linguagem da tecnologia.

Uma comunicação eficaz é a chave, e precisamos estabelecer uma linguagem lingua gem comum. A user story fornece a linguagem comum para construir um entendimento entendimento entre o interessado e a equipe técnica.

Qual o Tamanho da User Story? O que couber num cartão. Na frente a história e no verso o teste de aceitação. aceitação.

Existem sistemas com os campos próprios para esses conteúdos.

Com user story não temos de entender a linguagem li nguagem uns dos outros com o grau

de proficiência necessário para elaborar um soneto, só precisamos entender uns aos outros o suficiente para sabermos trabalhar juntos! Eu, como ........ (perfil de usuário), desejo fazer........ (necessidade), de forma que eu possa.........(intenção).

Em uma frase temos os três pilares do design de interação e do design centrado no usuário: usuário usuário,, necessidade real, real, motivação  motivação.. 

Figura 11.4: User story.

 

O que é SCRUM?

213

 User Stories não são Requisitos. User

Elas não são detalhadas nas especificações de requisitos (algo que um sistema sistema deve fazer), mas são expressões de intenções, e não são negociáveis; definem o que os usuários precisam, querem de algo assim.

Elas são curtas e de leitura fácil e compreensível para os desenvolvedores e os

interessados. Representam pequenos incrementos de funcionalidade valorizados, que po-

dem ser desenvolvidas em um período de dias ou semanas. Elas são relativamente relativamente fáceis para calcular o esforço para serem implementadas, e esse esforço pode ser rapidamente determinado. Elas não são registradas em grandes documentos, mas organizadas em listas

que podem ser mais facilmente reorganizadas e redistribuídas conforme novas informações são descobertas.

Elas não são detalhadas no início do projeto, mas são elaboradas baseadas em “just-in-time”, evitando assim especificidades demasiadamente cedo no levantamento, atrasos no desenvolvimento, inventário de necessidades e um superdimensionamento da solução. Precisam de pouca ou nenhuma manutenção e podem ser facilmente descartadas após implementação. Histórias de usuários, e o código que q ue é criado logo depois disso, servem como insumos para documentação do que é desenvolvido de forma bem incremental. incremental. Uma história de usuário é uma narrativa da vida real que descreve em deta-

lhes uma característica que o usuário quer para o sistema, sem entrar em grandes detalhes. Essa história deve incluir o usuário que quer o recurso, uma descrição da funcionalidade desejada e um argumento claro para o valor desse recurso descrito para o negócio.

A razão mais justificável para contar uma história de usuário é capturar a descrição de uma determinada funcionalidade e seu valor de negócios no início do projeto, portanto, desta forma, as funcionalidades podem ser corretamente priorizadas e sequenciadas no trabalho do projeto.

Um sinônimo comum para a “história de usuário” no contexto do SCRUM é o cartão de requisitos (requirements card). “Embora o termo “cartão de requisitos” de forma mais precisa remeta ao pro-

pósito de uma história de usuário, nem todos os requisitos podem ser descritos em uma história. “Cartão de requisitos” também reforça o fato de que o recurso (a estrela da

história do usuário) é de fato uma exigência para o projeto do sistema.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

214

SCRUM Funciona Após digerir inicialmente alguns materiais, palestras, livros sobre SCRUM, isso bom de demais ser verdade, mas para espanto, vê-se comoparecia a utilização partepara das técnicas do framework do do framework  dosatisfação SCRUM éeútil e produ produtiva tiva em qualquer situação de projeto de sistemas. Claro que os objetivos deste livro não incluem demonstrar detalhadamente a

aplicação do SCRUM, mas vale a pena ressaltar suas características no tocante ao assunto “Análise de Requisitos”. Assim podemos concluir que ele pode e deve ser utilizado como uma das técnicas de análise de requisitos.

Figura 11.5

Utilizamos esta figura para relembrar a todos que até o momento estamos navegando na superfície, discutindo e entendendo processo, ferramentas técnicas técni cas e papéis em diversos modelos para a construção de projetos de sistemas. Porém, o conhecimento, a cultura do negócio está submersa e esta é a que buscaremos elicitar, utilizando o que já estudamos. Vamos tentar mostrar um caso simulado de user stories:

Imagine você temfornecer de criarinformações um sistema sobre para IPhone queseus a ideia vaga e básica inicial que é que ele irá cinema epara usuários.

Sua ideia atual é inserir uma funcionalidade que mostre os filmes em cartaz, com horários e local de exibição.

 

O que é SCRUM?

215

A partir desta ideia, deve ser escrita uma user story que ficaria assim: Eu, como usuário do IPhone, desejo ver quais filmes estão em cartaz e seus respectivos horários, de forma que eu possa assistir a um filme ainda hoje.

Na última linha, temos a intenção - que é a dica da essência do seu sistema. Neste caso é “Ajudar os usuários a encontrar um filme para assistir”.

É simples, e descobrir a essência é importantíssimo para você construir um sistema que atenda às necessidades dos seus usuários, além de evitar desenvolvimento de funcionalidades inúteis e reduzir tempo de desenvolvimento.

Seguindo o raciocínio ao longo do projeto, várias ideias vão surgir, porém você terá uma guia a seguir, a pergunta-chave: Esta nova ideia foge ou está dentro da essência do meu sistema? sis tema? O quão ela é importante dentro da essência? Digamos que em uma reunião da equipe de SCRUM surge uma nova ideia:

inserir uma funcionalidade para que os usuários possam salvar um filme em uma lista de favoritos.

Veja como ficaria a user story: Eu, como usuário, desejo poder “armazenar” um filme, de forma que eu possa ver as informações depois em um próximo dia.

A pergunta que devemos fazer diante de uma nova funcionalidade é: “Esta funcionalidade vai ajudar os usuários a encontrar um filme para assistir?”

Pode ser que ajude, mas não existe certeza, é importante? Pode ser, é essencial? essencial? NÃO. São muitas dúvidas, então não é bom sinal. O que fazer neste caso? Guarde a ideia, continue o sistema com a sua essência (o Google e outros fazem isso com sabedoria) e observe o uso real, para então analisar se seus usuários usuá rios realmente necessitam dessa funcionalidade. User  U ser stories são descrições simples que representam uma funcionalidade. Não se deve trocar uma conversa por adição de detalhes na user story. O recomendável sempre é que essas user stories sejam escritas do ponto de vista de uma necessidade dos usuários, e com a participação dos interessados.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

216

 Sprint Planning Sprint No SCRUM, no fluxo normal, nós temos dois passos que iniciam a execução execução da sprint, chamados “Sprint Planning 1” e “Sprint Planning 2” (na imagem seguinte, os dois primeiros blocos cinzas).

Figura 11.6: Sprint Planning.

No Sprint Planning 1 acontece a escolha dos itens de backlog, nos quais vamos usar a sigla IBL para representá-los. Serão feitos na sprint. Nessa reunião, é muito importante a presença do Product Owner, pois ele é um dos principais responsáveis pelo roadmap, digamos, do projeto sendo desenvolvido por ele. Na grande maioria das vezes, tem principalmente o conhecimento conhecimento do negócio e a visão mais acertada de onde quer que o projeto chegue. Essa escolha das IBLs é feita pelo time todo, ou seja, todo o time tem de concordar que terão condições de implementar aquelas a quelas user stories escolhidas. Escolhidas as user stories que serão realizadas no sprint, chega o momento do Sprint Planning 2. 2. Em uma reunião de Sprint Planning 2, todo o time concentra seus esforços em quebrar aquelas IBLs (user stories) em unidades menores de trabalho, que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its.

 

217

O que é SCRUM?

Figura 11.7

Bom, é nesse momento que acontece a explosão de tarefas. A sprint começa sem ter nenhuma tarefa a ser feita e, no Sprint Planning 2, as tarefas são levantadas. A importância dessa fase do SCRUM é a seguinte: o que levantarmos como tarefa aqui vai guiar o desenvolvimento da sprint toda (e é claro que podemos lembrar ou criar mais atividades no decorrer do sprint, mas ter essa visão inicial ajuda muito e já pode antecipar alguns dos problemas que podem acontecer). O leitor, com certeza, tem agora a pergunta: mas como eu quebro as user stories em tarefas? Qual a granularidade? Para responder a estas perguntas, buscamos nas nossas pesquisas via web encontrar dicas ou instruções de como quebrar as tarefas. A seguir apresentamos o que consideramos as melhores:  



quebra de Granularidade grossa: uma das primeiras recomendações para a quebra tarefas é sempre criar tarefas as quais possam ser feitas em um dia de trabalho (ou menos); caso contrário, é melhor quebrar ainda mais a tarefa, com o objetivo de que ela caiba em um dia de trabalho. O objetivo objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder poder visualizar o trabalho diário no

burndown, que nesse caso vai se mover mover dia a dia, em vez de ficar parado uns dias e depois se mover.

 



Granularidade fina: o ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma task (lembrando que, para que isso aconteça, é preciso que seja realizada uma análise detalhada da user story a ser

desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes etc.). Cada detalhe, então,

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

218

vai virar uma task, e isso facilita a vida de quem for desenvolver a user story,

pois as tarefas já são quase que uma guia, e a finalização das tasks da user story simbolizaria que não falta mais NADA para aquela user story. Por exemplo, se você sempre acaba uma user story e vê que a equipe não fez uma va-

lidação em um formulário, formulário, então na próxima sprint você já inclui a validação como uma tarefa (post-it) à parte.  



que bra de Refinamento contínuo: o que se busca no caso é sempre adaptar a quebra

tarefas à realidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá de base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, é preciso juntar mais coisas em uma task só (que façam sentido estar juntos obviamente). Caso a granularidade tenha sido muito grossa, gros sa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais. individuais.

Documentação em SCRUM

Existe um mito de que não se documentam projetos que usam metodologias metodologias

de desenvolvimento ágil. Não é verdade. Aliás, não chega nem perto de ser verdade.

Figura 11.8

A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos de desenvolvimento tradicionais geralmente são bastante pres-

critivos e você tem de documentar tudo que estiver definido no processo (que geralmente é muita coisa).

 

O que é SCRUM?

219

Você não tem tempo de pensar no que está fazendo, simplesmente segue o que

foi definido e realiza os documentos exigidos no processo. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software “software funcionando  funcionando mais do que documentação”), mas isso não

significa que é proibido documentar qualquer coisa.

Muita gente confunde isso e diz que nunca se deve documentar em projetos projetos “ágeis”, o que é um grande erro. Em projetos ágeis você pode documentar sem problemas desde que a documentação seja necessária de fato. A ideia é que não devemos perder tempo com nada que não seja requerido de verdade para o projeto.

Documentação não Substitui Comunicação Em projetos tradicionais, muitos documentos são usados para comunicar ideias entre o stakeholder , analista e o programador, com QA e por aí vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros. Se você estiver se comunicando por documentos, você já dei-

xou de ser ágil há muito tempo. te mpo. Documentação não deve ser usada para substituir substituir a comunicação intensa e constante entre os membros me mbros do time de SCRUM.

Documentação não pode ser Perecível

Documentação tem de ser leve e não pode ser perecível. Ela deve ser durável. Se documentamos algo que precisa ser modificado todo dia, existem grandes chances de nos esquecermos de atualizar a documentação e ela passa a ficar desatualizada.

É melhor não ter documentação do que ter documentação errada. Além disso, se é preciso mudar a documentação toda hora, significa um aprofundamento maior nos detalhes, então a documentação vai “quebrar” a cada ca da linha de código que for escrita. Quando estiver documentando, pergunte-se: “Daqui a algum tempo essa documentação ainda será válida?” Faça documentação durável.

Não devemos nível de detalhe que-faça mudar a documentação o tempo todo (a não entrar ser quenum  precise disso e mesmo assim temos de penrealmente sar se não dá para fazer de outro jeito, por exemplo, automaticamente).

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

220

Documente o Necessário, e não mais do que Isso Assim, devemos implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso. Devemos documentar apenas o que for necessário. Não podemos perder tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem de ter um motivo, pois documentar sem uma necessidade real não faz sentido. O motivo não deve ser um simples, pois “o processo de desenvol-

vimento exige”. Documentar tem de ser Fácil Documentar tem de ser rápido; não pode dar trabalho demais. Podemos usar ferramentas como wikis, geradores de documentação e outras. Se for fácil documentar, as chances de fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa on-line/web), use ferramentas para publicar a documentação automaticamente.

Se a documentação for fácil de ser acessada (e tiver busca), ela fica mais útil. Além disso, recomendamos usar uma tecnologia fácil e conhecida, para que todos os membros do time possam documentar.

Documentação faz Parte do “Definition of Done” Se o seu projeto precisa de documentação por qualquer motivo, segundo Guilherme Chapiewski,(1) um programador apaixonado por desenvolver software software,, a

documentação deve fazer parte da “Definition of Done”.

É melhor documentar no momento em que as user stories estão sendo desenvolvidas, quando o conhecimento está fresco na cabeça, do que acumular uma porção de débito de informações e ter de pagar de uma vez só, quando você vai precisar conferir várias coisas que já estão prontas para documentar com precisão, o que vai dar mais trabalho e consumir muito mais tempo.

Documentação no Código pode ser um “Code Smell” “Code smell” é um sintoma no seu código que pode indicar um problema

maior. Em programação, code smell é qualquer sintoma no código-fonte que indica um problema mais profundo.

(1)

http://gc.blog.br/sobre-guilherme-chapiewski/ http://gc.blog.br/sobre-guilherme -chapiewski/ - blog sobre desenvolvimento de software e tecnologia: tecnologia: http://gc.blog.br/  http://gc.blog.br/ 

 

O que é SCRUM?

221

Muitas vezes códigos precisam ser documentados porque eles são desne-

cessariamente complexos. Sempre que possível, prefira refatorar o código para ele ficar mais fácil de entender em vez de escrever comentários (até porque na maioria das vezes o código

muda e o comentário fica lá desatualizado, e isso atrapalha mais do que ajuda).

Tenha uma boa suíte de testes (uma suíte bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software software,, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software  seja mais bem escrito e não mais bem documentado. software seja

Dicas de Cod Smells

Code smells comuns  

Código duplicado: código idêntico ou muito similar existe em mais de um local.

 

Método longo: um método, função ou procedure muito extenso. Classe extensa: classe que acabou ficando muito extensa (God Object).





 



 

Feature envy (sem tradução): classe que utiliza em excesso métodos de outra classe.

 

detalhes de Intimidade inapropriada: uma classe que possui dependência de detalhes implementação de outra classe.

 

Legado recusado: uma classe que sobrepõe (override) o método da classe ge-







nérica de forma que o contrato da classe genérica não é cumprido cumprido pela classe derivada.  

Classe preguiçosa: classe que faz muito pouco. Complexidade artificial: uso forçado de design patterns extremamente complicados, em que um design simples seria suficiente.

 

convenções Identificadores excessivamente longos: em particular, o uso de convenções

 

 



de nomes para evitar ambiguidades, o que deveria estar implícito implí cito na arquitetura do software software..

Finalizamos este capítulo com a seguinte colocação: O que é ser ágil?

“Realizar um trabalho com grande destreza e habilidade num tempo inferior ao comumente empregado e gerando no final algo com grande qualidade e de valor para quem recebe o produto.”

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

222

 Casos de Uso x User Stories Casos  

Casos de uso e stories são técnicas para desenvolver o sistema pelo pon to de vista do ator.

 

Casos de uso e stories não são documentos técnicos.

 

Casos de uso e stories são sucintos.

 

Casos de uso e stories são atômicos.

 

Casos de uso e stories agregam valor val or de negócio.

 

Casos de uso e stories são utilizados utiliza dos para gerenciar o projeto.



 

Casos de uso e stories dividem o sistema funcionalmente.



Casos de uso e stories podem ser estimados.



    

 



Casos de uso e stories direcionam os testes.

 

Problemas Comuns aos Projetos

12

“Os nossos maiores problemas não estão nos obstáculos do caminho, mas na escolha da direção errada.” (Augusto Cury)

Introdução

Este capítulo tem como objetivo entregar ao leitor um conjunto de quadros de pontos importantes a serem lembrados nas atividade de análise de requisitos. Absorvemos este material das pesquisas, de slides de aula, de André Luis Ogando Paraense, do DCA-FEEC-Unicamp, publicado em 8 de outubro de 2009. É uma síntese de principais pontos, servindo como um guia de orientação na análise e levantamento de requisitos. Começamos com os problemas comuns, da definição de requisitos, e logo a seguir apresentamos as principais armadilhas em que os analistas caem normalmente. Acreditamos que seja válido e sirva como uma fonte constante de consulta em seus projetos, assim como para identificar erros já cometidos, orientá-los para futuros projetos de maior qualidade e segurança.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

224

Tabela 12.1

Problemas comuns e exemplos

Escopo reduzido  Requisitos não funcionais descritos como Requisitos funcionalidades e vice-versa

Uma descrição menor que a da visão colocada como escopo do projeto. Exemplo: (funcional) acesso via Internet. Estrutura de descrição semelhante a casos de uso.

Requisitos não identificados unicamente

Requisitos sem ID.

Requisitos sem descrição! Design prematuro

Exemplo: “...SGBD será utilizado a plataforma Oracle”.

Termos vagos

Exemplo: “amigável”.

 Armadilhas dos Requisitos e Boas Práticas Iniciam-se as tabelas das principais armadilhas dos trabalhos de levantamento levantamento e especificação de requisitos. Tabela 12.2

Ambiguidade

Podem ser causadas pelo uso de certas palavras como: para, ou e a menos que. “O mesmo subsistema deve também ser capaz de gerar um sinal de cuidado/alerta visível ou audível para chamar a atenção do copiloto ou navegador.” Qual subsistema? O sinal deve ser visível, audível ou ambos? Deve ser cuidado e alerta, somente cuidado alerta? Deve para o copiloto e o navegador ou somente um deles? Se somente ou umsomente deles, quem e em queser condições?

Tabela 12.3

Requisitos múltiplos

Conjunções perigosas incluem: e, ou, mas. “O navegador deve ser capaz de ver a posição da aeronave em relação às balizas da rota ou pela estimativa da orientação inercial.” Não está claro se o “ou” indica que o navegador pode escolher o método que utilizará para a

navegação ou que os desenvolvedor desenvolvedores es possam decidir qual implementar.

 

225

Problemas Comuns aos Projetos

Tabela 12.4

Cláusulas evasivas

Palavras perigosas que implicam exceções incluem: se, quando, mas, exceto, a menos que, embora. “O alarme de incêndio deve sempre ser tocado quando a fumaça for detectada, a menos que o alarme esteja sendo testado ou o engenheiro tenha suprimido o alarme.” Requisito perigoso! Parece pedir algo definitivo, mas no último momento ele desiste e permite outras opções. Os problemas surgem quando os requisitos são testados e alguém tem de decidir o que (se houver) provaria que o requisito foi satisfeito.

Tabela 12.5

 Incoerências Incoerências

Palavras perigosas que implicam exceções incluem: se, quando, mas, exceto, a menos que, embora. “Dado de seja entrada dos dispositivos especifica especificados dosdesejam correta que ondeososinais sistema capazdesignados de diferenciar os designadores, o sinal saídarecebidos deve estarnadeordem acordo com o framework requerido da seção 3.1.5 para indicar o estado desejado de entrada.” Longa sentença incoerente.

Tabela 12.6

Design prematuro

Sinais de perigo incluem nomes de componentes, materiais, objetos de software  ou procedures e campos de bancos de dados. “A antena deve ser capaz de receber sinais FM usando um miolo.” Especificar design em vez das reais necessidades aumenta o custo dos sistemas por colocar restrições desnecessárias no desenvolvimento desenvolvimento e na manufatura. Frequentemente, Frequentemente, saber por quê é muito melhor do que saber o quê.

Tabela 12.7

Misturando diferentes tipos de requisitos

Sinais de perigo incluem nomes de componentes, materiais, objetos de software  ou procedures e campos de bancos de dados. O usuário deve ser capaz de ver o número do canal corrente que deve ser exibido com fonte Swiss

 “

tamanho 14 em um painel LCD em conformidade com o Padrão Regulamentar Federal 567-89 e montado com arruelas de borracha à prova de choque.” Uma forma rápida de conseguir confusão é misturar requisitos de usuários, sistemas e como o sistema deveria ser projetado, testado ou instalado.

 

226

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Tabela 12.8

 Especulação Especulação

Sinais de perigo incluem generalizações tais como: usualmente, geralmente, frequentemente, frequentemente, normalmente e tipicamente. “Os usuários normalmente necessitam de rápida indicação de intrusão no sistema.” Os requisitos são parte de um contrato entre o cliente e o desenvolvedor. Não há espaço para listas de desejos, termos de significado geral sobre coisas que alguém provavelmente quer. Tabela 12.9

Termos vagos e indefinidos

Termos vagos incluem: amigável, versátil, flexível, aproximadamente, possível. “A caixa de diálogo de impressão deve ser versátil e amigável.” Os requisitos que usam termos nãoindicada. são verificáveis porque não há teste definitivo para mostrar se o sistema temesses a propriedade Tabela 12.10

Expressão de meras possibilidades

“Opções possíveis” são indicadas com termos tais como: pode, deveria, desejável, poderia, talvez, provavelmente. “O subsistema de recepção provavelmente deverá ser forte o suficiente para receber um sinal de dentro de uma construção de placas de aço.” Sugestões que não são explicitamente declaradas declaradas como requisitos são invariavelmente ignoradas ignoradas pelos desenvolvedo desenvolvedores. res. Tabela 12.11

Pensamentos desejosos

Termos de pensamentos desejosos incluem: confiável, seguro, trata todas as falhas inesperadas, agrada a todos os usuários, roda em todas as plataformas, nunca falha, atualizável a todas as situações futuras. “O subsistema de recepção provavelmente deverá ser forte o suficiente para receber um sinal de dentro de uma construção de placas de aço.” Os pensamentos desejosos significam pedir o impossível. A engenharia é uma atividade do mundo real e nenhum sistema ou componente é perfeito.

“A parte mais difícil para construir um sistema de software é decidir o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil como o estabelecimento dos requisitos técnicos detalhados... detalhados... Nenhuma outra parte do trabalho mutila o sistema resultante se for feita errada. Nenhuma outra parte é tão difícil de corrigir depois.”  Frederick Brooks ,

Essence and Accidents of Software Software Engineering Engineering

 

227

Problemas Comuns aos Projetos

 Boas Práticas Boas Não estaria completo este guia se não apresentássemos também um guia de boas práticas para escrever bons requisitos. Tabela 12.12

Escrevendo bons requisitos

Sentença completa: + Sujeito: um ator, um stakeholder , o sistema em desenvolvimen desenvolvimento to ou uma entidade de design. Predicado: uma ação ou um resultado desejado que é feito para, por, com ou ao sujeito + as condições e os critérios de desempenho. “A secretária de entrada de pedidos deve ser capaz de completar dez pedidos de cliente em menos de duas horas.” Este requisito tem um sujeito (a secretária de entrada de pedidos, que é um ator), um estado final específico e mensurável menos de duas horas). (dez pedidos de cliente concluídos) e um critério de desempenho (em

 Check List Check Muito conveniente também é termos um check list l ist dos requisitos para validar validar o que realizamos. Tabela 12.13

Check list de bons requisitos

O requisito está correto?

Identificou a “principal causa” que gera o requisito?

O requisito está completo?

O requisito está declarado como uma sentença completa?

O requisito está claro?

O requisito está inequívoco e não confuso?

O requisito está consistente?

O requisito está conflitando com outros requisitos?

O requisito é avaliável?

É possível definir um critério do tipo passou/falhou?

O requisito pode ser rastreado?

O requisito está identificado de forma única?

O requisito é viável? O requisito está independente de design?

O requisito é atômico?

O requisito não pode ser desmembrado?

 

228

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Capturar Requisitos não Funcionais É importante também que seja realizada a identificação e captura dos requisitos não funcionais do projeto para a perfeita distinção deles. Tabela 12.14

Um modelo

Usabilidade: fatores humanos e questões de interface de usuário. Confiabilidade:  C onfiabilidade: disponibilidade, disponibilidade, exatidão, previsibilidade, frequência de falhas ou a capacidade de recuperação. Desempenho: taxa de transferência transferência da informação através do sistema, tempo de resposta e uso de recursos. Suportabilidade: compatibilidade compatibilidade e as habilidades para testar, adaptar, manter, configurar, instalar, escalonar e localizar. + Restrições físicas: hardware ou forma, tamanho e peso físico do sistema. de design: limitam a abordagem no desenvolvimento do sistema. de implementação: limites sobre a codificação ou a construção (linguagens, ferramentas, ferramentas, plataforma ou padrões necessários). de interface: interação com os sistemas externos, protocolos ou a natureza da informação que é passada. regras de negócio: regras de validação de dados, fórmulas e decisões de fluxo que governam como o negócio opera. “Não existe uma única maneira correta de especificar um sistema. No entanto, certamente existe uma única maneira que é melhor que todas as outras.” (Autor Desconhecido)

 

Um Processo com Requisitos

13 “Nunca é tarde para tentar o desconhecido. Nunca é tarde para ir mais além.” (Gabriele D Annunzio)

O livro não poderia encerrar sem apresentar um processo de desenvolvi desenvolvimento mento que na sua estrutura não contemplasse os principais pontos apresentados. Este capítulo descreve um processo de engenharia de requisitos proposto no trabalho apresentado por Caroline Carbonell Cintra, na Universidade Federal do Rio Grande do Sul, Instituto de Informática, no Programa de Pós-Graduação em Computação como requisito parcial para obtenção do grau de Mestre em Ciência de Computação, em 2005, que contempla amplamente os aspectos da im importância portância da Análise e Gestão de Requisitos apresentada neste livro. Primeiramente é descrita a metodologia utilizada para definir o processo, sua inserção no contexto de uma organização específica e a fundamentação teórica teórica do processo, baseada em RUP e CMMI. Após isso, são apresentados os componentes básicos do processo, seguidos de uma descrição detalhada dos fluxos de atividades do processo. Por fim, são apresentadas orientações sobre a inserção de práticas de méto métodos dos ágeis nas atividades do processo.

Metodologia de Concepção do Processo Proposto Contextualização do Processo

O processo de engenharia de requisitos proposto neste trabalho foi concebido concebido e implantado em uma organização de desenvolvimento de sistemas de software, em suma, uma fábrica de software. Esse processo se insere em um processo global de desenvolvimento elaborado pela organização com o objetivo de obter melhorias significativas em produtividade e qualidade de seus produtos de software, quando fornecidos aos seus clientes.

 

230

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

O processo global de desenvolvimento segue o ciclo de vida do RUP com as fases de Iniciação, Elaboração, Construção e Transição. Para cada fase é definido um conjunto de fluxos de atividades, que representam a descrição do processo. Essa documentação é construída em forma de páginas navegáveis, acessadas aces sadas por navegador web, disponíveis na Intranet da organização. A figura apresentada em seguida mostra a página que documenta os fluxos de atividade da fase de Iniciação, com a opção de navegação para o detalhamento detalhamento das atividades do fluxo Definir o Escopo do Sistema.

Figura 13.1: Fase de iniciação do processo de desenvolvimento global.

Objetivos e Características Fundamentais Esse processo de engenharia de requisitos proposto baseou-se nos enfoques

CMMI, RUP e métodos ágeis. Com o objetivo de alcançar qualidade e melhoria contínua, o processo busca bus ca conformidade com as áreas de processo do CMMI de Gerência de Requisitos (nível 2) e Desenvolviment Desenvolvimento o de Requisitos (nível 3).

 

Um Processo com Requisitos

231

Outro ganho obtido como consequência da conformidade com CMMI é o reconhecimento nacional e internacional da maturidade de uma organização. Os componentes do processo (atividades, papéis, produtos de trabalho) são  framework baseados processo RUP que, além de ser uma metodologia reconhecida e no destacada no de mercado e no mundo acadêmico, já é utilizado informalmente nas atividades das equipes de desenvolvimento de diversas organizações.

Práticas de métodos ágeis são recomendadas para utilização durante a execução do processo, com o intuito de aumentar produtividade e qualidade. Mais um quesito que orientou a elaboração desse processo foi a definição do seguinte princípio básico:  O processo deve primar pela praticidade e eficiência, evitando atividades atividades burocráticas e geração de artefatos que não ofereçam índices interessantes inte ressantes de retorno do investimento. Conhecimentos adquiridos durante atividades de consultoria a diversas empresas, cujos processos adotados obtiveram certificação no nível 2 de maturidade matu ridade do CMMI, também foram aproveitados na concepção do processo aqui apresentado.

Evolução do Processo O primeiro passo na concepção do processo foi a uniformização dos conceitos conceitos relacionados à engenharia de requisitos utilizados pelas abordagens fundamentais fundamentais usadas. Esse passo resultou na utilização das definições apresentadas neste livro. Os próximos passos, executados de forma iterativa, foram pesquisa, definição, definição, implantação, avaliação e ajuste. A primeira iteração envolveu a pesquisa e estudo abrangente das abordagens abordagens fundamentais do processo e a definição de sua versão inicial, compatível com a área de processo de Gerência de Requisitos, pertencente ao nível de maturidade maturidade 2 do CMMI. O processo de institucionalização na empresa foi iniciado e os projetos piloto pilo to foram definidos e iniciados.

Após isso, os resultados parciais da adoção do processo foram analisados. A próxima iteração de concepção do processo foi caracterizada por pesquisas pesqui sas mais direcionadas, com o estudo de assuntos específicos para a evolução do processo.

 

232

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Foram incluídos atividades e artefatos com o objetivo de adquirir conformidade com a área de processo de Desenvolvimento de Requisitos, do nível de maturidade 3 do CMMI. Também adicionadas ao processo utili zação de princípios, valoresforam e práticas dos métodos ágeis. orientações para a utilização Na segunda iteração, embora tenha sido adotada uma área de processo do nível 3 de maturidade do CMMI, isso aconteceu apenas no processo específico de considerando engenharia de requisitos, e não no processo global da organização, considerando que o livro é sobre análise e gestão de requisitos. Este fato resulta normalmente em problemas de institucionalização do processo nas organizações, mas faremos uma breve consideração mais adiante.

Elementos Básicos Os elementos básicos de formação do processo apresentado são os utilizados utili zados pelo RUP, para descrever seus aspectos estáticos, como papéis, artefatos, atividades e fluxos de atividades. Os três fluxos de atividades de engenharia de requisitos são:   Definir o Escopo do Sistema; Refinar Requisitos de Software;     Gerenciar Mudanças. Cada um desses fluxos é composto por um conjunto de atividades, que podem ser ordenadas ou não. Cada atividade é exercida por um membro da equipe que irá desempenhar um certo papel. A execução de uma atividade pode utilizar artefatos como entrada e pode gerar artefatos de saída. Algumas atividades aparecem em mais de um fluxo de atividades, e foram denominadas atividades recorrentes. As seções a seguir descrevem os papéis e artefatos relacionados a atividades atividades do processo de engenharia de requisitos e apresentação.

Papéis O conceito de papel na equipe de desenvolvimento é o mesmo utilizado no RUP, ou seja, a descrição do comportamento e responsabilidades de um indivíduo indivíduo ou grupo de indivíduos trabalhando juntos.

 

233

Um Processo com Requisitos

O comportamento é descrito por meio das atividades associadas àquele papel e as responsabilidades são definidas com relação aos artefatos criados, modificados ou controlados por ele. Os papéis te trabalho são:definidos para o processo de engenharia de requisitos proposto nes  Equipe: toda a equipe de desenvolvimento: • Analista de Sistemas:  o principal responsável pelas atividades de engenharia de requisitos: elicitação, análise, especificação, validação e gerência de requisitos. • Gerente de Projeto: responsável pelo bom andamento do projeto, monitoração de riscos, alocação de recursos e demais atividades de planejamento.   Cliente: representa um stakeholder  do  do sistema, pertencente à organização organização cliente e que possui autorização para atuar como fornecedor de requisitos ao pro jeto.  Comitê de Controle de Mudanças: é formado por representantes de todos os stakeholders. • Uma configuração típica seria: o gerente de projeto, o gerente ge rente do projeto na organização cliente, um analista e um líder técnico. • Em projetos pequenos, pode ser formado apenas pelo gerente de projeto.   Qualquer Papel: qualquer membro da equipe de desenvolvimento ou stakeholder   da organização cliente.

Figura 13.2: Papéis.

 Artefatos Os artefatos produzidos durante a execução das atividades do projeto são:

  Documentos de Entrada: quaisquer documentos relacionados ao projeto projeto que



foram produzidos antes da fase de Iniciação. Exemplos típicos de documentos de entrada são RFPs (Request for Proposals) enviados por um cliente, a Proposta Comercial feita pelo departamento de vendas e aceita pelo cliente e a Proposta Técnica, que sugere uma versão inicial das características e módulos do sistema.

 

234

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

 Atributos dos Requisitos: são dados recolhidos ao longo do processo de   Atributos



análise de requisitos, desde a especificação até a aprovação da especificação espe cificação final ou de posteriores mudanças.

• Há vários tipos de atributos de requisitos:status identificadores e informações informa ções cadastrais, especificações e detalhamento, e índices como importância para o negócio, relevância para arquitetura, estimativa de tamanho (ou complexidade). • Um atributo especial é a prioridade do requisito, definida com base nos índices de outros atributos, e cuja definição depende de negociações negociações com o cliente que envolvem atividades de gerência de projeto.   Matrizes de Rastreabilidade: documentam as relações de dependência entre requisitos. A rastreabilidade documentada é vertical (obrigatória) e horizontal (opcional). • vés É possível documentar de rastreabilidade rastreabilida explicitamen atrade tabelas, planilhasasoumatrizes ferramentas de gerênciade deexplicitamente, requisitos, oute,implirequisitos, citamente, através dos demais artefatos do projeto. • Um exemplo de documentação documentação implícita é a matriz que relaciona requisitos aos recursos de projeto como tempo e pessoas. • Os cronogramas do projeto possuem atividades atividades agrupadas agrupadas em blo blocos cos com os mesmos nomes dos requisitos, o que resulta em uma relação implícita com os requisitos armazenados no repositório.   Glossário: registro do vocabulário comum do projeto, na linguagem do cliente. É criado no início do projeto e evolui ao longo do desenvolvimento desenvolvimento do sistema, servindo como referência para todos os envolvidos. en volvidos   Documento de Visão: nesse documento é definida a visão que os envolvidos têm do produto a ser entregue, em termos das principais necessidades ne cessidades e características. • Também registra a motivação para o desenvolvimento do sistema, através da breve descrição do principal problema de negócio a ser resolvido pelo sistema, além de descrever os limites do produto e as restrições impostas à solução. • Por conter uma descrição descrição em alto nível dos requisitos centrais pre pretendidos, incluindo restrições de design, serve como base contratual para requisitos

técnicos mais detalhados.   Especificação de Requisitos de Software (ERS): captura todos os requisitos requisitos de especificações funciosoftware do sistema e consiste em um pacote contendo especificações



nais e não funcionais aplicáveis. • As especificações funcionais possuem dois níveis de detalhamento: uma visão geral da funcionalidade é descrita nesse documento e o detalhamento

 

Um Processo com Requisitos

235

minucioso de cada requisito é anotado em um documento docu mento chamado Especificação Funcional de Requisito.    Especificação Funcional de Requisitos: os requisitos mais genéricos, alguns Especificação requisitos não funcionais e os requisitos podem ser bem representados nas especificações funcionais tambémque sãonão registrados no ERS, na seção de Especificações Suplementares. • Esse documento descreve descreve minuciosamente a interação interação que ocorre entre os atores (usuários ou sistemas externos) e o sistema durante a execução deste(s) requisito(s). • O principal objetivo é especificar o funcionamento de uma porção do sistema de forma clara o suficiente para que: o cliente possa validar vali dar o que será desenvolvido e a equipe de desenvolvimento compreenda compreenda o que deve entregar. 

Domínio:   Modelo  modelo de tação dasdeentidades essenciais do objetos sistema.inicial do sistema ou outra represen

 Protótipo de Interface: descrição de uma ou mais interfaces com o usuário. Protótipo

• Pode ser criada criada em vários formatos, tais como protótipos funcionais do sistema, protótipos estáticos, exemplos de tela, desenhos à mão livre capturados em meio eletrônico etc.   Solicitação de Mudança: utilizada sempre que uma mudança no projeto projeto é requisitada. • Esse artefato pode ser criado criado por qualquer membro da equipe de desenvolvimento ou da equipe do cliente, e deve ser aprovado pelo Comitê de Controle de Mudanças. • A Solicitação de Mudança é utilizada utilizada para documentar a neces necessidade sidade de mudança (defeito, melhoria ou novos requisitos), informações informações sobre impacto e consequências de sua adoção e status da mudança, além das justificativas para as decisões tomadas sobre a implementação da mudança.   Repositório do Projeto: contém todos os artefatos utilizados no processo proces so de desenvolvimento do software. • Pode ser um conjunto de arquivos, um banco banco de dados dados ou qualquer outra base controlada, por exemplo, por uma ferramenta de gerência gerên cia de requisitos.



comunicações oficiais enviadas pelo cliente, atestando aceitação aceitação de algum artefato produzido. • Geralmente são e-mails com a aprovação de Especificações Funcionais Funcio nais de Requisitos.

  Aprovações:

 

236

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Figura 13.3: Artefatos do processo proposto.

 Atividades Recorrentes Algumas atividades são executadas repetidamente ao longo dos fluxos de trabalho do processo de engenharia de requisitos proposto. As atividades dizem respeito a necessidades de controle de requisitos e de compartilhamento e reiteração do conhecimento para todos os membros da equipe equipe de desenvolvimento. São elas:   gerência de Gerenciar Requisitos: está intimamente ligada aos conceitos de gerência requisitos, de gerência de escopo e de controle de mudanças, apresentados previamente neste trabalho.   Assegurar uma Visão Comum: relaciona-se à necessidade de validação dos requisitos com os clientes e à difusão e consolidação do conhecimento conhecimento sobre o sistema a todos os membros da equipe de desenvolvimento. desenvolvimento. Essas atividades são descritas em detalhes nas seções seguintes.

Gerenciar Requisitos Objetivos, Papéis e Artefatos

Essa atividade trata do controle, rastreabilidade, histórico e atributos de todos os requisitos dorequisitos sistema, de emsoftware todos os níveis deeabstração, ou seja, necessidades, neces sidades, características,  funcionais não funcionais. Seu principal objetivo é fornecer subsídios para a gerência de escopo e o controle de mudanças no projeto.

 

237

Um Processo com Requisitos

Todos os fluxos de trabalho relacionados a requisitos influenciam i nfluenciam os atribu atributos tos de requisitos. Assim, essa atividade está presente em todos os fluxos de trabalho do processo processo de engenharia de requisitos proposto. Os artefatos de entrada para essa atividade são todos aqueles relacionados a requisitos. Cada vez que um novo artefato desse tipo é criado ou modificado, essa atividade é executada, atualizando os atributos dos requisitos e as matrizes de rastreabilidade quando necessário. Todos os membros da equipe são responsáveis pela gerência de requisitos, mas o analista de sistemas é responsável por revisar os atributos e matrizes de rastreabilidade de requisitos frequentemente (ao menos uma vez por iteração), para certificar-se de que o conjunto de requisitos do sistema está propriamente controlado. A atividade Gerenciar Requisitos é executada em três passos: Manter atributos dos requisitos.     Manter rastreabilidade.    Priorizar requisitos. Priorizar

Figura 13.4: Gerenciar requisitos.

Manter Atributos dos Requisitos Sempre que alguma atividade cria ou modifica um artefato relacionado a requisitos do sistema, seus atributos são atualizados.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

238

Os atributos de requisitos utilizados nesse processo estão descritos na tabela tabela seguinte. Os atributos obrigatórios são fundamentais para a gerência de requisitos e precisam ser sempre registrados; os atributos opcionais são sugeridos para facilitar facili tar outras atividades do processo e a decisão de adotá-los ou não faz parte das atividades de planejamento do projeto. Tabela 13.1: Atributos de requisitos do processo proposto. Atributo

Nome

Descrição

Nome do Requisito, que é atribuído pelo analista de sistemas no momento de sua identificação. Pode ser refinado ao longo do período de análise.

Utilização

Obrigatória

Nível de abstração do requisito: • Necessidade Tipo

• Característica Requisito Funcional ou • Requisito Não Funcional

Obrigatória

Identificador

Um identificador único, que permite manter referências ao requisito, já que o nome pode mudar. A sugestão de identificador dada por esse processo é: • Necessidades: NECn • Características: CARCn • Requisitos: RFn, RNFn Em que “n” é um número sequencial, iniciado em “1”. Note que a sequência de cada tipo de requisito pode ter intervalos de falha, quando requisitos descobertos inicialmente foram removidos do escopo do projeto.

Obrigatória

Tamanho

Uma medida de tamanho de requisitos. Nesse processo, recomenda-se utilizar Pontos por Caso de Uso (Use Case Points).

Obrigatória

Esse atributo destina-se a auxiliar na priorização dos requisitos. É Relevância para definido pelo cliente, que deve informar ao analista a importância o negócio de um requisito para a solução de suas necessidades. Esse atributo destina-se a auxiliar na priorização dos requisitos. É definido pelo arquiteto do sistema, que deve analisar o grau de Relevância para influência que o projeto (design) de cada requisitos tem sobre a

Opcional

Opcional

a arquitetura

arquitetura geral do sistema e sobre as decisões técnicas a serem tomadas ao longo do projeto.

 

239

Um Processo com Requisitos

Atributo

Prioridade

Status

Descrição

Utilização

Esse atributo define a ordem de desenvolvimento dos requisitos do projeto. A prioridade é utilizada para auxiliar no planejamento, na definição de cronogramas, na composição de releases do sistema e Obrigatória atividades de teste, entre outras.

Status atual do requisito, variando entre os seguintes: • Identificado (estado inicial); • Em desenvolvimen desenvolvimento; to; • Em aprovação; • Aprovado; • Em alteração.

Obrigatória

Data de criaç criação ão Data de iden identific tificação ação do requi requisito sito..

Opcional

Responsável pela criação Data da última Atualização

Membro da equipe responsável pela identificação do caso de uso.

Opcional

Data da última atualização da especificação do requisito.

Opcional

Responsável pela última atualização

Membro da equipe responsável pela última atualização da especificação do requisito.

Opcional

Data de aprovação

Data em que o cliente aprovou formalmente a especificação detalhada do requisito.

Obrigatória

Responsável Nome do membro da equipe do cliente que aprovou formalmente a Obrigatória pela aprovação especificação detalhada do requisito. Histórico de modificações

Diferentes versões da especificação detalhada do requisito.

Opcional

Grande parte desta tarefa é, em geral, automática, em consequência da utilização de ferramentas de gerência de requisitos.

Manter Rastreabilidade Esse passo da gerência de requisitos trata da criação e manutenção das matrizes de rastreabilidade dos requisitos. Conforme comentou-se anteriormente neste trabalho, a documentação das

matrizes pode ser explícita ou implícita. A tabela seguinte descreve as matrizes mantidas no processo proposto, que resultam na documentação das dependências ilustradas na figura a seguir.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

240

Tabela 13.2 Matriz

Utilização

Necessidades x Características

Obrigatória

Características x Características Características x Requisitos Funcionais

Opcional Obrigatória

Características x Requisitos Não Funcionais

Obrigatória

Requisitos Fu Funcionais x Re Requisitos Não Funcionais

Obrigatória

 Requisitos Funcionais x Requisitos Funcionais

Opcional

Requisitos Funcionais x Especificações Funcionais

Obrigatória

Matrizes de Rastreabilidade do Processo Proposto

Figura 13.5: Rastreabilidade de requisitos do processo proposto.

Assim como a manutenção de atributos, a manutenção das matrizes de rastreabilidade ocorre ao longo de todo o processo de desenvolvimento.

Após a conclusão de cada artefato do sistema que descreva os requisitos da figura anterior, esse artefato deve ser submetido ao controle de rastreabilidade, o que significa atualizar as matrizes relacionadas a ele.

 

Um Processo com Requisitos

241

 Priorizar Requisitos Priorizar Esse terceiro passo da atividade Gerenciar Requisitos completa o primeiro passo, de manutenção de requisitos, preenchendo o valor do atributo de prioridade. priori dade. As prioridades dos requisitos do sistema orientam orie ntam o planejamento e a gerência ge rência de escopo. Como o processo proposto segue o ciclo de vida iterativo e incremental, cada iteração resulta em novos conjuntos de requisitos analisados, projetados e codificados. A prioridade auxilia na determinação dos casos de uso que compõem esses conjuntos. Dependendo do projeto, a priorização pode ter uma granularidade menor. Por exemplo, se os requisitos de um projeto são bastante complexos ou interdependentes, e se estão documentados meiode deforma casos mais de uso, pode serdoregistrada a priorização de cenários de casospor de uso, detalhada que apenas a priorização dos casos de uso. Os fatores que devem ser observados para determinar a prioridade dos requisitos são:   Relevância do requisito para o negócio, definida pelo cliente e o analista de sistemas; Relevância do requisito para a arquitetura, definida pelo arquiteto de software;     Riscos de projeto a serem mitigados, identificados durante atividades de planejamento e gerência do projeto; Dependências entre requisitos; Outros objetivos táticos ou restrições, como, por exemplo, questões técnicas técnicas   ainda não tratadas ou versões intermediárias do sistema a serem liberadas para validação pelo usuário. Como o processo proposto segue as orientações de RUP quanto à divisão nas fases de Iniciação, Elaboração, Construção e Transição, a relevância para a arquitetura tende a receber maior atenção, uma vez que a arquitetura deve estar claramente definida ao final da Elaboração.  



 Assegurar uma Visão Comum Objetivos, Papéis e Artefatos O principal objetivo dessa atividade é garantir que todos os envolvidos no projeto possuem uma visão comum do sistema em desenvolvimento.

 

242

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A equipe de trabalho precisa de uma visão única para que os componentes do sistema possam ser integrados propriamente e de forma a fornecerem as funcionalidades desejadas. A visão também deve ser a mesma entre a equipe de trabalho e o cliente, para que o sistema entregue possa ser utilizado da forma esperada. A visão comum sobre o sistema deve ser construída ao longo de todo o pro jeto, o que faz com que essa atividade apareça em todos os fluxos de trabalho do processo de engenharia de requisitos proposto. Os artefatos de entrada para essa atividade são todos aqueles relacionados a requisitos. Essa atividade é executada em paralelo ao desenvolvimento dos artefatos do projeto relacionados a requisitos. Por isso, todos os do membros envolvidos, assim como os fornecedores de requisitos sistema,daouequipe seja, osestão clientes. Embora todos esses participantes estejam envolvidos, é tarefa do gerente de projeto certificar-se do bom andamento dessa atividade.  



 



 



 



Os passos utilizados para assegurar a visão comum do sistema são: Realizar análise de requisitos em grupos. Revisar artefatos. Obter aprovações. Manter Glossário.

Figura 13.6: Manter glossário.

 

Um Processo com Requisitos

243

Realizar Análise de Requisitos em Grupos A análise de requisitos em grupos de trabalho é mais uma prática desse processo de engenharia de requisitos do que propriamente um passo da atividade atividade Assegurar uma Visão Comum. A prática da comunicação no contexto da engenharia de software é considerada considerada de grande importância em diversos estudos. Habilidades e atividades são citadas ao longo das áreas de processo de Desenvolvimento e Gerência de Requisitos do CMMI (SEI, 2002) e o primeiro valor básico que norteia as abordagens de XP e Modelagem Ágil é a comunicação (BECK, 2000), (AMBLER, 2002). Uma avaliação empírica feita recentemente em um centro de desenvolvimento desenvolvimento de software global (DAMIAN et al., 2004) concluiu que a prática de sessões de análise de requisitos em grupo contribui para uma melhor distribuição do conhecimento e uma melhora na comunicação entre desenvolvedores em 74% e 76% respectivamente. Realizar análise de requisitos em grupos significa organizar grupos de trabalho para atividades de engenharia de requisitos conforme a necessidade do pro jeto, com o principal objetivo de melhorar a comunicação entre os membros da equipe e com o cliente. Os grupos de trabalho são dinâmicos e têm como escopo diferentes níveis de requisitos do sistema. Um exemplo de grupo de trabalho poderia ser composto por um analista, um projetista e um desenvolvedor para tratar da especificação de um conjunto de requisitos correlatos que representassem um módulo do sistema. Outro grupo poderia ser composto por um analista de sistemas, o gerente do projeto e o arquiteto de software, para trabalhar na priorização dos requisitos de uma iteração. Esses grupos interagem em reuniões de frequência predefinida. É comum, nas fases de Iniciação e Elaboração, que as reuniões sejam diárias, com duração máxima de cerca de 30 minutos. Caso a agenda de uma das reuniões seja muito reduzida ou caso a equipe esteja envolvida em outras atividades naquele dia, a reunião pode ser cancelada ou

pode ser apenas uma rápida conversa informal, tratando dos principais assuntos pendentes. Um costume comum nesse tipo de reunião é manter o foco em itens que precisam e podem ser resolvidos pelo grupo, deixando questões individuais e que precisam envolver outras pessoas registradas para tratamento fora da reunião.

 

244

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A prática da análise de requisitos em grupos teve resultados excelentes nos projetos piloto observados durante este estudo.

Revisar Artefatos

O processo de engenharia de requisitos proposto adota os conceitos de revisão de artefatos de requisitos apresentados por Dean Leffingwell e Don Widrig, no seu livro Managing Software Requirements: A Unified Approach. De acordo com esses conceitos, existem dois tipos de revisão, sendo informal infor mal e formal. Essa atividade trata das revisões informais, feitas com os seguintes objetivos:   Garantir a qualidade dos requisitos, identificando problemas de com compreensão preensão do negócio e das necessidades do cliente pela equipe de de desenvolvimento. senvolvimento. Difundir o conhecimento sobre o sistema, fazendo com que todos os envolvi  dos compreendam o sistema da mesma forma.   Diminuir a dependência do projeto com relação a membros específicos da equipe e diminuir a necessidade de detalhamento da documentação por meio da promoção da comunicação entre a equipe. As reuniões informais são feitas de acordo com a necessidade do projeto. Assim como as sessões de análise de requisitos em grupo, são planejadas sob demanda. Podem envolver apenas membros da equipe, mas, em geral, pelo menos uma das revisões informais envolve também o cliente. A ideiao éfeedback discutir do a especificação de requisitos antes que esteja finalizada, antecipando cliente. Os artefatos sugeridos para revisão são os seguintes:    Documento de Visão; Documento   Especificação de Requisitos de Software (ERS); Especificação Funcional de Requisitos.   As revisões formais são tratadas no próximo passo da atividade de Assegurar Assegurar uma Visão Comum.

Obter Aprovações

É o resultado das revisões formais, ou seja, reuniões que envolvem o cliente que têm o objetivo principal de registrar a aprovação formal dos artefatos relacionados a requisitos.

 

Um Processo com Requisitos

245

O procedimento ideal é realizar uma revisão formal apenas após, pelo menos, uma revisão informal. Assim, qualquer ponto obscuro ou gerador de conflito já terá sido resolvido resolvido previamente e a aprovação será apenas uma formalidade. formalidade. Contudo, para artefatos simples ou repetitivos, a aprovação pode ser pedida pedida mesmo sem a realização de uma revisão informal. As aprovações representam uma visão comum entre a equipe de desenvolvimento e o cliente, o registro do comprometimento da equipe com os requisitos traçados e o registro do comprometimento do cliente com os requisitos req uisitos traçados. As revisões necessariamente não precisam ser feitas por meio de reunião. Geralmente, revisões informais são feitas com reuniões presenciais (ou via teleconferência) e revisões formais são feitas pelo cliente que, ao terminar, envia um e-mail oficializando a aprovação. Os documentos listados a seguir precisam, obrigatoriamente, de aprovações aprova ções do cliente:    Documento de Visão; Documento    Especificação de Requisitos de Software (ERS); Especificação   Especificação Funcional de Requisitos. Essas aprovações delimitam o escopo do sistema, e permitem que o gerente de projeto realize a gerência de escopo e demais negociações necessárias no projeto, com relação aos requisitos que devem fazer parte do sistema. Atividades que terminam com a conclusão de um artefato só devem ser consideradas terminadas após a revisão e aprovação dele.

Manter Glossário O glossário do sistema deve ser mantido desde as primeiras atividades da engenharia de requisitos. Seu objetivo é definir uma linguagem comum a todo o sistema, utilizando os termos de negócio familiares ao cliente, e difundindo esses termos para a equipe equi pe de desenvolvimento. Sempre que um membro da equipe identificar um termo pertencente ao domí-

nio do problema que o sistema se propõe a resolver, recomenda-se que essa pessoa registre o termo e uma breve descrição no glossário. gl ossário.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

246

Definir o Escopo do Sistema Os objetivos do fluxo de trabalho de definição do escopo do sistema podem ser sumarizados da seguinte forma:   Compreender o problema que deve ser resolvido pelo sistema, considerando considerando o domínio do negócio do cliente. Identificar e documentar as necessidades do cliente e as características que o sistema deverá apresentar apresentar para atendê-las (requisitos do cliente).  Identificar os critérios de aceitação dessas características.   Identificar as restrições impostas ao sistema por razões políticas, econômicas, econômicas, técnicas ou de qualquer outra natureza.   Identificar e documentar os requisitos de software do sistema para implementar as características (requisitos do produto). O fluxo de trabalho Definir o Escopo do Sistema faz parte da fase de Ini Iniciação ciação do projeto, cujo objetivo é justamente o de caracterizar o escopo do sistema, siste ma, identificando seus requisitos. Para atingir os objetivos descritos anteriormente, são executadas as seguintes seguin tes atividades: Compreender Requisitos do Cliente;     Compreender Requisitos do Produto;   Gerenciar Requisitos;   Assegurar uma Visão Comum. Cada uma dessas atividades é comentada a seguir.

 

247

Um Processo com Requisitos

Figura 13.7: Definir escopo do sistema.

Compreender os Requisitos do Cliente Objetivos, Papéis e Artefatos A definição do sistema será baseada no problema a ser resolvido e nos requisitos do cliente, ou seja, nas necessidades, expectativas e restrições dos stakeholders. Os objetivos da atividade de Compreender os Requisitos do Cliente são:   Compreender o problema que deve ser resolvido pelo sistema. Levantar as necessidades dos envolvidos e as restrições impostas por estes.     Identificar e documentar as características que o sistema deve apresentar apresentar para satisfazer estas necessidades.

 



Analisar e harmonizar necessidades, características e restrições.

compreender problema, é sobre preciso, primeiramente, identificar as pessoasPara capazes de fornecero informações o negócio, os stakeholders . Em particular, essas pessoas devem poder informar o cenário percebido que oferece uma oportunidade de desenvolvimento de software.

 

248

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

A seguir, deve-se interagir com os stakeholders para o levantamento, análise, discussão, revisão e documentação das dificuldades identificadas neste cenário, as causas dessas dificuldades e as necessidades e restrições dos stakeholders com relação ao sistema a ser desenvolvido. Partindo das necessidades identificadas, é preciso definir as características que o sistema deve apresentar para satisfazê-las. Todos estes itens representam os requisitos do cliente. Os requisitos identificados podem ser incompletos, imprecisos, não consensuais e até mesmo conflitantes. Assim, é preciso analisá-los de forma a buscar acordos entre os stakeholders  até que se alcance uma visão de comum acordo sobre os requisitos definitivos do sistema. O responsável por essa atividade é o analista sistemas. Para compreender compreen der os requisitos do cliente, o analista de sistema deve de seguir estes passos:   Identificar os fornecedores de requisitos;   Entender o problema;   Definir os limites do sistema;   Identificar as necessidades e restrições dos stakeholders;   Definir as características do sistema. Todas estas informações são registradas no Documento de Visão.

Identificar os Fornecedores de Requisitos

Este é um passo crucial no entendimento do problema a ser resolvido e na definição do sistema que deve resolvê-lo. Um dos conceitos básicos utilizados neste estudo é o termo stakeholder , ou seja, toda pessoa interessada no sistema e que será afetada por seu desenvolvimento. desenvolvimento. Os fornecedores de requisitos são stakeholders  oficialmente designados pelo cliente como representantes de todas as equipes interessadas no projeto de desenvolvimento do sistema.

É importante trabalhar junto com o cliente na definição dos fornecedores de requisitos. Eles devem, em conjunto, possuir uma visão global do contexto onde o sistema se insere, desde o ponto de vista de negócios até o cotidiano dos usuários finais, passando pelas equipes de tecnologia, suporte, treinamento e todos os outros

 

249

Um Processo com Requisitos

setores da organização que estarão envolvidos na utilização do sistema ou que terão algum papel relacionado ao suporte do sistema. Os fornecedores de requisitos devem, ainda, possuir autoridade suficiente para tomar decisões em nome dos setores que representam. Além disso, é importante definir uma hierarquia entre os fornecedores de requisitos, com um gerente de projeto e um gerente sênior (possivelmente a mesma pessoa), para os quais possam ser escaladas decisões sobre as quais não for possível chegar a um consenso. Os fornecedores de requisitos devem ser registrados no Documento de Visão, conforme a tabela seguinte. Entre os fornecedores de requisitos devem ser identificados, obrigatoriamente, obrigatoriamente, Um Gerente de Projeto e um Gerente Sênior, para os quais possam ser escaladas decisões sobre as quais não foi possível chegar a um consenso entre os demais fornecedores de requisitos. Tabela 13.3: Documento de Visão - fornecedores de requisitos. Nome

Responsabilidades

Critério de designação

Como o fornecedor de Informe nome Faça uma breve descrição das requisitos foi designado: do fornecedor de atividades do fornecedor de • indicado pelo cliente; requisitos requisitos e indique seu cargo • nomeado por fulano etc.

Dados para contato

Informe os dados para contato: • e-mail; • telefones, ramal etc.

Entender o Problema Entender o problema significa obter o conhecimento de qual o real problema proble ma a ser resolvido (ou qual a oportunidade a ser implementada) por um sistema, e identificar qual seria a melhor solução para resolvê-lo. Um problema pode ser definido como a diferença entre as coisas que são percebidas e as coisas que são desejadas. Partindo da definição apresentada, pode-se perceber que implementar todos os desejos manifestados pelo cliente não é, necessariamente, a forma pela qual se resolve o problema. Primeiramente, deve-se ter certeza de que a percepção do cliente sobre a situa-

ção atual é correta. Semais a percepção pode sero que a situação atual esteja próxima do do cliente ideal doestiver que eleequivocada, imagina, tornando problema menor ou mesmo inexistente. Outra prática utilizada na resolução do problema é investigá-lo mais a fundo, com a participação do cliente, chegando mais perto de suas verdadeiras causas.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

250

Esta percepção pode mudar o que é desejado pelo cliente. As verdadeiras causas, ou causas raiz do problema, são as responsáveis por diversos sintomas que são percebidos pelos fornecedores de requisitos como problemas. Por exemplo, um problema pode ser “Os nossos clientes não estão satisfeitos satisfeitos com nossos serviços”, ao passo que suas causas podem ser “O nosso processo de pagamento é pouco ágil” ou “Há muitas falhas no nosso processo de vendas”. Ao finalizar este passo de entendimento do problema, o analista de sistema deve ter condições de criar uma frase que defina o problema atacado e identifi identifique que os envolvidos e o impacto sofrido por eles. Deve, ainda, identificar uma possível solução para o problema. A tabela seguinte ilustra a definição do problema e a sugestão de solução que integram o Documento de Visão do processo de engenharia de requisitos proposto. Tabela 13.4

O Problema

Descreva o problema. Após descrevê-lo, tente identificar se este é realmente o problema ou apenas uma consequência do problema real.

Afeta

Os envolvidos afetados pelo problema. Exemplos: clientes, funcionários, finanças, vendas etc.

Cujo Impacto é

Qual o impacto do problema. Exemplos: falta de satisfação, perda de vendas etc.

A Sol Soluç ução ão pr prop opos osta ta é

List Li stee alg algun unss do do pri princ ncip ipai aiss ben benef efíc ício ioss de de uma uma bo boaa sol soluç ução ão..

Definir os Limites do Sistema O sistema a ser desenvolvido se insere em e m um contexto, dentro da organização. organização. Esse contexto inclui, entre outros fatores, os funcionários que utilizarão o sistema, o pessoal de manutenção, repositórios de dados relacionados ao sistema sistema (incluindo repositórios que o alimentam ou que utilizam dados gerados por ele), sistemas legados, mecanismos de comunicação os quais o sistema utilizará. É importante definir claramente os limites do sistema e documentar que fatores do contexto organizacional fazem parte do sistema e quais estão fora de seu

escopo. No livro Managing Software Requirements: A Unified Approach, algumas questões são sugeridas para auxiliar na definição do escopo do sistema:   Quem usa o sistema?   Quem fará manutenção no sistema?

 

Um Processo com Requisitos

251

Quem recebe as saídas do sistema? (exemplo: Relatórios)   Como o sistema comunica-se com outros sistemas? Para documentar os limites do sistema, é criado um diagrama de perspectiva perspec tiva do produto que evidencia o contexto de inserção do sistema, seus usuários, sistemas legados e demais pontos de integração.  



O processo de engenharia de requisitos proposto não define a notação a ser utilizada no diagrama de perspectiva do produto, mas sugere a utilização de um diagrama UML evidenciando todos os atores do sistema. A seção de definição dos limites do sistema no modelo do Documento de Visão do processo proposto é ilustrada na figura a seguir.

Documento de Visão - Perspectiva do Produto Esta do seção do Documento Visão oferece uma visão de nível superior dos recursos produto, interfaces de com outros aplicativos e configurações do sistema. sis tema. Ela coloca o produto na perspectiva perspectiva de outros produtos relacionados e do ambiente do usuário. Se o produto for independente e totalmente autossuficiente exponha isso aqui. Se o produto for um componente de um sistema maior, essa subseção deve relacionar como esses sistemas interagem e identificar as interfaces interfaces relevantes entre os sistemas. Exemplo: Diagrama UML com os atores do sistema, Diagrama de Fluxo de Dados Contextual etc.

Figura 13.8: Diagrama UML com atores.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

252

Identificar as Necessidades e Restrições dos Stakeholders Ao executar esta atividade, o analista de sistema identifica as necessidades do stakeholders e as restrições impostas por eles à solução do sistema. Nesta etapa, o analista de sistema deve utilizar técnicas de elicitação de requisitos para obter a lista de necessidades, informadas pelos fornecedores de requisitos, que devem ser satisfeitas pelo sistema. Além disso, deve registrar as restrições informadas por eles. As listas de necessidades e restrições levam algum tempo para se estabilizar estabili zar devido, principalmente, aos seguintes fatores:   Conflitos entre requisitos: conforme mencionado anteriormente neste trabalho, o cliente pode manifestar requisitos contraditórios ao definir suas necessidades e restrições. Esses requisitos devem ser analisados, negociados com os fornecedores decorreta requisitos e resolvidos, resultando em uma lista de necessidades e restrições e coerente.   infor madas Lacunas nas descrições: algumas necessidades ou restrições são informadas de forma vaga, imprecisa ou incompleta. Essas informações devem ser devidamente revisadas e completadas.

Definir as Características do Sistema As características são serviços ou qualidades do sistema que q ue satisfazem as necessidades dos stakeholders. Embora forneçam uma ideia de funcionalidade, as características devem ter como foco o funcionamento conceitual do sistema (o que) e não sua implementação (como). As características são derivadas das necessidades e restrições e complementadas com requisitos decorrentes de restrições técnicas, de escolhas de arquitetura da solução ou outras considerações semelhantes. É uma prática comum realizar a identificação de todos os requisitos do cliente (necessidades, restrições e características) de forma conjunta, já que esses requisitos tendem a ser identificados em momentos únicos. As características são descritas no Documento de Visão, que serve de acordo acordo

com o cliente sobre o que é esperado do sistema. Assim, o nível de detalhe de cada característica deve ser geral o suficiente para que qualquer stakeholder  possa  possa entendê-la.

 

Um Processo com Requisitos

253

Estabelecer critérios objetivos de aceitação dos requisitos é parte da compreensão desses requisitos. Os critérios de aceitação são usados para confirmar que o sistema satisfaz as especificações solicitadas. Caso um requisito não atinja algum de seus critérios de aceitação, o cliente pode rejeitá-lo com argumentos claros e irrefutáveis. Por outro lado, caso um requisito satisfaça todos os seus critérios de aceitação, aceitação, a equipe de desenvolvimento tem a garantia de que o cliente não pode rejeitar o sistema, alegando que deseja mais funcionalidades implementadas. Os critérios de aceitação são definidos na etapa de Iniciação, durante a qual o escopo do sistema está sendo definido. São registrados no Documento de Visão, e podem ser associados a características ou ao sistema como um todo. A seguir é apresentada uma ilustração das seções de características e critérios critérios de aceitação do modelo de Documento de Visão do processo proposto.

Figura 13.9: Documento de Visão - características do produto.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

254

Compreender os Requisitos do Produto Objetivos, Papéis e Artefatos Requisitos do cliente são refinados e elaborados para desenvolver requisitos requisi tos de produto, ou seja, os requisitos de software do sistema, visíveis externamente. O responsável pela compreensão de requisitos do produto é o analista de sistema, que deve seguir os passos: Identificar Requisitos Funcionais e Não Funcionais;     Documentar Requisitos de Software. Diversos artefatos de projeto são gerados durante a execução do primeiro passo. Apenas a elaboração de um documento é obrigatória no processo de engenharia de requisitos proposto: o documento de Especificação de Requisitos de Software (ERS), criado no segundo passo dessa atividade de compreensão dos requisitos do produto.

Identificar Requisitos Funcionais e Não Funcionais O conceito de requisito de software do sistema foi apresentado no capítulo 2 de conceitos. Em resumo, esta sessão define que:   Os requisitos de software podem ser funcionais (F) ou não funcionais. Os requisitos funcionais descrevem a interação do sistema com seus atores   (entidades externas ao sistema). Os requisitos não funcionais descrevem qualidades a serem observadas no sistema. Podem ser de usabilidade (U), confiabilidade (R, do inglês realiability), performance (P), suporte (S), formando a sigla URPS, além de outras categorias como restrições técnicas, requisitos de interface ou de hardware. Esses requisitos são elaborados a partir das características do sistema, descritas no documento de Visão do Produto, e complementados através de técnicas de análise de requisitos.  



Assim como adotado pelo RUP, o processo de engenharia de software pro  proposto posto

neste livro recomenda a utilização da modelagem de casos de uso como técnica de análise de requisitos para identificar requisitos funcionais e não funcionais funcionais do sistema. A técnica é descrita no capítulo específico de casos de uso.

 

Um Processo com Requisitos

255

Documentar Requisitos de Software Conforme a descrição dos artefatos apresentada no início deste capítulo, a Especificação de Requisitos de Software é composta pelo detalhamento de todos os requisitos de software do sistema, funcionais e não funcionais, e é documentada documentada em forma de um pacote de artefatos.  Já o documento de Especificação de Requisitos de Software (ERS) possui uma descrição geral das especificações funcionais e uma sessão de especificações suplementares do sistema. A composição do documento ERS tem origem no modelo de ERS de RUP, mas exclui as descrições detalhadas do documento. A Figura 13.10 ilustra o índice do modelo de documento ERS do processo processo de engenharia de requisitos proposto.

Figura 13.10: Índice analítico.

 

256

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Índice do Modelo de Documento ERS Quando a equipe de desenvolvimento opta pela utilização de modelagem de casos de uso, a documentação dos requisitos de software ocorre, frequentemente, frequentemente, da seguinte forma:   A identificação de requisitos funcionais e não funcionais (passo anterior) anterior) ocorre de forma conjunta por meio da construção do modelo de casos de uso do sistema.   O modelo de casos de uso inicial do sistema é criado através de um ou mais workshops de casos de uso. Após isso, novas sessões de modelagem e algumas especificações de caso de uso são feitas com o objetivo de estabilizar o modelo de casos de uso do sistema, sis tema, que é organizado em pacotes para melhor compreensão e manutenção. Após a estabilização do modelo, a seção de Requisitos Funcionais do ERS é documentada, com breves descrições dos atores e casos de uso do sistema. Requisitos genéricos ou que não ficam propriamente representados através através do modelo de casos de uso são descritos na seção de Especificações Suplementares Suplementares do ERS. O modelo de casos de uso pode conter requisitos não funcionais, como, por exemplo, o tempo máximo de resposta durante a execução de uma transação. Nestes casos, os requisitos não funcionais não aparecem de forma explícita no documento ERS, sendo documentados apenas nas especificações funcionais de casos de uso, no fluxo de atividades Refinar Requisitos de Software.

Gerenciar Requisitos

Essa atividade, recorrente em vários fluxos de trabalho, já foi descrita anteriormente (ver item Atividades Recorrentes). No fluxo de trabalho Definir o Escopo do Sistema, cada passo da gerência de requisitos é executado de forma específica:   Manter atributos dos requisitos: são registrados todos os atributos associados a cada necessidade, característica e requisitos de software do sistema. Os atributos relacionados à priorização (relevância para o negócio, relevância relevância

para a arquitetura e prioridade) ainda não são definidos. 

rastreabilidade: e: são   Manter rastreabilidad

preenchidas as seguintes matrizes de rastreabilidade: • Necessidades x Características • Características x Requisitos Funcionais • Características x Requisitos Não Funcionais

 

257

Um Processo com Requisitos

  Priorizar requisitos:  o



atributo de prioridade dos requisitos funcionais é

preenchido. Os demais atributos relacionados à prioridade dos requisitos do sistema são opcionais.

 Assegurar uma Visão Comum Essa atividade, recorrente em vários fluxos de trabalho, já foi descrita anteriormente (ver seção Atividades Recorrentes). Nesse fluxo de trabalho, cada passo executado e xecutado mantém o foco na definição de escopo do sistema:  Realizar análise de requisitos em grupos: sessões de análise em grupo típicas desse fluxo de trabalho são: discussão do problema, identificação identificação de necessidades e características; modelagem de casos de uso.

  Revisar artefatos e Obter aprovações: revisões informais e formais são feitas



sobre o documento de Visão e o documento ERS.   Manter Glossário: este artefato é criado e as primeiras definições soa registradas. Diversos termos do Glossário são identificados durante as sessões de análise de requisitos em grupo.

Resumo do Fluxo de Trabalho  



Definir o escopo do sistema - resumo

Fluxo de Trabalho: Refinar Requisitos de Software Fase de Execução: Iniciação, Elaboração, Construção Responsáveis: Equipe, Analista de Sistemas, Gerente de Projeto, Cliente Artefatos:

• • • • • •

Documentos de entrada Documento de visão Glossário Especificação de requisitos de software (ERS) Atributos de requisitos Matrizes de rastreabilidade

Atividades:

• Compreender os requisitos do cliente

-

Identificar fornecedores de requisitos Entender o problema Definir os limites do sistema Identificar as necessidades e restrições dos stakeholders Definir as características do sistema

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

258

• Compreender os requisitos do produto - Identificar requisitos funcionais e não funcionais - Documentar requisitos de software • Gerenciar requisitos - Manter atributos dos requisitos - Manter rastreabilidade - Priorizar requisitos • Assegurar uma visão comum - Realizar análise de requisitos em grupo - Revisar artefatos - Obter aprovações - Obter aprovações - Manter glossário Critérios de conclusão:

• • • • •

Glossário iniciado Documento de visão aprovado Documento de especificação de requisitos de software (ERS) aprovado Atributos dos requisitos definidos Matrizes de rastreabilidade preenchidas: - Necessidades x características - Características x requisitos funcionais - Características x requisitos não funcionais

Refinar Requisitos de Software

Esse fluxo de trabalho se dedica ao refinamento dos requisitos identificados identificados durante a definição do escopo do sistema. Esse refinamento envolve a documentação de informações detalhadas sobre os requisitos de software, a identificação de possibilidades de reutilização de componentes de análise de requisitos, a caracterização da interface do sistema com seus usuários e os primeiros esforços no sentido de criar o modelo de dados do sistema. O refinamento de requisitos de software  consolida o conhecimento adqui-

rido sobre esses requisitos, evidencia pontos de falha e revela requisitos que possivelmente ainda não foram descobertos. Assim, esse fluxo de trabalho se repete ao longo do processo, nas fases de Iniciação (opcionalmente), Elaboração (intensamente) e Construção. As atividades atividades envolvidas no fluxo de trabalho Refinar Requisitos de Software são:

 

259

Um Processo com Requisitos

Especificar Requisitos de Software;    Modelar a Interface; Modelar  



 



Analisar Domínio; GerenciaroRequisitos;   Assegurar uma Visão Comum.  



Figura 13.11: Refinamento de requisitos.

Estas atividades são descritas a seguir.

Especificar Requisitos de Software Objetivos, Papéis e Artefatos O principal objetivo dessa atividade é detalhar requisitos de software identificados durante a definição do escopo do sistema. Esses requisitos podem ser funcionais ou não funcionais.

O processo de engenharia de requisitos proposto sugere dois locais para o detalhamento de requisitos: a Especificação Funcional de Requisitos e a seção de Especificações Suplementares do documento ERS. A utilização de outros artefatos é aceitável, desde que a documentação detalhada dos requisitos funcionais e não funcionais do sistema seja produzida.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

260

Essa atividade se divide nos seguintes passos:   Detalhar requisitos de software; 

   



Refinar modelos de análise; Atualizar artefatos sobre requisitos. O responsável por essa atividade é o analista de sistemas.

Para executar os passos citados, o analista utiliza as informações do sistema registradas nos Documentos de Entrada, no documento de Visão e no documento ERS e gera Especificações Funcionais de Requisitos e possíveis atualizações das Especificações Suplementares. Cada um dos passos listados anteriormente é descrito a seguir.

Detalhar Requisitos de Software Os requisitos de software  do sistema, identificados em etapas anteriores de análise de requisitos, devem ser especificados em detalhe e documentados. A técnica de especificação sugerida é a da modelagem de casos de uso, que descreve, para cada caso de uso do modelo, os seguintes aspectos:  linhas) Descrição breve: um pequeno parágrafo (geralmente uma ou duas linhas) descrevendo o caso de uso. A descrição também aparece no documento documento ERS, e é feita ainda na fase de Iniciação do projeto, quando a equipe está trabalhando na definição de escopo. Fluxo de eventos básico: descreve a interação entre os atores e o sistema, sistema, na   forma de um diálogo: “O ator faz... O sistema faz ...”. Os eventos são descritos da forma mais independente possível da solução solução técnica, para evitar a tomada de alguma decisão que deveria ser feita fei ta durante as atividades de projeto (design) do sistema. O fluxo básico descreve os eventos que ocorrem mais frequentemente, sem mencionar alternativas ou tratamento de erros.   Fluxos de eventos alternativos: descrevem os eventos alternativos que não aparecem no fluxo básico. Também assume a forma de um diálogo entre ator e sistema.

eventos de   Fluxos de eventos de exceção: descrevem o tratamento de erro e os eventos



exceção que não diálogo entre atoraparecem e sistema.no fluxo básico. Também assumem a forma de um

 

Um Processo com Requisitos

261

  Regras de negócio:



são requisitos de software cuja descrição não é adequada adequada para inserção nos fluxos de eventos: regras de negócio complexas, complexas, requisitos não funcionais, detalhes sobre algum objeto do domínio dos casos de uso.



P   Protótipo   rotótipo de interface com o usuário: esta seção não aparece no modelo modelo clás-

sico de especificação de caso de uso. É opcional e relaciona-se à atividade de Modelar a Interface do sistema. O objetivo dessa seção é facilitar o entendimento do fluxo de eventos do caso de uso, fornecendo informações mais tangíveis do que o diálogo entre e ntre ator e sistema. Diversas técnicas podem ser utilizadas para preencher essa seção, tais como screenshots de protótipos funcionais, representações de telas do sistema siste ma feitas com variadas ferramentas gráficas ou até mesmo desenhos feitos à mão e capturados (storyboarding). É importante que os envolvidos na elaboração e revisão desse documento, sobretudo o cliente, saibam que o todos protótipo de interface é apenas facilitador, e não representa necessariamente os detalhes da tela final doum sistema. A especificação de um caso de uso pode ter mais de um requisito funcional e pode, inclusive, descrever requisitos não funcionais, caso estes se apliquem apenas ao caso de uso especificado. Por exemplo, a especificação do caso de uso Comprar Produto pode conter o seguinte requisito não funcional: “O processamento da compra e o envio de uma resposta ao cliente devem ocorrer em no máximo cinco segundos”. Ao detalhar casos de uso, o analista de sistemas identifica alguns requisitos (funcionais ou não) que não podem ser propriamente descritos na especificação funcional de requisitos. Isso acontece principalmente com requisitos não funcionais genéricos, que devem ser associados a todos os casos de uso do sistema. Nestes casos, esses requisitos são descritos na seção de Especificações Suplementares do documento ERS.

Refinar Modelos de Análise Com o detalhamento gradativo dos requisitos de software, o conhecimento sobre o modelo conceitual do sistema evolui, o que permite identificar oportuni-

dades de reúso e refinamento nos modelos de análise construídos. Novos requisitos são descobertos, outros são unificados ou corrigidos. Estas são as ações tomadas neste passo da especificação de requisitos. Para projetos que utilizam a modelagem de casos de uso, significa estruturar estruturar o modelo criando relações entre casos de uso como include, extend ou generalização. generalização.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

262

 Atualizar Artefatos  Atualizar  Artefatos Sobre Requisitos Assim como os modelos de análise são refinados, alguns artefatos sobre requisitos também podem precisar de atualizações. Um exemplo frequente é o documento de Especificação de Requisitos de Software, sobretudo a seção de Especificações Suplementares. Todo artefato modificado após aprovação precisa ser revisado e oficialmente oficialmen te provado novamente.

 Modelar Interface Modelar Objetivos, Papéis e Artefatos A interface com o usuário é um dos recursos mais produtivos na obtenção de feedback do cliente sobre o sistema em desenvolvimento. Por este motivo são inseridos protótipos de interface nas especificações funcionais de requisitos. Além disso, sistemas de software  precisam de interfaces planejadas e uniformes, para melhorar sua usabilidade, a facilidade de manutenção e até mesmo a produtividade, através do reúso de código padronizado. Os parágrafos anteriores descrevem os objetivos da atividade Modelar Interface. O responsável por essa atividade é o analista de sistemas, que pode utilizar recursos ferramentas construção de projeto protótipos, padrões de interface de mercado como ou mesmo a ajuda de um expert em gráfico. O artefato gerado é um Protótipo de Interface, que pode ser um documento textual sobre o comportamento, layout e outras características comuns da interface; um protótipo gráfico; ou qualquer outro formato que oriente a equipe de desenvolvimento sobre a padronização de interface. Os protótipos de interface inseridos em especificações funcionais de requisitos requisitos são geralmente baseados nesse protótipo de interface genérico.

 Analisar o Domínio Objetivos, Papéis e Artefatos A análise de domínio tem o objetivo de desenvolver o modelo de objetos inicial do sistema (Modelo de Domínio), representando objetos tangíveis do domínio domínio do problema.

 

Um Processo com Requisitos

263

Essa atividade reforça o vocabulário comum promovido pelo Glossário do sistema. Além do Glossário, diversos outros artefatos sobre requisitos servem como fonte para a análise de domínio: Documentos de Entrada, Visão, ERS, Especificações Funcionais de Requisitos. O responsável é o analista de sistemas. O Modelo de Domínio contribui com as atividades projeto (design) e modelagem de dados do sistema.

Gerenciar Requisitos Essa atividade já foi descrita anteriormente (consultar seção Atividades Recorrentes). No fluxo de trabalho Refinar Requisitos de Software, a principal ação é o preenchimento da matriz de rastreabilidade de Requisitos Funcionais x Especificações Funcionais.

 Assegurar uma Visão Comum Esta também é uma atividade recorrente (ver Atividades Recorrentes). Nesse fluxo de trabalho, sessões de análise em grupo típicas são revisões informais de especificações funcionais, em que dúvidas sobre o fluxo de eventos, pré e pós-condições são comentadas entre os analistas de sistemas. Cada Especificação Funcional de Requisito deve ser formalmente aprovada, aprova da, assim como atualizações das Especificações Suplementares. O Glossário continua em evolução.

Resumo do Fluxo de Trabalho Fluxo de Trabalho: Refinar Requisitos de Software Fase de Execução: Iniciação, Elaboração, Construção Responsáveis: Equipe, Analista de Sistemas, Gerente de Projeto, Cliente  Artefatos: Artefatos:

Documentos de Entrada Documento de Visão Especificação de Requisitos de Software (ERS) Glossário Atributos de Requisitos Matrizes de Rastreabilidade Especificação Funcional de Requisito

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

264

Protótipo de Interface Modelo de Objetos do Domínio Atividades:

  Especificar Requisitos de Software   Detalhar requisitos de software   Refinar modelos de análise   Atualizar artefatos sobre requisitos   Modelar a interface   Analisar o domínio  Gerenciar requisitos   Manter atributos dos requisitos   Manter rastreabilidade   Priorizar requisitos   Assegurar uma visão comum   Realizar análise de requisitos em grupo   Revisar artefatos   Obter aprovações   Manter glossário Critérios de conclusão:

Documento de visão aprovado Especificações Funcionais de Requisitos (de cada iteração) aprovadas Matriz de rastreabilidade Requisitos Funcionais x Especificações Funcionais preenchida. Glossário atualizado

Gerenciar Mudanças “Práticas modernas de desenvolvimento de software  reconhecem que especificações de requisitos estarão erradas em algum ponto constantemente, e identificam formas de mitigar esse risco ao longo do projeto.” A seção de Engenharia de Requisitos: Definições e Problemas Clássicos, apresentada neste trabalho, descreve des creve os fatores geradores de mudanças em projetos de software: mudanças no negócio, descobertas sobre complexidade de requisitos, melhorias, evolução da percepção do funcionamento do sistema.

Conforme foi descrito nessa seção, as mudanças devem ser gerenciadas para que não se perca o controle sobre as variáveis de escopo, prazo e custo do projeto. Do ponto de vista da engenharia de requisitos, as contribuições dadas à gerência de mudanças são:

 

Um Processo com Requisitos

265

Documentar os requisitos, seus atributos e relações de dependências, priorização e histórico.   Utilizar esses atributos para avaliar o impacto de mudanças sobre requisitos re quisitos em termos de esforço.   Validar, com o cliente, os resultados de alterações nos artefatos sobre requisitos decorrentes de mudanças no projeto. O primeiro item da lista de contribuições anterior, relacionado à documentação de atributos de requisitos, é coberto pela atividade Gerenciar Requisitos, presente em todos os fluxos de trabalho do processo de engenharia de requisitos proposto.  



O último item dessa lista, a validação de requisitos, é satisfeito pela atividade ativida de Assegurar uma Visão Comum, responsável pela revisão e aprovação de artefatos artefatos sobre requisitos, executada em todos os fluxos de trabalho desse processo. Assim, a única contribuição da engenharia de requisitos ao controle de mudanças no projeto que ainda não foi abordada é a utilização dos atributos de requireq uisitos para avaliar o impacto das mudanças. Essa avaliação faz parte do processo de gerência de mudanças. Embora esse processo não seja vinculado diretamente aos requisitos, já que controla mudanças em qualquer parte do projeto, será apresentado neste livro voltado para evidenciar o tratamento de mudanças em requisitos. Os principais objetivos da gerência de mudança, sob o enfoque da engenharia engenharia de requisitos, são: 

Registrar as mudanças; Analisar o impacto nos requisitos;   Decidir sobre a adoção da mudança;   Implementar a mudança. A implementação da mudança exige o replanejamento do projeto, atividade ativida de que faz parte dos fluxos de trabalho da gerência de projeto e, portanto, não será abordada neste livro.    

Da mesma forma, a definição da data de execução da mudança e o acom-

panhamento do esforço real necessários também fazem parte de outros fluxos de trabalho e não serão descritos aqui. Os demais objetivos são alcançados pelas atividades do fluxo de trabalho Gerenciar Mudanças, detalhadas nas seções seguintes:   Submeter solicitação de mudança;

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

266

Complementar solicitação de mudança;   Analisar solicitação de mudança.  



Figura 13.12: Gerenciar mudanças.

O artefato utilizado em todas essas atividades é a Solicitação de Mudanças. Esse documento pode ser criado como um simples e-mail e deve evoluir ao longo do fluxo de trabalho até que esteja completo. A Solicitação de Mudança contém todas as informações pertinentes à mudança, tais como identificação, status, descrição da situação atual e do problema que a mudança procura resolver, descrição da mudança, custo estimado de implementação mudança. da mudança, observações e informações resultantes da análise da Ao utilizar o termo implementação da mudança, não é feita uma referência ao código do sistema, mas sim a todos os artefatos em que a mudança deve ocor rer, inclusive artefatos relacionados a requisitos (Visão, ERS, Especificações Funcionais Funcionais etc.).

Submeter Solicitação de Mudança

Objetivos, Papéis e Artefatos Diversas pessoas estão envolvidas na construção de um sistema de software, tanto na organização cliente (participante externo) quando na equipe de desenvolvimento (participante interno). Quando um desses participantes percebe a necessidade de uma mudança no sistema, pode submeter uma solicitação de mudança.

 

267

Um Processo com Requisitos

A necessidade de mudança pode resultar de diversos eventos como a percepção de um erro de análise, de problemas encontrados no sistema, de novas necessidades dos participantes externos ou de oportunidades de melhorias. O artefato utilizado nessa atividade é a Solicitação de Mudança. O formato inicial da solicitação pode ser até mesmo um e-mail descrevendo o problema encontrado e a sugestão de modificação. Os dados cadastrais da solicitação também devem ser preenchidos, conforme confor me a ilustração em seguida.

Figura 13.13: Solicitação de mudança - dados cadastrais.

Conforme descrito anteriormente, qualquer participante pode disparar uma Solicitação de Mudança, que deve ser endereçada ao Gerente de Projeto. Uma mesma Solicitação de Mudança pode ser composta por várias mudanças mudanças relacionadas, que devem ser analisadas em conjunto. Primeiramente, as mudanças devem ser contextualizadas, descrevendo a que parte do sistema (módulo, programa, camada etc.) elas se referem. Após isso, deve-se descrever a situação atual, com problemas, e as mudanças mudan ças necessárias para resolvê-los, conforme a figura seguinte.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

268

Figura 13.14: Solicitação de mudança - descrição da mudança.

Complementar Solicitação de Mudança Objetivos, Papéis e Artefatos Logo após submetida, uma Solicitação de Mudança contém apenas uma descrição inicial das mudanças desejadas, figura anterior. O próximo passo é complementar a solicitação de forma que se possa decidir decidir se as mudanças serão aceitas ou rejeitadas. Essa complementação pode ser feita por diferentes participantes do projeto. Se as mudanças são relacionadas a requisitos, o responsável é o analista de sistemas, que deve executar dois passos:   Complementar a descrição da mudança. Analisar o impacto da mudança.  

Complementar a Descrição da Mudança

Nesse passo o analista de sistemas deve revisar a mudança, verificar se a descrição está clara e completa, certificar-se de que o problema não pode ser resolvido no sistema atual e de que não existe nenhuma outra solicitação de mudança mudança que contemple as mudanças da solicitação analisada.

 

Um Processo com Requisitos

269

Quando necessário, o analista de sistemas deve completar a descrição, possivelmente com a ajuda do solicitante, e inserir os comentários apropriados.

 Analisar o Impacto da Mudança Compreender e estimar as consequências da adoção das mudanças para o pro jeto, identificando os artefatos afetados e as atividades necessárias para implantar implantar as mudanças. Um recurso que auxilia na identificação de artefatos afetados é observar a documentação sobre rastreabilidade. Para cada atividade deve ser feita uma estimativa de impacto no escopo, prazo e custo do projeto.

Figura 13.15: Solicitação de mudança - análise de impacto.

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

270

No caso de mudanças em requisitos, o impacto no escopo deve ser estimado esti mado pelo analista de sistemas.  Já as estimativas de prazo e custo devem ser feitas pelo gerente de projeto com base no impacto em esforço. Para algumas solicitações de mudança, esse passo pode ser executado mais de uma vez, aumentando as informações sobre a análise de impacto a cada execução. Isso acontece com frequência quando as mudanças são muito grandes ou estruturais. Nestes casos, pode ser interessante fazer uma estimativa inicial menos precisa precisa e executar a próxima atividade do fluxo - Analisar Solicitação de Mudança. Assim, o comitê de controle de mudanças pode descartar a mudança mesmo antes de uma análise de impacto mais detalhada, que consumiria recursos recursos do pro jeto em uma solicitação cujo futuro é a rejeição. A data de cada análise de impacto deve ser registrada no histórico do documento. Essas datas são importantes porque o impacto vai aumentando ao longo do projeto, quando mais artefatos ficam prontos e precisam acomodar a mudança.

 Analisar Solicitação de Mudança Objetivos, Papéis e Artefatos Essa atividade parte de uma Solicitação de Mudança cuja descrição foi revista re vista e complementada e cuja análise de impacto já foi documentada (mesmo que apenas em uma estimativa inicial, conforme exemplificado na seção anterior). O objetivo, neste ponto, é decidir se as mudanças devem ser aprovadas. Os responsáveis por essa decisão são os integrantes do Comitê de Controle de Mudanças. Esse comitê é composto, geralmente, por um gerente da organização cliente e o gerente de projeto (equipe de desenvolvimento). O comitê utiliza as informações documentadas para decidir sobre a adoção ou não da mudança. Se a análise de impacto foi superficial e o comitê ainda acredita que as mudan-

ças podem ser necessárias, a atividade anterior pode ser executada mais uma vez, refinando as estimativas de impacto. Se o comitê decidir que as mudanças devem ser rejeitadas, essa decisão é documentada na Solicitação de Mudança e a atividade é encerrada. Caso as mudanças sejam aprovadas, a solicitação é atualizada com o novo status e é encaminhada ao gerente de projeto para replanejamento.

 

Um Processo com Requisitos

271

O replanejamento, que não faz parte dessa atividade, inclui nos planos do pro jeto as atividades necessárias para para acomodar as mudanças. mudanças.

Resumo do Fluxo de Trabalho  



Tabela Gerenciar Mudanças - resumo Fluxo de Trabalho: Refinar Requisitos de Software Fase de Execução: Iniciação, Elaboração, Construção Responsáveis: Participantes internos e externos, comitê de controle de

mudanças, gerente de projeto  Artefatos: Artefatos:

• Artefatos sobre requisitos (podem ser modificados) • Solicitação de mudança Atividades: • Submeter solicitaçã solicitaçãoo de mudança

• Complementar solicitação de mudança - Complementar a descrição da mudança

- Analisar solicitação de mudança • Analisar solicitação de mudança Critérios de conclusão:

• Mudança aprovada ou rejeitada.

Orientações sobre Práticas Ágeis  Análise das Possibilidades deestudados, Utilização neste trabalho, com o objetivo principal Os métodos ágeis foram de aumentar a produtividade durante a execução das atividades. Após uma ampla revisão bibliográfica, chegou-se às conclusões comentadas a seguir. Embora diversos métodos ágeis tenham sido propostos nos últimos anos, formando um catálogo variado de técnicas, procedimentos e dinâmicas de desenvolvimento, esses recursos se mostraram de difícil inserção no processo de engenharia de requisitos proposto neste trabalho. Acredita-se que as razões para isso sejam:

 



Os métodos ágeis, por possuírem definições simplificadas e promoverem promoverem a auto-organização projeto,para não apossuem conrequisitos. con junto  junto considerável de elementosdas de equipes processode voltados engenhaum engenharia ria de A seção Métodos Ágeis e a Engenharia de Requisitos, no capítulo 3, resume as estratégias ágeis de desenvolvimento encontradas que se relacionam direta-

 

272

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

mente à engenharia de requisitos. Como essas estratégias estratégias são bastante reduzidas, é difícil identificar sua aplicação ao longo do processo proposto.   Os métodos ágeis oferecem os maiores ganhos quando suas práticas são utilizadas em sinergia. Eleger apenas algumas práticas para utilização em um processo de desenvolvimento de software é, além de menos produtivo, mais arriscado, já que diversas técnicas só podem ser bem-sucedidas quando aplicadas em conjunto com as demais. Como o processo proposto neste livro é restrito à engenharia de requi req uisitos, sitos, não se pode inferir das técnicas utilizadas nas demais disciplinas de desenvolvimento de software que seguem os métodos ágeis. Este contexto dificulta a inserção de técnicas utilizadas por métodos ágeis no processo proposto, já que a maioria dessas técnicas tem a premissa de utilização em conjunto com outros recursos dos métodos ágeis, como o jogo do planejamento, o projeto (design) (design) evolucionário, a integração contínua e a adoção de testes automatizados.   Esse processo foi realizado em uma organização específica cujos projetos projetos típicos não possuem as características mais indicadas para a aplicação aplicação de métodos ágeis. Algumas das características dos projetos desenvolvidos nessa organiza organização ção são: • Grandes equipes, compostas de forma heterogênea; • Clientes internacionais, sendo algumas reuniões de análise realizadas realizadas na organização cliente e os contatos seguintes acontecendo por telefone, e-mail ou teleconferência; • Ambiente de negócios dinâmico, com uma taxa razoável razoável de mudan mudanças ças nos requisitos; necessidade de uma certa formalidade na documentação, documentação, requisitada pelos clientes. As características citadas não promovem a utilização de métodos ágeis, à exceção da instabilidade dos requisitos. Considerando as conclusões listadas anteriormente, mas ainda reconhecendo reconhecendo os benefícios que podem ser alcançados com a utilização de métodos ágeis, ado-

tou-se uma estratégia para a inserção desses métodos no processo de engenharia de requisitos proposto. Em vez de adotar técnicas específicas, partiu-se para uma abordagem baseada baseada em valores, princípios e práticas dos métodos ágeis que podem ser aproveitados apro veitados nas atividades do processo proposto.

 

Um Processo com Requisitos

273

Essa abordagem foi incluída no segmento de melhores práticas do processo proposto. A seção seguinte comenta essa abordagem, identificando algumas atividades atividades que podem beneficiar-se de valores, princípios ou práticas dos métodos ágeis.

Propostas de Inserção de Práticas Ágeis no Processo Proposto As sessões de análise de requisitos em grupo, parte da atividade de Assegurar uma Visão Comum, podem beneficiar-se das práticas de comunicação face a face, valorização da simplicidade e modelagem com os outros.  A comunicação face a face e a modelagem com os outros aplicam-se sobretudo ao passo de análise de requisitos em grupo. A valorização da simplicidade contribui com o processo no passo de revisão  de artefatos. Durante as revisões, deve-se tentar perceber qual o mínimo de investimento investi mento necessário para que os artefatos relacionados a requisitos contenham informações o suficiente para representar corretamente as necessidades do cliente cliente e para permitir que a equipe técnica implemente o requisito. Nessas reuniões, geralmente ficam claros fatores como o perfil do cliente e sua capacidade de abstração, o nível de clareza e complexidade de cada módulo do sistema (quando mais simples e claro, menos informações são necessárias no documento), a compreensão da equipe sobre o negócio. Embora indicadas para a atividade Assegurar uma Visão Comum, as práticas citadasde aplicam-se volvimento requisitos.a todas as atividades do processo que englobem desen  Outra prática que pode ser utilizada amplamente é adotar times auto-organizados. Embora o processo proposto defina as atividades que devem ser executadas, executadas, a equipe pode definir seu modo de trabalho e forma de interação, pode subdividirsub dividir-se para cuidar de mais de um assunto em paralelo ou realizar workshops com todos os envolvidos, e pode adotar as técnicas de elicitação e análise que julgar mais produtiva.

Algumas estratégias escolhidas pela equipe podem necessitar de uma coordenação de atividades com a gerência do projeto. Uma prática que já é recomendada pelo RUP é a participação ativa dos stakeholders.

 

274

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

Em todas as atividades de interação com o cliente, que são estimuladas pela participação ativa, as práticas da conversação e utilização de ferramentas fer ramentas simples também trazem benefícios. No momento do detalhamento de um requisito, deve-se envolver o cliente, revisando o escopo inicial definido e utilizando as técnicas de elicitação de requisitos requisitos descritas na seção de Melhores Práticas. Caso o cliente não possa estar fisicamente presente (se estiver, por exemplo, exemplo, em outro país), a conversação pode ser feita por telefone ou aplicação de mensagem instantânea.  O uso de e-mail deve ser evitado, pois esse meio não permite rápido feedback e desacelera a comunicação. De um modo geral, todas as práticas da Modelagem Ágil podem ser utilizadas nos fluxos de atividades Definir o Escopo do Sistema e Refinar Requisitos de Software, além da atividade Assegurar uma Visão Comum.

Destacadamente, as práticas criar vários modelos em paralelo e iterar para outro artefato aumentam a produtividade e a qualidade do passo Refinar Modelos Mode los de Análise. Por fim, no que diz respeito à Gerência de Mudanças, a prática receba bem as mudanças deve ser empregada para evitar a falta de flexibilidade flexibili dade observada observada na postura das equipes de desenvolvimento de software em geral.  Qualquer membro da equipe de desenvolvimento ou da organização cliente pode enviar uma solicitação de mudança em qualquer fase do projeto. A decisão sobre discutir a mudança e implementá-la é feita pelo Comitê de Controle de Mudanças, que representa todos os interessados. A dinâmica da análise de mudanças é avaliar o impacto i mpacto e envolver o cliente clien te na decisão sobre adotar ou não a mudança. Se a mudança for adotada, o escopo deve ser ajustado, podendo inclusive inclu sive excluir requisitos de baixa prioridade. Como a decisão é do cliente, não é preciso rejeitar ou mesmo dificultar a adoção da mudança. Esta é uma aplicação da prática maximizar o investimento dos stakeholders.

E assim, caro leitor, encerramos este livro, sabendo que poderíamos continuar continuar escrevendo e apresentando mais alternativas para análise e gestão de requisitos, requi sitos, mas esperamos ter contribuído com este material para a evolução técnica de todos. “Por vezes sentimos que aquilo que fazemos não é senão uma gota de água no mar. Mas o mar seria menor se lhe  faltasse uma uma gota.”  Madre Teresa Teresa de Calcutá

 

Exercício Prático Geral

A

 Apêndice

“O conhecimento dirige a prática; no entanto, a  prática aumenta aumenta o conhecimento.” conhecimento.” (Thomas Fuller)

Nosso exercício prático, que o levará a sair a campo para realizar a análise de requisitos utilizando as técnicas e métodos apresentados neste livro, será baseado em um negócio bem comum em todo o nosso país, polêmico até certo ponto, o que não o impedirá de realizá-lo e de interagir com seus responsáveis a fim de criar o que iremos solicitar como exercício para a aplicação do conteúdo apresentado neste livro. Esse cliente evolui a cada dia no que diz respeito aos conhecimentos de Tecnologia da Informação e em seu nível de exigência para que os sistemas efetivamente suportem suas atividades operacionais, estratégicas e de negócios. Esses fatores fazem que a análise de requisitos req uisitos funcionais e operacionais desse projeto de sistemas torne-se cada dia mais vital para o sucesso e para a satisfação final dessa realização. O sistema proposto neste trabalho será realizar o projeto de um controle informatizado para um estacionamento de grande porte para veículos particulares. As empresas que gerenciam estacionamentos normamente têm as a s mesmas necessidades e existem equipamentos - totens de entrada e saída - que possibilitam a automação total desses estacionamentos, que passam a necessitar apenas de operadores para efetuar o recebimento dos valores em cartões de mensalistas, ou de tíquetes de entrada, e dos pagamentos para liberar a saída do estacionamento.

Ao entrar no estacionamento, o cliente deve ter duas opções no totem (catraca) de entrada ou saída: inserir o seu cartão de mensalista, ou apertar um botão para emissão de um tíquete de registro de entrada. Podemos considerar que, no caso do cartão de mensalista, existem dados pessoais registrados nele, como nome, número de identidade, CPF, e modelo e placa do carro.

 

276

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

O cliente do tipo mensalista/diarista poderá adquirir dias de entrada antecipada. As compras antecipadas somente poderão ser feitas com 5 a 30 dias de antecedência. Os valores de diárias ou turnos são diferenciados da seguinte forma:  

Valor de um dia inteiro de estacionamento para mensalistas;

 

Valor/hora para clientes que irão usar um turno inteiro (quatro horas) ou, então, utilizar o valor de primeira hora e horas seguintes caso o cliente deixe o veículo estacionado por um período indeterminado.

 

Como a entrada e a saída são controladas por totens com sistema, estes e stes devem ter as funções de reconhecer o cartão do mensalista/periodista, bem como deve emitir tíquete de entrada, registrando a hora que o veículo entrou nesse estacionamento. o totem deve terque duas possibilidades de leitura liberarnaquele a cancela:Na lersaída, o cartão e confirmar este tem crédito para o diapara utilizado momento (independentemente da data), ou ler o tíquete, buscar seu registro de pagamento e, assim, liberar a cancela. Dessa forma, caso não existam créditos para a saída naquele momento, ou o tíquete não tenha registro de pagamento, a catraca não deverá liberar a cancela. Sendo necessário, pode existir no totem um botão para chamar um atendente do estacionamento, porém, a realização de pagamentos no ponto de saída do estacionamento não deve ser permitida e o cliente deve ser orientado a dirigir-se a um ponto de pagamento de tíquete ou de reposição e carga de crédito conforme a regra dos 5 a 30 dias de antecedência, para depois tentar novamente sair pelos portões com totens de entrada e saída. Os totens devem permitir o registro de entradas ou saídas, conforme setagem do sistema. Portanto, eles devem possuir identificação no sistema geral. Como esse sistema permitirá mensalistas e periodistas (menos de 30 dias), ele deverá possuir cadastro de usuários ou de cartões de usuários, mas sempre exigindo o registro dos dados do cliente e do veículo para esses casos. A cada entrada ou saída de um mensalista no mesmo dia, o sistema deverá identificar essa entrada múltipla a fim de evitar que a leitura do cartão na saída

registre débito duplo no mesmo dia de créditos diários. Entretanto, no caso de não mensalista, a cada entrada será emitido um tíquete, que deverá ser pago para permitir a saída. Todos os tíquetes de entrada, bem como os registros de entrada de mensalistas, devem ser parte de um cadastro com data e hora, e um número de identificação do tíquete, ou entrada no caso de cartão de identificação do mensalista, para que

 

 Apêndice A - Exercício Prático Geral

277

seja possível disponibilizar a totalização e a movimentação de veículos e valores relativos a uma data, faixas de horários e tipo de utilização (avulso ou mensalista). O sistema deve disponibilizar consultas/relatórios de movimentação financeira diários, semanais e mensais, distribuídos por tipo de utilização. Interfaces para cadastro e consulta de clientes mensalistas, bem como cancelamentos. O sistema deve permitir cadastros exclusivos para clientes especiais, com valores diferenciados e opção de pagamento por fatura mensal ou boleto bancário. As interfaces do sistema devem permitir a troca dos dados do veículo do cliente, independentemente do período, e o cadastro de mais de um veículo para o mesmo cartão. Contudo, somente deverá ser autorizada a entrada de um desses veículos por vez. Se dois ou mais veículos do mesmo cliente acessarem o estacionamento no mesmo dia, será permitido que apenas um veículo permaneça no estacionamento por vez. Para este exercício prático, você deve: 1)   Realizar estudo de caso; 1) 2)   Identificar os requisitos, mas sem deixar de identificar a fase do Rational Unified 2)

Process (RUP), e as fases subsequentes e seus componentes; Process (RUP), utilizando User 3)  Fazer a identificação clara dos requisitos com métodos ágeis utilizando Stories; Stories; de uso; 4)  Identificar e criar os diagramas de casos de criar os diagramas de classe com base na orientação a 5)  Identificar os objetos e criar objetos;

6)  Criar diagramas de estado para as situações aplicáveis a esses requisitos;

proposto; 7)  Criar diagramas de sequência para o sistema proposto; 8)  Identificar claramente quais são os cenários principais e alternativos para cada-

caso de uso; 9)  Definir os atributos dos requisitos;

10) Listar os atributos funcionais e não funcionais; 11) Modelar as interfaces de todo o sistema; 12)  Definir quais são os limites do sistema. 12)

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

278

Importante  

Não existem solução e formato únicos para a realização desse exercício, porém, você poderá validar seus resultados com a orientação de seu professor.

 

Esse é um exercício que deve ser desenvolvido aos poucos, conforme você adquire conhecimentos ao longo do estudo deste livro.





 

Bibliografia

279

Bibliografia AMBLER, S. W. Agile Modeling and the Unified Process. 2001. Disponível em: http://www.agilemodeling.com/essays/agileModelingRUP.htm. Anais... pp. 158-180. Rio de Janeiro: PUC-Rio, 2000. Disponível em: http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER0 http://wer.inf.puc-rio.br/WERpa pers/artigos/artigos_WER00/santander.pdf 0/santander.pdf Acesso em: 27 jan. 2009. (WER06). ARMOUR, F.; MILLER, G. Advanced Use Case Modeling. Addison-Wesley: Abril de 2001. BATINI, C.; CERI, S.; NAVATHE, S. B. Conceptual Database Design: An  An EntityRelationship Approach. California: Benjamin/Cummings Publishing, 1992. BECK, K.; BEEDLE, M; BENNEKUM, A. et. al. Manifesto for Agile Software Development.. Agile Alliance. 2001. Disponível em: Development http://www.agilemanifesto.org/. BELLOQUIM, A. CMMI: O futuro do CMM. Congresso Fenasoft 2001. InfoChoose Technologies, No 42, fevereiro/2002. BITTNER, K.; SPENCE, I. Use Case Modeling . Addison-Wesley Professional, 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language User Guide. Addison Wesley Longman, 1999.  _______. UML: Guia do Usuário. Traduzido por Fábio Freitas da Silva. Rio de  Janeiro: Campus, 2000. 2000. I nformation Modeling. In: 4th BUBENKO, J. A. Extending the Scope of Information

International Workshop on the Deductive Approach to Information Systems and Databases. Proceedings… pp. 73-98. Lloret de Mar, Espanha, 1993.

CAMEIRA, R.; CAULLIRAUX, H. Engenharia de Processos de Negócios: considerações metodológicas metodológicas com vistas à análise e integração de processos. In: 3o Simpósio de Administração da Produção, Logística e Operações Internacionais. Anais

Eletrônicos... São Paulo: FGV, 2000. CARNEGIE MELLON UNIVERSITY, SOFTWARE ENGINEERING INSTITUTE.

The Capability Maturity Model: Guidelines Guidelines for Improving the Software Process. Addison Wesley Longman, 1997. [CMU/SEI_1997]

 _______. Upgrading from SW-CMM to CMMI. Pittsburg, Pennsylvania, março/2003.[CMU/SEI_2003] CARNEGIE MELLON UNIVERSITY. Capability Maturity Model Integration (CMMI), Version 1.1: CMMI for Software Engineering (CMMI-SW, V1.1) - Staged Representation. Pittsburg, 2002.

 

280

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

CARVALHO, E. A. Engenharia de Processos de Negócios e a Engenharia de Requisitos: Análise  Análise e Comparações de Abordagens e Métodos Métodos de Elicitação de Requisitos de Sistema Orientada por Processos de Negócio. http://pt.scribd.com/ doc/38864094/Dissertacao-regras-de-negocio. CARVALHO, P. F. Levantamento orientado a pontos de vista, disponível em http://www.pedrofcarvalho.com.br/PDF/E http://www.pedrofcarvalho.com.br/PDF/ENGENHARIA_ANA NGENHARIA_ANALISE_  LISE_  METIDO_PONTO_DE_VISTA.pdf, METIDO_PONTO_DE_VISTA .pdf, S. J. Rio Preto - 2009. CARVALHO, P. F. Técnicas de Levantamento de Requisitos -2009. Disponível em e m www.pedrofcarvalho.com.br/.../ENGEN www.pedrofcarvalho.com.br/.../ENGENHARIA_ANALISE_  HARIA_ANALISE_  LEVANTAMENTO_REQUSITOS_2.pdf CASTRO, J. F.B. Introdução à Engenharia de Requisitos. Jornada de Atualização em Informática do XIV Congresso da Sociedade Brasileira de Computação, Canela, Agosto de 1995. Implementação o Do Método Mac Knight Para Elicitação CHAVES, V. M. G. Implementaçã De Requisitos Na Metodologia Aris, Projeto de Graduação apresentado à Escola de Informática Aplicada da Universidade Federal do Estado do Rio de Janeiro (UNIRIO). Março de 2008.

COCKBURN, A. Crystal Clear: A Human-Powered Methodology Methodology for Small Teams. Addison-Wesley Professional, 2004. COHN, M. Advantages of User Stories for Requirements: Article is provided courtesy of Prentice Hall Professional.

CORDEIRO, M. A. Uma ferramenta automatizada de suporte ao processo de gerenciamento de requisitos. Dissertação de Mestrado, Pontifica Universidade

Católica do Paraná. Curitiba, 2002. CRUZ, P. O. S. Heurísticas para Identificação de Requisitos de Sistemas de Informações a partir de Modelos de Processos. Dissertação (Mestrado em Informática). Núcleo de Computação Eletrônica (NCE), Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2004. DAVENPORT, T. H. Reengenharia de Processos. Rio de Janeiro: Campus, 1994. Mission Critical: realizing the promise of enterprise systems. 1 ed. Boston: Harvard Business School Press, 2000.

DAVENPORT, T. H.; PRUSAK, L. Conhecimento Empresarial. Rio de Janeiro: Campus, 1998. DEMIRORS, O.; GENCEL, C.; TARHAN, A. Utilizing Business Process Models for Requirements Elicitation. In: 29th Euromicro Conference. Proceedings... 412. Turquia: IEEE Computer Society Press, 2003.

 

Bibliografia

281

DIAS, F. et al. Uma Abordagem para a Transformação Automática do Modelo de Negócio em Modelo de Requisitos. In: Workshop em Engenharia de Requisitos (WER06). Anais… pp. 51-60. Rio de Janeiro: PUC-Rio, 2006. FALBO, R. A. Análise de Sistemas, Notas de Aula. UFES - Universidade Federal do Espírito Santo, 2002/2. FIORINI, S. T.; VON STAA, A.; BATISTA, R. M. Engenharia de Software com CMM. Rio de Janeiro: Brasport, 1998. FOWLER, M.; SCOTT, K. UML Essencial: Um breve guia para a linguagem-padrão me modelagem de objetos. 2 ed., Porto Alegre: Bookman, 2000. HARMON, P. WATSON, M. Understanding UML: The Developer’s Guide. 1. ed. São Francisco: Francisco: Morgan Morgan Kaufmann, 1997. HARTMANN, J.; PRICE, R. T. Utilizando padrões organizacionais e avaliação de risco para metodologiaFederal de desenvolvimento software : de Dissertação de adaptar Mestrado:a Universidade do Rio Grande dode Sul, Instituto Informática, Programa de Graduação em Computação. Porto Alegre, 2004.

HAZAN, C. Indicadores para a Gerência de Requisitos. Claudia Hazan12, Julio Cesar Sampaio do Prado Leite2 SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO - disponível em wer.inf.puc-rio.br/WERpapers/a wer.inf.puc-rio.br/WERpapers/artigos/ rtigos/ artigos.../claudia_hazan.pdf HOLTZBLATT, K.; BEYER, H. R. Contextual Design. In: SEOGAARD, M.; DAM, R. F. (eds.). The Encyclopedia of Human-Comput Human-Computer er Interaction. Aarhus, Denmark: The Interaction Design Foundation, 2013. IEEEde Recommended Practice for IEEE-SA Standards Boards IEEE Std 830-1993. 1993. Software Requirements Specifications. Specification s. Dezembro

 JACOBSON, I. et al. Object-Orie Object-Oriented nted Software Engineering: a use case approach.  Reading, MA: Addison-Wesley, 1992.  JACOBSON, I.; BOOCH, G.; RUMBAUGH, RUMBAUGH, J. The Unified Software Development Process. Reading, MA: Addison-Wesley, 1999a. The Unified

Modeling Language Reference Manual. 1 ed. Boston (MA): Addison-Wesley Longman, 1999b.

 JACOBSON, I.; CHRISTERSON, CHRISTERSON, M.; JONSSON, P.; ÖVERGAARD, G. ObjectOriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992. KNIGHT, D. M. Elicitação de Requisitos de Software a partir do Modelo de Negócio. Dissertação (Mestrado em Informática). Núcleo de Computação Eletrônica (NCE), Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2004.

 

282

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

KOTONYA, G. SOMMERVILLE, I. Requirements engineering: processes and i l. (Worldwide Series techniques. Chichester: John Wiley & Sons, 1998. xi, 282 p. : il. in Computer Science). KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: processes and techniques. New York: John Wiley & Sons, 1997. KRUCHTEN, P. Introdução ao RUP: Rational Unified Process. Rio de Janeiro: Ciência Moderna, 2003. KRUCHTEN, P. The Rational Unified Process: An  An Introduction. 2. ed. AddisonWesley, Março de 2001. KULAK, D. Use Cases: Requirements in Context. New York: Addison-Wesley, 2001. LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação. 4. ed. Rio de Janeiro: Livros Técnicos e Científicos, 1999. LEITE, J. C. S. P. Extreme Requirements:  Jornada Jornada de Engenharia de Requisitos  Aplicada. JIRA, Universidade de Sevilha, Junho de 2001.

LEITE, J. C. S. P.; ROSSI, G.; MAIORANA, V.; BALAGUER, F.; KAPLAN, G.; HADAD, G.; OLIVEROS, A. Enhancing a Requirements Baseline with Scenarios. Proceedings of the Third International Symposium on Requirements Engineering: IEEE Computer Society, pp. 44-53 (1997). LEMKE, A. P.; MARCELO, B. R. Usando Objetos de Conhecimento para Compartilhar Conhecimento na plataforma SemantiCore. Disponível em http://www.lbd.dcc.ufmg.br:8080/colecoes/seas/2009/006.pdf. LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE disponível em publica.fesppr.br/index.php/rnti/a publica.fesppr.br/index.php/rnti/article/viewArticle/12. rticle/viewArticle/12. LOCH, J. M.; REIS, D.; PALUDO, M. A metodologia Joint Application Design:   JAD como interface para para a conversão de conhecimento conhecimento tácito em em explícito. Um  Anais do Congresso exemplo de aplicação em desenvolvimento de software. In: Anais Brasileiro de Gestão do Conhecimento - KM Brasil 2003. São Paulo: Sociedade

Brasileira de Gestão do Conhecimento, 12 a 14 de Novembro de 2003. MELO, A. C. Desenvolvendo Aplicações com UML 2.0. 2. ed. Rio de Janeiro:

Brasport, 2004. MERTINS, C. Desenvolvimen Desenvolvimento to e Gestão de Requisitos de Software, (Uma proposta de metodologia baseada no CMMI) Monografia submetida

como requisito parcial para a obtenção do título de Bacharel em Informática. - Universidade do Vale do Rio dos Sinos - UNISINOS Ciências Exatas e

 

Bibliografia

283

Tecnológicas Graduação em Informática Habilitação em Análise de Sistemas São Leopoldo, 2004 disponível em www.unisinos.br/inf/images/stories/Inf/19tc www.unisinos.br/inf/images/stories/Inf/19tc_  _  cristiane_mertins.pdf. MONIZ, A.; PINHO, A.; PEREIRA, M.; GUERRA, R. S. Documento TeóricoPrático Etnografia e Engenharia de Requisitos de Sistemas de Software, Versão 1. 0 - 18 de dezembro de 2003 disponível em http://plaginas.fe.up.pt/~ei9904 http://plaginas.fe.up.pt/~ei99042/ 2/ erss/Etnografia.pdfni.

NASCIMENTO, A. O que é SCRUM. Disponível em http: //www.oficinadanet.com.br/artigo/gerencia/o_que_e_scrum.

NONAKA, I.; TAKEUCHI, H. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press,1995. OGANDO, A. L. Sobre requisitos e casos de uso, Aula prática 1. Paraense, disponível em 143.106.50.14 143.106.50.145:8080/Cursos/EA 5:8080/Cursos/EA976/02-09/EA 976/02-09/EA976-Pratica3.pd 976-Pratica3.pdff OLIVEIRA, K. M; WERNECK, V. M. B. Aquisição de Conhecimento: Velha Fórmula, Nova Aplicação. Exame Aplicação. Exame de Qualificação para Doutorado em Ciência da

Computação, COOPE, Universidade Federal do Rio de Janeiro, 1996. PADUAN, R. A volta da qualidade. Exame, 15 de janeiro de 2003. PAULA F.; PÁDUA. W. Engenharia de Software: fundamentos, métodos e padrões.  2. ed., Rio de Janeiro: LTC, 2003. PERILLO, M. O Conceito de Gestão do Conhecimento. Disponível em http://www.administradores.com.br/informe-se/artigos/o-conceito-de-gestaodo-conhecimento/32153/. PETERS, J. F.; PEDRICZ, W. Engenharia de software: teoria e prática. Trad: Ana Patrícia Garcia. Rio de Janeiro: Campus, 2001. Tradução de: An engineering approach. PRESSMAN, R. S. Engenharia de Software. 5. ed., Rio de Janeiro: McGraw-Hill, 2002. PRESSMAN, R. Engenharia de software. São Paulo: Pearson, 2006. PROF. MSC. TAKAI, O. K. Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas. Disponível em:

http://www.slideshare.net/EventosImpacta/modelagem-dos-processos-denegcio-para-a-definio-de-requisitos-de-sistemas.

Project Manager Institute in: http://www.pmirs.org. Em 15/12/2003. [PMI_WEB] RICHARDSON, R. T. e colaboradores. Pesquisa Social: Métodos e Técnicas.  3. ed., São Paulo: Atlas, 1999.

 

284

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

ROCHA, A. R.; MALDONADO, J. C.; WEBER, K. C. Gerenciando a Qualidade de Software com Base em Requisitos. pp. 238-246. Prentice Hall, 2001. SANTANDER, V. F. A.; CASTRO, J. F. B. Desenvolvend Desenvolvendo o Use Cases a partir de Modelagem Organizacional Organizacional..

SANTANDER, V. F. A.; CASTRO, J. F. B. Desenvolvend Desenvolvendo o Use Cases a partir de Modelagem Organizacional Organizacional.. In: Workshop em Engenharia de Requisitos. SANTOS, J. H. A. Gerência de Mudanças de Requisitos: Uma Proposta de  Aplicação a um Estudo de Caso. Caso. Programa de Pós-Graduação em Computação da UFRGS. Porto Alegre: 2004. SANTOS, C. A. B.; SANTOS, J. A. M. Mapeament Mapeamento o das práticas do SCRUM em relação aos requisitos referentes à Gerência de Projetos do nível G do MPS.BR.

SCHWABER, K. The Impact of Agile Processes on Requirements Engineering.  2002. Disponível em: http://www.agilealliance.org/articles/ schwaberkentheimpacto/view?searchterm=requirements.

SOMMERVILLE, I. Software Engineering . 4th ed. USA: Addison-Wesley Publishing Company, 1992. SOMMERVILLE, I. Software engineering. 6. ed. Harlow: Addison-Wesley, 2001. STAA, A.V. Engenharia de Programas. 2. ed. Rio de Janeiro: Livros Técnicos e Científicos, 1987.

STANDING. The Attribution of Success and Failure in IT Projects. Industrial Management & Data Systems, v. 106, n. 8, pp. 1148-1165, 2006. Extreme CHAOS. The Standish Group International Inc., STANDISH GROUP. 2001. Disponível em: .

StandishGroup. CHAOS Report - Geraldo Xexéo - Relatório 2004. Disponível em wiki.xexeo.org/tiki-download_file.php

SUTCLIFFE, A. Scenario-Base Scenario-Based d Requirement Analysis. Requirements Engineering Journal, 1998. WEBER, K. C. Qualidade e produtividade em software. 4. ed., renovada. São Paulo: Makron, 2001.

WOOD, J.; SILVER, D. Joint Application Application Development. Development. 2. ed, Chichester: John Wiley & Sons, 1995. YIN, R. K. Estudo de caso: Planejamento e Métodos. Trad: Daniel Grassi. 2. ed., Porto Alegre: Bookman, 2001. ZANLORENCI, E. P.; BURNETT, R. C. Certificação de Qualidade em Engenharia de Requisitos. Primeiro Simpósio Brasileiro de Qualidade de Software (I SBQS), Gramado, outubro de 2002.

 

Índice Remissivo

Índice Remissivo  A  Abstração 20, 38, 90, 102, 232, 234, 270 Análise 19, 44, 45, 54, 58, 89, 94, 95, 109, 125, 128, 148, 155, 163, 176, 177, 188-190, 213, 234  

de impacto 105, 109, 111, 172, 266, 267

Antropologia 131 Arquiteturas 20, 63, 66, 77 Artefatos 31, 39, 58, 59, 61, 65, 68, 70, 73-75, 80, 87, 88, 94, 95, 108, 109, 121, 203, 227-233, 238, 240, 241, 243, 250, 251, 254, 256, 258-263, 265-268, 270 Atores 70, 115, 117, 117 , 118, 121, 122, 176, 178-181, 190, 191, 191 , 198, 199, 231, 247, 248, 251, 253, 257 Atributos 34, 87, 94, 103, 115, 117-119, 121, 122, 230, 232-234, 236, 253, 254, 260-262

B

Backlog 203, 204, 206, 212 Boas práticas 39, 41, 48, 84, 220, 223 BPMN 156

C Capacidade de processo 48 Casos de uso 20, 31, 67, 68, 70, 87, 111, 115, 117-122, 173, 176-182, 184-191, 193, 195, 196, 207, 218, 220, 237, 251-258 Cenários 31, 67, 68, 79, 87, 110, 111, 119, 181, 184-186, 237    

primários 181, 182 secundários 182, 191

Check list 223 Ciclo de vida 23, 24, 58, 64, 65, 72, 74, 109, 110, 166, 205, 226, 237 CMMI 19, 20, 23, 27, 29, 40-42, 46-50, 53, 55, 56, 58, 59, 61, 62, 64, 75, 92-98, 107, 108, 226228, 239 Codificar 83 Confiabilidade 25, 35, 224, 251 Conhecimento(s)

285

 

explícitos 174

 

tácito 168, 169, 171, 174

Construção 24, 27, 35, 39, 48, 64, 71, 72, 83, 86, 103, 122, 190, 195, 237, 252

D Design 23, 25, 34, 35, 39, 63, 71, 72, 78, 82, 95, 111, 148, 208, 213, 217, 269 Diagrama de atividades 113, 156

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

286

Disciplina 27, 31, 47, 70, 93, 94, 96, 103, 112, 121, 122, 203 Documento de visão 116, 240, 241, 244-247, 249, 250, 254, 255, 257

EElaboração 41, 72, 116 Elicitação 100-102, 104, 116, 139, 150, 158-161, 164-166, 229, 248, 270 Elicitar 31, 109, 110, 116, 148 Engenharia de processos de negócio 165   requisit requisitos os 23, 24, 32, 51, 58, 75, 96, 122-125, 128, 181, 207, 225-229, 232, 233, 238-241, 246, 250, 251, 256, 261, 262, 268, 269 Entrevistas 31, 116, 137, 140-145, 150, 162 Especificação 23, 27, 32, 34, 55, 72, 79, 99, 103, 104, 121, 149, 151, 172-174, 181, 184, 193-195, 197, 207, 217, 220, 229-231, 239-241, 251, 256, 258, 260 Especulação 222 Estende 187, 188, 189 Etnografia 131, 132, 135, 136, 150, 170 Eventos 25, 31, 38, 54, 111, 121, 153, 156, 160, 180-183, 188, 191, 203, 257, 260, 264 Extend 122, 187, 191, 258

F Fase de desenvolvimento 122 Fatores críticos de sucesso 38 Formulários 137, 138, 140 Framework 39, 47, 52, 62, 67, 68, 73-75, 92, 94, 95, 128-130, 153, 201-203, 207, 210, 221, 227

G Garantia de qualidade 55, 97 Gargalo 138 Generalização 102, 134, 184, 186, 187, 258 Gerência de requisitos 53-55, 65, 99, 103, 105, 107, 108, 115, 171, 172, 174, 226, 227, 229-235, 239, 253

Gerenciar dependências 117, 118, 119, 122 Gestão de    

processo 44 projeto 44

 

requisitos requisit os 20, 23, 27, 44, 45, 171, 172, 225, 228, 271

Granularidade 166, 213, 214, 237

 

Índice Remissivo

I Incoerências 221 Iniciação 72, 116, 119, 122, 226, 229, 237, 239, 242, 249, 254, 257, 260 Interface 57, 87, 100, 111, 120, 121, 139, 190, 193, 195, 196, 224, 231, 251, 255, 257-260 Iteração 64, 65, 70, 72, 78, 88, 90, 106, 119, 227, 228, 233, 237, 261

 J  JAD 148, 149, 149, 150

M Metas 48, 61, 75, 92, 107, 111, 137 Metodologia 23, 29, 30, 39, 63, 64, 68, 91, 131, 135, 136, 165, 166, 202, 225, 227 Métodos ágeis 20, 27, 64, 67, 92, 94-96, 106, 122, 215, 225 Modelar 66, 85, 86, 88, 120, 121, 123, 152, 175, 187, 188, 255, 257, 259 Monitoramento e controle de projeto 54, 94 Mudanças 23, 24, 37, 53, 54, 63, 65, 67, 75-79, 86, 95, 99, 100, 103, 104, 108, 109, 114, 115, 117119, 121, 122, 163, 165, 173, 202, 261-267

N Níveis de maturidade 45, 46, 50, 51, 53, 61, 93, 96, 97

P Papéis 61, 68-70, 73, 82, 95, 163, 164, 177, 198, 203, 210, 228, 229, 232, 237 Performance 21, 25, 57, 63, 119, 251 Permissão 135, 144 Planejamento de projeto 54, 58, 94 Pontos de vista 30, 85, 88, 102, 127, 128, 129, 150 Pós-condições 120, 192, 260 Práticas 29, 30, 55, 64, 73, 87-89, 92, 107, 122, 124, 152, 203, 220, 223, 261, 268, 270 Precondições 192 Priorizar 23, 48, 116, 119, 203, 233, 237

287

Processo 23, 24, 26, 29, 39, 40, 53, 55, 125, 174, 176, 270  

de negócio 24, 26, 34, 36, 139, 146, 165

Prototipar 120, 121, 140 Protótipo 72, 95, 106, 121, 139, 196, 231, 257, 259

 

 Análise e Gestão de Requisitos de Software - Onde Nascem os Sistemas

288

Q Questionário 146 Questões 33, 66, 72, 73, 96, 106, 133, 142, 143, 149

R Rastreabilidade 54, 63, 109, 112, 115, 118, 119, 121, 161, 165, 166, 173, 230, 253-255, 260, 266 Refatoração 81, 82, 83, 106 Repositórios de conhecimento 173 Requisições de mudança 67, 119, 121, 122 Requisitos funcionais 19, 25, 34, 35, 158, 177, 236, 250-253, 256, 260  

não funcion funcionais ais 25, 34, 35, 128, 153, 220, 224, 231, 251, 253, 255, 257, 258

Responsabilidade 56, 80, 148, 203, 204 Retroalimentação Retroalimentaç ão 79, 88-90, 98 RUP 27, 32, 33, 70-75, 85, 91-96, 107, 112, 113, 122, 127, 153, 225-228, 251

S ScrumMaster 203, 205 Sprint Planning 212, 213 Sprints 204, 205, 214 Subprocesso 36, 52

T Técnicas 19, 20, 27, 29, 51, 52, 72, 85, 98, 127, 139, 140, 142, 148, 152, 159, 171, 176, 201, 207, 210, 218, 248, 258 Transição 72, 97, 122, 226, 237

U UML 87, 127, 153, 165, 169, 178, 179, 190, 191, 247 User Stories 20, 206, 207, 209, 211-213, 216, 218

 V