Faculdade Anhanguera

Curso Superior De Tecnologia Em Anlise E Desenvolvimento De

Sistemas- TADS

Fundamentos de Anlise Orientada a Objetos

2015

Faculdade Anhanguera

Curso Superior De Tecnologia Em Anlise E Desenvolvimento De

Sistemas - TADS

Fundamentos de Anlise Orientada a Objetos

2015

Atividade pratica Supervisionada - ATPS

Trabalho de atividade Prtica Supervisionada

entregue universidade Anhanguera como
foco no aumento de aprendizagem na
disciplina fundamentos da anlise orientada a
objeto.
Professor Rodrigo Hentz

Resumo
3

Esta Atividade Prtica Supervisionada (ATPS) tem como objetivo resolver o problema
organizacional da biblioteca da escola Bom Saber_XY, para manter a integridade dos
dados e o fluxo do mesmo para uma melhor gerncia, a escola designou a esquipe deste
trabalho para realizar a anlise de requisitos, a documentao do sistema e seus devidos
diagramas. Na anlise de requisitos percebeu-se que em uma biblioteca o
armazenamento dos livros e o controle dos emprstimos so as funes vitais. Para uma
melhor abstrao do sistema ser utilizada a linguagem UML, linguagem de modelagem
que utiliza diagramas para uma melhor documentao e organizao de um sistema.
Com este documento de especificao, o cliente e os desenvolvedores estaro a par de
tudo que se compe o projeto, de suas entidades at seus atores.

Palavras chave: UML, documento, especificao, biblioteca.

Abstract
4

This Practice Activity Supervised (ATPS) aims to solve the school library organizational
problem Bom Saber_XY, to maintain the integrity of the data and the flow of it for a
better management, the school designated the esquipe this work to perform
requirements analysis , system documentation and their proper diagrams. In the
requirements analysis it was observed that in a library storage of books and the control
of the loans are vital functions. For a better abstraction of the system will be used UML,
modeling language that uses diagrams for better documentation and organization of a
system. With this specification document, the client and the developers are aware of
everything that makes up the project, its entities to its actors.

Keywords: UML, document specification library.

Sumrio

Introduo........................................................................................................
.............04
Etapa 1 - Relatrio 1 Anlise dos
Requisitos........................................................................05
Resumo 1.1 - Anlise e Projetos Orientados a
Objetos.......................................................06
Resumo 1.2 Conceitos Gerais de Engenharia de
Software.................................................07
Resumo 1.3 Concepo, Elicitao e Tipos de
Requisitos................................................08
Resumo 1.4 Engenharia de
Requisitos............................................................................15
Listagem Informal dos Requisitos obtidos e problemas dessa
listagem.................................19
Listagem de Requisitos Funcionais e No Funcionais
validados..........................................20
Bibliografia

Etapa 1 - Introduo ao Levantamento e Anlise de Requisitos Orientados a

Objetos; Apresentao da UML. Abordagem resumida dos diagramas UML.
Apresentao de Ferramenta para modelagem de dados
Passo 1 Anlise e Projetos de Sistemas de informao Orientados a Objetos.
A UML (Linguagem de modelagem unificada) uma notao padro de diagramao,
uma linguagem que documenta, especifica e constri os artefatos de um sistema. Pode
ser usada como: Rascunho, Planta de software e Linguagem de programao e que pode
ser usada em 3 perspectivas: Conceitual, Especificao e Implementao, cada
perspectiva com seu significado de classe. Anlise e projeto orientados a objetos
Anlise: uma investigao, levantamento, anlise dos requisitos necessrios de um
projeto.
Projeto: Ele foca na soluo conceitual, que pode ser em hardware e em software, para
os requisitos levantados na anlise. Da nfase em cada objeto do software. Com muita
frequncia excluem dados ou detalhes de baixo nvel considerados bvios para os
consumidores ou simplesmente desnecessrios. Como citado no livro a anlise e o
projeto foram resumidos na frase: Faa a coisa certa (Anlise) e faa certa a coisa
(Projeto).
Os diagramas so usados para desenvolverem esses projetos como padres ou princpios
para serem mais eficientes em um desenvolvimento de um projeto dividido em etapas.
Definir: Casos de uso, Modelo de domnio, Diagramas de interao e de classe.
Definir casos de uso: So narrativas escritas ou cenrios exemplificando como usar a
aplicao.
Definir Modelo de domnio: Mostra o conceito de interesse do projeto.
Definir Diagramas de interao: Pode, por exemplo, mostrar o fluxo de mensagens entre
os objetos.
Definir Diagramas de classe: Ilustra os atributos e mtodos de classe, mostra a classe de
software que geralmente melhora a compreenso.

