2+ +artigo+ Requisitos +Prof+Fabio+2005

Anlise de Sistemas Agil: a
Gerncia de Requisitos em Ao e ca
Prof. Dr. Fbio Nogueira de Lucena a
fabio@inf.ufg.br
Instituto de Informatica Universidade Federal de Goias 22 de Maro de 2005 c
Prefcio a
A computaao, atravs do emprego de hardware e software, tem prestado c e notrios servios a sociedade. A Lei de Moore tem contribu favoravelo c ` do mente com o hardware. As diculdades de desenvolvimento de software, por outro lado, tem fomentado in meras pesquisas e sugerem que h muito o u a que fazer. Identicar o que o software dever oferecer aos clientes, para surpresa a de alguns, tido como o grande desao do desenvolvimento de software. e H pelo menos outro: gerncia de requisitos. Ao longo do tempo esta a e informaao precisa ser gerenciada, ou logo no in do desenvolvimento os c cio registros iniciais tero pouca utilidade. a O presente texto apresenta uma proposta agil para a elaboraao de espe c cicaoes de requisitos. Uma Especicaao de Requisitos de software (ERS) c c o principal insumo para a atividade de projeto e o resultado da fase coe nhecida por requisitos. Alguns modelos de processo designam esta fase de anlise. a A proposta inclui a combinaao de um processo, uma tcnica de eliciaao c e c de requisitos, modelagem de casos de uso (UML) e um plano de gerncia de e requisitos. Ou seja, o que necessrio em um mtodo com pouca burocracia e a e para ser bem-sucedido. Este o motivo para ser considerado agil. e No razovel pensar em mtodo universal, aplicvel a toda equipe de a e a e a ` desenvolvimento, a todo tipo de projeto. Mas poss enfatizar cenrios e vel a comuns e esquivar-se de especicidades. Esta foi a losoa subjacente ao mtodo apresentado. Espero que voc possa personaliz-lo, se for o caso e, e e a sobretudo, que obtenha bons resultados em aplicaoes reais e com agilidade. c
Objetivo
Uma abordagem ecaz para a realizaao da anlise de sistema c a por equipes pequenas de desenvolvimento. Deste objetivo so identicadas duas aoes principais que estabelecem a base a c subjacente e a organizaao deste texto: c Formacao. Fornecer fundamentos da anlise de sistemas. O leitor ir a a adquirir uma viso atualizada e abrangente sobre este assunto. O coa nhecimento dispon e relevante apresentado de forma pragmtica, vel e a sem rodeios. Pratica. A abordagem proposta contempla um cenrio comum a a fbricas de software de pequeno porte (veja Cap a tulo 9). Se voc e trabalha, oferece consultoria ou pretende, sobre anlise de sistemas a
para fbricas de software pequenas, ento provavelmente far uso oria a a entaoes similares aquelas presentes neste. c ` Convm ressaltar, no se trata de um texto acadmico nem compilaao e a e c de artigos tericos. Trata-se da realidade de empresas, muitas vezes em o um ambiente inspito onde soluoes imediatas so esperadas, mesmo o c a quando no so poss a a veis.
Pr-requisitos e
Paradigma de objetos. O paradigma de objetos assunto exe tenso e exige atenao. Felizmente, h referncias de boa qualidade c a e em abundncia. Algumas delas incluem [20], [30] e [11]. a UML. Est alm do escopo deste texto apresentar esta amplamente a e utilizada linguagem para a descriao de artefatos de software. Ao c leitor sugerida a leitura de [26]. De fato, a UML se estendeu de e tal forma que no poss a e vel compilar todo o assunto em uma unica referncia. A OMG (Object Management Group) oferece uma extensa e bibliograa sobre o assunto.
OMG www.omg.org
No coberto neste texto a

Anlise de sistemas apenas parte do desenvolvimento de software cua e jos processos envolvem muitas outras atividades, por exemplo, projeto de software, que est alm dos interesses deste texto. a e H pelo menos dois processos em execuao durante o desenvolvimento de a c um sistema de informaao: um que orienta as atividades que daro origem c a ao software e outro de gerncia, responsvel pelo andamento satisfatrio do e a o empreendimento. Todos eles so relevantes, embora no sejam contemplados a a neste texto.
Organizao ca
O texto encontra-se dividido em trs partes: e Fundamentos. Toda a base conceitual do texto, da qual se benecia a abordagem de anlise proposta, apresentada nesta parte. Esta a e e uma leitura util, particularmente para os menos experientes ou para se tornar conhecedor das prticas correntes mais promissoras. a Tecnologias. Os fundamentos no so sucientes. Praticantes sema a pre esto avidos pelas tecnologias que incorporam os conhecimentos a
Copyright c Fbio Nogueira de Lucena a
Verso preliminar a 22 de Maro de 2005 c
e os oferecem de forma utilizvel e conveniente. Esta a parte que a e muitos se sentem a vontade. Empregar efetivamente uma tecnologia, ` contudo, pressupe conhecimento (coberto na parte de Fundamentos) o empregado de forma correta (parte comentada abaixo). Analise de Sistemas Agil. Ao longo das partes anteriores foram estabelecidas no apenas as bases, mas ao mesmo tempo, diretrizes de a como empregar o conhecimento e as tecnologias dispon veis. Esta parte isola as questes peculiares tanto dos fundamentos quanto das tecnoo logias e apresenta um arcabouo onde podem ser empregados de forma c produtiva. As partes anteriores, Fundamentos e Tecnologias, podem ser interpretadas como sendo a apresentaao das menores unidades c que compem a abordagem proposta na terceira parte. A Anlise de o a Sistemas Agil (terceira parte) une de forma coerente o conte do anu teriormente apresentado. Esta parte orienta a realizaao da atividade c de anlise para quem j conhece as ferramentas de trabalho. a a
Contedo u
Fundamentos
14
1 Introduo ca 15 1.1 O problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Especicaao de Requisitos de Software (ERS) . . . . . . . . 16 c 1.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 Engenharia de requisitos 21 2.1 Desaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Motivaao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 c 2.3 O documento ConOps . . . . . . . . . . . . . . . . . . . . . . 24 3 Processo 3.1 Entradas e sa das . . . . . . . . . . . . . . . . . 3.2 Processo da engenharia de requisitos . . . . . . 3.3 Separaao entre especicaao e implementaao c c c 3.4 Pessoas . . . . . . . . . . . . . . . . . . . . . . 4 Anlise orientada a objetos a 5 Problema e soluo ca 5.1 Dom nio do problema . . . . 5.1.1 Necessidades . . . . . 5.2 Dom nio da soluao . . . . . . c 5.2.1 Caracter sticas . . . . 5.3 Compreendendo os dom nios . 26 27 28 29 30 32 34 34 35 36 37 38 40 40 41 42 43 44 46
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
6 Requisitos de software 6.1 O que um requisito? . . . . . . . e 6.2 Onde procurar por requisitos? . . . 6.3 Classicaao . . . . . . . . . . . . . c 6.4 O que no um requisito? . . . . . a e 6.5 Documentos . . . . . . . . . . . . . 6.6 Qualidades desejveis em uma ERS a 5
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
CONTEUDO
7 Resumo
49
II
Tecnologias
50
51
8 As ferramentas do analista
9 Contexto de referncia e 52 9.1 Caracterizaao . . . . . . . . . . . . . . . . . . . . . . . . . . 53 c 9.2 Investigaao do contexto . . . . . . . . . . . . . . . . . . . . . 53 c 10 Ator 55 10.1 Como encontrar atores? . . . . . . . . . . . . . . . . . . . . . 57 11 Caso de uso 11.1 Compreendendo casos de uso . . . 11.2 Deniao de caso de uso . . . . . . c 11.3 Associaao entre ator e caso de uso c 11.4 Descriao de caso de uso . . . . . . c 59 59 61 62 63 66 66 67 68 69
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
12 Relacionamento extend 12.1 Deniao . . . . . . . . . . . . . . . . . c 12.2 Execuao de um relacionamento extend c 12.3 O que no relacionamento extend . . . a e 12.4 Exemplos . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
13 Relacionamento include 70 13.1 Deniao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 c 13.2 Execuao de um relacionamento include . . . . . . . . . . . . 71 c 13.3 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 14 Diferenas entre include e extend c 15 Relacionamento de generalizao ca 16 Desenvolvimento orientado por caso de uso 17 Validando casos de uso 17.1 Checando: modelos de casos de uso . . . . . 17.1.1 Checando: descrioes de caso de uso c 17.1.2 Checando: atores . . . . . . . . . . . 17.1.3 Processo orientado a casos de uso . . 17.2 Entrevista . . . . . . . . . . . . . . . . . . . 17.2.1 Perl dos clientes e/ou usurios . . . a 17.2.2 Caracterizar o problema . . . . . . .
73 74 76 77 77 78 79 80 81 81 81
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
CONTEUDO
17.2.3 Compreender o ambiente do 17.2.4 Compreendendo o problema 17.2.5 Avaliando a oportunidade . 17.2.6 Avaliando necessidades . . 17.2.7 Outras questes . . . . . . . o 17.3 Checando o resultado . . . . . . . 17.4 Resumo . . . . . . . . . . . . . . .
usurio a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
82 82 83 83 83 83 86
III
Estudo de Caso
17.5 Artigo: [16] . . 17.5.1 Sidebar 17.6 Artigo: [3] . . . 17.7 Artigo: [25] . . 17.8 Artigo: [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
90 91 93 94 97
IV
Como gerenciar requisitos?

. . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
100 100 101 101 102 102 102 103
18 Uma bssola u 18.0.1 Compreenda o problema . . . . . . . . . . . . . 18.0.2 Compreenda as necessidades dos usurios . . . a 18.0.3 Deniao do sistema . . . . . . . . . . . . . . . c 18.0.4 Gerencie continualmente o escopo e mudanas . c 18.0.5 Rene a deniao do sistema . . . . . . . . . . c 18.0.6 Construindo o sistema correto . . . . . . . . . . 18.0.7 Gerencie o processo de requisitos . . . . . . . .
19 Consideraoes nais c 104 19.1 Referncias adicionais . . . . . . . . . . . . . . . . . . . . . . 104 e 19.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 19.3 O que falta fazer? . . . . . . . . . . . . . . . . . . . . . . . . . 105
Lista de Figuras
1.1
Universo de problemas dividido naqueles pass veis de serem solucionados e naqueles cujas respectivas soluoes so desconhecidas. Apenas c a um subconjunto dos primeiros pode ser solucionado com o apoio da computao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ca Problemas de interesse do cliente so decompostos pelos engenheiros a de sistemas em subsistemas. Aquele de software tratado pelos ene genheiros de software. Os engenheiros de requisitos se encarregam de renar a descrio do subsistema de software em uma Especicao ca ca de Requisitos de Software (ERS), que precedida pela anlise do proe a blema, na qual as necessidades dos clientes so identicadas. As fases a posteriores idealmente produzem o sistema que atende a ERS que, por sua vez, idealmente atende as necessidades dos clientes. O dom nio do problema, parte do mundo de interesse, fornece informaoes tanto c para engenheiros de sistemas quanto para engenheiros de requisitos (anlise do problema). . . . . . . . . . . . . . . . . . . . . . . . . a Sucesso e fracasso no desenvolvimento de software medido pela ine tensidade em que atende as necessidades dos clientes. As necessidades e o comportamento externo do software so capturados no documento a ERS. Uma boa ERS pode dar origem a um produto ruim da perspectiva do cliente, contudo, uma ERS ruim jamais conduzir a um a bom produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.2
17
1.3
18
2.1 2.2
Entre desejos e a satisfao deles esto os prossionais que os realizam. 22 ca a Evoluo do esforo despendido com atividades da engenharia de reca c quisitos. Os valores fornecidos so percentuais relativos ` durao e a a ca custo totais, ou seja, considera enquanto em 1981 o custo das atividades de engenharia de requisitos cavam em torno de 6%, em 2001 este percentual cresceu para quase 16% de todo o custo do projeto. . Modelo de ciclo de vida seqencial linear, waterfall ou ainda cascata. u Neste modelo, cada uma das fases s iniciada aps o trmino da o e o e anterior. A fase destacada indica aquela na qual a ERS produzida. e A engenharia de requisitos a rea do conhecimento que se envolve e a com as questes de interesse da fase de anlise. . . . . . . . . . . . o a
24
3.1
26
LISTA DE FIGURAS
3.2 3.3
As vrias fontes de informaoes para o processo da engenharia de a c requisitos e a Especicao de Requisitos de Software (ERS) produzida. 27 ca Requisitos evoluem ao longo de uma srie de iteraoes onde h eliciao e c a ca seguida de modelagem e validao. Estas atividades so intercaladas ca a com outras t picas da engenharia de software e podem se estender por praticamente todo o ciclo de vida da aplicao. Cada iterao pode ca ca renar a ERS parcial, produzida na iterao anterior e posteriormente ca utilizada pelo restante da equipe de desenvolvimento, mesmo estando incompleta. Observe que s a ultima iterao ir produzir uma ERS o ca a completa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A perspectiva do cliente (dom nio do problema) e a perspectiva da soluo (dom da soluo) so distintas. Software parte do dom ca nio ca a e nio da soluo. Ao longo do tempo, vrias iteraoes ocorrem entre estes ca a c dois dom nios, principalmente em decorrncia das mudanas das nee c cessidades dos clientes. . . . . . . . . . . . . . . . . . . . . . . . Da anlise do problema so localizadas as necessidades dos clientes, ou a a seja, elementos do dom do problema. As necessidades no fazem nio a parte do dom da soluo. . . . . . . . . . . . . . . . . . . . . nio ca O dom nio do problema contm necessidades, que sugerem carace ter sticas (dom da soluo) a serem realizadas pelos requisitos de nio ca software correspondentes. Uma necessidade satisfeita por pelo mee nos uma caracter stica. Cada caracter stica renada em um ou mais e requisitos de software. Convm ressaltar que conjuntos distintos de e requisitos podem satisfazer um mesmo conjunto de caracter sticas, da mesma forma que conjuntos distintos de caracter sticas podem satisfazer as mesmas necessidades. . . . . . . . . . . . . . . . . . . . . Para descrever um sistema vrias informaoes so necessrias alm das a c a a e relevantes entradas e sa das. As funoes, o ambiente computacional c e os atributos do sistema, juntamente com as anteriores formam um conjunto dos elementos necessrios e sucientes para descrio de um a ca software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.1
34
5.2
36
5.3
37
6.1
41
6.2
Uma classicao de requisitos amplamente utilizada descrita atravs ca e de um diagrama de classe da UML. Segundo esta classicao, os ca requisitos no funcionais so renados em Usabilidade, Conabilidade, a a Desempenho ou Manutenibilidade. Qualquer requisito que no entre a nesta classicao Funcional ou se trata de uma Restrio de Projeto. 42 ca e ca Documentos de responsabilidade do analista de sistema. Observe que a ERS, um dossi, compreende os diagramas de casos de uso, a descrio e ca dos casos de uso e os requisitos no funcionais, descritos no documento a Especicao Suplementar (ES). . . . . . . . . . . . . . . . . . . . ca
6.3
45
LISTA DE FIGURAS
6.4
Parte dos artefatos produzidos pela execuo das atividades da enca genharia de requisitos. Aqueles exibidos recebem o nome de Especicao de Requisitos de Software (ERS). O contedo de uma ERS ca u inclui requisitos funcionais, no funcionais e restrioes de projeto. Os a c dois ultimos geralmente esto contidos em documento denominado de a Especicao Suplementar (ES). Este documento em conjunto com os ca diagramas de casos de uso, as especicaoes correspondentes e outros c documentos usados formam uma ERS. . . . . . . . . . . . . . . . . Uma ERS descreve uma soluo com preciso suciente para ser comca a preendida tanto pelos stokeholders quanto por projetistas. A produo ca de uma ERS baseia-se nas necessidades dos clientes e nas caracter sticas ou requisitos de alto n obtidos. As necessidades e as vel caracter sticas so agrupadas em um documento chamado de Viso. . a a
46
6.5
46
10.1 Em um sistema que compreende processamento que realizado sem e

interveno humana, todos os dias, e que se inicia logo aps a meiaca o noite, Relgio o ator que dispara a execuo deste processamento. . o e ca
56
10.2 Ao identicar atores humanos lembre-se de no particulariz-los desa a

necessariamente. Quase sempre, o relevante o papel desempenhado e por um conjunto de usurios. Na Figura, mesmo que exista uma unica a pessoa que desempenha o papel, esta poder, quase sempre, ser subsa titu tornando o ator Gerente bem mais apropriado que o ator Joo da, a da Silva. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56 57 57
10.3 Exemplos de atores, que se comunicam com o sistema. . . . . . . . . 10.4 Um conjunto de atores. . . . . . . . . . . . . . . . . . . . . . . . 11.1 Viso dos usurios de um sistema de informao (metfora da fbrica). a a ca a a
Os resultados obtidos, conforme o que fornecido, as entradas, reete e o senso comum que usurios tm da operao de software. Este a e ca comportamento externo de interesse dos usurios, enquanto aquele e a interno problema de engenheiros de software. . . . . . . . . . . . . e
60
11.2 Perspectiva simplicada do universo dividia em duas partes: software

e o que interage com software (atores). A interao entre eles regisca e trada atravs de casos de uso. . . . . . . . . . . . . . . . . . . . . e
60
11.3 Comprador efetiva compra de itens previamente selecionados, o que

exige servio de consulta a crdito oferecido por outro sistema, o ator c e Sistema de Crdito. . . . . . . . . . . . . . . . . . . . . . . . . . e
62
10
LISTA DE FIGURAS
11.4 Nem sempre a interao entre usurio e sistema amigvel como gosca a e a
tar amos. Atualmente, comum o emprego de mouse, teclado, v e deos de alta denio e recursos sonoros para esta interao. Atores que ca ca so softwares interagem com o sistema, geralmente, atravs de proa e tocolos de comunicao. Sockets um destes protocolos comumente ca e empregados entre mquinas interligadas pela Internet. Uma operadora a de carto de crdito pode, por outro lado, disponibilizar uma interface a e proprietria, a ser utilizada pelo software de interesse, que utilizar a a a linha telefnica para obter os servios desta operadora. . . . . . . . . o c
63
12.1 O relacionamento extend entre casos de uso uma relao de dee ca pendncia do caso de uso que estende para o caso de uso base. . . . e 12.2 Execuo do caso de uso base B estendido pelos casos de uso A e C. ca
Ao atingir o passo 1 da seqncia de eventos de B, a condio (prue ca e condio) de A, caso de uso que estende B neste passo, executada. ca e Caso verdadeira, conforme sugere a gura, ento a seqncia de A a ue e executada. Ao trmino, o controle retornado para o ponto de exe e tenso em B, donde a execuo prossegue normalmente at o prximo a ca e o ponto de extenso, que transfere o controle para C. A condio de a ca guarda de C, conforme sugere a gura, avaliada como falsa e, neste e caso, o controle retorna imediatamente para B, sem que o comportamento descrito no uxo bsico de C seja executado. . . . . . . . . . a
66
68
13.1 O relacionamento include entre casos de uso uma relao de dee ca

pendncia do caso de uso base, aquele que inclui, para o caso de uso e que inclu e do. . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
13.2 O comportamento de um caso de uso inclu executado no momento do e

em que executado o ponto de incluso. Neste exemplo, os passos e a 2 e 4 do caso de uso base B so pontos de incluso. No primeiro a a deles o controle transferido para o caso de uso A. Aps o trmino e o e da execuo do caso de uso A o controle retorna para o caso de uso ca B, que prossegue com a execuo do passo 3. Ao atingir o passo 4 o ca controle novamente transferido para fora do caso de uso B. Aps o e o trmino da execuo do uxo de eventos de C o controle retorna para e ca o caso de uso B. . . . . . . . . . . . . . . . . . . . . . . . . . .
71 72
13.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1 O relacionamento de generalizao entre casos de uso dene um caso ca de uso derivado a partir de um caso de uso base. . . . . . . . . . . .
75
11
LISTA DE FIGURAS
17.1 O diagrama de estados ilustra as vrias fases de desenvolvimento de a

um caso de uso. A inicial contm informaoes m e c nimas, mas sucientes para serem analisadas posteriormente, onde detalhes sero acrescentaa dos. A descrio resultante ainda poder passar por vrios renamenca a a tos. De uma perspectiva ampla, no razovel esperar uma denio a e a ca nal, mas uma elaborada que, com o tempo, pode ser necessrio a ren-la. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a
80
12
Lista de Tabelas
3.1
Adaptado de [16]. Analista, Desenvolvedor e SQA so pratia cantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
13
Parte I
Fundamentos
14
Aprendi que quanto mais se conhece os requisitos, melhor o sistema se encaixa nas necessidades da organizaao. c Advanced Object-Oriented Analysis & Design using UML Cambridge University Press, 1998 James J. Odell
Introduo ca
Antes de desenvolver um sistema de informaao necessrio denir os c e a servios a serem oferecidos pelo sistema. Os requisitos incluem esta dec niao. Ao contrrio do que pode sugerir, no fcil denir requisitos de c a a e a software. Toda uma area se ocupa das diculdades: a engenharia de requi sitos. A conceituaao precisa de um sistema a ser constru exige uma clara c do compreenso do problema a ser solucionado e como um computador pode a ser usado para resolver o problema. O cliente tenta descrever o que deseja, enquanto os responsveis pelo desenvolvimento tentam elucidar as necesa sidades do cliente. A comunicaao no fcil, conforme sugere a gura c a e a abaixo.
O que ser feito O que a cliente deseja
A primeira parte deste texto oferece uma viso abrangente da engenharia a de requisitos e estabelece um arcabouo utilizado nas demais. Para aquec les no familiarizados com a area, a leitura obrigatria. Aqueles que j a e o a possuem experincia podem iniciar a leitura por outra parte. e Este um livro para ser praticado! Este livro para quem faz. e e 15
CAP ITULO 1
Introduo ca
1.1
O problema
Apesar de maravilhoso, o mundo est repleto de problemas. Para muia tos deles, em determinado instante, no so conhecidas as soluoes cora a c respondentes, enquanto h soluoes dispon a c veis para outros. Apenas um subconjunto dos problemas que possuem soluao podem se beneciar da c computaao (Figura 1.1). c
Problemas cujas solues, se existirem, so desconhecidas
Problemas que so passveis de serem solucionados

Problemas cujas solues beneficiam-se da computao
Figura 1.1: Universo de problemas dividido naqueles pass veis de serem solucionados e naqueles cujas respectivas soluoes so desconhecidas. Apenas um subconjunto dos c a primeiros pode ser solucionado com o apoio da computao. ca
Problema: denir um sistema de informao ca
Problemas que no esto no interior da nuvem esto alm dos interesses a a a e deste texto. Para os demais poss a confecao de software que os resolva e vel c total ou parcialmente. A Engenharia de Software a area que enfrenta os e desaos da construao destas soluoes. c c Entre os maiores destes desaos est, perante o problema em questo, a a a caracterizaao do software correspondente. Em outras palavras, no fcil c a e a denir um software que adequadamente resolve ou ameniza as diculdades oriundas de um dado problema. A Engenharia de Requisitos a parte da e engenharia de software responsvel por esta deniao. a c
1.2
Especicao de Requisitos de Software (ERS) ca

Para um problema no interior da nuvem de interesse, podem existir vrias propostas de soluao. As propostas de soluao e as soluoes respectia c c c vas fazem parte do dom nio da soluao. c Uma proposta de soluao denominada de Especicaao de Requisitos c e c de Software (ERS). Nesta especicaao um sistema de informaao denido. c c e A realizaao desta especicaao, ou soluao, um software. Uma ERS uma c c c e e proposta de soluao e no se confunde com a soluao propriamente dita, o c a c software correspondente.
16
SECAO 1.2
Especicao de Requisitos de Software (ERS) ca
A realizaao de uma proposta de soluao (ERS) exige esforos de vrias c c c a atividades. Por exemplo, projeto e codicaao, para citar dois temas entre c vrios outros relevantes ao desenvolvimento de software mas no contemplaa a dos neste texto. Modelos de ciclos de vida de softwares so vistos adiante a (Cap tulo 3).
Engenharia de Software
Engenharia de Requisitos
Outros nomes: requisitos, anlise, anlise de sistemas (de requisitos)
Projeto, implementao, testes, manuteno
Anlise do Problema
Definio do Sistema (comportamento externo) Soluo
ERS
Especificao de Requisitos de Software
Sistema
Parte do mundo de interesse
software
hardware, procedimentos, pessoas, ...
Engenharia de Sistemas
Identifica elementos da soluo
Figura 1.2: Problemas de interesse do cliente so decompostos pelos engenheiros a

de sistemas em subsistemas. Aquele de software tratado pelos engenheiros de softe ware. Os engenheiros de requisitos se encarregam de renar a descrio do subsistema ca de software em uma Especicao de Requisitos de Software (ERS), que precedida ca e pela anlise do problema, na qual as necessidades dos clientes so identicadas. As a a fases posteriores idealmente produzem o sistema que atende a ERS que, por sua vez, idealmente atende as necessidades dos clientes. O dom nio do problema, parte do mundo de interesse, fornece informaoes tanto para engenheiros de sistemas quanto c para engenheiros de requisitos (anlise do problema). a
A identicaao de uma proposta de soluao precedida pela anlise do c c e a problema em questo. Tal anlise exige a compreenso do dom a a a nio no qual o problema reside. Em alguns casos o escopo de interesse at modelado, e e resultando no que conhecido por modelagem do negcio. e o A anlise do problema e a modelagem do negcio so entradas valiosas a o a para uma adequada caracterizaao de uma soluao, documentada atravs c c e de uma ERS que, por sua vez, entrada necessria para a construao do e a c software correspondente. Observe que a existncia de uma ERS uma elaboraao conceitual do e c
A existncia de e problemas fazem emergir diculdades.
Uma ERS deve satisfazer necessidades e, dessa forma, resolver problemas.
17
CAP ITULO 1
Introduo ca
que dever ser constru condiao sine qua non para que o software a do e c correspondente possa ser criado. Isto no signica que toda a ERS deva a estar pronta antes do in da construao, como veremos posteriormente. cio c O principal objetivo deste texto apresentar uma abordagem pragmtica e a para a identicaao de requisitos de software, documentados em uma ERS, c talvez o mais importante artefato de um processo de software.
S se pode construir o (projeto e implementao) o que ca foi previamente denido (anlise). a
ERS
Boa especificao
Satisfao do cliente
Especificao ruim
Fracasso
Figura 1.3: Sucesso e fracasso no desenvolvimento de software medido pela intensie dade em que atende as necessidades dos clientes. As necessidades e o comportamento externo do software so capturados no documento ERS. Uma boa ERS pode dar a origem a um produto ruim da perspectiva do cliente, contudo, uma ERS ruim jamais conduzir a um bom produto. a
A gura 1.3 fornece uma perspectiva da importncia da engenharia de a requisitos e do seu principal produto: a ERS. Se o sistema desejado atende as necessidades do cliente, ento tem-se um caso de sucesso. Ou seja, tanto o a problema quanto a soluao foram adequadamente denidos. Por outro lado, c se o problema do cliente no adequadamente compreendido, ento a soluao a e a c proposta correspondente, contida na ERS, no atender as necessidades reais a a do cliente e o fracasso inevitvel. e a A engenharia de requisitos a area responsvel pela descoberta das reais e a necessidades do cliente e do comportamento externo de uma soluao, que c atende tais necessidades. O comportamento externo registrado na ERS, e que deve ser suscet a anlise, a comunicaao intelig e a subseq ente vel ` a ` c vel ` u implementaao. Sem uma especicaao de requisitos bem escrita, desenvolc c vedores no sabem o que construir, clientes no sabem o que esperar e no a a a h como validar o sistema constru a do.
18
SECAO 1.3
Contexto
1.3
Contexto
A medicina tem como foco o ser humano, que no parte da medicina. A a e engenharia civil visa viabilizar infra-estrutura util ao progresso. Em ambos os casos, tem-se uma area cujo objetivo satisfazer desejos alm de suas e e fronteiras. A computaao no diferente. Pode-se armar que aspiraoes humac a e c nas so afetadas pelos produtos desta area, direta ou indiretamente. Estes a produtos repercutem, contudo, alm da computaao, assim como nos casos e c anteriores. Em conseqncia, so avaliados adequadamente da perspectiva ue a externa, fornecida pelo cliente, que tambm a fonte de necessidades. e e Os benef cios da computaao so usufru c a dos atravs de uma combinaao e c de hardware e software. Hardware sem software faz muito pouco, software sem hardware imposs e vel. Denir software, portanto, depende do hardware onde este ser executado. a Uma viso mais abrangente revela que apenas a deniao do hardware a c no suciente. Por exemplo, a combinaao de software e hardware onde o a e c primeiro executado ter que interagir com outros dispositivos? Responder e a esta e outras perguntas exige a deniao de sistema, onde software o c e hardware que o executa formam apenas um dos componentes.
Sistema: grupo interdependente de pessoas, objetos e procedimentos formado com o propsito de satisfazer objetivos denidos ou deo sempenhar algum papel operacional ao executar funoes espec cicadas. Um sistema completo inclui todos os equipamentos, facilidades, mateirias, programas de computador, documentaao c tcnica, servios e pessoas envolvidos [4]. e c
A identicaao de requisitos destes sistemas e a posterior caracterizaao c c de elementos (ou subsistemas) e os objetivos correspondentes tema da e engenharia de sistemas. Estas informaoes do origem a um dos primeic a ros artefatos no processo de desenvolvimento, a saber, a Especicaao de c Requisitos de Sistema [4]. Um engenheiro de sistemas, por exemplo, responsvel pela identicaao e a c dos vrios componentes de um freio ABS, entre os quais software identica a apenas um deles. No razovel esperar pela deniao precisa dos requisitos de cada um a e a c dos componentes realizada por engenheiros de sistemas, que so responsveis a a pelo funcionamento global, por uma viso macro do sistema. Esta deniao a c detalhada e precisa depende de conhecimento espec co e peculiar as areas ` correspondentes aos componentes identicados.
19
CAP ITULO 1
Introduo ca
Cabe a engenharia de requisitos reunir o conhecimento dispon para ` vel obter a deniao detalhada de componentes de software. Portanto, a engec nharia de requisitos empregada para auxiliar na tarefa de identicaao dos e c requisitos de software, derivados da especicaao de requisitos do sistema c no qual o software est inserido. a E razovel esperar que a especicaao de requisitos do sistema seja abrana c gente e aborde apenas supercialmente as tarefas atribu das a software. Estes requisitos so insucientes para projetistas, que precisam de mais ina formaoes, registradas na especicaao de requisitos de software ou ERS c c (veja 1.2). No h consenso quanto a localizaao da engenharia de requisitos em a a ` c uma area que imediatamente a contm. Em alguns casos a engenharia de e requisitos tratada como parte da engenharia de sistemas [25], noutros como e area da engenharia de software [33]. Preferncias a parte, os objetivos da e ` engenharia de requisitos (ER) permanecem inalterados em ambos os casos.
20
Engenharia de requisitos
Segundo o Houaiss, engenharia a aplicaao de mtodos cient e c e cos ou emp ricos a utilizaao dos recursos da natureza em benef do ser humano. ` c cio Noutras palavras, trata da criaao de soluoes efetivas, conforme os recursos c c dispon veis, para problemas prticos empregando conhecimentos cient a cos. A engenharia de requisitos deve lembrar aos praticantes a acepao de engec nharia, associada a problemas reais e soluoes efetivas, pass c veis de serem analisadas da perspectiva da cincia. Desde o reconhecimento do problema e at o detalhamento da soluao, a engenharia de requisitos deve fazer uso e c do rigor da engenharia, ou aplic-lo ao que convencionalmente conhecido a e por anlise de sistemas. O engenheiro de requisitos o responsvel pela a e a identicaao dos requisitos de um software. c
2
Engenharia de requisitos a rea e a associada ` conhecida a anlise de sistemas. a
Objetivo da engenharia de requisitos: denir as necessidades dos clientes e uma soluao compat [10]. c vel
Alan Davis, um dos expoentes da area, aborda-a de trs perspectivas [9]: e De uma perspectiva de dom nio a ER compreende: A anlise do dom a nio do problema para determinar as necessidades de automaao de um usurio. c a A especicaao do comportamento externo do sistema que satisc faz necessidades. De uma perspectiva temporal a ER compreende: 21
CAP ITULO 2
Uma das atividades iniciais de engenharia de software que resulta na criaao de uma especicaao de requisitos de software (ERS). c c As constantes atividades de atualizaao da ERS, resultado de c mais conhecimento obtido do problema ou da soluao de software. c De uma perspectiva tecnolgica a ER compreende: o Uma grande faixa de mecanismos de especicaao que vo desde c a o emprego de linguagem natural at tcnicas de especicaao fore e c mal para denir precisamente o comportamento de um sistema. Apesar da terminologia heterogna, alguns elementos so essenciais a e a ` compreenso da engenharia de requisitos. O problema existe no dom a nio do cliente (ou usurio) e suscita necessidades. As necessidades do origem a a a caractersticas da soluao. As caracter c sticas so requisitos de software a abstratos, em uma forma intermediria entre os requisitos (concretos) de a software e as reais necessidades dos clientes. O Cap tulo 5 e dedicado a ` compreenso destas questes. a o
2.1
Desaos
Denir o que um software dever fazer pode induzir o leitor a imaginar a uma facilidade que no se verica na prtica. Barreiras de comunicaao a a c existem entre desenvolvedores e clientes, tornando a identicaao e interc pretaao comum dos requisitos uma tarefa dif c cil. O que claro para uns e e opaco para outros. Tais diculdades de comunicaao no so exclusivas do c a a desenvolvimento de software.
O garoto tem bom gosto. Esta torta muito boa!
Eu quero uma torta assim!
Figura 2.1: Entre desejos e a satisfao deles esto os prossionais que os realizam. ca a Uma ERS suscet e vel a atributos indesejveis. Ela pode estar incoma pleta, amb gua ou conter informaoes dif c ceis de serem testadas. Isto no a enumera todas as diculdades. Neste cenrio, a volatilidade de requisitos a
22
SECAO 2.2
Motivao ca
um srio complicador. Enquanto o software desenvolvido, o que pode e e e se estender por meses ou mais, os requisitos sofrem mudanas para manter c a compatibilidade com o mundo que o cerca. Durante o desenvolvimento, descobertas podem exigir atualizaoes na especicaao correspondente. Ou c c seja, prximo do imposs capturar, em determinado instante de tempo, e o vel todos os requisitos, visto que continuamente passam por alteraoes. c Clientes podem estar dispersos, dicultando o contato. Podem ser numerosos e, alm disso, possu e rem objetivos conitantes, perspectivas e formaoes c distintas. Alguns podem ter diculdade em esclarecer seus objetivos. Em outras palavras, a diculdade de eliciar 1 requisitos no envolve um dilogo a a entre um engenheiro de requisitos e uma unica pessoa, o cliente. O cliente pode ser toda uma comunidade heterogna, em vrios quesitos, com a qual e a o engenheiro de requisitos ter que se comunicar. a
2.2
Motivao ca
A computaao usufru atravs da combinaao de hardware e softc e da e c ware. A evoluao do hardware ditada pela Lei de Moore. Segundo esta lei, c e a capacidade computacional dos dispositivos f sicos dobra a cada 18 meses. Para felicidade de muitos, geralmente isto acompanhado de uma reduao e c dos preos. Do ponto de vista de software, contudo, no h um cenrio to c a a a a promissor. Pelo menos duas explicaoes podem ser identicadas. c A primeira decorre das crescentes necessidades. A computaao est c a sendo descoberta, empresas desejam cada vez mais a automaao de atividac des, h cada vez mais novas aplicaoes, antes no imaginadas. A segunda a c a decorre dos vrios desaos do desenvolvimento de software. a
Maior diculdade de desenvolvimento de software: denir o que suposto que o sistema realize e
Projetos falham e a principal causa das falhas esto associadas aos requia sitos. Brooks [15] contundente e no deixa margem para d vidas. Segundo e a u ele, a parte mais dif da construao de um software decidir precisamente cil c e o que construir. Nenhuma outra parte do trabalho conceitual to dif e a cil quanto estabelecer requisitos tcnicos detalhados. Nenhuma outra parte do e desenvolvimento de software causa tantos danos se feita de forma errada. Nenhuma mais dif de corrigir posteriormente. e cil Boehm [7] arma que 6% dos custos dos projetos e entre 9% e 12%
1 Segundo o dicionrio Houaiss da l a ngua portuguesa, eliciar fazer sair, expulsar, e expelir. Portanto, melhor reete a simples indisponibilidade dos requisitos em formato que facilita a captura. Capturar outro termo geralmente empregado, mas preterido e neste texto.
23
CAP ITULO 2
da duraao do projeto so dedicados a especicaao de requisitos. Valores c a ` c maiores, contudo, foram encontrados por Hofmann e Lehner [16], em 2001, vinte anos depois (Figura 2.2).
40 35 30 25 20 15 10 5 0 1981 2001 10,5 6 15,7 Durao Custo 38,6
Figura 2.2: Evoluo do esforo despendido com atividades da engenharia de requica c sitos. Os valores fornecidos so percentuais relativos ` durao e custo totais, ou seja, a a ca considera enquanto em 1981 o custo das atividades de engenharia de requisitos cavam em torno de 6%, em 2001 este percentual cresceu para quase 16% de todo o custo do projeto. Na literatura abundam os depoimentos favorveis a uma abordagem mais a disciplinada para tratar os requisitos. Elas explicam, em parte, o crescimento exibido no grco. Contudo, no so sucientes para eliminar as a a a diculdades. Este texto apresenta uma proposta objetiva e prtica para a lidar com tais diculdades.
2.3
O documento ConOps
A estratgia na qual desenvolvedores analisam as necessidades dos usurios e a e preparam a especicaao de requisitos correspondente, a ser validada pec los usurios apresenta vrios problemas. Conforme [12], diculdades de a a comunicaao entre stakeholders podem conduzir a insatisfaao com o futuro c ` c sistema. O manual do usurio pode ser de alguma ajuda, embora modicaoes a c sejam onerosas. Um prottipo da interface tambm pode ser util, embora o e a aprovaao de um prottipo possa no contemplar todos os requisitos, em c o a particular os operacionais. O ConOps visa esclarecer as necessidades operacionais de um sistema, o que facilita a comunicaao entre stakeholders. c Este documento estabelece uma ligaao entre as necessidades dos usurios c a o ponto de partida deste e o processo de desenvolvimento de um sistema. E desenvolvimento, a largada (Figura ??). e
24
SECAO 2.3
O documento ConOps
Um dos instrumentos de registro de requisitos mais conhecidos o doe cumento ConOps (Concepts of Operations). Este documento descreve as caracter sticas de um sistema da perspectiva operacional, empregando a linguagem do usurio, ao contrrio de uma ERS, que faz uso de linguagem a a adequada para o consumo de desenvolvedores. O emprego de diagramas, ilustraoes, e grcos estimulado. c a e ConOps a fotograa de um sistema a uma certa distncia da qual e a detalhes no podem ser detectados, mas apenas o que uma viso de mais a a alto n pode oferecer. O ConOps contm a misso de um sistema como vel e a gerenciar contatos de uma empresa; funoes como manter o registro de c contatos e objetivos como permitir o envio de mala direta para aniversariantes. Vises e expectativas dos usurios esto contidas no ConOps. Em cono a a seqncia, algumas informaoes so vagas como fcil de usar, operaao ue c a a c eciente e outros. Estas expresses reetem as percepoes do sistema da o c perspectiva do usurio a serem detalhadas em uma ERS. a O ConOps pode ser produzido pelos desenvolvedores do sistema ou pelos prprios usurios. A importncia do conte do deste documento ressaltada o a a u e pela existncia do padro IEEE 1362 [5], que detalha o conte do e a estrue a u tura deste documento. Elementos essenciais incluem: 1. Escopo 2. Documentos referenciados 3. O sistema ou situaao corrente c 4. Motivaao para um novo sistema ou modicaoes em um existente c c 5. Cenrios de operaao a c 6. Classes de usurios e caracter a sticas de uso 7. Resumo de impactos 8. Anlise do sistema proposto a 9. Notas 10. Apndices e Cenrios de operaao, em particular, beneciam-se de casos de uso. a c
25
A qualidade de um software est limitada a a qualidade do processo que o produziu. ` Status Report: Requirements Engineering, IEEE Software, 7579, nov/1993. Pei Hsia et al.
Processo
A engenharia de requisitos parte de um processo maior, o processo e de software, que compreende desde a identicaao de um problema at a c e construao da soluao correspondente e, inclusive, aps o in do emprego c c o cio da soluao produzida pelo processo. O intervalo de tempo correspondente c geralmente interpretado atravs de um ciclo de vida, que ressalta grandes e e fases do desenvolvimento de um software. Um dos modelos de ciclo de vida mais conhecidos o modelo seq encial linear (Figura 3.1). e u
Anlise
Produto Fase contemplada pela rea de Engenharia de Requisitos
Projeto Codificao
ERS
Testes Integrao
Figura 3.1: Modelo de ciclo de vida seqencial linear, waterfall ou ainda cascata. u
Neste modelo, cada uma das fases s iniciada aps o trmino da anterior. A fase o e o e destacada indica aquela na qual a ERS produzida. A engenharia de requisitos a e e rea do conhecimento que se envolve com as questes de interesse da fase de anlise. a o a
O modelo cascata (Figura 3.1) criticado na literatura por vrios motie a 26
SECAO 3.1
Entradas e sa das
vos. No se tem aqui a pretenso de julgar o mrito deste ou daquele proa a e cesso de software. Neste texto, o modelo cascata, pela simplicidade, facilita a identicaao da fase na qual as atividades da engenharia de requisitos so c a realizadas. Segundo este modelo, a fase de anlise deve produzir os requisitos a do software, registrados na ERS. Convm ressaltar, contudo, que o emprego e deste modelo apenas didtico. Na prtica, vrias iteraoes so necessrias e a a a c a a para produzir uma ERS, intercaladas com atividades de projeto, conforme comentado adiante. O modelo de ciclo de vida seq encial, por exemplo, no u a permite a realizaao intercalada de atividades, o que o torna incompat c vel com a prtica sugerida neste livro. Embora possua esta seqncia r a ue gida, o modelo seq encial contempla as tarefas que devem ser realizadas ao longo u do tempo, neste trabalho ele foi utilizado desta perspectiva. O amplo emprego de modelos evolucionrios um reconhecimento de que a e virtualmente imposs obter todos os requisitos e as decises de implee vel o mentaao corretos em uma primeira rodada. A ausncia de uma descriao c e c completa dos requisitos , para muitos praticantes, uma realidade. Neste e aspecto, o desao real encontrar quais os tipos e n e veis de incompletitude que o desenvolvedor pode viver com.
Segundo o modelo seqencial, os u requisitos so a denidos durante a fase de anlise, a algumas vezes tambm chamada de e requisitos.
3.1
Entradas e sa das
Uma perspectiva pela qual um processo pode ser observado pelas ene tradas que servem de insumos e as sa das produzidas (Figura 3.2).
ERS
Sadas
Sistemas existentes Clientes Regulamentos Domnio Entradas Padres
ER (processo)
MD
Modelagem de Domnio
Figura 3.2: As vrias fontes de informaoes para o processo da engenharia de requisitos a c e a Especicao de Requisitos de Software (ERS) produzida. ca So muitas as entradas, que podem assumir vrias formas. Sistemas de a a informaao existentes que sero substitu c a dos ou com os quais o novo sistema ter que interagir. As necessidades dos clientes. Padres e regulamentos a o empregados ou que devem ser seguidos pela organizaao e o dom c nio em questo. Estes compreendem as entradas. a
27
CAP ITULO 3
Processo
A sa consiste em especicaoes em linguagem natural, em sua maioda c ria. Contudo, modelos e diagramas podem ser empregados para elucidar o signicado dos requisitos.
3.2
Processo da engenharia de requisitos

Pode-se especular que as atividades de projeto, implementaao e outras, c precedidas pela confecao da ERS, seguem um processo seq encial, no qual c u inicia-se uma atividade apenas aps o trmino da anterior. Esta abordagem o e seq encial no apropriada e est distante da realidade quando a tarefa u a e a e denir requisitos. Na prtica, as vrias atividades necessrias a deniao de requisitos so a a a ` c a realizadas de forma iterativa e intercaladas com outras atividades de outras fases do ciclo de vida do sistema. A Figura 3.3 ilustra um processo para estas atividades. O emprego deste modelo pode exigir vrias iteraoes e a c se estender por todo o ciclo de vida do software. Naturalmente, isto ilustra a incompatibilidade do emprego do modelo seq encial e a realidade da u deniao de requisitos. c
Anlise de Sistemas (processo)

Incio ERS til a fases posteriores
Anlise do Problema
Eliciao
Modelagem
Validao
Omisso, dvida ou outra dificuldade detectada
Figura 3.3: Requisitos evoluem ao longo de uma srie de iteraoes onde h eliciao e c a ca seguida de modelagem e validao. Estas atividades so intercaladas com outras t ca a picas da engenharia de software e podem se estender por praticamente todo o ciclo de vida da aplicao. Cada iterao pode renar a ERS parcial, produzida na iterao anterior ca ca ca e posteriormente utilizada pelo restante da equipe de desenvolvimento, mesmo estando incompleta. Observe que s a ultima iterao ir produzir uma ERS completa. o ca a No h um processo unico nem um que satisfaz todos os casos. Aquele da a a Figura mencionada tem o propsito de ressaltar a iteraao e a validaao preo c c sentes em praticamente todas as propostas. Cada combinaao de empresa, c tipo de software e pessoal sugere um processo particular, a ser denido pelo processo de software da fbrica de software em questo. a a Na Figura 3.3 a fase de eliciaao refere-se a deniao de requisitos e resc ` c trioes fornecidas pelos stakeholders (veja deniao adiante). A modelagem c c
28
SECAO 3.3
Separao entre especicao e implementao ca ca ca
faz o registro dos requisitos eliciados. A validaao visa garantir que atributos c desejados estejam presentes na ERS.
3.3
Separao entre especicao e implementao ca ca ca

Convm ressaltar um aspecto de processo geralmente mal compreene dido. Especicaao e implementaao, anlise e s c c a ntese, requisitos e projeto so dicotomias equivalentes. So vrios os benef a a a cios desta polarizaao, pois c so atividades de naturezas distintas, exigem habilidades distintas. Cona tudo, exigir que toda a especicaao seja conclu antes do in c da cio da implementaao correspondente no parece razovel. c a a Conforme Swartout e Balzer [31], limitaoes da tecnologia de implec mentaao dispon podem forar mudanas na especicaao. Por exemplo, c vel c c c decidir a implementaao de uma pilha como um array em vez de uma lista c ligada pode impor limites no tamanho da pilha. Decidir pelo emprego de busca de padro em seqncias de caracteres com recurso para curingas a ue (wildcards) pode forar, de forma anloga, mudanas na especicaao corc a c c respondente. Swartout e Balzer alertam que a alteraao da semntica da c a especicaao para contemplar uma deciso de implementaao comum e c a c e inevitvel. a Ainda acrescentam que outra fonte de modicaoes de especicaao rec c side na capacidade humana limitada para antecipaao ou previso. Muitos c a sistemas possuem complexidades para as quais no exeq a e uvel antecipar todas as implicaoes de um requisito. Nestes casos, s durante a implec o mentaao as implicaoes podem ser examinadas em detalhes a partir da c c implementaao produzida. Em sistemas de porte considervel, freq ente c a e u encontrar efeitos indesejveis ou descrioes incompletas que foram revelaa c dos apenas com a implementaao. Nestes cenrios torna-se inclusive quesc a tionvel a viabilidade de uma ERS como um contrato xo entre um cliente a e um desenvolvedor. Um processo que intercala a especicaao e a implementaao mais coec c e rente, alm de ser real e stico quanto as modicaoes. Praticantes reconhecem ` c que a implementaao pode prosseguir de requisitos incompletos [29]. Os c exemplos acima mostram que requisitos no so absolutos. Em boa parte, a a so afetados por consideraoes de implementaao e pela disponibilidade de a c c recursos. Torna-se claro, portanto, que a especicaao no ocorre de forma c a isolada, sem interferncia de resultados de outras atividades do processo de e software. A deniao de requisitos claramente inui sobre as atividades de c projeto que, quando realizadas, podem dar origem a novos requisitos ou alteraoes naqueles existentes. c Muitos dos trabalhos sobre engenharia de requisitos foram direcionados para organizaoes preocupadas com o desenvolvimento de sistemas unicos, c
Especicao e ca implementao se ca intercalam benecamente ao longo do tempo.
29
CAP ITULO 3
Processo
grandes, cujos desenvolvimentos exigiam um contrato prvio entre as orgae nizaoes e as instituioes de desenvolvimento de software. Neste cenrio, c c a clientes e desenvolvedores envolviam-se em uma tarefa que visava chegar a um acordo acerca do sistema a ser constru do. Este consenso devia ser uma descriao precisa e no amb c a gua do sistema, aps o qual os desenvolveo dores recolhiam-se e s reapareciam na iminncia da implantaao. o e c Este cenrio pode ter servido de mote para a tentativa de eliciar toa talmente os requisitos em uma fase hermtica, sem conexo com outras. e a Entretanto, atualmente h uma tendncia em downsizing, ciclos mais curtos a e de produtos e crescente nfase na construao de componentes reutilizveis e e c a fam lias de arquiteturas de software, alm de emprego de software terceirie zado, o que bem distinto do cenrio anterior e torna o modelo de contrato e a de software irrelevante em muitos casos [29]. Siddiqi e Shekaran [29] discutem esta mudana de cenrio. Segundo eles, c a alguns itens merecem atenao cuidadosa: c Suporte a construtores de software voltado para o mercado. Neste caso, os requisitos no so eliciados de um cliente, mas criados atravs a a e da observaao de problemas em areas (dom c nios) espec cas e invenao c das soluoes. A engenharia de requisitos clssica oferece pouco suporte c a a tais cenrios. a Priorizar requisitos. A competiao tem forado a reduao do tempo c c c de liberaao de um produto, o que deliberadamente ocorre, muitas c vezes, atravs da reduao do escopo de cada verso. Em conseqncia, e c a ue deve-se distinguir entre o que desejvel e realmente necessrio de um e a a conjunto identicado de requisitos do sistema. Acrescente o fato de que alguns requisitos, quando modicados, podem passar a ser realizveis a atravs do emprego de um ou mais componentes de prateleira. e
3.4
Pessoas
Projetos de software envolvem, geralmente, um conjunto de pessoas. Cada participante pode ser classicado ou, em determinado instante da realizaao do projeto, identicado como pertencente a uma das categorias c abaixo: Gerente. Pessoa responsvel pelo planejamento, acompanhamento e a controle das atividades realizadas pelos praticantes. Praticante. Pessoa de habilidade tcnica necessria a consecuao das e a ` c tarefas planejadas pelo gerente. Cliente. Aquele que geralmente a principal fonte de requisitos. e
30
SECAO 3.4
Pessoas
O que stakeholders desejam e Stakeholder Motivao ca Cliente gera mudana para obter c benef cio Usurio a introduz mudanas c m nimas Gerente Executa projeto com os recursos dispon veis Analista Especica requisitos Desenvolvedor Gera o sistema com excelncia tcnica, usa as e e ultimas tecnologias SQA Assegurar que padres de o processo e produto so sea guidos
o que oferecem Experincia e estratgias de negcio e o processo do negcio, procedio mentos de operaao c gerncia de projeto, processo e de software mtodos e ferramentas da ER e tecnologias recentes, mtodos e de projeto, ambientes de programaao e linguagens c Processo de software, mtodos e padres e o
Tabela 3.1: Adaptado de [16]. Analista, Desenvolvedor e SQA so praticana tes. Usurio. Pessoa que interage com o software. a Independente da classicaao acima, h outro termo comumente emprec a gado para identicar aqueles que so beneciados pela execuao satisfatria a c o do projeto de software: stakeholder.
Stakeholder indiv duo ou organizaao que est ativamente envolvido em um c a projeto de software cujos interesses o projeto afeta. Pode incluir clientes, usurios, gerentes de projeto, analistas, desenvolvedores a e pessoal de controle de qualidade [16].
31
Anlise orientada a objetos a

A ind stria faz uso extensivo de mtodos que desenvolvedores acrediu e tam ou imaginam ser modernos como, por exemplo, a Anlise Orientada a a Objetos (AOO). A AOO um meio efetivo para descrever entidades no e mundo real e as respectivas interaoes. Contudo, para documentar o comc portamento externo de um sistema como uma caixa preta, ou seja, registrar os requisitos, a efetividade desta abordagem ainda no foi demonstrada [17]. a Projetos que se baseiam na AOO para a engenharia de requisitos provavelmente aumentam as respectivas probabilidades de falhas [18]. Em [13] uma opinio similar tambm questiona o emprego da AOO como mecanismo de a e registro de requisitos e ressalta os benef cios desta abordagem para a anlise a do problema. Na AOO, o analista decompe o problema em um conjunto de objetos que o interagem entre eles. Estes objetos so identicados conforme as entidades a existentes no dom nio do problema. Os relacionamentos entre os objetos so expressos atravs de trocas de mensagens, ou seja, um objeto envia a e uma mensagem a outro objeto requisitando um servio ou reagindo a uma c mensagem. Os relacionamentos estticos entre as entidades do dom a nio do problema so capturadas atravs dos conceitos de classicaao, agregaao, a e c c composiao e associaao. c c A modelagem do dom nio ajuda a separar requisitos do projeto correspondente. Quando objetos e os respectivos relacionamentos modelam entidades e relacionamentos do problema, aqueles se tornam compreens veis pelo cliente e especialistas do dom nio, o que facilita a compreenso dos a requisitos logo no in cio. Apesar dos benef cios, muitas discusses questionam o emprego da AOO o 32
Na AOO, modelamos o mundo pela identicao de ca classes e objetos que formam o vocabulrio a do dom nio do problema. Grady Booch
para a Especicaao de Requisitos de Software (ERS). Neste texto, AOO c e uma tcnica empregada para auxiliar a atividade de anlise do problema (Fie a gura 1.2). O modelo resultante, o modelo de dom nio, util a compreenso e ` a e modelagem do problema, itens importantes para a execuao satisfatria c o da engenharia de requisitos, embora no sejam considerados elementos de a uma ERS. A ERS est para a aplicaao (software) assim como o modelo de a c dom nio est para o problema correspondente. a
33
Problema e soluo ca
Pode-se, por convenincia, identicar a existncia de dois dom e e nios distintos, que empregam terminologias e perspectivas distintas: o dom nio do problema e o dom nio da soluao. c
Satisfao de requisitos
Mundo do cliente
Mundo do software
Problema
Necessidades
Soluo
Figura 5.1: A perspectiva do cliente (dom do problema) e a perspectiva da soluo nio ca

(dom nio da soluo) so distintas. Software parte do dom ca a e nio da soluo. Ao ca longo do tempo, vrias iteraoes ocorrem entre estes dois dom a c nios, principalmente em decorrncia das mudanas das necessidades dos clientes. e c
5.1
Essncia da AOO: e decomposio do ca problema em objetos.
Dom nio do problema

O dom nio de um problema pode ser descrito da perspectiva do paradigma de objetos. Este dom nio pode ser decomposto em classes conceituais ou objetos. Esta observaao do dom c nio do problema da perspectiva do paradigma de objetos recebe o nome de anlise orientada a objetos. Indea pendente da perspectiva, contudo, o relevante que a anlise deste dom e a nio facilita a descoberta de problemas a espera de soluoes. c 34
SECAO 5.1
Dom nio do problema
Em um escola, por exemplo,seriam detectados professores, aulas, alunos, notas e disciplinas. Se o contexto um parque de diverses, ento os e o a elementos provavelmente identicados seriam ingressos, crianas, adultos, c brinquedos, lanches e palhaos. Em um ambiente de editoraao de texto, as c c coisas de interesse so t a tulos, pargrafos, linhas, pginas e ilustraoes. a a c Ao observar estes elementos fcil distinguir associaoes entre eles. Por e a c exemplo, professores ministram disciplinas, adultos compram ingressos e um texto consiste em pargrafos. Pode-se inclusive identicar atividades realia zadas por eles. Por exemplo, professores registram o conte do apresentado u em suas aulas; ao nal de um dia no parque, adultos conferem a validade dos ingressos remanescentes e, durante a editoraao de um texto, pargrafos c a so formatados de vrias maneiras at que um resultado apropriado ena a e e contrado. Adultos cam inconformados com a lentido de las para a aquisiao de a c ingressos em muitos parques de diverso. Em geral, as las so espec a a cas conforme o brinquedo em questo e, em pouco tempo, tem-se que decidir a quais os brinquedos e quantas vezes ser utilizado. Este processo suscet a e vel a falhas e, invariavelmente, a la deve ser o destino de mais tempo da sua vida para trocar ingressos ou devolver aqueles que no sero utilizados. a a Este problema parece sugerir um software de compra pela Internet onde um carto impresso daria entrada a qualquer brinquedo at o saldo dispon a e vel. Aquele no utilizado seria devolvido ao comprador aps o relato, tambm a o e poss de ser feito via Internet. vel Compreender o problema, seus elementos e as relaoes entre estes navec e gar pelo dom nio do problema. Signica interaao efetiva com os usurios e c a exige bem mais do que uma simples reunio de poucos minutos. O pargrafo a a anterior apenas ilustra, de forma simplicada, o que se conhece por anlise a do problema. A ilustraao emprega a l c ngua portuguesa como instrumento de registro. Se o dom nio no conhecido, ento todo um esforo ter de a e a c a ser despendido para denir as necessidades dos clientes. Isto obvio, mas e muitas vezes negligenciado.
5.1.1
Necessidades
Conhecer o dom nio do problema em questo imprescind a e vel no processo de elaboraao de uma soluao correspondente. Esta dependncia dec c e corre da obrigatoriedade de se identicar as necessidades dos clientes. No a h como obt-las se o dom a e nio do problema no conhecido. A Figura 5.2 a e ilustra o mundo do cliente e indica que, deste mundo, surgem as necessidades, que so resultantes do contato do cliente com o mundo que o cerca. a
35
CAP ITULO 5
Problema e soluo ca
Necessidade: uma reexo acerca do problema de pessoal ou operacional do a negcio que deve ser considerada para justicar a compra ou o utilizaao de um novo sistema [23]. c
O que signica uma necessidade real? Um software para auxiliar o professor com o registro das aulas que ministrou pode no ser de interesse real a do professor nem mesmo da escola, se a diculdade exposta decorrente e de indisciplina do professor. Portanto, a real necessidade pode no ser um a software, mas uma mudana de postura do corpo docente. c
Mundo do cliente
Eu preciso:
1. Rpida ... 2. Fcil ... 3. Conexo com ... 4. Calcular ... 5. Listar produtos ... ...
Anlise do Problema
Problema
Necessidades
Figura 5.2: Da anlise do problema so localizadas as necessidades dos clientes, ou a a seja, elementos do dom do problema. As necessidades no fazem parte do dom nio a nio da soluo. ca O exemplo acima ilustra uma falsa necessidade, enquanto, eliminar a insatisfaao dos usurios do parque de diverses em relaao a compra, a c a o c ` ` ` troca e a devoluao de ingressos uma necessidade genu dos clientes. A ` c e na semelhana deste exemplo, aumentar a ecincia da escolha de um leiaute c e apropriado para as edioes de um jornal uma necessidade leg c e tima. Entenda ecincia como menor tempo gasto (quantidade) e melhor resultado e (qualidade). Convm ressaltar que o leiaute tem implicaoes no resultado do e c trabalho de vrios jornalistas que, muitas vezes, se vem obrigados a alterar a e os respectivos textos para adequ-los ao espao dispon a c vel. Necessidades so itens associados ao dom a nio do problema. No denem a uma soluao, mas fornecem uma perspectiva acerca do que uma soluao c c vivel deveria realizar. a
5.2
Dom nio da soluo ca

A anlise de um problema melhora a compreenso do contexto cona a siderado e elucida as necessidades pertinentes atividades realizadas no dom nio do problema. Com estas informaoes est-se preparado para uma c a incurso no dom a nio da soluao. Elementos do dom c nio da soluao incluem: c atividades (deniao do sistema, projeto, implementaao), objetos a serem c c
36
SECAO 5.2
Dom nio da soluo ca
utilizados na soluao (computadores, redes, dispositivos espec c cos) e artefatos produzidos (cdigo, descrioes de casos de uso, diagramas de classe e o c outros). Um modelo pragmtico e enxuto a ser empregado como orientaao para a c denir uma soluao para um dado problema, ou seja, a deniao de um c c sistema, a essncia deste texto. e e
5.2.1
Caracter sticas
A investigaao de uma soluao para um problema d origem a caracc c a tersticas de um software. Uma caracter stica localiza-se entre uma necessidade real e uma descriao detalhada de como um software realiza esta c necessidade. A esta descriao detalhada d-se o nome de requisito de softc a ware.
Caracter stica: um comportamento ou um atributo desejado para um sistema.
Domnio do Problema
N1 N2 ... nk
Necessidades
Figura 5.3: O dom do problema contm necessidades, que sugerem caracter nio e sticas (dom da soluo) a serem realizadas pelos requisitos de software correspondentes. nio ca Uma necessidade satisfeita por pelo menos uma caracter e stica. Cada caracter stica e renada em um ou mais requisitos de software. Convm ressaltar que conjuntos distintos e de requisitos podem satisfazer um mesmo conjunto de caracter sticas, da mesma forma que conjuntos distintos de caracter sticas podem satisfazer as mesmas necessidades. As caracter sticas e os requisitos de software fazem parte do dom nio da soluao, enquanto as necessidades fazem parte do dom c nio do problema. As necessidades esto associadas ao problema, elas so derivadas dos problemas. a a As caracter sticas so servios que o sistema fornece para a realizaao de uma a c c ou mais necessidades. Clientes geralmente fazem emprego de caracter sticas durante o processo de eliciaao dos requisitos ao se referir a soluao [24]. Nem descrevem suas c ` c
Domnio da Soluo
C1 C2 ... Cl
Caractersticas
R1 R2 R4 R4 ... Ru
Requisitos de Software
R3
37
CAP ITULO 5
Problema e soluo ca
necessidades nem os requisitos de software. Quando entrevistados, dizem que o sistema dever fazer uso de uma interface grca para emisso de nota a a a scal, por exemplo, o que uma caracter e stica. No fazem referncia a uma a e necessidade real, por exemplo, atendimento mais eciente do cliente. No a fazem referncia a um requisito real de software, por exemplo, reduao do e c tempo de transaao de emisso de nota scal para 60% do tempo consumido c a atualmente. Para ilustrar o relacionamento exposto na Figura 5.3. Observe o dom nio automobil stico, por exemplo. Usurios, em geral, desejam carros com vidro a eltrico e transmisso automtica, que so caracter e a a a sticas. A necessidade real associada a elas conforto e comodidade. Se para o cliente vidro eltrico e e e transmisso automtica so caracter a a a sticas que atendem as necessidades de conforto e comodidade, para o projetista, so requisitos vagos. Anal, a qual seria o tamanho do vidro? Qual a velocidade com que o vidro fecha? Qual a fora a ser exercida para tal? (Alguns pa exigem que esta presso c ses a no seja suciente para causar danos em crianas.) Qual o consumo mximo a c a de energia? Para a transmisso ainda h detalhes bem mais elaborados que a a os amantes dos automveis podero explicar por horas. o a Em geral, no se deveria escrever cdigo de vagas descrioes (caraca o c ter sticas). Caracter sticas auxiliam na comunicaao com os clientes em um c alto n de abstraao. Entretanto, para a posterior atividade de projeto, vel c e necessrio expressar estas caracter a sticas em mais detalhes, em um ou mais requisitos de software. Caracter sticas podem ser conitantes. Por exemplo, o cliente pode fazer referncia a um melhor tempo de processamento de uma transaao realizada e c pelos usurios e, ao mesmo tempo, sugerir que a interface grca seja fcil a a a de usar e aprender. Nestes casos, observe, no so fornecidas necessidades a a reais, mas interpretaoes de menor tempo de atendimento do cliente e c menor custo de treinamento dos usurios, respectivamente. a
5.3
Compreendendo os dom nios

O problema desempenha um papel importante na engenharia de requisitos, que deve caracterizar, do ponto de vista do comportamento externo, uma soluao. Esta soluao um software, cujos objetivos s podem ser c c e o encontrados fora do prprio software e, em conseqncia, no dom o ue nio do problema. No se pode encontrar os objetivos de um software de correio a eletrnico no prprio software, mas no ambiente em que empregado. Ao o o e analisar o contexto do cliente, observa-se problemas de comunicaao, que c dicultam a troca eciente de informaoes entre entidades do dom c nio do cliente. Portanto, o problema a diculdade de comunicaao e a necessidade e c correspondente facilitar a comunicaao. e c
Identicar caracter sticas exige conhecimento do dom nio do problema, que alvo da e atividade de anlise a do problema.
38
SECAO 5.3
Compreendendo os dom nios
Este problema deve ser analisado e desta anlise devem surgir vrias a a caracter sticas que a soluao, denominada de software de correio eletrnico, c o dever apresentar. Por exemplo, facilidade de utilizar o futuro software a provavelmente ser uma caracter a stica desejada. Esta facilidade no exaa e tamente um requisito de software, mas uma caracter stica que o produto dever apresentar. a A diculdade de comunicaao faz emergir nos clientes, uma necessidade: c facilitar esta comunicaao. Desta necessidade surgem caracter c sticas que a soluao dever apresentar, por exemplo: facilidade de uso do software; c a visualizar foto do destinatrio; localizaao do destinatrio sobre um mapa a c a da empresa e muitas outras. Estas caracter sticas so fornecidas pelos clia entes, na linguagem que eles empregam e, portanto, devem ser renadas para que requisitos mais espec cos do software sejam identicados. Para estas caracter sticas, respectivamente, os seguintes requisitos so plaus a veis: tempo de treinamento reduzido; as informaoes pertinentes a cada usurio c a do software inclui foto de tamanho X e Y cores por pixel; a identicaao c do destinatrio de uma mensagem dever incluir a localizaao geogrca do a a c a mesmo conforme a planta da empresa e muitos outros.
39
Requisitos de software
6.1
O que um requisito? e
Requisitos atendem caracter sticas, que so as respostas as necessidades a ` reais dos usurios. H uma dependncia natural entre estes elementos: nea a e cessidades conduzem a caracter sticas e estas, por sua vez, so renadas em a requisitos. Um requisito um recurso a ser oferecido por um sistema. O e conjunto de requisitos de um sistema descreve o que esse dever fazer. a
Requisito: alguma coisa que uma aplicaao deve fazer pelos usurios. E uma c a funao que o sistema deve fornecer com o propsito de justicar c o a sua existncia [21]. e
Tambm comum a deniao de requisito como uma capacidade ou e e c recurso necessitado por um usurio para resolver um problema. Da anlise a a do problema so identicadas as necessidades dos clientes e uma melhor a compreenso do problemas Destes pode-se iniciar a deniao de uma viso a c a de alto n vel da soluao registrada atravs de caracter c e sticas. Requisito e uma verso detalhada de uma caracter a stica. Vrios requisitos podem ser a originados de uma unica caracter stica. Por exemplo, para a caracter stica emisso de mala direta para os clientes vrios requisitos correspondentes a a so estabelecidos: cadastrar e atualizar dados dos clientes so alguns deles. a a Neste caso, para ilustrar, a necessidade correspondente poderia ser manter o cliente informado de promooes, por exemplo. c 40
SECAO 6.2
Onde procurar por requisitos?
6.2
Onde procurar por requisitos?

E comum os requisitos serem tratados como elementos funcionais de um sistema, ou seja, a forma como o sistema se comporta. Nestes casos, eles so descritos da perspectiva da interaao entre o usurio e o sistema. Por a c a exemplo, o usurio requisita impresso de relatrio, o sistema exibe todos a a o os tipos poss veis de relatrio ... e assim por diante. Requisitos funcionais, o contudo, no so sucientes para descrever sistemas de informaao, conforme a a c a Figura 6.1.
Descrio de um Sistema de Informao

Entradas Sadas Ambiente computacional
Sistema operacional, ...
Funes
Atributos do sistema
Desempenho, confiabilidade, ...
Figura 6.1: Para descrever um sistema vrias informaoes so necessrias alm das a c a a e relevantes entradas e sa das. As funoes, o ambiente computacional e os atributos do c sistema, juntamente com as anteriores formam um conjunto dos elementos necessrios a e sucientes para descrio de um software. ca Alan Davis [8] identica cinco classes necessrias para descrever um sisa tema: entradas, sa das, funoes (o mapeamento de entradas em sa c das), atributos do sistema (conabilidade, desempenho, manutenibilidade e outras) e atributos do ambiente onde o sistema estar inserido (sistema operacional, a protocolos de comunicaao, capacidades suscet c veis de serem realizadas e outras). Esta classicaao orienta o que se deve registrar em uma ERS. Ainda c auxilia a identicar o que e o que no um requisito. e a e Estas informaoes podem ser obtidas de vrias fontes: c a Uma especicaao de requisitos de sistema, preparada por um engec nheiro de sistemas, descreve o conjunto de todos os requisitos de um sistema. Parte destes requisitos sero satisfeitos por um software. a
41
CAP ITULO 6
O documento ConOps (xxx) um documento que registra necessidades e e expectativas operacionais de um sistema. Observaoes do sistema em uso pelos stakeholders. c Entrevistas com os clientes e usurios durante a eliciaao de requisitos. a c Documentaao dispon do sistema corrente. c vel Estudos de viabilidade. Modelos e prottipos do sistema. o
6.3
Classicao ca
A classicaao apresentada na seao anterior auxilia a identicar fontes c c de requisitos. Uma outra, contudo, geralmente empregada para registrar e informaoes em uma ERS (Figura 6.2). c Requisitos podem ser divididos em requisitos de software e restrioes c de projeto. Requisitos de software so subdivididos em requisitos funcioa nais e no funcionais. Os no funcionais ainda so agrupados naqueles de a a a usabilidade, conabilidade, desempenho e manutenibilidade.
<<requisito>> Requisito Linux Conectiva Linguagem Java
Casos de uso
<<requisito>> Requisito de Software
<<requisito>> Restrio de Projeto
<<requisito>> Funcional
<<requisito>> No funcional
Treinamento de 2h de 20% dos recursos (os principais)
<<requisito>> Manutenibilidade
<<requisito>> Confiabilidade
<<requisito>> Desempenho
<<requisito>> Usabilidade
Figura 6.2: Uma classicao de requisitos amplamente utilizada descrita atravs de ca e um diagrama de classe da UML. Segundo esta classicao, os requisitos no funcioca a nais so renados em Usabilidade, Conabilidade, Desempenho ou Manutenibilidade. a Qualquer requisito que no entre nesta classicao Funcional ou se trata de uma a ca e Restrio de Projeto. ca
42
SECAO 6.4
O que no um requisito? a e
Um requisito funcional envolve entradas, sa das e funoes (Figura 6.1). c O conjunto deles descrevem como o sistema deve se comportar quando determinadas entradas so fornecidas. a Um requisito no funcional expressa atributos do sistema (Figura 6.1). a Usabilidade refere-se a facilidade de operaao e aprendizagem correspon` c dente. Pode ser descrito atravs de tempo de treinamento para um usurio e a tornar-se prociente; atravs de tempo mdio para consecuao de uma data e e c tarefa; pela presena de caracter c sticas como dica (tool tip), assistente (wizard) e outras; pela observaao de padres disponibilizados pela ind stria c o u acerca da apresentaao e comportamento (look and feel). Conabilidade c designa at que ponto o sistema manter-se- em funcionamento conforme e a expectativas dos usurios. Tempo mdio entre falhas e tempo mdio para a e e reparar so alguns dos instrumentos utilizados para descrever requisitos no a a funcionais deste tipo. Desempenho cobre requisitos como tempo de resposta para uma transaao (tempo mdio e mximo), quantidade de transaoes por c e a c unidade de tempo, n mero de usurios simultneos que o sistema pode atenu a a der e modo de operaao quando o sistema encontra-se com sobrecarga de c servios. Manutenibilidade refere-se a facilidade de modicaao de um softc ` c ware ou habilidade para acomodar futuros melhoramentos. Uma restriao de projeto impe alguma limitaao no projeto do sistema c o c ou no processo de software a ser empregado. A instituiao na qual o sisc tema ser implantado pode exigir o emprego do PostgreSQL 1 ou Firebird2 a para armazenamento de dados, ou o emprego da linguagem de programaao c Java, por exemplo. Naturalmente, quanto mais requisitos deste tipo forem fornecidos, menos liberdade os projetistas tero durante a realizaao de a c suas atividades, o que pode repercutir na implementaao de outros requic sitos. Por exemplo, para o requisito o sistema deve ser executado tanto em ambiente Linux quanto Windows, classicado como uma restriao de c projeto, vrios outros requisitos podem ser afetados. a O conjunto de requisitos de um sistema deve cobrir as entradas, sa das, funoes, atributos do sistema e atributos do ambiente que hospedar o sisc a tema (Figura 6.1). Nem sempre, contudo, simples discenir entre o que e e parte ou no desta classicaao. Em geral, o resultado tratar informaoes a c e c que no fazem parte dos requisitos como requisitos e, inversamente, omitir a requisitos reais.
6.4
O que no um requisito? a e
Projeto a atividade do processo de software que recebe como insumo e uma especicaao de requisitos de software. Esta especicaao comentada c c e
1 2
Veja http://www.postgresql.org. Veja http://firebird.sourceforge.net.
43
CAP ITULO 6
na seao seguinte. Decises de projeto no deveriam fazer parte desta esc o a pecicaao ou, caso contrrio, engenheiros de requisitos estariam realizando c a tarefas de projetistas de software. Tais tarefas exigem habilidades e consideraoes distintas daquelas comentadas neste texto. Cuidado, portanto, c para no tratar decises de projeto como requisitos. Por exemplo, um rea o quisito pode identicar a necessidade de troca de documentos via Internet e, sem necessidade, estabelecer que o formato de troca PDF. 3 Claramente, e estabelecer PDF ou outro formato como aquele nos quais os documentos devero ser processados uma deciso de projeto, que dever considerar a e a a outras questes. o Estas decises de projeto podem at reetir preferncias do analista de o e e sistemas, contudo, no so relevantes para denir o comportamento externo a a do sistema e devem ser evitadas. Requisitos denem o que o sistema deve fazer, nada mais. Projeto descreve como o sistema atender os requisitos. a Esta separaao clara, contudo, deve ser compreendida no contexto de um c processo iterativo, veja seao 3 (pgina 26), no qual atividades de anlise c a a so intercaladas com aquelas de projeto. a Outras informaoes. Cronogramas, plano de mitigaao de riscos e outras c c de gerncia de projeto como plano de gerncia de conFiguraao, no fazem e e c a parte dos requisitos. Requisitos denem o que o software supostamente deve fazer e, portanto, uma restriao de recurso ou datas podem aumentar c a volatilidade dos requisitos ao considerar questes importantes, mas que o devem fazer parte de outros artefatos.
6.5
Documentos
O analista de sistema responsvel por vrios artefatos: e a a Casos de Uso (diagramas e as respectivas descrioes) c Documento Viso a Especicaao Suplementar (ES) c Especicaao de Requisitos de Software (ERS) c Modelo de Dom nio Uma ERS contm os requisitos funcionais, no funcionais e as restrioes e a c de projeto. No confunda restrioes com decises de projeto. As ultimas a c o so resultantes da execuao da atividade de projeto, enquanto as restrioes a c c so imposioes as quais os projetistas tero que satisfazer. a c ` a
Acrnimo de Portable Document Format. Este formato amplamente utilizado na o e troca de informaoes baseadas em documentos pela Internet. Veja www.adobe.com para c detalhes.
3
44
SECAO 6.5
Documentos
Casos de Uso
Viso
Problema, usurios, necessidades e caractersticas
ERS
Caso de uso A Caso de uso C
<<include>> Ator Caso de uso B
ES
Especificao Suplementar
MD
Modelagem de Domnio
Descrio UC
Fluxo bsico: 1. O usurio ... 2. O sistema ... Fluxo alternativo: 1. ...
Figura 6.3: Documentos de responsabilidade do analista de sistema. Observe que a

ERS, um dossi, compreende os diagramas de casos de uso, a descrio dos casos de e ca uso e os requisitos no funcionais, descritos no documento Especicao Suplementar a ca (ES).
Especicao de Requisitos de Software (ERS): ca documento (ou dossi) que descreve todos os requisitos de um e sistema
Conforme a deniao acima, o conte do de uma ERS deve contemplar c u todos os elementos da Figura 6.1 (pgina 41). Parte signicativa do registro a destes requisitos baseia-se no emprego de linguagem natural. As descrioes c de casos de uso um exemplo. Requisitos no funcionais tambm so dese a e a critos essencialmente atravs de especicaoes em linguagem natural (ou e c portugus). Estes outros requisitos fazem parte da ERS, mas so descrie a tos em documento prprio denominado de Especicaao Suplementar, ou o c ES por simplicidade. A Figura 6.3 ilustra o relacionamento entre estes documentos. Conforme a Figura 6.3, os documentos ali referenciados no incluem as a necessidades dos clientes e as caracter sticas da soluao. Esses no fazem c a parte de uma ERS, mas de outro documento, denominado de Viso. O docua mento Viso descreve os usurios do sistema, o mercado alvo, o problema, as a a necessidades decorrentes, e as caracter sticas de uma soluao. Uma ERS no c a contm tais informaoes, mas detalhes sucientes para a posterior atividade e c de projeto. Funcionalmente, uma ERS depende do conte do do documento u Viso correspondente. A Figura 6.5 ilustra esta dependncia. a e Convm ressaltar que as caracter e sticas contidas em um documento Viso a so simples descrioes de um comportamento desejado para uma sistema. a c So requisitos de software, mas em um alto n de abstraao, os so fornea vel c a
45
CAP ITULO 6
Especificao de Requisitos de Software (ERS)
Casos de Uso
Caso de uso A Caso de uso C
Descrio UC
Fluxo bsico: 1. O usurio ... 2. O sistema ... Fluxo alternativo: 1. ...
ES
Especificao Suplementar
<<include>> Ator Caso de uso B
Diagramas
Descries dos Casos de Uso
Requisitos no funcionais e restries de projeto
Figura 6.4: Parte dos artefatos produzidos pela execuo das atividades da engenharia ca de requisitos. Aqueles exibidos recebem o nome de Especicao de Requisitos de ca Software (ERS). O contedo de uma ERS inclui requisitos funcionais, no funcionais u a e restrioes de projeto. Os dois ultimos geralmente esto contidos em documento c a denominado de Especicao Suplementar (ES). Este documento em conjunto com ca os diagramas de casos de uso, as especicaoes correspondentes e outros documentos c usados formam uma ERS.
Viso
Problema, usurios, necessidades e caractersticas
Insumos
ERS
Figura 6.5: Uma ERS descreve uma soluo com preciso suciente para ser comca a preendida tanto pelos stokeholders quanto por projetistas. A produo de uma ERS ca baseia-se nas necessidades dos clientes e nas caracter sticas ou requisitos de alto n vel obtidos. As necessidades e as caracter sticas so agrupadas em um documento chamado a de Viso. a cidos em uma ERS. Antes de iniciar o desenvolvimento de uma ERS, deve-se conhecer o que qualica ou no este documento, assunto da seao seguinte. a c
6.6
Qualidades desejveis em uma ERS a

Uma ERS deve satisfazer atributos qualitativos para o sucesso do desenvolvimento de um software, ao mesmo tempo que uma ruim suciente e para o fracasso. Em um determinado instante de tempo tem-se uma verso a da ERS conforme os resultados produzidos pelas atividades correspondentes (Figura 3.2, pgina 27). Uma forma de mensurar a qualidade da realizaao a c destas atividades e, dessa forma, obter um grau de conana nos requisitos c
46
SECAO 6.6
Qualidades desejveis em uma ERS a
produzidos investigar a prpria ERS. e o A atividade de validaao (veja Figura 3.3, pgina 28) responsvel pela c a e a anlise da ERS. Embora no seja fcil produzir uma boa documentaao a a a c dos requisitos de um sistema, nem mesmo estabelecer um caminho seguro para que possa ser obtida, as propriedades desejveis so bem conhecidas. a a Um conjunto delas apresentado abaixo. So uteis para nortear decises e a o tanto dos analistas quanto por aqueles envolvidos na deniao de tcnicas a c e serem empregadas pelos primeiros. Observe que as caracter sticas desejadas so compat a veis com o que sugere o padro ISO 12207.1 [1], que trata dos a dados produzidos ao longo da execuao de um processo de software. c Completa Uma ERS deve conter toda e apenas a informaao necessria para que c a o software correspondente seja produzido. Qualquer implementaao c que satisfaz todos os requisitos da especicaao um produto aceitvel. 4 c e a Durante a realizaao das atividades da engenharia de requisitos, coc e mum a existncia de requisitos cujos detalhes so desconhecidos e que e a s podero ser obtidos posteriormente, aps o in o a o cio das atividades de projeto. Esses requisitos devem ser explicitamente identicados. A seao 3.2, pgina 28, fornece informaoes sobre a inevitvel interc a c a calaao entre especicaao de requisitos e projeto. c c Independente de implementaao c A ERS deve estar livre de questes de projeto e/ou implementaao. o c A exceao s deve ser admitida quando se tratar de um requisito real c o que, neste caso, classica-se como uma restriao de projeto (veja Fic gura 6.2, pgina 42). Convm ressaltar que, a deniao de requisito a e c contempla tanto recursos que devem estar presentes no futuro software para resolver um problem ou atingir um objetivo quanto para satisfazer um contrato, uma especicaao, um padro, um regulamento c a ou outra restriao a ser imposta. A exigncia de que a linguagem de c e programaao deve ser Java, por exemplo, uma t c e pica deciso de proa jeto que deve, d perspectiva de uma empresa que est comprometida a a com esta linguagem, ser tratada como um requisito, uma restriao de c projeto. Consistente e no amb a gua Se a ERS contm ambig idades, ento no ser poss ou validar o e u a a a vel conte do com o cliente ou vericar se o software correto foi produzido. u Todo requisito deve possuir apenas uma interpretaao e o conjunto c deles no pode ser conitante. a
Para cada ERS pode ser denido um conjunto de soluoes que atendem os requisitos c contidos neste documento. Naturalmente, entre elas tero diferenas de desempenho e a c facilidade de manutenao, entre outras. Todas, contudo, devem satisfazer a ERS. c
4
47
CAP ITULO 6
Precisa A ERS deve registrar precisamente o comportamento esperado. Para cada sa deve estar denido o conjunto aceitvel de entradas corresda a pondente. Para cada entrada deve estar denido o conjunto aceitvel a de sa das correspondente. Vericvel a Um requisito vericvel se poss determinar se este satisfeito e a e vel e pela implementaao correspondente ou no. Todo requisito que no c a a vericvel deve ser removido da ERS. Se no poss e a a e vel vericar se um requisito satisfeito, a ausncia deste provavelmente no ser e e a a detectada. Modicvel a A ERS deve facilitar as inevitveis mudanas. Um boa organizaao a c c deste documento pode facilitar, enquanto tambm no existem d vidas e a u de uma organizaao inadequada pode dicultar consideravelmente. c Intelig vel Desenvolvedores devem compreender o problema que os clientes esto a tentando resolver e os requisitos registrados na soluao apresentada c pelos engenheiros de requisitos. Em conseqncia, a ERS deve ser ue entendida tanto pelos clientes quanto por desenvolvedores. Organizada para referncia e reviso posteriores e a A ERS um dos principais produtos das atividades da engenharia e de software e, se for o caso, aquele empregado em uma disputa judicial com o cliente. A organizaao deste documento deveria facilitar a c localizaao rpida de questo associada aos requisitos. c a a Rastrevel a Uma ERS contm informaoes cuja origem e conseqncias devem ser e c ue de fcil determinaao. a c
48
Resumo
A necessidade de uma engenharia de requisitos bem feita foi devidamente justicada pelo signicativo impacto no sucesso e fracasso de um sistema de informaao. A nalidade da engenharia de requisitos produzir um c e documento conhecido por Especicaao de Requisitos de Software (ERS). O c conte do deste documento envolve consideraoes de dois dom u c nios distintos: o dom nio do problema e o dom nio da soluao. c Do problema imprescind uma clara compreenso, da qual emergem e vel a as necessidades do cliente. O acesso as necessidades e ao dom ` nio do problema permitir, atravs de um processo no trivial, eliciar os requisitos, a e a registrados de forma intermediria em caracter a sticas que a soluao dever c a apresentar e, de forma mais detalhada e compat vel com as perspectivas futuras de desenvolvimento, requisitos de software. Todas estas informaoes, produzidas ao longo de um processo iterativo, c so organizadas em documentos. A ERS um dos principais, contudo, a a e descriao dos requisitos, cuja deniao benecia-se de outros dois documenc c tos: Viso e Modelo de Dom a nio. Os requisitos propriamente ditos esto a organizados em dois artefatos que fazem parte da ERS: Casos de Uso e Especicaao Suplementar. c Os documentos acima compreendem uma organizaao conceitual. Fic sicamente, cada um destes documentos podem estar dispersos por vrios a arquivos, nos mais variados formatos. O inverso tambm pode ocorrer, ou e seja, um arquivo f sico em html, por exemplo, pode conter toda a ERS.
49
Parte II
Tecnologias
50
Requisitos no so coisas l fora, voando como borboletas, assim a a a como no trabalho do analista encontrar alguma rede apropriada para a e captur-las. Requisitos emergem de interaoes sociais entre os usurios a c a e o analista. Siddiqi & Shekaran [29]
As ferramentas do analista
A parte anterior deniu requisito, ofereceu uma viso abrangente das a atividades do analista de sistemas e da area correspondente, a engenharia de requisitos. Em particular, mostrou o signicativo impacto destas atividades no sucesso de um sistema de informaao. c Nesta parte, o objetivo apresentar os mecanismos necessrios para uma e a anlise de sistema eciente: (a) uma tcnica para eliciaao de requisitos, (b) a e c uma linguagem de modelagem e (c) um processo que os integre. Isto pode sugerir a existncia de um melhor conjunto de mecanismos, e o que no faz sentido. Observe que uma tcnica de eliciaao suscet ao a e c e vel cenrio onde empregada, donde decorre que no existe uma melhor, mas a e a uma mais apropriada do que outra conforme o cenrio. O mesmo verdade a e para os demais itens. Torna-se claro, portanto, que os itens (a), (b) e (c) s o fazem sentido em um contexto (delineado no Cap tulo 9). A literatura sobre o assunto e a quantidade de propostas so extensas. a Muitas delas j foram desaprovadas por experincias e muitas outras no a e a so amplamente utilizadas ou no mostraram evidncias de benef a a e cios que propalam oferecer. Deste conjunto de possibilidades, apenas as mais promissoras e compat veis com o contexto denido foram consideradas. Se a anlise de sistemas deve ser agil, ento ter que se basear em ferramentas a a a que tm demonstrado resultados positivos, que efetivamente empregada e e e permite uso imediato com custos relativamente baixos.
51
A agua molda o seu curso de acordo com o solo. A Arte da Guerra Sun Tzu
Contexto de referncia e
Todo mtodo, ferramenta ou outro elemento produzido pelo homem pose sui um alvo. Supostamente este alvo beneciado pela proposta apresene tada. Neste livro, a proposta a anlise agil de sistemas de informaao. E o e a c alvo? Anal, quais sistemas de informaao? Bem, isto o que este cap c e tulo responde e dene como contexto de referncia. e Se o contexto abrangente, ento todo um conjunto de tcnicas e linguae a e gens, provavelmente, o mais apropriado. Em casos assim, mtodos tambm e e e devem ser gerais, muitas vezes bem mais amplos do que os leitores gostariam ou considerariam uteis em face dos problemas rotineiros que enfrentam. Por outro lado, quanto mais restrito o contexto, mais espec cas podem ser as consideraoes, mais uteis podem ser as orientaoes fornecidas, contudo, proc c vavelmente poucos leitores iriam identicar seus problemas rotineiros com o contexto restrito. Este o problema: em um contexto amplo tem-se pouca e orientaao para oferecer aos praticantes, em um contexto restrito apenas a c realidade de poucos considerada. e Pode parecer um problema sem soluao, contudo, em cenrios reais so c a a as circunstncias que ditam o que necessrio e, quase sempre, a equipe a e a envolvida ter que possuir um m a nimo de experincia para adequar o coe nhecimento dos livros a situaao vivenciada. Dado um contexto X, no ` c a e razovel esperar por um livro que aborde extensivamente o contexto X. Com a sorte, algo prximo de X pode ser encontrado. Isto no impede, contudo, o a a caracterizaao de um contexto e a investigaao do que apropriado ao c c e contexto caracterizado. E, sobretudo, a esperana de que o contexto seja c representativo, ou, pelo menos, favorea o leitor nas suas arduas tarefas, c quando ter diculdades espec a cas. 52
SECAO 9.1
Caracterizao ca
9.1
Caracterizao ca
A caracterizaao do contexto no realizada de forma arbitrria. Aquele c a e a aqui denido visa reetir o caso comum, ou mais freq ente. Noutras u palavras, no el a ind strias de software que possuem equipes compostas a e u de dezenas ou mais pessoas, envolvidas em empreendimentos de softwares de milhares de linhas de cdigo. Noutro extremo, equipes formadas por at 2 o e membros podero considerar a abordagem aqui proposta como cerimoniosa, a ou formal em excesso para softwares pequenos, que podem ser confeccionados satisfatoriamente com qualidade e no tempo relativamente curto por equipes deste tamanho. Entre estes extremos residem inumerveis contexa tos. Os itens abaixo, portanto, no esgotam todos eles. Nem razovel a e a supor que se trata de um conjunto de itens que dene, de forma precisa, um contexto. Formam, contudo, contornos reais e baseados em experincias do e autor. Natureza do software produzido. Sistemas cr ticos, capazes de gerar preju zos intolerveis, exigem abordagens distintas daquela aqui a denida. Nestes casos, um rigor bem maior esperado do processo e do que aquele aqui oferecido. Sistemas ditos comerciais so o alvo. a No inclui aqueles cr a ticos, cient cos e aqueles que devem produzir respostas em intervalos restritos de tempo (tempo real), por exemplo. Tamanho da equipe. Equipes numerosas, mesmo que desenvolvendo sistemas comerciais, impem restrioes alm daquelas contempladas o c e pela anlise agil proposta neste texto. No h uma deniao clara do a a a c que seja uma equipe numerosa, nem tampouco este texto se prope a o quantic-las quanto ao n mero de membros. Equipes da ordem de 3 a u a 8 so de tamanho mais adequado a proposta aqui apresentada. No a ` a e dif perceber que equipes de dezenas de pessoas, por exemplo, exigem cil uma maior cerimnia quanto ao processo de eliciaao e registro de o c artefatos que aquela aqui apresentada.
9.2
Investigao do contexto ca
A Seao anterior tratou da demarcaao de contextos poss c c veis onde a abordagem de anlise agil proposta neste trabalho considerada apropriada. a e O objetivo desta seao esclarecer o porqu de algumas caracter c e e sticas desta abordagem. Ao mesmo tempo, esta seao ilustra, em muitos aspectos, como c esta proposta pode ser alterada para contemplar contextos distintos daquele identicado acima ou que possuam peculiaridades no consideradas. a Numero de artefatos. Os artefatos produzidos pela anlise agil a so poucos, veja Seao 6.5, pg. 44. Equipes pequenas envolvidas a c a
53
CAP ITULO 9
Contexto de referncia e
com o desenvolvimento de softwares comerciais tornam prescind veis muitas formalidades de outros cenrios que, em conseqncia, exigem a ue registros de outras informaoes. Convm ressaltar que informaoes de c e c interesse de gerentes de projetos no foram consideradas, embora o a analista, muitas vezes, seja o responsvel pela obtenao delas. Por a c exemplo, o resultado de revises tcnicas com stakeholders no faz o e a parte do conjunto de artefatos.
54
10
Pode-se argumentar que os resultados esperados de um sistema so a vis veis atravs do comportamento que este oferece as entidades externas. e ` Neste caso, h uma necessidade de interaao entre estas entidades externas a c e o sistema. Neste texto, tal comportamento descrito atravs de casos de e e uso, enquanto as entidades externas so os atores. a
Ator
Ator: Entidade externa que interage com o sistema.

Atores no necessariamente so seres humanos. Os usurios que diretaa a a mente interagem com um sistema podem no ser, portanto, os unicos atores. a Para um sistema bancrio, o computador porttil de um cliente pode ser um a a ator. Em uma grande organizaao, na qual coexistem vrios sistemas que c a cooperam entre si, da perspectiva de cada um destes sistemas, os demais com os quais este coopera so atores. A Figura abaixo ilustra outro caso. a Quando um ator representa um usurio humano, a identicaao deste a c e o papel realizado pelo ser humano em questo. Por exemplo, Vendedor um a e ator que representa o papel realizado por vrias pessoas em uma empresa a (cada uma destas pessoas pode realizar outros papis ao interagir com o e mesmo sistema). Em conseqncia, denir Joo da Silva como ator uma ue a e atividade rara, permitida somente quando este particular ser humano for a unica entidade externa com a qual o sistema ir interagir para produzir a algum comportamento. Observe que esta uma situaao excepcional, pois, e c em geral, este ser humano ocupa um cargo e qualquer ser humano, de cargo de mesma envergadura ou superior poder interagir com o sistema para se a 55
Nome do ator
Representao grfica de ator
<<Actor>> Nome do ator
Representao alternativa
CAP ITULO 10
Ator
Marca o tempo
Ator correspondente
Relgio
Gera eventos em intervalos preestabelecidos Inicia casos de uso em certos instantes de tempo
Figura 10.1: Em um sistema que compreende processamento que realizado sem e

interveno humana, todos os dias, e que se inicia logo aps a meia-noite, Relgio o ca o o e ator que dispara a execuo deste processamento. ca
obter o mesmo comportamento. Continuando com este exemplo, Joo da a Silva pode ser o gerente de um banco, responsvel pela abertura eletrnica a o do cofre de um banco. Observe que, embora seja de todo o pessoal da agncia e o unico que possa interagir com o sistema para realizar esta tarefa, o ator Gerente prefer e vel. A Figura abaixo ilustra esta diretriz.
Ator um papel em vez de uma pessoa particular.
Gerente
Joo da Silva
Figura 10.2: Ao identicar atores humanos lembre-se de no particulariz-los desnea a

cessariamente. Quase sempre, o relevante o papel desempenhado por um conjunto de e usurios. Na Figura, mesmo que exista uma unica pessoa que desempenha o papel, esta a poder, quase sempre, ser substitu a da, tornando o ator Gerente bem mais apropriado que o ator Joo da Silva. a
Casos de uso registram a interaao entre o sistema e atores. A Figura 10.4 c mostra dois atores de um suposto sistema envolvendo a venda de produtos. Observe que, neste cenrio, no apenas o vendedor mas tambm o comprador a a e interage com o sistema, visto que so atores. Sistemas que permitem a a venda de produtos pela Internet, por exemplo, tm como atores os prprios e o compradores. Atores so elementos externos ao sistema, ou seja, esto alm a a e das fronteiras de interesse. Sem a existncia de atores no seria poss e a vel explorar os supostos benef cios de um sistema, pois este no teria como se comunicar ou interagir a com entidades externas. Atores podem estar organizados em hierarquias, como aquela abaixo, composta exclusivamente de atores humanos.
56
SECAO 10.1
Como encontrar atores?
Comprador
Vendedor
Figura 10.3: Exemplos de atores, que se comunicam com o sistema.
Secretaria de Programa
Aluno
Administrador
Navegante
Secretaria de Pr-Reitoria
Coordenao de Programa
Usurio
Administrao Superior
Pr-Reitoria
Coordenador de Programa Outro participante
Pr-Reitor Participante Docente
Pesquisador
Figura 10.4: Um conjunto de atores.
10.1
Como encontrar atores?

Algumas perguntas auxiliam na identicaao de atores alm, naturalc e mente, do reconhecimento de que servios oferecidos por um sistema so c a iniciados por atores; atores fornecem servios empregados pelo sistema e c atores recebem informaoes de casos de uso. c Quem ou o qu inicia operaoes do sistema? e c Quem ou o qu interage com o sistema para ajudar nas tarefas realie zadas? H interfaces para a obtenao de informaoes manipuladas pelo sisa c c tema? H conexes com sistema administrativo de contas de usurios ou oua o a tros? H atores j denidos? a a
57
CAP ITULO 10
Ator
H software e/ou hardware que interage com o sistema? a Se um determinado evento ocorre no sistema, ento qual a entidade a externa que deve ser informada?
58
11
Caso de uso
Embora a anlise de sistemas no se resuma ao emprego de uma notaao a a c apropriada, no h d vidas de que a forma empregada para registro desema a u penha um papel importante. Anal, o futuro sistema ter que ser reprea sentado tanto para consulta da equipe de desenvolvimento quanto para a validaao por parte dos usurios. c a H vrias formas de se capturar requisitos funcionais. A principal e ama a plamente empregada faz uso de linguagem natural (portugus, por exemplo). e Caso de uso, tema deste cap tulo, uma forma disciplinada de emprego e de linguagem natural para descrever o comportamento de sistemas de informaao. Convm ressaltar, contudo, que casos de uso, alm de permitir c e e capturar os requisitos, tambm so uteis para direcionar todo o desenvolvie a mento de um software.
11.1
Compreendendo casos de uso

Registrar os requisitos imprescind para a comunicaao com os usurios, e vel c a que devero valid-los, e para a comunicaao com os projetistas, que devero a a c a implement-los. Da perspectiva dos usurios, o sistema caracterizado pelas a a e informaoes que entram e pelos resultados produzidos. Usurios no esto c a a a interessados com o que de fato ocorre internamente. Esta uma questo e a de projeto de software, desenvolvida no ambiente da equipe de desenvolvimento. Muitas vezes, distante deste ambiente, encontram-se os usurios, a que no sabem exatamente o que os engenheiros de software esto fazendo. a a Contudo, no tm d vidas de que ser necessrio interagir com o futuro sisa e u a a tema para que os benef cios esperados possam ser usufru dos. A viso deles a 59
CAP ITULO 11
Caso de uso
ilustrada na Figura 11.1. e
Sadas
Entradas
Figura 11.1: Viso dos usurios de um sistema de informao (metfora da fbrica). a a ca a a

Os resultados obtidos, conforme o que fornecido, as entradas, reete o senso comum e que usurios tm da operao de software. Este comportamento externo de interesse a e ca e dos usurios, enquanto aquele interno problema de engenheiros de software. a e
A Figura 11.2 ilustra este cenrio. Nesta viso peculiar do universo, v-se a a e que este povoado por sistemas computacionais. Seriam de pouca utilidade e se no houvesse interaao entre tais sistemas e o restante do universo ou, pelo a c menos, aquela parte interessada nesta interaao. Na Figura 11.2 denominouc se de atores esta parte interessada. Um ator pode representar um ser humano espec co, um papel, um outro sistema computacional ou um dispositivo f sico, por exemplo. Qualquer que seja a natureza do ator, sabe-se que este a parte do universo que ir interagir com o sistema computacional. e a
Software
Ator-1 Ator-2 Ator-An Ator-A4
Software
Ator-B1
Software
Ator-A1
A
Ator-A2
Ator-B2
Ator-A3
Figura 11.2: Perspectiva simplicada do universo dividia em duas partes: software e

o que interage com software (atores). A interao entre eles registrada atravs de ca e e casos de uso.
A Figura 11.2 ilustra a interaao entre atores e sistemas. O ator denomic nado de Ator-A3, por exemplo, interage com o sistema denominado de Software A. O Ator-B1 interage com o sistema Software-B. De forma anloga, a vrias outras interaoes so ilustradas nesta Figura. Casos de uso servem a c a para representar interaoes entre usurio e sistema. As interaoes so o meio c a c a
60
SECAO 11.2
Denio de caso de uso ca
atravs do qual os benef e cios oferecidos pelo sistema computacional podem ser explorados. Um sistema computacional oferece, em geral, vrios servios atravs dos a c e quais as intenoes dos atores so realizadas. Dividir logicamente a interaao c a c do ator com o sistema conforme as intenoes do primeiro uma forma de c e fracionar as interaoes em unidades menores e gerenciveis. Por exemplo, o c a ator Contador pode interagir com um sistema computacional contbil dua rante todo um dia. Naturalmente, vrios servios so requisitados pelo ator, a c a vrios so os objetivos deste ator ao longo do dia. De fato, provavelmente, a a o ator ir repetir vrias vezes um conjunto reduzido de interaoes com o a a c sistema. Cada uma destas interaoes deste conjunto adequadamente capc e turada por um caso de uso. Todo sistema computacional precisa interagir com o ambiente que o cerca com o propsito de oferecer servios de valor para os usurios. Usurios no o c a a a no tm d vidas de que esta interaao necessria. Alis, percebem o a e u c e a a sistema naturalmente atravs destas interaoes. So as interaoes que dese c a c crevem o que fornecido de entrada ao sistema e o que produzido na sa e e da por este. Esta viso de um sistema atravs do que se passa externamente a e atravs de uma interaao o alvo pass e c e vel de ser registrado por casos de uso. O que o sistema dever realizar a interaao, registrada em um caso a e c de uso que, dessa forma, naturalmente isola requisitos da forma como estes sero realizados, o como. Este isolamento tido por muitos como positivo. a e Independente de um benef apenas suposto, casos de uso registram requicio sitos funcionais de uma perspectiva prxima e natural aos usurios, a saber, o a a interaao que estes tero com o sistema. c a
Um caso de uso sempre iniciado por e um ator [21].
11.2
Denio de caso de uso ca

No h uma deniao precisa e universalmente aceita de caso de uso, a a c o que no foi suciente para impedir que seja amplamente empregada pela a ind stria. Em [28], caso de uso uma especicaao de seqncias de aoes, u e c ue c incluindo variantes destas e seqncias de erro que um sistema, subsistema ue ou classe realiza ao interagir com atores externos. O objetivo desta seao c esclarecer como interpretar esta deniao. Para tal, outras denioes e c c tambm so apresentadas. e a
Caso de uso: Seqncia de aoes entre um usurio e um sistema de informaao. ue c a c Relata, da perspectiva do usurio, a interaao necessria para que a c a um determinado objetivo seja atingido.
Segundo [26], caso de uso representa uma unidade coerente de funcionaliCopyright c Fbio Nogueira de Lucena a
61
CAP ITULO 11
Caso de uso
dade fornecida por um sistema, subsistema, ou uma classe, manifestada pela seqncia de mensagens trocadas entre o sistema (subsistema ou classe) e ue um ou mais elementos externos (chamados atores), juntamente com as aoes c realizadas pelo sistema (subsistema ou classe). Atores se beneciam de servios oferecidos por um sistema ou oferecem c servios. Por exemplo, o ator Comprador, veja Figura acima, pode intec ragir com um sistema de venda de livros pela Internet atravs do qual as e referncias de interesse so localizadas e, em determinado momento, este e a registra o seu interesse em efetivar a compra. A interaao correspondente c registrada no caso de uso Efetiva compra de itens selecionados (Figura e 11.3). Este caso de uso interage com outro ator, Sistema de Crdito. Obe serve que este no um ator humano, mas um outro sistema que dever a e a validar eventual pedido de crdito solicitado ao sistema. e
Comprador
Efetiva compra de itens selecionados
Sistema de Crdito
Figura 11.3: Comprador efetiva compra de itens previamente selecionados, o que exige
servio de consulta a crdito oferecido por outro sistema, o ator Sistema de Crdito. c e e
Todo caso de uso deve ser necessrio e a no deve assumir uma a soluo. ca
Caso de uso tambm pode ser interpretado como uma descriao abse c trata de um cenrio de como um ator interage com o sistema e como o a sistema responde a interaao do ator. Um caso de uso compreende todos ` c os percursos, tanto aqueles de sucesso quanto aqueles de fracasso, em uma tentativa do ator em atingir determinado objetivo. Um cenrio um destes a e percursos. Um caso de uso uma descriao abstrata de um cenrio porque e c a representa todo um conjunto de cenrios e no apenas um em particular. a a Um cenrio de um caso de uso uma instncia deste caso de uso. Para o a e a caso de uso Autenticar usurio, por exemplo, um cenrio o usurio Joo a a e a a da Silva conseguir acesso ao sistema aps fornecer sua identicaao (nome e o c senha) correta e requisitar a autenticaao. Outro cenrio Esperto J nior, c a e u usurio no autorizado, fornecer uma identicaao (nome e senha), requisia a c tar a autenticaao e receber como resposta uma negaao, informando que c c nome e/ou senha esto incorretos. a
11.3
Todo leitor de um caso de uso deve ter uma interpretao ca clara do que este signica.
Associao entre ator e caso de uso ca

A associaao entre um ator e um caso de uso signica a existncia de c e um meio de comunicaao entre ambos. Um ator associado a um caso de uso c signica que o ator comunica-se com o sistema conforme a descriao do caso c de uso. Se um ator no se comunica com um determinado caso de uso, ento a a
62
SECAO 11.4
Descrio de caso de uso ca
este ator no interage com o sistema para realizar o objetivo subjacente ao a caso de uso. A orientaao da associaao indica quem inicia a seqncia de c c ue interaao. Neste exemplo, algum ser humano, desempenhando o papel de c e comprador, quem ir iniciar esta interaao. Por outro lado, o ator Sistema a c de Crdito passivo, no sentido em que este presta servios ao caso de uso e e c sob requisiao deste ultimo, conforme a orientaao da associaao entre eles. c c c Associaoes conduzem inevitavelmente a discusso de interfaces. Interc ` a face o meio atravs do qual atores comunicam-se com o sistema. Quando o e e ator um ser humano, uma interface grca (geralmente representada pela e a sigla em ingls GUI) o meio de comunicaao. Quando o ator um softe e c e ware, todo um conjunto de classes como JDBC, por exemplo, a interface. e Neste caso, entre o sistema desenvolvido em Java e um SGBD relacional. A Figura abaixo ilustra a instanciaao de associaoes entre atores e casos de c c uso.
Gerente insatisfeito Sistema de crdito
A descrio de um ca caso de uso deve facilitar da denio ca de testes.
Erro
Sistema
Conexo (EJB, CORBA, ...)
Gerente
Analisa produtividade
Caixa
Recebe pagamento
Operadora de Carto de Crdito
Figura 11.4: Nem sempre a interao entre usurio e sistema amigvel como gosca a e a
tar amos. Atualmente, comum o emprego de mouse, teclado, v e deos de alta denio ca e recursos sonoros para esta interao. Atores que so softwares interagem com o sisca a tema, geralmente, atravs de protocolos de comunicao. Sockets um destes protocoe ca e los comumente empregados entre mquinas interligadas pela Internet. Uma operadora a de carto de crdito pode, por outro lado, disponibilizar uma interface proprietria, a a e a ser utilizada pelo software de interesse, que utilizar a linha telefnica para obter os a o servios desta operadora. c
11.4

Um diagrama de casos de uso no detalhado o suciente para descrea e ver os requisitos funcionais de um sistema. Tais diagramas, por exemplo, permitem apenas identicar os atores e sugerir poss veis interaoes destes c com o sistema. Um diagrama de caso de uso um e ndice grco das a correspondentes descrioes. Atravs dos diagramas de casos de uso pode-se c e
Casos de uso devem ser escritos de tal forma que possam ser usados como um contrato.
63
CAP ITULO 11
Caso de uso
Caso de uso no a e projeto.
Caso de uso no a e cdigo. o
navegar pelos requisitos e, possivelmente, at facilitar a compreenso dese a tes. Caso de uso um texto, cujo registro em geral benecia-se do emprego e de linguagens naturais. O texto descreve o dilogo entre usurio e sistema. a a Alm de linguagem natural pode-se empregar diagramas da UML como o e diagrama de seqncia, onde o ator e o caso de interagem. Este no o unico ue a e tipo de diagrama que pode ser empregado, tambm sugerido o diagrama e e de atividades. Fica claro, portanto, que no existe uma unica maneira de se a descrever um caso de uso. Alis, mesmo a descriao narrativa, em forma de a c texto, conta com defensores de escolas de estilos distintos. Existem muitas propostas para descriao de casos de uso. Em [19] so c a comentadas algumas das abordagens para deniao e formalizaao de casos c c de uso. Deve-se salientar que no existe a melhor forma de descriao a c de casos de uso. Pode-se especular que exista uma mais apropriada que outra para um contexto particular. Independente de qual abordagem vai ser seguida, gerentes de projeto devem assegurar que padres de estilo e o de especicaoes de requisitos estabelecidos sejam seguidos por todos os c participantes de um projeto [32]. Discusso exaustivas sobre modelos de a descriao de casos de uso so encontradas em [22, 21]. c a Aqui so comentados elementos comuns, presentes em praticamente toda a descriao de caso de uso: c Nome. Deve sugerir o tipo de servio obtido da interaao corresponc c dente. Descriao. Breve descriao da nalidade do caso de uso da perspectiva c c do ator. Pr-condiao. Restrioes no estado do sistema satisfeitos antes que o e c c caso de uso possa ser iniciado. Noutras palavras, o que deve ser verdade para que o caso de uso possa ser executado? Em uma biblioteca, quando o funcionrio interage com o sistema atravs do caso de uso a e Devolve livro, a pr-condiao para a execuao deste caso de uso e c c e que o mesmo esteja emprestado. Curso bsico de eventos. Espera-se que as interaoes produzam rea c sultados positivos para o ator. Quando o propsito de uma interaao o c realizado de forma satisfatria, conforme previamente idealizado, e o diz-se que se trata do curso bsico, do caso de sucesso da interaao. a c Por exemplo, efetivar compra de itens selecionados envolve uma conrmaao de intenao por parte do ator, a posterior vericaao, por c c c parte do sistema, se o cliente (papel Comprador) possui crdito sue ciente, o que realizado pelo ator Sistema de Crdito. Se a resposta e e positiva para estes eventos, ento a compra efetivada e o sistema e a e dever emitir uma mensagem parabenizando o ator pela compra, por a exemplo. Observe que, ao contrrio deste caso de sucesso, o caso bom, a
64
SECAO 11.4
situaoes excepcionais podem ocorrer. O cliente pode no possuir c a crdito suciente para o pedido em questo ou at mesmo o servio e a e c prestado pelo ator Sistema de Crdito estar indispon momentanee vel amente. Situaoes como esta no so tratadas pelo curso bsico, mas c a a a por cursos alternativos, veja abaixo. Curso(s) alternativo(s). Interaoes so mapas atravs dos quais vrios c a e a percursos podem ser tomados. Um ator pode, durante a interaao, c mudar de interesse. O sistema pode no conseguir efetuar uma dea terminada operaao pela indisponibilidade de rede ou falha no banco c de dados. Estes percursos so ditos alternativos por representarem, a supostamente, casos excepcionais ou casos que se desviam do curso bsico, comentado acima. a Ps-condiao. Restrioes satisfeitas aps a execuao do caso de uso. o c c o c Compreendem sentenas que devem ser verdadeiras aps a realizaao c o c do caso de uso. Noutras palavras, qual o estado do sistema aps a o execuao do caso de uso? Para o caso de uso Devolve livro, uma c ps-condiao apropriada O livro devolvido retirado da lista de o c e e emprestados ao usurio em questo. A ps-condiao , em geral, um a a o c e sentena composta, pois deve contemplar a situaao aps a execuao c c o c do caso de uso seja do uxo bsico ou alternativo. Por exemplo, caso a seja poss vel cancelar a devoluao, ento a ps-condiao para o caso c a o c de uso ilustrado anteriormente pode ser reescrito como A lista de emprestados continua inalterada (operaao cancelada) ou o livro dec volvido retirado da lista de emprestados. e Conforme comentado acima, existem muitos modelos para a descriao de c casos de uso. Apenas os elementos essenciais so apresentados nos exemplos a aqui fornecidos. Quando considerado apropriado, outras informaoes sero c a fornecidas e, nestes casos, devidamente comentadas, a semelhana do que ` c foi feito para o sumrio, o curso bsico e os cursos alternativos. a a Os itens acima so sucientes para descrever boa parte dos requisitos a geralmente encontrados. Sistemas complexos, contudo, exigem mais do que estas descrioes. Nestes casos, com o propsito de estruturar modelos de c o casos de uso e fornecer mecanismos para que possam ser organizados conforme a complexidade em questo, casos de uso podem se relacionar de a trs formas formas: extend (Cap e tulo 12), include (Cap tulo 13) e herana c (Cap tulo 15). Estes relacionamentos so empregados para estruturar espea cicaoes em casos de uso. Relacionamentos no sentido de interaoes no c c a existem entre casos de uso de um mesmo sistema, mas apenas entre os casos de uso e atores. Nada impede que um ator seja um software e, dessa forma, pode haver interaao entre casos de uso, mas em sistemas distintos. c
Um caso de uso um e conjunto de requisitos organizados em torno de um evento iniciado por um ator.
A descrio de um ca caso de uso assume que o ator comporta-se responsavelmente, mesmo assim, entradas erradas e exceoes devem ser c descritas.
No existe interao a ca entre casos de uso de um mesmo sistema.
65
Relacionamento extend
` A medida que o comportamento do sistema vai se tornando mais claro comum a identicaao de comportamentos que estendem o curso bsico e c a de casos de uso j identicados. Estes comportamentos so acrescentados a a aqueles do caso de uso base. No h substituiao de comportamento. Nestes ` a a c casos, tais comportamentos adicionais podem ser modelados em casos de uso distintos dos casos de uso base, aqueles que so estendidos. A ligaao a c entre os casos de uso base e aqueles que os estendem realizada atravs de e e relacionamentos extend (Figura 12.1).
<<extend>>
12
Caso de Uso Extenso
Caso de Uso Base
Figura 12.1: O relacionamento extend entre casos de uso uma relao de dee ca pendncia do caso de uso que estende para o caso de uso base. e
12.1
Um caso de uso que estende outro pode ser removido ou adicionado sem que o caso de uso base sofra qualquer modicao. ca
Denio ca
Um relacionamento extend de um caso de uso A para um caso de uso B indica que uma instncia do caso de uso B pode ser acrescida de comportaa mentos especicados por A. O acrscimo submete-se as condioes espec e ` c cas fornecidas na extenso (caso de uso A). O comportamento inserido em pona e tos espec cos do uxo de eventos do caso de uso B, denominados de pontos de extenso. Cada ponto de extenso deve possuir um identicador unico a a 66
SECAO 12.2
Execuo de um relacionamento extend ca
no caso de uso B. E importante destacar que o caso de uso B no sabe da a existncia do caso de uso A. e Extenso um comportamento acrescido ao uxo bsico de eventos de a e a um caso de uso, sem se misturar ao ultimo. Dessa forma, permite ressaltar o que acrescido em um caso de uso isolado, sem comprometer a legibie lidade do caso de uso base, visto que a descriao de ambos so distintas. c a Esta separaao no os torna completamente independentes. Uma extenso c a a depende e s faz sentido com a existncia do caso de uso estendido. Por ouo e tro lado, o caso de uso estendido no precisa ser reescrito ou reestruturado a para acomodar o comportamento acrescido. O uxo bsico de eventos do a caso de uso base no alterado. a e
No h dependncia a a e do caso de uso base para o caso de uso que o estende.
Relacionamento extend: Modela adioes ao comportamento de um caso de uso. c

A descriao do caso de uso A que estende o caso de uso base B deve c conter onde e qual a condiao para que A estenda o comportamento de B. c O local refere-se, no caso de uso base B, aos pontos onde o curso bsico a pode ser acrescentado com comportamento descrito em A (os pontos de extenso). O acrscimo depende do resultado da avaliaao da condiao de a e c c disparo descrita em A.
12.2
Execuo de um relacionamento extend ca

A Figura 12.2 ilustra o processo de execuao de um caso de uso estenc dido por outros. Quando um ponto de extenso em um caso de uso base a (caso de uso estendido) atingido, o controle transferido para o caso de e e uso que estende o caso de uso base atravs de um relacionamento extend. e Neste momento, a condiao de guarda executada e, caso verdadeira, o comc e portamento adicional executado. Aps a execuao deste comportamento e o c acrescido ao caso de uso base, o controle retorna para o caso de uso base, imediatamente aps o ponto de extenso. Se houver a condiao de guarda o a c e a avaliaao desta resultar em valor falso, ento nenhum comportamento c a adicional aqueles do caso de uso base executado neste ponto de extenso. ` e a Ou seja, o uxo de eventos do caso de uso base prossegue normalmente. De forma simplicada, um relacionamento extend de um caso de uso A para um caso de uso B pode ser interpretado como um caso de uso C (virtual) onde o comportamento descrito em A foi adicionado aquele de B nos ` pontos de extenso correspondentes, juntamente com as poss a veis condioes c com guarda. O caso de uso virtual C, gerado desta unio, executado a e normalmente. Quando, no uxo de eventos de C, for atingido os pontos de extenso denidos em B, a condiao de guarda executada. Se verdadeira, o a c e
Aps a execuo de o ca uma extenso, o a controle necessariamente retorna para o caso de uso base.
O caso de uso B pode ser executado com ou sem o acrscimo do e comportamento de A.
67
CAP ITULO 12
Relacionamento extend
Transferncia do fluxo de controle

Execuo da extenso (guarda verdadeira)
Caso de uso: Pr-condio (guarda): Fluxo bsico:
A Se ... 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ... Passo 1 (B) C Se ... 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ... Passo 3 (B)
Caso de uso: Ator(es): Fluxo bsico:
B Ser humano 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ... Passo 1 Passo 3
Pontos de extenso:
Caso de uso: Pr-condio (guarda): Fluxo bsico:
Pontos de extenso:
Retorno para ponto de extenso (guarda falsa)
Pontos de extenso:
Figura 12.2: Execuo do caso de uso base B estendido pelos casos de uso A e C. Ao ca
atingir o passo 1 da seqncia de eventos de B, a condio (pr-condio) de A, caso de ue ca e ca uso que estende B neste passo, executada. Caso verdadeira, conforme sugere a gura, e ento a seqncia de A executada. Ao trmino, o controle retornado para o ponto a ue e e e de extenso em B, donde a execuo prossegue normalmente at o prximo ponto de a ca e o extenso, que transfere o controle para C. A condio de guarda de C, conforme sugere a ca a gura, avaliada como falsa e, neste caso, o controle retorna imediatamente para B, e sem que o comportamento descrito no uxo bsico de C seja executado. a
comportamento correspondente executado. Se falsa, a execuao prossegue e c normalmente para o prximo elemento no uxo de eventos. o
12.3
O que no relacionamento extend a e

O comportamento descrito em um caso de uso que estende outro no a substitui o comportamento deste outro. O propsito complementar o o e comportamento do caso de uso base com requisitos que no fazem parte a do uxo bsico de eventos. Fluxo alternativo ou tratamento de exceoes, a c que em geral no retornam o controle para o ponto de extenso, no so a a a a adequadamente tratados com o emprego de relacionamentos extend. Quando um caso de uso extenso empregado em vrios relacionamena e a tos extend, considere a possibilidade do emprego do relacionamento include (discutido no prximo cap o tulo). Reutilizaao melhor capturado atravs c e e de relacionamentos include do que relacionamentos extend.
No capture exceoes a c com extend.
Se houver dvida u quanto ao emprego de extend, ento a modele-o como um uxo alternativo.
Um relacionamento extend compat e vel com o desenvolvimento incremental de software. O caso de uso de extenso pode ser empregado para a fornecer requisitos no contemplados anteriormente no processo de desena volvimento. Empregar criteriosamente este tipo de relacionamento facilitar a a legibilidade de modelos ou, caso contrrio, ter pouco signicado. a a
68
SECAO 12.4
Exemplos
12.4
Exemplos
69
Relacionamento include
` A medida que detalhes so obtidos, provvel a identicaao de parte a e a c do comportamento de um caso de uso que tambm util a outro caso de e e uso. Nestes casos e naqueles onde parte do comportamento de um caso de uso, quando isolado em um novo caso de uso, torna mais leg o conjunto vel resultante, deve-se empregar o relacionamento include (Figura 13.1).
<<include>>
13
Caso de Uso Base
Caso de Uso Includo
Figura 13.1: O relacionamento include entre casos de uso uma relao de dee ca
pendncia do caso de uso base, aquele que inclui, para o caso de uso que inclu e e do.
13.1
Denio ca
Um relacionamento include de um caso de uso A para um caso de uso B signica que o comportamento de A contm o comportamento denido e em B. Neste cenrio, o caso de uso base, caso de uso A, acrescido do a e comportamento do caso de uso inclu do, B. Casos de uso inclu dos so casos a de uso que simplesmente so referenciados por outros casos de uso e fazem a parte do comportamento destes. B desconhece a existncia de A. e 70
Um caso de uso pode ser inclu por vrios do a outros.
SECAO 13.2
Execuo de um relacionamento include ca
Relacionamento include: Modela reutilizaao de um caso de uso por outro. c
13.2
Execuo de um relacionamento include ca

A Figura 13.2 ilustra a execuao de um relacionamento include. Quando c um caso de uso atinge em seu uxo de eventos a incluso de um outro caso de a uso, o controle transferido para o uxo de eventos do caso de uso inclu e do. Nenhuma condiao, ao contrrio do relacionamento extend, avaliada no c a e caso de uso inclu com o propsito de prevenir ou no o uxo de eventos do o a deste. Quando o uxo de eventos do caso de uso inclu nalizado, o do e controle transferido de volta para o caso de uso base, no mesmo local e da incluso. A partir deste ponto, o uxo de eventos do caso de uso base a retoma a execuao, que prossegue normalmente, como se a incluso tivesse c a efeito parecido a uma chamada de rotina em linguagens de programaao. c
Transferncia do fluxo de controle
Caso de uso: Ator(es): Fluxo bsico: Caso de uso: Fluxo bsico:
A 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ...
B Ser humano 1. O ator ... 2. Inclua A 3. O ator ... 4. Inclua C

Execuo da incluso
Caso de uso:
C 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ...
Execuo da incluso Retorno para ponto de incluso
Fluxo bsico:
Figura 13.2: O comportamento de um caso de uso inclu executado no momento do e em que executado o ponto de incluso. Neste exemplo, os passos 2 e 4 do caso de uso e a base B so pontos de incluso. No primeiro deles o controle transferido para o caso a a e de uso A. Aps o trmino da execuo do caso de uso A o controle retorna para o caso o e ca de uso B, que prossegue com a execuo do passo 3. Ao atingir o passo 4 o controle ca novamente transferido para fora do caso de uso B. Aps o trmino da execuo do e o e ca uxo de eventos de C o controle retorna para o caso de uso B. O caso de uso base desconhece detalhes do caso de uso inclu do. A incluso signica apenas que o caso de uso base ir se beneciar do resultado a a da execuao de um outro caso de uso, independente do uxo de eventos deste. c
Reutilizao de caso ca de uso ocorre atravs e de relacionamentos include.
13.3
Exemplos
71
CAP ITULO 13
Relacionamento include
Caso de uso: Ator(es): Curso bsico:
Exemplo Ser humano 1. O ator ... 2. O sistema ... 3. O ator ... 4. O sistema ...
Figura 13.3:
72
Diferenas entre include e extend c

Optar entre o emprego de include ou extend nem sempre de deciso e a simples. Se por um lado a deciso pode no ser simples, por outro, ela deve a a ser evitada. Quando se emprega casos de uso para o registro de requisitos funcionais, a essncia no se resume nos diagramas correspondentes. Ree a gistrar requisitos funcionais atravs de casos de uso escrever texto. Os e e diagramas so ferramentas adicionais que nos auxiliam a lidar com a coma plexidade de alguns casos, que exigem o emprego de relacionamentos como include e extend. Despender tempo
14
73
Relacionamento de generalizao ca
Embora o conceito de generalizaao (especializaao) seja extensivamente c c empregado entre classes, surgem vrias diculdades quando este conceito a e aplicado para relacionar casos de uso. A deniao simples: um caso de c e uso descendente herda o comportamento do caso de uso ancestral. Comportamento pode ser acrescentado ou sobrepor aquele presente no caso de uso ancestral. A prtica sugere um cenrio diferente. Uma rpida consulta a literatura a a a ` ir revelar que o emprego deste relacionamento entre casos de uso carece a de um tratamento mais rigoroso, capaz de elucidar os poss veis benef cios e como obt-los. Os raros exemplos geralmente empregados so insucientes e a para convencer os praticantes. Esta situaao se reete na forma de abordar c este tipo de relacionamento entre casos de uso: secundria em relaao aos e a c demais tipos. Em cap tulos anteriores vimos, por exemplo, a forma de descrever os relacionamentos include e extend entre casos de uso. No se trata de uma a consideraao elementar de diagramas, mas da forma como o relacionamento c registrado em texto. (Lembremo-nos de que um caso de uso texto.) e e Quando o assunto herana entre casos de uso, a descriao em forma de e c c texto empregada em [2], por exemplo, sofre de uma diculdade bem superior aquela dos relacionamentos include e extend, tornando a idia, embora in` e teressante, impraticvel. Anal, como acrescentar comportamento descrito a em texto sem o onus de um pesadelo para manter as referncias atualizadas? e Esta apenas uma das questes envolvidas com o registro. Em conseqncia, e o ue a anlise de sistemas agil sugere o no emprego deste relacionamento. O ema a prego signica um aumento na complexidade da especicaao sem a garantia c 74
15
Evite o emprego do relacionamento de generalizao! ca
de benef cios. Isto no signica que uma deniao no possa ser fornecida juntamente a c a com um diagrama ilustrativo.
Relacionamento de generalizao: ca Modela similaridades conceituais entre casos de uso.
Caso de Uso Derivado
Caso de Uso Base
Figura 15.1: O relacionamento de generalizao entre casos de uso dene um caso ca

de uso derivado a partir de um caso de uso base.
75
Desenvolvimento orientado por caso de uso

O emprego de casos de uso no resolve os problemas da engenharia de a requisitos. Enquanto notaao, pode-se especular que casos de uso oferecem c uma viso vantajosa em relaao a outras, por exemplo, auxilia na rastreaa c bilidade dos requisitos. Contudo, mister compreender a limitaao desta e c natureza. Por exemplo, a diculdade de se eliciar os requisitos, talvez o maior problema do desenvolvimento de software, permanece. Se no h a a requisito conhecido, ento no h o que se registrar em um caso de uso. a a a De fato, s se emprega caso de uso quando esta diculdade de eliciaao o c e vencida. Anal, o que se poderia registrar em um caso de uso quando no a h conhecimento para ser representado? A resposta: nada. Observe que a esta restriao no exclusiva de casos de uso nem elimina os benef c a e cios do emprego desta abordagem como norteador de desenvolvimento de sistemas, tema do restante da seao. c Uma compreenso plena do conte do desta seao exige do leitor familia u c aridade com a linguagem UML, da qual casos de uso um ilustre membro, e e com as atividades de anlise e projeto orientados a objeto. Infelizmente a tais assuntos esto alm dos objetivos e do espao dispon neste texto. a e c vel
16
76
Validando casos de uso

17.1 Checando: modelos de casos de uso
A seao 6.6 apresenta caracter c sticas desejveis em uma ERS. Atingir a aquelas qualidades o objetivo para se obter uma boa ERS. Esta seao e c interpreta aquelas qualidades da perspectiva do emprego de casos de uso como principal instrumento de registro de uma ERS.
17
Modelo de caso de uso: Um modelo de casos de uso inclui, alm de diagramas de casos de e uso e as descrioes correspondentes, glossrios, imagens, textos c a e outros documentos empregados na especicaao dos casos de c uso.
Todos os casos de uso foram encontrados? Aqueles identicados devem ser capazes de realizar todos os comportamentos do sistema, caso contrrio, alguns casos de uso esto faltando. a a Os casos de uso atendem todos os requisitos funcionais? O modelo de caso de uso contm comportamento supruo? Tudo o e e que parte deste modelo desejado? e e A diviso do modelo em packages apropriada? A organizaao adoa e c tada torna o modelo mais simples e intuitivo de entender e facilitar posteriores manutenoes? c 77
CAP ITULO 17
O estudo do modelo de casos de uso permite obter uma viso clara das a funoes do sistema e como estas esto interrelacionadas? c a A seao de introduao de cada modelo de caso de uso contm toda a c c e informaao necessria para a compreenso dos casos de uso ali descric a a tos?
17.1.1
Checando: descrioes de caso de uso c

Cada caso de uso concreto est envolvido com pelo menos um ator? a Se no, alguma coisa est errada. Um caso de uso que no interage a a a com um ator supruo e deveria ser removido. e e Cada caso de uso independente dos demais? Se dois casos de uso seme pre so ativados na mesma seqncia, ento pode-se, provavelmente, a ue a uni-los. H casos de uso com comportamentos similares, ou seja, cursos bsicos a a de eventos parecidos? Se se deseja que o comportamento seja o mesmo no futuro, ento pode-se especular a fuso deles. Isso facilita a ina a troduao de mudanas futuras. Voc dever envolver os usurios se c c e a a voc decidir fundir os casos de uso, provavelmente eles sero afetados. e a Parte de um curso bsico de um caso de uso j foi modelado como a a um outro caso de uso? Se armativo, ento o novo caso de uso dever a a fazer uso do existente. Parte de um curso bsico existente j parte de outro caso de uso? a ae Se armativo, ento esta parte deveria ser extra e compor um novo a da caso de uso, a ser utilizado pelos anteriores. Deveria o curso bsico de um caso de uso ser inserido no curso de a outro caso de uso? Se armativo, ento deve-se modelar como um a relacionamento extend. Cada caso de uso tem nome unico, intuitivo e elucidativo? Clientes e usurios compreendem os nomes e as descrioes dos casos a c de uso? O nome de cada caso de uso deve descrever o comportamento oferecido pelo caso de uso. O caso de uso atende todos os requisitos no funcionais? Provavela mente esses esto descritos em outro documento. a A comunicaao entre ator e sistema, descrita em um caso de uso, c atende as expectativas dos usurios? a E claro quando o curso bsico de um caso de uso se inicia e termina? a
78
SECAO 17.1
Checando: modelos de casos de uso
H descriao do que ocorre quando determinada condiao no atena c c a e dida? Os casos de uso so complexos? Se deseja que sejam simples, casos de a uso complexos devem ser fracionados. O caso de uso contm cursos de eventos bem distintos? Se for o caso, e provavelmente poder tratar melhor a interaao fragmentando este a c caso de uso em outros. E claro quem deseja realizar um caso de uso? O propsito de um caso o de uso claro? e As interaoes e troca de informaoes so claras? c c a O resumo fornece uma viso clara do caso de uso? a Est claro como o caso de uso se inicia e termina? a Se o caso de uso produz dados, estes precisam ser armazenados? Onde? Se o caso de uso usa dados, de onde os dados vm? e Todos os atores foram considerados?
17.1.2
Checando: atores
Todos os atores foram encontrados? Todos os papis foram identie cados e modelados? Provavelmente esta vericaao s ser poss c o a vel quando todos os casos de uso estiverem descritos. Cada ator est envolvido com pelo menos um caso de uso? a Pode-se identicar as pessoas que iro realizar as tarefas de cada ator? a Se no, verique se o papel do ator no parte de outro papel. a a e Atores similares desempenham os mesmos papis em relaao ao sise c tema? Se armativo, ento estes devem ser fundidos em um unico a ator. Dois atores desempenham o mesmo papel em relaao a um caso de c uso? Se armativo, ento voc deveria usar generalizaoes de atores a e c para modelar o comportamente compartilhado. Um determinado ator uso o sistema com propsitos completamente o diferentes ou o ator possui propsitos completamente diferentes ao ino teragir com o sistema? Se armativo, ento provavelmente este unico a ator est representando dois ou mais atores. Tente isolar estas difea renas. c
79
CAP ITULO 17
Os atores possuem nomes e descrioes intuitivas? Usurios e clientes c a podem compreender os nomes empregados? E importante que os nomes dos atores correspondam aos respectivos papis. Caso contrrio, e a mude-os.
17.1.3
Processo orientado a casos de uso

Em [2] proposto o desenvolvimento de casos de uso em trs fases, e e conforme ilustra a Figura 17.1.
Refinamento
Refinamento Inicial Base
Refinamento Elaborada
Refinada Inicial
Caso de uso: Ator(es): Descrio:
Acrscimo e reviso de informaes
Caso de uso: Ator(es): Descrio: <mais itens>:
Figura 17.1: O diagrama de estados ilustra as vrias fases de desenvolvimento de um a

caso de uso. A inicial contm informaoes m e c nimas, mas sucientes para serem analisadas posteriormente, onde detalhes sero acrescentados. A descrio resultante ainda a ca poder passar por vrios renamentos. De uma perspectiva ampla, no razovel esa a a e a perar uma denio nal, mas uma elaborada que, com o tempo, pode ser necessrio ca a ren-la. a
Nome do caso de uso Ator(es): Nome do ator ou atores que interagem com o sistema Descrio: ca Descriao da interaao entre o(s) ator(es) e o sistema. c c A descriao mais sosticada. c Caso de uso: Nome do caso de uso ID: Identicador unico do caso de uso Prioridade: Em grandes sistemas cujo desenvolvimento incremental, e estabelecer a prioridade essencial para controlar o escopo. e Empregar uma classicaao numrica ou categorias como c e alta, mdia e baixa so algumas das opoes. e a c Ator(es): Nome do ator ou atores que interagem com o sistema Descrio: ca Descriao da interaao entre o(s) ator(es) e o sistema. c c Pr-condio: e ca Condiao satisfeita quando o caso de uso iniciado c e Curso bsico: a Caso de sucesso, timo, da interaao entre ator e siso c tema Curso alternativo: Caso(s) alternativo(s) para o curso bsico ou exceoes a c Ps-condio: o ca Condiao satisfeita aps a execuao do caso de uso c o c
Caso de uso:
80
SECAO 17.2
Entrevista
17.2
Entrevista
Uma das formas mais simples e direta para se obter os requisitos entree vistar o usurio. Ainda permite que seja utilizida, virtualmente, em qualquer a situaao. Cuidado, contudo, deve ser empregado para que a entrevista obc tenha os resultados esperados. As predisposioes do entrevistador podem c prejudicar a troca de informaoes com o entrevistado. Neste sentido, ter c um conjunto de questes previamente preparadas e livres de contexto um o e benef cio. No restante desta seao apresentada uma proposta derivada dac e quelas em [27] e [24] de perguntas livres de contexto para entrevistar clientes e usurios. a
17.2.1
Perl dos clientes e/ou usurios a

Nome Empresa Emprego (t tulo) Quais as suas principais responsabilidades? Quais os resultados que voc produz? e Para quem? Como medido o sucesso? e Quais os problemas que interferem com o sucesso? O que tende a facilitar e a dicultar o seu trabalho?
17.2.2
Caracterizar o problema
indexcaracterizar!o problema Como caracterizar um bom resultado? H restriao de desempenho ou outra restriao? a c c Qual o ambiente onde a soluao ser usada? c a Quais so os problemas para o tipo de aplicaao em questo? a c a Por que cada um deles existe? Como voc resolve cada um deles? e Como voc gostaria de resolver cada um deles? e
81
CAP ITULO 17
Quem usar a soluao? a c Quem est por trs da requisiao? a a c Qual o benef econmico de uma soluao satisfatria? cio o c o H outra fonte de soluao? a c
17.2.3
Compreender o ambiente do usurio a

Quem so os usurios? a a Qual a formaao deles? e c Qual a formaao computacional deles? e c Os usurios so experientes para lidar com este tipo de problema? a a Quais as plataformas que esto em uso? a H aplicaoes em uso que so relevantes para a aplicaao em questo? a c a c a Quais so suas expectativas a respeito da usabilidade do produto? a Quais as suas expectativas em termos de tempo de treinamento? Que tipo de ajuda ao usurio voc precisa? Material impresso? Ona e line? Recaptular para compreender melhor. Voc disse que: (liste cada um e dos problemas com suas prprias palavras) o Estes problemas reetem adequadamente as diculdades correntes com a soluao atualmente empregada? c
17.2.4
Compreendendo o problema
Liste problemas que voc acredita ser de interesse dos clientes e usurios. e a Para cada um deles, obtenha respostas para as seguintes questes. o Isto um problema real? e Quais as razes para este problema? o Como voc resolve o problema no momento? e Como voc gostaria de resolver o problema? e
82
SECAO 17.3
Checando o resultado
17.2.5
Avaliando a oportunidade
Quem na organizaao necessita desta aplicaao? c c Quantos destes tipos de usurio iro fazer uso da aplicaao? a a c Como voc faria para mensurar uma soluao de sucesso? e c
17.2.6
Avaliando necessidades
Quais as expectativas em relaao a conabilidade? E em relaao ao c ` c desempenho? Quem ir sustentar o produto, voc ou outros? a e Quais as expectativas em relaao a manutenao? c ` c Quais os requisitos de segurana? c Quais os requisitos de instalaao e conFiguraao? c c H requisitos de licena especiais? a c Como o software ser distribu a do? H requisitos para rotulaao e empacotamento? a c
17.2.7
Outras questes o
H requisitos legais, de regulamento ou ambiente ou outros padres a o que devem ser seguidos? Voc pode citar qualquer outro requisito que eu deveria saber? e H alguma outra questo que eu deveria ter feito? a a Voc gostaria de participar de uma reviso dos requisitos? e a Logo aps a entrevista, enquanto as informaoes ainda esto frescas em o c a sua mente, sumarize as trs necessidades de maior prioridade ou problemas e identicados pelo usurio ou cliente. a
17.3
Pode-se aferir o resultado das atividades da engenharia de requisitos analisando a ERS produzida. Abaixo seguem questes que auxiliam no o sentido de descobrir eventuais problemas com esta especicaao. c 1. O que o software suposto realizar est descrito? e a
83
CAP ITULO 17
2. Como o software interage com pessoas, hardware e outros softwares? 3. Qual o desempenho, a disponibilidade, o tempo de resposta e o tempo de recuperaao de desastre para os vrios elementos de software? c a 4. Quais as consideraoes de portabilidade, correao, manutenibilidade e c c segurana? c 5. H padres a serem seguidos? H linguagem de programaao predea o a c nida? H sistema operacional predenido? H browser predenido? a a Quais as verses destes produtos? H pol o a ticas para integridade de banco de dados? Quais os limites dos recursos? 6. H requisitos denidos em outro documento que no faa parte da a a c especicaao de requisitos de software (ERS)? c 7. A ERS contm todos os requisitos do software? e 8. A ERS descreve detalhes de projeto e implementaao? No deveria. c a 9. A ERS no deveria impor restrioes desnecessrias ao software. a c a 10. A ERS limita apropriadamente a faixa de projetos vlidos sem espea cicar detalhes a serem produzidos pela atividade de projeto? 11. Todo requisito contido na ERS deve ser atendida pelo software? 12. H uma unica interpretaao para cada requisito? a c 13. Diagramas foram empregados para ampliar a legibilidade de descrioes c em linguagem natural? 14. A ERS inclui todos os requisitos signicantes? 15. Todos os valores de entrada em todos os poss veis cenrios foram idena ticados e contemplados? 16. Foram fornecidas as respostas para os valores de entrada vlidos e a aqueles invlidos? a 17. Todas as Figuras, tabelas e diagramas incluem rtulos e referncias, o e alm de denioes de todas as unidades de medida? e c 18. Todas as questes que foram identicadas para fazer depois foram o contempladas e eliminadas? 19. A ERS est de acordo com o documento Viso, o modelo de casos de a a uso e as especicaoes suplementares? c
84
SECAO 17.3
20. H concordncia com especicaoes eventualmente dispon a a c veis de mais alto n vel? 21. H conito entre requisitos? a 22. Cada requisito foi marcado com um identicador para indicar a importncia ou estabilidade daquele requisito em particular? a 23. Outros atributos relevantes para a determinaao de prioridades foram c adequadamente estabelecidos? 24. Cada requisito vericvel? e a 25. H algum processo efetivo atravs do qual uma pessoa ou mquina a e a possa checar se o produto atende os requisitos? 26. A estrutura e estilo da ERS facilita a realizaao de mudanas? c c 27. Redundncia foi identicada e minimizada? a 28. Cada requisito possui um identicador claro? 29. A origem de cada requisito clara? e 30. Artefatos antigos podem ser facilmente rastreados? 31. H quantidade suciente de rastros para elementos derivados da a ERS? 32. Todas as entradas e sa das foram especicadas? A origem delas, a preciso (n mero de casas decimais, por exemplo), faixa de valores e a u freqncia? ue 33. Todos os formatos de sa da, por exemplo, relatrios e pginas web por o a exemplo, foram devidamente identicados e claramentes especicados? 34. Todas as interfaces externas de hardware e software foram especicadas? 35. Para todas as operaoes que se zerem necessrias h o tempo de c a a resposta esperado devidamente especicado? 36. Todas as consideraoes temporais como tempo de processamento, hora c de processamento, taxa de transferncia e outras foram especicadas? e 37. Toda a especicaao de segurana foi fornecida? c c 38. A conabilidade do sistema foi especicada? Conseqncias de falha ue no software foram especicadas? Foi fornecida estratgia para detecao e c de erro e eventual recuperaao? c
85
CAP ITULO 17
39. Memria mxima foi especicada? o a 40. A capacidade mxima de armazenamento foi especicada? a 41. A capacidade do sistema de se adaptar a mudanas foi devidamente c especicada? Mudanas de ambiente foram especicadas? Mudanas c c na interface com outros produtos foram especicadas? 42. Os requisitos esto escritos na linguagem do usurio? Os usurios a a a pensam que sim? 43. H conitos entre requisitos? a 44. H compromissos aceitveis entre atributos, por exemplo, entre facilia a dade de uso e desempenho? 45. A especicaao no inclui informaoes de projeto? c a c 46. A ERS encontra-se detalhada adequadamente ou detalhes precisam ser incorporados? H requisitos que podem ser especicados com menos a detalhes? 47. A ERS clara o suciente para ser fornecida a um grupo independente e para construao e mesmo assim ser claramente compreendida? c 48. Cada item da ERS pass de ser testado? E poss que um grupo e vel vel de teste independente determine se um requisito foi satisfeito ou no? a 49. As areas onde detalhes esto ausentes esto devidamente especica a a das? 50. Os requisitos esto completos no sentido de que um produto que os a satisfaz ser aceitvel para os clientes? a a 51. Voc se sente confortvel com todos os requisitos? Requisitos que so e a a imposs veis de serem implementados foram exclu dos?
17.4
Resumo
Foram descritas ferramentas de grande impacto empregadas na engenharia de requisitos. As ferramentas incluem uma tcnica para eliciaao de e c requisitos atravs de entrevista, uma tcnica para a modelagem de requisitos e e e uma proposta de plano de gerncia de requisitos. e So elementos de grande impacto por produzirem parte signicativa, a seno todo o resultado contido na ERS. Convm ressaltar que muitas outras a e poderiam ser empregadas e a escolha daquelas aqui apresentadas no tem a o propsito de reduzir a importncia das demais. Contudo, a perspectiva o a
86
SECAO 17.4
Resumo
do autor ao longo de anos mostra que o dom nio de emprego destas outras est restrito a nichos espec a cos. Para o desenvolvimento de sistemas de informaao, sem outras restrioes, o autor sugere que o conjunto exibido c c oferece uma melhor relaao entre custo e benef c cio.
87
Parte III
Estudo de Caso
88
Aps a introduao de conceitos bsicos para uma Especicaao de Reo c a c quisitos de Software (ERS) e a elucidaao de uma caixa de ferramentas de c grande impacto para a produao deste importante documento, esta parte c concentra-se no desenvolvimento de um estudo de caso real. Embora seja dif estabelecer a complexidade do estudo de caso, no cil a e dif perceber que se trata de um sistema no trivial. Em conseqncia, cil a ue compat e vel com a pretenso de observar a engenharia de requisitos de a uma otica prtica, sem recorrer a trabalho didtico que, muitas vezes, omite a ` a diculdades encontradas em cenrios reais, tornando a tarefa em questo a a mais simples do que de fato , turvando a vista do praticante para desaos e do caminho que inevitavelmente sero encontrados no dia-a-dia. a
89
17.5
Artigo: [16]
xxx Conhecimento espec co e profundo da aplicaao exigido para consc e truir softwares grandes e complexos. Um dos mais destacados problemas em projetos de software o pouco e conhecimento do dom nio da aplicaao. c Vrias equipes de ER usam modelos para facilitar a comunicaao ena c tre stakeholders. Tambm fornecem exemplos compreensivos para e melhorar a legibilidade da especicaao. A ferramenta mais comum c usada durante a ER foi um portal web interno, acess vel a todos os stakeholders, onde a equipe de projeto depositava e mantinha os requisitos. A maioria das equipes executam vrias rodadas de ER. A maioria dos a projetos envolvem a deniao de prottipos, que variam desde simples c o mock-ups at prottipos operacionais. Muitos projetos tambm verie o e cavam e validavam os requisitos com m ltiplos stakeholders. Vrias u a equipes fazem uso de cenrios para validar os requisitos. a As equipes que obtiveram mais sucesso foram aqueles usaram mtodos e de modelagem avanados como modelos OO, entre outros. Contudo, c no abandonaram modelos bsicos, por exemplo, o modelo de entidadea a relacionamento ou diagrama de transiao de estados. Nestes casos, tenc taram criar um modelo mais completo do sistemas. A construao de c prottipos tambm foi empregada para esclarecer requisitos conhecio e dos e descobrir outros. Modelos e prottipos ajudaram especialmente o os clientes e usurios a visualizarem a soluao proposta. a c O envolvimento dos clientes e usurios no processo de ER alm de a e manter bom relacionamento com stakeholders comum entre as equie pes de sucesso. Algumas das melhores prticas fornecidas pelos autores so destacadas a a abaixo. Envolver clientes e usurios por todo o processo de ER permite a melhor compreenso das reais necessidades. a Alocaao de 15% a 30% do esforo total do projeto para atividac c des de ER permite manter especicaao de alta qualidade durante c o projeto. Fornecer modelos e exemplos util. e
90
SECAO 17.5
Artigo: [16]
Manter bom relacionamento com e entre os stakeholders amplia a satisfaao geral. c Desenvolver modelos complementares e prottipos elimina amo big idades e inconsistncias. u e Revises com usurios, cenrios e walk-throughs validam e verio a a cam requisitos, resultando em especicaao mais precisa e maior c satisfaao do cliente. c Para obter sucesso, necessrio integrar os processo tcnicos, sociais e e a e organizacionais para melhor atender as necessidades particulares dos projetos e caracter sticas.
17.5.1
Sidebar
A engenharia de requisitos denota tanto o processo de especicaao de c requisitos atravs do estudo das necessidades de stakeholders quanto o proe cesso de sistematicamente analisar e renar estas especicaoes. Uma esc pecicaao o principal resultado da engenharia de requisitos. Trata-se de c e um relatrio conciso dos requisitos que o software deve satisfazer, ou seja, o das condioes e capacidades atravs das quais o usurio atinge um objetivo c e a ou que o sistema possui para satisfazer um contrato ou padro. Idealmente, a uma especicaao permite que os stakeholders rapidamente conheam o softc c ware e que desenvolvedores compreendam exatamente o que os stakeholders desejam. Apesar da terminologia heterognea encontrada na literatura, a ER deve e incluir quatro atividades separadas, mas relacionadas: eliciaao, modelagem, c validaao e vericaao. Na prtica, estas atividades variam no instante c c a em que so executadas e a na intensidade correspondente para projetos a diferentes. Em cenrio t a pico, primeiro os requisitos so eliciados de qualquer que a seja a fonte dispon (expertos, repositrios ou software existente) e ento vel o a modelados. Eliciar e modelar requisitos so atividades interrelacionadas. a A modelagem descreve uma soluao percebida no contexto do dom c nio da aplicaao usando notaao informal, semi-formal ou formal. H uma gradual c c a normalizaao de modelos at que uma especicaao candidata seja validada c e c e vericada. Isto fornece aos stakeholders uma retroalimentaao da interc pretaao dos requisitos de tal forma que eles possam corrigir os enganos to c a cedo quanto poss vel. Eliciaao c Eliciaao freq entemente tratada como simples questo de entrevista c e u a com usurios ou anlise de documentos, embora muitos outros mtodos de a a e eliciaao estejam dispon c veis. Alguns enfatizam sesses em grupo na forma o
91
de workshop, outros so empregados principalmente para eliciar requisitos a de tipos espec cos de sistemas. Eliciaao tambm inclui atividades que c e exploram como software pode satisfazer objetivos organizacionais, quais as alternativas existentes e como afetam os vrios stakeholders. a Modelagem Expertos tm proposto vrios mtodos de modelagem e linguagens de ese a e pecicaao para tornar requisitos precisos e consistentes. Tradicionalmente c esses mtodos tm separado os dados, funoes e aspectos de comportamento e e c dos requisitos. Tambm tm especicado software atravs de um ou mais e e e modelos distintos. Prottipos, por exemplo, tentam criar um modelo opeo racional que stakeholders podem experimentar diretamente. Paul Ward e Stephen Mellor, seguidos por muitos outros, proporam extenses para os modelos bsicos. Muitas das extenses esto direcionadas o a o a para a modelagem de sistemas de tempo real. Avanos na programaao c c e no projeto orientados a objetos introduziram uma abordagem mais integrada para a modelagem de requisitos. Alm disso, mtodos de modelagem e e avanados tentam estabelecer uma ligaao mais prxima entre modelos e a c c o voz do cliente, a viso dos stakeholders e objetivos do negcio. a o Validaao e Vericaao c c O objetivo da validaao de requisitos certicar de que estes atendem as c e intenoes dos stakeholders. Est sendo especicado o software correto? Em c a outras palavras, a validaao examina um produto de trabalho (por exemc plo, uma especicaao) para determinar a conformidade desta com as nec cessidades dos stakeholders. Vericaao, por outro lado, determina se a c especicaao consistente com os requisitos. O software est sendo especic e a cado corretamente? Ou seja, constata se a especicaao est consistente c a internamente atravs de provas matemticas ou tcnicas de inspeao. e a e c Uma questo importante na validaao e vericaao de requisitos est na a c c a classicaao destes com o propsito de prioriz-los. Focalizar em requisitos c o a de alta prioridade antes de considerar aqueles de menor prioridade pode reduzir, de forma signicativa, os custos e a duraao de projetos. Alm do c e mais, por toda a ER deve ser atualizada as prioridades dos requisitos. Por exemplo, durante a eliciaao, checar as prioridades pode assegurar que elas c continuam adequadamente reetindo as necessidades dos stakeholders. Isto destaca a natureza recorrente da validaao e vericaao de requisitos. c c Mtodos para validaao e vericaao de requisitos so relativamente ese c c a cassos. Revises com pares, inspeoes, walk-throughs e cenrios esto entre o c a a as propostas mais proeminentes. O registro de decises e as razes pertio o nentes so uteis. a
92
SECAO 17.6
Artigo: [3]
17.6
Artigo: [3]
Denir requisitos dif e cil, apesar dos progressos. Assim como em outros campos, pesquisadores tm proposto mtodos e e para lidar com os problemas e praticantes eventualmente adotam alguns deles. Neste sentido, pode haver distncia entre o que proposto a e e o que praticado. Este um cenrio comum na engenharia de softe e a ware e, particularmente, na engenharia de requisitos. Atualmente, muitos engenheiros de software reconhecem que qualquer descriao de uma nova abordagem para resolver um problema dif na c cil engenharia de software deve vir da experincia prtica ou ser acome a panhada por uma descriao de pelos menos uma aplicaao real da c c abordagem em um problema signicativo na ind stria e avaliaao do u c sucesso do esforo. Poucos artigos tm divulgado mtodos que no c e e a foram experimentados em cenrios reais. a A separaao entre pesquisa e prtica pode ser exemplicada. A sec a paraao entre requisitos funcionais e no funcionais um exemplo. c a e Pesquisadores insistem na distinao. Para os praticantes, em muitos c casos a distinao no clara. Outro exemplo. A ER foi desenvolvida c a e com especial atenao para sistemas grandes, unicos, para um unico c cliente o que exigia um contrato entre cliente e desenvolvedor. Nestes casos, a implementaao de menos recursos do que o contrato contic nha signicava erro. Para a realidade de muitos desenvolvedores de hoje, a realidade bem diferente. O software para o mercado e noe e vas verses so constantemente produzidas. Pesquisadores enfatizam o a a distinao entre o que o sistema far sem referncia a como isto ser c a e a feito. Tambm no h recurso para tudo que o cliente deseja e, em e a a conseqncia, necessrio estabelecer uma prioridade entre os requisiue e a tos. Por ultimo, requisitos so essencialmente incompletos. E comum a situaoes onde o prprio cliente no tem uma clara noao de suas nec o a c cessidades em determinado instante de tempo ou, muda esta opinio a com o passar do tempo. A ER visa oferecer uma base de engenharia para a anlise convencia onal de sistemas. Geralmente esta base emerge atravs de mtodos e e e ferramentas provenientes, em maioria, de pesquisadores. A anlise de requisitos a primeira fase do ciclo de vida de desenvola e vimento de software.
93
17.7
Artigo: [25]
Uma vez que a ER une o mundo informal das necessidades dos stakeholders ao mundo formal do comportamento de software, a questo a principal no se deve ser usado mecanismos formais, mas quando a e empreg-los. a No contexto da engenharia de sistemas, uma compreenso da teoria e a prtica de sistemas relevante para a ER. Isto inclui atividades de caa e racterizaao de sistemas, identicaao das fronteiras correspondentes c c e gerncia de seus ciclos de vida. ER tambm envolve a atividade de e e anlise de sistemas, tradicionalmente encontrada no mundo de sistea mas de informaao. c A ER freq entemente considerada como a atividade inicial (fronte u end) do processo de desenvolvimento de software. Em geral verdade, e embora tambm sejam freq entes mudanas nos requisitos durante o e u c desenvolvimento e, inclusive, aps disponibilizado para uso. Dessa o forma, RE desenvolve um papel importante na gerncia de mudanas. e c Contudo, boa parte do servio de ER realizado no in c e cio do ciclo de vida do projeto, anal, erros de requisitos tais como requisitos no a compreendidos ou omissos so mais caros de serem corrigidos posteria ormente no ciclo de vida. Em geral poss estimar custos de projeto, cronogramas e a viabie vel lidade tcnica a partir de especicaoes precisas de requisitos. e c A eliciaao de requisitos talvez a atividade mais freq entemente c e u considerada como o primeiro passo no processo de engenharia de requisitos. O termo eliciaao prefer a capturar para evitar a c e vel ` sugesto de que os requisitos esto dispon a a veis para serem coletados atravs da simples emisso de questes apropriadas. e a o Informaoes obtidas durante a eliciaao de requisitos freq entemente c c u exigem a interpretaao, anlise, modelagem e validaao antes que o c a c engenheiro de requisitos sinta-se confortvel com uma descriao deles. a c Um dos mais importantes objetivos da eliciaao encontrar quais proc e blemas precisam ser resolvidos e da identicar as fronteiras do sistema. As fronteiras denem, em um alto n vel, onde o sistema nal se encaixa no ambiente operacional corrente. As tarefas que usurios correntemente executam ou aquelas que eles a desejam executar so freq entemente representadas atravs de casos a u e de uso, que exibem a viso externa dos requisitos de sistemas. a
94
SECAO 17.7
Artigo: [25]
As tcnicas de eliciaao de requisitos dependem do tempo e recursos e c dispon veis para o engenheiro de requisitos e, naturalmente, o tipo de informaao que se deseja eliciar. Tcnicas tradicionais. Questionrios, c e a entrevistas e anlise de documentaao existente, modelos de processo e a c outros manuais de sistemas existentes. Tcnicas de eliciaao de grupo. e c JAD um exemplo. Prottipos. Na presena de incertezas acerca dos e o c requisitos ou quando feedback cedo esperado. Tcnica orientada a e e modelo. Fornece modelo espec co para o tipo de informaao a ser c registrada. Tcnicas cognitivas. Tcnicas originalmente desenvolvidas e e para aquisiao de conhecimento para sistemas baseados em conhecic mento. Dado o grande conjunto de tcnicas para eliciar requisitos, alguma e orientaao deve ser fornecida com o propsito de guiar seus usurios. c o a Mtodo um mecanismo atravs do qual esta orientaao pode ser e e e c oferecida. Modelagem a construao de descrioes abstratas que so suscet e c c a veis de interpretaao. Modelos podem ser empregados para representar um c grande faixa de produtos do processo de ER. O contexto de muitas atividades de ER e sistemas de software uma e organizaao na qual o desenvolvimento realizado ou na qual um sisc e tema ir operar. A modelagem de um empresa freq entemente ema e u pregada para capturar o objetivo de um sistema atravs da descriao e c do comportamento da organizaao na qual o sistema ir operar. c a Modelar objetivos particularmente util a engenharia de requisitos. e ` Objetivos de alto n do negcio podem ser paulatinamente renavel o dos como parte do processo de eliciaao, conduzindo a requisitos que c podem ser operacionalizados. Sistemas de informaao grandes geralmente usam e geram considerveis c a volumes de informaao. Essa informaao precisa ser compreendida, c c manipulada e gerenciada. Decises cuidadosas precisam ser feitas o acerca de quais informaoes o sistema necessitar representar e como c a a informaao retida pelo sistema corresponde a fenmenos reais reprec o sentados. A modelagem de dados fornece a oportunidade de tratar estas questes na ER. Tradicionalmente, MER (modelo de entidades e o relacionamentos entre elas) empregado para este tipo de modelagem e e anlise. Entretanto, a modelagem orientada a objetos, que emprega a classes e hierarquias de objetos tem sido cada vez mais empregada. Uma parte signicativa do processo de ER refere-se a descrioes do c dom nio. O modelo de dom nio fornece uma descriao abstrata do c mundo no qual o sistema desejado ir operar. a
95
Requisitos no funcionais so geralmente mais dif a a ceis de serem expressos em forma mensurvel, tornando mais dif a anlise corresa cil a pondente. Um benef relevante da modelagem de requisitos a oportunidade cio e de anlise que esta oferece sobre os modelos produzidos. a ER no apenas o processo de descoberta e especicaao de requisia e c tos. Inclui tambm um processo de facilitaao efetiva da comunicaao e c c desses requisitos entre os diferentes stakeholders. A forma como os requisitos so documentados desempenha um papel relevante para a a leitura, anlise, reescrita e validaao deles. Notaoes e linguagens de a c c especicaao o principal foco de pesquisa. c e Gerncia de requisitos tem sido reconhecida como elemento crucial. e Neste sentido, importante no apenas escrever requisitos, mas tambm e a e realizar tal tarefa de forma suscet vel ao rastreamente por parte de vrios interessados, com o propsito de gerenciar a evoluao deles ao a o c longo do tempo. Este rastreamento denido como a habilidade de e descrever e seguir a vida de um requisito tanto adiante quanto para trs, ou seja, da origem at documentos gerados posteriormente e desa e tes para aqueles que os precederam. A descriao expl c cita de requisitos condiao necessria para que estes e c a possam ser validados e para que conitos entre stakeholders possam ser resolvidos. Relembre que validaao o processo de estabelecer que c e os requisitos e modelos eliciados fornecem uma perspectiva precisa dos requisitos. H quem arme que descrioes usadas na ER deveriam ser refutveis. a c a Aquelas que no o so deveriam ser renadas. a a Mudanas na documentaao de requisitos necessitam ser gerenciadas. c c O m nimo envolve tcnicas e ferramentas de gerncia de conguraao e e c e controle de verso e exploram ligaoes de rastreabilidade para monia c torar e controlar o impacto de mudanas em diferentes partes do doc cumento. Mudanas t c picas incluem a adiao de requisitos, remoao e c c eliminaao de erros. c O engenheiro de requisitos deve possuir habilidades sociais e tcnicas. e As sociais so necessrias para a interaao com uma variedade de a a c stakeholders, o que inclui potencialmente pessoas que no possuem a habilidades tcnicas. As tcnicas para a interaao com projetistas e e e c desenvolvedores. Muitos sistemas no atendem as necessidades de seus clientes por, a ao menos em parte, uma ER no efetiva. ER geralmente tratada a e
96
SECAO 17.8
Artigo: [33]
como atividade que consome tempo, burocrtica e que envolve proa cesso t pico de contrato. Esta atitude est mudando a medida que a a ` ER est sendo reconhecida como atividade cr a tica em qualquer processo de engenharia de sistemas. Muitas mudanas, por exemplo, vec locidade esperada de desenvolvimento, possibilidade de mudana e ouc tras esto determinando como os sistemas devem ser desenvolvidos. A a necessidade de software mais fcil de ser usado, rpido e melhor contia a nua crescendo e, em conseqncia, a ER ter que continuar evoluindo ue a para lidar com estes novos cenrios de desenvolvimento. a
17.8
Artigo: [33]
Pode-se observar a ER de duas dimenses. A primeira bem peculiar, o e trata-se de uma tentativa de caracterizar o trabalho que precisa ser feito, ou seja, consistem em problemas correspondentes. A segunda consiste em soluoes, ou esforos de pesquisa que podem contribuir c c para resolver os problemas. Engenharia de Requisitos (ER) o ramo da engenharia de software e que se preocupa com necessidades do mundo real para funoes de sisc temas de software assim como as restrioes pertinentes. ER tambm c e considera o relacionamento desses fatores para oferecer preciso as esa ` pecicaoes do comportamento de software. H um destaque para a c a importncia de objetivos do mundo real, que motivam o desenvola vimento de um sistema de software. Isto representa o porqu e o e qu de um sistema. Tambm deve ser dada nfase para a preciso de e e e a especicaoes. O resultado ser utilizado para analisar os requisitos, c a validar o que os stakeholders desejam, projetar o que projetistas devem construir e vericar que eles foram feitos corretamente. No se pode a omitir um tratamento apropriado para as constantes mudanas, e na c necessidade de reutilizar parcialmente especicaoes, como engenheic ros freq entemente fazem em outros ramos da engenharia. u
97
Parte IV
Como gerenciar requisitos?
98
Em um cenrio de produao, espera-se que a fbrica de software em a c a questo tenha o seu plano de gerncia de requisitos bem denido e conhecido a e pelos praticantes. Este pode no ser o seu caso. Neste ponto, apesar de a muitas informaoes terem sido fornecidas, muitos tm diculdades de colocc e a las em funcionamento. Se este o cenrio, ento voc deve ler esta parte! e a a e
Bom, e agora, o que eu fao?
99
18
Uma bssola u
Uma receita para a gerncia de requisitos particularmente util para e e aqueles que esto executando estas atividades pela primeira vez. A proposta a que segue no tem a pretenso de eximir o leitor de uma anlise cuidadosa a a a das atividades de gerncia de requisitos. Uma excelente referncia sobre o e e assunto encontrada em [24]. O que segue uma proposta enxuta, come e pat com a losoa de grande impacto e pouca burocracia adotada neste vel texto. A proposta prescreve a execuao das seguintes atividades, a serem ajusc tadas conforme o cenrio em questo. a a Compreenda o problema Compreenda as necessidades dos usurios a Dena o sistema Gerencie continualmente o escopo e mudanas c Rene a deniao do sistema c Construa o sistema correto Gerencie o processo de requisitos
18.0.1
Compreenda o problema
As etapas abaixo visam a identicaao precisa do problema. Aps a c o identicaao, um acordo deve ser estabelecido com os clientes acerca da c descriao realizada. c 100
1. Obtenha um acordo (compromisso) acerca do problema em questo. a 2. Compreenda as causas principais (raiz dos problemas). 3. Identique os stakeholders, usurios ou atores do sistema. a 4. Dena as fronteiras do sistema. 5. Identique restrioes impostas a soluao. c ` c
18.0.2
Compreenda as necessidades dos usurios a

Personalize uma entrevista conforme o sistema a ser descrito. A tcnica e de entrevista foi discutida na seao 17.2 (pgina 81). c a Entreviste stakeholders identicados anteriormente. Se o n mero for u pequeno, entreviste todos. Caso contrrio, contente-se com algo em a torno de 5 a 15 stakeholders. Identique as 10 principais necessidades apresentadas pelos stakeholders. Registre as denioes inesquec c veis das necessidades apresentadas nas prprias palavras fornecidas por eles. o Descreva tais necessidades no documento Viso. Personalize-o cona forme as necessidades do projeto. Inicie a rastreabilidade de requisitos. Faa um workshop. c 1. Execute uma sesso de brainstorming para identicar e renar a caracter sticas. 2. Organize as caracter sticas por prioridade, criticalidade e utilidade. Execute workshops com freqncia para obter informaoes e avaliar os ue c resultados do emprego de prottipos. o
18.0.3
Denio do sistema ca
Crie uma deniao do produto. Divulgue amplamente e obtenha um c acordo quanto a deniao. ` c Acrescente atributos como prioridade, importncia, utilidade, risco, a esforo, estabilidade e verso conforme a necessidade. Dena requisitos c a questes envolvendo licenas de uso, documentaao, questes legais e o c c o de legislaao, entre outras. c
101
CAP ITULO 18
Uma bssola u
Torne o documento Viso o principal documento do projeto. Facilite a o acesso a ele. Identique aquele pelo qual todas as mudanas de c caracter sticas devero ser realizadas. Faa com que a empresa tenha a c sempre um documento Viso corrente. a
18.0.4
Gerencie continualmente o escopo e mudanas c

1. Baseado nas estimativas de esforo, determine um marco para cada c ediao do documento Viso usando como atributo o n mero de verso. c a u a 2. Obtenha concordncia do cliente quanto ao escopo. a 3. Comunique e gerencie expectativas em todos os lugares. 4. Gerencie mudanas atravs de marcos (baseline). Use um documento c e Delta Viso para alteraoes no documento Viso. Certique-se de que a c a o responsvel pelo controle de mudanas tomar as decises dif a c a o ceis. 5. Instale um sistema de gerncia de requisioes de mudana para ree c c gistr-las e certique-se de que todas cheguem a gerncia de controle a ` e de mudanas por este sistema. c
18.0.5
Rene a denio do sistema ca

1. Sempre dever existir uma ERS. a 2. Certique-se de que todos estejam familiarizados com tal especicaao. c 3. Faa com que a rastreabilidade de requisitos permita navegar entre c casos de uso e caracter sticas. 4. Certique-se de todos os requisitos no funcionais foram denidos. a
18.0.6
Construindo o sistema correto

1. Realize uma anlise de riscos para identicar aquilo que a empresa a no pode arcar com se estiver incorreto. Desenvolva um plano de a V&V para os resultados obtidos. 2. Neste momento, aqueles que iro testar o sistema devero iniciar o a a planejamento dos testes. 3. Se estiver dispon vel uma equipe de controle de qualidade, ento o a papel de monitorar e avaliar o processo de requisitos e os planos de V&V devero ser assumidos pela mesma. a 4. Para integrar elementos de projeto e requisitos faa uso de casos de c uso e as realizaoes destes. c
102
5. Realize marcos de testes de aceitaao peridicos para validar o trabalho c o e assegurar cont nuo envolvimento do cliente.
18.0.7
Gerencie o processo de requisitos

1. O responsvel pelo documento Viso dever realizar revises peridicas a a a o o para avaliar o status da equipe, gerar relatrios e auxiliar neste esforo. o c 2. Monitore o processo da especicaao de requisitos de software para c assegurar que o conte do do documento Viso est sendo adequadau a a mente considerado nos requisitos detalhados. 3. Antes que mudanas signicativas sejam introduzidas, certique-se de c que o processo de reviso de controle de mudanas ser executado. a c a
103
Consideraoes nais c
Dominar a confecao da Especicaao de Requisitos de Software (ERS) c c um objetivo que exige investimento. Subjacente ao texto est uma abore a dagem de grande impacto e pouca burocracia. Ou seja, destaque para a produao imediata de resultados baseada no emprego de tcnicas que c e tm mostrado benef e cios. Em conseqncia, foram omitidas extensas apreue sentaoes e discusses de abordagens alternativas, o que no tira o mrito c o a e que possam ter.
19
19.1
Referncias adicionais e
Requirements Engineering Journal http://rej.co.umist.ac.uk/
19.2
Ferramentas
A Survey of Requirements Engineering Tools http://www.systemsguild.com/GuildSite/Robs/retools.html. Ferramentas comerciais para engenharia de requisitos http://easyweb.easynet.co.uk/iany/other/vendors.htm 104
SECAO 19.3
O que falta fazer?
19.3
O que falta fazer?

1. Modelagem de dom nio. Ressaltar que a modelagem de objetos pode ser de dom nio, da anlise ou de projeto. O modelo de dom a nio, ou glossrio visual, contm apenas objetos que fazem sentido para a e o negcio em questo. o a 2. Contemplar a referncia [6]. e 3. Contemplar a referncia [14]. e 4. Alguns diagramas empregam notaao mista, envolvendo UML e a cric atividade do autor. Devem ser revistas, seguir o padro UML. a
105
Bibliograa
[1] ISO/IEC 12207. Standard for Information Technology Software life cycle processes Life cycle data. IEEE/EIA 12207.1, april 1998. [2] Frank Armour and Granville Miller. Advanced Use Case Modeling. Object Technology Series. Addison-Wesley, 2001. [3] Daniel M. Berry and Brian Lawrence. Requirements Engineering. IEEE Software, pages 2629, march/april 1998. [4] IEEE Standards Board. IEEE Guide for Devoloping System Requirements Specications Std 1233. IEEE Press, december 1998. [5] IEEE Standards Board. IEEE Guide for Information Technology System DenitionConcept of Operations (ConOps) Document Std 1362. IEEE Press, march 1998. [6] IEEE Standards Board. IEEE Recommended Practice for Software Requirements Specications Std 830. IEEE Press, june 1998. [7] B. W. Boehm. Software Engineering Economics. Prentice-Hall, 1981. [8] Alan Davis. Achieving Quality in Software Requirements. Software Quality Professional, pages 3744, june 1999. [9] Alan M. Davis and Peter A. Freeman. Introduction Requirements Engineering. IEEE Transactions on Software Engineering, 17(3), 1991. [10] Alan M. Davis and Pei Hsia. Giving Voice to Requirements Engineering. IEEE Software, pages 1215, march 1994. [11] Gregor Engels and Luuk Groenewegen. Object-oriented modeling: a roadmap. In Proceedings of the conference on The future of Software engineering, pages 103116. ACM Press, 2000. [12] Richard E. Fairley and Richard H. Thayer. The concept of operations: The bridge from operational requirements to technical specications. In Richard H. Thayer and Merlin Dorfman, editors, Software Engineering: The Development Process, pages 121131. John Wiley & Sons, 2002. 106
BIBLIOGRAFIA
[13] Staurt R. Faulk. Software Requirements: A Tutorial. In Merlin Dorfman and Richard H. Thayer, editors, Software Engineering. IEEE Press, 1997. [14] Donald G. Firesmith. Use Case Modeling Guidelines. In Proceedings of TOOLS USA99. IEEE Computer Society, 1999. [15] Jr. Frederick P. Brooks. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 20(4):1019, april 1987. [16] Hubert F. Hofmann and Franz Lehner. Requirements Engineering as a Success Factor in Software Projects. IEEE Software, pages 5866, july/august 2001. [17] Pei Hsia, Alan Davis, and David Kung. Status Report: Requirements Engineering. IEEE Software, pages 7579, november 1993. [18] Pei Hsia, Alan Davis, and David Kung. Why is requirements engineering underused? IEEE Software, pages 69, march 1994. [19] Russel R. Hurlbut. A Survey of Approaches for Describing and Formalizing Use Cases. Dispon em http://www.iit.edu/rhurlbut/xpt-trvel 97-03.html. [20] Tim Korson and John D. McGregor. Understanding object-oriented: a unifying paradigm. Communications of the ACM, 33(9):4060, 1990. [21] Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context. Addison-Wesley, 2000. [22] Craig Larman. Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and the Unied Process. Prentice-Hall, second edition, 2001. [23] Dean Lengwell. Features, Use Cases, Requirements, oh My! The Rational Edge, 2001. http://www.therationaledge.com/content/dec 00/t usecase.html. [24] Dean Lengwell and Don Widrig. Managing Software Requeirements: A Unied Approach. Object Technology Series. Addison-Wesley, 2000. [25] Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a roadmap. In Proceedings of the conference on The future of Software engineering, pages 3546. ACM Press, 2000. [26] Object Management Group (OMG). Unied Modeling Language: Superstructure, version 2 edition, 2002.
107
BIBLIOGRAFIA
[27] Roger S. Pressman. Software Engineering: A Practitioners Approach. McGraw-Hill, 5th edition edition, 2001. [28] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unied Modeling Language Reference Manual. Addison-Wesley, 1999. [29] Jawed Siddiqi and M. Chandra Shekaran. Requirements Engineering: The Emerging Wisdom. IEEE Software, pages 1519, march 1996. [30] Alan Snyder. The Essence of Objects: Concepts and Terms. IEEE Software, pages 3142, january 1993. [31] William Swartout and Robert Balzer. On the Inevitable Intertwining of Specication and Implementation. Communications of the ACM, 25(7):438440, 1982. [32] William M. Wilson, Linda H. Rosenberg, and Lawrence E. Hyatt. Automated Analysis of Requirement Specications. In ICSE97, pages 161171, 1997. [33] Pamela Zave. Classication of research eorts in requirements engineering. ACM Computing Surveys (CSUR), 29(4):315321, 1997.
108

2+ +artigo+ Requisitos +Prof+Fabio+2005

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2+ +artigo+ Requisitos +Prof+Fabio+2005

Hochgeladen von

Copyright:

Verfügbare Formate

Anlise de Sistemas Agil: a

Instituto de Informatica Universidade Federal de Goias 22 de Maro de 2005 c

No coberto neste texto a

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

Verso preliminar a 22 de Maro de 2005 c

Como gerenciar requisitos?

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

10.1 Em um sistema que compreende processamento que realizado sem e

10.2 Ao identicar atores humanos lembre-se de no particulariz-los desa a

11.2 Perspectiva simplicada do universo dividia em duas partes: software

11.3 Comprador efetiva compra de itens previamente selecionados, o que

Verso preliminar a 22 de Maro de 2005 c

13.1 O relacionamento include entre casos de uso uma relao de dee ca

13.2 O comportamento de um caso de uso inclu executado no momento do e

Verso preliminar a 22 de Maro de 2005 c

17.1 O diagrama de estados ilustra as vrias fases de desenvolvimento de a

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

Adaptado de [16]. Analista, Desenvolvedor e SQA so pratia cantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

O que ser feito O que a cliente deseja

Problemas cujas solues, se existirem, so desconhecidas

Problemas que so passveis de serem solucionados

Especicao de Requisitos de Software (ERS) ca

Verso preliminar a 22 de Maro de 2005 c

Especicao de Requisitos de Software (ERS) ca

Projeto, implementao, testes, manuteno

Definio do Sistema (comportamento externo) Soluo

Parte do mundo de interesse

hardware, procedimentos, pessoas, ...

Figura 1.2: Problemas de interesse do cliente so decompostos pelos engenheiros a

A existncia de e problemas fazem emergir diculdades.

Uma ERS deve satisfazer necessidades e, dessa forma, resolver problemas.

Verso preliminar a 22 de Maro de 2005 c

S se pode construir o (projeto e implementao) o que ca foi previamente denido (anlise). a

Verso preliminar a 22 de Maro de 2005 c

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

Eu quero uma torta assim!

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a

Verso preliminar a 22 de Maro de 2005 c

O modelo cascata (Figura 3.1) criticado na literatura por vrios motie a 26

Sistemas existentes Clientes Regulamentos Domnio Entradas Padres

Verso preliminar a 22 de Maro de 2005 c

Processo da engenharia de requisitos

Anlise de Sistemas (processo)

Omisso, dvida ou outra dificuldade detectada

Verso preliminar a 22 de Maro de 2005 c

Separao entre especicao e implementao ca ca ca

Separao entre especicao e implementao ca ca ca

Especicao e ca implementao se ca intercalam benecamente ao longo do tempo.

Verso preliminar a 22 de Maro de 2005 c

Verso preliminar a 22 de Maro de 2005 c

Copyright c Fbio Nogueira de Lucena a