CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 176

6 LEVANTAMENTO E ANLISE DE REQUISITOS

O objetivo bsico das fases de Levantamento de Requisitos e Anlise de Requisitos identificar, caracterizar e compreender o problema cuja soluo ser proposta atravs de um software. E realizar tais coisas significa fazer tratamento de requisitos, das mais diferentes formas.

6.1 REQUISITOS DE SOFTWARE E TIPOS DE REQUISITOS

As definies associadas a requisito de software so as mais variadas. Entre aquelas que podem ser citadas destacam-se as do IEEE (1997): "Uma condio ou capacidade solicitada por um usurio para resolver um problema ou para atender um objetivo seu"; "Uma condio ou capacidade que um sistema ou componente deve possuir para satisfazer um contrato, um padro, uma especificao, ou outro documento formalmente estabelecido"; "Uma representao formal (documentada) de uma condio ou capacidade descrita acima".

Pode-se citar ainda : Sentenas que expressam as necessidades dos clientes e que condicionam a qualidade do software. Podem ser funcionais ou no-funcionais; Descrio dos anseios de um cliente/usurios para um sistema de software de computador; O comportamento geral de um sistema viso do Cliente; O que o cliente quer que o sistema faa viso do Desenvolvedor; Uma especificao do que deve ser implementado.

Existem vrias classificaes para requisitos. Normalmente apenas dois tipos so considerados: Funcionais e No-funcionais. Uma das definies mais conhecidas de requisitos define os seguintes tipos: Requisitos de Negcio Os objetivos de mais alto nvel de uma organizao (documentos de viso do escopo do projeto e contexto de negcio); Requisitos do Usurio As tarefas que o usurio deve estar apto a realizar com o sistema (casos de uso); Requisitos Funcionais As funcionalidades a serem construdas (Especificao de Requisitos descries detalhadas dos casos de uso); Requisitos No-Funcionais Representam as restries impostas ao sistema, ou ao desenvolvimento deste. Exemplo: desempenho, segurana, usabilidade.

A fim de nortear a identificao de requisitos so definidos atributos destes. Alguns dos atributos que habitualmente devem ser considerados na identificao dos requisitos de um software so os seguintes: Concreto; Completo; Factvel; Necessrio; No ambguo; Dotado de uma certa prioridade.

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 177

6.2 ENGENHARIA DE REQUISITOS

Origem: http://engenhariadesoftware.blogspot.com/2007/05/engenharia-de-requisitos.html

Os diversos relacionamentos e restries que os requisitos exercem uns sobre os outros so muito difceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decises de design que afetam um ou mais requisitos s sero tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples a deciso de requisitos de segurana mais restritos que podem ir de encontro ao requisito de melhor desempenho. A importncia e complexidade de todas as atividades relacionadas aos requisitos levaram, no incio dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominao ressaltar que o processo de definir os requisitos de software uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentao e processos prprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida. Os objetivos da Engenharia de Requisitos podem ser categorizados em trs grupos principais [Zave]: Investigao de objetivos, funes e restries de uma aplicao de software. o o o o o o Ultrapassar as barreiras de comunicao; Gerar estratgias para converter objetivos vagos em propriedades ou restries especficas; Compreender prioridades e graus de satisfao; Associar requisitos com os vrios agentes do domnio; Estimar custos, riscos e cronogramas; Assegurar completude; Integrar representaes e vises mltiplas; Avaliar estratgias de solues alternativas que satisfaam os requisitos; Obter uma especificao completa, consistente e no ambgua; Validar a especificao - verificar que ela satisfaz aos requisitos; Obter especificaes que sejam apropriadas para as atividades de design e implementao; Reutilizao de requisitos durante o processo de evoluo; Reutilizao de requisitos no desenvolvimento de software similares; Reconstruo de requisitos;

Especificao do software. o o o o o

Gerenciamento da evoluo e das famlias do software. o o o

A engenharia de requisitos inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrio de observaes do mundo real atravs de notaes apropriadas. Os benefcios da Engenharia de Requisitos so: Concordncia entre desenvolvedores, clientes e usurios sobre o trabalho a ser feito e quais os critrios de aceitao do sistema; Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos); Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema;

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 178

Atingir os objetivos com o mnimo de desperdcio.

Uma boa especificao de requisitos deve ser: Clara e no-ambgua; Completa; Correta; Compreensvel; Consistente; Concisa; Confivel.

[...] (Fim do artigo)

6.2.1 CONCEITOS GERAIS

A seguir apresentado uma srie de caractersticas para melhor compreender a atuao e importncia da Engenharia de Requisitos. Universo de Informao = o conjunto geral no qual o software ser desenvolvido. Inclui todas as fontes de informao e todas as pessoas relacionadas ao software, s quais denominamos de agentes desse universo. O UdeI a realidade circunstanciada pelo conjunto de objetivos definidos por quem solicitou o software. Ponto de Partida para se trabalhar com os requisitos: o ESCOPO, identificado na etapa de Planejamento.

Motivaes para o Desenvolvimento da Engenharia de Requisitos: Aspectos Sociais Baixo nvel de aceitao dos sistemas pelos usurios o o Em Sistemas de Informao Comerciais chegam a 40% Em Sistemas de Informao de tempo-real chegam a 75%

Aspectos Jurdicos O documento de requisitos um acordo contratual entre clientes e fornecedores. Os desenvolvedores de software tm obrigao de inquirir os requisitos dos seus clientes. Os desenvolvedores de software tm a obrigao de informar seus usurios acerca da soluo proposta (um manual de usurios no suficiente)