- Engenharia de software a engenharia que estuda os custos e as especificaes de um

projeto, visando um melhor aproveitamento dos recursos e um software de alta
qualidade. Os engenheiros de software utilizam-se de ferramentas para estudar a
viabilidade de um projeto, dentre estas ferramentas est o documento de especificao,
arquivo que consta todos os relatrios e diagramas, assim como uma estimativa de
custos e usurios chaves. A diagramao uma parte importante da anlise de requisitos
para a viabilidade do projeto, dentre os diagramas mais importantes esto o de caso de
uso e o diagrama de classe, ambos voltados para o melhor entendimento do cliente, j
que so mais simples e com pouco valor para o desenvolvimento do software ou
aplicativo. Este estudo minucioso com apoio da diagramao serve para evitar eventuais
prejuzos ou abstrao total do projeto. Sem a engenharia de software os programas
seriam muito mais caros, por que se no tem organizao burocrtica de um sistema os
desenvolvedores e o cliente se perdem nas especificaes do programa, alm de atrasos
pela falta de diagramas de Gannt por exemplo. A linguagem da diagramao da
engenharia de software a linguagem UML, padro no desenvolvimento de software e
de simples compreenso. Um bom engenheiro gera um bom estudo de viabilidade que
culmina em um bom software que deve ter facilidade de manuteno, confiana,
eficincia e usabilidade, gerando assim uma gratido do cliente e custos baixos.

Engenharia de Requisitos um aspecto importante no Gerenciamento de Projetos, a

responsvel por coletar dados indispensveis, necessrios, exigncias de que o usurio
necessite para solucionar um problema e alcanar seus objetivos. Assim como
determinar as suas expectativas de um usurio para determinado produto.
A anlise de requisitos um processo que envolve o estudo das necessidades do usurio
para se encontrar uma definio correta ou completa do sistema ou requisito de
software.
Essa anlise de requisitos vital para o desenvolvimento do sistema, ela vai determinar
o sucesso ou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos,
detalhados e relevantes para o projeto. Pois eles fornecero a referncia para validar o
produto final, estabelecero o acordo entre cliente e fornecedor sobre o que e o software
far e consequentemente reduziro os custos de desenvolvimento, pois requisitos mal
definidos implicam num retrabalho.

10

- Desenvolver softwares uma atividade complexa por natureza. Uma das razes para
esta afirmao que no existe uma nica soluo para cada cenrio de
desenvolvimento. Engenharia de software, uma rea de computao voltada
especificao, desenvolvimento e manuteno de sistemas de software, com aplicao
de tecnologias e prticas de gerncia de processos e outras disciplinas, visando a
organizao, produtividade e qualidade. Software : programa a parte lgica do
computador,

onde

fica

armazenados

base

de

dados.

Processo de software: pode ser definido como um conjunto coerente de atividades,

polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios
para conceber, desenvolver, dispor e manter um produto de software. Mtodos de
Engenharia de Software: um elemento que representa a uma chamada de um
procedimento para um Objeto, utilizado na programao orientada a objetos.
Atributos de um bom Software: manuteno, eficincia, confiana e usabilidade.
Desafios da engenharia de software: lidar com sistemas legados, lidar com diversidade,
inclui uma mistura entre hardware e software, sistemas legados, fornecimento e
heterogeneidade. Engenharia de Sistemas: e o que foca no desenvolvimento e
organizao de sistemas artificiais e complexos, a engenharia de sistemas integra outros
grupos de disciplinas. Processos de software: quando se fornece um servio ou cria-se
um produto, seja desenvolvendo um software, umas sequncias de etapas para
completar um conjunto de tarefas. Nos aspectos lgicos internos do software,
garantindo que todas as instrues tenham sido testadas nos aspectos funcionais
externos, para descobrir erros e garantir que a entrada definida produza resultados que
concordem com os esperados. Engenharia de Software baseada em componentes um
ramo de engenharia de software, com nfase na decomposio de sistemas, em
componentes lgicos com interfaces bem definidas, usadas para comunicao entre os
prprios componentes, num nvel de abstrao mais altos do que objetos.
Entrega incremental uma estratgia de planejamento estagiado em vrias partes do
sistema so desenvolvidas em paralelo e integrada quando completas. Desenvolvimento
em espiral um processo de desenvolvimento de software que combina elementos de
projeto prototipao em etapas um esforo para combinar. O software especificado
nesse documento uma ferramenta de modelagem grfica tridimensional mais simples
que as encontradas atualmente no mercado de software, os requisitos de software sero
classificados

