Mdulo VI Requisitos de Software Pedro de Alcntara dos Santos Neto

FICHA BIBLIOGRFICA

PRESIDENTE DA REPBLICA Luiz Incio Lula da Silva MINISTRO DA EDUCAO Fernando Haddad GOVERNADOR DO ESTADO DO PIAU Wilson Martins UNIVERSIDADE FEDERAL DO PIAU Luiz de Sousa Santos Jnior SECRETRIO DE EDUCAO A DISTNCIA DO MEC Carlos Eduardo Bielschowsky COORDENADORIA GERAL DA UNIVERSIDADE ABERTA DO BRASIL Celso Costa SECRETRIO DE EDUCAO DO ESTADO DO PIAU Antnio Jos Medeiros COORDENADOR GERAL DO CENTRO DE EDUCAO ABERTA A DISTNCIA DA UFPI Gildsio Guedes Fernandes SUPERITENDENTE DE EDUCAO SUPERIOR NO ESTADO Eliane Mendona CENTRO DE CIENCIAS DA NATUREZA Helder Nunes da Cunha COORDENADOR DO CURSO DE SISTEMA DE INFORMAO NA MODALIADE DE EAD Lus Cludio Demes da Mata Souza COORDENADORA DE MATERIAL DE DIDTICO DO CEAD/UFPI Cleidinalva Maria Barbosa Oliveira DIAGRAMAO Joaquim Carvalho de Aguiar Neto

APRESENTAO

Um Sistema de Informao (SI), ou qualquer outro software, tem seu incio associado idia de desenvolv-lo. A partir desse momento, necessrio iniciar uma srie de reunies para se aprofundar conhecimento nas regras que envolvem a operao do sistema. O conjunto de atividades que auxilia a obteno de informaes a respeito de como o sistema deveria ser criado, juntamente com uma representao desses conceitos em modelos que sejam utilizados para o desenvolvimento, faz parte das atividades de Requisitos e Anlise. Nesta apostila apresentamos um detalhamento dessas atividades, guiadas a partir de vrios exemplos prticos ilustrando sua execuo. Na Unidade I detalhamos os conceitos associados ao Fluxo de Requisitos, diretamente relacionado obteno de informaes dos clientes para se elaborar um documento que descreve suas necessidades. Na Unidade II apresentamos o Fluxo de Anlise, associado modelagem das informaes obtidas durante o levantamento de requisitos, porm, transformando-as em um nvel mais prximo dos desenvolvedores. apresentado tambm um mtodo para contagem do tamanho de um sistema, baseado na Especificao de Requisitos e Anlise. Na Unidade III exibimos os exemplos completos de diversos artefatos utilizados para exemplificarmos o levantamentos de requisitos, convocao e exibio dos resultados de uma reunio, alm da reviso dos requisitos e reviso da anlise.

SUMRIO GERAL
UNIDADE I ................................................................................................... 7 O FLUXO DE REQUISITOS ........................................................................ 7 1. O Fluxo de Requisitos ............................................................................. 9 1.1. Qualidade dos requisitos ................................................................ 10 1.1.1. Correo .................................................................................. 10 1.1.2. Preciso ................................................................................... 11 1.1.3. Completeza .............................................................................. 11 1.1.4. Consistncia ............................................................................ 12 1.1.5. Priorizao............................................................................... 12 1.1.6. Verificabilidade ....................................................................... 12 1.1.7. Modificabilidade ..................................................................... 13 1.1.8. Rastreabilidade ........................................................................ 13 1.2. Atividades do Fluxo de Requisitos ................................................ 14 1.1.9. Definio do Escopo ............................................................... 15 1.1.10. Identificao dos Requisitos ................................................. 18 1.1.11. Detalhamento dos Requisitos ................................................ 22 Detalhamento dos Casos de uso ........................................................... 29 1.1.12. Definio dos Prottipos de Interface ................................... 35 1.1.13. Reviso dos Requisitos ......................................................... 41 1.3. Exerccios ....................................................................................... 42 2. Tcnicas de Apoio ao Levantamento de Requisitos ............................. 45 1.4. Oficinas de requisitos ..................................................................... 45 2.1.1. Personalizao ......................................................................... 46 2.1.2. Sesses .................................................................................... 47 2.1.3. Fechamento ............................................................................. 49 1.5. Revises ......................................................................................... 50 2.1.4. Participantes ............................................................................ 52 2.1.5. Conduo................................................................................. 53 1.6. Exerccios ....................................................................................... 56 UNIDADE II ................................................................................................ 60 ANLISE DE SOFTWARE ........................................................................ 60 3. A Linguagem UML ............................................................................... 62 1.7. A Origem da UML ......................................................................... 62 1.8. Vises ............................................................................................. 64 1.9. Modelo de Elementos ..................................................................... 65 3.1.1. Classes ..................................................................................... 65 3.1.2. Objetos .................................................................................... 67 3.1.3. Estados .................................................................................... 68 3.1.4. Pacotes..................................................................................... 68 3.1.5. Componentes ........................................................................... 69 3.1.6. Relacionamentos ..................................................................... 69 1.10. Mecanismos Gerais ...................................................................... 74 1.11. Diagramas .................................................................................... 75 5

3.1.7. Diagrama de Casos de uso ...................................................... 75 3.1.8. Diagrama de Classes ............................................................... 76 3.1.9. Diagrama de Objetos ............................................................... 76 3.1.10. Diagrama de Estados ............................................................. 77 3.1.11. Diagrama de Seqncia ......................................................... 78 3.1.12. Diagrama de Colaborao ..................................................... 79 3.1.13. Diagrama de Atividades ........................................................ 80 3.1.14. Diagrama de Componentes ................................................... 81 3.1.15. Diagrama de Implantao ..................................................... 81 1.12. Consideraes Finais .................................................................... 82 1.13. Exerccios ..................................................................................... 82 4. O Fluxo de Anlise................................................................................ 84 1.14. Atividades do Fluxo de Anlise ................................................... 84 4.1.1. Identificao das Classes......................................................... 85 4.1.2. Organizao das Classes ......................................................... 94 4.1.3. Realizao dos Casos de Uso .................................................. 95 4.1.4. Reviso da Anlise .................................................................. 97 1.15. Exerccios ..................................................................................... 98 5. Anlise de Pontos de Funo ................................................................ 99 5.1 Introduo a Anlise de Pontos de Funo ................................... 103 5.2 O Processo de Contagem .............................................................. 105 5.2.1 Contagem de Funes de Dados ............................................ 112 5.2.2 Contagem de Funes de Transao ...................................... 114 5.3 Contagem Estimativa de Pontos de Funo .................................. 120 5.3.1 Contagem de funes de dados .............................................. 122 5.3.2 Contagem de funes de transao ........................................ 124 5.4 Planejamento e Gesto de Projetos com PF .................................. 130 5.5 Viso crtica da APF ..................................................................... 131 5.6 Exerccios ...................................................................................... 134 UNIDADE III............................................................................................. 139 EXEMPLOS DE ARTEFATOS ................................................................ 139

UNIDADE I O FLUXO DE REQUISITOS

RESUMO Nesta unidade apresentamos o Fluxo de Requisitos, que est diretamente associado obteno de informaes junto aos clientes sobre o problema a ser tratado. Em muitos projetos esse fluxo pouco explorado, o que normalmente resulta no desenvolvimento de um software que no atende aos anseios dos usurios finais. No Capitulo 1 apresentamos as atividades prescritas no fluxo, com a exemplificao de como realizar cada atividade, a partir da explicao de como execut-la no sistema exemplo. No Captulo 2 apresentamos algumas tcnicas utilizadas como forma de apoiar o levantamento de requisitos, mais especificamente, tcnicas para se conduzir uma reunio com o objetivo de se obter informaes e construir um conceito em conjunto, alm de tcnicas para revisar artefatos produzidos durante o desenvolvimento de software.

SUMRIO DA UNIDADE
UNIDADE I ................................................................................................... 7 O FLUXO DE REQUISITOS ........................................................................ 7 1. O Fluxo de Requisitos ............................................................................. 9 1.1. Qualidade dos requisitos ................................................................ 10 1.1.1. Correo .................................................................................. 10 1.1.2. Preciso ................................................................................... 11 1.1.3. Completeza .............................................................................. 11 1.1.4. Consistncia ............................................................................ 12 1.1.5. Priorizao............................................................................... 12 1.1.6. Verificabilidade ....................................................................... 12 1.1.7. Modificabilidade ..................................................................... 13 1.1.8. Rastreabilidade ........................................................................ 13 1.2. Atividades do Fluxo de Requisitos ................................................ 14 1.1.9. Definio do Escopo ............................................................... 15 1.1.10. Identificao dos Requisitos ................................................. 18 1.1.11. Detalhamento dos Requisitos ................................................ 22 Detalhamento dos Casos de uso ........................................................... 29 1.1.12. Definio dos Prottipos de Interface ................................... 35 1.1.13. Reviso dos Requisitos ......................................................... 41 1.3. Exerccios ....................................................................................... 42 2. Tcnicas de Apoio ao Levantamento de Requisitos ............................. 45 1.4. Oficinas de requisitos ..................................................................... 45 2.1.1. Personalizao ......................................................................... 46 2.1.2. Sesses .................................................................................... 47 2.1.3. Fechamento ............................................................................. 49 1.5. Revises ......................................................................................... 50 2.1.4. Participantes ............................................................................ 52 2.1.5. Conduo................................................................................. 53 1.6. Exerccios ....................................................................................... 56

UNIDADE I O FLUXO DE REQUISITOS

1. O Fluxo de Requisitos
Um requisito pode ser definido como um desejo, necessidade, restrio ou expectativa de um cliente com relao a um produto. Ou seja, um cliente, ao pensar em um produto, possui muitos aspectos
Um requisito pode ser resumido como algo desejado por um usurio, com relao a um produto.

em sua mente. Esses aspectos necessitam ser capturados, definidos, organizados, verificados e validados para ento chegarmos a uma Especificao de Requisitos. Esse documento o principal artefato gerado no incio do desenvolvimento de software. Seu principal objetivo prover um enunciado completo, claro e preciso dos requisitos de um produto de software. Logicamente, a gerao de uma especificao de requisitos para um produto novo bem mais complexa que para produtos existentes. Em muitos casos, os prprios clientes no sabem ao certo o que querem. Na verdade, a maioria dos clientes consegue identificar bem o que no quer. Nesses casos, o uso da prototipao algo muito recomendado. Mais adiante vamos detalhar essa tcnica que pode auxiliar bastante o fluxo de requisitos. importante detalhar de forma precisa o que o Fluxo de Requisitos. Esse fluxo rene as atividades que visam a obter o enunciado completo, claro e preciso dos requisitos de um produto de software. Os requisitos devem ser levantados pela equipe do projeto, normalmente denominados Analistas de Requisitos (ou Engenheiros de Requisitos) em conjunto com representantes do cliente, usurios chaves e at contando com a presena de especialistas da rea de aplicao, uma vez que o projeto pode envolver conhecimentos no triviais que exijam a presena de profissionais altamente especializados com a rea de negcio do produto a ser construdo.

O conjunto de tcnicas empregadas para levantar, detalhar,

O conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto compe a Engenharia de Requisitos.

documentar e validar os requisitos de um produto compe a Engenharia de Requisitos. O resultado principal do fluxo dos requisitos o documento de Especificao de Requisitos, que abreviaremos aqui de ER.

1.1.

Qualidade dos requisitos

Os requisitos de um software correspondem a uma parte muito importante do desenvolvimento. Por conta disso, necessrio que eles possuam diversas caractersticas de qualidade, permitindo assim seu uso de forma adequada e eficiente. A seguir apresentamos uma lista de caractersticas de qualidade de requisitos, baseadas nas caractersticas de qualidade de requisitos existentes no livro de Wilson de Pdua Paula Filho. As caractersticas citadas nesta seo podem ser utilizadas como critrios para se realizar uma reviso de requisitos, conforme ser apresentado mais a frente. Mas para isso, necessrio entender o que est relacionado a cada uma das caractersticas.

1.1.1.

Correo

Uma Especificao de Requisitos correta se todo requisito presente nela realmente um requisito do produto a ser construdo. No existe ferramenta que garanta a correo de uma Especificao de Requisitos. Para verific-la, deve-se checar a coerncia da Especificao dos Requisitos do Software com outros documentos da aplicao, como manuais, protocolos, regras de negcio, etc. Uma outra forma de se tentar garantir a correo solicitar a aprovao formal da ER, por parte do cliente, sem a qual o projeto no poder prosseguir. Por conta disso que normalmente ao final de um levantamento de requisitos feita uma reviso do trabalho 10

executado. A idia por trs disso e encontrar falha na qualidade dos requisitos. Essas falhas podem estar associadas a qualquer uma das caractersticas apresentadas nessa seo.

1.1.2.

Preciso

Uma ER precisa se todo requisito presente possuir apenas uma nica interpretao, aceita tanto pelos desenvolvedores quanto pelos usurios chaves. Em particular, uma ER deve ser compreensvel para todo o seu pblico alvo, e deve ser suficiente para a especificao dos testes de aceitao do produto. Recomenda-se a incluso no glossrio da ER de todos os termos contidos no documento que possam causar ambigidades de entendimento. Uma forma de verificar a preciso de uma ER solicitar sua leitura por pessoas que no tenham participado da sua elaborao, para analisarmos se possvel entender o que foi especificado de forma precisa.

1.1.3.

Completeza

Uma ER completa se reflete todas as decises de especificao que foram tomadas, no contendo clusulas de pendncias. Uma ER completa deveria conter todos os requisitos significativos relativos a funcionalidade, desempenho, restries de desenho, atributos e interfaces externas, alm de definir as respostas do software para todas as entradas possveis, vlidas e invlidas, em todas as situaes possveis. Tambm fundamental para uma ER possuir um glossrio de todos os termos tcnicos e unidades de medida, facilitando assim seu entendimento por todos. bastante comum que organizaes criem suas pseudo ERs contendo apenas um pedao da especificao do comportamento do 11

software desejado, normalmente ignorando os requisitos no funcionais.

1.1.4.

Consistncia

Uma ER consistente se no h conflitos entre nenhum dos subconjuntos de requisitos presentes, tais como conflitos com o mundo real, como por exemplo, formatos de relatrios ou cores de sinalizao; conflito lgico ou temporal entre aes, quando, por exemplo, um requisito diz que a ao A deve ser realizada antes da ao B, e outro diz o contrrio; e uso de termos diferentes para designar o mesmo objeto do mundo real, como, por exemplo, lembrete versus aviso. Mais uma vez notamos que um reviso fundamental para o fechamento de uma ER, pois apenas a partir de uma ao como essa que poderemos descobrir certas incorrees.

1.1.5.

Priorizao

Uma ER priorizada se cada requisito classificado de acordo com a respectiva importncia e estabilidade. A estabilidade estima a probabilidade de que o requisito venha a ser alterado no decorrer do projeto, com base na experincia de projetos correlatos. A priorizao classifica o requisito de acordo com graus de importncia atribudos pelos clientes. A priorizao algo importante pois normalmente os custos e prazos podem ser bastante limitados, sendo importante descrever o que mais importante e deve ser tratado primeiro. Da mesma forma, aquilo que ainda est em processo de mudana no pode ser considerado para implementao, pois ainda no estvel e qualquer ao aplicada pode ser trabalho perdido!

1.1.6.

Verificabilidade

12

Uma ER verificvel se todos os seus requisitos so verificveis. Um requisito verificvel se existir um processo finito, com custo compensador, que possa ser executado por uma pessoa ou mquina e que mostre a conformidade do produto final com o requisito.

1.1.7.

Modificabilidade

Uma ER modificvel se sua estrutura e estilo permitirem a mudana de qualquer requisito, de forma fcil, completa e consistente. A modificabilidade geralmente requer que haja uma organizao coerente, com ndices e referncias cruzadas; ausncia de redundncia entre requisitos; definio separada de cada requisito. Essa caracterstica est diretamente relacionada ao uso de padres e convenes, de forma que o trabalho seja feito utilizandose formatos pr-definidos e adequados ao uso.

1.1.8.

Rastreabilidade

Uma ER rastrevel se permite a fcil determinao dos itens que antecederam o surgimento do item e os itens que foram gerados por conta da existncia do item. Isso normalmente est associado a dois tipos de rastreabilidade: Rastreabilidade para trs, na qual deve ser possvel localizar a origem de cada requisito. Deve-se sempre saber por que existe cada requisito e quem ou o que o originou. Isso importante para que se possa avaliar o impacto da mudana daquele requisito, e dirimir dvidas de interpretao. Rastreabilidade para a frente, na qual deve ser possvel localizar quais os resultados do desenvolvimento que sero afetados por cada requisito. Isso importante para garantir que os itens de anlise, desenho, cdigo e testes abranjam 13

todos os requisitos e para localizar os itens que sero afetados por uma mudana nos requisitos.

1.2.

Atividades do Fluxo de Requisitos

O Fluxo de Requisitos composto por vrias atividades, que devem ser executadas dentro de um processo de desenvolvimento. Diversos processos de software possuem atividades de requisitos em suas definies. As atividades que sero explanadas neste texto representam as atividades mais comuns relacionadas Engenharia de Requisitos. No entanto, a anlise de um processo de software especfico pode conter diversas diferenas para as atividades aqui apresentadas.

Figura 1: Atividades do Fluxo de Requisitos.

As atividades do Fluxo de Requisitos so exibidas na Figura 1. A figura exibe um diagrama de atividades. O primeiro elemento na 14

figura (uma circunferncia preta) conhecida como atividade inicial. Ela representa o ponto de partida do fluxo. Os demais retngulos com os lados arredondados representam atividades. Existem duas barras de sincronizao na figura, que representam que as atividades posteriores s iniciam quando a todas as atividades com ligao sincronizao tenham encerradas. Assim, conforme exibido, a Reviso dos requisitos apenas tem inicio quando o Detalhamento dos Requisitos e Detalhamento dos Prottipos de Interface tenha sido concludas. A Definio do Escopo a atividade onde o escopo do projeto vai ser identificado. De forma geral, a partir do escopo deve ser possvel identificar o que faz parte do projeto e o que no faz parte. A Identificao dos Requisitos a atividade relacionada obteno de tudo o que os clientes desejam com relao ao produto. Isso inclui a definio do comportamento esperado, bem como outros aspectos que devero ser identificados. O Detalhamento dos Requisitos a atividade em que os desenvolvedores, com a ajuda dos clientes, iniciam a desdobrar os requisitos em funes do produto, de forma que o atendimento seja completo. A Definio dos Prottipos de Interface a atividade em que verses iniciais das interfaces do produto so criadas, com o intuito maior de deixar claro o que se deseja, reduzindo assim problemas com requisitos questionveis ou difceis de serem entendidos. Por fim, a Reviso dos Requisitos a atividade em que feita uma reviso geral do trabalho realizado, com o intuito de remover problemas com relao aos requisitos identificados e todos os seus desdobramentos executados.

1.1.9.

Definio do Escopo

15

O Escopo de um Projeto algo fundamental para o seu sucesso. Sua definio algo considerado simples, porm, ela deve ser feita de forma prudente e com a participao dos principais envolvidos. Em muitos momentos, o escopo do projeto dever ser reanalisado, pois ele que define o que est includo e o que no est includo no projeto em questo. Um escopo mal estruturado poder levar a falhas de cronograma e de oramento, uma vez que tarefas acima do previsto podem ser consideradas, ao invs daquilo o que realmente deveria ter sido includo. De forma geral, o escopo de um projeto pode ser simplesmente um texto, que define o que deve fazer parte do projeto. Neste material, utilizaremos um exemplo para demonstrar todas as atividades aqui descritas. Ser usado como exemplo prtico algo muito apropriado ao tema: uma ferramenta para Gerncia de Requisitos. Esse projeto ser denominado ReqG. Para isso, precisamos definir o escopo de um projeto cujo objetivo produzir uma ferramenta para gerenciamento de requisitos. Uma sugesto de tal escopo pode ser visualizada a seguir: Gerenciar os requisitos de um projeto de software, registrando todos os dados associados sua definio, de forma a cobrir todas as atividades previstas no fluxo de requisitos.
Uma boa forma de evitar problemas com os clientes de um projeto definir bem o escopo e, para evitar falsas expectativas, detalhar o que no faz parte dele. Por isso to importante termos uma seo com os Limites do Produto.

Na definio acima, podemos notar que o trabalho a ser realizado foi definido. Certamente, nem todos os que chegarem a ler o enunciado podero entender por completo o que deve ser feito. Isso acontece por que apenas as pessoas com conhecimento no problema e no que est sendo definido, poderiam entender por completo essa definio. No entanto, ela poder ser revista em diversos momentos do projeto. Algo comum definio do escopo , definir tambm, o que est fora dele. Isso normalmente ajuda aos clientes entenderem de 16

forma mais precisa o que est e o que no est includo no projeto. A definio do que no est includo de forma explcita evita falsas expectativas. Isso normalmente favorece o processo de comunicao com o cliente. importante ressaltar que o fluxo de requisitos um fluxo com grande participao do cliente. Ele quem define praticamente tudo o que ser produzido nessa fase do desenvolvimento. Assim, quanto mais mecanismos utilizarmos para facilitar a comunicao com o cliente, melhores resultados obteremos com sua execuo. Continuando com nosso exemplo, uma forma interessante de definir o escopo seria detalhar o que no est includo no projeto. Essa seo normalmente conhecida como Limites do produto. Uma sugesto para tal seo seria a seguinte: 1. O ReqG no controlar a execuo de tarefas no projeto, apenas registrar os dados relacionados a requisitos. 2. O ReqG no gerar documentos editveis com a especificao de requisitos. Os dados ficam registrados no sistema e s podem ser alterados por ele. 3. O ReqG no controlar qualquer aspecto do custo ou do cronograma de execuo. 4. O backup e a recuperao das bases de dados do sistema ficam a cargo da administrao de dados e no sero providas pelo ReqG. 5. O ReqG no ter ajuda on-line. Uma dvida que deve pairar naqueles que iniciam a elicitao de requisitos justamente saber quem deveria participar dessa definio. Normalmente, qualquer organizao possui alguns nveis hierrquicos em sua constituio. As pessoas no nvel hierrquico mais alto geralmente possuem um bom conhecimento sobre tudo o que realizado na organizao. Isso acontece por que eles devem ser comunicadas e devem acompanhar o que se passa dentro da instituio. Essas pessoas formam um grupo ideal para se utilizar na definio de um produto, pois conhecem o todo. Ao aprofundarmos 17

nas definies dos requisitos, necessitaremos da participao de outras pessoas, com conhecimentos mais aprofundados em detalhes especficos. Assim, para levantar requisitos para uma aplicao que
Importante: para se conhecer bem o que deve ser feito por um produto, devemos comear a conversa com aqueles que entendem um pouco de tudo (diretoria) para depois iniciarmos um aprofundamento nos detalhes (gerncia, chefias).

controle uma empresa, idealmente deveramos conversar com os diretores da organizao, uma vez que eles devem saber exatamente como a organizao funciona. Em seguida, devemos conversar com os gerentes, pois normalmente existe um gerente para cada rea prioritria da organizao. Ele conhece tudo o que se passa em seu setor. Para que seja possvel detalhar o que realmente feito em cada setor, deveramos conversar com os funcionrios que executam as atividades ou com os chefes de setores em um nvel inferior aos gerentes. Baseado nos exemplos acima, vamos dar incio a um trabalho prtico, que dever ser feito por cada aluno da disciplina, que acompanhar este material: a definio de um Software de Controle de Emprstimos Pessoais. Esse software ser definido por voc leitor, ao longo deste material. De incio, procure definir o escopo e os limites do produto, de forma similar ao que fizemos com o software de gesto de requisitos. Utilize os modelos e o exemplo de ERSw que estamos apresentando como exemplo e que est contido na pgina da disciplina.

1.1.10.

Identificao dos Requisitos

A Identificao do Requisitos a atividade que prescreve a criao de uma lista dos requisitos para a aplicao a ser desenvolvida. Cada requisito nada mais que um descrio textual de algo que deveria ser considerada durante o desenvolvimento de software. Os requisitos podem ser divididos em dois tipos: requisitos funcionais e requisitos no funcionais. Os requisitos funcionais esto diretamente ligadas ao comportamento que a aplicao deve conter. 18

Por exemplo, em um sistema de controle de uma biblioteca, o Emprstimo de Livro exige que o usurio a tomar um livro emprestado esteja cadastrado, ativo, que o livro desejado esteja disponvel, no reservado, no seja cativo e que o usurio no esteja com cinco livros emprestados, considerando que esse seja o nmero mximo de emprstimos simultneos permitido. Tudo isso
Requisitos funcionais esto associados a comportamento. Requisitos no funcionais esto ligados a caractersticas que o comportamento deve possuir.

que foi comentado so detalhes do comportamento que o software deve ter. Um outro tipo de requisito so os no funcionais. Nesse caso, eles no expressam comportamento, mas caractersticas que o comportamento deve ter. Por exemplo, supondo o mesmo requisito, Emprstimo de Livro, podemos exigir como requisito de desempenho que ele funcione com at 100 usurios simultneos, gerando respostas em at 8s. Outro requisito no funcional associado ao emprstimo seria que ele fosse simples de usar, permitindo que uma pessoa conseguisse utiliz-lo apenas lendo o manual associado. Observe que tudo o que relatamos neste pargrafo no trata de comportamento, mas de caractersticas desejadas ao comportamento especificado no pargrafo anterior. A lista dos requisitos, conforme comentado, a expresso que resumo aquilo que os clientes desejam. importante a participao dos Analistas de Requisitos para que seja possvel organizar esses pedidos e estruturar o texto que os descreve de forma que seja possvel analisar e desdobrar esses pedidos em funes do produto. A Tabela 1 exibe a lista de requisitos para a ferramenta de gesto de requisitos que queremos construir.

Tabela 1: Exemplo de definio de requisitos.

ID RF1 Requisitos

Requisito

Descrio O sistema deve permitir cadastrar e controlar todos os aspectos relacionados aos requisitos de um projeto, permitindo visualizar isso e 19

acompanhar sua evoluo, incluindo as pessoas que trabalharam no projeto, os analistas e gerente do projeto. RF2 Casos de uso O sistema deve possibilitar a especificao dos casos de uso, registrando sua descrio, atores, prottipos de tela associados, relacionando aos requisitos que deram origem ao caso de uso. Deve ser possvel realizar uma reviso dos requisitos e casos de uso, utilizando critrios definidos pelos prprios gerentes de projetos, de forma independente dos demais projetos. Deve ser possvel que os clientes possam acompanhar a evoluo do projeto a qualquer momento, consultando tudo o que foi feito. Deve ser possvel liberar o acesso ao sistema por projeto, indicando o seu gerente. Assim, para se ter acesso ao sistema, dever ser adquirida uma licena para um projeto. A partir disso o gerente ficar responsvel por definir quem dever usar o sistema, seja para trabalhar na especificao de requisitos, como um dos Engenheiros de Requisitos, seja como cliente consultando o resultado do trabalho realizado. Deve ser possvel gerar a especificao na forma de um documento no editvel, contendo todos os dados registrados do projeto.

RF3

Reviso

RF4

Acompanhamento dos clientes

RF5

Liberao de acesso por projeto

RF6

Gerao da documentao

Podemos notar que os requisitos exibidos na Tabela 1 so simples e exibem as necessidades de algum que trabalha com requisitos. Podemos notar tambm que muito precisa ser detalhado para que tenhamos algo pronto para implementar. A Tabela 2 exibe a lista de requisitos no funcionais identificados para o produto. Observe que tambm so definies simples, mas que retratam o que se deseja com relao a certas caractersticas ligadas ao comportamento do software. So exemplos disso a definio do ambiente (Web), o uso de uma 20

tecnologia especfica (MySQL) ou a definio de valores para atributos de qualidade como a quantidade de acessos simultneos e o tempo mximo de resposta. importante ressaltar que requisitos no funcionais

necessitam da definio de valores que permitam sua verificao. Dizer que o sistema deve ser rpido no ajuda muito aos testadores que devem verificar se o produto atende ER. Mas especificar um tempo mximo de resposta em um contexto pr-definido ajuda bastante.
Tabela 2: Exemplo de requisitos no funcionais.

ID RNF1 Ambiente

Requisito

Descrio O sistema deve funcionar em ambiente Web, sendo compatvel com os principais navegadores do momento: Internet Explorer, Firefox, Safari e Chroma. O sistema deve ser desenvolvido utilizando-se a linguagem Java, com as tecnologias JSF e Hibernate. O sistema deve utilizar o banco de dados MySQL. O sistema deve ser construdo para funcionar com 100 usurios simultneos, com respostas de at 5s quando utilizado em rede local. O sistema deve restringir o acesso por meio de senhas. Deve-se ter um controle no registro de senha, de forma a impedir o uso de senhas consideradas fceis. Um usurio com conhecimento bsico em informtica e conhecimento nos conceitos de requisitos deveria ser capaz de operar o sistema com um curso de 30 minutos.

RNF2 Linguagem

