Engenharia

Nesta seo voc encontra artigos voltados para testes, processo, modelos, documentao, entre outros.

Boas Prticas na Engenharia de Requisitos

De que se trata o artigo?
Este artigo objetiva a apresentao de padres para construo de Documento de Especicao de Requisitos de Software (DERS) e tambm mostrar boas prticas para sua elaborao, de forma a facilitar a comunicao entre os stakeholders.

Nauane Karoline Brazolino Dias

[email protected]

Graduanda do curso de Bacharelado em Sistemas de Informaes pelo Centro de Ensino Superior de Juiz de Fora (CES/JF).Estagiria da Prefeitura de Juiz de Fora e integrante do grupo de pesquisa do projeto Modelagem de Ontologia de Domnio Para Workflow Cientfico.

Marco Antnio Pereira Arajo

[email protected]

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ. Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF. Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora. Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery. Professor do curso de Bacharelado em Cincia da Computao da Faculdade Governador Ozanam Coelho. Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D.Andr Arcoverde. Analista de Sistemas da Prefeitura de Juiz de Fora. Editor da Engenharia de Software Magazine.

om os avanos tecnolgicos que vem ocorrendo nas ltimas dcadas e a visvel diminuio do custo do hardware, a informao passa a ser um recurso estratgico das empresas. O software se tornou, ento, a fora motora desta nova era. A integridade das informaes oferecidas por um software pode diferenciar uma empresa de suas concorrentes. O software capaz de manipular o produto mais importante para uma empresa a informao, e por isso to caro. Para evitar que a parte mais cara dos sistemas computadorizados fosse desenvolvida com baixa qualidade e pouca previsibilidade de custo e recursos, surgiram tcnicas de Engenharia de Software. A Engenharia de Software surgiu com o objetivo de definir e aplicar mtodos que pudessem ajudar no processo de construo, manuteno e implantao de software. A Engenharia de Software pode ser entendida, ento, como a disciplina de

Para que serve?

Obedecendo a padres para desenvolvimento do DERS, esse documento apresentar melhor qualidade, representando, consequentemente, o que os stakeholders esperam do projeto de software que est sendo desenvolvido, tornando possvel que o projeto seja implementado com maior possibilidade de sucesso, abrangendo as necessidades dos usurios.

Em que situao o tema til?

Em projetos de software, a Engenharia de Requisitos normalmente empregada como uma das fases preliminares. atravs da Engenharia de Requisitos que os analistas descobrem as reais necessidades do cliente e transferem-nas para o DERS. Utilizando os padres mostrados neste artigo, possvel criar um DERS com maior qualidade.

engenharia aplicada ao desenvolvimento de software, compreendendo um conjunto de etapas que envolvem mtodos,

14

Engenharia de Software Magazine - Boas Prticas na Engenharia de Requisitos

ENGENHARIA DE RE QUISI TOS

ferramentas e procedimentos que possibilitam o controle do processo de desenvolvimento de software, ocupando-se de todos os aspectos, desde os estgios iniciais de especificao do sistema at a manuteno desse sistema, oferecendo ao profissional uma base para a construo de software de alta qualidade produtivamente. A Engenharia de Requisitos pode ser vista como uma sub-rea da Engenharia de Software, cujo principal objetivo a obteno de uma especificao correta e completa dos requisitos. Este artigo prope apresentar a Engenharia de Requisitos e seu principal produto, o Documento de Especificao de Requisitos de Software (DERS), e mostrar boas prticas para a construo do mesmo.

Suporte: O software certamente ir precisar de modificaes aps ser entregue ao cliente. Essas modificaes podem ocorrer por causa de erros que tenham sido encontrados, novas funcionalidades, melhoria de desempenho ou adaptao de funcionalidades existentes. Neste modelo de Engenharia de Software, a Engenharia de Requisitos encontra-se na primeira fase - a fase de Anlise. Na Figura 2, pode-se ver a representao do processo de Engenharia de Requisitos.