em

requisitos

funcionais

requisitos

no

funcionais.

11

1.1 Conceitos Gerais da Engenharia de Software

Software algo abstrato e intangvel. So todos os dados de documentao e

configurao necessrios para que o programa opere. Engenharia de software uma
disciplina de engenharia que se relaciona com a produo de um software desde sua fase
inicial de especificao at sua manuteno. Baseia-se na existncia de um nmero
significativo de componentes reusveis para que no tenham que sempre comear do
zero. Um processo de software so as atividades e resultados de um software e sendo
quatro fundamentais comuns a todos os processos, so elas:
Especificao: Define o que vai ser produzido e suas restries. Desenvolvimento:
Projetar e programar o software. Validao: Verificao para conferir se realmente est
dentro do que foi especificado. Evoluo: modificado para se adaptar s mudanas de
requisitos.
Os atributos de um bom software so: A facilidade de manuteno, confiana, eficincia
e usabilidade. Os principais desafios na produo de um software so o da diversidade
(para que os sistemas operem com sistemas distribudos), o de tempo de entrega e o de
confiana dos usurios. Muitos softwares seguem o chamado Desenvolvimento
Evolucionrio (Desenvolvimento exploratrio e prototipao throwaway) para que com
comentrios do usurio possam ir refinando o programa at uma verso que satisfaa
totalmente e tambm para se adaptar a novas tecnologias disponveis. Engenharia de
Requisitos: Se divide em quatro fases: Estudo de viabilidade: Verifica se as
necessidades do usurio podem ser realmente satisfeitas. Licitao e Anlise de
Requisitos: Derivao de requisitos atravs da observao de sistemas existentes.
Especificao: Definir um conjunto de requisitos com as informaes coletadas.
Validao: Verifica os requisitos em relao ao realismo, consistncia e abrangncia.

12

Engenharia De Requisitos
1.2 Engenharia De Requisitos
A Engenharia de Requisitos, pode ser definida como o processo sistemtico de
desenvolvimento de requisitos atravs de um processo interativo e cooperativo de
anlise de problema de documentao de observaes resultantes em uma variedade de
formatos de representao e de checagem da preciso do entendimento obtido. O
processo de engenharia de requisitos um conjunto estruturado de atividades para
extrair requisitos, valid-los e mant-los.
As tcnicas de engenharia de requisitos referem-se ao conjunto de ferramentas
aplicveis ao desenvolvimento dos processos. Requisitos simplesmente, podem ser
definidos como "algo que um cliente necessita". Entretanto, do ponto de vista de um
desenvolvedor, requisito pode tambm ser definido como "algo que necessita ser
projetado". A engenharia de requisitos procura sistematizar o processo de definio de
requisitos. Essa sistematizao necessria porque a complexidade dos sistemas exige
que se preste mais ateno ao correto entendimento do problema antes
do comprometimento de uma soluo. As aquisies de requisitos so valorosas por
duas razes: primeiramente, da perspectiva da engenharia de software, a criao de
sistema solicitado pelo cliente talvez a mais crucial parte do processo de
desenvolvimento de software.
Os requisitos do sistema descrevem como o sistema visto pelo usurio e servir de
veculo de comunicao entre usurio e o desenvolvedor e tambm tornam ser requisitos
de software, pois apresentam as funcionalidades, restries e exigncias quanto
performance, segurana de acesso, interface com o usurio, portabilidade,
modularidade, manuteno, confiabilidade etc.

13

Elicitao dos Requisitos

Das seis etapas do clico de vida de um sistema (Engenharia de Sistemas, Anlise,
Projeto, Implementao, Teste e Manuteno) a engenharia de requisitos ocorre de
forma intensa nas trs primeiras etapas, porm pode se estender para as demais
dependendo