Aspectos Econmicos

Especificao Projeto Codificao

70%

70% 60% 50% 40% 30% 20% 10% 0% 40% 30% 30%

25% 9%

% total erros

% total do custo de correo erros

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 179

A Importncia da realizao de uma Engenharia de Requisitos: A causa da falha (e do sucesso) de muitos projetos atribuda aos requisitos; A Sociedade exige softwares cada vez mais complexos, demandando a aplicao de tcnicas mais avanadas; Quanto mais prematura a descoberta de erros durante o processo de desenvolvimento de software: o o o Menor o custo das correes; Melhor qualidade; Melhor atendimento de prazos estipulados.

Questes que precisam ser respondidas: Como capturar e categorizar adequadamente as necessidades do cliente para um dado produto? Que artefatos devemos criar para representar esse conhecimento?

Perfil do Engenheiro de Requisitos: Habilidade de lidar com conceitos abstratos; Habilidade de absorver fatos pertinentes a partir de fontes conflitantes e confusas; Habilidade de entender o ambiente do usurio/cliente; Habilidade de lidar com problemas complexos; Habilidade de aplicar elementos de software/hardware ao ambiente do usurio/cliente; Habilidade de comunicar-se bem; Habilidade de evitar detalhes desnecessrios.

Benefcios que a Engenharia de Requisitos pode alcanar: No ter de refazer funcionalidades; o o Em ambas as fases de desenvolvimento e manuteno; Isso custa em mdia 68200 vezes mais caro!

A equipe toma um maior e melhor conhecimento do domnio do problema a ser resolvido; Evita escrever funcionalidades que no so necessrias; Sincronismo maior entre o que foi contratado com o que ser implementado pelos desenvolvedores; Equipe de desenvolvimento e clientes mais satisfeitos.

6.2.2 DIFICULDADES A SEREM ENFRENTADAS

Trata-se de uma rea at recentemente no muito estudada. No entanto a necessidade de melhorar o software e a identificao deste nicho como possvel soluo deu um grande impulso a rea. Erros mais comuns cometidos durante o Levantamento de Requisitos:

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 180

Ignorar um grupo de clientes; Ignorar um nico cliente; Omitir um grupo de requisitos; Permitir inconsistncias entre grupos de requisitos; Aceitar requisito inadequado; Aceitar requisito incorreto, indefinido, ou impreciso; Aceitar um requisito ambguo e inconsistente.

Alguns problemas relativos Comunicao: Como apresentar os dados? Problemas com abstrao (generalizao x especializao); Linguagem (vocabulrio, termos utilizados); Se no conseguirmos uma comunicao adequada, como querer extrair os requisitos corretamente? Isto , como evitar um Domnio de aplicao mal definido? Como especificar requisitos sem saber de onde retirar os dados necessrios? Dados demais causam: o o Atrasos no cronograma; Tornam difcil a identificao dos requisitos reais do sistema; Provavelmente os requisitos no refletiro a real necessidade do usurio (se que o software poder ser construdo num caso assim); Inconsistncias; Falta de completude; Ambigidade; Falta de mtricas.

Dados de menos causam: o

Conseqncias de problemas de comunicao: o o o o

A utilizao de tcnicas apropriadas permitem identificar estes problemas, fornecer algum apoio a soluo. Problemas enfrentados pelo Desenvolvedor: frustrante tomar conhecimento da real funcionalidade desejada quando o sistema j se encontra pronto; Escrevem funcionalidades implcitas e documentaes de requisitos incompletas; Interrupes no andamento do projeto; No discutem as necessidades e desejos com afinco; difcil decidir o que precisa ser exatamente implementado; Pensam que j sabem o que o cliente necessita; Minimizam a qualidade do produto.

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 181

Problemas enfrentados pelo Cliente: Usam um produto de software que no executa as tarefas desejadas; Inibido para comunicar as mudanas ocorridas; Acreditam que o tempo perdido na fase de coleta de requisitos s ir atrasar a entrega do produto final (Build-me a system now!!! ).

6.2.3 ATIVIDADES DA ENGENHARIA DE REQUISITOS

Existem diferentes classificaes sobre quais atividades devem ser realizadas durante a Engenharia de Requisitos. As mais comumente encontradas so: Elicitao; Validao; Anlise; Modelagem.

Aquisio

Especificao

Elicitao

Modelagem

Validao

Anlise

Alm delas ainda podem ser citadas: Estudo de Viabilidade; Determinao do domnio da aplicao; Gesto de Requisitos.

O estudo de viabilidade e a determinao do domnio da aplicao costumam ocorrer logo no incio do desenvolvimento do software, durante o Planejamento do Projeto. A Gesto de Requisitos deve ocorrer durante todo o ciclo de vida do software. As demais atividades so comumente realizadas durante as fases conhecidas como Levantamento de Requisitos (descoberta dos requisitos) e Anlise de Requisitos (estudo e compreenso dos requisitos).

6.2.3.1
o o o

Estudo de Viabilidade
Contribui para os objetivos da organizao; Pode ser construdo utilizando a tecnologia corrente dentro do oramento; Pode ser integrado com outros sistemas. E se o sistema no fosse implementado? Quais so os problemas dos processos correntes?

Um estudo viabilidade decide se o sistema proposto:

Questes a serem respondidas pelas pessoas da organizao: o o

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 182

o o o o

Como o sistema proposto ajudar? Quais sero os problemas de integrao? preciso nova tecnologia? Quais as facilidades que devem ser suportadas pelo sistema proposto?