A Engenharia de Requisitos
O principal objetivo da Engenharia de Requisitos criar e manter documentos de requisitos de sistemas, chamado de Documento de Especificao de Requisitos de Software (DERS) [2]. O processo de engenharia de requisitos, como um todo, contm quatro grandes sub-processos que so: em quais aspectos o sistema til ao negcio (estudo de viabilidade), descoberta de requisitos (elicitao e anlise), converso de tais requisitos em um formato padro (especificao) e descoberta se tais requisitos realmente definem o sistema tal como o usurio deseja (validao). Na Figura 1 pode ser visto um processo de Engenharia de Software como um todo, conhecido como Ciclo de Vida Clssico, que tambm pode ser executado vrias vezes como parte integrante de um ciclo de vida iterativo e incremental.

Figura 2. Processo de Engenharia de Requisitos [2]

Figura 1. O processo de Engenharia de Software [3]

Esse modelo representa o processo de Engenharia de Software como um todo e envolve as atividades [3]: Anlise de requisitos do software: nessa fase que a Engenharia de Requisitos aplicada. Os requisitos do sistema so coletados baseados no conhecimento de domnio do software, assim como funes requeridas, comportamento, desempenho e interface. Projeto: projeto de software na verdade um processo de vrios passos que foca em quatro atributos distintos: estrutura de dados, arquitetura do software, representao de interface e detalhes de procedimentos (algortmicos). Codificao: o projeto traduzido em linguagem de mquina atravs de uma linguagem de programao. Testes: Os testes focam em descobrir erros e definir que determinadas entradas iro realmente produzir os resultados esperados.

O processo iterativo, ou seja, pode-se voltar a uma fase que j foi feita, como em uma espiral. As trs fases principais (elicitao, especificao e validao) so divididas em subfases. A elicitao, que responsvel por coletar os requisitos, foi dividida em Elicitao dos Requisitos do Sistema e Elicitao dos Requisitos de Usurio. A fase de especificao foi dividida em Especificao dos Requisitos de Sistema e Modelagem, Especificao dos Requisitos de Usurio e Especificao dos Requisitos de Negcio. E a fase de Validao foi dividida em Estudo de Viabilidade, Prototipao e Revises. Acompanhando a linha de evoluo dos processos de Engenharia de Requisitos, comea-se com a elicitao dos requisitos de usurio e a especificao dos requisitos de negcio para realizar um estudo de viabilidade. Concludo este processo, feita a elicitao dos requisitos do sistema, a especificao dos requisitos do usurio e a especificao dos requisitos de sistema e modelagem. Nesse nterim possvel reavaliar alguma pendncia nos processos feitos anteriormente, visando uma melhoria dos mesmos. O prximo passo a prototipao, que ir mostrar aos stakeholders um primeiro cenrio do software. Em seguida so feitas as revises apuradas na validao feita com os stakeholders. Caso esteja tudo feito de acordo com as pretenses dos interessados no projeto, o Documento de Especificao de Requisitos de Software (DERS) considerado pronto e passa-se para a prxima fase do processo de Engenharia de Software.

Edio 27 - Engenharia de Software Magazine

15

Nem sempre fcil identificar corretamente os requisitos de software, at mesmo devido natureza abstrata prpria de um projeto de software. Porm, se esse processo no for bem feito, o DERS ficar comprometido, inviabilizando toda a fase de projeto, que a fase seguinte fase de Anlise. So muitos os problemas que podem acontecer durante todo o processo de desenvolvimento e implementao de um software, e problemas relacionados base da construo do software, ou seja, os requisitos desse software, podem gerar impactos negativos no final da construo. Requisitos incompletos ou defeituosos podem causar problemas no produto de software final. Muitos projetos tm falhado devido a problemas na elicitao, tais como requisitos incompletos, mal entendidos ou ambguos. Faz-se necessrio ento que esses requisitos sejam bem construdos de maneira que expressem exatamente o que o usurio deseja, da maneira que ele deseja e a forma como poder ser feito. Por isso importante conhecer tcnicas para tornar a construo destes requisitos mais eficaz. Todo o trabalho feito nas fases iniciais de Engenharia de Requisitos (viabilidade, elicitao, anlise e especificao) gera como resultado o DERS. O DERS o documento oficial do que dever ser implementado pelos desenvolvedores do sistema [2].

