escola superior aberta do brasil - esab curso de … · direcionado para requisitos funcionais. o...

ESCOLA SUPERIOR ABERTA DO BRASIL - ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM

ENGENHARIA DE SISTEMAS

DAMIÃO GONÇALVES DOS SANTOS FILHO

MODELAGEM DE REQUISITOS FUNCIONAIS MEDIANTE

ESPECIFICAÇÃO DE CASOS DE USO

SÃO PAULO – SP

2012




Monografia apresentada ao Curso de Pós-Graduação em Engenharia de Sistemas da Escola Superior Aberta do Brasil como requisito para obtenção do título de Especialista em Engenharia de Sistemas, sob orientação do Prof. Marcelo Albuquerque Schuster.

SÃO PAULO – SP

2012




Monografia aprovada em ... de ... de 2012.

Banca Examinadora

_____________________________

_____________________________

_____________________________

SÃO PAULO – SP

2012

RESUMO

Palavras-chave: Requisitos; Funcionais; Casos de Uso. O presente trabalho aborda o tema Modelagem de Requisitos Funcionais, mediante especificação de casos de uso. A pesquisa é do tipo exploratório-descritiva, sendo observados conceitos oriundos da literatura especializadas na área de Engenharia de Requisitos e UML. O objetivo principal do trabalho é analisar o processo de modelagem de requisitos funcionais, utilizando casos de uso. O trabalho é composto por três capítulos. O primeiro mostra conceitos básicos da Engenharia de Requisitos, envolvendo: definição de requisitos, entendimento de sua importância e visão a respeito dos tipos de requisitos existentes. O estudo é direcionado para requisitos funcionais. O segundo analisa quais são os processos típicos da definição de requisitos, sendo o estudo direcionado para as atividades de levantamento, análise, especificação, validação e gestão de requisitos. O terceiro e último capítulo avalia os elementos necessários para a elaboração do documento de especificação de casos de uso e do diagrama de casos de uso, sendo os conceitos aplicados, de forma prática, na modelagem de requisitos de um sistema típico da área de vendas on-line. Este trabalho revela a importância dos requisitos para o sucesso dos projetos de software, sendo a modelagem dos requisitos funcionais, através de casos de uso, uma alternativa interessante e viável, pois possibilita a aplicação dos conceitos da engenharia de requisitos de forma prática e consistente.

LISTA DE TABELAS (ou QUADROS, GRÁFICOS, FIGURAS e SIGLAS)

Tabela 1 – Projetos de softwares concluídos dentro do prazo, orçamento e

requisitos previstos.................................................................................................. 09

Gráfico 1 - Projetos de softwares concluídos dentro do prazo, orçamento e

requisitos previstos.................................................................................................. 10

Tabela 2 – Opinião de gerentes de TI sobre principais causas de fracasso dos

projetos.................................................................................................................... 11

Quadro 1 – Capítulos de um documento de requisitos............................................ 23

Quadro 2 – Passos do processo de gerenciamento de mudanças nos

requisitos.................................................................................................................. 28

Template 1 – Modelo para o documento de especificação de casos de uso.......... 31

Especificação de Caso de Uso 1 – Valida Usuário.................................................. 34

Quadro 3 – Categorias de atores............................................................................. 36

Especificação de Caso de Uso 2 – Efetua Pedido pela Internet.............................. 38

Especificação de Caso de Uso 3 – Consulta Pedidos pela Internet 41

Especificação de Caso de Uso 4 – Informa Dados do Pedido................................ 43

Quadro 4 - Notações utilizadas para representar elementos do Diagrama de

Casos de uso........................................................................................................... 46

Quadro 5 – Atores do sistema de vendas on-line.................................................... 49

Quadro 6 – Resumo dos casos de uso do sistema de vendas on-line.................... 49

Diagrama 1 – Diagrama de casos de uso do sistema de vendas on-line................ 50

SUMÁRIO

INTRODUÇÃO........................................................................................................06

CAPÍTULO 1 - CONCEITOS BÁSICOS DA ENGENHARIA DE REQ UISITOS... 08

1.1 O QUE SÃO REQUISITOS......................................................................... 08

1.2 A IMPORTÂNCIA DOS REQUISITOS....................................................... 08

1.3 TIPOS DE REQUISITOS............................................................................ 11

1.3.1 Requisitos Funcionais ............................................................................. 11

1.3.2 Requisitos Não Funcionais ..................................................................... 13

CAPÍTULO 2 – PROCESSOS UTILIZADOS NA DEFINIÇÃO DE R EQUISITOS 15

2.1 LEVANTAMENTO DE REQUISITOS......................................................... 15

2.1.1 Selecionar as Fontes dos Requisitos ..................................................... 16

2.1.2 Definir o Escopo do Sistema ................................................................... 17

2.1.3 Coletar os Requisitos ............................................................................... 18

2.2 ANÁLISE DE REQUISITOS....................................................................... 20

2.3 ESPECIFICAÇÃO DE REQUISITOS..........................................................22

2.4 VALIDAÇÃO DE REQUISITOS.................................................................. 25

2.5 GESTÃO DE REQUISITOS........................................................................ 27

CAPÍTULO 3 - CASOS DE USO E REQUISITOS FUNCIONAIS 3 0

3.1 CENÁRIOS................................................................................................. 33

3.2 ATORES..................................................................................................... 35

3.3 RELACIONAMENTO ENTRE CASOS DE USO........................................ 37

3.3.1 Relacionamento de Comunicação .......................................................... 37

3.3.2 Relacionamento de Inclusão ................................................................... 38

3.3.3 Relacionamento de Extensão .................................................................. 40

3.3.4 Relacionamento de Generalização ......................................................... 44

3.4 DIAGRAMA DE CASOS DE USO.............................................................. 46

CONCLUSÃO ........................................................................................................ 51

REFERÊNCIAS...................................................................................................... 53

6

INTRODUÇÃO

O tema abordado nesta pesquisa, modelagem de requisitos funcionais mediante

especificação de casos de uso, é de extrema relevância no cenário atual de

desenvolvimento de softwares. As empresas investem muito tempo e dinheiro no

desenvolvimento de sistemas e são cada vez mais dependentes deles para o

exercício de suas atividades. Neste contexto, as empresas não querem correr o

risco de solicitar o desenvolvimento de um sistema sem conhecer previamente as

funcionalidades que este sistema terá e se de fato atenderá suas necessidades,

levando-se em consideração restrições tecnológicas, de tempo e custo. Caberá,

portanto, à equipe de desenvolvimento, a tarefa de apresentar os requisitos

funcionais, através de um modelo de casos de uso, fornecendo assim uma visão das

funcionalidades que o sistema disponibilizará aos usuários. Este modelo servirá

como uma espécie de contrato entre a equipe de desenvolvimento e a empresa

solicitante, uma vez que o sistema deverá estar de acordo com o que foi definido no

modelo. Surge então a questão, que é o problema desta pesquisa: como modelar

requisitos funcionais utilizando casos de uso? Para responder a esta pergunta, a

proposta deste trabalho, como objetivo geral, é analisar o processo de modelagem

de requisitos funcionais utilizando casos de uso e, como objetivos específicos:

estudar os conceitos básicos da engenharia de requisitos, através da definição de

requisitos, entendimento de sua importância e compreensão dos tipos de requisitos

existentes, sendo o estudo direcionado para os requisitos funcionais; compreender

quais os processos típicos da definição de Requisitos, através do estudo das

atividades de levantamento, análise, especificação, validação e gestão de requisitos;

estudar a modelagem de requisitos funcionais, utilizando casos de uso,

compreendendo os conceitos de modelagem de casos de uso e aplicando estes

conceitos através do estudo das funcionalidades de um sistema típico da área de

vendas on-line.

A pesquisa será do tipo Exploratório-descritiva. A contribuição deste trabalho será

criar um template para especificação de casos de uso e aplicar este template na

modelagem das funcionalidades básicas de um sistema típico da área de vendas on-

line, fornecendo assim um modelo de boas práticas na área de engenharia de

7

requisitos. Isto será possível a partir da observação de conceitos levantados em

literatura especializada, na área de Engenharia de Software e UML, e de

informações observadas em sistemas típicos na área de vendas on-line.

8

CAPÍTULO 1 - CONCEITOS BÁSICOS DA ENGENHARIA DE

REQUISITOS

1.1 - O QUE SÃO REQUISITOS

Requisitos são “...capacidades e condições às quais o sistema – e em termos mais

amplos, o projeto – deve atender. ” (LARMAN, 2004, p. 63), representam então, de

forma documental, uma especificação do que será feito pelo sistema, sendo utilizado

em todas as fases do projeto.

Segundo Sommerville (2003, p. 82) “As descrições das funções e das restrições são

os requisitos para o sistema; e o processo de descobrir, analisar, documentar e

verificar essas funções e restrições é chamado de engenharia de requisitos.”

Existe, portanto, uma disciplina da engenharia de software que trata especificamente

de requisitos, a engenharia de requisitos. Esta disciplina estabelece a

fundamentação necessária, para descrever, através de requisitos, o que o sistema

deve fazer e não o como deve fazer. Outras disciplinas da Engenharia de Software

tratarão do como, mas é fundamental estabelecer a visão do que deve ser feito,

antes do início de outras fases do projeto.

Isto implica dizer que não se deve especificar requisitos partindo do ponto de vista

da implementação da solução do problema, mas sim a partir do ponto de vista do

usuário. O sistema tem como objetivo básico atender as necessidades do usuário. É

importante, portanto, descobrir o que o usuário realmente deseja e o que

efetivamente pode ser feito para atendê-lo, levando-se em conta restrições

tecnológicas, de tempo e custo.

1.2 - A IMPORTÂNCIA DOS REQUISITOS

De acordo com Sommerville (2003) os requisitos podem ser considerados como um

contrato entre o cliente e o desenvolvedor do software.

De forma geral podemos definir a importância dos requisitos, conforme itens a

seguir:

9

• São insumos básicos para mensuração do tamanho e custo do sistema;

• São utilizados por analistas e desenvolvedores porque definem o que é esperado

do sistema.

• Possibilitam ao cliente, durante as fases do desenvolvimento, avaliar se o

sistema está sendo desenvolvido de acordo com as funcionalidades previamente

definidas e detalhadas.

• São insumos básicos para que sejam efetuados testes finais, homologação e

liberação do sistema para implantação em produção.

• Auxiliam na elaboração de documentação do sistema.

• São fundamentais para a manutenção do sistema durante todo o seu ciclo de

vida.

Sem dúvida alguma é possível afirmar que requisitos são importantes para o

sucesso dos projetos de software. Neste contexto, entretanto, podemos levantar

duas questões relevantes, a primeira: os projetos de software são, em sua maioria,

bem sucedidos? A segunda: qual a principal causa das falhas nos projetos de

software?

1 ª Questão: Os projetos de software são, em sua maioria, bem sucedidos?

Infelizmente, a resposta a esta questão é não. Em um artigo publicado na internet,

Dominguez (2009), cita dados do Standish Group, entidade que realiza pesquisa na

área de projetos de software, conforme tabela abaixo:

Tabela 1 – Projetos de softwares concluídos dentro do prazo, orçamento e requisitos previstos

1994 1996 1998 2000 2002 2004 2006 2009 Sucesso 16% 27% 26% 28% 34% 29% 35% 32% Problemático 53% 33% 46% 49% 51% 53% 46% 44% Fracassado 31% 40% 28% 23% 15% 18% 19% 24%

Fonte: Dominguez (2010)