RNF3 Banco de dados RNF4 Desempenho

RNF5 Segurana

RNF6 Usabilidade

O desenvolvimento de software pode ser entendido como uma srie de transformaes que nos levam dos desejos dos clientes, at um produto executvel, que atende a tais desejos. O incio das transformaes acontece quando iniciamos uma srie de 21

reunies para entender o que os clientes desejam. Essa lista, normalmente abstrata, devendo ser melhor detalhada sob diversos aspectos, at que possa ser utilizada como guia para a implementao. Na identificao dos requisitos, todos os aspectos levantados pelos clientes devem ser registrados, da forma mais parecida com o que foi relatado. Nas prximas atividades esses aspectos sero transformados em elementos que permitem seu detalhamento de forma estruturada. No entanto, isso no acontece nesse momento. Mais uma vez ressaltamos que essa atividade necessita ser realizada com pessoas que possuam uma boa viso geral do todo. A idia obter uma descrio de alto nvel do que precisa ser feito, deixando para depois um detalhamento aprofundado de cada questo. Nesse momento voc dever fazer o levantamento dos requisitos relacionados ao Software de Controle de Emprstimos Pessoais, que iniciamos anteriormente. Crie uma lista de requisitos desejados por voc com relao a esse produto. Utilize o exemplo que disponibilizamos na pgina para iniciar o trabalho. Dessa forma, voc deve ir alterando as sees sendo descritas.

1.1.11.

Detalhamento dos Requisitos

O Detalhamento dos Requisitos a atividade em que cada requisito identificado deve ser desdobrado em funes do produto. Cada funo do produto pode estar ligada a um nico requisito,
Casos de uso podem ser considerados as funes que um produto deve oferecer.

assim como pode estar relacionada a mais de um requisito. O desdobramento de requisitos gera a identificao dos Casos de Uso. Esse um termo comum na Engenharia de Requisitos e que precisa ser entendido. Um Caso de Uso uma fatia de funcionalidade do sistema, que representa algo de valor para seus usurios e que no apresenta nem lacunas nem superposio com outros casos de uso. 22

Os casos de uso so acionados por atores. Um ator a representao de um papel no sistema. Atores podem representar um grupo de usurios, um outro sistema, com o qual o sistema sendo especificado deve interagir. Um caso de uso normalmente interage com apenas um ator, mas pode interagir com mais de um. Segundo Wilson de Paula Pdua Filho, atores podem ser identificados atravs dos seguintes critrios: quem est interessado em certo requisito; quem se beneficiar diretamente do produto; quem usar informao do produto; quem fornecer informao ao produto; quem remover informao do produto; quem dar suporte e manuteno ao produto; quais os recursos externos usados pelo produto; quais os papis desempenhados por cada usurio; quais os grupos de usurios que desempenham o mesmo papel; quais os sistemas legados com os quais o produto deve interagir; o tempo, quando casos de uso so disparados

periodicamente, de forma automtica. Atores so usados para representar tambm sistemas externos. Estes podem incluir sistemas legados, produtos comerciais de software e outros componentes de um sistema maior. Podem incluir recursos de hardware e comunicao que devam receber um tratamento especfico por parte do produto (por exemplo, dispositivos de hardware que normalmente no fazem parte do ambiente operacional). Um ator especial o Tempo, usado para acionar casos de uso que so disparados periodicamente, de forma automtica. 23

Atores modelam papis associados ao uso do produto. Papis e no pessoas!

Cada

diagrama

de

casos

de

uso

especifica

os

relacionamentos entre casos de uso e atores. Os relacionamentos indicam a existncia de comunicao entre atores e casos de uso. Um caso de uso pode estar associado a mais de um ator, quando a sua execuo requer a participao de diferentes atores. Normalmente, a comunicao ser representada como ligao sem direo. Nesses casos, convencionado que a iniciativa de comunicao parte do ator. Quando a iniciativa parte do caso de uso (por exemplo, alarmes, mensagens, dados enviados para outros sistemas etc.), a comunicao deve ser direcionada para o ator.

Figura 2: Exemplo de ator e caso de uso.

A Figura 2 exibe um exemplo de como representado um caso de uso e atores em UML. O caso de uso Exemplo de caso de uso est associado a dois atores, o Ator e o Outro ator. Observe que o relacionamento entre o caso de uso e o ator Outro ator possui uma seta com indicao de direo. Isso mostra o fluxo de dados no relacionamento. Dessa forma, as informaes devem fluir do caso de uso para o ator. Assim, aps a identificao dos requisitos, necessrio detalhar quais casos de uso sero necessrios para atender aos desejos identificados pelos clientes. Nesse momento inicia-se uma tarefa um pouco mais nobre dos Engenheiros de Requisitos, que justamente ajudar aos clientes a pensar como estruturar o software, em termos de funes, para atender aos anseios identificados. Como exemplo iremos analisar os requisitos contidos na Tabela 1. Inicialmente, utilizaremos o RF1. O texto que o descreve est detalhado no quadro a seguir: 24

O sistema deve permitir cadastrar e controlar todos os aspectos relacionados aos requisitos de um projeto, permitindo visualizar isso e acompanhar sua evoluo, incluindo as pessoas que trabalharam no projeto, os analistas e o gerente do projeto. De acordo com o texto do requisito, o sistema deve
Os requisitos so textos que descrevem os desejos dos clientes. Simples assim! Os casos de uso so as tradues dos requisitos em funes do produto, feita por Engenheiros de Requisitos, a partir de um entendimento do que foi solicitado e o que pode ter em um produto.

possibilitar o cadastro e controle dos requisitos. Com isso, podemos identificar uma funo do produto: Cadastro de requisitos. Esse ento j um dos casos de uso do sistema. Temos que lembrar que existem requisitos funcionais e no funcionais. Assim, teremos que decidir se iremos realizar esse cadastro em uma nico caso de uso ou se sero necessrios dois casos de uso: um para o cadastro de requisitos funcionais e outro para requisitos no funcionais. Nesse caso em especfico, vamos utilizar um nico caso de uso para registro dos requisitos. Vamos nomear esse caso de uso como Gesto de requisitos. Observe que ainda no texto do RF1 existe a meno ao registro das pessoas que trabalharam no projeto. Isso significa que teremos que ter um cadastro dos envolvidos no projeto. Teremos que cadastrar o gerente, os analistas e os clientes envolvidos. Com isso, possvel identificar que teremos que cadastrar os membros do projeto. Isso d origem a mais um caso de uso: Gesto de membros. Continuando a anlise, podemos concluir que para atender o RF2 necessrio termos um caso de uso para a Gesto de Casos de Uso. No entanto, teremos tambm que registrar os atores associados ao caso de uso. Isso nos remete a um novo caso de uso: Gesto de atores. O RF3 nos remete diretamente a um novo casos de uso: Reviso. No entanto, foi descrito que as revises sero guiadas por critrios independentes para cada projeto. Isso nos leva a identificar um novo caso de uso: Gesto de critrios.

25

O RF4 solicita que exista uma forma de acompanhar o projeto. Isso pode ser resumido a partir de uma funo do produto que gerasse a especificao em um formato contendo todos os dados do projeto, incluindo requisitos, casos de uso, atores, etc. Por conta disso, o RF4 nos levou a identificar mais um caso de uso: Gerao da especificao. O RF5 refere-se ao modelo de negcio do sistema. Para que alguma pessoa possa utiliz-lo, necessrio que seja realizado o cadastro de um projeto. Esse projeto ter um gerente associado que a partir de ento poder cadastrar seus analistas, clientes, os requisitos, casos de uso, etc. Dessa forma, necessrio que o sistema tenha um caso de uso Cadastro de Projeto, que deve ser feito por um administrador, responsvel por liberar acesso ao software. No entanto, um projeto possui diversos dados adicionais, como seu escopo, datas de execuo, limites do produto, que tambm precisam ser cadastrados. Isso nos leva a ter um outro caso de uso, para que seja possvel registrar tais dados, mas utilizado pelo gerente do projeto e no pelo administrador do sistema. Esse caso de uso ser chamado de Controle do projeto. Analisando o RF6, que trata da gerao da documentao, encontramos algo interessante: a necessidade relatada j est contemplada com a proposio do caso de uso Gerao da documentao, identificado quando analisamos o RF4. Dessa forma, ao propormos o caso de uso Gerao da documentao, no s atendemos ao requisito RF4, como tambm ao RF6. Pronto! Acabamos de identificar todos os casos de uso do sistema, a partir de uma leitura e interpretao dos requisitos expostos pelos clientes. Mais uma vez importante ressaltar que embora tenhamos feito isso de forma direta neste documento, isso normalmente exige reunies, discusses e um amadurecimento, no s por parte dos clientes, como tambm dos profissionais envolvidos, para que se cheguem a uma determinao do produto a ser desenvolvido. A Figura 3 apresenta um diagrama de casos de 26

uso com todos os casos de uso identificados, alm dos atores associados. Outro ponto importante de ressaltar que isso no representa ainda o detalhamento dos requisitos. necessrio descrever de forma muito mais aprofundada os requisitos. Isso inclui a determinao das regras de negcio associadas a cada um dos casos de uso. Isso ser feito na prxima subseo.

O diagrama de casos de uso nos d uma visao ampla do sistema, exibindo as funes existentes e os papis associados.

Figura 3: Diagrama de casos de uso para o ReqG.

A exibio dos casos de uso e os requisitos que foram utilizados para sua gerao, nos do uma idia da rastreabilidade dos requisitos.

A Tabela 3 exibe a lista de casos de uso identificados no sistema, com uma identificao dos requisitos associados. Essa ligao entre caso de uso e requisito conhecida como 27

rastreabilidade. Isso nos permite saber quem deu origem a qu. Assim, possvel saber que um requisito deu origem a um determinado caso de uso.
Tabela 3: Lista de casos de uso identificados.

ID UC1

Caso de uso Gesto de Requisitos

Requisito associado RF1

Descrio Cadastro de requisitos funcionais e no funcionais associados ao projeto. Cadastro de todos envolvidos no projeto. os

UC2 UC3 UC4 UC5

Gesto de Membros RF1 Gesto de Casos de Uso Gesto de Atores Reviso RF2 RF2 RF3

Definio dos casos de uso do projeto. Definio dos atores que iro interagir no projeto. Reviso de um requisito ou de um caso de uso, observando os critrios pr-estabelecidos no projeto para a reviso. Cadastro de critrios a serem utilizados em uma reviso. Cadastro de um projeto, com definio do seu gerente, feito pelo administrador do sistema. Cadastro de um gerente de projeto, feito pelo administrador do sistema. Controle do projeto, com detalhamento de informaes sobre o mesmo, feito pelo gerente do projeto. Gerao da especificao de requisitos, utilizando um formato pr-definido, contendo todos os dados registrados no projeto.

UC6 UC7

Gesto de Critrios de Reviso Cadastro de Projeto

RF3 RF5

UC8

Gesto de Gerentes

RF5

UC9

Controle de Projetos

RF5

UC10 Gerao da especificao

RF6, RF4

28

UC11 Relatrio de Acompanhamento

RF6, RF4

Emisso de um relatrio contendo uma indicao do estado do projeto, a partir do estado de cada caso de uso que o compe.

A Tabela 4 exibe a lista de atores identificados. importante ressaltar que a identificao de atores muito nos facilita o entendimento do produto. Por isso, fundamental que ao se pensar em uma funo do sistema, haja tambm uma reflexo sobre que grupo deveria utilizar tal funo.
Tabela 4: Lista de atores do projeto.

N 1. 2. 3. 4. Cliente

Ator

Descrio Clientes de um projeto, normalmente responsvel pelo fornecimento de informaes para moldagem do produto. Responsvel pelo controle do uso do sistema, liberando acesso aos Gerentes a partir do cadastramento de um projeto. Responsvel pelo controle de um projeto, definindo a equipe e suas tarefas. Pessoa que faz parte da equipe que trabalha no projeto.

Administrador Gerente Membro

Dando prosseguimento ao nosso trabalho, relacionado ao Software de Controle de Emprstimos Pessoais, necessrio identificar os casos de uso e atores associados ao sistema.

Detalhamento dos Casos de uso

Conforme demonstrado na Seo anterior, o Detalhamento dos Requisitos inicia pela identificao dos casos de uso relacionados s necessidades relatadas pelos fornecedores de requisitos. No entanto, a identificao dos casos de uso apenas o incio do detalhamento. A partir da identificao de um caso de uso, sabemos que uma determinada funo dever existir no sistema. Mas ser necessrio detalhar como ser essa funo. Isso inclui a

29

descrio desses casos de uso, especificando como eles devero funcionar. A atividade de Detalhamento dos Casos de Uso uma subatividade do Detalhamento dos Requisitos. Existem muitas formas de ser descrever um caso de uso. Uma forma muito utilizada e adotada neste trabalho utilizar o conceito de fluxos dos casos de uso. O detalhamento dos fluxos dos casos de uso uma tarefa onerosa e muito importante para a correta especificao do funcionamento de parte de um produto. Cada fluxo detalha passo a passo o que deve acontecer em determinada parte do produto. Essa descrio geralmente feita por meio de textos seguindo formatos pr-estabelecidos. Notaes muito informais so chamadas de histrias de usurio (user stories) e so comumente adotadas por metodologias geis. Cada caso de uso deve possuir ao menos a descrio de suas pr-condies, assim como um fluxo principal, que representa um caminho de execuo que normalmente o mais utilizado para o caso de uso. Um exemplo de fluxo principal apresentado a seguir. Nele, possvel observar que existem passos relacionados com aes do sistema (ReqG) e passos relacionados a aes do ator (Administrador). Fluxo principal 1. O ReqG exibe a Tela de Gesto de Gerentes. 2. O Administrador informa os dados para pesquisa por Gerentes. 3. O Administrador aciona o comando Pesquisar. 4. O ReqG recupera e exibe na lista Gerentes recuperados os Gerentes que atendem aos parmetros de pesquisa informados, ordenados pelo Nome em ordem crescente.

Os fluxos so comumente descritos em linguagem natural, na forma de uma seqncia de passos. Cada passo corresponde a uma ao de um ator ou do produto e que devem aparecer explicitamente como sujeitos da frase. Outros atores podem aparecer como objetos 30

verbais de uma ao. Nesses caso, provavelmente tais atores estejam ligados ao caso de uso utilizando-se setas que indicam a direo da comunicao no diagrama de casos de uso. Condies e iteraes podem aparecer nas descries dos casos de uso (se alguma coisa, para cada coisa faa isso). Um detalhe importante que a descrio dos casos de uso, na forma apresentada neste trabalho, necessitar de um prottipo de interface com o usurio. Isso ser descrito na prxima seo. Por enquanto, iremos nos ater descrio do caso de uso. No entanto, utilizaremos parte de um exemplo que ser completamente includo como anexo deste trabalho. Uma leitura detalhada no Anexo I permitir um bom entendimento dos conceitos apresentados, uma vez que o anexo descreve um sistema real em que foi necessrio aplicar todos os conceitos apresentados neste trabalho. Alm do fluxo principal, que descreve uma parte do caso de uso que provavelmente seja a mais utilizada, existem fluxos alternativos e subfluxos. Os fluxos alternativos (tambm chamados de fluxos excepcionais) so descries de alternativas de execuo que podem ser iniciadas sempre que suas pr-condies forem atendidas. Um exemplo disso apresentado a seguir. Fluxo alternativo Incluso de um Novo Gerente Precondies 1. O Administrador acionou o comando Novo. Passos 1. O Administrador preenche os Dados do Gerente. 2. O Administrador aciona o comando Salvar. 3. O ReqG verifica que no existe um Gerente com email e login informados. 4. O ReqG salva os Dados do Gerente.

Observe que na descrio do fluxo alternativo acima existe a especificao de precondies. Essas precondies detalham o que deve acontecer para que o fluxo entre em execuo. No caso, para que a incluso de um novo gerente acontea, necessrio que o

31

ator associado ao caso de uso acione o comando novo, pois essa a indicao que se deseja que o fluxo seja executado. Nesse fluxo tambm temos algo muito interessante e fundamental na descrio dos casos de uso: a especificao de restries no seu funcionamento. No passo 3 do fluxo especificado que o sistema (ReqG) verificar se uma determinada condio atendida. Isso significa que o fluxo s continuar se ela for verdade. Caso ela no seja verdade, o fluxo no continuar sua execuo. Nesse caso, foi especificada uma condio simples, relacionada verificao da existncia de um gerente com determinadas informaes. No entanto, poderamos ter especificado condies bem mais complexas. Essas condies sero traduzidas nas diversas regras de negcio de um produto durante sua implementao.
O levantamento de requisitos deve detalhar o desejo dos clientes. No devemos introduzir especificidades de desenho ou implementao durante essa atividade. Por isso no aconselhado detalhar mensagens ao usurio, tecnologias, etc.

Outro detalhe importante que devemos ressaltar que no precisamos definir mensagens ao usurio neste momento. A maioria dos iniciantes na descrio de casos de uso tentado a descrever a verificao contida no passo 3 do fluxo alternativo exibido anteriormente contendo uma mensagem ao usurio, normalmente da seguinte forma: O ReqG verifica se no existe um gerente com email informado. Se existir o ReqG emite a mensagem Gerente j cadastrado!. Mas qual o problema em especificar mensagens durante o detalhamento dos casos de uso? Mensagens ao usurio fazem parte do projeto (design) do sistema, uma etapa posterior aos requisitos e anlise. As mensagens devem seguir convenes e padres de usabilidade, no sendo adequado defini-las em um momento em que isso no o foco. Assim, bem melhor apenas identificar as restries e deixar para o momento apropriado a definio completa e correta das mensagens. Os subfluxos so utilizados para descrever conjuntos de passos que foram extrados de algum fluxo por serem grandes, complexos ou com potencial de serem reutilizados em outros fluxos. Seria algo equivalente a extrair um mtodo de um outro mtodo. 32

Para acionar a execuo de um subfluxo necessrio especificar isso de forma direta: O ReqG executa o Subfluxo X. Em casos de uso do tipo CRUD (Create, Read, Update, Delete), que descrevem um cadastro, normalmente contendo funcionalidades para se cadastrar, pesquisar, alterar e excluir algo, uma dvida comum : qual dessas funcionalidades deve ser especificada no fluxo principal do caso de uso? A resposta : qualquer uma. Mas lembre-se que normalmente utilizamos no fluxo principal a funcionalidade que mais comumente utilizada. Uma conveno utilizada neste trabalho foi sempre utilizar as pesquisas como funcionalidade descrita no fluxo principal de casos de uso do tipo CRUD. Em geral, os casos de uso no possuem pr-condies e alguns tem apenas o fluxo principal. Embora existam diversos formatos utilizados para sua descrio, conforme o formato apresentado nos exemplos contidos neste texto, o mais importante que as descries utilizadas sejam inteligveis para quem as l. Dessa forma, o bom senso o maior guia para a descrio dos casos de uso: se uma pessoa consegue ler e entender o que tem descrito, com condies de criar um programa que implemente as descries, ento o caso de uso est bem descrito. No entanto, importante ressaltar que os iniciantes na descrio de casos de uso nem sempre deixam lacunas na descrio que impossibilitam o seu entendimento. Isso muito comum e tende a ser reduzido com a experincia. Para finalizar essa seo, apresentamos a descrio de um caso de uso um pouco mais complexo, que detalha as regras para gerao de um relatrio associado ao nosso exemplo, contido no Anexo I deste texto. Fluxo principal O ReqG exibe a Tela de Relatrio de Acompanhamento. O Membro informa os dados para pesquisa por Projetos. O Membro aciona o comando Pesquisar. 33

O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em ordem crescente. O Membro aciona o comando Gerar Relatrio. Para cada requisito contido no projeto: O ReqG imprime uma linha com o ID, nome, descrio, tipo e estado do requisito, calculado a partir do estado ou a partir dos casos de uso associados. Para cada caso de uso associado ao requisito: O ReqG imprime uma linha com o ID, nome, descrio e estado do caso de uso. O ReqG soma o percentual de concluso de cada caso de uso, de acordo com o seu estado, sendo Identificado (10%), Detalhado (25%), Implementado (75%) e Homologado (100%). Se o requisito possui casos de uso associados: O ReqG calcula o percentual de concluso do requisito a partir da soma de todos os percentuais dos casos de uso, dividido pela quantidade de casos de uso. Seno: O ReqG calcula o percentual de concluso do requisito a partir do estado do requisito. O ReqG calcula o percentual de concluso do projeto a partir da soma de todos os percentuais dos requisitos, divididos pela quantidade de requisitos existentes. Esse exemplo possui alguns pontos interessantes. Ele possui claramente definido em cada passo o seu responsvel, que normalmente o sistema ou o ator. Existe a descrio de diversas regras de negcio, detalhando como calcular alguma coisa. Para isso, foram utilizados condicionais (se) e iteraes (para). Ressaltamos que apenas a leitura do caso de uso no nos permite gerar o relatrio detalhado, pois temos que analisar tambm uma sugesto de formato para tal relatrio. Isso est descrito no Anexo I e ser comentado na prxima seo, que trata da definio dos prottipos de interface. Nesse momento necessrio o detalhamento dos casos de uso identificados ao Software de Controle de Emprstimos Pessoais. Crie a descrio dos casos de uso, sempre levando em considerao a necessidade de termos restries para algumas regras envolvidas no sistema.

34

1.1.12. Interface

Definio dos Prottipos de

A Definio dos Prottipos de Interface especifica, de forma detalhada, os requisitos relacionados as fontes de entrada e sada de dados no produto. Nas interfaces grficas de usurio, existem questes que claramente representam requisitos dos produtos, tais como formatos de dados e comandos. Outros detalhes, como formatos de telas e janelas, so aspectos de desenho da interface de usurio e no devem ser tratados durante a fase de Requisitos. No entanto, a criao de um esboo da interface normalmente auxilia bastante a identificao de regras de negcio, dados a serem utilizados e formatos de campos. extremamente importante definir
Os prottipos de interfaces, durante o levantamento de requisitos, devem ser focados em se descobrir as informaes e restries importantes ao requisito. Nenhum aspecto de execuo ou usabilidade deveria ser tratado nesse momento.

que tecnologia utilizar para gerao desses esboos, uma vez que eles no devem demandar muito esforo e nem deveriam focar em tecnologias especfica, visto que isso pode limitar o espao da soluo sem que haja essa necessidade. Os esboos so apenas sugestes, mas que no deveriam ser seguidos rigorosamente na construo no produto. Eles servem muito mais para detalhar os dados envolvidos nos fluxos do que propriamente para especificar formatos de tela. Exemplos de esboos podem ser construdos utilizando-se as seguintes tecnologias: desenhos mo livre, em papel; leiautes alfanumricos, feitos com um editor de texto, como o Word; leiautes feitos em um editor HTML, como o DreamWeaver; desenhos feitos com uma ferramenta de desenho tcnico, como o Pencil; telas desenhadas em um ambiente de desenvolvimento rpido, como Delphi; 35

telas desenhadas no ambiente definitivo de implementao, utilizando Java Swing. Os esboos devem ser descritos de forma que o usurio

consiga entender seu objetivo e entenda seu funcionamento, independente da tecnologia a ser utilizada. Os campos e comandos existentes nos prottipos devem representar requisitos relacionados aos dados necessrios para se implementar uma determinada funo. importante utilizar formatos independente de tecnologia, para que sua definio final fique apenas para o Projeto (Design). No interessante tentar definir esse formato durante o levantamento de requisitos. Neste trabalho iremos utilizar uma conveno para

especificao de prottipos criados utilizando-se um editor de texto. Essa alternativa bastante vivel por conta da sua facilidade de manipulao, expressividade e, alm disso, pelo fato de estar completamente implementao. Gerao da Especificao Informaes do Projeto Projeto SystemG (texto com at 30 caracteres) Gerente Silio Silvestre Ferreira Freitas (texto com at 100 caracteres) <Pesquisar> Projetos recuperados Projeto Descrio Gerente SystemG Criao de um sistema X Silio Silvestre Ferreira Freitas Frigo Projeto muito interessante Alberto Sobrinho Arajo TecnoComp Manuteno de algo Silio Silvestre Ferreira Freitas <Gerar Especificao>
Figura 4: Exemplo de prottipo simples.

dissociada

de

qualquer

tecnologia

de

A Figura 4 exibe um exemplo de um prottipo simples para uma interface de usurio. Nela existem diversas convenes que guiaro a criao de outras interfaces. A primeira conveno est relacionada s cores utilizadas nas interfaces. Cada cor possui um significado, conforme detalhado na Tabela 5. Um campo com fundo branco indica que ele editvel, ou seja, o usurio poder realizar 36

alteraes nos valores existentes. Campos com uma tonalidade cinza clara so campos com valores dinmicos, preenchidos pelo sistema, mas que no podem ser alterados pelo usurio. As demais partes do prottipo que possuem uma tonalidade cinza mais acentuada so partes fixas e rtulos, que normalmente no so mutveis.
Tabela 5: Conveno relacionada s cores nos prottipos.

Campo altervel. Campo no altervel. Ttulo de interface, rtulo de campo ou comando.

Na Figura 4 temos ainda outras informaes interessantes. O formato de cada campo altervel descrito na forma de um texto, junto ao prprio campo. Isso pode ser visto no campo projeto, que pode conter textos com at 30 caracteres. Quaisquer outras restries associadas podem ser especificadas nesse texto, independente de sua complexidade. Podemos especificar mscaras, condies para que ele seja ocultado ou exibido, valores inicialmente exibidos, etc. Tudo o que for necessrio pode ser especificado no prprio campo. Isso torna muito simples o entendimento do seu formato e do seu funcionamento. Na mesma figura existe ainda a especificao de diversos comandos, descritos a partir dos delimitadores <>. Um comando uma entidade que dispara alguma ao. Note que no definimos se o comando ser um boto, hiperlink, comando de voz ou qualquer outro tipo. O importante deixar claro que existe um comando na tela e que ao ser acionado responsvel por alguma ao. Essa a vantagem de se utilizar prottipos independentes de tecnologia: no temos aderncia a qualquer formato. Isso facilita o desenho definitivo da interface sem limitar o conjunto de alternativas existentes. Outro ponto interessante na figura a existncia de uma tabela com uma lista de valores (Projetos recuperados). Uma tabela 37

algo

comum

na

maioria

dos

sistemas.

Freqentemente

necessitamos especificar tabelas em nossos prottipos, pois elas so muito teis para agrupar informaes correlacionadas. Tambm importante ressaltar algo que geralmente gera muita confuso nos iniciantes em criao de prottipos para o levantamento de requisitos: essas telas nunca vo executar! Assim, fique tranqilo quanto a usabilidade, pois elas no sero usveis! As telas definitivas, feitas com base nesses prottipos que vo executar. Mas por enquanto, temos apenas um esboo daquilo que ser feito em uma fase posterior do desenvolvimento. Quando temos um prottipo e o detalhamento do caso de uso, o entendimento de parte de um produto se torna bastante simples. Veja por exemplo, a descrio do fluxo principal associado ao prottipo exibido na Figura 4. O ReqG exibe a Tela de Gerao da Especificao. O Membro informa os dados para pesquisa por Projetos. O Membro aciona o comando Pesquisar. O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em ordem crescente. O Membro aciona o comando Gerar Especificao. O ReqG gera um documento no formato especificado no arquivo ModeloERSw.doc.

Alguns prottipos possuem campos com formatos mais especficos, conforme apresentado na Figura 5. O campo projeto possui um asterisco que indica que ele obrigatrio. Alm disso, seu contedo contm a especificao que ele conter uma lista de projetos que atendem a uma determinada restrio. Isso significa que essa lista ser carregada dinamicamente, durante a execuo do produto e que seus valores sero trazidos de uma entidade do produto.

38

Dados da Reviso Projeto* Identificador* Descrio* Data* Participantes dos desenvolvedores* Participantes dos clientes Situao* [Lista de Projetos que possuem o usurio corrente como membro] Reviso preliminar de requisitos (texto at 50 caracteres) Reviso preliminar de requisitos (texto at 50 caracteres) 12/12/2010 (data no formato dd/mm/aaaa) [Lista de Membros do Projeto que no sejam clientes] ... [Lista de Membros do Projeto que no sejam clientes] [Lista de Membros do Projeto que sejam clientes] ... [Lista de Membros do Projeto que sejam clientes] [Aberta; Fechada]
Figura 5: Prottipo com campos mais especficos.

Ainda no prottipo exibido na Figura 5, podemos notar que o campo Participantes dos desenvolvedores tambm possui uma especificao de uma lista, porm, podemos notar que esse mesmo campo poder ter mais de um valor. Isso poder ser mapeado sob diversas formas em uma interface definitiva: vrios campos do tipo check box, um campo list, uma tabela, etc. Tipos de Ingresso [Lista de Tipos de Ingresso pr-cadastrados no sistema] ... [Lista de Tipos de Ingresso pr-cadastrados no sistema] [Lista de Effects pr-cadastrados no sistema] ... [Lista de Effects pr-cadastrados no sistema] [Matrcula; Nome]

Effects

Classificao