Figura 3. Estrutura do DERS

O Documento de Especificao de Requisitos de Software

O DERS, segundo o IEEE (Institute of Electrical and Electronics Engineers), deve ser completo e no ambguo, sendo responsvel por auxiliar os clientes de software a descrever com preciso o que eles desejam obter, e desenvolvedores de software a entender exatamente o que o cliente deseja. Ainda segundo o IEEE, para os clientes, desenvolvedores e outros indivduos ligados ao projeto, um bom DERS deve prover diversos benefcios, tais como: Estabelecer a base de acordo entre os clientes e a empresa fornecedora sobre o que o software ir fazer; Reduzir o esforo de desenvolvimento; Prover uma base para estimativas de custo e prazos; Prover uma base para validao e verificao do produto; Facilitar a manuteno do produto de software final. Um DERS conta com alguns padres indicados para sua elaborao. O IEEE elaborou um documento que contm padres e prticas recomendadas para a criao do DERS chamado IEEE Recommended Practice for Software Requirements Specification - Prticas Recomendadas para a Especificao de Requisitos de Software. Segundo essas prticas, o DERS deve ter uma estrutura tal como mostrada na Figura 3. As sees devem, ento, ser preenchidas da seguinte maneira: Propsito (1.1): deve delinear o propsito particular deste DERS e especificar para quem est sendo feito esse documento.

Escopo (1.2): deve especificar o produto software a ser produzido, nomeando-o; explicar o que o produto ir fazer e, se necessrio, o que no ir fazer, descrever as aplicaes do software que est sendo especificado, incluindo benefcios, objetivos e metas relevantes. Definies, siglas e abreviaturas (1.3): deve prover a definio de todos os termos, siglas e abreviaturas que so necessrias para entender este DERS. Referncias (1.4): deve prover uma lista de todos os documentos que forem referenciados em outros locais do DERS, identificando cada um por autor, ttulo, data, editora, organizao, e outros atributos quando aplicveis. Viso Global (1.5): deve apresentar de forma sucinta e resumida o que os captulos restantes do DERS iro tratar. Perspectiva do produto (2.1): deve colocar o produto na perspectiva de outros produtos relacionados. Se um produto independente, isso deve ser dito aqui. Caso contrrio, se um componente de um sistema maior, o que ocorre frequentemente, ento esta subseo deve relatar as interfaces entre esse software e o sistema, alm dos requisitos do sistema maior para a funcionalidade deste software. Funes do produto (2.2): deve prover um ndice das principais funes que o software ir executar. Caractersticas do usurio (2.3): deve descrever as caractersticas gerais dos usurios do produto. Restries (2.4): deve descrever qualquer outro item que limite as opes do produto, tais como polticas de controle, limitaes de hardware, interface com outras aplicaes, controles de segurana, entre outros itens que forem relevantes. Pressupostos e Dependncias (2.5): deve listar todos os fatores que afetem os requisitos definidos. Requisitos Especficos (3): contm a definio dos requisitos de software. o principal captulo do DERS, pois nesta seo que os requisitos funcionais e no funcionais estaro definidos. Esse modelo apresentado o padro que o IEEE indica. Cockburn (2005) apresenta uma complementao a este modelo, onde utiliza um modelo semelhante ao modelo do IEEE, acrescido de um captulo para descrio de casos de uso que implementem os requisitos funcionais especificados.

16

Engenharia de Software Magazine - Boas Prticas na Engenharia de Requisitos