Conforme relatório do Standish Group, Standish (1995, p. 2. Tradução Google

Tradutor /Tradução nossa), entendemos as três classificações de projetos,

mencionadas na tabela acima, como:

Successful – “... sucesso do projeto: O projeto é concluído dentro do prazo e do orçamento, com todas as características e funções, conforme a especificação inicial.” Challenged - “... projeto problemático: O projeto está concluído e operacional, mas estoura o orçamento, está acima do prazo estimado e oferece menos recursos e funções que as originalmente especificadas.”

10

Failed - “... projeto fracassado: O projeto é cancelado em algum momento durante o ciclo de desenvolvimento.”

Para melhor visualização e análise dos dados, foi elaborado o gráfico abaixo:

16

2726

28

34

29

35

32

53

33

46

4951

53

4644

31

40

28

23

15

1819

24

0

10

20

30

40

50

60

1994 1996 1998 2000 2002 2004 2006 2009

em %

Sucesso Problemático Fracassado

Gráfico 1 - Projetos de softwares concluídos dentro do prazo, orçamento e requisitos previstos Fonte: Elaboração própria (2012)

Analisando os dados do gráfico, chega-se às seguintes conclusões:

• O percentual de projetos bem sucedidos apresentou uma evolução no período de

1994 a 2009, sofrendo declínio em alguns anos, mas em geral apresentando

uma trajetória ascendente. Entretanto, é um percentual bem menor, comparando

à soma dos projetos problemáticos e fracassados.

• O percentual de projetos problemáticos oscilou bastante, está mais baixo em

2009, mas ainda chegando próximo da casa dos 50%. Significa dizer que quase

metade dos projetos são entregues acima do orçamento, fora do prazo e com um

número de funcionalidades menor do que as solicitadas.

• Quanto aos projetos fracassados, verificamos o menor percentual em 2002, mas

nos anos seguintes passou por sucessivas evoluções, o que é preocupante,

porque revela o nível crescente de risco no desenvolvimento de projetos de

software.

2ª Questão: Qual a principal causa das falhas nos projetos de software?

11

O relatório do Standish Group do ano de 1995, Standish (1995, p. 2. Tradução

Google Tradutor /Tradução nossa), conhecido como The Chaos Report, também

revela a preocupação da entidade em descobrir as principais causas de fracasso

dos projetos, ou seja, os que são cancelados em algum momento durante ciclo de

desenvolvimento.

Ao pesquisar a opinião de gerentes de TI sobre esta questão, Standish (1995)

revela que requisitos incompletos é o motivo que está no topo da lista, conforme

tabela abaixo:

Tabela 2 – Opinião de gerentes de TI sobre principais causas de fracasso dos projetos

Fatores para o fracasso dos projetos % de Respostas 1. Requisitos incompletos 13,1 2. Falta de envolvimento do usuário 12,4 3. Falta de recursos 10,6 4. Expectativas irreais 9,9 5. Falta de apoio executivo 9,3 6. Mudanças nos requisitos e especificações 8,7 7. Falta de planejamento 8,1 8. O sistema não era mais necessário 7,5 9. Falta de Gerenciamento 6,2 10. Analfabetismo Tecnologia 4,3 Outros 9,9

Fonte: Standish (1995)

Avaliando os dados, percebe-se a importância dos requisitos. Eles podem ser

fatores importantes tanto para o sucesso quanto para o fracasso dos projetos de

desenvolvimento de software.

1.3 - TIPOS DE REQUISITOS

Os requisitos costumam ser classificados como funcionais ou não funcionais. Esta

classificação é útil para nos auxiliar a identificar e descrever, de forma adequada, as

diferentes funcionalidades que compõem um sistema.

1.3.1 Requisitos Funcionais

12

Os requisitos funcionais descrevem a funcionalidades esperadas do software.

Representam, portanto, as funções a serem executadas pelo sistema, de forma a

atender as necessidades do usuário.

Para Sommerville (2003, p. 83),

Requisitos funcionais são declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer.

Em linhas gerais os requisitos funcionais demonstram o comportamento do sistema

em relação a entradas específicas, estabelecendo os cenários possíveis para

tratamento destas entradas, as regras de negócios exigidas e determinado as saídas

necessárias para atender as solicitações do usuário.

Segundo Pfleeger (2004, p. 115),

As questões trazidas pelos requisitos funcionais têm respostas que são independentes da implementação de uma solução para o problema do cliente. Descrevemos o que o sistema fará, sem discutir sobre que computador específico e linguagem de programação serão utilizados, as estruturas de dados internas envolvidas...

Esta abordagem, mencionada por Pfleeger, confere aos requisitos uma total

independência da solução a ser implementada.

O importante é definir o que o sistema fará, ou seja, o foco está na necessidade ou

problema do usuário e não na solução tecnológica a ser adotada.

Quando o requisito é elaborado do ponto de vista do desenvolvedor e não do

usuário, o foco passa a ser o como a solução será implementada. Passa-se a utilizar

termos técnicos de implementação, muitas vezes já imaginando como a solução

será desenvolvida. Neste caso, o requisito funcional deixa de ser legível para o

usuário e corre o sério risco de não atender as suas expectativas e reais

necessidades.

Ocorre, portanto, um avanço para etapa seguinte no fluxo de desenvolvimento,

porque o desenvolvedor parte do pressuposto que entendeu bem a necessidade do

usuário, sem contudo especificá-la adequadamente, através do uso correto do

requisito funcional.

Se o desenvolvedor entendeu bem a necessidade do usuário e especificou

adequadamente, através do requisito funcional, então, não ficará preso a uma

determinada plataforma tecnológica e poderá focar o desenvolvimento no que

realmente interessa, a necessidade ou problema do usuário.

13

1.3.2 Requisitos Não Funcionais

Requisitos não funcionais, segundo Sommerville (2003, p. 83), “... São restrições

sobre os serviços ou as funções oferecidos pelo sistema. Entre eles destacam-se

restrições de tempo, restrições sobre o processo de desenvolvimento, padrões,

entre outros.”

Enquanto os requisitos funcionais tratam das funcionalidades do sistema, de forma

particionada, os requisitos não funcionais envolvem as características globais do

software.

Para Sommerville (2003), os requisitos não funcionais são mais importantes do que

os funcionais, porque, em geral, o não cumprimento de um requisito não funcional

pode inviabilizar o sistema como um todo, enquanto a falta em cumprir um requisito

funcional pode degradar o sistema, mas não torná-lo inútil.

É comum a classificação dos requisitos não funcionais utilizando-se a sigla URPS+.

Esta sigla envolve as seguintes definições:

• Usabilidade: Esta categoria envolve a facilidade de utilização do sistema, tempo

esperado para que os usuários sejam treinados, tempo de duração para

determinadas operações do sistema, ou padrões de usabilidade com as quais o

sistema deve estar aderente.

• Confiabilidade: Envolve questões relacionadas à disponibilidade do sistema,

intervalo entre falhas, tempo de indisponibilidade após a ocorrência de falha do

sistema, precisão para determinada saída do sistema, número máximo de

defeitos.

• Performance ou desempenho: Tempo de resposta para uma transação,

throughput (ex.: transações por segundo), capacidade (número de usuários ou

transações concorrentes), operação parcial, quando o sistema estiver com

alguma instabilidade, uso de recursos como memória, espaço em disco, etc.

• Suportabilidade: Padrões de codificação, convenções de nomenclatura,

bibliotecas de classes e utilitários de manutenção.

• Outros: Design, desenvolvimento, interface, físicos.

14

Como parte dos objetivos específicos deste trabalho consiste em aplicar os

conceitos adquiridos na modelagem das funcionalidades básicas de um sistema

típico da área de vendas on-line, identificam-se abaixo alguns requisitos não

funcionais para um sistema desta área:

• Apenas usuários autorizados podem acessar o aplicativo;

• O sistema deve ser desenvolvido em, no máximo 5 meses;

• O sistema deverá ser Web;

• A interface com o usuário deverá ser simples e com boa usabilidade;

• O processo de inclusão de um pedido não poderá demorar mais que 5 minutos.

15

CAPÍTULO 2 – PROCESSOS UTILIZADOS NA DEFINIÇÃO DE

REQUISITOS

2.1 - LEVANTAMENTO DE REQUISITOS

Uma das tarefas mais complexas na engenharia de software é realizar, de forma

eficaz e eficiente o levantamento dos requisitos. Segundo Pressman (2006, p. 116),

Entender os requisitos de um problema está entre as tarefas mais difíceis enfrentadas por um engenheiro de software. Quando você começa a pensar sobre isso, a engenharia de requisitos não parece tão difícil. Afinal de contas, o cliente não sabe o que é necessário? Os usuários finais não deveriam ter um bom entendimento das características e funções que vão oferecer benefícios? Surpreendentemente, em muitos casos, a resposta a estas perguntas é não. E mesmo que clientes e usuários finais sejam explícitos quanto às suas necessidades, essas vão se modificar ao longo do projeto. A engenharia de requisitos é difícil.

Entender as dificuldades inerentes ao processo de levantamento de requisitos, não

deve nos levar a uma atitude pessimista quanto ao sucesso do projeto. Reconhecer

as dificuldades nos estimula a encará-las com mais seriedade e a envidar os

esforços necessários para minimizar riscos e maximizar ganhos, oriundos de

requisitos bem elaborados, completos, precisos e consistentes.

Pode-se definir a tarefa de levantamento de requisitos como a elaboração de uma

lista de objetivos ou funcionalidades do sistema. É imprescindível identificar o

escopo do sistema, sua importância para o negócio da empresa e como será a sua

utilização.

Neste processo, a equipe técnica de desenvolvimento, trabalha junto aos

stakeholders, pois são eles que detêm informações importantes sobre o negócio,

são os responsáveis pelas demandas as quais o sistema se propõe a atender e se

constituem no objetivo maior da aplicação.

O sucesso do projeto, portanto, está diretamente relacionado à satisfação final dos

stakeholders. Sommerville (2003, p. 104 e 105) define stakeholders como “...

qualquer pessoa quer terá alguma influência direta ou indireta sobre os requisitos do

sistema. Dentre os stakeholders destacam-se os usuários finais que interagirão com

o sistema e todo o pessoal, em uma organização, que venha a ser por ele afetado.”

O levantamento de requisitos envolve, portanto, usuários finais, gerentes e, pessoas

que conhecem os processos pertinentes ao negócio, dentre outros.

16

Segundo Sommerville (2003) os stakeholders:

• Não têm uma idéia clara do que desejam, nem dos custos de suas solicitações;

• Expressam os requisitos com o conhecimento implícito da sua área,

conhecimento este que ainda não é inteligível pelo engenheiro de requisitos;

• Pensam nos requisitos de forma distinta dos demais, cabendo ao engenheiro de

requisitos identificar os possíveis conflitos, de forma a estabelecer um senso

comum;

• Podem existir interesses políticos de stakeholders, por exemplo de gerentes

querendo definir requisitos específicos de sistema para obter maior influência na

empresa;

• Os requisitos são dinâmicos, porque a empresa é dinâmica, novos stakeholders

pode sugerir mudanças nos requisitos, ou a própria dinâmica da empresa pode

demandar mudanças nos requisitos.

Como o levantamento de requisitos é uma fase inicial do projeto, não há

necessidade de fornecer detalhes. Durante a atividade de especificação de

requisitos é que os mesmos serão escritos de forma detalhada. A idéia é que os

requisitos levantados sirvam de insumos básicos visando:

• Auxílio para descrever a solução indicada para resolução do problema;

• Orientar os trabalhos da equipe nas etapas seguintes do processo de

desenvolvimento do sistema;

• Insumos iniciais para avaliação de riscos, custos e prazos.

Visando facilitar o levantamento dos requisitos, as seguintes atividades podem ser

sugeridas:

2.1.1 Selecionar as Fontes dos Requisitos

Os stakeholders são a principal fonte de requisitos em qualquer projeto, são eles

que detêm o conhecimento do negócio. Segundo Techy (2008, p. 29),

Fontes de requisitos podem ser documentos contendo Regras de Negócio, Modelo de Domínio e o Contexto Organizacional para o Sistema, ou qualquer outro documento fornecido pelo patrocinador do projeto. No entanto, a principal fonte de requisitos em qualquer projeto são as partes interessadas (envolvidos ou stakeholders).

17

O engenheiro de requisitos precisa desenvolver as habilidades e competências

necessárias para extrair informações importantes dos stakeholders, do ponto de

vista do projeto que está se iniciando e resolvendo conflitos, quando ocorrerem

opiniões divergentes sobre o mesmo requisito. Os conflitos ocorrem porque os

requisitos são levantados com a participação de diferentes stakeholders. Caberá ao

engenheiro de requisitos a responsabilidade de extrair as informações de forma

coerente, harmoniosa e consensual. É importante questionar os usuários do

sistema, de forma a conhecer o que cada um faz ou qual a contribuição que pode

fornecer, de acordo com a área de atuação ou influência.

Outras fontes de requisitos são: legislação relacionada a alguma funcionalidade do

sistema, manuais, normas e layouts como os layouts da FEBRABAN para troca de

arquivos de cobrança bancária, CNAB remessa e CNAB retorno, além de padrões

para emissão de boletos bancários; layouts e procedimentos legais para transmissão

de arquivo e emissão da nota fiscal paulista; Em sistemas de gestão escolar, temos

modelos de documentos exigidos pelas delegacias de ensino e o próprio regimento

interno da escola, o qual estabelece critérios de avaliação e aprovação.

2.1.2 Definir o Escopo do Sistema

É fundamental compreender o que a solução se propõe a fazer (dentro do escopo) e

o que ela não fará (fora do escopo), para que seja possível selecionar conteúdos

significativos a serem utilizados na lista de requisitos. Segundo Techy (2008, p. 29)

“Definir as fronteiras do sistema ajuda na compreensão do domínio e facilita a

definição do escopo, isto é, permite uma visão do que o sistema irá atender (dentro

do escopo) e do que o sistema não irá atender (fora do escopo).”

Ao documentar as expectativas e necessidades dos stakeholders, o engenheiro de

requisitos poderá diferenciar as necessidades que fazem parte do escopo do

sistema, sendo, portanto, relevantes para o projeto, das que não fazem parte do

escopo do sistema. Esta não é uma tarefa fácil. Stakeholders podem exercer

pressão para verem suas necessidades atendidas, mas o que deve ficar claro é o

que de fato o sistema se propõe a fazer.

18

Necessidades que vão além do contexto ou que inviabilizem o projeto, precisam ser

negociadas. Uma solução possível e elencar necessidades que poderão ser

atendidas em outro projeto. É fundamental que os stakeholders estejam de acordo

com a definição do problema, uma vez que existem restrições de custo e prazo e

todos têm que ter uma visão comum a respeito dos pontos fundamentais do projeto.

2.1.3 Coletar os Requisitos

Existem diversas técnicas para coleta de requisitos. Dentre elas Techy (2008)

destaca:

• Entrevistas. Esta técnica é geralmente a primeira utilizada. Os analistas

entrevistam clientes para obter informações relevantes para o projeto. A

entrevista deve ser objetiva, concisa, dirigida e ao final validada para garantir que

o assunto foi corretamente entendido.

• Questionários. É uma alternativa quando usuários não dispõem de tempo, estão

em outras localidade, ou ainda quando o objetivo é atingir um número maior de

envolvidos. O questionário não substitui as entrevistas. Após a elaboração de um

documento único, com dos dados dos questionários, é importante agendar

entrevista com alguns dos envolvidos de forma a revisar o conteúdo e esclarecer

dúvidas ou mal-entendidos.

O questionário deve ser planejado, conhecendo-se previamente as dúvidas que

as pessoas irão responder. Envolve questões objetivas e subjetivas, elaboradas

de forma simples, curtas e precisas.

• Observação “in loco”. Os analistas vivenciam o dia a dia da empresa, observando

como as tarefas são executadas, quais as atividades mais importantes e que

podem fazer parte do projeto. As observações devem ser documentadas e

validadas, através de entrevistas específicas com futuros usuários.

• Brainstorming. É uma técnica interessante e bastante utilizada. Trata-se de

reuniões breves, envolvendo clientes e usuários, mediados por um facilitador.

Estas reuniões propiciam o surgimento de várias idéias a respeito dos problemas

atuais e objetivos almejados. As idéias levantadas são afixadas em painéis, para

19

facilitar avaliação e validação. Terminada a reunião, um relatório será elaborado,

descrevendo os requisitos consensuais entre os participantes.

• Diagramas. Fluxogramas, diagrama de atividades da UML ou notação BPMN

(Busines Process Modeling Notation), podem ser utilizados para facilitar o

entendimento e possibilitar ao usuário uma forma mais simples de expressar

suas necessidades.

• Narrativas ou cenários de uso. São descrições, em texto livre e de forma

simplificada, dos participantes e suas atividades na execução de tarefas

relacionadas ao problema que o analista está estudando. As narrativas são úteis

para auxiliar na elaboração dos requisitos, mas não os substitui.

• Resumo de casos de uso ou caso de uso essencial. Na fase de levantamento de

requisitos, o importante é obter uma visão geral do sistema. Por este motivo,

ainda não é o momento apropriado para elaboração de casos de uso, entretanto

pode-se utilizar o resumo dos casos de uso, que é uma descrição de duas a seis

sentenças, focada nas atividades mais importantes. As narrativas de uso, podem

ser utilizadas na definição dos casos de uso.

• Histórias de usuário. Utilizadas em metodologias de desenvolvimento ágeis,

como XP (Extreme Programming), para descrever rapidamente as

funcionalidades mais importantes, ou seja, as que agregam valor, do ponto de

vista do comprador do software. Parte-se do pressuposto de que não é possível

descobrir todos os requisitos na fase inicial do projeto, porque os requisitos

iniciais são tênues e o usuário consegue se expressar melhor ao longo do

processo de desenvolvimento. Na fase de levantamento de requisitos são

elaboradas as histórias em nível mais alto, sendo estas histórias divididas em

outras mais simples em fases posteriores. São escritas em reuniões que utilizam

a técnica de brainstorming.

• Protótipo. Na fase de levantamento de requisitos, utiliza-se um protótipo estático,

ou seja, um esboço rápido da tela, sem preocupação com estética e navegação.

O trabalho final do levantamento de requisitos, segundo Pressman (2006, p. 125),

para a maioria dos sistemas, inclui:

• Uma declaração da necessidade e da viabilidade. • Uma afirmação limitada do escopo do sistema ou do produto. • Uma lista de clientes, usuários e outros interessados que participaram do

levantamento de requisitos. • Uma descrição do ambiente técnico do sistema.

20

• Uma lista de requisitos (preferencialmente organizada por função) e as restrições de domínio que se aplicam a cada um deles.

• Um conjunto de cenários de uso que fornecem informações sobre o uso do sistema ou do produto sob diferentes condições de operação.

• Quaisquer protótipos desenvolvidos para definir melhor os requisitos.

Todos estes artefatos devem ser revisados pelas pessoas envolvidas no trabalho de

levantamento de requisitos.

2.2 - ANÁLISE DE REQUISITOS

A análise de requisitos é uma atividade que ocorre paralelamente à fase de

levantamento de requisitos.

Os artefatos que servem de insumos para esta fase, são provenientes do

levantamento de requisitos. A análise será feita a partir dos requisitos identificados,

os quais foram documentados em uma lista de requisitos, em resumos de casos de

uso ou em histórias de usuários, de acordo com a técnica escolhida.

Segundo Filho (2003, p. 87),

“Requisitos de alta qualidade são claros, completos, sem ambigüidade, implementáveis, consistentes e testáveis. Os requisitos que não apresentam essas qualidades são problemáticos: eles devem ser revistos e renegociados com os clientes e usuários.”

Para que este nível de qualidade seja atingido, devemos formular as seguintes

questões:

• Existem duplicidades, ambigüidades ou conflito entre os requisitos?

• Os requisitos foram detalhados de forma sucinta, de acordo com a fase atual do

projeto?

• Os requisitos estão em conformidade com o objetivo do projeto?

• Os requisitos são viáveis do ponto de vista técnico, financeiro e operacional?

A próxima tarefa é avaliar os requisitos mais importantes, do ponto de vista do

cliente, ou seja, os que mais agregam valor ao negócio. Nesta perspectiva os

requisitos devem ser classificados pelo nível de prioridade. Segundo Pressman

(2006), é possível utilizar a IFQ. Técnica para implantação da função de qualidade,

que classifica os requisitos como:

• Requisitos normais. São requisitos que atendem aos objetivos e alvos

estabelecidos nas reuniões com o cliente;

21

• Requisitos esperados. São requisitos sobre os quais o cliente não comenta, mas

assume que estarão presentes, por exemplo: facilidade de instalação do

software, confiabilidade e precisão operacional;

• Requisitos excitantes. Requisitos que superam positivamente as expectativas do

cliente.

Outra classificação possível é proposta por Filho (2003, p. 91),

• requisito essencial - requisito sem cujo atendimento o produto é inaceitável;

• requisito desejável – requisito cujo atendimento aumenta o valor do produto, mas cuja ausência pode ser relevada em caso de necessidade (por exemplo, por causa de concretização de riscos);

• requisito opcional – requisito a ser cumprido se houver disponibilidade de prazo e orçamento, depois de atendidos os demais requisitos.

Esta classificação parece mais apropriada, porque permite priorizar o que de fato é

essencial e agrega valor ao negócio, do ponto de vista do cliente. Sem este

entendimento corre-se o risco de entregar uma solução fora do custo e prazo

estimados.

O analista deve estar atento ao fato de que é mais importante entregar o sistema

dentro do prazo e expectativa do cliente, do que entregar um sistema mais completo,

entretanto, fora do prazo e custo esperados.

Os requisitos classificados como desejáveis podem ser negociados com o cliente,

caso representem risco de atrasar o projeto, de forma a serem entregues após a

implantação.

Os requisitos opcionais, os quais não impedem o funcionamento do sistema, podem

ser eliminados ou planejados para uma próxima versão do sistema. Só devem ser

atendidos se houver disponibilidade de prazo e orçamento.

A partir destas considerações e classificações, é recomendado separar os requisitos

na ordem em que serão desenvolvidos, estabelecendo uma codificação que permita

seguir uma sequência, com intervalos de 10 em 10, por exemplo, prevendo a

possibilidade de mudança na ordem de prioridade. Requisitos que mais agregam

valor ao negócio devem encabeçar esta lista. Compete ao analista a condução do

processo de priorização e classificação dos requisitos, de acordo com as

necessidades do cliente.

Devem ser avaliados também os riscos em virtude de novas tecnologias utilizadas

no desenvolvimento e as questões relacionadas à performance. Um sistema pode

atender a requisitos funcionais de forma excepcional, mas se não atender aos