Figura 6: Exemplo de especificao de prottipo usando editores de texto.

39

Uma modelagem do prottipo, feita utilizando nossas convenes, podem ser mapeadas para diferentes formatos em tecnologias especficas.

Figura 7: Exemplo de interface definitiva similar ao prottipo da figura anterior.

Na Figura 6 temos a especificao de trs campos utilizando nossas convenes. Os dois primeiros campos so multivalorados enquanto que o terceiro pode ser apenas um de dois possveis valores. Na Figura 7 temos um exemplo de como esse prottipo pode ser construdo em um ambiente definitivo (HTML). Note que embora os dois primeiros campos possuam a mesma representao em nosso formato independente de tecnologia, ele pode ter diferentes implementaes em um ambiente definitivo. Mais uma vez ressaltamos que existem diversos exemplos no Anexo I deste documento, que possui a especificao completa de um sistema real. Ele deve servir de base para a criao do nosso trabalho prtico. chegada a hora de realizar a criao dos prottipo para os casos de uso identificados. Lembre-se de seguir o formato independente de tecnologia apresentado aqui e fique atento s convenes definidas.

40

1.1.13.

Reviso dos Requisitos

A reviso dos requisitos a atividade realizada para garantir que o padro prescrito pela organizao foi realmente seguida e que os requisitos identificados atendam aos critrios de qualidade solicitados,
Uma reviso deve ser feita com base em critrios bem definidos.

permitindo

seu

correto

entendimento

e,

por

conseguinte, a realizao do projeto adequado bem como da implementao apropriada. Para a reviso necessrio inicialmente estabelecer os critrios a serem utilizados. Na Seo 2 foram expostos diversos critrios de qualidade para requisitos. Um projeto pode determinar que critrios devem ser utilizados para a realizao das revises, para ento analisar cada requisito luz dos critrios selecionados. Dessa forma, podemos facilmente visualizar que uma reviso nada mais que uma leitura e posterior anlise dos requisitos, tendo em mente aspectos bem pontuais a serem avaliados. De modo geral, pessoas que no sejam os autores da especificao de requisitos seriam mais adequados para a realizao da reviso que os prprios autores. Isso acontece por que normalmente os autores podem ficar cegos quanto a certos problemas. Um exemplo de reviso para parte dos requisitos contidos no Anexo I apresentado a na Tabela 6. Nela podemos notar a anlise de alguns requisitos e casos de uso, com base em critrios prdefinidos. A partir dessa anlise sero registrados os eventuais conflitos e acompanhado os passos para sua resoluo.
Tabela 6: Fragmento da reviso de uma ER.

Nr.

Requisito

Caso de Uso

Ambigidade

Clareza

Completude
No aprovado Aprovado

1 2

RF1 RF2

UC2 UC3

Aprovado Aprovado

Aprovado Aprovado

RF5

UC8

No aprovado

Aprovado

Aprovado

Conflitos No foi especificado a ordem em que os resultados devem ser exibidos. O caso de uso parece que poderia ser agrupado com o caso de uso Gesto de Membros, no havendo

41

necessidade de criao de um caso de uso adicional.

No prximo captulo apresentaremos de forma detalhada uma forma de se conduzir reunies para levantamento de requisitos e para realizao de revises. No Anexo IV existe a reviso por completo, contendo os critrios utilizados e sua explicao, assim como o resultado da avaliao executada. Voc deve criar algo similar para o Software de Controle de Emprstimo Pessoais. Lembre-se de definir os critrio, detalhando como eles sero utilizados, alm de registrar os problemas e as formas de resoluo deles. Com a apresentao do formato para reviso de requisitos, encerramos o detalhamento do Fluxo de Requisitos. Aps uma execuo completa desse fluxo, teremos boas informaes sobre como desenvolver um produto que atenda s necessidades do cliente, porm, ainda sero necessrias vrias transformaes at que o produto seja construdo. Algo que devemos ressaltar bastante para os iniciantes no levantamento de requisitos uma frase contida no livro do Prof. Wilson de Pdua: desenvolver uma especificao de requisitos custa tempo e dinheiro; no faz-la geralmente custa mais tempo e dinheiro ainda!

1.3.

Exerccios

1. Qual a definio de requisito? 2. Qual o objetivo de uma Especificao de Requisitos? 3. Por que a gerao de uma Especificao de Requisitos para um produto novo mais complexa que para produtos existentes? 4. O que o fluxo de requisitos? 5. Quem participa do levantamento de requisitos? 42

6. O que a Engenharia de Requisitos? 7. Cite e explique 3 caractersticas de qualidade de requisitos. 8. Quais so as atividades do fluxo de requisitos? Descrevaas brevemente/ 9. O que o escopo de um projeto? 10. Por que importante se definir os limites do produto? 11. Como deve ser a abordagem em uma instituio para se levantar requisitos junto aos clientes? 12. Qual a diferena entre requisitos funcionais e nofuncionais? 13. Cite 3 exemplos de requisitos funcionais para um Sistema Acadmico. 14. Cite 3 exemplos de requisitos no-funcionais para um Sistema Acadmico. 15. O que um caso de uso? 16. O que so os atores? 17. Como identificar atores? 18. O que devemos fazer para identificarmos casos de uso? 19. Identifique casos de uso e atores para os requisitos descritos na questo 13. 20. Crie um diagrama de casos de uso para os itens identificados na questo anterior. 21. O que um fluxo principal? 22. Qual a diferena entre fluxo principal e fluxo alternativo? 23. Como podemos especificar regras de negcio nos casos de uso? 24. Qual a importncia de um prottipo de interface? 25. Quais so as tecnologias possveis que serem utilizadas para construo de prottipos? 26. Qual a conveno de cores utilizadas para construo de prottipos? O que elas significam?

43

27. Crie um prottipo de tela utilizando as convenes prescritas no captulo, para modelar alguma tela real de algum sistema que voc utilize. 28. Para que serve a reviso dos requisitos? Qual a importncia dos critrios para uma reviso de requisitos?

44

UNIDADE I O FLUXO DE REQUISITOS

2. Tcnicas de Apoio ao Levantamento de Requisitos

Durante o levantamento de requisitos so necessrias diversas reunies. Tais reunies tem como objetivo bsico entender bem as necessidades dos clientes, alm de avaliar se os dados coletados esto adequados e consistentes com as necessidades. Por conta disso so necessrias tcnicas que facilitem a execuo dessas reunies. Neste captulo apresentaremos justamente tcnicas apropriadas para os dois casos citados anteriormente. Boa parte do material deste captulo foi baseado do livro Engenharia de Software de autoria do Prof. Wilson de Pdua Paula Filho.

1.4.

Oficinas de requisitos

As oficinas de requisitos so reunies estruturadas para

Uma oficina de requisitos uma forma de se identificar o que se deseja de forma conjunta com os usurios.

definio conjunta dos requisitos, envolvendo desenvolvedores, usurios e demais especialistas. O tipo de oficina que ser aqui discutido baseado nas tcnicas de JAD, embora existam variantes na literatura. As oficinas de requisitos usam uma tcnica estruturada de conduo de reunies de desenvolvimento, aplicvel a diversas atividades do ciclo de vida do software, sendo especialmente til no levantamento de requisitos. Nessas reunies, denominadas oficinas de requisitos, o levantamento e detalhamento dos requisitos feito em conjunto, com a participao de desenvolvedores e usurios chaves, assim como gerentes, todos unidos para termos uma melhor qualidade no resultado do trabalho. 45

As oficinas de requisitos tendem a apresentar melhores resultados do que os levantamentos baseados em reunies individuais com alguns usurios. Isso acontece por uma srie de razes, dentre elas: elas facilitam o comprometimento dos usurios com poder de deciso e os requisitos;
O levantamento de requisitos utilizando JAD normalmente apresenta resultados muito interessantes.

elas reduzem o prazo de levantamento de requisitos, visto que a reunio com todos os envolvidos tende a ser mais direta que conversas individuais setorizadas;

eliminam requisitos de valor questionvel, uma vez que todos so discutidos nas reunies;

reduzem diferenas de interpretao dos requisitos entre usurios e desenvolvedores, uma vez que as explicaes acontecem ao vivo e com diferentes pontos de vista;

produzem um primeiro esboo das interfaces de usurio, a partir do direcionamento dado pelos prprios usurios no momento das reunies;

trazem a tona, o mais cedo possvel, problemas polticos que possam interferir no projeto. Essas oficinas possuem trs partes bem distintas: a

Personalizao, onde so feitas adaptaes do mtodo para a aplicao; as Sesses propriamente ditas, na qual as reunies so realizadas com a participao de todos os envolvidos; e o Fechamento, com a produo do resultados obtidos.

2.1.1.

Personalizao

A personalizao da oficina de requisitos uma parte simples do processo. Nessa parte as equipes so selecionadas e organizadas, para que haja a participao dos usurios chave para as reunies sejam produtivas, alm de uma orientao sobre como os trabalhos sero conduzidos. 46

Alm do que foi exposto, so feitas as particularizaes necessrias ao projeto, bem como a preparao das instalaes a serem utilizadas para as reunies. Um ponto importante a se discutir nesse momento : quais so os usurios adequados a participarem de uma reunio de levantamento de requisitos? No existe uma resposta genrica e adequada para tal questo, mas existem diretrizes importantes a
A seleo dos participantes das reunies algo que pode facilitar muito o levantamento de requisitos.

serem seguidas. Uma dessas diretivas : nas reunies iniciais, onde so determinados o escopo e os requisitos, mais importante a participao de usurios com um bom conhecimento do todo, embora no tenha conhecimentos aprofundados sobre as partes. Tipicamente, esses usurios so as pessoas da organizao com maior nvel hierrquico. Normalmente chefes, coordenadores, gerentes, diretores possuem um bom conhecimento do todo e pouco das partes. Eles so pessoas importantes para as reunies iniciais de levantamento de requisitos. Uma vez levantados os requisitos iniciais, torna-se importante ter contato com as pessoas que possuem mais conhecimentos detalhados nas partes que compem o produto. chegada a hora de termos o detalhamento dos requisitos, onde teremos que propor prottipos para as interfaces, alm de detalhar as regras de negcios do produto. Para isso os funcionrios com mais conhecimento dos detalhes e provavelmente menos conhecimento do todo, so mais importantes.

2.1.2.

Sesses

As sesses correspondem realizao efetiva das reunies. Todos os integrantes da equipe da oficina devem participar das sesses em tempo integral, para que no se perca tempo em recapitulaes para os ausentes em sesses anteriores. Idealmente, as sesses devem ser conduzidas em local afastado das organizaes dos participantes, visto que muito comum que haja 47

diversas interrupes quando as sesses so realizadas nas instalaes do cliente. Assim, uma boa dica levar as sesses para longe do ambiente dos clientes. Interrupes so altamente prejudiciais, sendo importante avisar todos os participantes sobre essa regras. Telefonemas no devem ser atendidos, os telefones celulares devem ser desligados.
Sem o controle adequado nas sesses, o risco de insucesso aumenta bastante!

Deve-se

planejar

disponibilidade

dos

materiais

necessrios, tais como: computadores: normalmente so necessrios pelo menos 2 computadores (ou notebooks), sendo um para projeo da ER sendo criada e outro para redao da ata da reunio; projetores: pelo menos um projetor necessrio, para que seja possvel exibir o resultado do trabalho e permitir uma discusso de todos; copiadoras: eventualmente pode ser necessrio compartilhar material com os demais participantes; blocos de escrever, flip-charts, quadros brancos, lpis e canetas: em muitos momentos ser necessrio escrever, sendo importante termos materiais para tal fim; lanches: as sesses podem durar um turno inteiro, sendo importante um momento para repor as energias e evitar a desateno nas discusses. Existem papis importantes nas sesses. Cada um possui uma atribuio especfica e pode ser decisivo para o sucesso das reunies. Dentre os papis destacamos: o lder da sesso, responsvel por manter o bom clima e o foco das discusses, que deve dominar tcnicas de conduo de reunio e ser treinado na conduo destas oficinas;

48

os patrocinadores, representantes do cliente, responsveis pela resoluo de conflitos entre grupos de usurios, com poder de deciso para tal;

os representantes dos usurios, com autoridade para tomar decises em nome da respectiva comunidade;

os desenvolvedores, cuja funo bsica durante a oficina deve ser a de fornecer informao sobre a viabilidade das idias levantadas;

o relator, participante da equipe do projeto, encarregado de redigir as atas de reunio. Durante a discusso, as idias devem ser registradas e

simultaneamente exibidas a todos os participantes, seja atravs de quadros brancos, seja atravs de computador com projetor. O lder deve estimular a participao de todos, mantendo o foco, encaminhando a resoluo de conflitos e identificando questes que no possam ser resolvidas durante a sesso. Deve ficar claro para todos o comprometimento que dever existir em relao s concluses da oficina.

2.1.3.

Fechamento

importante apresentar os resultados de uma sesso na forma de uma ata. Isso passa uma imagem mais profissional, alm de demonstrar organizao.

No Fechamento so produzidos os artefatos resultantes da reunio. Isso normalmente inclui partes da ER e atas. Deve-se ter um cuidado especial para as pendncias registradas na reunio e que devem ser resolvidas em uma data acertada por todos. Normalmente no fechamento feita uma apresentao do material produzido, incluindo a Ata, para posterior envio e aprovao por parte dos envolvidos. No Anexo II exibimos um exemplo de uma Agenda para uma reunio de levantamento de requisitos e no Anexo III um exemplo de uma ata para uma reunio. Esses modelo podem ser utilizados para servir de base para criao desses artefatos em um projeto. 49

De modo geral, uma ata deve conter um espao para detalhar os participantes (clientes e desenvolvedor), assuntos discutidos e pendncias. As atas so importantes pois alm de registrarem os assuntos discutidos, envolvidos na discusso e o tempo em que tais discusses apareceram, mostra profissionalismo nas relaes, algo que no comum em todas as empresas que trabalham com o desenvolvimento de software.

1.5.
O
Uma reviso um mecanismo de garantia da qualidade normalmente aplicada para verificar artefatos no executveis.

Revises
Teste de Software algo muito importante no

desenvolvimento. Ele usado para avaliar se o produto construdo est de acordo com os requisitos identificados. Mas se construmos uma ER, como fazer para test-la? nesse momento que torna-se necessrio a realizao de atividades de garantia da qualidade que tenha como objetivo avaliar o trabalho realizado. Para os casos em que o produto do trabalho no executvel, as revises so adequadas. As revises de software so tcnicas eficazes de garantia da qualidade. Segundo um grande pesquisador na rea da Engenharia de Software, Watts Humphrey, as Revises so mais eficazes que os testes para se encontrar defeitos em um produto. As revises aplicadas no desenvolvimento de software normalmente so de responsabilidade de um grupo de garantia da qualidade. Como boa parte das organizaes so pequenas e no conseguem ter um grupo dedicado somente a isso, necessrio ter no processo uma previso dessa atividade. O fluxo de requisitos apresentado neste texto contm a previso de uma reviso no final de sua execuo, devendo essa ser liderada pelo Gerente do Projeto, caso no haja um responsvel direto. Existem diversos tipos de reviso. A reviso tcnica tem como objetivo avaliar artefatos especficos para verificar se eles esto

50

conformes com os respectivos padres e se modificaes foram efetuadas de maneira correta. A inspeo mais formal que a reviso tcnica. Ela tem o objetivo principal de identificar e remover defeitos. Para isso, seu resultado deve gerar uma lista de defeitos com classificao, exigindo dos autores do artefato revisado providncia para a resoluo dos problemas relatados. Na reviso de apresentao o autor demonstra o material em ordem lgica, sem limite de tempo, a um grupo que verifica o material medida que ele vai sendo apresentado. Este tipo de reviso no exige preparao prvia e pode ser feito com maior nmero de participantes, por terem estes papel mais passivo. Elas podem ser usadas nos marcos de projeto em que so necessrias apresentaes ao cliente. A reviso gerencial conduzida pelo gerente de um projeto, com os objetivos principais de avaliar os problemas tcnicos e gerenciais do projeto, assim como o seu progresso em relao aos planos. Alm das revises formais, existem diversos tipos de reviso informal, que podem e devem ser usadas. Alguns mtodos geis se utilizam muito desse tipo de reviso, uma vez que essa prtica de revisar uma boa prtica no desenvolvimento de software. Dentre os tipos de revises informais, destacam-se: A programao em pares, adotada no XP e outros processos geis. Essa uma reviso contnua, onde uma dupla trabalha programando em uma mesma mquina. Um dos integrantes da dupla responsvel por pilotar o equipamento e o outro responsvel por uma reviso permanente do trabalho sendo executado. A reviso individual realizada pelos autores, seguindo formalmente os roteiros pertinentes, eventualmente com a ajuda de pares.

51

A reviso preliminar realizada por um ou mais pares dos autores, para eliminar defeitos mais simples do material, como ortografia, numerao, estilos e consistncia.

2.1.4.

Participantes

Uma reviso deve ser feita com a participao de diversas pessoas. No entanto, aconselhvel que esse grupo tenha de 5 a 8 membros, sendo: 1 lder; 1 relator; 1 ou 2 autores; 2 a 4 revisores pares dos autores; 0 a 2 representantes dos usurios, dependendo do material em reviso. O lder da reviso deve possuir algumas caractersticas, conforme detalhamento a seguir:
Um nmero grande de participantes inviabiliza a produo de bons resultados em uma reviso.

ele deve compreender o propsito das revises em geral e entender seu funcionamento; ter conhecimentos tcnicos de alto nvel sobre o material a ser revisado; ter participado de alguma outra reviso como revisor e tambm, de preferncia, como autor; no ter com qualquer um dos revisores alguma dificuldade pessoal que possa interferir em sua habilidade de liderar a reviso. Assim como o lder, o relator da reviso tambm deve possuir

algumas caractersticas: compreender o propsito das revises em geral e entender seu funcionamento; compreender o jargo e os formatos utilizados neste material; ser capaz de comunicar-se com as pessoas que estaro presentes na reviso; ter participado de alguma outra reviso como revisor ou como autor.

52

Os demais revisores devem levar em conta os seguintes aspectos de comportamento: estar preparado, lendo cuidadosamente o material antes da reunio; ter conhecimento tcnico sobre parte do material da reviso; ser cooperativo; ser franco em relao ao material da reviso, mas polido em relao aos autores; compreender perfeitamente os pontos discutidos; usar um comentrio positivo e outro negativo; apontar defeitos, mas no discutir como resolv-los (a resoluo no faz parte da reviso); evitar discusses sobre detalhes no-pertinentes qualidade do material em reviso; limitar-se aos assuntos tcnicos; no avaliar os produtores, apenas o resultado do projeto. Normalmente, os revisores so desenvolvedores, ou seja, pares dos autores. Em alguns casos, pode ser desejvel a participao de usurios como revisores, por exemplo, em revises das especificaes de requisitos, dos desenhos das interfaces de usurio e da documentao de usurio. Nesse caso, os usurios devem estar cientes de que estaro analisando a qualidade do material sob reviso.

2.1.5.

Conduo

muito importante deixar bem claro nas reunies que o que est sendo revisado um trabalho e no seus autores. Isso deve ser frisado por que comum que haja certas disputas em revises que trazem tona certos problemas de relacionamento. Outro ponto chave manter sempre em mente que o objetivo da reviso no detalhar solues, mas apenas apontar problemas e, eventualmente, dar sugestes sobre possveis melhorias ao

53

material em reviso. A descoberta por solues pode levar um tempo muito grande, inviabilizando a prpria reviso. Normalmente a reunio de reviso no deve ultrapassar duas horas. Deve-se garantir que no sejam feitas interrupes externas reunio e que os membros da reviso no sejam solicitados por telefonemas ou trabalhos externos. O lder da reviso deve certificarse de que todos os telefones celulares estejam desligados. Nas revises tcnicas, o material normalmente apresentado na ordem em que est documentado, por um autor ou pelo lder da reviso. Nas inspees, comum utilizar-se a ordem por item analisado. Desta maneira, em cada etapa a equipe de inspeo ter a ateno focalizada em um aspecto especfico.
preciso deixar muito claro que em uma reviso estamos analisando o trabalho produzido e no seus produtores.

reunio

deve

ser

iniciada

pontualmente;

nenhum

participante poder mais entrar, aps o seu incio. Se a reunio tiver que ser interrompida, ou se algum dos participantes estiver ausente reviso dever ser cancelada, e nova data para a reviso dever ser marcada pelo lder. Uma reviso tcnica realizada de acordo com o seguinte procedimento: 1. O gerente do projeto envia o material para o Grupo de Garantia da Qualidade (GQ) ou para o grupo responsvel pela realizao das revises, caso no haja o grupo de garantia da qualidade. O material consiste dos resultados de uma ou mais atividades de fase do desenvolvimento, como uma ER, prrevisados se necessrio, para eliminar problemas menores de estilo, ortografia etc. 2. O GQ convoca os membros da equipe de reviso, escolhe o lder e o relator desta equipe e distribui os resultados para o grupo de revisores. 3. preparao observaes. O grupo de revisores estuda o material e faz a da reviso, possivelmente registrando suas

54

4. analisado. 5.

O lder comanda a realizao da reunio de reviso e

envia para o GQ os relatrios contendo o resultado do material O GQ faz o ps processamento da reviso.

Em alguns estilos de reviso, a deteco de defeitos realizada principalmente durante a reunio, tendo a preparao o objetivo de estudo e anlise preliminar do material. Em outros estilos, solicita-se que os revisores procurem localizar o mximo de defeitos durante a preparao, tendo a reunio o objetivo principal de eliminar duplicaes e padronizar a classificao dos defeitos e o fraseado das observaes. O Relatrio de Reviso deve conter uma lista com os defeitos encontrados. importante o uso de um projetor durante a gerao do relatrio, para permitir que todos vejam o que est sendo escrito. Ao final da reunio, deve-se produzir uma verso impressa, com listagem das anotaes, que ser conferida por todos os participantes e que receber as assinaturas destes. Os autores devem agir em relao a essa lista de defeitos, anotando as providncias tomadas. Uma recomendao que para cada defeito, o autor deve inserir a providncia correspondente, indicando se o defeito foi corrigido ou expondo as razes pelas quais discorda da necessidade de correo. O autor deve tambm indicar o tempo gasto para remoo do defeito, que ser posteriormente usado para alimentar uma base de dados histricos. Aps a reviso, o GQ deve encaminhar o resultado para o Gerente do Projeto, para que se faam as correes necessrias no material revisado. Isso depende muito do resultado da reviso, que pode ser: Aceitao: indicando que o material foi aceito, embora ainda devam existir outros procedimentos de controle. Revises menores: o gerente do projeto solicita equipe do projeto que providencie os acertos necessrios. O GQ deve verificar se as correes devidas foram feitas. 55

Revises maiores: o gerente do projeto solicita equipe do projeto que corrija o material e pede ao GQ uma nova reviso ao final da correo. Reconstruo: o gerente do projeto investiga as causas dos problemas material, observadas. importante ressaltar que as sugestes apontadas no detectados, indicando as agendando provveis a reconstruo para do falhas serem

relatrio

de

reviso

no

precisam

ser

necessariamente

implementadas. Cabe ao gerente do projeto determinar, entre as alteraes propostas, quais devem ser realmente executadas, ponderando os aspectos tcnicos, gerenciais e polticos e ouvindo o GQ. Os Relatrios de Revises devem ser arquivados permanentemente, sendo importante que cada projeto mantenha seu repositrio.

1.6.

Exerccios

1. O que so oficinas de requisitos? 2. Por que as oficinas de requisitos tendem a apresentar melhores resultados que as reunies individuais? 3. Como so divididas as oficinas? 4. O que feito na personalizao de uma oficina? 5. Por que as sesses de levantamento deveriam ser feitas longe do ambiente dos participantes dos clientes? 6. Que materiais so necessrios durante uma sesso de levantamento de requisitos? 7. Quais so os papis associadas a uma sesso de levantamento de requisitos? 8. O que feito no fechamento de uma sesso? 9. O que deve existir em uma ata de uma reunio de levantamento de requisitos? 56

10. Qual a relao existente entre o teste e a reviso? 11. Quem o responsvel pela conduo de uma reviso? 12. Quais so os tipos de reviso existentes? 13. Qual a forma de reviso existente no processo XP? 14. Quais caractersticas devem estar associadas ao lder de uma reviso? 15. Quais caractersticas devem estar associadas ao relator de uma reviso? 16. Quais aspectos de comportamento so importantes para os demais revisores? 17. Como deve ser conduzida uma reunio de reviso? 18. Quais so os possveis resultados de uma reviso?

57

UNIDADE I O FLUXO DE REQUISITOS WEBLIOGRAFIA

Pgina da Universidade Aberta do Piau - UAPI http://www.ufpi.br/uapi Pgina da Universidade Aberta do Brasil- UAB http://www.uab.gov.br Instituto de Engenharia de Software do MIT http://www.sei.cmu.edu/ Stio de apoio ao livro de Roger Pressman http://www.rspa.com/ Stio de apoio ao livro de Ian Sommerville http://www.comp.lancs.ac.uk/computing/resources/IanS/ Stio de apoio ao livro de Wilson de Pdua http://homepages.dcc.ufmg.br/~wilson/ Stio da Ferramenta Astah http://astah.change-vision.com

58

UNIDADE I O FLUXO DE REQUISITOS

REFERNCIAS BIBLIOGRFICAS
ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes, Editora Bookman, 2003. IAN SOMMERVILLE, Engenharia de Software, 6a. Edio, Addison-Wesley, 2005. JANE WOOD, SILVER DENISE, Joint Application Development, John Wiley & Sons Inc, ISBN 0-47104-299-4. KENT BECK, Extreme Programming Explained: embrace

change. Boston: AddisonWesley/Longman, 1999. ROGER S. PRESSMAN, Engenharia de Software, 5a. Edio, McGraw-Hill, So Paulo, 2002. WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

59

UNIDADE II ANLISE DE SOFTWARE

RESUMO Nesta unidade apresentamos o Fluxo de Anlise. Ele tem como objetivo modelar conceitos importantes, identificados durante o levantamento de requisitos. Essa modelagem d origem a diversas classes e diagramas, que apresentam a especificao de requisitos sob outra forma, mais prxima dos desenvolvedores e um pouco mais distante dos usurios finais. No Capitulo 3 apresentamos a Linguagem UML, um padro de facto para a modelagem de sistemas e fundamental para execuo do Fluxo de Anlise. Todos os seus elementos sero descritos, juntamente com um breve detalhamento sobre como utilizar a ferramenta Astah para modelagem. No Captulo 4 apresentamos o Fluxo de Anlise. No fluxo so detalhadas as atividades relacionadas disciplina, apresentando em detalhes a Anlise para nosso sistema exemplo. Detalharemos os passos executados para cada atividade. No Captulo 5 apresentamos a Anlise de Ponto de Funo, que uma tcnica para contagem de sistemas quando esses ainda no foram implementados e possuem apenas uma Especificao de Requisitos e um Modelo de Anlise.

60

SUMRIO DA UNIDADE

UNIDADE II ................................................................................................ 60 ANLISE DE SOFTWARE ........................................................................ 60 3. A Linguagem UML ............................................................................... 62 1.7. A Origem da UML ......................................................................... 62 1.8. Vises ............................................................................................. 64 1.9. Modelo de Elementos ..................................................................... 65 3.1.1. Classes ..................................................................................... 65 3.1.2. Objetos .................................................................................... 67 3.1.3. Estados .................................................................................... 68 3.1.4. Pacotes..................................................................................... 68 3.1.5. Componentes ........................................................................... 69 3.1.6. Relacionamentos ..................................................................... 69 1.10. Mecanismos Gerais ...................................................................... 74 1.11. Diagramas .................................................................................... 75 3.1.7. Diagrama de Casos de uso ...................................................... 75 3.1.8. Diagrama de Classes ............................................................... 76 3.1.9. Diagrama de Objetos ............................................................... 76 3.1.10. Diagrama de Estados ............................................................. 77 3.1.11. Diagrama de Seqncia ......................................................... 78 3.1.12. Diagrama de Colaborao ..................................................... 79 3.1.13. Diagrama de Atividades ........................................................ 80 3.1.14. Diagrama de Componentes ................................................... 81 3.1.15. Diagrama de Implantao ..................................................... 81 1.12. Consideraes Finais .................................................................... 82 1.13. Exerccios ..................................................................................... 82 4. O Fluxo de Anlise................................................................................ 84 1.14. Atividades do Fluxo de Anlise ................................................... 84 4.1.1. Identificao das Classes......................................................... 85 4.1.2. Organizao das Classes ......................................................... 94 4.1.3. Realizao dos Casos de Uso .................................................. 95 4.1.4. Reviso da Anlise .................................................................. 97 1.15. Exerccios ..................................................................................... 98 5. Anlise de Pontos de Funo ................................................................ 99 5.1 Introduo a Anlise de Pontos de Funo ................................... 103 5.2 O Processo de Contagem .............................................................. 105 5.2.1 Contagem de Funes de Dados ............................................ 112 5.2.2 Contagem de Funes de Transao ...................................... 114 5.3 Contagem Estimativa de Pontos de Funo .................................. 120 5.3.1 Contagem de funes de dados .............................................. 122 5.3.2 Contagem de funes de transao ........................................ 124 5.4 Planejamento e Gesto de Projetos com PF .................................. 130 5.5 Viso crtica da APF ..................................................................... 131 5.6 Exerccios ...................................................................................... 134 61