ENGENHARIA DE RE QUISI TOS

Casos de uso representam a interao do sistema com seus usurios e servem como um meio de comunicao entre os envolvidos no projeto e so geralmente descritos em forma textual, embora possam ser descritos de outra maneira, tal como fluxogramas, diagramas, entre outras. Assim, utilizando casos de uso, o usurio rev os diagramas e as especificaes para determinar se o analista realmente capturou os requisitos do sistema. Por este motivo, essencial que os diagramas e as especificaes mostrem ao usurio os aspectos essenciais para que o software seja desenvolvido. Dessa forma, o modelo do IEEE ganha um captulo para facilitar a fase de validao junto aos stakeholders. Ento, com essa proposta, o documento de requisitos utilizado ter o aspecto apresentado na Figura 4.

Figura 5. Custos para Correo de Falhas

Boas Prticas para Construo do DERS

De acordo com o modelo apresentado na Figura 3 (e ampliado na Figura 4), os itens 1 e 2 abordam outros aspectos do software e do projeto de software que no so, por si s, requisitos do software. Esses dois itens devem ser escritos obedecendo as orientaes do IEEE e as especificaes da empresa. O item 3, conforme apresentado na Figura 3, configura-se ento como o captulo mais importante, pois ser atravs deste item que o software ser especificado e com base neste item que o cliente ir validar o produto. Os itens 4 e 5 tambm so importantes, pois so uma maneira de mostrar aos stakeholders a primeira viso do projeto.

Figura 4.

Com este modelo, pretende-se construir um documento completo, que consiga atingir de forma objetiva e completa todos os requisitos do software, alm de utilizar os casos de uso para mostrar ao usurio o software que ser projetado. De acordo com a Figura 4, foram inseridos dois itens, um para os diagramas de caso de uso, que deve seguir o padro da UML (Unified Modeling Language), e o outro com a descrio minuciosa dos casos de uso. Assim, pode-se mostrar aos interessados no projeto mais detalhadamente o que se pretende como intuito de aumentar a acuidade do DERS. Quando um processo de requisitos ineficaz, o DERS no reflete as necessidades reais do cliente, o que gera um software de baixa qualidade. Segundo estudos, de 40% a 60% de todos os problemas encontrados em um projeto de software so causados por falhas no processo de requisitos. Se a fase de engenharia de requisitos for bem feita, esses problemas poderiam ser detectados e corrigidos a um custo muito mais baixo. De acordo com o quadro da Figura 5, o custo para corrigir um defeito na fase de testes supera em mais de 30 vezes o custo para corrigir a mesma falha durante a fase de requisitos. Com essa anlise, podemos facilmente detectar que boas prticas de engenharia de requisitos que procurem evitar a propagao de falhas para outras fases podem trazer benefcios como a reduo de custo do projeto. Entre estas boas prticas esto a padronizao, a inspeo e a reviso do DERS.

Requisitos Especficos
No item de Requisitos Especficos (item 3 conforme modelo apresentado na Figura 4) do DERS devem-se descrever os requisitos de software, que sero funcionais e no-funcionais. Os requisitos funcionais so aqueles que dizem respeito funcionalidade do software, o que ele deve fazer. Esses requisitos descrevem como o sistema deve reagir a particulares entradas e sadas e como deve agir em determinadas situaes. Se necessrio, tambm podem ser includos requisitos que expliquem o que o sistema no ser capaz de fazer. Os requisitos no-funcionais so restries aos servios e funes oferecidos pelo sistema. Geralmente se aplicam ao sistema como um todo e no so, geralmente, aplicados individualmente a uma caracterstica ou servio do sistema. Entre esses requisitos se encontram, por exemplo, os requisitos de desempenho, de segurana, de entrada e sada, entre outros. Descrever bem estes requisitos fundamental para que o DERS se torne um bom DERS, pois sero estes os requisitos implementados pelos casos de uso que sero diagramados e desenhados nos diagramas e especificaes dos casos de uso (itens 4 e 5 conforme modelo apresentado na Figura 4). Entretanto, nem sempre fcil descrever tais requisitos e sua forma depende muito do software que est sendo descrito [2]. difcil ento escolher um padro geral para criao destes requisitos.