22

requisitos não-funcionais, corre sério risco de ser descontinuado, ou nem mesmo

chegar ao ambiente de produção. Se por exemplo, um sistema na área de

automação bancária, responsável por milhares de transações diárias, for

desenvolvido sem atender a requisitos de performance, certamente será inutilizado.

2.3 - ESPECIFICAÇÃO DE REQUISITOS

Após levantamento e análise dos requisitos é necessário detalhar os requisitos,

através da elaboração de documentos e modelos que possam ser avaliados,

revisados e aprovados. Esta documentação é importante, porque fornece os

insumos necessários para a elaboração e construção do software. Se a

documentação dos requisitos for bem elaborada, contribuirá de forma significativa

para minimizar riscos inerentes ao processo de desenvolvimento, como retrabalho e

fracasso em atender as necessidades do cliente.

De acordo com Sommerville (2003, p. 95),

O documento de requisitos de software – às vezes, chamado de SRS (software requirements specification) ou especificação de requisitos de software – é a declaração oficial do que é exigido dos desenvolvedores do sistema. Ele deve incluir os requisitos de usuário para um sistema e uma especificação detalhada dos requisitos de sistema.

Os requisitos de usuário, mencionados por Sommerville, são definidos no

documento de definição de requisitos e a especificação detalhada dos requisitos de

sistema, é definida no documento de especificação de requisitos. Os requisitos de

usuário e de sistema podem ser elaborados de forma integrada, em uma única

descrição. Alternativamente, os requisitos de usuário podem ser definidos de forma

introdutória à especificação dos requisitos de sistema.

Segundo Pfleeger (2004, p. 141),

“O documento de especificação de requisitos cobre exatamente o mesmo terreno que o documento de definição de requisitos. O documento de definição de requisitos é escrito em um nível apropriado para o cliente e em termos compreensíveis para este. Entretanto, o documento de especificação dos requisitos é escrito a partir da perspectiva do desenvolvedor.”

A forma de elaborar a especificação de requisitos normalmente é definida em

conformidade com o processo de desenvolvimento de software adotado pela

organização responsável pelo desenvolvimento.

23

Empresas que trabalham com o modelo em cascata, também conhecido como ciclo

de vida clássico, seguem ou adaptam padrões estabelecidos. Sommerville (2003, p

97 e 98), cita o padrão da IEEE, a qual sugere a seguinte estrutura para os

documentos re requisitos:

1. Introdução 1.1 Propósito do documento de requisitos 1.2 Escopo do produto 1.3 Definições, acrônimos e abreviações 1.4 Referências 1.5 Visão geral do restante do documento 2. Descrição Geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características do usuário 2.4 Restrições gerais 2.5 Suposições e dependências 3. Requisitos específicos que abrangem os requisitos funcionais, não funcionais e de interface. Essa é, obviamente, a parte mais substancial do documento, mas devido à ampla variabilidade na prática organizacional, não é apropriado definir uma estrutura-padrão para essa seção... 4. Apêndices 5. Índice

Por se tratar de uma estrutura muito genérica, ainda que com orientações

relevantes, Sommerville (2003, p. 98 e 99) faz uma sugestão interessante para a

organização de um documento de requisitos, baseado no padrão IEEE, conforme

quadro abaixo:

Capítulo Descrição

Prefácio

Ele deve definir o público a que se destina o documento e descrever seu histórico da versão, incluindo uma lógica para a criação de uma nova versão e um sumário das mudanças feitas em cada versão.

Introdução

Deve descrever a necessidade do sistema. Deve descrever brevemente suas funções e explicar como ele deverá operar com outros sistemas. Deve descrever como o sistema se ajusta aos negócios em geral ou aos objetivos estratégicos da organização que está encomendando o software.

Glossário Deve definir os termos técnicos utilizados no documento. Não se deve fazer suposições sobre a experiência ou o conhecimento apurado do leitor.

Definição de requisitos do usuário

Os serviços fornecidos para o usuário e os requisitos não funcionais do sistema devem ser descritos nesta seção. Essa descrição pode utilizar linguagem natural, diagramas ou outras notações que sejam compreensíveis pelos clientes. Padrões de produtos e de processos a serem seguidos devem ser especificados.

Arquitetura de sistemas

Este capítulo deve apresentar uma visão geral de alto nível da arquitetura de sistema prevista, mostrando a distribuição de funções por meio de módulos de sistemas. Os componentes de arquitetura que estão sendo reutilizados devem ser destacados.

Especificação de requisitos do sistema

Deve descrever os requisitos funcionais e não funcionais com mais detalhes. Se for necessário, outros detalhes podem também

24

ser adicionados aos requisitos não funcionais; por exemplo, podem ser definidas interfaces com outros sistemas.

Modelos de sistema

Devem ser estabelecidos um ou mais modelos de sistemas, mostrando o relacionamento entre os componentes de sistema e o sistema e seu ambiente. Esses podem ser os modelos de objeto, os modelos de fluxo de dados e os modelos semânticos de dados.

Evolução de sistema Devem ser descritas as suposições fundamentais na quais o sistema se baseia e as mudanças previstas, devidas à evolução de hardware, mudanças nas necessidades de usuário etc.

Apêndices

São fornecidos detalhes e informações específicas relacionadas à aplicação que está sendo desenvolvida. Exemplos de apêndices que podem ser incluídos são descrições de hardware e bases de dados. Os requisitos de hardware definem as configurações mínima e ótima para o sistema. Os requisitos de base de dados definem a organização lógica dos dados utilizados pelo sistema e os relacionamentos entre esses dados.

Índice Podem ser incluídos vários índices no documento. Da mesma maneira que um índice normal alfabético, pode haver um índice de diagramas, um índice de funções, entre outros.

Quadro 1 – Capítulos de um documento de requisitos Fonte: Sommerville (2003)

Avaliando o modelo proposto por Sommerville, percebe-se que é um excelente

modelo, contendo boas práticas a serem adotadas pelas empresas, ao elaborarem a

documentação de requisitos.

Entretanto, este modelo deve ser encarado como referencial e não com um produto

acabado e estratificado. Caberá a cada empresa a tarefa de adaptar o modelo às

suas necessidades. Trata-se portando de uma ferramenta útil para que a empresa

elabore seus próprios templates, sendo estes sim, documentos formais e

normatizados.

Para sistemas com um grande número de requisitos, é aconselhável criar um

documento para cada requisito. Estes artefatos podem ser nomeados de forma

padronizada, utilizando-se para tanto uma composição envolvendo o código do

requisito e do título do requisito.

Vimos até aqui a forma tradicional de documentar os requisitos, entretanto, é cada

vez mais comum a utilização de casos de uso para especificação de requisitos.

Empresas que adotam a metodologia de desenvolvimento iterativo e o Processo

unificado (PU), especificam requisitos no formato de casos de uso. Como o processo

é iterativo, não é necessário definir todos os requisitos no início do projeto. Outra

abordagem possível tem sido seguida pelos que adotam a metodologia de

desenvolvimento ágil de software. Na abordagem ágil uma parte significativa da

documentação é substituída por conversas com os usuários, porque uma premissa

25

do desenvolvimento ágil é que um dos membros da equipe seja um representante

direto do cliente.

Este trabalho tem como objetivo geral analisar o processo de modelagem de

requisitos funcionais, utilizando casos de uso, por isto este assunto será retomado,

de forma mais detalhada, no capítulo 3.

2.4 - VALIDAÇÃO DE REQUISITOS

Requisitos são fundamentais para o sucesso do projeto, clientes e desenvolvedores

precisam estar convictos de que os requisitos estão de acordo com o esperado e

descrevem exatamente o que o sistema fará, quando for implantado.

Segundo Pfleeger (2004, p. 142) “A validação dos requisitos é o processo que

determina que a especificação é consistente com a definição dos requisitos. Isto é, a

validação assegura que os requisitos atenderão às necessidades dos clientes.”

A primeira etapa do processo de validação consiste em verificar se os requisitos

listados no documento de definição possuem um documento de especificação de

requisitos correspondente e vice-versa. Esta etapa assegura a rastreabilidade entre

os dois documentos de requisitos.

A próxima etapa é a revisão dos requisitos. Esta revisão deverá ser efetuada pela

equipe de desenvolvimento, representantes do cliente e usuários chaves. De acordo

com Pfleeger (2004, p. 143), caberá aos envolvidos na atividade de revisão observar

os seguintes itens:

1. Revisamos as metas e os objetivos estabelecidos para o sistema. 2. Comparamos os requisitos com as metas e os objetivos, para verificar se todos os requisitos são necessários. 3. Descrevemos o ambiente em que o sistema irá operar. Examinamos as interfaces entre o sistema e todos os outros sistemas, e verificamos se elas estão corretas e completas. Em seguida, o fluxo e a estrutura das informações do sistema são, novamente, revisados, a fim de assegurar que os requisitos refletem com precisão a intenção e entendimento do cliente. As funções do sistema deverão ser consistentes na abrangência e no propósito do cliente. Além disso, as funções e restrições devem ser realistas e estar dentro de nossa capacidade de desenvolvimento. Todos os requisitos são novamente verificados, em busca de possíveis omissões, imperfeições e inconsistências. 4. Se existir qualquer risco envolvido no desenvolvimento ou no funcionamento real do sistema, ele será avaliado e documentado. Depois disso, discutimos e comparamos alternativas, e verificamos se existe concordância quanto às abordagens a serem utilizadas. 5. Conversamos sobre os testes do sistema. Como os requisitos continuarão a ser verificados e validados, à medida que o desenvolvimento

26

prossegue (e os requisitos se modificam e aumentam)? Como a equipe de testes poderá testar se todos os requisitos foram implementados de forma adequada? Quem fornecerá os dados para os testes? Se o sistema tiver de ser implementado em fases, como os requisitos serão verificados durante as fases intermediárias?

Com base nestes conceitos é possível formular as seguintes questões:

• Os requisitos propostos conciliam as diferentes necessidades dos usuários e

fornecem as funções que melhor atendem a estas necessidades?

• Os requisitos são consistentes, ou seja, não são contraditórios ou conflitantes

entre si?

• Os requisitos contemplam todas as funcionalidades necessárias para atender

aos objetivos do sistema, do ponto de vista do usuário?

• Os requisitos foram especificados de forma coerente com prazo, orçamento e

conhecimento tecnológico existente?

• Os requisitos podem ser facilmente checados, de forma a demonstrar, após a

entrega, que o sistema atende fielmente aos requisitos propostos e validados?

Diversas técnicas podem ser utilizadas no processo de validação dos requisitos.

Sommerville (2004) menciona como técnicas para validação de requisitos a revisão

de requisitos, prototipacão, geração de casos de teste e a análise automatizada da

consistência. A seguir detalharemos melhor estas técnicas com algumas

considerações relevantes.

• Revisão de requisitos. A revisão dos requisitos é um processo sistemático e

fundamental para o êxito do projeto. O presente estudo já abordou esta técnica

de forma mais detalhada.

• Prototipação. É uma técnica muito utilizada, principalmente para

desenvolvedores que utilizam o PU (processo unificado) ou metodologias ágeis.

Consistem na elaboração de modelos executáveis que representem alguma

funcionalidade do sistema, ou módulos do sistema. O protótipo é construído de

forma simples, sem a preocupação com validação de campos ou elaboração de

lógicas complexas. Visa apenas demonstrar os conceitos básicos da

funcionalidade envolvida, de forma a permitir que os usuários visualizem as

funcionalidades propostas nos requisitos.