do

paradigma

engenharia

de

software

adotado.

As fases so: Elicitao, Anlise, Especificao e Validao sendo que entre a validao
e a anlise preciso haver um gerenciamento. Na Elicitao deve abordar quatro
dimenses: Entendimento do domnio da aplicao, Entendimento do problema,
Entendimento do negcio e Entendimento das necessidades e restries dos envolvidos.
E, na Elicitao o Entendimento do domnio da aplicao O conhecimento do domnio
da aplicao o conhecimento geral onde o sistema ser aplicado. Entendimento do
problema. Os detalhes problema do cliente onde o sistema ser aplicado devem ser
entendidos. Entendimento do negcio Deve-se entender como os sistemas interagem e
contribuem de forma geral com os objetivos de negcio. Os problemas enfrentados na
Elicitao so analisados a partir de dois grandes grupos: Problemas Acidentais e
Essenciais

sendo

os

essenciais

mais

difceis

de

serem

superados

As tcnicas de Elicitao so: Introspeco, Observao, Questionrio, Entrevista, JAD

(Joint Application Design), compreenso, entendimento e trabalho em grupo, Anlise de
Protocolo, Anlise

de

Discurso, Prototipao,

Casos

de

Uso

Cenrios.

A anlise tem por objetivo encontrar os possveis problemas obtidos na Elicitao

(declarao informal) tornando-os muito vinculados. Trs elementos fundamentais
devem ser verificados: Verificao de Necessidade, Consistncia e Possibilidade.
A Especificao de Requisitos nada mais do que o resultado da Elicitao e Anlise
sendo transformados em documentos que organizam os requisitos do sistema utilizando
metodologia de desenvolvimento de sistema e facilitam a comunicao entre
desenvolvedores

usurios

principalmente

na

validao

dos

requisitos.

As tcnicas de especificao se classificam em dois grandes grupos: Semi-formais:

UML e etc. Formal: DSR (Documento de Requisitos do Sistema) Tais documentos
tambm so chamados de artefatos de software assumindo um papel fundamental no
desenvolvimento de sistemas. Os principais benefcios obtidos pelos documentos
gerados so: Ponte de comunicao entre usurios e desenvolvedores; Registro dos
resultados obtidos durante a Elicitao e Anlise; Define as necessidade e restries
Serve de base para estimativa de custos e cronograma; base para desenvolvimento de
14

plano de teste; Definio de padro de comportamento esperado pelos profissionais

envolvidos na manuteno e utilizado para registro de mudanas de engenharia.
A Validao a fase final da engenharia de requisitos e tem por objetivo verificar e
validar os requisitos especificados envolvendo tanto usurios quanto desenvolvedores
buscando identificar possveis problemas, omisses e ambiguidades. Os principais
problemas so: no atendimento a padres de qualidade, requisitos descritos de forma
pobre levando ambiguidade, erros na modelagem do problema ou sistema e requisitos
conflitantes no identificados durante a anlise. Tais problemas devem ser sanados que
o documento de especificao seja aprovado e utilizado para desenvolver o sistema
gerando a Lista de Problemas e Aes Acordadas Gerenciamento uma etapa que se
desenvolve em paralelo em toda a atividade citadas anteriormente, onde no decorrer do
tempo, os requisitos se alteram devido s mudanas de ambiente e um melhor
entendimento do usurio sobre suas reais necessidades. As principais questes
relacionadas ao gerenciamento de requisitos so: Gerenciamento de mudanas em
requisitos j acordados, relacionamento entre os requisitos e gerenciamento das
dependncias entre os documentos de requisitos e outros documentos produzidos
durante o processo de engenharia de software. As mudanas, que ocorrem o tempo todo,
resultam de uma combinao de fatores: Inconsistncias, conflitos e falhas nos
requisitos especificados; Evoluo do conhecimento do usurio; Problemas de custos,
cronograma ou tcnicos; Alterao de prioridade do cliente; Alteraes de ambiente e
Alteraes organizacional.
Segundo Larman: So capacidades e condies s quais o sistema e em termos mais
amplos, o projeto deve atender. No so apenas funcionalidades Comumente
classificados em funcionais e no funcionais.
1.3 Requisitos Funcionais e No Funcionais
Requisitos funcionais: eles vo estabelecer como o sistema vai agir, e o que deve fazer,
as funcionalidades e servios do sistema, devendo ser descritos detalhadamente. Nesta
face, pode-se usar o MER, modelos de casos de uso, fluxogramas, para facilitar o
entendimento das funes do sistema. E requisitos Funcionais que so as
funcionalidades do sistema, o que o software deve fazer do ponto de vista do usurio.
Requisitos no funcionais: definem as propriedades do sistema e suas restries. Ex.: a
confiabilidade do sistema, o tempo de resposta do programa, o espao em disco. E
15