Edio 27 - Engenharia de Software Magazine

17

Porm, apesar das diferenas entre cada projeto de software, que iro gerar requisitos muito diferentes em cada DERS, o IEEE apresenta algumas caractersticas que devem ser comuns a todos os requisitos. O IEEE recomenda que um requisito deve ser correto, no ambguo, completo, consistente, verificvel, modificvel e rastrevel. Ainda recomendvel que os requisitos sejam organizados de forma a facilitar a leitura do documento. Isso pode ser feito agrupando requisitos que tenham alguma funcionalidade em comum.

Diagrama de Casos de Uso

O diagrama de casos de uso deve mostrar, graficamente, todas as funes que um sistema precisar desempenhar e, para sua construo, deve obedecer aos padres da UML. De maneira geral, os casos de uso devero ter a mesma nomenclatura das funes listadas no item 2.2 do modelo proposto (Figura 4). Esta prtica recomendada de forma a gerar um documento sem ambiguidades e que ser mais facilmente lido pelo usurio. Cada categoria de usurio do sistema, desde que tenha um nvel de acesso diferente, deve ser representada por um ator que ir ter acesso s funes do sistema representadas pelos casos de uso. Cada um desses casos de uso ser descrito no item 5 da especificao.

Descrio dos Casos de Uso

Os casos de uso so muito indicados para o DERS porque rapidamente se aprende a ler um caso de uso. Os casos de uso so [...] populares porque contam uma histria coerente de como o sistema ir se comportar em uso. Os usurios do sistema conseguem ver o que este novo sistema ser [2]. Com um caso de uso bem feito, possvel mostrar aos usurios o que o sistema se prope a fazer e validar com o usurio se esta perspectiva est correta. Um caso de uso escrito em linguagem natural e constitudo por uma sequncia de sentenas. Estes passos so compostos por aes simples, que descrevem o ator realizando uma tarefa ou passando informao para um outro ator. Um caso de uso tem normalmente, ao menos, dois finais possveis, um de sucesso e outro de erro. Um caso de uso sempre ser responsvel por implementar, pelo menos, um requisito funcional do sistema. Todos os requisitos funcionais do sistema devem estar ligados a um ou mais casos de uso. Essas ligaes entre casos de uso e requisitos necessria para permitir a rastreabilidade dos requisitos. Uma vez que um requisito mude, possvel, atravs dos casos de uso aos quais ele est ligado, ver qual o impacto da mudana e aplic-la a todo o documento, mantendo-o ntegro. Um caso de uso pode especificar objetivo, requisitos implementados, atores, prioridade, pr-condies, frequncia de uso, ps-condies, fluxo principal, fluxos alternativos, fluxos de exceo, validaes, regras de negcio e prottipo de interfaces. Algumas dessas informaes podem ser suprimidas e consideradas opcionais, dependendo do sistema que est sendo especificado.