A equipe de desenvolvimento pode ter algo em mente que seja diferente da

visão dos usuários, a respeito da mesma funcionalidade. O protótipo possibilita o

27

alinhamento da visão de desenvolvedores e usuários, na medida em que fornece

um modelo similar ao que será desenvolvido.

• Geração de casos de teste. O princípio básico é que os requisitos devem ser

testáveis. Partindo deste princípio é possível a elaboração de casos de testes

que permitam validar os requisitos. O objetivo da disciplina de testes não é seguir

o caminho comum e concluir que está tudo ok com o requisito avaliado. A idéia é

que sejam elaborados testes que permitam seguir fluxos alternativos e que sejam

testadas situações eficientes na detecção de erros. Se o requisito não pode ser

testado então sua implementação será duvidosa, devendo, portanto, ser

reconsiderado ou reescrito.

• Análise automatizada da consistência. Requisitos especificados com notação

estruturada ou formal, utilizando-se de ferramenta CASE, são passíveis de

validação através da construção de uma base de dados de requisitos e da

utilização de regras do método ou da notação. Como resultado deste processo a

ferramenta produz um relatório das inconsistências localizadas.

Os problemas detectados nesta fase são documentados e corrigidos antes do início

do desenvolvimento. Corrigir erros detectados na validação de requisitos é mais

simples e envolve custo bem menor do que corrigir um sistema durante a fase de

desenvolvimento ou quando o sistema estiver em ambiente de produção.

2.5 – GESTÃO DE REQUISITOS

Gerenciar requisitos de sistemas de médio e grande porte não é tarefa simples de

ser executada. Requisitos são utilizados em todas as fases e durante todo o ciclo de

vida dos sistemas, ou seja, só deixarão de ser utilizados quando o sistema for

descontinuado. Evidencia-se então a característica de persistência dos requisitos,

sendo esta uma característica intrínseca e que decorre da necessidade de que haja

correspondência fidedigna entre o que o sistema faz e o que efetivamente foi

planejado e documentado nos requisitos. Para que esta correspondência seja

possível, os requisitos também evoluem juntamente com o sistema. Esta evolução

significa que novos requisitos serão elaborados, outros serão modificados e alguns

excluídos.

28

O caráter dinâmico dos requisitos decorre do processo contínuo de revisão e

melhoria, durante o projeto do sistema e também após a implantação, no ciclo de

manutenção. O tempo de vida de um sistema tende a ser relativamente grande. As

mudanças, evolutivas ou corretivas, surgem, em geral, quando ocorrem os seguintes

fatores:

• Demandas provenientes de necessidades de novos usuários;

• Demandas para atender novas necessidades da área de negócios da empresa;

• Demandas legais, decorrentes de mudanças na legislação vigente;

• Demandas decorrentes de necessidades de atualizações tecnologias.

Segundo Pressman (2006, p. 121), “A gestão de requisitos é um conjunto de

atividades que ajudam a equipe de projeto a identificar, controlar e rastrear

requisitos e modificações de requisitos em qualquer época, à medida que o projeto

prossegue.”

É importante que a empresa adote um processo formal de controle sobre as

mudanças nos requisitos. De acordo com Techy (2008, p. 79), o processo de

gerenciamento das mudanças envolve os seguintes passos:

Passo 1. Receber as solicitações de alteração de re quisitos. Estas solicitações devem ser formais, registradas em formulários ou documentos apropriados. O grau de formalidade vai variar conforme a metodologia de desenvolvimento que está sendo utilizada. Passo 2. Analisar o impacto da mudança. Uma análise criteriosa deve ser conduzida para avaliar o impacto do requisito a ser incluído, alterado ou excluído sobre cada requisito relacionado. Passo 3 . Analisar o custo da mudança. Devem-se considerar os efeitos da mudança em outros requisitos do sistema, considerando impactos no esforço e no prazo. Passo 4. Aprovar ou rejeitar a mudança. Caso o impacto seja significativo, os requisitos (analisado e relacionado) devem ser revistos. Passo 5. Alterar o documento de requisitos e outros documentos. Os documentos devem ser alterados para refletir as mudanças ocorridas. Passo 6. Notificar os envolvidos. Os envolvidos devem ser informados tanto em relação a mudanças aprovadas quanto as rejeitadas. Passo 7. Desenvolvimento das mudanças aprovadas

Quadro 2 – Passos do processo de gerenciamento de mudanças nos requisitos Fone: Techy (2008)

Ainda segundo Techy (2008) uma condição essencial para gerenciamento de

requisitos é a rastreabilidade. Um requisito pode ser considerado como rastreável

se, no mínimo, for possível: identificar o solicitante, saber por que o requisito existe e

determinar o relacionamento com outros requisitos.

Existem ferramentas que auxiliam no processo de rastreamento, baseado em

tabelas de rastreamento. Pressman (2006, p. 121) cita algumas destas tabelas,

29

Tabela de rastreamento de características . Mostra como os requisitos se relacionam a características importantes do sistema/produto observáveis pelo cliente. Tabela de rastreamento de fontes . Identifica a fonte de cada requisito. Tabela de rastreamento de dependência . Indica como os requisitos estão relacionados uns aos outros. Tabela de rastreamento de subsistemas. Caracteriza os requisitos pelo(s) subsistema(s) que eles governam. Tabela de rastreamento de interface. Mostra como os requisitos se relacionam com as interfaces internas e externas do sistema.

30

CAPÍTULO 3 - CASOS DE USO E REQUISITOS FUNCIONAIS

Nos tópicos anteriores, este estudo discorreu sobre os conceitos básicos da

engenharia de requisitos e os processos típicos utilizados na definição de requisitos.

A partir deste tópico o foco será a modelagem de requisitos funcionais mediante a

especificação de casos de uso. Existem outras formas de documentar os requisitos

funcionais, como por exemplo, o registro de requisitos funcionais, que é um artefato

típico da metodologia de desenvolvimento estruturada. Entretanto, atualmente é

muito comum a utilização de casos de uso como forma de especificar os requisitos

funcionais e esta será a abordagem adotada como padrão neste estudo.

De acordo com Ramos (2006, p. 64),

A modelagem de requisitos funcionais (e mesmo o próprio desenvolvimento de softwares), mediante a especificação de casos de uso, é, atualmente, considerada uma abordagem extremamente adequada, pois facilita a comunicação entre a equipe de projeto e os clientes/usuários, e, ainda, promove a comunicação, o gerenciamento e a condução do desenvolvimento do projeto.

Visando fornecer o contexto do surgimento e utilização de casos de uso, vale

ressaltar que casos de uso fazem parte da UML e do PU. PU, abreviação de

Processo Unificado, é um processo padrão para o desenvolvimento de software,

também conhecido pela sigla RUP, abreviação de Rational Unified Process, ou,

traduzindo, Processo Unificado Racional.

O RUP utiliza a UML, abreviação de Unified Modeling Language, ou, traduzindo,

Linguagem de Modelagem Unificada. A UML inclui os diagramas de casos de uso

(em inglês use cases), utilizados para representar os requisitos funcionais.

Segundo Larman (2004, p. 71),

Casos de uso são documentos textuais, não diagramas, e a modelagem de casos de uso é basicamente um ato de redigir textos, não de desenhar. Entretanto, a UML define um diagrama de caso de uso para ilustrar os nomes dos casos de uso e atores, assim como seus relacionamentos.

Temos então um modelo de casos de uso (MCU) composto pela especificação de

casos de uso, elaborada em linguagem natural e o diagrama de casos de uso, que é

a ferramenta da UML para modelagem de casos de uso.

De acordo com Bezerra (2007, p. 55),

Um caso de uso representa uma determinada funcionalidade de um sistema conforme percebida externamente. Representa também os agentes externos que interagem com o sistema. Um caso de uso, entretanto não revela a estrutura e o comportamento internos do sistema.

31

Através do modelo de casos de uso é possível conhecer as funcionalidades que o

sistema disponibiliza aos usuários, entretanto não será possível saber como o

sistema age internamente para produzir os resultados visíveis externamente. Outras

disciplinas da engenharia de software serão responsáveis por detalhar o

funcionamento interno do sistema.

Segundo Bezerra (2007, p. 55),

Cada caso de uso de um sistema se define pela descrição narrativa (textual) das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema. A UML não define uma estrutura textual a ser utilizada na descrição de um caso de uso. Consequentemente, há vários estilos de descrição propostos para definir casos de uso. A escolha de um ou de outro estilo fica a cargo da equipe de desenvolvimento, ou então, pode ser uma restrição definida pelos clientes que encomendaram o sistema.

De acordo com este entendimento, há vários formatos possíveis para a

especificação de casos de uso. Os formatos comuns são o contínuo, o numerado e

o tabular.

É importante que a empresa adote um template (modelo de documento) padrão para

o documento de especificação de casos de uso. O modelo poderá ser adaptado, de

acordo com as necessidades específicas da empresa, porém uma vez definido

assume caráter normativo, devendo ser adotando por todos os envolvidos no

processo de especificação de requisitos.

Para os objetivos deste estudo, elabora-se um template próprio, adaptado de alguns

existentes no mercado, para o documento de especificação de casos de uso,

conforme abaixo:

<Nome do Projeto>

Especificação de Caso de Uso: <Nome do Caso de Uso>

Breve Descrição: [Descrição resumida do caso de uso]

Histórico de Revisões Data Versão Descrição Autor

[dd/mm/aaaa] [x.x] [detalhes das revisões] [mome do autor]

1. Atores: [Nome dos atores que participam do caso de uso]

32

2. Pré-condições: [Condição que o sistema deve satisfazer para permitir o início do caso de uso]

3. Fluxo de Eventos

O <nome do ator> inicia o caso de uso [Descrição do evento que inicia o caso de uso]

3.1. Fluxo Básico

[Descrição dos passos que compões o fluxo básico. Cada passo deve ser numerado como subitem, ou seja: 3.1.1, 3.1.2 etc. Na ocorrência de fluxos alternativos, devem ser referenciados com a sigla FA seguida de numeração seqüencial, ou seja, FA1 FA2 etc.]

3.2. Fluxos Alternativos

FA1 <nome do fluxo alternativo>

[Mencionar o passo do fluxo básico aonde existe a ocorrência do fluxo alternativo e a seguir descrever os passos do fluxo alternativo] FA2 ...

4. Pós-condições: [Estado do sistema após a realização do caso de uso, sendo resultados de sucesso ou de falha do caso de uso.]

Template 1 – Modelo para o documento de especificação de casos de uso Fone: Elaboração própria (2012)

O texto entre colchetes e exibido em itálico e azul são apenas dicas de

preenchimento. Para efeito de padronização o template define a fonte a ser utilizada

como Arial 12 e o espaçamento entre linhas de 1,5 linha.

Existem casos de uso concretos e abstratos. Casos de uso concretos são iniciados

por atores e possuem um fluxo completo de eventos. Do ponto de vistas dos atores

do sistema, só é possível visualizar os casos de uso concretos. Diferentemente

disto, os casos de uso abstratos não apresentam relação de comunicação com

qualquer ator, mas são acessados por outros casos de usos. Quando um ator inicia

um caso de uso concreto, terá acesso, de forma indireta, ao comportamento dos

casos de uso abstratos associados e esta associação ocorre através dos

relacionamentos de inclusão, extensão e generalização. O tópico 3.3 detalha estes

tipos de relacionamento.

Quanto ao grau de abstração dos casos de uso, podem ser classificados como real