6.2.3.2

Determinao do Domnio da Aplicao

Trata-se de um subconjunto do sistema no qual o software ser aplicado; Inclui pessoas, as diversas fontes de informao; Delimita o que ser feito; Dados (atributos) + Controles (eventos); Relacionado definio do ESCOPO do software.

6.2.3.3

Elicitao

Envolvimento com o ambiente de trabalho do cliente; Entender a razo porque as coisas so feitas da forma que so; Descoberta de dados sobre o sistema a serem utilizados na definio de requisitos. Conseqentemente, identificao da fonte destes dados: pessoas, livros, leis, sistemas anteriores; Meios de extrair os dados: leitura de documentos, engenharia reversa, observao, entrevistas, questionrios, etc; Envolve a equipe tcnica trabalhando com clientes para conhecer melhor o domnio da aplicao, os servios que o sistema dever prover e as restries operacionais do sistema; Pode envolver usurios finais, gerentes, engenheiros, especialistas de domnio, etc. Genericamente so chamados stakeholders; H 03 atividades principais: o Identificao de fontes de informao os locais para coleta de informaes. UdeI: Contm toda informao necessria; Agentes (Atores, Usurios); Outras fontes de Informao: Documentao do macrosistema, Polticas, Manuais, Memos, atas, contratos..., Livros sobre tema relacionado, Outros sistemas da empresa, Outros sistemas externos; Importante: Priorizar as Fontes de Informao. o Atores mais importantes; Documentos mais mencionados; Rede de comunicaes entre os componentes do macro-sistema.

Coleta de Dados a captura das informaes necessrias. Existem diferentes maneiras de se coletar dados, entre elas podem ser citadas: Leitura de documentos; Observao; Entrevistas; Questionrios; Anlise de Protocolos; Participao ativa dos agentes do UdeI; Enfoque antropolgico; Reunies; Reutilizao; Recuperao (engenharia reversa) do projeto do software;

Comunicao forma de contato entre todos os envolvidos no projeto.

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 183

O que costuma utilizar: Ferramentas, Pessoal, Mtodos.

6.2.3.4

Anlise

Compreenso do problema; Identificao de Partes - Derivar implicaes (O particionamento para melhor entender e atacar o problema, e as interfaces entre as partes); Resolver inconsistncias; Determinar o que est faltando.

6.2.3.5

Verificao e Validao

Origem: Engenharia de Software, Ian Sommerville, 8. Edio

A validao de requisitos dedica-se a mostrar que os requisitos definem o sistema que o cliente realmente deseja e est relacionada a descoberta de problemas envolvendo requisitos. Costuma ocorrer em conjunto com a atividade de anlise de requisitos. Custos de erros de requisitos so altos e, desse modo, a validao muito importante. O custo da reparao de um erro de requisitos depois da entrega pode equivaler a 100 vezes o custo de reparao de um erro de implementao. As verificaes realizadas normalmente envolvem: Verificao de validade. O sistema fornece as funes que melhor apiam as necessidades do cliente? Verificao de consistncia. Existe algum tipo de conflito de requisitos? Verificao de completeza. Todas as funes requisitadas pelo cliente foram includas? Verificao de realismo. Os requisitos podem ser implementados com o oramento e a tecnologia disponveis? Facilidade de verificao. Os requisitos podem ser verificados?

H uma srie de tcnicas quem podem ser aplicadas individualmente ou em conjunto, destacando-se: Revises de requisitos - Anlise manual sistemtica dos requisitos. Prototipao - Uso de um modelo executvel do sistema para verificar requisitos.. Gerao de casos de teste - Desenvolvimento de testes para requisitos a fim de verificar a testabilidade.

Reviso de Requisitos Revises regulares devem ser feitas enquanto a definio de requisitos est sendo formulada. Ambos, cliente e fornecedor, devem ser envolvidos nas revises. Revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre desenvolvedores, clientes e usurios podem resolver problemas nos estgios iniciais.

A verificao a ser procedida deve checar consistncia e completeza, alm disso podem ser verificados os seguintes itens:

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 184

Facilidade de verificao. O requisito realisticamente testvel? Facilidade de compreenso. O requisito adequademente compreendido? Rastreabilidade. A origem do requisito claramente estabelecida? Adaptabilidade. O requisito pode ser mudado sem um grande impacto em outros requisitos?

6.2.3.6

Modelagem

Os resultados da fase de aquisio so modelados (especificados) em forma de modelos conceituais; Criao de modelos com base nos requisitos coletados (organizao, modelao); Auxilia na anlise dos requisitos, identificao de problemas; Visa definir: Fluxo de Informao, Contedo da Informao, Estrutura da Informao (relacionamentos); Procura localizar: Entradas, Sadas, Processos, Interfaces, Informaes; Por exemplo: modelos de caso de uso; Diferentes modelos podem ser produzidos durante a atividade de modelagem de requisitos. Tais modelos organizam-se basicamente em: o o o Particionamento identificao de relacionamentos (parte de) entre entidades; Abstrao identificao de generalidades entre entidades; Projeo identificao de diferentes formas de se olhar para o problema. Representao Tipos, Relaes, Operaes; Organizao Nveis de Abstrao, Regras de Refinamento, Regras de Consistncia; Armazenamento Classificao.

H 03 atividades: o o o

6.2.3.7

Gesto de Requisitos