O objetivo de um Caso de Uso (UC Use Case) deve descrever para que serve esse UC em poucas palavras. Os requisitos implementados representam a ligao dos requisitos especificados no item de Requisitos Especficos (item 3) com o UC que est sendo descrito. Os atores so os usurios especficos do UC e deve ser um dos usurios do sistema. A prioridade de um UC normalmente descrita como Alta, Mdia ou Baixa, assim como a frequncia de uso, e essas duas informaes sero importantes no momento de desenvolvimento do software, caso seja necessrio priorizar o desenvolvimento de parte do software. As pr-condies dizem respeito s condies que devero ser respeitadas antes do incio do caso de uso, ou seja, como o caso de uso no ser chamado caso esta restrio no seja cumprida, essas condies no iro gerar fluxo de exceo e no precisaro de validao. Mas importante tomar cuidado, uma condio que nem sempre verdadeira no pode ser classificada como uma pr-condio. Caso uma condio seja verdadeira com algumas ressalvas deve-se criar uma validao referente a isto e gerar fluxos de exceo, e no apont-la como uma pr-condio. A ps-condio descreve em que o caso de uso modificou o sistema. Os fluxos so a parte principal do caso de uso. Um caso de uso deve conter todos os cenrios, tanto de sucesso quanto de falha. A melhor maneira de organizar o texto escrever o cenrio de sucesso principal, ou fluxo principal, como uma sequncia numerada simples de passos que executada do acionamento at a concluso. Depois disso, devem-se descrever os outros cenrios, sendo os cenrios de sucesso alternativos, chamados de fluxos alternativos, e os cenrios de falha, chamado de fluxos de exceo. Algumas boas prticas para escrever um caso de uso de forma eficaz so [2]: Utilizar gramtica simples: o principal objetivo do UC mostrar, de forma clara, o que o sistema faz. Se um texto complexo for escrito para descrever esse UC, o seu entendimento ser prejudicado. Mostrar claramente quem so os atores: mostrando claramente quais so os atores do UC, fica mais fcil para os stakeholders compreenderem o UC e as suas funes. Incluir todas as aes: na descrio do UC no adianta apenas colocar a descrio de sucesso do mesmo. preciso colocar todas as aes, de sucesso e de falha. Todas as aes que puderem ser tomadas pelos atores podero gerar caminhos alternativos, e esses devem ser descritos. Validar (nunca verificar): o termo validar prefervel ao termo verificar, pois deixa claro que o sistema ir validar os dados inseridos de acordo com as regras de negcio e restries para os valores. Mencionar o tempo apenas opcionalmente: no obrigatrio mencionar o tempo, pois fica implcito que um passo ocorre logo aps o anterior. Os erros mais comuns so estender desnecessariamente os casos de uso e descrever com uma preciso desnecessria, omitir o sujeito das sentenas (omitindo tambm o ator), fazer

18

Engenharia de Software Magazine - Boas Prticas na Engenharia de Requisitos

ENGENHARIA DE RE QUISI TOS

suposies sobre o projeto de interface com o usurio e usar nveis de objetivos que so muito baixos. Ou seja, ser muito especfico ruim, pois tende a aumentar desnecessariamente a complexidade do projeto, entretanto, tambm no se deve ser objetivo demais, omitindo pontos importantes do caso de uso. Cockburn (2005) diz que h apenas um formato de sentena usado na escrita de passo de ao no caso de uso: uma sentena no presente, com verbo ativo na voz ativa, descrevendo um ator alcanando com sucesso um objetivo que move o processo adiante. Um bom exemplo disso : O ator seleciona a opo Incluir Cliente.

Figura 6. Exemplo de Requisitos Funcionais

A Inspeo do DERS
A inspeo do DERS muito importante para o sucesso do DERS e deve avaliar o documento como um todo em busca de defeitos antes da validao junto ao cliente e usurios. Os erros encontrados em um DERS podem ser: Omisso: todo erro relativo a alguma informao que no foi descrita, ou seja, que no est presente no DERS. Pode ser algum requisito que no foi includo, falta de resposta do sistema a alguma situao, falta da definio de termos, entre outras omisses. Ambiguidade: ocorre sempre que alguma informao estiver descrita de forma a poder causa confuso ou dvida. Inconsistncia: alguma sentena que contradiz algo que foi dito anteriormente no documento. Fato Incorreto: quando um fato descrito no DERS no verdadeiro ou no pode ser executado, de acordo com as condies especificadas no domnio da aplicao. Informao Estranha: so as informaes que no pertencem ao DERS, no sendo necessrias para o entendimento do mesmo. Esse problema tambm contempla as informaes que so passadas, mas no so utilizadas em nenhum momento no DERS. altamente recomendvel que a inspeo do DERS seja feita por um outro profissional, que no o responsvel por criar o DERS.