requisitos No-Funcionais que determinam as caractersticas desejveis do software

como desempenho, confiabilidade, segurana entre outros.
Cada

requisito

funcional

no

funcional

formam

estudo

de

casos

Engenharia de requisitos no contexto do desenvolvimento de software.

Tabela de Requisitos Funcionais

RF1
RF2
RF3
RF4
RF5
RF6
RF7
RF8

O sistema deve fazer um cadastramento de usurios

O sistema de fazer um cadastramento dos livros
O sistema deve Controlar lista de livros alugados diariamente e data da devoluo
O sistema deve realizar a reserva de livros on-line
O sistema deve permitir importao de dados cadastrais
O sistema deve realizar backups, para possvel perda de informaes
O sistema deve controlar a quantidade de livros no estoque com o que tem
Gerar Relatrios com quantidades alugados e parados.

Tabela de Requisitos No Funcionais

RNF1
RNF2
RNF3
RNF4
RNF5
RNF6

O sistema deve exigir login de usurio

O sistema deve apresentar mensagens de sucesso na concluso de cadastros
O sistema deve apresentar mensagens de campos obrigatrios no preenchidos
O sistema deve disponibilizar ajuda para novos usurios com dicas de preenchimento
O sistema deve disponibilizar acesso ao manual de ajuda
O sistema deve conter opo de busca rpida, utilizando palavra chave.

Listagem informal dos requisitos obtidos.

Como forma de aproximar e melhorar a comunicao com o cliente a listagem informal
de requisitos foi produzida com base nos requisitos bsico citados no tpico anterior. A
listagem foi produzida j com os requisitos finais necessrios para o sistema ser
produzido com qualidade e que agrade o cliente em seus aspectos.

16

1) O sistema deve fazer um cadastramento de usurios;

2) O sistema de fazer um cadastramento dos livros;
3) O sistema deve Controlar lista de livros alugados diariamente e data da
devoluo;
4) O sistema deve realizar a reserva de livros on-line;
5) O sistema deve permitir importao de dados cadastrais;
6) O sistema deve realizar backups, para possvel perda de informaes;
7) O sistema deve controlar a quantidade de livros no estoque com o que tem;
8) Gerar Relatrios com quantidades alugados e parados.

Problemas encontrados
No foi mencionado nada sobre rotinas de backup e tal requisito necessrio devido
grande quantidade de dados cadastrais exigidos.
No foi mencionado sobre a possibilidade de importar dados de sistemas de terceiros
visando aproveitar dados e dar agilidade nos dados cadastrais.

Listagem dos Requisitos Funcionais e No Funcionais validados

Requisitos Funcionais
O software deve permitir o cadastro do usurio (aluno, funcionrio) da escola;
O software deve permitir o cadastro de livros, jornais e revistas. (Incluso,
excluso, alterao)
O software deve garantir que todos os usurios tenham acesso ao sistema dentro
das suas especificaes: alunos (para realizar emprstimo) e funcionrio (para
gerenciar os emprstimos).
O software deve garantir que apenas usurios autenticados tenham acesso ao
sistema
O software deve permitir que usurios possam recuperar sua senha.
O software deve permitir que usurios tenham acesso os livros, jornais e revistas
disponveis.
O software deve permitir que o usurio possa realizar reserva de livros e data de
disponibilidade para o emprstimo.
O software deve informar indisponibilidade dos livros.
O software deve permitir que os funcionrios possam ter acesso aos emprstimos
dos alunos.
O software deve informar a data de devoluo dos emprstimos.

Requisitos No funcionais
17

O sistema deve exigir login e senha para acesso.