UNIDADE II O FLUXO DE ANLISE

3. A Linguagem UML
A modelagem um dos conceitos importantes para o desenvolvimento de software. Um modelo uma abstrao de algo, em que nos concentramos nos aspectos fundamentais do que se est querendo modelar, ignorando os aspectos que no so relevantes. Modelos so fundamentais no desenvolvimento pois criam uma camada de abstrao do que estamos querendo modelar, focando apenas no que importante. Isso permite que os desenvolvedores consigam representar algo complexo de forma bem mais simples, explorando apenas o que se deseja explorar em um determinado momento. A Unified Modelling Language (UML), ou Linguagem de Modelagem Unificada em Portugus, uma linguagem utilizada para a criao de modelos. Ela possui uma interessante caracterstica que a fez ser to difundida: ela uma linguagem baseada em diagramas, o que a torna muito mais simples de usar e entender.
Existem diversas ferramentas UML disponveis. Escolhemos uma por sua adequao ao que necessitaremos e no por ser melhor que as outras ferramentas existentes.

Neste trabalho utilizaremos uma ferramenta gratuita para a modelagem UML. O objetivo possibilitar o uso de uma ferramenta, aplicando os conceitos de forma prtica. A ferramenta selecionada foi a ASTAH, que pode ser gratuitamente obtida em http://astah.change-vision.com. Utilizamos a verso community para demonstrar a aplicao prtica dos conceitos apresentados durante o captulo.

1.7.

A Origem da UML

62

At o surgimento da UML existiam diversos processos de software e diversas linguagens de modelagem associadas aos processos. Isso gerava muitos problemas, devido a ausncia de um padro para se modelar conceitos de um sistema. Por conta disso, houve uma tentativa de padronizar os processos e as linguagens de modelagem, gerando uma unificao dos conceitos associados. Isso deu origem ao Processo Unificado (Unified Process UP) e a UML. Trs processos deram origem ao UP e UML: Booch Esse mtodo foi criado por Grady Booch e foi baseado no fato de um sistema ter diversas vises, cada uma descrita por modelos e diagramas. O mtodo possua uma simbologia complexa de ser desenhada mo. OMT O Object Modelling Technique foi desenvolvido pela General Electric onde o pesquisador James Rumbaugh trabalhava. Os modelos prescritos pelo mtodo so compostos por modelos de objetos, funcional e casos de uso. OOSE/Objectory Os dois mtodos foram desenvolvidos por Ivar Jacobson. Ambos so baseados na utilizao de casos de uso, a partir da modelagem dos requisitos iniciais do sistema vistos por um ator externo. O mtodo Objectory foi adaptado para permitir seu uso tambm para a modelagem de processos de negcio, fundamentais no funcionamento de qualquer organizao. Os mtodos citados anteriormente tinham idias em comum e idias diferentes. Da mesma forma, eles possuam notaes prprias. A partir disso, os trs amigos resolveram criar um notao nica, baseada no que havia de melhor em cada notao. Isso deu origem UML. De forma similar, eles criaram um processo nico, tambm baseado na unificao das melhores idias existentes nos processos, criando assim o UP. A UML atualmente um padro de facto. O mundo inteiro utiliza a UML. Ela uma forma de comunicao padro que aceita e exigida por muitas organizaes. Para entendermos a UML 63

necessrio saber como ela dividida. Nas prximas sees apresentaremos cada uma das partes da UML: Vises, Modelos de Elementos, Mecanismos Gerais e Diagramas.

1.8.
Cada viso foca em um aspecto particular do produto sendo modelado.

Vises

Uma viso mostra um aspecto diferente do sistema que est sendo modelado, sendo normalmente composta por diversos diagramas que focam em aspectos particulares de um sistema. As principais vises da UML so: Viso de Casos de Uso: descreve o comportamento do sistema, a partir da definio de como o sistema se comportar a partir da interao com os atores externos que o utilizaro. Isso est diretamente ligado ao diagrama de casos de uso. Viso Lgica: descreve como o comportamento ser implementado. Enquanto a viso de caso de uso est muito mais associada viso externa do sistema, a viso lgica foca na viso interna, descrevendo os mecanismos que sero necessrios para que o sistema funcione. Isso inclui a estrutura esttica, composta por classes, objetos, relacionamentos, assim como a estrutura dinmica, composta por realizaes. A parte esttica da viso lgica descrita por diagrama de classes e de objetos. A parte dinmica descrita por diagramas de estado, seqncia, colaborao e atividade. Viso de Componentes: descreve a diviso da implementao em mdulos, demonstrando suas dependncias. Essa viso est diretamente ligado ao diagrama de componentes. Viso de concorrncia: descreve o sistema sob a perspectiva de diviso em processos e processadores, indicando se haver execues em paralelo, detalhando a comunicao e a concorrncia existente no sistema. Essa viso pode ser descrita pelos diagramas dinmicos (estado, seqncia,

64

colaborao

atividade),

alm

dos

diagramas

de

desdobramento. Viso de Organizao: descreve a organizao fsica do sistema, indicando os computadores, perifricos e suas conexes entre si. Essa viso ligada aos diagramas de desdobramento.

1.9.

Modelo de Elementos

Os conceitos utilizados nos diagramas so modelos de elementos. Eles representam as definies comuns existentes na linguagem, tais como classes, objetos, mensagens, atributos e relacionamentos. Esta seo detalha os principais modelo de elementos existentes na UML.

3.1.1.

Classes

Uma classe uma representao abstrata de um conceito. Nessa representao tentamos focar nos dados relacionados entidade sendo modelada, bem como nas possveis operaes que podem acontecer sobre esses dados. Na UML as classes so representadas por um retngulo que pode ser dividido em at 3 compartimentos: o nome da classe, seus atributos e as operaes possveis. A identificao de classes em um sistema feito a partir de uma anlise da Especificao de Requisitos. A notao de classes da UML independente da linguagem a ser utilizada. Assim, uma classe representada em UML pode ser gerada em Java, C++, Ruby, etc.

65

Figura 8: Exemplo de Classe.

A Figura 8 exibe um exemplo de classe. O nome da classe Pessoa. Ela possui diversos atributos (nome, email, telefone, celular, login e senha). Na classe existe apenas uma operao (salvar). Para se criar uma classe utilizando a ferramenta Astah ser necessrio criar um diagrama de classes, uma vez que tal diagrama possibilita a criao de classes. Uma vez criado um diagrama de classe, ser exibida uma barra de ferramentas similar mostrada na Figura 9Figura 9. De forma geral, todas as ferramentas UML apresentam barras de ferramentas para facilitar a criao de elementos em diagramas. Para cada diagrama, uma barra de ferramentas com os elementos possveis de integrar o diagrama so exibidos.

Figura 9: Barra de ferramentas para criao de diagramas de classe.

O primeiro item na barra de ferramenta o item para seleo de objetos. O segundo item o boto que permite criar classes. Basta clicar nele e clicar no diagrama para que uma classe seja criada. Aps sua criao, possvel, via acionamento do boto direito do mouse sob a classe, criar atributos e operaes, conforme exibido na Figura 10.

66

Figura 10: Criao de atributos e operaes para classes.

3.1.2.

Objetos

Os objetos representam instncias de uma classe. De maneira simples, enquanto que as classes representam conceitos, objetos representam coisas reais associadas ao conceito modelado. Como exemplo, na Figura 9 temos a representao do conceito pessoa, indicando que algo que contm nome, email, celular, etc. Na Figura 11 temos um exemplo de uma instncia de Pessoa, que possui nome Pedro, email pedro@gmail.com, etc. Esse apenas um exemplo de Pessoa, mas muitos outros podem ser criados. Para criar um objeto, podemos utilizar a barra de ferramentas exibida na Figura 9. O boto para tal ao o 15o. elemento da esquerda para a direita. Ao se passar o ponteiro do mouse por cima dele ser exibido o texto InstanceSpecification. Ao clicar no boto, para que ele fique selecionado, clicando em qualquer local dentro do diagrama de classe, um objeto ser apresentado. Depois disso voc ter que associar o objeto a uma classe, para que em seguida seja possvel especificar os valores dos atributos.

67

Figura 11: Exemplo de um objeto pessoa.

3.1.3.

Estados

Os objetos normalmente possuem um estado. Um estado representa o resultado das operaes executadas no objeto, sendo normalmente determinado pelos valores de seus atributos e ligaes existentes com outros objetos. A Figura 12 apresenta dois estados relacionados a um objeto Livro. Um livro pode estar livre ou emprestado. Para mudar de livre para emprestado necessrio que o evento emprstimo seja realizado. Para mudar de emprestado para livre, necessrio que o evento devoluo acontea. Os estados de um objeto podem deixar claro seu funcionamento, sendo uma descrio simples de se entender e bastante expressiva.

Figura 12: Exemplos de estados para o objeto Livro.

3.1.4.

Pacotes

Um Pacote um agrupamento de itens, utilizado para fins de organizao. De forma geral, esses agrupamentos so feitos para se manter juntos elementos que possuem algum tipo de relao entre si. Os pacotes podem ser criados dentro dos modelos UML, a partir do acionamento do boto direito do mouse em cima do local desejado. De forma simples, um pacote pode ser comparado a uma 68

pasta dentro do modelo. A Figura 13 apresenta um exemplo de criao de um pacote em um modelo UML.

Figura 13: Criao de um pacote na ferramenta Astah.

3.1.5.

Componentes

Um componente a representao de uma parte do sistema. Isso pode ser um cdigo na linguagem fonte ou cdigo executvel. Imagine um sistema feito em Java. Cada arquivo .class pode ser considerado um componente, assim como qualquer arquivo .java. A Figura 14 exibe exemplos de componentes criados na Astah. O uso desse tipo de elemento est diretamente associado ao projeto de um software. Por conta disso, ele ser pouco explorado neste material, uma vez que estamos tratando de requisitos e anlise.

Figura 14: Exemplos de componentes.

3.1.6.

Relacionamentos

Os relacionamentos permitem a ligao de classes e objetos entre si, estabelecendo uma relao entre eles. Essas ligaes podem assumir os seguintes tipos: associao, generalizao e dependncia. A seguir detalhamos brevemente cada um dos tipos de relacionamentos. Associao 69

Uma associao cria uma conexo entre as classe ou entre objetos das classes. Dessa forma, uma associao entre classes indica que qualquer objeto de uma classe ter uma conexo com um objeto da outra classe. A associao simples a forma mais comum de uma associao. Ela representada por uma linha ligando duas classes. Essa linha pode possuir uma seta indicando direo. Isso significa que ela s pode ser usada para o lado em que ela aponta. No havendo seta, significa que os dois lados so navegveis. A Figura 15 exibe um exemplo contendo associaes com e sem direo. Isso significa que podemos obter os Membros a partir de um Projeto, assim como a partir de Membro podemos obter os Projetos, uma vez que a associao no possui direo. J a outra associao indica que podemos obter facilmente os Clientes de um Projeto, mas o inverso no verdadeiro.

Figura 15: Exemplo de classes com associaes com e sem direo.

A Figura 16 exibe as mesmas associaes contidas na Figura 15, porm, com a especificao dos nomes dos papis nos relacionamentos e multiplicidades das relaes. Os nomes dos papis do origem ao nome dos atributos das classes quando fazemos gerao de cdigo. Dessa forma, ao gerarmos cdigo para a classe Projeto, ela conter dois atributos de coleo: um denominado membros e outro chamado clientes. A maioria das ferramentas UML permitem alguma gerao de cdigo. No entanto, isso no est diretamente ligado aos objetivos deste material, pois estamos ainda entendendo o problema e no projetando uma soluo.

70

Para se inserir nome dos papis, multiplicidade e nome nos relacionamentos, voc deve clicar na associao e visualizar a caixa de propriedades do item, que normalmente fica localizado no canto inferior esquerdo da tela da ferramenta Astah.

Figura 16: Associao com nomeao dos papis e multiplicidades.

A multiplicidade das associaes pode assumir diversos valores, tais como 0..1 (zero ou um), 2 (dois), 4..9 (de quatro a nove), etc. O uso de * indica que no h um limite estabelecido. Quando no descrito multiplicidade utilizamos como padro 1.

Figura 17: Exemplo com auto-associao e especificao do nome da associao.

A Figura 17 exibe um exemplo de associao recursiva entre Membro (tambm chamada de auto-associao). Conforme especificado, um membro, que um chefe, chefia vrios membros subordinados. Da mesma forma, um membro subordinado tem um membro que seu chefe. Esse exemplo tambm mostra uma associao com nome (chefia). Existem outros tipos de associao que no sero detalhados aqui, como as associaes com restries, associaes ternrias, associaes qualificadas e classes de associao. No entanto, existe muito material na Internet disponvel sobre o assunto, que no

71

 to comum de ser encontro em modelos de anlise, foco deste documento. Ainda existem dois tipos particulares de associao que merecem comentrios: agregao e composio. A Agregao uma associao que indica a relao todo/parte. Isso significa que um dos itens relacionados o todo na relao e o outro uma parte. Normalmente os nomes das associaes, caso fossem utilizados, deveriam ser tem, contm, faz parte. Uma agregao no possui uma representao especfica na maioria das linguagens de programao nem necessitam de um comportamento especial da implementao associada. A Figura 18 exibe um exemplo que mostra que um Projeto contm Membros. Conforme comentado, a implementao da agregao entre projeto e membros dever gerar a mesma implementao que uma associao normal. Observe que uma Agregao representada por um losango no preenchido. necessrio termos muita ateno com a simbologia associada UML: o uso de um smbolo errado pode passar um idia completamente diferente do que se desejava!

Figura 18: Exemplo de agregao.

A Figura 19 exibe uma associao do tipo Composio. Nesse tipo de associao existe um relacionamento forte entre os integrantes: a parte no vive sem o todo. Dessa forma, a implementao de uma Composio exige que esse comportamento seja implementado, caso contrrio, no estaremos cumprindo o que foi modelado. No exemplo temos modelado que Scio contm Dependentes. Dessa forma, est implcito que, a excluso de um scio, implica na excluso de todos os seus dependentes. 72

Figura 19: Exemplo de Composio.

Observe que a composio tambm representada por um losango, porm, preenchido. Observe tambm que a diferena entre estar ou no preenchido pode causar uma grande mudana no entendimento e na forma de implementar o que foi modelado! Generalizaes Uma Generalizao indica que um elemento herdar todos os atributos e operaes de um outro elemento, podendo ainda incluir comportamento adicional. Nos locais em que so esperados um elemento do tipo mais geral pode-se utilizar um elemento especfico sem qualquer problema. A Figura 20 exibe um exemplo de generalizao. Nela podemos notar que um Projeto possui um Cliente, que a classe genrica. Um Cliente pode tanto ser uma Pessoa Fsica como uma Pessoa Jurdica.

Figura 20: Exemplo de Generalizao.

Dependncias 73

A Dependncia uma relao mais fraca entre elementos, que indica que uma alterao em um elemento pode indicar uma mudana de comportamento em outro. A dependncia muito utilizada na especificao de arquitetura de um sistema, indicando que um determinado sistema depende de tecnologia X, Y, Z. De forma geral uma relao mais fraca que a associao mas indica uma conexo semntica entre os envolvido.

Figura 21: Exemplo de Dependncia entre classes.

A Figura 21 exibe uma relao de dependncia entre classes. Pode-se visualizar que a classe Dependente possui um mtodo salvar que possui um parmetro do tipo Conexo. Logo, uma alterao no tipo Conexo pode causar uma mudana no comportamento de Dependente. Isso causa a dependncia entre as classes. A dependncia no precisa ser exibida nos diagramas, a no ser que seja necessrio expor essa dependncia. Por conta disso, na figura existe a composio entre scio e dependente exibida duas vezes, sendo que na parte do lado direito foi enfatizada a dependncia entre a classe Dependente e conexo, uma vez que dentro da classe Dependente existe um mtodo que usa um objeto do tipo Conexo.

1.10.

Mecanismos Gerais

Na UML existem informaes adicionais que so associados aos modelos. O grande exemplo disso so as notas. Embora a UML tenha muita semntica associada s representaes, no possvel modelar tudo. Dessa forma, uma nota pode ajudar a detalhar certas informaes. A Figura 22 exibe um diagrama contendo uma nota.

74

Nela, especificado uma regra para a associao de scios e dependentes, utilizando nossa linguagem natural.

Figura 22: Exemplo de nota em um diagrama.

1.11.

Diagramas

Na UML existem diversos grficos que descrevem o que existe em uma viso. Esses grficos so os diagramas, utilizados para criar as vises do sistema. Existem 9 diagramas na UML que sero apresentados nas prximas subsees. A criao de um diagrama na ferramenta Astah feito a partir do menu Create Diagram, exibido quando se clica com o boto direito em algum pacote do modelo. A partir desse menu possvel criar qualquer um dos diagramas existentes. A Figura 23 exibe o menu para criao de diagramas na ferramenta Astah.

Figura 23: Menu para criao de diagramas na Astah.

3.1.7.

Diagrama de Casos de uso

O diagrama de casos de uso exibe os requisitos funcionais de um sistema. Isso est diretamente ligado ao comportamento que o sistema dever adotar. Nesse diagrama existem atores, que representam papis no sistema e casos de uso, que representam as 75

funcionalidades existentes. A ligao entre atores e caso de uso indica que h comunicao entre eles. Uma seta direcionada pode ser utilizada para definir o sentido da comunicao. A Figura 24 exibe um exemplo de diagrama de casos de uso. Temos o caso de uso Reserva de livro, associado ao ator Aluno. Nesse caso, pode-se concluir que um aluno pode reservar um livro, embora no tenhamos detalhes sobre quais so as regras especficas para a reserva. O ator Aluno, nesse caso, representa um
Diagramas de caso de uso so excelentes para se obter um entendimento rpido sobre um sistema!

papel relacionado a um grupo de usurios. O outro caso de uso da figura, Invalidao de reserva, est associado ao ator Tempo. Isso indica que o caso de uso acionado automaticamente dentro de certos perodos de tempo pr-estabelecidos.

Figura 24: Exemplo de casos de uso.

3.1.8.

Diagrama de Classes

O diagrama de classes est associado viso esttica de um sistema. Conforme visto neste captulo, classes podem se associar a outras classes de diferentes formas (associao, composio, dependncia, etc.). Um sistema real pode conter um nmero grande de classes, sendo necessrio a criao de diversos diagramas, cada um focando em um aspecto especfico. Uma mesma classe pode aparecer em diferentes diagramas. Nas figuras anteriores foram apresentados diversos diagramas de classe para se explicar os mais diferentes relacionamentos entre classes.

3.1.9.

Diagrama de Objetos

O diagrama de objetos descreve uma instncia especfica de uma diagrama de classe. Sua notao bem prxima do diagrama

76

de classe, porm, importante frisar que ele exibe as instncias das classes, com sua configurao de execuo momentnea. Os diagramas de objetos no so to utilizados nos modelos, mas servem para esclarecer aspectos importantes de diagramas complexos. A Figura 25 exibe um diagrama de objetos para o diagrama de classe apresentado na Figura 19. Essa apenas uma possvel configurao para o diagrama de classe comentado. Nele podemos perceber que o Scio Pedro possui dois dependentes: Ana
Diagramas de objetos podem facilitar o entedimento de classes complexas, a partir da demonstrao de uma instncia especfica, onde podemos demonstrar alguns aspectos mais difceis de serem entendidos.

Clia e Joana. Diversas outros diagramas de objetos so possveis, desde que eles no violem as restries existentes no diagrama de classe original.

Figura 25: Diagrama de objetos.

Os diagramas de estados mostram a dinmica das classes e so facilmente entendidos por usurios leigos, a partir de um mnimo de explicao.

3.1.10.

Diagrama de Estados

O diagrama de estados descreve o comportamento dinmico de uma instncia de uma classe, normalmente representando seu ciclo de vida. Esse diagrama importante para descrever classes que possuem objetos com ciclos complexos, uma vez que podemos especificar as aes e condies associadas s mudanas de estado. A exibe um diagrama de estados para um objeto Livro. Ele inicia livre, pronto para ser reservado, emprestado ou tornado cativo e, dependendo da funo utilizada, pode assumir outros estados. Um livro pode ser reservado, para depois ser emprestado e ento devolvido para que seja feito novo emprstimo. No diagrama, temos a indicao que o estado inicial de um objeto livro livre e que furtado um estado final (sinalizado pelo estado final, ligado ao estado furtado). Um estado final indica que o ciclo de vida do objeto 77

acabou, no sendo possvel mais nenhuma outra transio de estados.

Figura 26: Diagrama de estados para o objeto Livro.

3.1.11.

Diagrama de Seqncia

O diagrama de seqncia mostra a troca de mensagens entre objetos durante a implementao de certos comportamentos. O foco no diagrama de seqncia mostrar as interaes entre objetos, ao invs de mostrar apenas o comportamento interno de um objeto. Ele ainda apresenta a ordem temporal das chamadas, destacando assim a seqncia das aes invocadas, por isso seu nome. A Figura 27 exibe um diagrama de seqncia. Os objetos associados ao diagrama so exibidos na forma de um retngulo, com uma linha tracejada abaixo. Essa linha chamada linha da vida do objeto, indicando quando o objeto est vivo durante a execuo do roteiro sendo modelado. As setas entre objetos indicam o acionamento de algum mtodo existente via troca de mensagens. Na figura podemos notar que o objeto Scio invoca o mtodo criar do objeto Dependente, acionando os mtodos associar e salvar logo em seguida. O mtodo salvar, do objeto Dependente, aciona o mtodo validar, tambm interno a Dependente, que por sua vez

78

aciona o mtodo validarCPF do objeto til e salvarObjeto do objeto Persistncia. Fica claro a ordenao temporal das chamadas. Diagramas de seqncia podem ser utilizados para se detalhar casos de uso. Essa uma notao alternativa aos textos descrevendo os diversos fluxos que compem os casos de uso. No entanto, essa alternativa mais difcil de ser entendida pelos clientes, razo essa que dificulta sua adoo com essa finalidade.

Figura 27: Exemplo de Diagrama de Seqncia.

Um outra aplicao para diagramas de seqncia exibir conceitos chaves de uma arquitetura, detalhando como determinados roteiros funcionam. Ele serve como uma explicao do que acontece em determinados casos, uma vez que detalha o comportamento dinmico que parte de um software pode ter sob certas circunstncias.

3.1.12.

Diagrama de Colaborao

O diagrama de colaborao pode ser considerado como uma outra forma de exibio do diagrama de seqncia. Um diagrama pode ser convertido para o outro, na maioria das ferramentas UML, a partir de um clique. A diferena entre os diagramas est no foco: no diagrama de colaborao enfatizado a troca de mensagens entre objetos e no 79

sua ordem temporal. O diagrama de colaborao pouco utilizado no desenvolvimento de software, sendo prefervel o diagrama de seqncia. Por conta disso, no daremos muita nfase a ele neste trabalho.

3.1.13.

Diagrama de Atividades

O diagrama de atividades uma variante do diagrama de estados na UML. Porm, seu objetivo completamente diferente:
Diagramas de atividade podem ser utilizados com diferentes propsitos. At mesmo para modelar um processo!

enquanto os diagramas de estados exibem o comportamento interno de um objeto, o diagrama de atividades exibem as aes associadas a um roteiro, possibilitando detalhar os executores envolvidos e os produtos de trabalho gerados. Diagramas de atividades podem ser usados para detalhar etapas de um processo, descrio de fluxos de um caso de uso e qualquer outro roteiro que exija a informao das aes associadas. Neste trabalho, utilizamos diagramas de atividades para descrever os processos relacionados com requisitos e anlise.

Figura 28: Descrio de um processo utilizando Diagrama de Atividades.

80

A Figura 28 exibe um diagrama de atividades criado com o intuito de descrever um processo para criao de mquinas virtuais em um Datacenter. Podemos notar que o diagrama exibe a ordem em que as aes devem acontecer, deixando claro os responsveis (exibidos na forma de diviso de colunas no diagrama). Existe no diagrama uma condio que indica para onde a execuo deve ir, caso determinada situao acontea.

3.1.14.

Diagrama de Componentes

O diagrama de componentes exibe a relao entre as partes que compem um sistema e a organizao dos mdulos. Eles podem representar classes, pacotes e subsistemas. Esse tipo de diagrama muito associado exibio da arquitetura de um sistema, deixando claro como ele est estruturado, alem de demonstrar sua organizao e dependncia.

Figura 29: Diagrama de Componentes detalhando estrutura de um sistema.

A Figura 29 exibe um diagrama de componentes detalhando a estrutura de um sistema. Podemos notar que os subsistemas RH e Acadmico dependem do sistema Administrativo. De mesma forma, poderamos detalhar dependncias entre pacotes, classes e outros subsistemas. Isso descreve o agrupamento utilizado na construo de um sistema, exibindo ainda sua organizao e dependncias.

3.1.15.

Diagrama de Implantao

O diagrama de implantao exibe a arquitetura de execuo de um sistema, detalhando os componentes fsicos que executam no 81

ambiente de execuo utilizado. Com isso possvel detalhar que mdulo funcionar em qual dispositivo e como ser sua comunicao com outros dispositivos.

Esse tipo de diagrama tambm muito associado exibio da arquitetura de um sistema, deixando claro como ser organizada sua execuo.

1.12.

Consideraes Finais

Neste captulo apresentamos a UML. Essa linguagem atualmente um padro de facto para a modelagem no mundo. Demonstramos sua diviso e como utliz-la a partir de uma ferramenta gratuita, a Astah. No prximo captulo iremos apresentar como usar a UML para modelar aspectos identificados em uma ER, embora isso j tenha iniciado com a criao de diagramas de caso de uso durante o levantamento de requisitos.

1.13.

Exerccios

1. O que um modelo? 2. O que a UML? 3. Qual a origem da UML? 4. O que so as vises da UML? 5. Quais so as vises existentes na UML? 6. O que uma classe? Como ela representada em UML? 7. O que um objeto? Como ele representado em UML? 8. O que um estado na UML? 82

9. Quando devemos utilizar estados da UML? 10. O que um pacote na UML? 11. O que um componente na UML? 12. Existem diversos tipos de relacionamentos entre classes na UML. Descreva a associao simples, apresentando um exemplo com nome dos papis e cardinalidades. 13. O que uma autoassociao? 14. Qual 15. Cite a um diferena exemplo de uma agregao de uma para uma composio? prtica Generalizao, demonstrando isso no formato prescrito pela UML. 16. O que significa o relacionamento de dependncia? 17. Crie um diagrama de caso de uso para um sistema acadmico, com pelo menos 4 casos de uso. 18. Crie um diagrama de estados para um sistema acadmico, com pelo menos 5 classes. 19. Crie um diagrama de estado para modelar algo que faa parte do seu dia a dia. 20. Para que utilizamos o diagrama de atividades? 21. Crie um diagrama de atividades para modelar algo em seu trabalho ou relacionado ao seu dia a dia. 22. Para que serve o diagrama de componentes? 23. Qual o objetivo do diagrama de implantao?

83

UNIDADE II O FLUXO DE ANLISE

4. O Fluxo de Anlise
O Fluxo de Anlise tem como objetivo modelar os conceitos identificados na ER, tornando-os mais prximos do mundo computacional e um pouco mais distante dos usurios finais. Com isso, tambm feita uma reviso dos requisitos identificados, visando avaliar sua qualidade. Atualmente, a Anlise Orientada a Objetos o formato mais utilizado para modelagem dos conceitos existentes em uma ER. Por conta disso, utilizaremos bastante o conceito de classe e objeto. Tambm ser bastante utilizada a linguagem UML, uma vez que a Anlise se baseia na modelagem dos conceitos existentes na ER.

1.14.

Atividades do Fluxo de Anlise

Figura 30: Atividades do Fluxo de Anlise.

A Figura 30 exibe as atividades do Fluxo de Anlise. Conforme foi ressaltado durante a apresentao do Fluxo de Anlise, enfatizamos que essa figura exibe uma sugesto de atividades para o fluxo. Processos como o RUP prescrevem muito mais atividades enquanto processos geis prescrevem muito pouco. De forma geral, colocamos aqui apenas o essencial e que provavelmente seja interessante em qualquer processo. 84

O Fluxo de Anlise inicia pela identificao das classes. Nessa atividade teremos que traduzir os conceitos relevantes, identificados na ER, em classes, relacionamentos, atributos e operaes. Na atividade Organizao das classes feito uma organizao das classes identificadas, criando pacotes (pastas) para melhor agrupamento dos itens e atribuindo esteretipos a todos os
No existe consenso sobre as atividades relacionadas Anlise. Neste trabalho detalhamos aquilo que muito til na prtica e presente em muitos processos.