Figura 7.

Aps elicitar os requisitos, especific-los e criar um diagrama de casos de uso que o implemente, necessrio descrever o caso de uso conforme pode ser observado na Figura 8.

Estudo de Caso
Com base na estrutura apresentada, apresentaremos a partir de agora um estudo de caso.

Construo do DERS
O primeiro passo descrever todos os requisitos do sistema, que devem ser elicitados com os stakeholders. Levando em conta que neste estudo de caso deseja-se apenas realizar o login, ento se devem descrever apenas os requisitos diretamente ligados a esta funcionalidade. Ao conversar com os stakeholders do projeto, o seguinte cenrio foi obtido (Figura 6). Nota-se que apenas um requisito foi levantado. Tendo os requisitos especificados, deve-se construir o diagrama de casos de uso que ir implementar estes requisitos antes da descrio de tais casos de uso. Levando-se em conta o requisito apurado, o diagrama da Figura 7 o suficiente para implement-lo.

Figura 8.

Com base nas prerrogativas e modelo mostrados anteriormente, construiu-se a descrio acima. Pode-se visualizar um quadro com as informaes bsicas descritas. H ainda a descrio dos campos do formulrio Login, que parte deste caso de uso, e o Fluxo Principal que so as aes do ator dentro do caso de uso.

Inspeo do DERS
A inspeo do DERS, como dito anteriormente, deve ser feita por outros membros da equipe, que no aquele que foi

Edio 27 - Engenharia de Software Magazine

19

responsvel por sua criao. Esta pessoa ter maior facilidade em encontrar os defeitos do documento, pois ter que entender o documento com sua leitura, e atravs deste exerccio poder conseguir encontrar defeitos. Os defeitos de um DERS o tornam de difcil compreenso. Ao ler o fragmento de DERS apresentado, percebe-se que no h fluxos alternativos, mostrando os caminhos alternativos de sucesso e de falha. A Figura 9 mostra os possveis caminhos alternativos que deveriam estar no documento.

Figura 9. Exemplo de Caminhos Alternativos

O Fluxo Principal tambm deve ser alterado para indicar em que momento ocorrem os fluxos alternativos. O Fluxo Alternativo [A1], por exemplo, ocorre no passo 3 do Fluxo Principal, pois o ator, ao invs de escolher a opo Login, escolhe a opo Cancelar. O mesmo vale para o [A2]. J os Fluxos de Exceo normalmente ocorrem no passo que contiver o termo validar. Neste exemplo, os Fluxos de Exceo [E1] e [E2] ocorrero no passo 4. O Fluxo Principal ficar como mostrado na Figura 10.

Figura 10. Alternativos

Uma leitura minuciosa e detalhista importante para detectar todos os eventuais defeitos que possam existir no DERS. Consultando a Figura 7, pode-se notar que o caso de uso foi denominado Entrar no Sistema, enquanto na descrio do mesmo (Figura 8), percebe-se que o termo utilizado foi Realizar login. Este , geralmente, um dos defeitos mais comuns em um DERS, tratando-se de uma inconsistncia. Quando se trata de um sistema pequeno como o descrito neste exemplo, fcil perceber que o caso de uso do diagrama o caso de uso que est sendo descrito. Porm, este problema torna-se ainda mais grave quando pensado em um sistema maior. A terminologia empregada deve obedecer a um padro. Neste caso, deve-se escolher apenas um dos dois termos e utiliz-