ou essencial. De acordo com Bezerra (2007, p. 57), “Um caso de uso essencial é

33

abstrato no sentido de não fazer menção a aspectos relativos à tecnologia utilizada

nas interações entre ator e casos de uso.” Esta é uma abordagem mais adequada

para a documentação dos requisitos funcionais de um sistema, uma vez que o

requisito é especificado sem detalhes da tecnologia ou do como será implementado.

Já nos casos de uso com grau de abstração real, existe um comprometimento prévio

com a solução tecnológica a ser adotada. Isto não é recomendável porque os

requisitos funcionais servem de insumos para as demais fases do processo de

desenvolvimento, devendo, portanto, permitir que a equipe de projetos indique uma

ou mais soluções possíveis para atender os mesmos requisitos funcionais.

Bezerra (2007, p. 58) propõe a seguinte regra para identificar se um caso de uso é

real ou essencial:

É uma boa idéia utilizar a regra prática dos 100 anos para identificar se um caso de uso contém algum detalhe de tecnologia: pergunte-se, ao ler a narrativa do caso de uso, se a mesma seria válida tanto há 100 anos, quanto daqui a 100 anos. Se a resposta para a sua pergunta for um “sim”, então isso é um indício de que se trata de um caso de uso essencial. Caso contrário, trata-se de um caso de uso real.

3.1 – CENÁRIOS

Cenários são diferentes situações possíveis para a realização de um caso de uso.

De acordo com Ramos (2006, p. 66),

Um cenário é uma determinada sequência de ações que ilustra um comportamento do sistema. Em uma definição mais abstrata, deve-se entender um cenário como uma instância de um caso de uso, sendo normal que este possa ser descrito por dezenas de possíveis cenários. Uma designação alternativa para cenário, por vezes utilizada, é fluxo de ações. É preciso especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um usuário não técnico possa entendê-lo sem dificuldade.

Para descrever uma funcionalidade do sistema, requisito funcional, o caso de uso

utiliza um ou mais cenários possíveis. Por exemplo, um cenário principal descreve

que o sistema valida o usuário quando este fornece login e senha. Entretanto, existe

a necessidade de cenários alternativos, para descrever o que ocorre quando o

usuário informa senha ou login inválidos. O caso de uso abaixo ilustra melhor este

exemplo.

34

Sistema de Vendas On-Line

Especificação de Caso de Uso: Valida Usuário

Breve Descrição: Autentica usuários a partir do login e senha informados.


10/03/2012 1.0 Criação do documento Damião

1. Atores: Usuário

2. Pré-condições: Não se aplica.

3. Fluxo de Eventos

O Usuário inicia o caso de uso ao acessar sua conta na loja virtual.

3.1. Fluxo Básico

3.1.1. O sistema solicita a identificação do Usuário.

3.1.2. O Usuário informa login e Senha. FA1

3.1.3. O Sistema valida os dados fornecidos e efetua Login. FA2 FA3

3.1.4. Finaliza caso de uso.


FA1 Novos usuários

No passo 3.1.2 do fluxo básico, caso o usuário opte por fazer o seu

cadastro, o sistema deve executar os seguintes passos:

1. O sistema solicita dados cadastrais do Usuário.

2. O Usuário informa os dados solicitados. FA4

3. O sistema solicita a criação do login e senha do Usuário.

4. O Usuário cria seu login e senha.

2. Retorna ao passo 3.1.4 do fluxo básico.

35

FA2 Login inválido

No passo 3.1.3 do fluxo básico, caso o sistema verifique que o login está em

branco ou não foi localizado, deve executar os seguintes passos:

1. O sistema informa que o login é Inválido.


FA3 Senha inválida

No passo 3.1.3 do fluxo básico, caso o sistema verifique que a senha está

em branco ou não confere, deve executar os seguintes passos:

1. O sistema informa que a senha é Inválida.


FA4 Usuário desiste de fazer o cadastro

No passo 2 do fluxo alternativo FA1, caso o usuário desista de fazer o

cadastro, o sistema deve executar os seguintes passos:

1. O sistema informa que o usuário desistiu de efetuar o cadastro.


4. Pós-condições: Usuário autenticado; Usuário não autenticado.

Especificação de Caso de Uso 1 – Valida Usuário Fonte: Elaboração Própria (2012)

De acordo com Bezerra (2007, p.59),

Uma analogia válida para entender a relação entre caso de uso e cenário é a de um labirinto. Em um labirinto, temos geralmente diversas maneiras para chegar a uma determinada saída a partir de uma determinada entrada. De forma análoga, podemos comparar o labirinto ao caso de uso. Por outro lado, podemos comparar um cenário a cada uma das possíveis maneiras de atravessar o “caso de uso”.

3.2 - ATORES

Durante a fase de levantamento de requisitos, o analista de requisitos identifica

quais os usuários principais que vão interagir com o sistema. Estes usuários, ou

36

qualquer elemento externo que interage com o sistema é denominada ator, na

terminologia da UML.

Segundo Pressman (2006, p. 130),

O primeiro passo ao escrever um caso de uso é definir o conjunto de “atores” que estarão envolvidos na história. Atores são as diferentes pessoas (ou dispositivos) que usam o sistema ou produto dentro do contexto da função e do comportamento que devem ser descritos. Atores representam os papéis que pessoas (ou dispositivos) desempenham quando o sistema está em operação. Definindo mais formalmente, um ator é qualquer coisa que se comunique com o sistema ou o produto e que seja externa ao sistema em si. Casa ator tem um ou mais objetivos quando uso o sistema.

Entendemos, portanto, que o ator pode ser um usuário que interage com o sistema,

mas também pode ser, por exemplo, um sistema externo que tenha alguma interface

com o sistema em análise.

Ainda segundo Pressman (2006, p. 130),

É importante notar que um ator e um usuário final não são necessariamente a mesma coisa. O usuário típico pode desempenhar vários papéis diferentes quando usa um sistema, enquanto o ator representa uma classe de entidades externas (frequentemente, mas nem sempre, pessoas) que desempenham apenas um papel no contexto do caso de uso.

É possível, portanto, que o usuário desempenhe mais de um papel, no contexto do

caso de uso. Um caixa de loja, sob certas circunstâncias, pode desempenhar

também o papel de vendedor. Neste caso, o usuário que emite o pedido é o mesmo

que registraria o pagamento. Na descrição do caso de uso, é importante nomear

atores de acordo com o papel que desempenhem ao utilizarem o sistema. Neste

exemplo, utiliza-se um ator para representar o papel de vendedor e outro para

representar o papel de caixa, mesmo que a empresa não faça tal distinção. Esta

abordagem é interessante, porque além de representar corretamente os papéis

desempenhados pelo usuário, o caso de uso continuará válido e, por conseguinte, o

sistema terá esta possibilidade de interação, caso a empresa passe a fazer distinção

entre caixas e vendedores, ou mesmo se o sistema for utilizado por outra empresa,

com este tipo de segregação de funções.

Os atores podem ser classificados em categorias diversas, como por exemplo:

Categoria Atores Cargos Cliente, Vendedor, Supervisor etc. Organizações ou Departamentos Transportadora, Administradora de Cartões,

Contabilidade etc. Sistemas Externos Sistema de Cobrança, Sistema de Estoque etc. Dispositivos Externos Leitor de Código de Barras, Sensor etc.

Quadro 3 – Categorias de atores

37

Fonte: Bezerra (2007)

Existem atores primários e atores secundários, ou principais e de suporte. Segundo

Bezerra (2007, p. 61),

Um ator primário é aquele que inicia uma sequência de interações de um caso de uso. São eles os agentes externos para os quais o caso de uso traz benefício direto. As funcionalidades principais do sistema são definidas tendo em mente os objetivos dos atores primários.

Os casos de uso são elaborados tendo em vista satisfazer os objetivos dos atores

principais, ou primários, porque são eles que interagem diretamente com o sistema e

usufruem das suas funcionalidades. Os atores de suporte ou secundários, são

aqueles que fornecem serviços ao sistema, mantendo ou auxiliando os atores

principais na utilização do sistema.

3.3 – RELACIONAMENTO ENTRE CASOS DE USO

Atores e casos de uso não são suficientes para a especificação de requisitos

funcionais. Para viabilizar o modelo de casos de uso, é fundamental possibilitar a

existência de relacionamento entre atores e casos de uso. Um ator pode estar

relacionado a um ou mais casos de uso, os casos de uso podem se relacionar entre

si e os atores também podem se relacionar com outros atores.

A UML define quatro tipos de relacionamentos possíveis: comunicação, inclusão,

extensão e generalização. Sendo que todos estes relacionamentos possuem

notação gráfica específica, definida na UML.

3.3.1 Relacionamento de Comunicação

Este relacionamento é o mais utilizado. Um ator se relaciona com o caso de uso

através do relacionamento de comunicação. Esta associação envolve troca de

informações entre o ator e o sistema, por meio do caso de uso. Um ator pode se

relacionar a um ou mais casos de uso.

38

3.3.2 Relacionamento de Inclusão

Relacionamento de inclusão é utilizado apenas entre casos de uso. De acordo com

Bezerra (2007, p.62),

O princípio subjacente ao relacionamento entre casos de uso é o mesmo utilizado no mecanismo de definição de rotinas em linguagem de programação. Quando dois ou mais casos de uso incluem uma sequência comum de interações, essa sequência comum pode ser descrita em outro caso de uso. A partir daí, vários casos de uso do sistema podem incluir o comportamento desse caso de uso comum.

O objetivo deste relacionamento é, portanto, possibilitar que um caso de uso base

inclua outro, evitando assim a duplicação de informações e simplificando a tarefa de

revisão e manutenção do texto. O caso de uso a ser incluído é encapsulado, porque

é utilizado por outro caso de uso, sem que seus atributos sejam acessados

diretamente ou modificados. Este grau de abstração permite o reuso em diferentes

casos de uso. O Caso de uso de inclusão é sempre abstrato.

A UML não estabelece um padrão para referenciar o relacionamento de inclusão,

entretanto, é comum e consensual que esta referencia seja feita no texto do caso de

uso que inclui o outro, sendo o texto sugerido: “Incluir o caso de uso <nome do caso

de uso incluso>”.

O caso de uso abaixo exemplifica o relacionamento de inclusão. O caso de uso

“Efetua Pedido pela Internet” inclui o caso de uso “Valda usuário”, citado no item 3.1.


Especificação de Caso de Uso: Efetua Pedido pela Internet

Breve Descrição: O “Cliente Internauta”, autenticado pelo sistema, efetua o pedido,

com base nos itens que inseriu no carinho de compras, sendo o pagamento

aprovado pelo “Serviço de Autorização do Pagamento”.



39

1. Atores: Cliente Internauta e Serviço de Autorização do Pagamento.

2. Pré-condições: O Cliente Internauta incluiu itens no carrinho de compras.

3. Fluxo de Eventos

Incluir caso de uso “Valida Usuário”.

O Cliente Internauta inicia o caso de uso ao confirmar a opção de finalizar a

compra.

3.1. Fluxo Básico

3.1.1. O Sistema exibe os itens que o cliente incluiu no carrinho de compras.

3.1.2. O Cliente confirma os itens selecionados. FA1

3.1.3. O sistema solicita o CEP aonde será feita a entrega dos produtos.

3.1.4. O Cliente informa o CEP

3.1.5. O Sistema exibe o valor do frete. FA1 FA2

3.1.6 O Sistema informa o prazo previsto para entrega e solicita os dados

necessários para o pagamento.