elementos identificados. Na Realizao dos Casos de Uso so exibidas as interaes entre objetos para se implementar um determinado comportamento, expresso na descrio dos casos de uso da ER. A diferena est no formato dessa descrio, que ser feita na forma de troca de mensagens entre objetos. A Reviso da Anlise o momento em que o trabalho realizado no fluxo revisto, no intuito de se aumentar a qualidade e evitar que problemas se perpetuem no restante das atividades de desenvolvimento.

4.1.1.

Identificao das Classes

O principal resultado obtido durante a Identificao das Classes a criao de diagramas modelando os principais conceitos existentes no sistema. Um conceito simples de entender e modelar est relacionado aos dados persistentes. Praticamente todas as aplicaes existentes necessitam persistir dados. Um diagrama exibindo todos as classes associadas a dados persistentes, demonstrando os relacionamentos existentes, facilita bastante o entendimento do problema e at mesmo a criao de uma soluo. Esse diagrama normalmente denominado Diagrama de Classes de Entidade. Uma entidade uma classe que est relacionada a dados persistentes. Dando continuidade ao nosso exemplo, com requisitos levantados na Unidade I, poderemos agora iniciar o levantamento 85

das classes persistentes, para depois detalharmos tais classes. Para que isso seja feito, necessrio analisar cada caso de uso, procura de informaes que devem ser persistidas. Iniciando essa anlise, a partir do caso de uso Cadastro de Projeto, podemos notar a necessidade de termos uma entidade associada a Projeto. Pela descrio do caso de uso fcil notar que
No existe uma tcnica bem estabelecida e reconhecidamente efetiva para a identificao de classes. O entendimento do contexto descrito na ER e o bom senso apurado so as melhores tcnicas existentes!

um projeto deve possuir uma sigla, descrio e um gerente associado. Aqui cabe uma anlise a mais: um gerente ser uma outra entidade ou pode ser apenas um campo texto para informao do seu nome? Nossa idia cadastrar gerentes de projeto, para que possamos associ-los a outros projetos e manter assim um histrico de execues. Dessa forma fundamental que os gerentes estejam associados a alguma entidade. Com isso j possvel criar as entidades Projeto e Gerente. Continuando a anlise, podemos notar que o caso de uso Gesto de Gerentes nos fornece mais informaes sobre os dados associados a um gerente, tais como nome, email, telefone, login e senha. Assim, podemos completar a classe Gerente, j identificada, adicionando tais atributos. O prximo caso de uso, Gesto de Membros, nos faz refletir sobre alguns pontos importantes. Um membro pode ser um Cliente ou um Engenheiro de Requisitos, conforme consta no caso de uso. Dessa forma fica a reflexo: ser que necessitamos realmente de uma classe de entidade para modelar Gerente ou ser que o Gerente de um projeto tambm no um Membro? No existe uma resposta precisa sobre a questo, pois o contexto deve ser analisado. No entanto, definimos nesse trabalho, por achar mais adequado, que devemos ter apenas a classe Membro. Assim, a classe Gerente, identificada no pargrafo anterior ser excluda do nosso modelo, ficando apenas Projeto e Membro at o momento. Isso nos gera o modelo exibido na

86

Figura 31. A classe projeto contm vrios outros atributos identificados a partir da anlise do caso de uso Controle de Projetos.

Figura 31: Modelo representando Projeto e Membro.

Uma outra constatao interessante que os membros possuem login e senha para acesso ao sistema. Tomamos a deciso de modelar isso em uma classe separada, indicando que os membros so usurios do sistema. Observe que isso foi uma deciso de modelagem tomada pela equipe, sem que houvesse um indicao na ER que pudesse nos levar a isso. Poderamos ter mantido os atributos de Usurio na classe Membro, no necessitando dessa classe extra. Porm, acreditamos que a modelagem utilizada mais apropriada e permite uma maior inteligibilidade representao. Por conta disso, resolvemos adotla. Isso exibido na Figura 32.

87

Figura 32: Extrao da classe Usurio.

Continuando nossa anlise, partirmos para o caso de uso Gesto de Requisitos. fcil notar que um projeto pode ter vrios requisitos. Os requisitos possuem atributos simples: identificador, nome, descrio, tipo, prioridade, complexidade e situao. Os atributos relacionados a uma lista com valores fixos e pr-definidos, como o caso de tipo, prioridade, complexidade e situao, podem ser modelados com o tipo inteiro, onde cada valor pode ser representado por um nmero. No entanto, a anlise desse caso de uso nos levanta duas questes interessantes: 1. Qual o tipo de associao entre projeto e requisitos? Ela no parece ser uma associao simples. Os requisitos fazem parte do projeto e parecem no sobreviver sem a existncia do projeto. Isso nos remete ao conceito de composio. Dessa forma, modelaremos a associao entre projeto e requisitos como uma composio. 2. No prottipo da tela de gesto de requisitos existe um histrico de alterao. Isso nos indica que ser necessrio a existncia de uma entidade que modele as alteraes de requisitos. Nesse caso, a classe requisito dever ter uma associao com os histricos de alterao. 88

A modelagem das classes at as consideraes acima, nos remete a um modelo conforme o exibido na Figura 33.

Figura 33: Modelo do sistema contendo requisitos e alteraes.

Os prximos casos de uso: Gesto de Atores e Gesto de Casos de Uso, esto bastante relacionados. A classe Ator possui atributos simples (nome e descrio) e pode estar relacionada a vrios casos de uso, uma vez que possvel registrar vrios casos de uso associado a um ator. O caso de uso Gesto de Casos de Uso possui diversos atributos e relacionamentos com outras classes. fcil perceber que um caso de uso pode ter vrios prottipos de tela. Isso nos remete a uma nova classe (Prottipo) e o relacionamento com essa classe. Como um prottipo no consegue viver dissociado de seu caso de uso, isso indica uma composio entre os dois. Algo bem mais interessante acontece com os fluxos. Observe que um caso de uso tem um fluxo principal, diversos fluxos alternativos e diversos subfluxos. Um fluxo contm seu nome e passos. Fluxos alternativos contm, alm disso, pr-condies. Isso 89

denota

que

existe

uma

generalizao

envolvida

nesse

relacionamento. Dessa forma, fluxo algo que contm nome e passos e fluxo alternativo um fluxo com pr-condies. Observe que na Figura 34 apresentamos um exemplo para tal modelagem. A classe Caso de uso contm dois relacionamentos com Fluxo: uma para representar o fluxo principal e outro para representar os possveis subfluxos existentes. importante ressaltar que essa uma boa modelagem para o problema, mas difcil de ser percebida para iniciantes na execuo da Anlise.

Figura 34: Modelagem para Ator e Caso de uso.

A ltima parte da ER a ser considerada para Anlise a parte relacionada complexidade Reviso. associada, Essa no parte sendo tambm trivial possui uma e sua anlise

entendimento. Um projeto pode possuir diversas revises. As revises tem critrios associados, com uma indicao de aprovao e uma observao, alm da associao ao item sendo avaliado, que pode ser um requisito ou caso de uso. Mas como representar isso? Nesse caso teremos que criar uma classe adicional, no visvel pelos usurios diretamente, para agrupar todos os elementos necessrios ao relacionamento. Assim, teremos um item de 90

avaliao, que estar relacionado ao critrio utilizado para avaliao, reviso em andamento e ao elemento sendo revisado (requisito ou caso de uso). muito comum durante uma anlise de um caso real, encontrarmos a necessidade de criao de itens para agrupamento, como foi o caso da reviso.

Figura 35: Modelagem dos aspectos relacionados a um reviso.

Observe na Figura 35 o resultado da modelagem dos aspectos ligado uma reviso. O projeto contm revises, que possuem diversos itens de reviso. Esses itens so os responsveis pelo agrupamento que indica qual o critrio utilizado, o que est sendo revisado (requisito ou caso de uso) e qual o resultado dessa avaliao de item em especfico, dado pelos atributos avaliao e observaes. Ainda existem dois casos de uso na ER: Gerao da Especificao e Relatrio de Acompanhamento. Porm, nenhum dos 91

dois acrescenta dados novos. Com isso ento, finalizamos a identificao das classes de entidade. O resultado final dessa Anlise mostrada na Figura 36.

Figura 36: Modelagem final dos conceitos existentes na ER do ReqG.

No entanto, preciso destacar que a Identificao das Classes ainda no foi concluda. Ainda devemos identificar todas as demais classes do projeto. Isso inclui as classes relacionadas s telas e relatrios, denominadas classes de fronteira, alm das classes que devem conter as regras de negcio, denominadas classes de controle. A identificao dessas classes permite a criao das realizaes dos casos de uso. No entanto, a realizao algo que no prescrito pelos mtodos geis e ser apenas demonstrado neste trabalho, sem tanta profundidade.

92

Figura 37: Exemplo de classes de fronteira e controle.

A Figura 37 exibe um diagrama contendo duas classes de fronteira e uma classe de controle. Esses classes foram criadas para representar as telas identificadas para os casos de uso Cadastro de Projetos e Controle de Projetos, alm de uma classe para modelar as regras de negcio relacionadas a projeto, denominada Regras de Projeto. Essas classes foram estereotipadas, com os esteretipos <<boundary>> e <<control>>. Isso possibilitou essa apresentao utilizando a forma icnica, onde as classes se apresentam com imagens no tradicionais. Os esteretipos do mais poder UML, permitindo classificar elementos com alguma coisa em comum. Um exemplo para facilitar o entendimento seria, por exemplo, modelar hospital. Poderamos ter smbolos especficos para representar mdicos e pacientes. Com isso, estaramos estereotipando um elemento. Assim, todos os mdicos teriam o mesmo smbolo, j indicando algumas propriedades e comportamento associado. Esse smbolo poderia estar associado e uma imagem, destacando cada elemento em um diagrama. A Figura 37 nos demonstra que as classes Tela de Cadastro de Projetos e Tela de Controle de Projetos representam classes de apresentao (uma vez que esto estereotipadas como fronteira) e possuem uma associao com a classe Regras de Projeto. Essa 93

classe contm as regras de negcio relacionado a projetos, uma vez que ela est estereotipada como controle. Normalmente, ao identificarmos uma classe j definimos seu esteretipo, embora isso seja uma atividade diretamente relacionada organizao das classes, apresentada a seguir.

4.1.2.

Organizao das Classes

Uma vez identificadas todas as classes de entidade, devemos organiz-las, de forma a facilitar o trabalho e entendimento do projeto. A organizao est associada criao de pacotes com os agrupamentos necessrios, alm da atribuio dos esteretipos exigidos. Devemos utilizar algum critrio para agrupamento das classes. No entanto, no existe uma regras especfica para isso. Geralmente o bom senso o melhor dos guias. Como exemplo, observe o agrupamento sugerido para o nosso exemplo, apresentado na Figura 38. Dividimos o projeto em quatro pacotes: Administrao: para conter os itens relacionados administrao e uso do sistema, composto pelas classes Alterao (registro de histrico de alterao) e Usurios (representao dos usurios do sistema). Projeto: contendo a representao de um projeto e dos seus membros. Requisitos: contendo os elementos ligados requisitos, como os casos de uso, prottipos, atores, fluxos e fluxos alternativos. Reviso: contendo os itens diretamente ligados a uma reviso, como os critrios, itens de reviso e a prpria reviso. Conforme comentado, o importante criar uma organizao no projeto, que favorea seu entendimento. Se isso acontecer, o resultado da execuo da atividade foi bom. 94

Figura 38: Organizao das classes para o ReqG.

4.1.3.

Realizao dos Casos de Uso

Uma realizao de caso de uso mostra como um caso de uso ser implementado, a partir da colaborao dos objetos que os implementam. Isso feito a partir da criao de diagramas de interao (seqncia ou colaborao) detalhando o caso de uso. De forma geral, uma realizao pode ser considerada como a descrio do caso de uso, similar descrio textual, s que utilizando objetos e operaes.

95

Figura 39: Realizao para o caso de uso Controle de Projeto.

A Figura 39 exibe a realizao para o caso de uso Controle de Projetos. Podemos observar que na realizao esto todas as classes relacionadas ao caso de uso: sua tela, regras de negcio e as entidades associadas. No caso em especfico, existe apenas uma entidade relacionada. Se esse caso de uso tivesse que criar relacionamentos com diversos objetos de outras classes, elas deveriam estar na realizao, alm de existir mensagens at esses objetos. Conforme j comentado, alguns processos prescrevem a realizao de todos os seus casos de uso, outros apenas dos mais importantes e, alguns, como os baseados em mtodos geis, no prescrevem qualquer realizao. No entanto, havendo a 96

necessidade de se criar realizaes ser necessrio organiz-las. Um exemplo de tal organizao pode ser exibido na Figura 40. importante mantermos um padro para evitar dificuldades de entendimento.

Figura 40: Organizao das realizaes de um caso de uso.

Uma vez identificadas todas as classes de entidade, devemos organiz-las, de forma a facilitar o trabalho e entendimento do projeto. A organizao est associada a criao de pacotes com os agrupamentos necessrios, alm da atribuio dos esteretipos necessrios.

4.1.4.

Reviso da Anlise

A reviso da anlise o momento de fazermos uma verificao geral nos diagramas e classes identificadas. A reviso da Anlise 97

pode ser feita da mesma forma que a reviso dos Requisitos. Os artefatos so exatamente os mesmos. At mesmo os critrios podem ser iguais. A mudana est na forma de se avaliar o atendimento aos critrios. Por exemplo, o critrio completude deveria verificar se todos os atributos existentes nos prottipos esto modelados nas entidades. Isso, por sinal, um dos principais itens para a reviso da Anlise e que precisa ser executado com bastante ateno. No Anexo V deste trabalho temos a planilha utilizada para a reviso do modelo de Anlise, contendo a descrio dos critrios associados, bem como o resultado da prpria reviso executada.

1.15.

Exerccios

1. Qual o objetivo do fluxo de anlise? 2. Descreva brevemente as atividades do fluxo de anlise. 3. O que uma classe de entidade? 4. Como devemos proceder para identificar classes a partir de um ER? 5. O que um esteretipo na UML? 6. Por que devemos organizar as classes de um modelo de anlise? 7. O que uma realizao de caso de uso? 8. Qual o principal objetivo da reviso da Anlise? 9. Qual um dos principais pontos a se verificar durante uma reviso da Anlise?

98

UNIDADE II ANLISE DE PONTOS DE FUNO

5. Anlise de Pontos de Funo

A cada dia que passa, cresce a necessidade mundial por sistemas de informao, que esto cada vez mais presentes em nossas vidas, auxiliando as mais variadas tarefas. Essa abrangncia dos sistemas, causa tambm um aumento na sua complexidade, sendo sempre importante que eles sejam desenvolvidos o mais rpido possvel, cumprindo sempre um cronograma pr-estabelecido para tal. Um problema frequente relacionado ao desenvolvimento de software est relacionado ao estabelecimento de estimativas de prazos e custos equivocadas, o que leva a dificuldade em cumprimento do que foi estabelecido. Fora isso, provvel que haja uma correria no final do projeto, possibilitando a perda de qualidade para que seja possvel cumprir prazos irreais.
Para se estabelecer estimativas de custo e prazo para projetos de software, necessrio ter uma base histrica de custo e prazo de outros projetos!

Tais problemas so muito comuns. Mas uma pergunta que pode ser feita : como podemos evitar tais problemas? Uma possvel resposta para isso usar experincias passadas, com o apoio de tcnicas associadas ao controle e gesto de projetos. Isso exige o uso de mtricas que permitam associar um trabalho a uma medida clara e objetiva de quanto foi gasto para faz-lo. A Mensurao em software o processo de definir, coletar, analisar e agir sobre medidas que possam melhorar no s a qualidade dos produtos, como tambm o prprio processo de desenvolvimento. fundamental que a mensurao gere dados quantitativos que possam ser utilizados para auxiliar o processo de tomada de decises.

99

Muitas coisas podem ser medidas durante o desenvolvimento de software. So exemplos dessas possibilidades: o tamanho do produto, complexidade, esforo necessrio para sua construo, cronograma, etc. Mas uma importante pergunta que devemos fazer : para que necessitamos medir o tamanho de um produto de software? Vrias so as razes. Apenas medindo que podemos estimar algo. Isso viabiliza a determinao de preo do produto, alm de facilitar o planejamento do projeto. As medidas de tamanho de produtos de software possuem correlao com o esforo necessrio para sua produo. Conhecendo tais medidas podemos ser capazes de realizar estimativas com muito mais chances de acertarmos, uma vez que tendo medidas podemos encontrar a produtividade da equipe. Com base nessa produtividade podemos fazer previses para outras situaes. A Produtividade uma medida importante para a realizao de
A produtividade uma medida fundamental para realizao de estimativas. Ela indica a capacidade de produo por unidade de tempo.

estimativas. Ela baseada na medida do produto do trabalho dividido pelo esforo para produzi-lo. Um exemplo simples disso a produtividade de um pintor. Imagine que ele consegue pintar 20m2 de parede por dia. Essa medida, 20m2/dia, pode ser utilizada para nos guiar nas prximas estimativas. Se existir um servio para pintar 200m2 de paredes, poderamos estimar 10 dias teis de trabalho. Da mesma forma, a produtividade relacionada a software pode nos ajudar em estimativas. Para isso, fundamental que o esforo dedicado para realizar um trabalho seja cuidadosamente medido, de forma precisa. De nada adianta termos o registro do esforo se ele no for preciso. Isso certamente vai gerar estimativas equivocadas. Imagine como exemplo a medida de produtividade do pintor comentado acima. Se houvssemos errado na medida do esforo empregado para pintar uma parede, imaginando, por exemplo, que para pintar 20m2 o profissional gastou apenas 4h ao invs de 8h, qualquer medida feita com base nessa produtividade (20m2/4h) estar associada a uma grande taxa de erro. 100

Dessa forma torna-se claro a necessidade por mensurao, uma vez que ela base para encontrarmos a produtividade e a produtividade nos permite realizar estimativas. No entanto, para a rea de software temos um problema adicional: a mensurao na rea de software no nada trivial! necessrio utilizar uma medida que seja padronizada, uniforme para uma aplicao e inteligvel para a populao. Existem algumas medidas possveis, como linhas de cdigo, casos de uso e mdulos implantados. Mas vamos ver que tais medidas no so as mais adequadas. De forma geral, uma boa medida de tamanho deve possuir algumas caractersticas fundamentais para garantir sua adequabilidade: ela deve ser deduzida dos requisitos, ou seja, a partir da especificao de requisitos associadas ao produto deve ser possvel estimar o tamanho do produto. Um exemplo disso a medida de tamanho de uma casa, em que normalmente utilizado o tamanho em metros quadrados. A partir da especificao de produto (casa), detalhando nmero de quartos, banheiros, salas, possvel deduzir o tamanho da edificao. Se for realizado um pr-projeto, incluindo uma planta baixa, essa estimativa tende a ser muito melhorada, uma vez que ela serve como um prottipo da construo a ser realizada; ser contvel a partir de um procedimento definido. A medida deve permitir que a contagem do tamanho do produto seja facilmente mensurvel quando o mesmo encontra-se completo. Continuando no exemplo de uma casa, podemos notar que, uma vez a casa construda fcil medi-la em m2, permitindo assim uma fcil comparao entre o que foi estimado e o que foi realmente feito.

101

Existem diversas medidas de tamanho que podem ser utilizadas para software. Dentre elas destacamos: linhas de cdigo; pontos de funo; pontos de caso de uso; pontos de objetos.

A medida em linhas de cdigo muito interessante por muitos aspectos, dentre eles, podemos destacar que ela a mais simples e barata de se utilizar. Alm disso, ela pode ser contada de forma totalmente automtica, uma vez que possui as caractersticas comentadas acima. Aps as explicaes acima, detalhando as vantagens

associadas ao uso de linhas de cdigo como medida de tamanho para software, podemos nos questionar: por que ela no seria a medida ideal a utilizarmos? por que utilizar outra medida? A resposta para as perguntas anteriores , tambm,

relativamente simples: linhas de cdigo somente podem ser medidas DEPOIS do produto concludo. Mas, no entanto, essa medida no
A medida em linhas de cdigo muito boa: simples, de baixa custo, bem definida. Mas ela s pode ser obtida DEPOIS do produto pronto! Isso impossibilita seu uso para estimar a construo do produto.

adequada por que ela no pode ser obtida dos requisitos. Ou seja, ela no pode nos ajudar em estimativas, pois ela adequada para contar o tamanho de produtos construdos e no de produtos a construir. Alm disso, a medida em linhas de cdigo no independente de tecnologia: um produto desenvolvido em Java deve ter tamanho diferente de um desenvolvido em Delphi, que deve ser diferente de um desenvolvido em Ruby. Isso no uma caracterstica boa para uma medida. Por esses motivos, foram criados outras medidas apropriadas para o desenvolvimento de software. Uma dessas medidas, denominada pontos de funo bastante utilizada no mundo e objeto de estudo deste captulo.

102

5.1

Introduo a Anlise de Pontos de Funo

A Anlise de Pontos de Funo (APF) mede a funcionalidade

entregue ao usurio. Uma caracterstica interessante da APF que ela independente da forma de implementao, ou seja, se o produto vai ser desenvolvimento em Java, C, Ruby, Delphi, isso no influencia em nada a contagem realizada. Essa caracterstica de independncia de tecnologia possibilita algo muito interessante: a comparao entre empresas e linguagens.
APF independente de tecnologia. Isso permite comparar empresas e tecnologias de forma efetiva!

Existindo uma medida independente de tecnologia, possvel analisar se a empresa X trabalha de forma mais rpida que a empresa Y, caso ambas iniciem o desenvolvimento do produto. Da mesma forma, podemos analisar se a linguagem A permite maior produtividade que a linguagem B. Pontos de funo foram inicialmente propostos por Allan Albrecht em 1979. A formalizao das regras de contagem teve incio em 1984, pela IBM, a partir da criao de manuais para guiar a contagem. Em 1986 foi criado o International Function Points Users Group (IFPUG). como Essa lder organizao na tem e como misso ser do reconhecida promoo encorajamento