los ao longo de todo o DERS para descrever o caso de uso. Pode-se mudar no diagrama ou na descrio, mas os dois tm que ter a mesma nomenclatura. Outro tipo de defeito ambiguidade pode ser notado durante a descrio do caso de uso. Na descrio dos campos est escrito que existe um campo Nome, porm ao visualizar o prottipo da tela, percebe-se a existncia de um campo Usurio, e nenhum campo Nome. Esses termos tambm no podem diferir, pois atrapalham o entendimento do DERS. A mesma coisa para a opo Entrar descrita na seo Campos, que chamada Opo Login na seo Fluxo Principal, e desenhada como um boto Login no formulrio. A diversidade de vocabulrio pode ser uma fonte de inconsistncias no documento, gerando ambiguidade. Um s termo utilizado para denominar diversos elementos, ou vrios termos para determinar uma mesma situao, pode gerar interpretaes errneas. Outro erro incomum o de Omisso. Observa-se na Figura 8 que no existe uma opo para recuperao de senha. Essa opo comum a formulrios de login, pois o usurio pode eventualmente esquecer sua senha e o sistema deve prover uma maneira de recuper-la. Mesmo sabendo-se que necessrio um ponto para recuperao de senha, o Fluxo Alternativo [A2] pode ser visto como uma Informao Inconsistente, pois com base no presente documento, no pode ser executada. Analisando o prottipo de tela proposto, ainda possvel encontrar um outro defeito, que pode ser categorizado com um Fato Estranho. Nota-se que o formulrio tem trs botes, sendo que apenas dois dos quais esto sendo utilizados e descritos pelo caso de uso. O terceiro boto Fechar parece ser um boto que est sobrando e, por isso, configura-se como um defeito. Ainda possvel encontrar outros defeitos com uma leitura atenciosa. Por exemplo, quais so os nveis de acesso? Esse um defeito de omisso. Pode ser que, ao completar o DERS, essa definio fosse feita, mas nesse momento ela no existe. sempre importante delimitar o software, de forma que no sejam encontradas omisses ou ambiguidades. Um documento ntegro muito importante para a construo de um bom software. Categorizar defeitos um processo um pouco subjetivo e depende da interpretao do inspetor do documento. Por isso importante fazer uma leitura minuciosa e atenta, marcando os defeitos encontrados e justificando-os, para que posteriormente o DERS possa ser revisado pelo seu construtor.

Consideraes Finais
A Engenharia de Requisitos tem como um de seus objetivos a criao do Documento de Especificao de Requisitos de Software (DERS). O DERS construdo com o intuito de conseguir descrever o que o usurio deseja antes de comear a implementar o projeto. Quando um DERS bem construdo, atravs de sua avaliao junto aos stakeholders do projeto, possvel descobrir se

20

Engenharia de Software Magazine - Boas Prticas na Engenharia de Requisitos

ENGENHARIA DE RE QUISI TOS

www.devmedia.com.br/esmag/feedback

Edio 27 - Engenharia de Software Magazine

21

edio ta

os interesses dos mesmos foram corretamente entendidos, fazendo as necessrias correes a um custo muito inferior se comparado a custos em outras etapas do projeto. Criar um bom DERS nem sempre fcil, mas seguindo algumas diretrizes, como as do IEEE, pode-se criar um DERS consistente e completo. Adicionando casos de uso ao DERS ainda possvel chegar mais prximo aos stakeholders, pois trata-se de uma linguagem de entendimento mais fcil. Algumas boas prticas facilitam a criao de um caso de uso eficaz, que ser capaz de fornecer aos interessados no projeto todas as informaes que estes precisam, de maneira objetiva e completa. Com um DERS completo, no ambguo e objetivo, um projeto tem maiores chances de chegar ao resultado esperado pelos stakeholders, ou seja, ter sucesso.

Referncias Bibliogrficas COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes. Bookman, Porto Alegre: 2005. SOMMERVILLE, Ian. Software Engineering 8th. 8 ed. Pearson: Essex, England: 2007. PRESSMAN, Roger S. Software Engineering - A Practitioners Approach. 5 ed. Mc Graw Hill: Boston, Estados Unidos: 2001.

D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
D s

Feedback eu
sobre e s