3.1.7. O Cliente informa os dados para efetivar o pagamento. FA1

3.1.8. O sistema confirma os dados do pagamento e avisa o Cliente que o

pedido foi efetuado com sucesso. FA3

3.1.9. Finaliza Caso de Uso


FA1 Cliente Desiste do Pedido

Nos passos 3.1.2, 3.1.5 e 3.1.7 do fluxo básico, caso o Cliente opte por

desistir da compra, o sistema deve executar os seguintes passos:

1. O sistema informa que o cliente desistiu da compra.


FA2 Frete Grátis

No passo 3.1.5 do fluxo básico, caso o sistema verifique que o CEP

informado pertence a uma região aonde não há incidência de cobrança de

40

frete, deve executar os seguintes passos:

1. O sistema informa que o frete é grátis para o CEP informado.


FA3 Pagamento não autorizado

No passo 3.1.8 do fluxo básico, caso o sistema não confirme os dados do

pagamento, deve executar os seguintes passos:

1. O sistema informa que o pagamento não foi autorizado.


4. Pós-condições: Um pedido efetuado; Nenhum pedido efetuado.

Especificação de Caso de Uso 2 – Efetua Pedido pela Internet Fonte: Elaboração Própria (2012)

3.3.3 Relacionamento de Extensão

Relacionamento de Extensão também é utilizado apenas entre casos de uso,

possibilitando a conexão entre um caso de uso de extensão e um caso de uso base.

Normalmente o caso de uso de extensão é abstrato, mas não é necessário que seja.

Segundo Bezerra (2007, p. 63),

O relacionamento de extensão é utilizado para modelar situações em que diferentes sequências de interações podem ser inseridas em um mesmo caso de uso. Cada uma dessas diferentes sequências representa um comportamento eventual, ou seja, um comportamento que só ocorre sob certas condições, ou cuja realização depende da escolha do ator. Na realidade, quando o relacionamento de extensão é utilizado de forma adequada, a descrição do caso de uso estendido não deve aparentar falta de completude, ou seja, essa descrição não deve dar a entender que deve (necessariamente) existir uma extensão em seu comportamento.

Deste modo, a extensão é condicional, ou seja, sua execução depende do que

ocorre no caso de uso base. O caso de uso base segue seu fluxo sem denotar

relação de dependência com o caso de uso que o estende, ou seja, o caso de uso

base poder ser realizado sem a utilização do caso de uso extensão.

Segundo Ramos (2006, p. 70), “O caso de destino é estendido em um ou mais

pontos, chamados pontos de extensão, os quais são mecanismos de variabilidade.”.

41

A execução do ponto de extensão é desencadeada quando alguma condição é

satisfeita ou existe solicitação direta do ator. Quando ocorre a extensão, em algum

ponto do caso de uso base, o caso de uso extensor pode acessar e modificar

atributos do caso de uso base, entretanto o caso de uso base não controle o

extensor, nem pode ver as extensões ou acessar seus atributos. Esta característica

é importante porque permite que o caso de uso extensor seja alterado, sem que isto

implique necessariamente em alteração no caso de uso base. Entretanto, se for

utilizada a descrição de passos numerada e ocorrer alguma remoção ou inclusão de

passo, no caso de uso base, pode ser necessário alterar a referência no caso de uso

extensor.

Segundo Ramos (2006, p. 70),

Uma relação de extensão permite representar: • A parte de um caso que o usuário vê como opcional, ou como integrante

de várias alternativas; • Um sub-fluxo de ações executado apenas se determinadas condições

se verificarem; • Vários fluxos de ações que podem ser inseridos em um determinado

ponto de extensão, de forma controlada, mediante uma interação explícita com um ator.

Para exemplificar os conceitos objeto deste estudo, utilizaremos o exemplo de uma

loja virtual, na qual clientes autenticados podem efetuar pedidos e consultar pedidos.

No item anterior, 3.3.2, o caso de uso “Efetua Pedido pela Internet”, inclui o caso de

uso “Valda Usuário”. Para aplicar os conceitos deste tópico, aonde é abordado o

relacionamento de extensão, elabora-se a seguir o caso de uso “Consulta Pedidos

pela Internet”, o qual além de incluir o caso de uso “Valida Usuário”, também é

estendido pelo caso de uso “Informa Dados do Pedido”.


Especificação de Caso de Uso: Consulta Pedidos pela Internet

Breve Descrição: O “Cliente Internauta”, autenticado pelo sistema, consulta os

pedidos, com base em uma lista dos últimos pedidos, ou informando dados do

pedido para consulta.


42


1. Atores: Cliente Internauta

2. Pré-condições: Não se aplica.

3. Fluxo de Eventos

Incluir caso de uso “Valida Usuário”.

Pontos de extensão: No passo 3.1.2 do fluxo básico, caso o Cliente opte por

informar dados para pesquisar pedidos, o sistema deve utilizar o caso de uso de

extensão “Informa Dados do Pedido”.

O Cliente inicia o caso de uso ao acessar a consulta de pedidos

3.1. Fluxo Básico

3.1.1. O Sistema exibe uma lista de pedidos recentes e oferece uma

alternativa para o Cliente fornecer dados para pesquisar pedidos.

3.1.2. O Cliente seleciona um dos itens da lista ou informa dados para

pesquisar pedidos. FA1

3.1.3. O sistema exibe os dados do pedido selecionado.

3.1.4. O Cliente visualiza os dados e opta por finalizar a consulta. FA2

3.1.5. Finaliza Caso de Uso


FA1 Cliente Desiste da consulta

No passo 3.1.2 do fluxo básico, acaso o Cliente opte por desistir da

consulta, o sistema deve executar os seguintes passos:

1. O sistema informa que o cliente optou por encerrar a consulta.


FA2 Cliente Continua Consultando Pedidos

No passo 3.1.4 do fluxo básico, aonde o cliente o opta por continuar

consultando pedidos, o sistema deve executar o seguinte passo:

43


4. Pós-condições: Um pedido selecionado; Não existem pedidos para consulta.

Especificação de Caso de Uso 3 – Consulta Pedidos pela Internet Fonte: Elaboração Própria (2012)


Especificação de Caso de Uso: Informa Dados do Pedido

Breve Descrição: Estende os casos de uso “Consulta Pedidos pela Internet”.

Permite consulta através do número do pedido ou do período de compras.



1. Atores: Cliente Internauta

2. Pré-condições: Usuário logado; Consulta de pedidos em andamento.

3. Fluxo de Eventos

Este caso de uso é uma extensão de outros casos de uso.

3.1. Fluxo Básico

3.1.1. O sistema solicita os dados para consultar os pedidos.

3.1.2. O Cliente informa o número do pedido. FA1

3.1.3. O Sistema consulta os pedidos com base na informação fornecida pelo

Cliente.

3.1.4. O sistema exibe uma lista do(s) pedido(s) localizado(s). FA2

3.1.5. O Cliente seleciona um dos itens da lista.

3.1.6. Retorna ao passo 3.1.3 do fluxo básico do caso de uso “Consulta

44

Pedidos pela Internet”.


FA1 Cliente informa período em que realizou o pedid o

No passo 3.1.2 do fluxo básico, caso o Cliente opte por informar o período

em que realizou o pedido, o sistema deve executar o seguinte passo:


FA2 Sistema não localiza pedidos

No passo 3.1.4 do fluxo básico, caso o sistema não localize nenhum pedido,

deverá executar os seguintes passos:

1. O sistema informa que não localizou pedidos de acordo com o parâmetro

informado pelo Cliente.

2. Retorna ao passo 3.1.2 do fluxo básico do caso de uso “Consulta Pedidos

pela Internet”.

4. Pós-condições: Um pedido selecionado; Nenhum pedido selecionado.

Especificação de Caso de Uso 4 – Informa Dados do Pedido Fonte: Elaboração Própria (2012)

3.3.4 Relacionamento de Generalização

Relacionamento de generalização pode ser utilizado entre casos de uso ou entre

atores. Segundo Bezerra (2007, p. 65), “Esse relacionamento permite que um caso

de uso (ou um ator) herde características de um caso de uso (ator) base. O caso de

uso (ator) herdeiro pode especializar o comportamento do caso de uso (ator) base.”

O caso de uso (ator) filho assume a estrutura, comportamento e os relacionamentos

do pai. O caso de uso filho é uma especialização do pai, podendo subtrair ou

adicionar comportamentos específicas.

Bezerra (2007, p. 67) sugere as seguintes situações aonde é recomendável utilizar a

Generalização:

45

Generalização entre casos de uso. Use generalização entre casos de uso quando você identificar dois ou mais casos de uso com comportamentos semelhantes. Crie, então, um caso de uso mais genérico (de preferência abstrato) e o relacione por generalização aos casos de uso semelhantes. Generalização entre atores. Use generalização quando precisar definir um ator que desempenhe um papel que já é desempenhado por outro ator em relação ao sistema, mas que também possui comportamento particular adicional.

A utilização de generalização entre atores é mais simples, porém a generalização

entre casos de uso é mais complexa, porque o caso de uso pai deve indicar quais

comportamentos do pai estão sendo especializados. Se a especificação do caso de

uso pai for numerada, então pode-se indicar no filho quais passos do pai estão

sendo redefinidos ou estendidos.

Casos de uso pai e filho podem ser concretos ou abstratos. Recomenda-se,

entretanto, que o caso de uso pai seja sempre abstrato.

Ao redefinir o fluxo de eventos do caso de uso pai, o filho deve, entretanto, preservar

o propósito original do pai. A estrutura geral do fluxo de eventos do caso de uso pai,

incluindo os passos deve permanecer no filho, mas o conteúdo pode ser modificado

pelo filho. Se o caso de uso pai for abstrato, não possuindo, portanto, um fluxo

completo de comportamento, o caso de uso filho deve completar os passos, de

forma a torná-los significativos para ao ator.

Quando ocorre generalização de um pai e dois filhos, os filhos são instanciados de

forma separada, sendo que o ator terá acesso apenas às especializações do caso

de uso com o qual estabelece relação de comunicação.

Considerando o exemplo do item 3.3.2 especificação de Caso de Uso Efetua

Pedido, é possível implementar um relacionamento de generalização de forma a

possibilitar que o cliente efetue o pedido pela Internet ou por telefone. Neste

exemplo, o caso de uso pai pode ser definido como “Efetua Pedido” e é um caso de

uso abstrato, por não possuir relacionamento de comunicação com nenhum ator.

Os casos de uso filhos, seriam então, “Efetua Pedido pela Internet” e “Efetua Pedido

por Telefone”, sendo ambos os casos de uso concretos, por serem iniciados por

atores e possuírem fluxo completo de eventos.

Como exemplo de generalização entre atores, é possível definir um ator filho como

“Cliente Internauta”, o qual efetua pedidos pela internet, e outro ator filho como

“Cliente Televendas”, o qual efetua pedidos por telefone. Estes dois atores

participam do relacionamento de generalização com o ator pai “Cliente”.

46

No próximo item deste trabalho, 3.4, os dois exemplos de generalização, citados

acima, generalização entre casos de uso e generalização entre atores, serão

visualizados de forma mais clara, através do diagrama de casos de uso.

3.4 – DIAGRAMA DE CASOS DE USO

Nos tópicos anteriores, este trabalho abordou conceitos fundamentais do modelo de

caos de uso, mas sob a perspectiva de elaboração de textos, neste tópico,

entretanto o enfoque será na perspectiva gráfica do modelo de casos de uso.

De acordo com Bezerra (2007, p. 70),