gerenciamento do desenvolvimento de software a partir do uso da APF. Dentre outras atribuies, o IFPUG mantm o manual de contagem de pontos de funo, que atualmente est em sua verso 4.3.1 e pode ser obtido na pgina oficial da organizao (http://www.ifpug.org/). A tcnica de Anlise de Pontos de Funo foi concebida com dois objetivos principais: Possibilitar a mensurao de funcionalidades que um software oferece da aos seus usurios, utilizada de para forma sua independente implementao; Criar uma forma de contagem que gere um custo adicional pequeno, no sendo caro realizar a medio e 103 tecnologia

que permita que seu uso seja feito entre diferentes projetos e organizaes. Aps sua criao e uso por parte da comunidade, foi possvel notar que a tcnica de APF possua no somente os benefcios inicialmente propostos, mas permitia tambm: Determinar o tamanho de uma aplicao j construda, a partir da funcionalidade nela contida; Determinar os benefcios de um pacote de aplicativos para uma organizao, baseados em quantas funes eles atendem dentro do contexto de necessidades existentes, permitindo uma comparao quantitativa sobre quem atendeu mais em termo de tamanho. Alm disso, a APF permitiu que o controle de produtividade dos elementos que fazem parte de uma equipe de desenvolvimento fosse medido e acompanhado. Isso foi possvel devido ao fato de existir um mtodo simples para se medir o tamanho de uma funcionalidade, aliada ao tempo para se desenvolver tal funcionalidade. Isso gera a produtividade, que, conforme j foi dito, a razo entre o tamanho de um produto de trabalho desenvolvido pelo esforo necessrio para sua produo. Fora a produtividade, foi possvel estabelecer um parmetro de comparao com outros projetos, permitindo estimar outros recursos necessrios para uma empreitada. Isso permite um melhor planejamento, pois independe da tecnologia utilizada, pontos de funo servem para normalizar os dados relativos a tamanho, permitindo a comparao entre empresas, tudo isso de forma independente do que usam para produzir seu trabalho. De forma geral, as principais vantagens do uso de APF so: Transparncia para o usurio final. Com o uso de APF, o usurio consegue entender a medida de tamanho relacionada ao produto que ele deseja. Isso tambm permite o acompanhamento da evoluo do produto. 104

Isso tambm estimula o prprio usurio e o torna mais ativo no desenvolvimento. Apoio estimativa de tempo, recursos e custos. O uso de APF permite estimar o tempo necessrio para desenvolver algo, baseado em uma comparao da produtividade de uma equipe em projetos passados. A partir dessa base histrica possvel encontrar o tempo gasto para desenvolver um ponto de funo, permitindo assim estimar qualquer trabalho que possa ser contado utilizando APF. importante notar que, mesmo se tivermos um detalhamento do projeto, mesmo que ele esteja em estgios iniciais de desenvolvimento, possvel j iniciar as estimativas, pois a contagem pode ser feita de forma preliminar. Essa outra caracterstica muito interessante. Facilitar contratos de terceirizao. Muitas vezes, uma empresa terceirizada pode alegar ter trabalho por 100h em parte de um software sem ter conseguido muita evoluo. Por isso a contagem em horas no considerada uma forma eficiente para se avaliar contratos terceirizados. fundamental acompanhar tais contratos pela medida de funcionalidade desenvolvida em um perodo de tempo. Por conta disso, APF a tcnica sugerida para acompanhar praticamente todos os contratos de desenvolvimento existentes nas instituies pblicas. De forma geral, a APF uma tcnica muito utilizada no mundo e bastante consolidada. Isso no significa que ela no tenha defeitos. Possui vrios e possui contextos de uso bem definidos. Iremos tratar disso mais a frente. Por hora, vamos detalhar um pouco melhor como ela funciona.

5.2

O Processo de Contagem
105

Muito j falamos sobre APF. Mas como ela funciona exatamente? Nesta seo trataremos disso. Uma representao dos principais elementos relacionados contagem de pontos de funo
A contagem de PF baseada em 5 elementos: dados mantidos pela aplicao, dados mantidos por outra aplicao e usados pela aplicao sendo contada, funes que mudam dados, funes que consultam dados e realizam processamento nesses dados e funes que apenas consultam dados.

exibido na Figura 41. Para a contagem temos que levar em considerao cinco elementos: 1. Arquivo Lgico Interno (ALI), que representam os dados mantidos pela aplicao. 2. Arquivo de Interface Externa (AIE), que representam dados utilizados pela aplicao, mas mantidos por outras aplicaes. 3. Entrada Externa (EE), que representam as entradas de dados que causam mudanas nos ALIs. 4. Sada Externa (SE) que causam a exibio de dados relacionados aplicao, normalmente exigindo algum tipo de processamento. 5. Consulta Externa (CE) que causam a simples exibio de dados relacionados aplicao.

Figura 41: Representao dos principais elementos associados APF.

A contagem de pontos de funo envolve um procedimento simples, baseado em poucos passos: 1. Determinar o tipo de contagem; 2. Identificar o escopo de contagem e a fronteira da aplicao; 3. Contar funes de dados; 4. Contar funes de transao; 5. Determinar o fator de ajuste; 6. Calcular o total de pontos de funo ajustados. 106

Cada um desses passos sero detalhados nas prximas sees. Por enquanto, iremos detalhar mais alguns aspectos relacionados contagem. De forma geral, existem trs tipos de contagem de PF: Projeto de desenvolvimento. Nesse caso medido o tamanho das funes oferecidas aos usurios, decorrentes do desenvolvimento de um software, que ser criado no projeto, ou seja, ele no existe ainda. Projeto de evoluo. feita a medida das modificaes de funcionalidades associadas a uma aplicao existente, ou seja, a contagem das mudanas em um software que j foi desenvolvido mas precisa ser alterado. Aplicao. Est associado medida das funcionalidades existentes em uma aplicao. Essa medida inicializada quando a contagem do projeto de desenvolvimento concluda. Depois, cada vez que um projeto de evoluo realizado, a contagem da aplicao deve ser atualizada, incorporando a medida das mudanas efetivadas. Para que uma contagem possa ser realizada necessrio definir o objetivo da contagem, deixando claro para que ser realizado o trabalho de mensurao. Existem diferentes objetivos possveis. necessrio tambm estabelecer o escopo da contagem, determinando exatamente o que deve ser considerado. Alm disso, necessrio estabelecer o limite existente entre o sistema e o mundo exterior, uma vez que isso ajuda a guiar a contagem. Podem existir diferentes objetivos para uma contagem. Um possvel objetivo fornecer insumos para a estimativa do esforo de desenvolvimento. Podemos contar o tamanho de um software, a partir da sua especificao, com o intuito de utiliza-lo para estimar o tempo de desenvolvimento. Isso feito com base em outros projetos 107

conjunto de aplicaes instaladas. Nesse caso, realizamos uma contagem apenas para termos o inventrio dos sistemas existentes. Um outro objetivo comparar o tamanho das funcionalidades oferecidas por produtos concorrentes. Imagine que estamos querendo selecionar o produto que mais atenda a uma certa especificao. Poderamos contar o tamanho de funcionalidade atendida por um e pelo outro, facilitando assim saber quem mais atende. Alm do objetivo, necessrio definir o escopo da contagem. Isso significa que devemos definir um (sub)conjunto do software a ser medido, utilizando como base o objetivo definido. necessrio determinar exatamente o que deve ser includo na contagem. Em alguns casos isso pode incluir mais de uma aplicao. Em projetos de evoluo, o escopo da contagem pode incluir todas as funes adicionadas, alteradas ou excludas. Em projetos de desenvolvimento isso inclui todas as funes construdas ou customizadas pelo projeto. Em aplicaes inclui toda a funcionalidade ou apenas a frao que tem valor para o usurio, como por exemplo no caso de comparao entre ferramentas que mais atendem certas funcionalidades. Para que a contagem acontea, tambm importante definir a fronteira da aplicao. Isso significa que devemos estabelecer uma diviso conceitual entre a aplicao e mundo externo, uma vez que temos que saber exatamente o que est dentro e o que est fora da aplicao, pois isso tem influncia direta na contagem. Os dados mantidos pela aplicao possuem contagem diferenciada de dados apenas consultados, mantidos externamente. fundamental saber quais so as funes que operam utilizando dados que cruzam a fronteira da aplicao a partir de transaes. A fronteira da aplicao deve ser definida com base na viso do usurio. Ele deve ser independente do escopo da contagem. Ela deve ser delimitada em reas funcionais, como vistas pelo usurio e no baseada em consideraes tcnicas. A fronteira dada por 108

aquilo que o usurio percebe. Assim, analisando a aplicao pela viso do usurio conseguimos dizer o que faz parte e o que no faz parte da aplicao.

Figura 42: Aes para clculo em PF.

A Figura 42 exibe as aes relacionadas a contagem em Pontos de Funo. Inicialmente, necessrio identificar todas as funes existentes na aplicao. Em seguida, necessrio contar os elementos. Podem existir diversos elementos associados a uma funo, sendo necessrio cont-los adequadamente. Aps essa contagem ser possvel estabelecer os pesos relacionados a cada parte a ser considerada. A partir desses pesos possvel identificar o tamanho em PF. A identificao de funes o momento em que devemos listar todas as funes existentes na aplicao. Isso deve ser feito levando-se em considerao o escopo da contagem, uma vez que ele determina o que deve ser includo. Cada funo dever contribuir para parte do tamanho total da aplicao. Basicamente, existem duas categorias de funes: Funes de dados Funes de transao

109

As funes de dados representam a funcionalidade oferecida ao usurio para cumprir requisitos de dados, ou seja, elas so a representao de todos os dados existentes na aplicao. Elas podem ser categorizadas em dois tipos:
A diferena de um ALI para um AIE simplesmente o fato que um ALI mantido pela aplicao sendo contada e o AIE no!

Arquivo Lgico Interno (ALI); Arquivo de Interface Externa (AIE).

importante ressaltar que o termo arquivo refere-se a grupos de dados logicamente correlatos, independente de sua forma de implementao. Assim, um ALI pode representar um dado que foi implementado sob a forma de uma tabela em um banco de dados. No caso de um sistema de biblioteca, poderamos ter como funes de dados: Usurio da biblioteca; Ttulo; Exemplar; Emprstimo; Reserva.

Os AIEs so similares aos ALIs, com uma nica diferena: eles so mantidos por outra aplicao e no pela aplicao sendo considerada na contagem. Ou seja, os AIEs so ALIs em outras aplicaes. Por exemplo, imagine que em um sistema de biblioteca, no tenhamos os dados de endereo (logradouro, bairro, cidade, estado) de um usurio. Ao invs disso, temos apenas o CEP e o nmero. Assim, os dados de endereo sero considerados como um AIE, pois no sero mantidos pela aplicao. As funes de transao representam a funcionalidade oferecida ao usurio para processar os dados da aplicao. Elas podem ser de trs tipos: Entrada Externa (EE); Sada Externa (SE); Consulta Externa (CE). 110

Conforme j comentado, uma EE representa alguma funo que causa algum tipo de mudana em dados mantidos pela aplicao. So exemplo de EE em um sistema de biblioteca o emprstimo de livro, reserva de exemplar, incluso de novo usurio. Cada uma dessas funes deve causar uma alterao em um dado mantido em algum ALI da aplicao.
A diferena de uma SE para uma CE que existe um processamento associado a uma SE.

Uma SE representa a gerao de dados, normalmente na forma de um relatrio, que envolva algum tipo de processamento associado. So exemplos desse tipo de funo o quantitativo de emprstimos por perodo e livros com maior quantidade de reserva. Uma CE representa algo parecido com uma SE, porm, no envolve nenhum tipo de processamento complexo para sua gerao. So exemplos de tais funes a listagem de livros emprestados e usurios ativos. Uma vez tendo identificado todas as funes, precisamos contar os elementos presentes. Para o caso de funes de dados necessrio contarmos os tipos de registros e os campos de dados envolvidos. Nas prximas sees iremos fazer isso para o exemplo da apostila. Para cada funo de transao necessrio contar os arquivos referenciados e os campos de dados. A partir dessa contagem podemos classificar cada funo quanto complexidade, que pode ser Baixa, Mdia ou Alta. Cada tipo de funo possui um peso, de acordo com sua complexidade. O peso corresponde quantidade de PF no ajustados que a funo agrega aplicao. Somando-se os pesos de todas as funes, podemos obter o total de PF no ajustados. A Tabela 7 exibe os pesos associados s funes. Nela temos a classificao por cada tipo de funo e por complexidade. Uma vez que saibamos quais so as funes existentes e sua complexidade, basta obter o seu peso, que j representa o tamanho em PF.

111

Tabela 7: Pesos associados s funes na contagem de PF.

5.2.1 Contagem de Funes de Dados

A contagem de um ALI deve ser independente de modelagem e baseada na viso do usurio.

As funes de dados so tipicamente as primeiras funes contadas em uma aplicao. Conforme j mencionado, so divididas em ALI e AIE, correspondendo a grupos de dados que podem ser atualizados e recuperados pela aplicao. importante ressaltar que os agrupamentos utilizados para a contagem no esto associados sua implementao no sistema desenvolvido. Eles devem estar associados ao significado lgico reconhecvel pelo usurio. Os ALIs so grupos de dados ou informaes de controle, identificveis pelo usurio e mantidos dentro da fronteira da aplicao. Seu objetivo principal armazenar dados, mantidos por meio de um ou mais processos elementares da aplicao que est sendo contada. Para se identificar ALIs necessrio procurar por grupos de dados ou informaes de controle correlatos. Um ALI deve necessariamente apresentar uma unidade lgica reconhecvel pelo usurio e deve ser mantido por meio de um processo elementar da aplicao.

112

 importante ressaltar que no devemos considerar os arquivos lgicos que o usurio no tenha acesso, tais como arquivos internos do sistema (temporrios ou de trabalho). Para se atribuir complexidade a um ALI necessrio identificar
Para a contagem de um ALI necessrio identificar o nmero de agrupamentos existentes (TER) e nmero de campos (TED).

os Tipos de Elementos de Registro (TERs) e os Tipos de Elementos de Dados (TEDs). Um TER um subgrupo de dados dentro de um ALI/AIE reconhecvel pelo usurio. Essa definio normalmente traz muitas dvidas aos contadores, uma vez que essa definio imprecisa. Mas de modo geral, uma ALI/AIE possui apenas um TER. O outro elemento associado contagem de ALI/AIE so os TEDs. Eles representam um campo nico, no repetitivo e reconhecvel pelo usurio, mantido ou consultado no arquivo durante a execuo de uma funcionalidade. No entanto, fundamental ressaltar que devemos considerar apenas os TEDs que so efetivamente usados pela aplicao. Assim, se um ALI possui 20 TEDs mas so utilizados apenas 10 na aplicao, temos que considerar apenas os 10 campos. Alm desses campos, necessrio considerar os dados necessrios para estabelecer relacionamentos entre os ALI/AIE.
Tabela 8: Tabelam para classificao de ALI/AIE.

A Tabela 8 exibe a tabela com os parmetros para classificao de um ALI/AIE. Os AIEs so, de forma similar aos ALIs, grupo de dados ou informaes de controle, identificveis pelo usurio e referenciados 113

pela aplicao. No entanto, eles so mantidos na fronteira de outra aplicao. Logicamente, por conta disso, tambm devero ser contados de forma diferente.

5.2.2 Contagem de Funes de Transao

As funes de transao correspondem funcionalidade oferecida ao usurio com o intuito de permitir o processamento dos dados contidos na aplicao. Isso inclui a entrada de dados, consultas a dados pr-armazenados, alm da gerao de dados derivados. Conforme j comentado, existem, basicamente, trs tipos de funes de transao: Entrada Externa (EE), Sada Externa (SE) e Consulta Externa (CE). Entrada Externa Uma Entrada Externa um processo elementar da aplicao que processa dados ou informaes de controle que entram na fronteira de aplicao, ou seja, tem como principal objetivo manter um ou mais ALIs. Isso normalmente causa uma alterao no comportamento da aplicao. O termo processo elementar utilizado para denotar a menor unidade de atividade que significativa para o usurio. Essa funo deve sempre levar a aplicao a um estado consistente, sob a tica do negcio. importante frisar que para algo ser classificado como uma Entrada Externa necessrio receber dados de fora da aplicao. Isso significa que pelo menos um ALI deve ser mantido. Para se identificar uma EE, pelo menos uma das seguintes condies deve ser satisfeita: A lgica de processamento deve ser nica, diferente das lgicas executadas por outras EEs;

114

O conjunto de elementos de dados identificado diferente daqueles identificados para outras EEs; O conjunto de ALIs ou AIEs referenciados diferente daqueles referenciados por outras EEs.

necessrio contar apenas os dados de cruzam a fronteira da aplicao e que fazem sentido para o usurio. Nada de contar entradas dependents de tecnologia e imperceptveis na viso do usurio.

So casos tpicos de uma EE a incluso, alterao ou excluso de itens em um cadastro, obteno de mensagens e atualizao de arquivos. No devemos considerar entradas necessrias apenas em funo da tecnologia empregada e que no contribuem em nada para o usurio, nem parte da entrada das consultas que serve apenas para direcionar a recuperao de dados, como so os casos de parmetros de pesquisa e nem telas de entrada para fins de navegao, como os menus. Em alguns casos, existem sistemas com mtodos diferentes para executar a mesma funo. Eles no devem ser considerados EEs. Da mesma forma, respostas s mensagens de confirmao no cruzam a fronteira da aplicao. Uma vez identificada uma EE, necessrio atribuir sua complexidade. Isso est diretamente ligado identificao dos Tipos de Arquivos Referenciados (TARs) e Tipos de Elementos de Dados (TEDs). Os TARs representam o nmero de ALIs/AIEs mantidos ou referenciados pela EE. Os TEDs representam os campos reconhecveis pelo usurio, que cruzam a fronteira da aplicao durante a EE. Uma vez conhecidos o nmero de TARs e TEDs, podemos chegar complexidade da funo. A Tabela 9 exibe a tabela para atribuio de complexidade para uma EE.

115

Tabela 9: Atribuio de complexidade para EEs.

Sada Externa Uma Sada Externa (SE) um processo elementar da aplicao que gera dados ou informao de controle para fora da fronteira da aplicao. Seu objetivo principal apresentar informaes ao usurio da aplicao, fornecendo dados que auxiliem suas atividades. Uma SE funciona a partir de uma lgica de processamento, que envolve a gerao de dados derivados. Essa, por sinal, a diferena de uma SE de uma CE. Uma SE envolve dados cuja obteno requer algum tipo de processamento alm da recuperao de campos de ALIs. Se isso no ocorrer, no se trata de uma SE. Para a identificao de uma SE, necessrio procurar por dados ou informaes de controle que devem sair da fronteira da aplicao. Ressaltando mais uma vez, a lgica de processamento de uma SE deve: Conter pelo menos um clculo ou frmula matemtica; Criar dados derivados; Manter pelo menos um ALI; ou Alterar o comportamento da aplicao.

Um outro detalhe importante que a lgica de processamento utilizada na SE deve ser nica, diferente daquela executada por outras SEs. Da mesma forma, o conjunto de elementos de dados identificado deve ser diferente daqueles identificados para outras 116

SEs, assim como o conjunto de ALIs ou AIEs referenciados tambm deve ser diferente daqueles referenciados por outras SEs. Se isso no se configurar, provavelmente temos uma nica SE, que possui parmetros diferentes e que no deveria ser contada como uma outra SE. So exemplos tpicos de SEs: Relatrios que consolidam dados atravs de clculos; Telas de exibio de dados, que possuam dados derivados; Exibio de grficos com dados calculados; Transferncia de dados, arquivos ou mensagens enviadas a outra aplicao, quando isso envolve gerao de dados derivados ou atualizao de arquivos. muito importante que no seja considerado como SEs relatrios idnticos, com valores de dados diferentes. Uma mudana em um parmetro, seja a introduo de um parmetro adicional, no representa uma SE diferente. Da mesma forma, mensagens de erro ou validao, que fazem parte de outro processo elementar, no podem ser consideradas SEs. Assim, se no processo de incluso de um elementos em uma aplicao, for necessrio fazer uma validao, que gere um dado calculado, que ser apresentado e demonstrado como uma mensagem ao usurio, isso no pode ser considerado como uma SE. Arquivos enviados a outras aplicaes, que no envolvam dados derivados ou manuteno de arquivos, tambm no podem ser consideradas SEs. De forma similar a EE, a atribuio de complexidade a uma SE se d a partir da identificao dos TARs e TEDs contidos na funo. A regra tambm bem parecida: Contar um TAR para cada ALI ou AIE lido durante o processamento da SE, de acordo com os requisitos do usurio;

117

Contar um TAR para cada ALI mantido pelo processo elementar da SE, lembrando que cada ALI conta uma vez, e no cada TER de um ALI; Contar apenas uma vez os ALIs que so tanto lidos quanto mantidos; Contar um TED para cada campo no repetitivo reconhecido pelo usurio, seja ele um campo que entra na fronteira da aplicao ou que saia da fronteira da aplicao. Se um mesmo TED entra e sai da fronteira da aplicao, ele deve ser contado apenas uma vez.

Alguns detalhes especiais com relao contagem de TEDs devem ser especificadas. No devemos contar: Numerao de pginas; Campo de data/hora de emisso de relatrio; Literais (strings); Ttulos fixos, nomes de campos, ttulos de colunas, etc; Campos de ALIs mantidos ou consultados, que no cruzem a fronteira da aplicao; Campos mltiplos que na viso do usurio tenham um significado nico, como por exemplo, mltiplas linhas de um campo de endereo. A Tabela 10 exibe a tabela para atribuio de complexidade para uma SE.
Tabela 10: Atribuio de complexidade para SEs.

118

Consulta Externa Uma Consulta Externa (CE) um processo elementar que recupera dados ou informao de controle para fora da fronteira da aplicao. Seu objetivo principal apresentar informaes ao usurio, a partir da simples recuperao de dados de ALIs e/ou AIEs. Um CE no envolve clculos nem manuteno de ALIs. No entanto, fundamental que existam dados ou informaes de controle que saiam da fronteira da aplicao, recuperados de um ou mais ALIs ou AIEs associados funo. A lgica de processamento envolvida em uma CE no pode conter clculos ou frmulas matemticas, nem a gerao de dados derivados ou a manuteno de ALIs. O CE tambm segue as mesmas restries associadas a uma SE: A lgica de processamento nica, diferente daquela executada por outras CEs; O conjunto de elementos de dados identificado diferente daqueles identificados para outras CEs; O conjunto de ALIs ou AIEs referenciados diferente daqueles referenciados por outras CEs. So exemplos tpicos de CEs relatrios que exibem dados contidos em ALIs ou AIEs, sem clculos, telas de exibio de dados que no possuam dados derivados e transferncia de dados, arquivos ou mensagens enviadas a outra aplicao, sem que haja dados derivados ou atualizao de ALIs. Existem algumas caractersticas adicionais na contagem de CEs. So tambm classificados como CEs: Telas de log-on, para autenticao de usurios; Ajuda on-line. Nesse caso, cada nvel de ajuda (tela, campo) conta como uma CE distinta; 119

Consultas do tipo lista e combo, normalmente utilizadas para facilitar o preenchimento de campos em outros processos elementares.

Tambm de forma similar s SEs, no devem ser consideradas CEs relatrios idnticos com valores de dados diferentes, mensagens de erro ou confirmao que fazem parte de outro processo elementar e arquivos enviados a outras aplicaes que envolvam dados derivados ou manuteno de arquivos. A contagem tambm feita de forma similar a uma SE: devem ser contado um TAR para cada ALI ou AIE lido durante o processamento da CE. A contagem para TEDs similar ao de uma SE. A Tabela 11 exibe a tabela para atribuio de complexidade para uma CE.
Tabela 11: Atribuio de complexidade para CEs.

5.3

Contagem Estimativa de Pontos de Funo

Nesta seo explicaremos como proceder com uma contagem

estimativa de pontos de funo. importante ressaltar que uma contagem estimativa no tem como objetivo ir a fundo nas regras e detalhes da contagem. Ela serve como uma aproximao do valor exato, para fins gerenciais, mas sem ser to rigorosa quanto ao processo utilizado para obteno desse valor. Nosso objetivo neste captulo no tornar o leitor um especialista em APF, mas sim um conhecedor da tcnica. Para se 120

tornar um especialista ser necessrio muito mais investimento no estudo do manual do IFPUG, bem como na prtica de contagem. A Figura 43 exibe um resumo do roteiro para contagem estimativa em um projeto de software. De posse do modelo de dados para o projeto, normalmente contido nos diagramas UML que descrevem a aplicao, possvel realizar uma contagem das funes de dados existentes. Da mesma forma, com a descrio das funes, normalmente contidas nas descries dos casos de uso que compem o projeto, possvel contar as funes de transao. Assim, a Especificao de Requisitos, juntamente com o Modelo de Anlise possuem todas as informaes necessrias para procedermos com uma contagem.

Figura 43: Roteiro para contagem estimativa em um projeto.

Agora vamos proceder com a contagem estimativa para o nosso exemplo. importante ressaltar que em uma contagem, normalmente surgem diversas dvidas. Precisamos anotar nossas decises para que qualquer pessoa que tente realizar uma contagem possa chegar aos mesmos resultados. Neste trabalho no discutimos nem utilizaremos o fator de ajuste, que uma medida que pode influenciar em 35% do tamanho do sistema (para mais ou para menos), devido a algumas 121

caractersticas a serem avaliadas. Como o fator de ajuste est muito defasado, por conta das caractersticas avaliadas, utilizaremos apenas o valor bruto calculado. Em uma contagem tradicional esse valor deveria ser multiplicado pelo fator de ajuste, para obtermos o clculo em pontos de funo ajustados.

5.3.1 Contagem de funes de dados

Nossa contagem se inicia pelas funes de dados. Nosso
Esta seo apresenta um exemplo de contagem estimativa para funes de dados. Voc dever fazer o mesmo para um exemplo escolhido por voc.

sistema exemplo, mesmo no sendo complexo, possui diversas classes. Temos que proceder com a contagem desses elementos. Utilizaremos como base o diagrama de classes exibido na Figura 36. Iniciando pela classe Projeto, podemos perceber que ela um ALI contendo 9 TEDs. Ela no possui nem um agrupamento interno, por conta disso, devemos conta-la como um ALI com apenas um TER. De acordo com a Tabela 8, Projeto uma ALI simples. Continuando pela classe Membro, comeamos a ter que decidir algumas questes para proceder com a contagem. Conforme pode ser visto na Figura 36 a classe Membro herda de Usurio, que por sua vez tem uma relao com Alterao. De um modo geral, um usurio da aplicao no perceber essa diviso interna. Assim, essas 3 classes juntas representam um nico ALI, que possui 2 TERs (e no 3, pois Usurio e Membro representam apenas um agrupamento). Como todo membro deve ter as informaes de usurio, isso representa um nico TER, ao invs de 2. A classe alterao representa um outro TER. Com isso, temos que Membro um ALI, que possui 2 TERs. Com relao a quantidade de campo, possumos as seguintes quantidades: Membro possui 4 campos; Usurio possui 2 campos; Alterao possui 1 campo.

Nossa contagem levar em considerao 10 campos para Membro, contabilizando os 4 visveis diretamente, 2 de usurio e 2 campos adicionais, para permitir seus relacionamentos com projeto, 122

alm de 2 outros campos para a classe Reviso. Com isso teremos 7 TEDs. Com isso, a complexidade do ALI Membro pode ser considerada baixa. A classe Critrio representa um ALI simples, sem

agrupamentos. Ela possui 3 campos, porm, devemos considerar um campo adicional para o relacionamento com projeto. Assim, a classe critrio tem complexidade baixa. A classe Requisito um ALI que possui 2 TERs. Consideramos isso por conta do relacionamento com Alterao. Requisito possui 7 campos, mas consideraremos 8 por conta do relacionamento com Projeto. Alterao possui um campo, mas consideraremos 2 por conta do relacionamento com Requisito. Assim, temos Requisito como sendo um ALI, com 2 TERs e 10 TEDs. A classe Ator representa um ALI simples, contendo um agrupamento para alteraes. Ela possui 2 campos, porm, devemos considerar um campo adicional para o relacionamento com Caso de uso. Alterao possui 1 campo, mas vamos considerar 2 por conta do agrupamento com Ator. Assim, a classe Ator uma ALI, com 2 TERs e 5 TEDs. Ela tem complexidade baixa. A classe Caso de uso provavelmente o item mais complexo do exemplo. Ela possui diversos TERs: Caso de uso, com 6 campos; Alterao com 1 campo; Prottipo com 2 campos; Fluxos com 2 campos; Fluxos alternativos com 1 campo.

No total, Caso de uso um ALI com 5 TERs e que possui 18 campos, pois foram contabilizados 8 campos para a classe caso de uso (2 adicionais para o relacionamento com requisitos e atores), 2 campos para Alterao (1 campo adicional para o relacionamento com Caso de uso), 3 campos para Prottipo (1 campo adicional para 123

o relacionamento com Caso de uso), 3 campos para Fluxo (1 campo adicional para o relacionamento com Caso de uso) e 2 campos para Fluxo Alternativa (1 campo adicional para o relacionamento com Caso de uso). Assim, Caso de uso considerado um ALI com complexidade baixa. Observe que embora bem mais complexo que os demais ALIs analisados aqui, ele ainda possui a mesma complexidade. Essa uma das crticas a contagem em PF. Finalizando, a classe Reviso possui um agrupamento para a avaliao, denominada Item de reviso. A classe Reviso possui 4 campos e Item de reviso possui 2 campos. No entanto, existem 3 relacionamentos adicionais, que Reviso responsvel (2 com Membro e um com Projeto). Item de reviso possui 4 campos adicionais, por conta dos relacionamentos com Reviso, Critrio, Requisito e Caso de uso, contabilizando 4 campos adicionais. Assim, Reviso um ALI com 2 TERs e 13 TEDs. Com isso, Reviso tambm possui complexidade baixa. A Tabela 12 resume a atribuio de complexidade para os elementos presentes em nosso exemplo.
Tabela 12: Resumo das complexidades para os ALI do exemplo.

Cada ALI de complexidade baixa conta 7 PF, conforme descrito na Tabela 7. Assim, temos 6 ALIs simples, que nos resulta em 6 x 7 = 42 pontos de funo de dados.

5.3.2 Contagem de funes de transao

Agora procederemos com a contagem das funes de transao. Vale ressaltar que uma contagem detalhada deve levar em considerao todas as regras, incluindo campos chaves, comandos, ajuda, previso de relacionamentos, etc. Por conta disso, 124

faremos uma contagem bastante simplificada. Utilizaremos com base para contagem de TEDs apenas os campos visveis ao usurios, esquecendo-se de outros detalhes da contagem. Assim, contaremos os ALIs/AIEs referenciados na funo (que sero os TARs) e os TEDs envolvidos. Depois disso, faremos a atribuio de complexidade, baseado nas tabelas de atribuio de complexidade para EE, SE e CE (Tabela 9, Tabela 10, Tabela 11).
De forma similar seo anterior, nesta seo apresentamos um exemplo de contagem estimativa para funes de transao. Voc dever fazer o mesmo para um exemplo escolhido por voc.

A contagem das funes de transao vai seguir a ordem dos casos de uso na Especificao de Requisitos do ReqG. O primeiro caso de uso o Cadastro de Projeto. A pesquisa por projeto faz com que 2 campos cruzem a fronteira do sistema. Esses campos so de dois ALIs diferentes: Projeto e Membro (gerente). Assim, a pesquisa uma CE que possui 2 TARs e 2 TEDs referenciados. Por conta disso, ela uma CE de complexidade baixa, conforme Tabela 11. Ainda no Cadastro de Projeto possvel visualizar os dados, exibindo os trs campos relacionados (sigla, descrio e gerente). A visualizao tambm possui 2 TARs (Projeto e Gerente) e 3 TEDs. Ela tambm uma CE de complexidade baixa. A alterao uma EE que possui 2 TARs e 3 TEDs. Ela uma EE de complexidade baixa. A excluso um caso diferenciado. Para a excluso, normalmente apenas o identificador do elemento a ser excludo cruza a fronteira da aplicao. Por conta disso, utilizaremos sempre nas excluses o padro de termos 1 TAR e 1 TED. Isso funciona dessa forma na contagem detalhada, porm, existem algumas outras regras envolvidas. O segundo caso de uso considerado Gesto de Gerentes. Podemos realizar uma pesquisa, a visualizao dos dados de um gerente, uma incluso, alterao e excluso. A pesquisa uma CE que referencia dois ALIs: Gerente e Projeto. Alm disso, a pesquisa exibe 4 campos. O restante da funes lida apenas com o ALI Gerente. A visualizao, incluso e alterao lidam com 5 campos. A excluso, conforme nossa padronizao, trata de apenas 1 campo.

125

O prximo caso de uso, Gesto de Membros, parecido com o caso de uso Gesto de Gerentes. Podemos realizar uma pesquisa, a visualizao dos dados de um membro, uma incluso, alterao e excluso. Todas as funes referenciam 2 ALIs: Membro e Projeto. O restante contar os campos referenciados e atribuir a complexidade. O caso de uso Controle de Projetos possui apenas 3 funes: pesquisa, alterao e visualizao. A pesquisa um CE que referencia 2 ALIs, Projeto e Membro. A visualizao e alterao tambm referenciam 2 ALIs, mas exibem vrios campos. Observe que alguns campos aparecem 2 vezes na tela, por isso no so contados duas vezes. So exemplos disso o nome do projeto e nome de um membro, que aparecem tanto nos dados do projeto, como tambm nos dados dos Membros. O caso de uso Gesto de Requisitos um CRUD (acrnimo para Create, Read, Update, Delete) que referencia 3 ALIs: Projeto, Requisito e Membro. No entanto, na pesquisa so referenciados apenas 2 ALIs. O caso de uso Gesto de Atores tambm um CRUD. Ele possui 3 ALIs referenciados: Projeto, Caso de Uso e Ator. A pesquisa referencia 4 campos, enquanto que as outras funes (com exceo da excluso) referenciam 8 campos. A Gesto de Casos de Uso possui muitos ALIs referenciados. Na pesquisa so referenciados 3 ALIs: Caso de uso, Requisito e Projeto. Nas demais funes, ainda temos referencia a Membro e Ator. Observe que existem campos na tela utilizados para entrada de dados mas que no cruzam a fronteira do sistema. Um exemplo disso a tabela Dados do Fluxo Alternativo. Os campos so usados para criar a lista de Fluxos Alternativos da tela. Essa lista que enviada e que cruza a fronteira da aplicao. Assim, no devemos contar os campos que no cruzam a fronteira da aplicao. 126

A Gesto de Critrios um caso de uso simples, que referencia os ALIs Projeto e Critrio, alm de usar 4 campos. O caso de uso Reviso possui 5 funes de transao: pesquisa, visualizao, incluso, alterao e reabertura. A pesquisa referencia 2 ALIs: Reviso e Projeto. As funes de visualizao, incluso e alterao referenciam Projeto, Reviso, Critrio, Requisitos, Caso de uso e Membro. A funo Reabertura apenas altera um campo de Reviso, que indica de ela foi fechada ou no. A Gerao da Especificao possui duas funes de transao: pesquisa e gerao. A pesquisa referencia 2 ALIs: Projeto e Membro. A gerao de especificao uma CE que referencia todos os ALIs, com exceo de Reviso e Critrio. So 5 ALIs. Todos os campos desses ALIs so referenciados na funo. O Relatrio de acompanhamento possui duas funes: uma CE relacionada pesquisa e uma SE relacionada gerao do relatrio de acompanhamento. A pesquisa referencia 2 ALIs: Projeto e Membro. A SE referencia os ALIs Projeto, Membro, Requisito e Caso de uso. Existem campos adicionais para informar o percentual de concluso do requisito, do caso de uso e do projeto como um todo. Esses so campos adicionais do relatrio e que precisam ser contabilizados. Por isso a contagem referencia 14 campos: so 11 campos normais e 3 calculados. A Tabela 13 exibe um resumo da contagem realizada, detalhando as funes identificadas, nmero de TARs e TEDs envolvidos, complexidade identificada e valor da funo em Pontos de Funo. importante frisar que devemos ter um cuidado especial com o nmero de ALIs referenciados nas funes. Se existir pelo menos um campo de um ALI envolvido na funo, ento esse ALI referenciado. Alm disso, temos que contar o nmero de campos associados funo. Conforme comentamos, utilizamos uma contagem simplificada: contamos apenas os campos visveis. No 127

trataremos aqui de outros detalhes, como previso de comandos, mensagens, relacionamentos entre elementos, etc. Isso simplifica o processo de entendimento da APF. No entanto, frisamos que existem muitos detalhes a serem considerados em uma contagem detalhada.

128

Tabela 13: Resumo da contagem de funes de transao.

129

5.4

Planejamento e Gesto de Projetos com PF

Pontos de Funo podem ser utilizados para auxiliar a

estimativa de esforo necessrio ao desenvolvimento ou evoluo de um produto. Isso pode ser feito a partir do clculo de produtividade associada a um projeto e sua equipe.
O uso de APF permite o acompanhamento da produtividade, bem como seu uso para a realizao de estimativas de custo e esforo.

A produtividade uma medida que indica a capacidade de produo. No caso de software, ela indica a capacidade de produzir software por unidade de tempo. Uma funo para produtividade, baseada em pontos de funo : Produtividade = PF / PM (ponto de funo por pessoa-ms). Mas como calcular isso? Basta contar quantos pontos de funo foram desenvolvidos por uma equipe em um ms de trabalho. Se descobrirmos isso, podemos usar para fazer estimativas. De posse da produtividade de uma pessoa ou de uma equipe, fcil obter uma estimativa de tempo para realizao do desenvolvimento de um sistema. Por exemplo, se uma equipe tem mdia de 200 PF/ms, um software de 600 PF poderia ser construdo em 3 meses. No entanto, existem diversos fatores que podem influenciar os dados de produtividade. As diferenas entre linguagens utilizadas, tecnologias e capacitao da equipe podem influenciar muito os dados de produtividade. Imagine por exemplo programadores COBOL e programadores que utilizem Delphi. Certamente a produtividade de programadores Delphi deve ser bem superior a de programadores COBOL, uma vez que Delphi possui elementos que favorecem a produtividade em relao ao COBOL. Na verdade, uma mesma equipe pode ter produtividade bastante diferente de um projeto para outro. As pessoas podem perder produtividade quando esto com problemas pessoais.

130

Um outro dado interessante que o tamanho dos projetos tambm pode influenciar na produtividade. Projetos muito grandes tendem a ter produtividade menor que projetos pequenos. A explicao para isso simples: quando um projeto muito grande, coisas simples podem crescer em dimenso, de formar a gerar um problema. Um exemplo a comunicao: grandes equipes tem muitos problemas para uma reunio, por exemplo. Pequenas equipes resolvem isso facilmente. Outros fatores que podem influenciar no clculo de

produtividade so as coletas de medidas no padronizadas ou no confiveis. Se isso ocorrer, as estimativas podem ser muito imprecisas. Outro ponto importante que as medidas sejam feitas utilizando produtos que tenham sua qualidade controlada. Uma empresa pode gerar um sistema rapidamente e com isso ter uma produtividade alta. Porm, se a qualidade dele no medida, podem ser descobertos tantos erros que no justifiquem considerar o produto concludo. Assim, fundamental o controle da qualidade para que tenhamos uma medida de produtividade efetiva. Normalmente a obteno de dados de produtividade segue alguns passos. Inicialmente, preciso identificar projetos similares, uma vez que a produtividade pode ser dependente do que se faz. Outro ponto importante caracterizar o tamanho, linguagem, aplicao, experincia da equipe e principalmente o processo usado para guiar o trabalho. Com isso feito, pode-se obter a produtividade para cada projeto. Assim, pontos de funo uma boa mtrica para ajudar no clculo de produtividade. No entanto, necessrio ter cuidado com as medies, para no gerarmos dados inconfiveis.

5.5

Viso crtica da APF

131

A APF possui muitas vantagens e desvantagens associadas. importante conhecer cada um desses pontos para que tenhamos subsdios suficientes para decidir ou no pelo seu uso. As vantagens do PF so: A especificao de requisitos suficiente para o clculo. Essa caracterstica muito interessante para o uso do APF em projetos. Com a ER de um produto, podemos estimar seu tamanho e assim estimar custo e esforo para seu desenvolvimento. Mtodo de grande difuso. APF utilizado no mundo inteiro. Alm disso, mesmo estando defasado em alguns pontos, ainda possui muitos usurios. Alm disso, em projetos de terceirizao no Brasil ele indicado como mtrica para clculo da produo e definio de pagamentos. Muitos dados publicados. Existem muitos dados de empresas relativos ao uso de APF. Esses dados podem at ser adquiridos por outras empresas. So bases histricas de projetos com diversas informaes disponveis, que podem ser utilizadas por outras organizaes para ajudar em suas estimativas. Podem ser usados para comparaes. Com o uso do APF podemos comparar a efetividade de tecnologias diferentes (Java x Delphi), alm de permitir a comparao de empresas (A x B), analisando quem produz mais em menos tempo. Grupo internacional de usurios (IFPUG). O grupo de usurios de APF grande, existente em boa parte do mundo e bastante atuante. Questes enviadas ao grupo so respondidas em pouco tempo. Frum para troca de informao. Existem muitos fruns para eliminao de dvidas associados, com respostas efetivas e em tempos reduzidos. 132

No entanto, mesmo tendo essas vantagens, existem diversas desvantagens associadas. No tm nenhuma interpretao concreta. No faz parte do nosso dia a dia o uso de APF. Assim, dizer que algo tem 200PF ou 600PF no representa uma informao associada. No a mesma coisa de dizer que uma casa tem 1.000m2. No entanto, apenas difundindo ainda mais o seu uso que essa medida pode ter uma interpretao concreta. Contagem no pode ser facilmente automatizada. Existem muita interpretao associada contagem de PF. Isso dificulta sua automao por completo, visto que essas Existem variaes interpretaes variantes do do so difceis de serem algumas automatizadas por completa. mtodo. que Existem mtodo utilizam caractersticas

diferentes de contagem. Isso pode gerar diferenas em trabalhos e contradies. Existem valores diferentes para os pesos usados, alm de regras diferentes de contagem. So orientados para sistemas de informao. APF foi criada para contagem de sistemas de informao, sendo apropriadas para esses casos. No entanto, seu uso para contagem de tamanho de jogos, aplicaes para celulares, adequadas. recuperao da informao, no so Assim, qualquer aplicao em contextos

diferentes requerem adaptaes para os produtos a serem contados. A contagem rigorosa difcil. Existem muitas regras associadas. Por conta disso fizemos uma contagem bastante simplificada. As regras so muito extensas e difceis de serem seguidas em detalhes.

133

Requer

profissional

especializado.

Uma

contagem

detalhada exige um profissionais bastante especializado, que caro e difcil de ser encontrado no mercado de trabalho. A APF ainda possui algumas limitaes que devem ser consideradas em qualquer projeto de contagem: No leva em conta a reutilizao. A APF no possui um mecanismo de contabilizar o reuso de partes de um projeto, visto que isso pode reduzir o esforo necessrio
A APF possui vrias vantagens e desvantagens associadas. No entanto, ela ainda uma forma muito utilizada no mundo.

para sua construo. No previsto o reuso de componentes, de cdigo legado, de cdigo herdado de verses anteriores. difcil seu uso para contagem de alteraes de requisitos. APF inadequada para contar a complexidade de aes de manuteno corretiva, pois difcil expressar as diferenas de uma verso para outra. De modo geral, APF possui vantagens e desvantagens, mas mesmo assim um mtodo bastante utilizado. De qualquer forma, independente de utilizar APF ou outro mtodo, importante termos medidas para controlar nosso trabalho. Como foi dito pelo famoso escritor Tom DeMarco: No se consegue controlar o que no se consegue medir.

5.6

Exerccios
1. O que a mensurao em software? 2. O que pode ser medido em um software? 3. O que a produtividade? 4. Quais so as caractersticas de uma boa medida de tamanho?

134

5. Por que linhas de cdigo no utilizada como medida para controlar estimativas de desenvolvimento? 6. O que APF? 7. Quando surgiu a APF? 8. Quais foram os dois objetivos principais da APF? 9. Quais so os cinco elementos considerados em uma contagem? Explique cada um deles. 10. Quais so os passos includos no procedimento de contagem de PF? 11. Quais so os 3 tipos de contagem existente? Explique cada uma. 12. O que o escopo da contagem em PF? 13. Quais so as duas categorias de funes a ser consideradas em um clculo de PF? 14. O que um ALI? E um AIE? Qual a diferena entre eles? 15. Quais so os 3 tipos de funes de transao? 16. O que pode influenciar a contagem de um ALI? Explique esses elementos. 17. Quais campos devem ser considerados em uma tela para a contagem do tamanho de uma EE? 18. D exemplos de SE e CE ressaltando a diferena entre os dois. 19. O que pode ser usado como insulo para a contagem das funes de dados em um projeto? O que pode ser usado para contar as funes de transao? 20. Realize uma contagem de funes de dados de um projeto diferente do exemplo da apostila, explicando as decises existentes e detalhando os nmeros associados, de forma similar ao exemplo detalhado. 21. De forma similar a questo anterior, realize uma contagem de funes de transao de um projeto diferente do exemplo da apostila, explicando as decises existentes e detalhando os nmeros associados, de forma similar ao exemplo detalhado. 135

22. Como podemos utilizar APF para estimar um projeto? 23. Cite vantagens e desvantagens do uso de APF.

136

UNIDADE II O FLUXO DE ANLISE WEBLIOGRAFIA

Pgina da Universidade Aberta do Piau - UAPI http://www.ufpi.br/uapi Pgina da Universidade Aberta do Brasil- UAB http://www.uab.gov.br Stio de apoio ao livro de Wilson de Pdua http://homepages.dcc.ufmg.br/~wilson/ Stio oficial da UML http://www.uml.org/ International Function Points User Group http://www.ifpug.org/ Brazilian Function Points User Group http://www.bfpug.com.br/

137

UNIDADE II O FLUXO DE ANLISE

REFERNCIAS BIBLIOGRFICAS
BERTRAND MEYER, Object-oriented Software Construction,

Prentice-Hall, 2a edio, 1997. DAVID GARMUS, DAVID HERRON, Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley, 2000. KENDALL SCOTT, Processo Unificado Explicado, Editora

Bookman, 2003. J. RUMBAUGH, I. JACOBSON, G. BOOCH. The Unified Modeling Language Reference Manual, Addison Wesley, 1999. WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

138

UNIDADE III EXEMPLOS DE ARTEFATOS

RESUMO Nesta unidade apresentamos exemplos completos dos artefatos utilizados para o levantamento de requisitos, registro de uma reunio e para reviso de uma ER ou de um modelo de anlise. Eles so exemplos completos para o sistema exemplo abordado no trabalho.

139

SUMRIO DA UNIDADE

UNIDADE III............................................................................................. 139 EXEMPLOS DE ARTEFATOS ................................................................ 139 ANEXO I Exemplo de Especificao de Requisitos .............................. 141 ANEXO II Exemplo de Agenda de Oficina de Levantamento de Requisitos ................................................................................................... 178 ANEXO III Exemplo de Ata de Oficina de Levantamento de Requisitos .................................................................................................................... 180 Anexo IV - Reviso da Especificao de Requisitos ................................. 181 Anexo V - Reviso do Modelo de Anlise................................................. 185

140

ANEXO I Exemplo de Especificao de Requisitos

Fictcia Solues em Informtica

Especificao dos Requisitos do Software ReqG 1.0

Autores: Equipe Fictcia

Teresina - PI

Dezembro de 2010

141

Aprovao
Aprovamos o documento de Especificao de Requisitos do projeto ReqG 1.0. Responsvel Gildsio Guedes Fernandes Instituio UAPI Data 08/12/2010 08/12/2010 08/12/2010 Assinatura

Lus Cludio Demes da Mata UAPI Souza Pedro de Alcntara dos S. Neto FICTCIA

142

Verses revisadas anteriores

Responsvel Pedro de Alcntara dos S. Neto

Verso 1.0

Data 07/12/2010

Descrio Finalizao da verso inicial.

143

Especificao dos Requisitos do Software Gerenciador de Requisitos 1.0

Sumrio
Introduo Nome do produto Escopo do produto Limites do produto Definies e siglas Definio dos Requisitos Requisitos Funcionais Requisitos No-Funcionais Detalhamento dos Requisitos Diagrama de contexto Casos de uso Atores Especificao dos Casos De Uso Cadastro de Projeto Gesto de Gerentes Gesto de Membros Controle de Projetos Gesto de Requisitos Gesto de Atores Gesto de Casos de Uso Gesto de Critrios Reviso Gerao da Especificao Relatrio de Acompanhamento

145 145 145 145 145 146 146 146 148 148 148 149 151 151 153 155 157 158 161 164 168 170 175 175

144

Introduo
Nome do produto
ReqG: Sistema Gerenciador de Requisitos de Software.

Escopo do produto
Gerenciar os requisitos de um projeto de software, via Web, registrando todos os dados associados sua definio, de forma a cobrir todas as atividades previstas em um fluxo de requisitos.

Limites do produto
1. O ReqG no controlar a execuo de tarefas no projeto, apenas registrar os dados relacionados aos requisitos. 2. O ReqG no gerar documentos editveis com a especificao de requisitos. Os dados ficam registrados no sistema e s podem ser alterados por ele. 3. O ReqG no controlar qualquer aspecto do custo ou do cronograma de execuo. 4. O backup e a recuperao das bases de dados do sistema ficam a cargo da administrao de dados e no sero providas pelo ReqG. 5. O ReqG no ter ajuda on-line.

Definies e siglas
Nr. 1 2 3 JSF Hibernate MySQL Sigla Definio Java Server Faces. Tecnologia para construo da camada de apresentao de um sistema Web. Framework para persistncia de dados em Java. Banco de dados livre bastante popular no mundo.

145

Definio dos Requisitos

Requisitos Funcionais
ID RF1 Requisitos Requisito Descrio O sistema deve permitir cadastrar e controlar todos os aspectos relacionados aos requisitos de um projeto, permitindo visualizar isso e acompanhar sua evoluo, incluindo as pessoas que trabalharam no projeto, os analistas e gerente do projeto. O sistema deve possibilitar a especificao dos casos de uso, registrando sua descrio, atores, prottipos de tela associados, relacionando aos requisitos que deram origem ao caso de uso. Deve ser possvel realizar uma reviso dos requisitos e casos de uso, utilizando critrios definidos pelos prprios gerentes de projetos, de forma independente dos demais projetos. Deve ser possvel que os clientes possam acompanhar a evoluo do projeto a qualquer momento, consultando tudo o que foi feito. Deve ser possvel liberar o acesso ao sistema por projeto, indicando o seu gerente. Assim, para se ter acesso ao sistema, dever ser adquirida uma licena para um projeto. A partir disso o gerente ficar responsvel por definir quem dever usar o sistema, seja para trabalhar na especificao de requisitos, como um dos Engenheiros de Requisitos, seja como cliente consultando o resultado do trabalho realizado. Deve ser possvel gerar a especificao na forma de um documento, contendo todos os dados registrados do projeto.

5.7

RF2

Casos de uso

RF3

Reviso

RF4

Acompanhamento dos clientes

RF5

Liberao de acesso por projeto

RF6

Gerao da documentao

Requisitos No-Funcionais
ID Requisito Descrio 146

RNF1 Ambiente

O sistema deve funcionar em ambiente Web, sendo compatvel com os principais navegadores do momento: Internet Explorer, Firefox, Safari e Chroma. O sistema deve ser desenvolvido utilizando-se a linguagem Java, com as tecnologias JSF e Hibernate. O sistema deve utilizar o banco de dados MySQL. O sistema deve ser construdo para funcionar com 100 usurios simultneos, com respostas de at 5s quando utilizado em rede local. O sistema deve restringir o acesso por meio de senhas. Deve-se ter um controle no registro de senha, de forma a impedir o uso de senhas consideradas fceis. Um usurio com conhecimento bsico em informtica e conhecimento nos conceitos de requisitos deveria ser capaz de operar o sistema com um curso de 30 minutos.

RNF2 Linguagem

RNF3 Banco de dados RNF4 Desempenho

RNF5 Segurana

RNF6 Usabilidade

147

Detalhamento dos Requisitos

Diagrama de contexto

Casos de uso
ID UC1 Caso de uso Gesto de Requisitos Requisito associado RF1 Descrio Cadastro de requisitos funcionais e no 148

funcionais associados ao projeto. UC2 UC3 UC4 UC5 Gesto de Membros Gesto de Casos de Uso Gesto de Atores Reviso RF1 RF2 RF2 RF3 Cadastro de todos os envolvidos no projeto. Definio dos casos de uso do projeto. Definio dos atores que iro interagir no projeto. Reviso de um requisito ou de um caso de uso, observando os critrios prestabelecidos no projeto para a reviso. Cadastro de critrios a serem utilizados em uma reviso. Cadastro de um projeto, com definio do seu gerente, feito pelo administrador do sistema. Cadastro de um gerente de projeto, feito pelo administrador do sistema. Controle do projeto, com detalhamento de informaes sobre o mesmo, feito pelo gerente do projeto. Gerao da especificao de requisitos, utilizando um formato pr-definido, contendo todos os dados registrados no projeto. Emisso de um relatrio contendo uma indicao do estado do projeto, a partir do estado de cada caso de uso que o compe.

UC6 UC7

Gesto de Critrios de Reviso Cadastro de Projeto

RF3 RF5

UC8 UC9

Gesto de Gerentes Controle de Projetos

RF5 RF5

UC10 Gerao da especificao

RF6, RF4

UC11 Relatrio de Acompanhamento

RF4, RF6

Atores
N 5. 6. 7. Cliente Administrador Gerente Ator Descrio Clientes de um projeto, normalmente responsvel pelo fornecimento de informaes para moldagem do produto. Responsvel pelo controle do uso do sistema, liberando acesso aos Gerentes a partir do cadastramento de um projeto. Responsvel pelo controle de um projeto, definindo a equipe e suas tarefas. 149

8. 9.

Membro Engenheiro Requisito

Pessoa que faz parte da equipe que trabalha no projeto. de Tcnico com formao em Engenharia de Software, capaz de identificar e descrever requisitos, utilizando as prescries de Engenharia de Requisitos existentes e implementadas no sistema.

150

Especificao dos Casos De Uso

Cadastro de Projeto

Prottipo de Tela de Cadastro de Projetos

Cadastro de Projetos Pesquisa por Projetos Nome SystemG (texto com at 30 caracteres) Gerente Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres) <Pesquisar> Projetos recuperados Sigla Gerente SystemG Silio Silvestre Ferreira Freitas Frigo Alberto Sobrinho Arajo TecnoComp Silio Silvestre Ferreira Freitas <Novo> <Alterar> <Visualizar> <Excluir> Dados do Projeto Sigla* ReqG 1.0 (texto com at 30 caracteres) Descrio Sistema de Gerenciamento de Requisitos do Projeto (texto com at 255 caracteres) Gerente* [Lista de Gerentes de Projeto cadastrados no sistema] <Salvar>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal 1. O ReqG exibe a Tela de Cadastro de Projetos. 2. O Administrador informa os dados para pesquisa por projetos. 3. O Administrador aciona o comando Pesquisar. 4. O ReqG recupera e exibe na lista Projetos Recuperados os projetos que atendem aos parmetros de pesquisa informados, ordenados pela Sigla em ordem crescente. Fluxo alternativo Incluso de novo projeto O Administrador acionou o comando Novo. Precondies 1. Passos 1. O Administrador preenche os Dados do Projeto. 2. 3. 4. 5. O Administrador aciona o comando Salvar. O ReqG verifica que no existe um projeto com sigla informada. O ReqG salva os dados do projeto. O ReqG envia um email ao gerente do projeto informando o cadastramento do projeto. 151