o processo de gerir as mudanas nos requisitos durante o processo de engenharia de requisitos e o prprio processo de desenvolvimento de sistemas; Requisitos so inevitavelmente incompletos e inconsistentes. o o Novos requisitos emergem durante o processo, pois as necessidades do negcio mudam e a compreenso dos requisitos melhora; Pode haver contradio nos requisitos; A prioridade de desenvolvimento; requisitos diferentes pode mudar durante o processo de

Mudana de requisitos. o o

O negcio pode sofrer alteraes durante o desenvolvimento.

6.3 LEVANTAMENTO DE REQUISITOS

O levantamento de requisitos a etapa mais importante em termos de retorno em investimentos feitos para um projeto de desenvolvimento. Muitos sistemas foram abandonados ou nem chegaram a uso porque os membros da equipe no dispensaram tempo suficiente para compreender as necessidades do cliente em relao ao novo sistema. Em um estudo baseado em 6.700 sistemas

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 185

feito em 1997, Carper Jones mostrou que os custos resultantes da m realizao desta etapa de entendimento podem chegar a 200 vezes o realmente necessrio (Jones, 1997). (http://www.mundooo.com.br/php/modules.php?name=MOOArtigos&pa=showpage&pid=20). A grande pergunta a ser respondida neste momento : O que o cliente deseja do sistema a ser desenvolvido? Diferentes metodologias propem diferentes maneiras de se proceder ao levantamento de requisitos. Hoje em dia, as tarefas que costumam ser realizadas so: Descoberta de requisitos; Definio do Escopo; Modelagem de Casos de Uso.

preciso ter-se em mente o seguinte: O Levantamento de Requisitos a etapa onde so identificadas as necessidades do cliente, e conseqentemente as caractersticas do problema que deve ser resolvido pelo sistema em construo; focada em compreender O QUE o problema, sem se preocupar em COMO o problema ser implementado; Antes de efetivamente iniciar a identificao dos Casos de Uso, e o seu detalhamento, necessrio gerar alguma compreenso sobre o problema, o que pode vir atravs de uma Descrio de Mini-Mundo, ou ainda a definio do Escopo do Problema. No Escopo habitualmente so identificados: o O Ambiente da Empresa descrio da empresa e do ambiente de trabalho onde o sistema ser desenvolvido; o O Problema identificao das principais caractersticas do problema que precisar ser transportado para o software, destacando as dificuldades que o cliente vem enfrentando atualmente por no ter um sistema informatizado, ou por ter um sistema informatizado que no atende as suas reais necessidades; o A proposta de soluo identificao das principais caractersticas da soluo a ser proposta para o cliente, sem entrar em detalhes, mas comentando como sero resolvidos os problemas listados anteriormente; o Os benefcios esperados identificao dos principais benefcios que o cliente ir adquirir em seu ambiente de trabalho ao utilizar a soluo proposta; o Os limites / restries caso o sistema a ser desenvolvido tenha algum limite / restrio de uso ou de processos a serem implementados, identificados desde o 1. momento interessante j deix-lo caracterizado desde este momento; Aps a definio do Escopo realiza-se a modelagem de casos de uso.

Principais artefatos gerados em tal etapa: Definio de Requisitos Tal documento pode no ser gerado, considerando-se que posteriormente os requisitos devem estar contemplados na Especificao de Requisitos. Porm sua elaborao pode auxiliar Gesto de Requisitos; Especificao de Requisitos.

6.4 ANLISE DE REQUISITOS

Origem: Anlise de Sistemas, Notas de Aula, prof. Ricardo Falbo, UFES, Departamento de Informtica. Com insero de comentrios prprios.

Ao contrrio do Levantamento de Requisitos, que pode ser realizado como etapa inicial para praticamente qualquer metodologia, a anlise de requisitos, mais focada na elaborao de modelos ir requerer a escolha de uma metodologia. No caso dessa disciplina estar sendo descrita a Anlise de Requisitos Orientada a Objeto.

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 186

O objetivo da Anlise Orientada a objetos definir todas as classes relevantes ao problema, suas operaes e atributos, seus relacionamentos, seu comportamento. As classes identificadas neste momento so denominadas Classes de Negcio (pois so relacionadas ao problema, enquanto que durante a fase de Design so identificadas as Classes de Software). Pode ser vista literalmente como a traduo de objetos do mundo real para o mundo computacional (o comeo, pelo menos) Quando um novo sistema precisa ser construdo e decidimos utilizar o paradigma orientado a objetos (OO) em seu desenvolvimento, surge uma importante questo: Como modelar os requisitos do sistema de um modo adequado para a Engenharia de Software OO? Uma vez que, essencialmente, este paradigma trabalha com objetos, necessrio identificar quais os objetos relevantes, como eles se relacionam e como eles se comportam no contexto do sistema. Alm disso, preciso especificar e modelar o problema de maneira que seja possvel criar um projeto OO efetivo. Todos estes aspectos so tratados dentro do contexto da Anlise Orientada a Objetos (AOO) [Pressman00]. O propsito da Anlise Orientada a Objetos (AOO) definir todas as classes (e os relacionamentos e comportamentos associados a ela) que so relevantes para o problema a ser resolvido. Para tal, um nmero de tarefas deve ocorrer: Identificao de Classes; Especificao de Hierarquias de Generalizao/Especializao; Identificao de Associaes e Atributos; Modelagem do Comportamento; Definio das Operaes.

importante notar que estas atividades so dependentes umas das outras e que, durante o desenvolvimento, elas so realizadas, tipicamente, de forma iterativa. A nfase da fase de anlise, no entanto, deve ser sempre o entendimento do domnio do problema, sempre desconsiderando aspectos de implementao. A popularidade da orientao a objetos fez surgir dezenas de mtodos OO para anlise e projeto. Cada um deles, introduz um processo para analisar um sistema, um conjunto de modelos que evoluem ao longo do processo e uma notao que permite ao engenheiro de software criar cada modelo de maneira consistente [Pressman00]. Entre os principais mtodos existentes podemos citar o Mtodo de Booch [Booch94], OMT [Rumbaugh94], OOSE [Jacobson92] e o Mtodo de Coad & Yourdon [Coad92][Coad93]. Ainda que, primeira vista, estes mtodos possam parecer substancialmente diferentes, isto no verdade. Todos eles consideram, de alguma forma, as tarefas listadas anteriormente. Essencialmente, as maiores diferenas esto nas diretrizes e heursticas fornecidas, nos modelos utilizados, suas notaes e no processo sugerido. Tentativas para se definir um mtodo padro tm sido realizadas, mas tm encontrado como principal obstculo a definio de um processo padro de anlise e projeto. Assim, um primeiro passo foi dado ao se propor a Linguagem de Modelagem Unificada (UML), que estabelece, para um conjunto de modelos normalmente utilizados no desenvolvimento OO, uma notao padro. [...]

6.5 UML - LINGUAGEM DE MODELAGEM UNIFICADA

Origem: http://www.plugmasters.com.br/sys/materias/476/1/UML---Que-raios-%E9-isso%3F Autor: Bruno Roque Data: 13/11/2006 Artigo: UML Que raios isso?

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 187

Quando a gente acha que j viu todo o tipo de sopa de letras em desenvolvimento de software sempre aparece algo novo. Agora surge essa tal de UML que se tornou um padro mundial em desenvolvimento de sistemas, mas que raios isso? A UML ou Unified Modeling Language (que nada tem a ver com XML, HTML, XLS, DML, DHTML) uma linguagem de modelagem no proprietria de terceira gerao. Ela foi criada para facilitar e uniformizar a forma de especificao de projetos de desenvolvimento de software. Agora voc deve estar se perguntando "Vou ter que aprender mais uma metodologia?". Bem, na verdade metodologia no, pois a UML no um mtodo, uma notao. Um mtodo normalmente 1 composto por uma linguagem de modelagem (notao grfica) e por um processo (passos para elaborao do projeto). Dessa forma a UML, pode ser usada com qualquer processo j que independente dele. Resumindo, a definio ideal para a UML seria: UML (Unified Modeling Language - Linguagem de Modelagem Unificada) uma linguagem para 2 especificao, visualizao, construo e documentao de artefatos de desenvolvimento de sistemas. Breve Histria Para entender porque a UML se tornou um padro mundial interessante conhecermos como ela nasceu e como se desenvolveu at chegar a sua verso atual (verso 2.0). No incio dos conceitos de O.O. (Orientao a Objetos), diversos mtodos foram apresentados para a comunidade. Chegaram a mais de 50 entre os anos de 1989 a 1994, porm a maioria deles cometeu o erro de tentar estender os mtodos estruturados da poca. Com isso os maiores prejudicados foram os usurios, no caso ns, que no conseguiam encontrar uma maneira satisfatria de modelar seus sistemas. Essa situao ficou conhecida como a guerra dos mtodos. Foi a partir da dcada de 90 que comearam a surgir teorias que procuravam trabalhar de forma mais ativa com o paradigma da orientao a objetos. Diversos autores famosos contriburam com publicaes de seus respectivos mtodos. Por volta de 1993 existiam 3 mtodos que mais cresciam no mercado, eram eles Booch93 de Grady Booch, OMT-2 de James Rumbaugh e OOSE de Ivar Jacobson. Cada um deles possua pontos fortes em alguma parte. O OOSE possua foco em casos de uso (use cases), OMT-2 se destaca na fase de anlise de sistemas de informao e Booch93 era mais forte na fase de projeto. O sucesso desses mtodos se deu principalmente ao fato de no terem tentado estender os mtodos j existentes. Seus mtodos j convergiam de maneira independente, ento seria mais produtivo continuar de forma conjunta. Em outubro de 1994 comearam os esforos para unificao dos mtodos. J em outubro de 1995 Booch e Rumbaugh lanaram um rascunho do Mtodo Unificado unificando o Booch93 e o OMT-2, aps isso Jacobson se juntou equipe do projeto e o Mtodo Unificado passou a incorporar o OOSE. E foi em junho de 1996 que os trs amigos, como j eram conhecidos, lanaram a primeira verso com os trs mtodos, a verso 0.9 que foi batizada como UML. Da em diante surgiram vrias novas verses, como podemos acompanhar atravs do grfico abaixo:

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 188

A OMG lanou uma RFP (Request for Proposals) para que outras empresas pudessem contribuir com a evoluo da UML, da se chegou a verso 1.1. Aps alcanar esta verso, a OMG passou a 4 adot-la como padro e a se responsabilizar (atravs da RTF Revision Task Force) pelas revises. Essas revises so controladas de forma a no provocar uma grande mudana no escopo original. E realmente foi isso que aconteceu, se observarmos as diferenas entre as verses, veremos que de uma para a outra no houve grande impacto, o que facilitou sua disseminao pelo mundo. Viso Geral A UML permite modelar: Elementos; Relacionamentos; Mecanismos de Extensibilidade; Diagramas. Elementos: Estruturais Classes, interfaces, colaboraes, componentes, casos de uso, classes ativas, ns; Comportamentais Interaes, mquinas de estado; Grupos de elementos Pacotes, subsistemas, modelos; Outros Notas.

Relacionamentos: Dependncias; Associaes; Generalizaes; Implementaes (realization);

Mecanismos de Extensibilidade: Esteretipos;

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 189

Tagged value; Regras (constraints).

Diagramas: Um Diagrama uma representao grfica parcial ou total de um modelo. Apresentao grfica de uma coleo de elementos de modelo, geralmente processados como um grfico de arcos (relacionamentos) e vrtices (outros elementos de modelo) conectados. A UML 2.0 (verso atual) define 13 tipos de diagramas divididos em 2 categorias. Modelos Estticos ou Estruturais Diagramas estticos ou estruturais definem estaticamente a arquitetura de um modelo. So usados para modelar as coisas que compem um modelo - as classes, os objetos, as relaes e os componentes fsicos. Alm disso, tambm so usados para modelar os relacionamentos e as dependncias entre elementos. Abaixo temos uma tabela com os diagramas estruturais e suas respectivas descries: Diagrama de pacotes usado dividir o modelo em containers lgicos ou em "pacotes" e descreve as interaes entre eles em alto nvel. Diagrama de classes Define os elementos bsicos de um modelo: os tipos, as classes e os relacionamentos so usados construir um modelo completo. Diagrama de objetos Similar ao diagrama de classes, porm sua principal diferena que ele apresenta os atributos com valores. Corresponde a uma instncia do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo. Diagrama de estrutura composta Fornece meios de definir a estrutura de um elemento e de focaliz-la no detalhe, na construo e em relacionamentos internos. Diagrama de componentes Apresenta as dependncias ente componentes de softwares, incluindo implementao de classes, arquivos de cdigo fonte, arquivo de cdigo binrio, arquivos executveis e scripts. Diagrama de instalao

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 190

Mostra a configurao dos elementos de processamento em tempo de execuo, alm dos componentes, processos e objetos do sistema neles existentes. Modelos Dinmicos ou de Comportamento Os diagramas dinmicos ou de comportamento apresentam as variedades da interao e do estado instantneo dentro de um modelo enquanto executado. Diagrama casos de uso usado modelar interaes do usurio/sistema. Definem o comportamento, as exigncias e o resultado esperado de uma funcionalidade. Diagrama de atividades uma variao do diagrama de mquina de estados. Representa a execuo das aes e as transies que so acionadas pela concluso de outras aes ou atividades. Diagrama de mquina de estados Representa as aes ocorridas em reposta ao recebimento de um evento, onde cada ponto de parada representa um estado da aplicao. Diagrama de comunicao Exibe uma interao, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Diagrama de seqncia usado para representar o comportamento das operaes, mtodos (procedimentos ou funes) entre classes de um cenrio. Diagrama de Tempo a fuso do diagrama de seqncia e estado apresentando o comportamento dos objetos e sua interao em uma escala de tempo, ou seja, o estado dos objetos em relao ao tempo e as mensagens que modificam esse estado. Diagrama de Interatividade a fuso do diagrama de atividades e seqncia. Ele permite que fragmentos das interaes sejam facilmente combinados aos pontos e fluxos de deciso. Como acredito que voc j est cansado de ler este texto (eu estaria!!), vou encerrar por aqui essa introduo. Nos prximos artigos darei mais detalhes, inclusive com exemplos de cada um desses diagramas. At mais pessoal!

Observaes: 1 - responsabilidade do processo decidir quais e quando os artefatos sero produzidos, a equipe e atividades necessrias para criar e manter esses artefatos. 2 - Exemplos: Requisitos, Caso de Uso, Plano de Teste, cdigo-fonte, planos de projetos, etc.. 3 A OMG uma organizao internacional, fundada em 1989. Promove teoria e prtica da tecnologia orientada a objetos em desenvolvimento de sistemas.

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 191

4 A verso 1.1 foi oferecida a OMG em Julho de 1997 e foi aceita em Setembro do mesmo ano. Em 14 de Novembro de 1997, a UML 1.1 passou a ser adotada como padro pela OMG.

6.6 MTODOS E TCNICAS DE LEVANTAMENTO DE REQUISITOS 6.6.1 TCNICAS PARA COLETA DE DADOS
OBSERVAO: Material base se encontra em anexo. Anlise de Sistemas, Notas de Aula. prof. Ricardo Falbo, UFES, Departamento de Informtica. Captulo 2 Tcnicas de Levantamento de Requisitos.

6.6.2 MODELAGEM DE CASOS DE USO

OBSERVAO: Material base se encontra em anexo. Anlise de Sistemas, Notas de Aula. prof. Ricardo Falbo, UFES, Departamento de Informtica. Captulo 3 Modelagem de Casos de Uso; Tambm recomendada a leitura do seguinte texto: Um tutorial para escrita de casos de uso, Marco Mendes, site: http://blog.marcomendes.com/2006/10/09/um-tutorial-para-escrita-decasos-de-uso/

A seguir se encontra disposto um resumo-guia para tratamento de casos de uso.

Origem: Modelagem Orientado a Objeto, Engenharia de Software, 2006.2, UNESP

Diagrama de Caso de uso Especificam a viso externa do sistema; Descrevem como o sistema percebido por seus usurios; Descrevem as interaes entre os usurios e o sistema; Descreve uma seqncia de aes que representam um cenrio principal (perfeito) e cenrios alternativos demonstrando o comportamento de um sistema; Objetivo da modelagem de casos de uso: o Separar as funcionalidades do sistema, agrupando um conjunto de aes que tenham um objetivo bem definido

Notao:

Caso de Uso 1

Ator

Caso de Uso 2

Ator o Representa um conjunto coerente de papis que os usurios de casos de uso desempenham quando interagem com esses casos de uso;

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 192

o o o

Ser humano, dispositivo de hardware, ou outro sistema; Os atores no so parte do sistema: representam interaes individuais com o sistema de maneira especfica; Os atores se conectam aos casos de uso somente por associao. A Associao indica que o ator e o caso de uso se comunicam entre si, cada um com possibilidade de enviar e receber mensagens;

Caso de Uso o o o Descreve o que um sistema faz, mas no especifica como isso feito; Deve ter um nome que o distingue dos demais casos de uso; O comportamento de um caso de uso especificado atravs de um, ou mais, cenrios (descrio do caso de uso);

Exemplo de uma descrio simplificada e parcial de Caso de Uso:

Dicas para a modelagem dos Casos de Uso: 1 2 3 4 Pode-se iniciar identificando uma lista de atores ou uma lista de casos de uso (a partir de uma lista pode-se chegar na outra). Dado um caso de uso, identificamos seus atores a partir de questes como: Quais atores so responsveis por este caso de uso? Dado um ator, identificamos sua interao com o sistema: Quais so os servios que o sistema deve oferecer a esse ator? Necessrio tambm identificar os papis dos atores (do origem a novos atores).

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 193

Identificar cenrios comuns a vrios casos de uso. (fatorao dos cenrios comuns em casos de uso separados)

6.7 MTODOS E TCNICAS DE ANLISE DE REQUISITOS

[...] Neste texto, no adotamos nenhum mtodo especfico, mas, ao mesmo tempo todos. Isto , procuramos incorporar as caractersticas que julgamos serem as mais teis de cada um dos mtodos em uma abordagem bsica para o desenvolvimento OO. O processo de desenvolvimento deve ser definido caso a caso, levando-se em conta as particularidades do projeto em questo, do domnio de aplicao e das caractersticas da equipe de desenvolvimento, entre outras. Mas a abordagem aqui proposta pode ser vista como o ponto de partida para esta definio. Quanto aos modelos e suas notaes, adotamos, basicamente, aqueles definidos na UML [Furlan98]. (Origem: Anlise de Sistemas, Notas de Aula, prof. Ricardo Falbo, UFES, Departamento de Informtica.) OBSERVAO: Material base se encontra em anexo. Anlise de Sistemas, Notas de Aula. prof. Ricardo Falbo, UFES, Departamento de Informtica. Captulo 5 Anlise Orientada a Objetos.

6.8 DOCUMENTAO 6.8.1 DEFINIO X ESPECIFICAO DE REQUISITOS

Definio de Requisitos: o Uma declarao em linguagem natural dos servios que o sistema dever prover e suas limitaes operacionais. Exemplo: O software deve prover meios para representao e acesso a arquivos externos criados por outras ferramentas; o o Deve conter tanto os requisitos funcionais quanto os no-funcionais; No modelo proposto que acompanha este material o documento de definio de requisitos apresenta trs listas de requisitos: Aprovados, Adiados e Cancelados. Um documento estruturado contendo de forma detalhada descries dos servios. Escrito como um contrato entre cliente e fornecedor; Exemplo: O usurio deve ter facilidades para definir o tipo dos arquivos externos; Cada arquivo externo pode ter uma ferramenta associada, a qual pode ser aplicada ao arquivo Cada arquivo externo pode ser representado como um cone especfico na tela do computador etc. o o o No um documento de projeto. Na medida do possvel, dever definir o QUE do sistema em vez de COMO o sistema dever ser feito; Serve de base para o projeto ou implementao; Deve-se garantir que todos os requisitos aprovados que constam do documento de Definio de Requisitos estaro aqui contemplados;

Especificao de Requisitos: o

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 194

No modelo proposto que acompanha este material o documento de especificao de requisitos apresenta o Escopo do Sistema e a Modelagem de Casos de Uso.

Sobre Descrio de Caso de Uso Existem vrias maneiras possveis de se elaborar um caso de uso, visto que ele basicamente uma descrio textual. O que mais importa que todos os detalhes do processo estejam ali identificados, de uma maneira clara e completa, que poder ser avaliado e compreendido por todos os envolvidos no processo de desenvolvimento de software. Segue abaixo um dos modelos de descrio de caso de uso com os quais prefiro trabalhar. Apesar dele ser muito textual, normalmente ficando mais longo do que outros modelos, ele deixa os detalhes do caso de uso bem caracterizados. O modelo separa o caso de uso em 4 partes: Objetivo onde fica descrito o objetivo do caso de uso, e as observaes que forem julgadas pertinentes; Curso Normal onde fica(m) descrito(s) o(s) processo(s) principal(is) tratado(s) no caso de uso. Ele organizado fortemente atravs dos passos que o processo segue para ser executado, caracterizando basicamente a comunicao que dever ser realizada entre o ator do caso de uso e o sistema a ser desenvolvido; Curso Alternativo Descrio de provveis tratamentos de erro e excees que o processo possa conter, e que so para c transcritos a fim de destacar o curso normal, bem como facilitar a leitura do caso de uso; Regras de Negcio onde podem ficar descritos as frmulas, clculos e procedimentos executados dentro de algum dos cursos acima identificados e que so aqui definidos para facilitar a leitura, alm de permitir uma maior concentrao e destaque no procedimento. E tambm facilitar reutilizao de texto quando este procedimento for ser descrito em mais de um local do caso de uso, ou mesmo em casos de uso diferentes.

6.8.2 ESPECIFICAO DE ANLISE

Para poder melhor trabalharmos com a Especificao de Anlise de Sistemas segue em anexo a este material um modelo de um documento de Especificao de Anlise de Sistemas simplificado. A seguir encontra-se algum detalhamento sobre tal modelo. O modelo separa o documento em 4 partes: Introduo uma breve descrio sobre o documento e o que ser tratado. Exemplo de Texto: Este documento contm a especificao de anlise para o projeto de informatizao da <...>. Esta atividade foi desenvolvida em duas etapas principais, a primeira focando na estrutura de informao do sistema (classes, atributos e associaes), a segunda em seu comportamento (operaes e trocas de mensagem entre objetos). Na seo 2, so apresentados os produtos da primeira etapa, a saber: Diagrama de Pacotes, Diagramas de Classes (um para cada pacote). Na seo 3, so apresentados os produtos da segunda etapa: Diagramas de Transio de Estados (para as classes com comportamento varivel ao longo do tempo), Diagramas de Seqncia (agrupados por casos de uso) e as Descries dos Atributos e Operaes, fechando o conjunto de produtos gerados na fase de anlise. Modelagem Esttica Contm a descrio da soluo do sistema de maneira esttica, identificando as classes e atributos, operaes e relacionamentos. A modelagem esttica basicamente representada por dois tipos de diagramas: o Diagrama de Pacotes caso tenha sido elaborado no Documento de Especificao de Requisitos deve ser aqui repetido, caso contrrio dever ser criado neste

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 195

momento. Deve-se sempre ter em mente que os pacotes identificados devem agrupar classes de negcio, mais do que uma funcionalidade similar; o Diagrama de Classes deve ser criado pelo menos um diagrama de classe para cada pacote identificado anteriormente. Um diagrama de classe ir conter a identificao das classes, com seus atributos, operaes e relacionamentos;

Modelagem Comportamental Contm a descrio da soluo do sistema de maneira dinmica (comportamental), identificando os estados pelos quais uma classe pode passar e a seqncia de execuo de cada um dos processos que compe os casos de uso, j considerando as operaes das classes que devem ser executadas. A modelagem comportamental basicamente representada por dois tipos de diagramas: o Diagrama de Estados deve ser criado um diagrama de estado para cada classe cuja variao de estados seja interessante de ser mapeada. A sua construo no obrigatria, mas apenas em casos de existirem classes com vrios estados, cujo mapeamento facilite o entendimento da soluo; Diagrama de Seqncia deve ser criado um diagrama de seqncia para cada caso de uso do sistema, descrevendo as operaes de cada classe que devem ser executadas na realizao do caso de uso;

Descrio de Atributos e Operaes contm a descrio detalhada dos atributos e operaes de cada classe. Vale destacar que no caso dos atributos descreve-se o significado de cada atributo, e no caso das operaes descreve-se o objetivo e principais caractersticas de cada operao (uma espcie de algoritmo para guiar o programador sem lhe tirar a liberdade de criao de cdigo-fonte).

OBSERVAO: Para melhor acompanhamento e fixao das atividades de Levantamento e Anlise de requisitos, em anexo a este contedo esto propostos alguns modelos (e exemplos) de documentos habitualmente gerados em tais atividades. Os documentos so os seguintes: Levantamento de Requisitos: Definio de Requisitos (modelo); Especificao de Requisitos (modelo e exemplo); Anlise de Sistemas: Especificao de Anlise (modelo e exemplo).

6.9 SUGESTES DE FERRAMENTAS

Para se trabalhar com os diagramas da UML interessante o uso de alguma ferramenta que permita essa diagramao. Algumas ferramentas atualmente disponveis no mercado so: Rational Rose Desenvolvido pela Rational Corporation, de uso comercial, porm possui verses de avaliao free (normalmente no prazo de 30 dias) (http://www.rational.com); VisualParadigm for UML - H verso free (http://www.visual-paradigm.com/); Together (www.togethersoft.com); Poseidon (http://www.gentleware.com/products.html); DIA - Download free (http://www.lysator.liu.se/~alla/dia/); Jude UML download free (http://objectclub.esm.co.jp/Jude/);))

CEUNES-UFES Matria: Levantamento e Anlise de Requisitos

Disciplina: Engenharia de Software Pgina: 196

ArgoUML Download free (http://www.argoUML.tigris.org).

6.10 DICAS DE LEITURA

PRESSMAN, Roger. Engenharia de software. 2006. McGraw-Hill. Captulo 7 Engenharia de Requisitos; captulo 8 Modelagem de Anlise; SOMMERVILLE, Ian. Engenharia de software. 2007. Pearson Education. Captulo 6 Requisitos de Software; Captulo 7 Processos de Engenharia de Requisitos; captulo 8 Modelos de sistemas; FURLAN, Jos Davi. Modelagem de objetos atravs da UML. Captulo 2 Modelando com a UML; LARMAN, Graig. Utilizando UML e padres. 2007. Bookman; Artigo: Ferramentas de apoio UML: um modelo para avaliao baseado em requisitos funcionais e no-funcionais, JULIANE FORESTI, LIS NGELA DE BORTOLI, Instituto de Cincias Exatas e Geocincias Universidade de Passo Fundo (UPF) (site: http://www.dcc.ufla.br/infocomp/artigos/v4.1/art08.pdf) Dica: a Aspercon (http://www.aspercom.com.br/) disponibiliza um curso on-line grtis denominado Entendendo Casos de Uso. Basta acessar o site, se cadastrar, e fazer o curso! Site da UML: http://www.uml.org/