O sistema deve ser atualizado online, assim que confirmar a reserva dos livros.
O sistema deve disponibilizar ferramenta de busca.
O sistema deve rodar em qualquer plataforma
O sistema deve informar aos usurios quando o livro procurado estiver

disponvel.
O sistema deve bloquear o cadastro quando expirar o prazo para devoluo.
O sistema deve gerar alerta para o aluno e os funcionrios que o emprstimo
teve o prazo expirado.

Etapa 2. Diagramas de Casos de Uso, Documentao dos Casos de Uso.

Atores, Associaes (Incluso, Extenso); Diagramas de Classes e Objetos da
UML.
Resumo 2.1 Casos de Uso
Casos de uso so narrativas em texto, descrevendo a unidade funcional, e so
amplamente utilizados para descobrir e registrar requisitos de sistemas. Os diagramas de
Casos de Uso so representaes dos Casos de Uso e podem ser representados por uma
18

elipse contendo, internamente, o nome do caso de uso. Um caso de uso representa uma
unidade discreta da integrao entre um usurio (humano ou mquina) e o sistema.
Um caso de uso uma unidade de um trabalho significante. Por exemplo: o "login para
o sistema", "registrar no sistema" e "criar pedidos" so todos casos de uso. Cada caso de
uso tem uma descrio o qual descreve a funcionalidade que ir ser construda no
sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou
"estender" outro caso de uso com seu prprio comportamento. Casos de uso so
tipicamente relacionados a "atores". Um ator um humano ou entidade mquina que
interage com o sistema para executar um significante trabalho. importante notar que
no descreve como o software dever ser construdo, mas sim como ele dever se
comportar quando estiver pronto. Um software frequentemente um produto complexo,
e sua descrio envolve a identificao e documentao de vrios casos de uso, cada um
deles descrevendo uma "fatia" do que o software ou uma de suas partes dever oferecer.
Normalmente evitam o uso de termos tcnicos, preferindo a linguagem do utilizador
final, so empregados tanto por quem desenvolve o software quanto pelos utilizadores
do software.
Ator:

algum

ou

alguma

coisa

que

interage

com

sistema.

** Um ator e representado graficamente por um cone de um homenzinho (Stckman.).

**Atores podem ter relacionamentos de generalizao entre eles (uma vez que
representam classes).
Relacionamentos:
Generalizao: significa que um caso de uso de um filho herda o comportamento e o
significado do pai, generalizao e a representao graficamente por uma linha solidam
com um triangulo numa das extremidades.

Relacionamentos:
Associao e uma ligao que pode ocorrer entre ator e caso de uso e entre casos de uso.
Esteretipos comuns para associao entre casos de uso so: A associao com o
esteretipo indica que o caso de uso base incorpora opcionalmente o comportamento do
caso de uso estendido. A associao com o esteretipo indica que o caso de uso base
incorpora explicitamente o comportamento do outro caso de uso.
19

Resumo 2.2 Diagrama de Casos de Uso

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicao entre os
analistas e o cliente.
Um diagrama de Caso de Uso descreve um cenrio que mostra as funcionalidades do
sistema do ponto de vista do usurio. O cliente deve ver no diagrama de Casos de Uso
as principais funcionalidades de seu sistema. Um caso de uso representado por uma
elipse e um rtulo com o nome do caso de uso. Um caso de uso define uma grande
funo do sistema. A implicao que uma funo pode ser estruturada em outras
funes e, portanto, um caso de uso pode ser estruturado. Define uma funcionalidade do
sistema do ponto de vista do usurio. O diagrama de Caso de Uso representado por:
atores; casos de uso; relacionamentos entre estes elementos, estes relacionamentos
podem ser: Associaes entre atores e casos de uso;
Generalizaes entre os atores;
Generalizaes, extends e includes entre os casos de uso. Casos de uso podem
opcionalmente estar envolvidos por um retngulo que representa os limites do sistema.

Resumo 2.3 Diagramas de Classe UML

Classe Objetivo
Descrever os vrios tipos de objetos no sistema e o relacionamento entre eles.
Um diagrama de classes pode oferecer trs perspectivas, cada uma para um tipo de
observador diferente. So elas conceituais.

20

Representa os conceitos do domnio em estudo. Perspectiva destinada ao cliente.