Fluxo alternativo Alterao de um Projeto Precondies 1. O Administrador selecionou um Projeto na lista de Projetos Recuperados. 2. O Administrador acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Projeto. 2. O Administrador altera os Dados do Projeto que desejar. 3. O Administrador aciona o comando Salvar. 4. O ReqG salva os dados do projeto. 5. O ReqG verifica que no existe um projeto com sigla informada. 6. O ReqG salva os dados do projeto. 7. O ReqG envia um email ao gerente do projeto informando a alterao no
projeto.

Fluxo alternativo Visualizao de Dados de um Projeto Precondies 1. O Administrador selecionou um projeto na lista de Projetos Recuperados. 2. O Administrador acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Projeto somente para leitura.

Fluxo alternativo Excluso de um Projeto Precondies 1. O Administrador selecionou um projeto na lista de Projetos Recuperados. 2. O Administrador acionou o comando Excluir. Passos 1. O ReqG verifica que no h dados associado ao projeto selecionado, como requisitos, casos de uso, membros e revises. 2. O ReqG exclui o projeto selecionado. 3. O ReqG envia um email ao gerente do projeto informando a excluso do
projeto.

152

Gesto de Gerentes

Prottipo de Tela de Gesto de Gerentes

Gesto de Gerentes Nome Projeto Pesquisa por Gerentes Silio Silvestre Ferreira Freitas (texto com at 100 caracteres) Ferrare 1.0 (texto com at 30 caracteres) <Pesquisar> Gerentes recuperados Nome Login Email
Silio jj siliosffreitas@gmail.com jjacavalcante@hotmail.com

Projeto

Silio Silvestre Ferreira Freitas Joo Jos Almeida Cavalcante

Ferrare 1.0, ReqG 1.0 Genesis 2.0

Nome* Email* Telefone Login* Senha*

<Novo> <Alterar> <Visualizar> <Excluir> Dados do Gerente Silio Silvestre Ferreira Freitas (texto com at 100 caracteres) siliosffreitas@gmail.com (email vlido) (86) 3224-3678 (texto at 100 caracteres) siliosffreitas (texto at 20 caracteres) 12345678 (texto at 20 caracteres) <Salvar>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal 5. O ReqG exibe a Tela de Gesto de Gerentes. 6. O Administrador informa os dados para pesquisa por Gerentes. 7. O Administrador aciona o comando Pesquisar. 8. O ReqG recupera e exibe na lista Gerentes recuperados os Gerentes que atendem aos parmetros de pesquisa informados, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de um Novo Gerente Precondies 2. O Administrador acionou o comando Novo. Passos 6. O Administrador preenche os Dados do Gerente. 7. O Administrador aciona o comando Salvar. 8. O ReqG verifica que no existe um Gerente com email e login informados. 9. O ReqG salva os Dados do Gerente. Fluxo alternativo Alterao de um Gerente 153

Precondies 1. O Administrador selecionou um Gerente na lista de Gerentes recuperados. 2. O Administrador acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Gerente. 2. O Administrador altera os Dados do Gerente que desejar. 3. O Administrador aciona o comando Salvar. 4. O ReqG verifica que no existe um Gerente com email e login informados. 5. O ReqG salva os Dados do Gerente. Fluxo alternativo Visualizao de Dados de um Gerente Precondies 1. O Administrador selecionou um Gerente na lista de Gerentes recuperados. 2. O Administrador acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Gerente somente para leitura.

a. Fluxo alternativo Excluso de um Gerente Precondies 1. O Administrador selecionou um Gerente na lista de Gerentes recuperados. 2. O Administrador acionou o comando Excluir. Passos 1. O ReqG verifica que no h nenhum projeto que tenha o Gerente selecionado como Gerente do projeto. 2. O ReqG exclui o Gerente selecionado.

154

Gesto de Membros

Prottipo de Tela de Gesto de Membros

Gesto de Membros Pesquisa por Membros Nome Pedro da Silva Castro (texto com at 50 caracteres) Cargo [Analista, Programador, Designer, Arquiteto de Software, Fornecedor de Requisitos] <Pesquisar> Membros do Projeto Nome Projeto Telefone Papel Email
Pedro Lucas Adriana Pedro@email.com lucassld@gmail.com Adriana12@hotmail.com Ferrare 1.0 Quantum 2.0 XMen 1.1 (12) 1212-1212 (23) 3443-3433 (34) 4554-5445 Analista Design Programador

Nome* Email* Telefone * Papel* Login* Senha* Projeto*

<Novo> <Alterar> <Visualizar> <Excluir> Dados do Membro Thiago Alves (texto com at 100 caracteres) tt@gmail.com (email vlido) (086) 9999-9999 (telefone vlido) [Cliente; Engenheiro de Requisitos] Thiago (texto com at 20 caracteres) Senha (texto com at 20 caracteres) [Lista de projetos pr-cadastrados no sistema e associados ao usurio corrente] ... [Lista de projetos pr-cadastrados no sistema e associados ao usurio corrente] <Salvar>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal 1. O ReqG exibe a Tela de Gesto de Membros. 2. O Gerente informa os dados para pesquisa por Membros. 3. O Gerente aciona o comando Pesquisar. 4. O ReqG recupera e exibe na lista Membros Recuperados os Membros que atendem aos parmetros de pesquisa informados, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de um Novo Membro Precondies 1. O Gerente acionou o comando Novo. Passos 1. O Gerente preenche os Dados do Membro. 155

2. O Gerente aciona o comando Salvar. 3. O ReqG verifica que no existe um membro cadastrado com login e email informados. 4. O ReqG salva os dados do Membro. 5. O ReqG envia um email ao Membro informando sobre sua incluso nos projetos selecionados, detalhando seu cargo em cada projeto. Fluxo alternativo Alterao de um Membro Precondies 1. O Gerente selecionou um Membro na lista de Membros Recuperados. 2. O Gerente acionou o comando Alterar. Passos 1. 2. 3. 4. 5. 6. O ReqG recupera e exibe Dados do Membro. O Gerente altera os Dados do Membro que desejar. O Gerente aciona o comando Salvar. O ReqG verifica que no existe um membro com login e email informados. O ReqG salva os dados do Membro. O ReqG envia um email para o membro informando as alteraes.

Fluxo alternativo Visualizao de Dados de um Membro Precondies 1. O Gerente selecionou um Membro na lista de Membros Recuperados. 2. O Gerente acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Membro somente para leitura.

Fluxo alternativo Excluso de um Membro Precondies 1. O Gerente selecionou um Membro na lista de Membros Recuperados. 2. O Gerente acionou o comando Excluir. Passos 1. O ReqG verifica se que o Membro no trabalhou no projeto, fornecendo informaes a respeito do levantamento de requisitos tais como registrando requisitos, detalhando casos de uso, prottipos, realizando revises, etc.. 2. O ReqG exclui o Membro selecionado.

156

Controle de Projetos

Prottipo de Tela de Controle de Projetos

Controle do Projeto Pesquisa por projetos Projeto Estocando (texto com at 30 caracteres) <Pesquisar> Projetos recuperados Sigla Gerente SystemG Silio Silvestre Ferreira Freitas Frigo Alberto Sobrinho Arajo TecnoComp Silio Silvestre Ferreira Freitas <Alterar> <Visualizar> Dados do Projeto Projeto SystemG Gerente Silio Silvestre Ferreira Freitas Escopo* Sistema de apoio e controle de requisitos (texto com at 2000 caracteres) Diagrama de Contexto SystemG_DiagramaContexto.jpg (Imagem) Limites do produto O sistema no ter monitoramento online (rea de texto com at 2000 caracteres) Instituio responsvel Ficttica Solues em Informtica (texto com at 100 caracteres) pela execuo Instituio cliente Biriba Comrcio (texto com at 100 caracteres) Data de incio* 12/05/2009 (data passada ou atual vlida no formato dd/mm/aaaa) Data de Trmino 12/05/2011 (data futura vlida no formato dd/mm/aaaa) Membros do Projeto Nome Projeto Celular Cargo Email
Pedro Lucas Adriana Pedro@email.com lucassld@gmail.com Adriana12@hotmail.com Ferrare 1.0 Quantum 2.0 XMen 1.1 (12) 1212-1212 (23) 3443-3433 (34) 4554-5445 Analista Design Programador

<Salvar>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal O ReqG exibe a Tela de Controle do Projeto. O Gerente informa os dados para pesquisa por Projetos. O Gerente aciona o comando Pesquisar.

157

O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de pesquisa informados e que tenham como Gerente o usurio corrente, ordenados pelo Nome em ordem crescente. O Gerente seleciona o projeto a controlar e aciona o comando Alterar. O Gerente altera os dados de controle do projeto. O Gerente aciona o comando Salvar. O ReqG salva os dados do projeto. O ReqG envia um email a todos os membros do projeto relatando as alteraes realizadas.

Gesto de Requisitos

Prottipo de Tela de Gesto de Requisitos

Gesto de Requisitos Pesquisa por requisitos Estocando (texto com at 30 caracteres) Linguagem (texto com at 30 caracteres) <Pesquisar>

