Post on 21-Jan-2019
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
DAMIÃO GONÇALVES DOS SANTOS FILHO
MODELAGEM DE REQUISITOS FUNCIONAIS MEDIANTE
ESPECIFICAÇÃO DE CASOS DE USO
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
DAMIÃO GONÇALVES DOS SANTOS FILHO
MODELAGEM DE REQUISITOS FUNCIONAIS MEDIANTE
ESPECIFICAÇÃO DE CASOS DE USO
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.
Histórico de Revisões Data Versão Descrição Autor
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.
3.2. Fluxos Alternativos
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.
2. Retorna ao passo 3.1.1 do fluxo básico.
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.
2. Retorna ao passo 3.1.1 do fluxo básico.
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.
2. Retorna ao passo 3.1.1 do fluxo básico.
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.
Sistema de Vendas On-Line
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”.
Histórico de Revisões Data Versão Descrição Autor
12/03/2012 1.0 Criação do documento Damião
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
3.2. Fluxos Alternativos
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.
2. Retorna ao passo 3.1.9 do fluxo básico.
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.
2. Retorna ao passo 3.1.6 do fluxo básico.
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.
2. Retorna ao passo 3.1.7 do fluxo básico.
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”.
Sistema de Vendas On-Line
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.
Histórico de Revisões Data Versão Descrição Autor
42
16/03/2012 1.0 Criação do documento Damião
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
3.2. Fluxos Alternativos
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.
2. Retorna ao passo 3.1.5 do fluxo básico.
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
1. Retorna ao passo 3.1.1 do fluxo básico.
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)
Sistema de Vendas On-Line
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.
Histórico de Revisões Data Versão Descrição Autor
18/03/2012 1.0 Criação do documento Damião
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”.
3.2. Fluxos Alternativos
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:
1. Retorna ao passo 3.1.3 do fluxo básico.
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.