Especificao.
Tem foco nas principais interfaces da arquitetura, nos principais mtodos, e no como
eles iro ser implementados.
Perspectiva destinada as pessoas que no precisam saber detalhes de desenvolvimento,
tais como gerentes de projeto. Implementao - a mais utilizada de todas (veja exemplo
na figura abaixo), aborda vrios detalhes de implementao, tais como navegabilidade,
tipo dos atributos, etc. Perspectiva destinada ao time de desenvolvimento.

Diagrama de Caso de Uso

Diagrama de Classes

21

Concluso
A anlise de requisitos engloba todas as tarefas que lidam com investigao, definio e
escopo de novos sistemas ou alteraes. Anlise de requisitos uma parte importante do
22

processo de projeto de sistemas, na qual o engenheiro de requisitos e o analista de

negcio, juntamente com engenheiro de sistema ou desenvolvedor de software,
identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos do
sistema tenham sido identificados, os projetistas de sistemas estaro preparados para
projetar a soluo.
A anlise de requisitos a primeira fase de desenvolvimento de software dividido em
Requisito funcional e Requisito no-funcional. nesta fase que o analista faz as
primeiras reunies com os clientes e/ou usurios do software para conhecer as
funcionalidades do sistema que ser desenvolvido. nesta fase tambm que ocorre a
maior parte dos erros, pois a falta de experincia dos clientes ou usurios faz com que
eles nem sempre tenham claro em sua mente quais funcionalidades o software ter.
Um caso de uso um tipo de classificador representando uma unidade funcional
coerente provida pelo sistema, subsistema, ou classe manifestada por sequncias de
mensagens intercambiveis entre os sistemas e um ou mais atores.
Casos de uso so narrativas em texto, descrevendo a unidade funcional, e so
amplamente utilizados para descobrir e registrar requisitos de sistemas. Os diagramas de
Casos de Uso so representaes dos Casos de Uso e podem ser representados por uma
elipse contendo, internamente, o nome do caso de uso.
Um caso de uso representa uma unidade discreta da interao entre um usurio (humano
ou mquina) e o sistema. Um caso de uso uma unidade de um trabalho significante.
Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" so todos
casos de uso. Cada caso de uso tem uma descrio o qual descreve a funcionalidade que
ir ser construda no sistema proposto. Um caso de uso pode "incluir" outra
funcionalidade de caso de uso ou "estender" outro caso de uso com seu prprio
comportamento.
Casos de uso so tipicamente relacionados a "atores". Um ator um humano ou
entidade mquina que interage com o sistema para executar um significante trabalho.
importante notar que no descreve como o software dever ser construdo, mas sim
como ele dever se comportar quando estiver pronto. Um software frequentemente um
produto complexo, e sua descrio envolve a identificao e documentao de vrios
casos de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas
partes dever oferecer.
Normalmente evitam o uso de termos tcnicos, preferindo a linguagem do utilizador
final, so empregados tanto por quem desenvolve o software quanto pelos utilizadores
do software.

Bibliografia
LARMAN, Craig. Utilizando UML e padres:
Uma introduo a anlise e ao projeto orientados a objetos e ao desenvolvimento
iterativo. 3 ed. Porto Alegre: Bookman, 2008.
23

Conceitos Gerais de Engenharia de Software - Disponvel em:

https://docs.google.com/file/d/0B2k9x8w9Y2JfOHVMdUJsS0NQX1k/edit?
usp=sharing
FASE DE CONCEPO AOO Disponvel em
http://americoneto.wordpress.com /2009/12/09/fase-de-concepcao-aoAcesso em
ELICITAO DE REQUISITOS E SUAS TCNICAS - Disponvel em Acessado em
TIPOS DE REQUISITOS Disponvel em <
http://felipe.wikicode.com.br/2009/01/tipos-de-requisitos.html> Acesso em
ENGENHARIA DE REQUISITOS - Disponvel em: < https://docs.google.com/file/d/
0B2k9x8w9Y2JfNjFEV3FTTHJyYTA/edit>

DIAGRAMA DE CASOSDE USO - Disponvel em < https://docs.google.com/file/d/

0B2k9x8w9Y2JfOHFfN1B5R2g0LUk/
Diagrama de Classes Disponvel em < http://www.dsc.ufcg.edu.br/~jacques/
cursos/map/html/uml/diagramas/classes/classes1.htm

24