Projeto Requisito

158

Requisitos recuperados Nome Descrio Linguagem Java Desenvolvido em Java Gesto de Projetos Gesto de Projetos Reviso Prioridade Alta Mdia Projeto Ferrare 1.0 Quantum 2.0 XMen 1.0

Reviso dos Requisitos Baixa <Novo> <Alterar> <Visualizar> <Excluir>

Identificador* Nome* Descrio* Tipo* Prioridade* Complexidade* Situao*

Dados do Requisito RF1 (formato RFn para funcionais ou RNFn para no funcionais, onde n o prximo nmero natural no associado a um requisito) Linguagem Java (texto at 100 caracteres) O Sistema deve ser desenvolvido em Java para a Web (texto at 2000 caracteres) [Funcional; No Funcional] [Alta; Mdia; Baixa] [Alta; Mdia; Baixa] [Identificado; Detalhado; Implementado; Homologado] <Salvar> Histrico de Alterao Responsvel Joaquim Parente Astulfo Alves Silio Silvestre Papel Analista Analista Gerente Email joa@gmail.com astoa@gmail.com silio@gmail.com

Data 10/05/2010 15/05/2010 10/07/2010

Detalhamento do Caso de Uso

Precondies O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente do Projeto. Fluxo principal O ReqG exibe a Tela de Gesto de Requisitos. O Engenheiro de Requisitos informa os dados para pesquisa por Requisitos. O Engenheiro de Requisitos aciona o comando Pesquisar. O ReqG recupera e exibe na lista Requisitos Recuperados os requisitos que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de Novo Requisito

159

Precondies 1. O Engenheiro de Requisitos acionou o comando Novo. Passos 1. O Engenheiro de Requisitos preenche os Dados do Requisito. 2. O Engenheiro de Requisitos aciona o comando Salvar. 3. O ReqG gera o identificador do requisito sendo RF + n para requisitos funcionais ou RNF + n para requisitos no funcionais, onde n o prximo numero natural no associado a um requisito. 4. O ReqG verifica que no h requisito para o projeto com o nome e tipo informado. 5. O ReqG verifica que a situao do requisito Identificado. 6. O ReqG salva os dados do Requisito. 7. O ReqG registra no histrico de alterao do requisito a data atual, o usurio corrente como responsvel pela incluso. Fluxo alternativo de Alterao do Requisito Precondies 1. O Engenheiro de Requisitos selecionou um Requisito na lista de Requisitos recuperados. 2. O Engenheiro de Requisitos acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Requisito. 2. O Engenheiro de Requisitos altera os Dados do Requisito que desejar. 3. O Engenheiro de Requisitos aciona o comando Salvar. 4. O ReqG verifica que todos os casos de uso relacionados ao requisito esto na mesma situao do requisito. 5. O ReqG salva os dados do Requisito. 6. O ReqG registra no histrico de alterao do requisito a data atual e o usurio corrente como responsvel pela alterao. Fluxo alternativo Visualizao de Dados de Requisito Precondies 1. O Engenheiro de Requisitos selecionou um Requisito na lista de Requisitos recuperadas. 2. O Engenheiro de Requisitos acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Requisito somente para leitura.

Fluxo alternativo Excluso de Requisito

160

Precondies 1. O Engenheiro de Requisitos selecionou um Requisito na lista de Requisitos recuperados. 2. O Engenheiro de Requisitos acionou o comando Excluir. Passos 1. O ReqG verifica que no existe nenhum caso de uso ou reviso associado ao Requisito. 2. O ReqG exclui o requisito selecionado.

Gesto de Atores

Prottipo de Tela de Gesto de Atores

Gesto de Atores Pesquisa por Ator Estocando (texto com at 30 caracteres) Gerente (texto com at 30 caracteres) <Pesquisar> Atores recuperados

Projeto Ator

Nome Caixeiro

Descrio Caso de Uso Projeto Usurio que abre e fecha UC6,UC8 Estocando compra Fiscal de Fiscaliza entrada e sada UC1 Estocando ponto de Reviso Reviso dos Requisitos UC2 Ferrare 1.0 <Novo> <Alterar> <Visualizar> <Excluir> Dados do Ator Nome* Caixeiro (texto at 50 caracteres, nico) Descrio* Responsvel pela venda de mercadorias (texto at 100 caracteres) Caso de uso associado [Lista de caso de uso cadastrado no projeto] ... [Lista de caso de uso cadastrado no projeto] <Salvar> Histrico de Alterao Data 10/05/2010 15/05/2010 10/07/2010 Responsvel Joaquim Parente Astulfo Alves Silio Silvestre Papel Analista Analista Gerente Email joa@gmail.com astoa@gmail.com silio@gmail.com

Detalhamento do Caso de Uso

Precondies O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente do Projeto. 161

Fluxo principal O ReqG exibe a Tela de Gesto de Atores. O Engenheiro de Requisitos informa os dados para pesquisa por Atores. O Engenheiro de Requisitos aciona o comando Pesquisar. O ReqG recupera e exibe na lista Atores Recuperados os atores que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de Novo Ator Precondies 1. O Engenheiro de Requisitos acionou o comando Novo. Passos 1. O Engenheiro de Requisitos preenche os Dados do Ator. 2. O Engenheiro de Requisitos aciona o comando Salvar. 3. O ReqG verifica que no existe um ator com mesmo nome para o projeto. 4. O ReqG salva os dados do Ator. 5. O ReqG registra no histrico de alterao do ator a data atual, o usurio corrente como responsvel pela incluso.

Fluxo alternativo de Alterao do Ator Precondies 1. O Engenheiro de Requisitos selecionou um Ator na lista de Atores recuperados. 2. O Engenheiro de Requisitos acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Ator. 2. O Engenheiro de Requisitos altera os Dados do Ator que desejar. 3. O Engenheiro de Requisitos aciona o comando Salvar. 4. O ReqG verifica que no existe um ator com mesmo nome para o projeto. 5. O ReqG salva os dados do Ator. 6. O ReqG registra no histrico de alterao do ator a data atual, o usurio corrente como responsvel pela alterao. Fluxo alternativo Visualizao de Dados de Ator Precondies 1. O Engenheiro de Requisitos selecionou um Ator na lista de Atores recuperados. 2. O Engenheiro de Requisitos acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Ator somente para leitura.

Fluxo alternativo Excluso de Ator

162

Precondies 1. O Engenheiro de Requisitos selecionou um Ator na lista de Atores recuperados. 2. O Engenheiro de Requisitos acionou o comando Excluir. Passos 1. O ReqG verifica que o ator no est associado a nenhum caso de uso. 2. O ReqG exclui o ator selecionado.

163

Gesto de Casos de Uso

Prottipo de Tela de Gesto de Casos de Uso

Projeto Caso de uso Gesto de Casos de Uso Pesquisa por Casos de Uso Estocando (texto at 30 caracteres) Criao de Projetos (texto at 30 caracteres) <Pesquisar> Casos de Uso recuperados

Nome Descrio Requisitos Projeto Gesto de Projetos Criao de Projetos RF01, RF03 Estocando Gesto de Gerentes Controle de Gerentes por um projeto. RF01 Estocando Gesto de Membros Controle de membros de uma equipe RF02 Ferrare 1.0 <Novo> <Alterar> <Visualizar> <Excluir> Dados do Caso de Uso Identificador* UC1 (formato UCn, onde n o prximo nmero natural no associado a um caso de uso) Nome* Cadastrar Projeto (texto at 100 caracteres) Descrio* Cria a conta no sistema para o gerenciamento dos requisitos de um projeto (texto at 2000 caracteres) Ator [Lista de atores pr-cadastrados para o projeto] ... [Lista de atores pr-cadastrados para o projeto] Requisitos [Lista de requisitos pr-cadastrados para o projeto] associados ... [Lista de requisitos pr-cadastrados para o projeto] Prioridade* Complexidade* Situao* [Alta; Mdia; Baixa] [Alta; Mdia; Baixa] [Identificado; Detalhado; Implementado; Homologado] Fluxo Principal Precondio Usurio logado no Sistema como Gerente (Texto com at 500 caracteres) Passos* O ReqG exibe a Tela de Gesto de Casos de Uso. O ReqG recupera e exibe todos os casos de uso cadastrados. (rea de texto com at 2000 caracteres) Fluxos Alternativos Nome Pr-condies Passos Incluso de caso de O usurio acionou o O ReqG faz isso. uso comando novo. O ReqG faz aquilo. ReqG salva tudo. Excluso de caso de O usurio acionou o O ReqG remove tudo. uso comando excluir. Dados do Fluxo Alternativo Nome* Incluso de usurio (texto com at 100 caracteres, nico por projeto) Precondio* Usurio logado no Sistema como Gerente (texto com at 500 caracteres) 164

Passos*

O ReqG exibe a Tela de Gesto de Casos de Uso. O ReqG recupera e exibe todos os casos de uso cadastrados. (rea de texto com at 2000 caracteres) <Adicionar fluxo> <Excluir fluxo> Subfluxos Nome Passos Atualizao de algo O ReqG faz isso. O ReqG faz aquilo. ReqG salva tudo. Atualizao de algo O ReqG faz isso. O ReqG faz aquilo. ReqG salva tudo. Dados do Subfluxo Nome* Incluso de usurio (texto com at 100 caracteres, nico por projeto) Passos* O ReqG exibe a Tela de Gesto de Casos de Uso. O ReqG recupera e exibe todos os casos de uso cadastrados. (rea de texto com at 2000 caracteres) <Adicionar subfluxo> <Excluir Subfluxo> Prottipos de interfaces Nome Arquivo Tela de Incluso de caso de uso Tela.jpg Conexo com sistema de tarefas Dados de Prottipos de interfaces Nome* Tela de incluso de usurio (texto com at 100 caracteres, nico por projeto) Arquivo Tela.jpg (arquivo com imagem) <Adicionar prottipo> <Excluir prottipo> <Salvar> Histrico de Alterao Data Responsvel Papel Email 10/05/2010 15/05/2010 10/07/2010 Joaquim Parente Astulfo Alves Silio Silvestre Analista Analista Gerente joa@gmail.com astoa@gmail.com silio@gmail.com

Detalhamento do Caso de Uso

Precondies O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente do Projeto. Fluxo principal O ReqG exibe a Tela de Gesto de Casos de uso. O Engenheiro de Requisitos informa os dados para pesquisa por Casos de uso. O Engenheiro de Requisitos aciona o comando Pesquisar.

165

O ReqG recupera e exibe na lista Casos de uso Recuperados os casos de uso que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de Novo Caso de Uso Precondies 1. O Engenheiro de Requisitos acionou o comando Novo. Passos 1. O Engenheiro de Requisitos preenche os Dados do Caso de Uso. 2. Se desejar, o Engenheiro de Requisitos inclui fluxos alternativos, subfluxos e prottipos de interfaces. 3. Se desejar, o Engenheiro de Requisitos exclui fluxos alternativos, subfluxos e prottipos de interfaces. 4. O Engenheiro de Requisitos aciona o comando Salvar. 5. O ReqG verifica que no existe um caso de uso com mesmo nome para o projeto. 6. O ReqG salva os dados do caso de uso. 7. O ReqG registra no histrico de alterao do caso de uso a data atual e o usurio corrente como responsvel pela incluso. Fluxo alternativo de Alterao do Caso de Uso Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de Casos de Uso recuperados. 2. O Engenheiro de Requisitos acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Caso de Uso. 2. O Engenheiro de Requisitos altera os Dados do Caso de Uso. 3. Se desejar, o Engenheiro de Requisitos inclui fluxos alternativos e prottipos de interfaces. 4. O Engenheiro de Requisitos aciona o comando Salvar. 5. O ReqG verifica que no existe um caso de uso com mesmo nome para o projeto. 6. O ReqG salva os dados do Caso de Uso. 7. O ReqG registra no histrico de alterao do caso de uso a data atual e o usurio corrente como responsvel pela alterao. Fluxo alternativo Visualizao de Caso de Uso Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de Casos de Uso recuperados. 2. O Engenheiro de Requisitos acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Caso de Uso somente para leitura.

Fluxo alternativo Excluso de Caso de Uso 166

Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de Caso de Uso recuperado. 2. O Engenheiro de Requisitos acionou o comando Excluir. Passos 1. O ReqG solicita confirmao da excluso. 2. O ReqG exclui o caso de uso.

167

Gesto de Critrios

Prottipo de Tela de Critrios

Gesto de Critrios Projeto Critrio Tipo Pesquisa por Critrios Estocando (texto at 30 caracteres) Ambiguidade (texto at 50 caracteres) [Requisito; Caso de uso] <Pesquisar> Critrios recuperados Projeto
Ferrare 1.0 Ferrare 1.0 ReqG 1.0

Nome
Ambiguidade Clareza Completude

Descrio
Apresenta mais de um sentido semntico Apresenta uma interpretao direta e clara O Caso de uso est completo

Tipo
Requisito Requisito Caso de uso

<Novo> <Alterar> <Visualizar> <Excluir> Projeto Nome* Descrio* Tipo* Dados do Critrio [Lista de Projetos cadastrados e que o usurio corrente Membro] Ambigidade (texto at 50 caracteres) Apresenta mais de um sentido (texto at 2000 caracteres) [Requisito; Caso de Uso] <Salvar>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal O ReqG exibe a Tela de Gesto de Critrios. O Gerente informa os dados para pesquisa por Critrios. O Gerente aciona o comando Pesquisar. O ReqG recupera e exibe na lista Critrios Recuperados os critrios que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome em ordem crescente. Fluxo alternativo Incluso de Novo Critrio

168

Precondies 1. O Gerente acionou o comando Novo. Passos 1. O Gerente preenche os Dados do Critrio. 2. O Gerente aciona o comando Salvar. 3. O ReqG verifica que no existe um critrio cadastrado com o nome informado. 4. O ReqG salva os dados do Critrio. Fluxo alternativo de Alterao de Critrio Precondies 1. O Gerente selecionou um Critrio na lista de Critrios recuperados. 2. O Gerente acionou o comando Alterar. Passos 1. O ReqG recupera e exibe Dados do Critrio. 2. O Gerente altera os Dados do Critrio que desejar. 3. O Gerente aciona o comando Salvar. 5. O ReqG verifica que no existe um critrio cadastrado com o nome informado. 4. O ReqG salva os dados do Critrio. Fluxo alternativo Visualizao de Dados de Critrio Precondies 1. O Gerente selecionou um Critrio na lista de Critrios recuperados. 2. O Gerente acionou o comando Visualizar. Passos 1. O ReqG recupera e exibe os Dados do Critrio somente para leitura.

Fluxo alternativo Excluso de Critrio Precondies 1. O Gerente selecionou um Critrio na lista de Critrios recuperados. 2. O Gerente acionou o comando Excluir. Passos 1. O ReqG verifica que no existe nenhuma reviso cadastrada e que utilize o critrio. 2. O ReqG exclui o Critrio selecionado.

169

Reviso

Prottipo de Tela de Reviso

Reviso Pesquisar por Revises Reviso Projeto Reviso preliminar de levantamento (texto com at 30 caracteres ). SystemG (texto com at 30 caracteres ) <Pesquisar> Revises recuperadas Projeto SystemG 1.0 SystemG 1.0 SystemG 2.0 SystemG 2.0 ProjetoX 1.0 Identificador da Reviso Reviso final de detalhamento de requisitos Reviso final de detalhamento de requisitos Reviso inicial de requisitos Dados da Reviso Projeto* Identificador* Descrio* Data* Participantes dos desenvolvedores* Participantes dos clientes Situao* [Lista de Projetos que possuem o usurio corrente como membro] Reviso preliminar de requisitos (texto at 50 caracteres) Reviso preliminar de requisitos (texto at 50 caracteres) 12/12/2010 (data no formato dd/mm/aaaa) [Lista de Membros do Projeto que no sejam clientes] ... [Lista de Membros do Projeto que no sejam clientes] [Lista de Membros do Projeto que sejam clientes] ... [Lista de Membros do Projeto que sejam clientes] [Aberta; Fechada] Requisitos/Casos de uso Avaliados Requisito/Caso de uso Banco de dados Critrio Ambuiguidade Clareza Preciso Atende? Sim No No Observaes No ficou claro o banco a ser utilizado. No foi definido com preciso a verso do banco a ser utilizado. 170 Data 31/11/2009 14/11/2010 12/12/2010 Reviso preliminar de levantamento de requisitos 31/10/2009 Reviso preliminar de levantamento de requisitos 17/10/2010

<Nova Reviso> <Alterar Reviso> <Visualizar Reviso> <Reabrir reviso>

Gesto de membros

Ambuiguidade

Sim

Clareza Preciso Reviso Ambuiguidade Clareza

Sim Sim Sim No

No ficou claro se a reviso apenas de requisitos ou se pode ser de casos de uso tambm. -

Preciso

Sim

<Excluir Avaliao de Requisito/Caso de uso> Avaliao de Critrios para Requisitos Requisito a ser avaliado [Lista de requisitos cadastrados no projeto] Atende? [sim; no] [sim; no] [sim; no] Observaes (texto com at 100 caracteres) (texto com at 100 caracteres) (texto com at 100 caracteres)

Critrio Ambuiguidade Clareza Preciso

<Adicionar Avaliao de Requisito> Avaliao de Critrios para Casos de Uso Caso de uso a ser avaliado [Lista de Casos de uso cadastrados no projeto] Atende? [sim; no] [sim; no] [sim; no] <Salvar> Observaes (texto com at 100 caracteres) (texto com at 100 caracteres) (texto com at 100 caracteres)

Critrio Ambuiguidade Clareza Preciso

<Adicionar Avaliao de Caso de uso>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal O ReqG exibe a Tela de Reviso. O Engenheiro de Requisito informa os dados para pesquisa por Reviso. O Engenheiro de Requisito aciona o comando Pesquisar. O ReqG recupera e exibe na lista Revises Recuperados as revises que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Projeto e Identificador da reviso em ordem crescente. 171

Fluxo alternativo Incluso de Nova Reviso Precondies 1. O Engenheiro de Requisito acionou o comando Nova Reviso. Passos 1. O Gerente preenche os Dados do Reviso 2. Para cada Requisito a ser avaliado: 2.1. O ReqG executa o Subfluxo Avaliao de Requisito. 3. Para cada Caso de uso a ser avaliado: 3.1. O ReqG executa o Subfluxo Avaliao de Caso de uso. 4. Se desejar excluir alguma avaliao de requisito ou caso de uso: 4.1. O ReqG executa o Subfluxo 5. O Engenheiro de Requisitos aciona o comando Salvar. 6. O ReqG verifica que no existe uma reviso cadastrada para o projeto com o mesmo identificador. 7. O ReqG salva os dados da Reviso. Subfluxo Avaliao de Requisito 1. O Engenheiro de Requisitos informa o Requisito a ser avaliado. 2. O ReqG recupera e exibe na lista de Avaliao de Critrios para Requisitos os critrios associados a requisitos cadastrados no projeto. 3. O Engenheiro de Requisitos informa se o critrio foi atendido e, se desejar, preenche algum informao adicional no campo observaes. 4. O Engenheiro de Requisitos aciona o comando Adicionar Avaliao de Requisito.

Subfluxo Avaliao de Caso de uso 1. O Engenheiro de Requisitos informa o Caso de uso a ser avaliado. 2. O ReqG recupera e exibe na lista de Avaliao de Critrios para Casos de uso os critrios associados a casos de uso cadastrados no projeto. 3. O Engenheiro de Requisitos informa se o critrio foi atendido e, se desejar, preenche algum informao adicional no campo observaes. 4. O Engenheiro de Requisitos aciona o comando Adicionar Avaliao de Caso de uso. Subfluxo Excluso de Avaliao 1. O Engenheiro de Requisitos seleciona uma avaliao de Requisito ou Caso de uso na lista de Requisitos/Casos de uso avaliados. 172

2. O Engenheiro de Requisitos aciona o comando Excluir Avaliao de Requisito/Caso de uso. 3. O ReqG remove a avaliao do requisito/caso de uso.

Fluxo alternativo Alterao de Reviso Precondies 1. O Engenheiro de Requisito selecionou uma Reviso da Lista de Revises recuperadas. 2. O Engenheiro de Requisito acionou o comando Alterar Reviso. 3. A Reviso no encontra-se no estado fechada. Passos 1. O ReqG recupera e exibe cada avaliao de requisito e caso de uso associada reviso na lista de Requisitos/Casos de uso avaliados. 2. O Gerente preenche os Dados do Reviso. 3. Para cada Requisito a ser avaliado: 3.1. O ReqG executa o Subfluxo Avaliao de Requisito. 4. Para cada Caso de uso a ser avaliado: 4.1. O ReqG executa o Subfluxo Avaliao de Caso de uso. 5. Se desejar excluir alguma avaliao de requisito ou caso de uso: 5.1. O ReqG executa o Subfluxo 6. O Engenheiro de Requisitos aciona o comando Salvar. 7. O ReqG verifica que no existe uma reviso cadastrada para o projeto com o mesmo identificador. 8. O ReqG salva os dados da Reviso. Fluxo alternativo Visualizao de Reviso Precondies 1. O Engenheiro de Requisito selecionou uma Reviso da Lista de Revises recuperadas. 2. O Engenheiro de Requisito acionou o comando Visualizar Reviso. Passos 1. O ReqG recupera e exibe os Dados da Reviso. 2. O ReqG recupera e exibe cada avaliao de requisito e caso de uso associada reviso na lista de Requisitos/Casos de uso avaliados.

Fluxo alternativo Reabertura de Reviso

173

Precondies 1. O Engenheiro de Requisito selecionou uma Reviso da Lista de Revises recuperadas. 2. O Engenheiro de Requisito acionou o comando Reabrir Reviso. 3. A Reviso encontra-se no estado fechada. Passos 1. O ReqG altera o status da reviso para Aberta. 2. O ReqG salva os dados da Reviso.

174

Gerao da Especificao

Prottipo de Tela de Gerao da Especificao

Gerao da Especificao Informaes do Projeto Projeto SystemG (texto com at 30 caracteres) Gerente Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres) <Pesquisar> Projetos recuperados Projeto Descrio Gerente SystemG Criao de um sistema X Silio Silvestre Ferreira Freitas Frigo Projeto muito interessante Alberto Sobrinho Arajo TecnoComp Manuteno de algo Silio Silvestre Ferreira Freitas <Gerar Especificao>

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal O ReqG exibe a Tela de Gerao da Especificao. O Membro informa os dados para pesquisa por Projetos. O Membro aciona o comando Pesquisar. O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em ordem crescente. O Membro aciona o comando Gerar Especificao. O ReqG gera um documento no formato especificado no arquivo Modelo-ERSw.doc.

Relatrio de Acompanhamento

Prottipo da Tela de Relatrio de Acompanhamento

Relatrio de Acompanhamento Informaes do Projeto Projeto SystemG (texto com at 30 caracteres) Gerente Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres) <Pesquisar> Projetos recuperados Projeto Descrio Gerente SystemG Criao de um sistema X Silio Silvestre Ferreira Freitas Frigo Projeto muito interessante Alberto Sobrinho Arajo TecnoComp Manuteno de algo Silio Silvestre Ferreira Freitas 175

<Gerar Relatrio>

Prottipo do Relatrio de Acompanhamento

Relatrio de Acompanhamento Projeto: SystemG Gerente: Silio Silvestre ID Requisito Descrio Tipo Estado --------------------------------------------------------------------------------------------------------------------------RF1 Linguagem Java O sistema deve ser feito em Java. No-funcional Identificado (10%) RF2 Acompanhamento O sistema deve permitir o acompa- Funcional Identificado (20%) nhamento do projeto pelos membros ID Caso de uso Descrio Estado -----------------------------------------------------------------------------------------------------------------------UC4 Gerao da especificao Relatrio com a descrio do projeto Detalhado (25%) UC6 Relatrio de Acomp. Relatrio com o estado do projeto Detalhado (25%) UC8 Gesto de Membros Cadastro de membros Identificado (10%) RF3 Gesto de projeto O sistema deve permitir o acompa- Funcional Detalhado (50%) nhamento do projeto pelos membros ID Caso de uso Descrio Estado -----------------------------------------------------------------------------------------------------------------------UC2 Gesto de projetos Cadastro de projetos Detalhado (25%) UC3 Controle de projetos Controle do projeto Implementado (75%)

Percentual de concluso do projeto: 27%

Detalhamento do Caso de Uso

Precondies No aplicvel. Fluxo principal O ReqG exibe a Tela de Relatrio de Acompanhamento. O Membro informa os dados para pesquisa por Projetos. O Membro aciona o comando Pesquisar. O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em ordem crescente. O Membro aciona o comando Gerar Relatrio. Para cada requisito contido no projeto: O ReqG imprime uma linha com o ID, nome, descrio, tipo e estado do requisito, calculado a partir do estado ou a partir dos casos de uso associados. Para cada caso de uso associado ao requisito: O ReqG imprime uma linha com o ID, nome, descrio e estado do caso de uso. O ReqG soma o percentual de concluso de cada caso de uso, de acordo com o seu estado, sendo Identificado (10%), Detalhado (25%), Implementado (75%) e Homologado (100%). Se o requisito possui casos de uso associados: 176

O ReqG calcula o percentual de concluso do requisito a partir da soma de todos os percentuais dos casos de uso, dividido pela quantidade de casos de uso. Seno: O ReqG calcula o percentual de concluso do requisito a partir do estado do requisito. O ReqG calcula o percentual de concluso do projeto a partir da soma de todos os percentuais dos requisitos, divididos pela quantidade de requisitos existentes.

177

ANEXO II Exemplo de Agenda de Oficina de Levantamento de Requisitos

Agenda de Oficina de Levantamento de Requisitos Projeto NomeDoProjeto

Data: Horrio: Local: 10/05/10 11:00 - 11:30h Nome do Local Participantes do Cliente: Nome do Cliente 1 Nome do Cliente 2 Nome do Cliente 3 Participantes do Desenvolvedor: Nome do Desenvolvedor 1 Nome do Desenvolvedor 2 Nome do Desenvolvedor 3 Pauta prevista: N 1. Assunto Apresentao inicial Descrio Apresentao do calendrio (programao de datas e pautas) das oficinas; Apresentao do cronograma do levantamento inicial e detalhamento dos requisitos. 2. Sees iniciais da ERSw Determinao do Escopo do produto Descrio Geral do Produto Levantamento das Funes Pauta adicional: N 1. Assunto 1 Assunto Descrio Pauta adicional, para ser discutida caso haja tempo na reunio, apenas uma forma de preveno. Documentos necessrios para a realizao da oficina Pelo Cliente: Pelos Desenvolvedores: 1. Algum documento necessrio para se chegar em alguma funo do sistema, como normas, leis, exemplos, etc. 1. Algum documento ou artefato que pode ajudar no levantamento de requisitos. Pendncias a serem checadas: N Descrio Responsvel

1 1. Observaes: A Pauta Adicional ser discutida apenas se houver disponibilidade de tempo.

A impossibilidade de participao de algum membro convocado dever ser comunicada, no mnimo, com um dia de antecedncia da reunio. Caso algum documento a ser apresentado ou pendncia a ser checada no tenha sido preparada(o) 178

em tempo, tal fato deve ser comunicado, no mnimo, com um dia de antecedncia da reunio. Convocado por: Nome da Organizao Desenvolvedora Nome da Equipe Data: 10/05/10

179

ANEXO III Exemplo de Ata de Oficina de Levantamento de Requisitos

Ata de Reunio de Levantamento de Requisitos Projeto NomeDoProjeto

Data: Horrio: Local: 10/05/10 11:00 - 11:30h Nome do Local Participantes do Cliente: Nome do Cliente 1 Nome do Cliente 2 Nome do Cliente 3 Participantes do Desenvolvedor: Nome do Desenvolvedor 1 Nome do Desenvolvedor 2 Nome do Desenvolvedor 3 Tpicos discutidos N 1. 2. Assunto Apresentao inicial Sees iniciais da ERSw Descrio 1. O planejamento inicial foi apresentado aos usurios. 1. Foi solicitada a alterao da data de incio do perodo de reviso da ERSw pelos usurios. O fornecedor ficou de avaliar se ser possvel. 2. Foi esclarecido que os resultados precisaro ser acompanhados por outros membros da PLAG. 3. Foi sugerida uma apresentao do trabalho que est sendo feito para as pessoas envolvidas do cliente para que as mesmas tomem conhecimento. 4. O cronograma inicial das oficinas e pautas sugeridas para cada uma delas foi apresentado aos usurios. Foi colocado que caso alguma oficina seja cancelada, esse cancelamento ter repercusso em todo o planejamento comprometendo os prazos de entrega da ERSw e fases posteriores a especificao. Erratas Data Pendncias N 3. Descrio Responsvel UFPI UFPI UFPI Prazo Em aberto Tpico incorreto Correo

Agendar uma data para apresentao do trabalho que est sendo feito para os envolvidos do cliente. 4. Rever perodo de reviso da ERSw pelos usurios. 5. Rever Pautas previstas das oficinas. Data de envio da ata para o cliente:

180