O DCU é um dos diagramas da UML e corresponde a uma visão externa de alto nível do sistema. Esse diagrama representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. O DCU tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema. Nesse sentido, a finalidade de um DCU é apresentar um tipo de “diagrama de contexto” que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.

O objetivo do diagrama de casos de uso (DCU) é, portanto, modelar os requisitos

funcionais, de forma gráfica, permitindo assim uma visão complementar e que auxilia

no entendimento das especificações textuais.

O diagrama de caso, também pode ser chamado de diagrama de contexto. Segundo

Filho (2003, p. 100),

O diagrama de casos de uso mais importante é o diagrama de contexto. Esse é um diagrama que mostra as interfaces do produto com seu ambiente de aplicação, inclusive os diversos tipos de usuários e outros sistemas com os quais o produto deve interagir... Nesse diagrama, os usuários, sistemas externos e outros componentes de um sistema maior são representados por atores, enquanto os casos de uso representam as possíveis formas de interação do produto com os atores.

A tabela abaixo relaciona os elementos existentes no diagrama de casos de uso e

as notações utilizadas para representar esses elementos.

Elemento Notação Utilizada e Exemplo

Ator

Figura de um indivíduo (boneco). O nome do ator deve constar abaixo da figura.

Ator

47

Caso de Uso

Elipse. O nome do caso de uso deve constar abaixo ou dentro da elipse.

Caso de Uso

Relacionamento de Comunicação

Linha cheia e, em geral, sem setas, porque a comunicação entre o ator e o caso de uso pode ocorrer em ambos os sentidos, ou pode não ser relevante determinar esta informação.

Ator

Caso de Uso

Relacionamento de Inclusão

Linha tracejada, contendo seta direcionada para o caso de uso incluído e o estereótipo <<include>>.

Ator

Caso de Uso 1

Caso de Uso 2

<<include>>

Relacionamento de Extensão

Linha tracejada, contendo seta direcionada para o caso de uso estendido e o estereótipo <<extend>>.

Ator

Caso de Uso 1

Caso de Uso 2

<<extend>>

Relacionamento de

Generalização entre Atores

Linha cheia com uma seta fechada no final, apontando para o ator Pai do relacionamento de generalização.

48

Ator Pai

Ator Filho 1 Ator Filho 2

Relacionamento de Generalização entre Casos de

Uso

Linha cheia com uma seta fechada no final, apontando para o caso de uso Pai do relacionamento de generalização.

Ator 1

Caso de Uso Filho 1

Caso de Uso Pai

Ator 2

Caso de Uso Filho 2

Fronteira do Sistema

Retângulo no interior do qual são inseridos os casos de uso. Os atores são posicionados do lado de fora do retângulo.

System

Ator 1

Caso de Uso 1

Ator 2

Caso de Uso 2

Ator 3

Quadro 4 - Notações utilizadas para representar elementos do Diagrama de Casos de uso Fone: Elaboração própria (2012)

Compreendendo os conceitos estudados até este ponto, envolvendo a modelagem

de requisitos funcionais, mediante especificação de casos de uso, e as notações

utilizadas para representar os elementos do digrama de casos de uso, é possível

49

aplicar os conceitos adquiridos, para modelar os requisitos funcionais básicos de um

sistema típico da área de vendas on-line.

Antes de desenhar o diagrama de casos de uso, é importante elaborar a lista de

atores e o resumo dos casos de uso do sistema, conforme a seguir.

A tabela abaixo identifica quais são os atores do sistema, considerando as

funcionalidades básicas de um sistema de vendas on-line.

Ator Objetivo

Cliente Ator pai (abstrato) no relacionamento de generalização com os atores filhos: “Cliente Internauta” e “Cliente Televendas”.

Cliente Internauta Fazer e consultar pedidos pela Internet. Cliente Televendas Fazer e consultar pedidos por telefone.

Atendente de Televendas Fazer e consultar pedidos, conforme solicitação do cliente, por telefone.

Serviço de Autorização do Pagamento

Serviço responsável por autorizar pagamentos com base nos dados do pagamento informados pelo cliente.

Quadro 5 – Atores do sistema de vendas on-line Fone: Elaboração Própria (2012)

Durante este estudo ficou demonstrado que os casos de uso modelam os requisitos

funcionais do sistema e que estes requisitos precisam se identificados e listados.

Uma forma de fazer isto é através da elaboração de uma listagem com resumo dos

casos de uso, ou, em outras palavras, uma listagem com um resumo dos requisitos

funcionais do sistema.

O quadro abaixo identifica e fornece um resumo dos casos de uso, considerando as

funcionalidades básicas de um sistema de vendas on-line. Apesar de fornecer uma

visão resumida, é possível identificar todos os elementos necessários para a

elaboração do diagrama de casos de uso, ou seja, atores, casos de uso,

relacionamentos de comunicação, inclusão, extensão e generalização.

Caso de Uso Resumo

Valida Usuário

O usuário informa login e senha e o sistema faz a autenticação dos dados fornecidos. Este caso de uso é incluído nos seguintes casos de uso: “Efetua Pedido pela Internet”, “Efetua Pedido por Telefone”, “Consulta Pedidos pela Internet”, e “Consulta Pedidos por Telefone”.

Efetua Pedido Caso de uso pai (abstrato) no relacionamento de generalização com os casos de uso filhos: “Efetua Pedido pela Internet” e “Efetua Pedido por Telefone”.

Efetua Pedido pela Internet

O “Cliente Internauta”, autenticado pelo sistema, efetua o pedido, com base nos itens que inseriu no carinho de compras, sendo o pagamento aprovado pelo “Serviço de Autorização do Pagamento”.

Efetua Pedido por Telefone O “Atendente de Televendas”, autenticado pelo sistema,

50

efetua o pedido, com base nas informações fornecidas, por telefone, pelo “Cliente Televendas”, sendo o pagamento aprovado pelo “Serviço de Autorização do Pagamento”.

Consulta Pedidos Caso de uso pai (abstrato) no relacionamento de generalização com os casos de uso filhos: “Consulta Pedido pela Internet” e “Consulta Pedido por Telefone”.

Consulta Pedidos pela Internet O “Cliente Internauta”, autenticado pelo sistema, consulta os pedidos, com base em uma lista dos últimos pedidos, ou informando dados do pedido para consulta.

Consulta Pedidos por Telefone O “Atendente de Televendas”, autenticado pelo sistema, consulta os pedidos, com base nas informações fornecidas, por telefone, pelo “Cliente Televendas”.

Informa Dados do Pedido

Estende os casos de uso “Consulta Pedidos pela Internet” e “Consulta Pedidos por Telefone”. Permite consulta através do número do pedido, período da compra ou dados pessoais (no caso de consulta por telefone).

Quadro 6 – Resumo dos casos de uso do sistema de vendas on-line Fone: Elaboração própria (2012)

Com base na lista de atores e no resumo de casos de uso do sistema de vendas on-

line é possível elaborar o diagrama de casos de uso.

System

Cliente

Atendente deTelevendas

Serviço deAutorização do

Pagamento

Valida Usuário

Efetua PedidoCliente Internauta

Cliente Televendas

Efetua Pedidopela Internet

Efetua Pedidopor Telefone

Consulta Pedidos

Consulta Pedidospela Internet

Consulta Pedidospor Telefone

Informa Dadosdo Pedido

<<include>>

<<include>>

<<extend>>

<<extend>>

<<include>>

<<include>>

Diagrama 1 – Diagrama de casos de uso do sistema de vendas on-line Fonte: Elaboração própria (2012)

51

CONCLUSÃO

Esta pesquisa viabilizou o desenvolvimento de um template próprio, adaptado de

alguns existentes no mercado, para o documento de especificação de casos de uso

e a modelagem das funcionalidades básicas de um sistema típico da área de vendas

on-line, fornecendo assim um exemplo de boas práticas na área de engenharia de

requisitos.

O estudo levou a uma reflexão sobre a necessidade de conceber um modelo para a

especificação de casos de usos, porque a UML não define uma formatação rígida

para a especificação de casos de uso, entretanto, no dia a dia, percebe-se a

necessidade de padronização, a fim de tornar a especificação de caso de uso mais

clara e inteligível por toda a equipe responsável pelo desenvolvimento e pelos

usuários que fazem parte do processo.

Para atingir este resultado, foi necessário explorar o tema de forma mais

abrangente, de acordo com os objetivos traçadas, os quais envolviam: analisar o

processo de modelagem de requisitos funcionais utilizando casos de uso; estudar os

conceitos básicos da engenharia de requisitos, através da definição de requisitos,

entendimento de sua importância e compreensão dos tipos de requisitos existentes,

sendo o estudo direcionado para os requisitos funcionais; compreender quais os

processos típicos da definição de Requisitos, através do estudo das atividades de

levantamento, análise, especificação, validação e gestão de requisitos; estudar a

modelagem de requisitos funcionais, utilizando casos de uso, compreendendo os

conceitos de modelagem de casos de uso e aplicando estes conceitos através do

estudo das funcionalidades básicas de um sistema típico da área de vendas on-line.

Observa-se no conteúdo do trabalho a concretização destes objetivos, sendo

possível delinear uma hipótese plausível para responder à questão que se constituiu

no problema de pesquisa, ou seja, como modelar requisitos funcionais utilizando

casos de uso?

A proposta, para solucionar o problema de pesquisa, foi alcançada. Envolveu a

obtenção de conhecimentos básicos dos conceitos da engenharia de requisitos, dos

processos típicos da definição de requisitos e dos elementos que compõem o

modelo de casos de uso. A partir desta fundamentação teórica, foi possível

52

desenvolver a especificação de casos de uso, de acordo com o template próprio e

elaborar o diagrama de casos de uso.

Este foi o caminho percorrido para solucionar o problema inicialmente proposto,

entretanto existem alternativas que se contrapõem ou complementam esta, como

por exemplo, a utilização de histórias de usuários ao invés de casos de uso, dentro

de um cenário de desenvolvimento ágil de sistemas. Este seria uma nova

perspectiva para abordagem da questão de como especificar requisitos funcionais,

abrindo-se, portanto, caminho para novas pesquisas na área de modelagem de

requisitos funcionais.

53

REFERFÊNCIAS

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML . 2ª ed. Rio de Janeiro: Elsevier, 2007. DOMINGUEZ, Jorge, Artigo de 01/07/2009: The Curious Case of the CHAOS Report 2009 . Disponível em <http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html>. Acesso em: 12/02/2012. FILHO, Wilson de Pádua Paula. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed. São Paulo: LTC, 2003. LARMAN, Graig. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientado a objetos e ao Processo unificado. 2ª ed. Porto Alegre: Bookman, 2004. PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª ed. São Paulo: Prentice Hall, 2004. PRESSMAN, Roger S. Engenharia de Software. 6ª ed. São Paulo: McGraw Hill, 2006. RAMOS, Ricardo Argenton. Treinamento Prático em UML. São Paulo: Digerati Books, 2006. SOMMERVILLE, Ian. Engenharia de Software . 6ª ed. São Paulo: Addison Wesley, 2003. STANDISH, The Standish Group 1995, THE STANDISH GROUP REPORT CHAOS . Tradução Google Tradutor. TECHY, Maria Cecília de Souza, Apostila: Requisitos Levantamento e Especificação , 3ª ed. São Paulo: Aspercom Serviços de Informática LTDA, 2008.

escola superior aberta do brasil - esab curso de … · direcionado para requisitos funcionais. o...

Documents