E2_ANPS

Prévia do material em texto

E-book 2
ANÁLISE E PROJETO 
DE SISTEMAS
Gláucia Silva Bierwagen
Neste E-Book:
INTRODUÇÃO ���������������������������������������������� 3
ELICITAÇÃO DE REQUISISTOS DE 
SISTEMAS ORIENTADOS A OBJETOS ��4
Elicitação de um requisito ���������������������������������������6
Técnicas para elicitação de requisitos �������������������8
Dificuldades para elicitação de requisitos ���������� 11
ESPECIFICAÇÃO DE REQUISISTOS 
DE SISTEMAS ORIENTADOS A 
OBJETOS ������������������������������������������������������13
Requisitos �������������������������������������������������������������� 13
A especificação de requisitos ������������������������������ 15
As especificações estruturadas ��������������������������� 17
Estrutura de documentos de especificação de 
requisitos ��������������������������������������������������������������� 20
ANÁLISE DE REQUISITOS ���������������������� 22
VALIDAÇÃO DE REQUISITOS ����������������26
FERRAMENTAS DE MODELAGEM �������28
CONSIDERAÇÕES FINAIS ����������������������30
SÍNTESE ��������������������������������������������������������31
2
INTRODUÇÃO
Neste módulo você aprenderá o que é elicitação ou 
levantamento de requisitos – uma fase muito impor-
tante na elaboração de softwares e sistemas� Ela 
envolve muito diálogo entre desenvolvedores, clientes 
e usuários finais para que o produto tenha sucesso.
Você estudará, também, quem são os principais 
atores envolvidos no desenvolvimento de um siste-
ma, como projetistas, gerentes, etc.; conhecerá as 
principais técnicas de elicitação de requisitos, como 
entrevistas, observações, dentre outras. Além disso, 
compreenderá melhor o que são requisitos e quais 
são os seus principais tipos; bem como os tipos de 
escrita na especificação de requisitos, ou seja, a fase 
de escrita da documentação�
Em seguida, você compreenderá que na análise de 
projetos é necessário identificar fases que auxiliam 
a ter detalhes pormenorizados do projeto, como: pro-
jeto de algoritmos, de interface gráfica, entre outros. 
Você conhecerá as principais verificações e técnicas 
de validação de requisitos e, por fim, estudará alguns 
exemplos de ferramentas de modelagem.
Aproveite a leitura!
3
ELICITAÇÃO DE 
REQUISISTOS DE SISTEMAS 
ORIENTADOS A OBJETOS
Neste tópico você aprenderá que, para que um pro-
jeto de desenvolvimento de sistema dê certo, é im-
portante que ele atenda o cliente� Sendo assim, é 
preciso que se registre e valide – por meio de do-
cumentação – todas as necessidades do cliente� 
Isso é muito importante, pois, durante a finalização 
e entrega do produto, o cliente pode expressar que 
aquele não foi o produto que solicitou� Mas, como é 
possíviel comprovar que o produto elaborado está 
compatível com o que foi solicitado?
A solução para isso é fazer um levantamento de do-
cumentação chamada de requisitos. O que é isso? 
Requisitos é o nome que se dá ao conjunto de docu-
mentos de descrições dos serviços que serão ofere-
cidos pelo sistema e suas restrições operacionais, 
de modo que satisfaça as necessidades/desejos 
do cliente. Os requisitos do usuário referem-se às 
necessidades dos clientes, e os requisitos do siste-
ma relacionam-se às descrições mais detalhadas 
das funções, serviços e restrições operacionais do 
próprio sistema�
Essa documentação deve estar alinhada e ser vali-
dada pelo cliente e a equipe de desenvolvimento de 
softwares ou sistemas� É importante que você saiba 
que, dentro do escopo dos requisitos, é necessário 
4
manter a rastreabilidade entre os elementos, visto 
que os demais elementos são evoluções do docu-
mento, no decorrer do projeto (GONÇALVES, 2015; 
BEZERRA, 2007; FOWLER, 2005).
FIQUE ATENTO
É importante que você saiba que o termo de 
rastreabilidade é usado para realizar um mape-
amento que é feito entre os elementos que se re-
lacionam� Esse mapeamento pode ser feito por 
planilhas e por pares, por exemplo, requisitos fun-
cionais versus casos de uso (SOMMERVILLE, p. 
2019, p. 78).
A geração de um documento de requisitos é realizada 
a partir do levantamento, mediante informações dos 
usuários. Após a criação desse documento, faz-se 
a especificação de casos de uso (ou história dos 
usuários). A seguir, temos os seguintes passos:
1. Criação de diagramas da UML para cada especi-
ficação de caso de uso.
2. Desenvolvimento de códigos a partir dos diagra-
mas gerados e da especificação de caso de uso (ou 
história do usuário).
3. Criação de planilhas de teste, tendo como base a 
especificação de caso de uso (ou história do usuário).
4. Validação pelo cliente do software desenvolvi-
do, sendo que os requisitos que foram aceitos por 
5
ele são utilizados como parâmetro para validar o 
sistema�
5. Finalmente, quando o software encontra-se 
em estágio de evolução, o documento de requisi-
tos é a raiz das mudanças a serem implementadas 
(GONÇALVES, 2015; SOMMERVILLE, 2019).
Em seguida, você estudará as principais técnicas e 
tecnologias envolvidas na Elicitação de Requisistos, 
ou seja, o levantamento e a compreensão destes�
Elicitação de um requisito
Para fazer o levantamento ou elicitação de requisitos 
é necessário que os profissionais envolvidos no de-
senvolvimento de software relacionem-se diretamen-
te com os clientes – que podem somente contratar 
os sistemas e não usá-los, ou serem os usuários 
finais do sistema – para aprender sobre o domínio 
da aplicação, as funcionalidades do sistema, o de-
sempenho esperado e as restrições de infraestrutura. 
Nesta fase de levantamento é importante saber que 
o trabalho colaborativo de vários profissionais trará 
uma visão mais abrangente para elencar todos os 
requisitos. A reunião de informações virá de docu-
mentação e interação com stakeholders, ou seja, o 
público de interesse para levantamento de requisitos�
Mas, quem são os principais atores da equipe 
de desenvolvimento? Podemos ter os seguintes 
profissionais:
6
 ● Gerentes de Projetos: são os profissionais respon-
sáveis pela gerência ou coordenação das atividades 
necessárias à construção do sistema; elaboração 
de orçamentos, cronogramas de execução das ati-
vidades, definição do processo de desenvolvimento, 
atribuições da equipe, os recursos de hardware e 
software, etc�
 ● Analistas: são os profissionais que compreendem 
os problemas do domínio do negócio para que pos-
sam definir os requisitos do sistema a ser desen-
volvido. São profissionais que, além de ter conhe-
ciemtno básico da área de domínio, devem ter boa 
comunicação com os especialistas do domínio para 
obter conhecimento acerca dos problemas e das ne-
cessidades envolvidas na organização empresarial.
 ● Projetistas: são os integrantes da equipe de de-
senvolvimento cujas funções são: (1) avaliar as al-
ternativas de solução (da definição) do problema 
resultante da análise e (2) gerar a especificação de 
uma solução computacional detalhada.
 ● Arquitetos de software: são profissionais que ela-
boram a arquitetura do sistema como um todo� Este 
profissional é quem toma decisões sobre quais se-
rão os subsistemas que compõem o sistema como 
um todo e quais serão as interfaces entre esses 
subsistemas�
 ● Programadores: são os profissionais responsáveis 
pela implementação do sistema. Podem ser profi-
cientes em uma ou mais linguagens de programação, 
7
além de conhecer banco de dados. Um projeto mais 
complexo poderá ter vários programadores.
 ● Especialistas de domínio ou especialistas de ne-
gócio: são os profissionais que possuem conheci-
mentos sobre a área ou do negócio em que o sistema 
em desenvolvimento estará inserido�
 ● Avaliadores de qualidade: são profissionais que 
asseguram a adequação do processo de desenvol-
vimento e do produto de software, conforme os pa-
drões de qualidade estabelecidos pela organização 
(BEZERRA, 2007, pp. 31-35).
Além da equipe responsável pelo desenvolvimento, 
temos outros atores envolvidos, como os stakehol-
ders, que são o público de interesse para o levanta-
mento de requisitos� Além deles, outras fontes de 
requisitos são: ambientefísico, documentação (for-
mulários, por exemplo), dados existentes, recursos 
existentes, sistemas legados e Segurança. Realizar 
a extração dos requisitos do domínio do problema 
não é uma tarefa fácil� Mas, o que pode contribuir 
para isso? Vamos conferir?
Técnicas para elicitação de 
requisitos
 ● A realização de entrevistas – a equipe análise de 
sistemas reúne-se com o(s) stakeholder(s) para uma 
conversa sobre as necessidades e expectativas em 
relação ao sistema a ser desenvolvido�
8
 ● A observação do ambiente onde a aplicação irá 
funcionar, com o objetivo de captar informações 
acerca do funcionamento dos processos da empresa�
 ● Etnografia de uma imersão total no ambiente dos 
clientes, por meio de observação�
 ● A demonstração de tarefas específicas pode ser 
mostrada detalhadamente e repetidas vezes. Diante 
desse cenário, a técnica de demonstração de tarefa 
é utilizada; os stakeholders fazem a demonstração 
das tarefas aos analistas de sistemas�
 ● Estudo de documento em papel – formulários de 
cadastro e relatórios já utilizados auxiliam bastante 
a atividade de elicitação de requisitos, uma vez que 
estes podem revelar um conjunto de dados esperado 
para uma funcionalidade�
 ● Substituição do usuário (role playing) em tarefas 
específicas e complexas, em que o analista repete 
os passos, sendo auxiliado pelo usuário em relação 
às dúvidas que possam surgir.
 ● A aplicação de um questionário que pode consistir 
em um conjunto de perguntas que devem ser respon-
didas pelos usuários� Serve para tirar dúvidas com 
relação aos requisitos já elicitados ou na descoberta 
de novos�
 ● A técnica de brainstorming (tempestade de ideias) 
permite que os participantes de diferentes perfis em 
uma reunião, durante um período de tempo estabele-
cido, possam ditar ideias, que são escritas de modo 
que todos visualizem. Quando a sessão se encerra, 
9
as repetições de ideias são retiradas e as que geram 
dúvidas são explicadas. As melhores ideias esco-
lhidas coletivamente são analisadas, melhoradas e 
aproveitadas�
Figura 1:  Brainstorming. Fonte: Pexels.
 ● A prototipação consiste na criação de um esboço 
inacabado que demonstre uma determinada fun-
cionalidade do sistema� Normalmente, esse esboço 
representa a parte de interface gráfica, com os for-
mulários, com botões e campos de texto; no entanto, 
sem acesso a banco de dados, tratamento de cam-
pos ou processamento de cálculos�
 ● Os workshops ou oficinas de requisitos podem 
reunir todos os envolvidos durante um período cur-
to, mas intensivo e focado� Nesse período, várias 
técnicas mencionadas podem ser aplicadas se-
10
https://www.pexels.com/pt-br/foto/brainstorm-comodo-complexo-complicado-212286/
quencialmente (BEZERRA, 2007; GONÇALVES, 2015; 
SOMMERVILLE, 2019).
Dificuldades para elicitação de 
requisitos
A elicitação e a compreensão dos requisitos dos 
stakeholders e análise desses é um processo com 
feedback contínuo de cada atividade para as outras 
atividades, que começa com a descoberta de requi-
sitos e termina com sua documentação� No entanto, 
essa tarefa não é fácil, pois stakeholders:
1. costumam não saber o que querem de um siste-
ma computacional; eles podem achar difícil articular 
o que querem que o sistema faça, e, como não sabem 
o que é viável e o que não é, podem fazer exigências 
inviáveis�
2. expressam requisitos em seus próprios termos 
e com o conhecimento implícito de seu próprio 
trabalho.
3. de vários perfis podem ter requisitos diferentes 
e podem expressar essas diferenças de várias ma-
neiras. Os analistas de requisitos precisam descobrir 
todas as potenciais fontes de requisitos e descobrir 
as semelhanças e conflitos (SOMMERVILLE, 2019, 
p. 71).
Além destes, fatores políticos – como a posição de 
um stakeholder – podem influenciar os requisitos 
11
do sistema. O ambiente econômico e empresarial 
– que são dinâmicos – podem interferir na análise, 
suprimindo, alterando, ou no surgimento de outros 
requisitos�
Podcast 1 
Em seguida, você analisará quais são os tipos de 
requisitos e a Especificação de Requisitos, ou seja, 
a documentação escrita dos requisitos�
12
https://famonline.instructure.com/files/707594/download?download_frd=1
ESPECIFICAÇÃO DE 
REQUISISTOS DE SISTEMAS 
ORIENTADOS A OBJETOS
Neste tópico, você aprenderá sobre quais são os 
tipos de requisitos e a Especificação de Requisitos, 
ou seja, a documentação escrita de requisitos�
Requisitos
Como estudamos anteriormente, existem os requisi-
tos de usuários e os do próprio sistema� Você apren-
derá também o que são os requisitos funcionais e 
não funcionais� Vamos lá?
 ● Requisitos funcionais são declarações de serviços 
que o sistema deve fornecer, de como o sistema deve 
reagir a entradas específicas e de como o sistema 
deve se comportar em determinadas situações ou 
não deve fazer.
 ● Requisitos não funcionais são restrições aos ser-
viços ou funções oferecidos pelo sistema. Incluem 
restrições de timing, restrições no processo de desen-
volvimento do software, e restrições impostas pelas 
normas das organizações e legislações. Ao contrário 
das características individuais ou serviços do sis-
tema, os requisitos não funcionais, muitas vezes, 
aplicam-se ao sistema como um todo� São requisitos 
usados para garantir a confiabilidade e o desempe-
nho do sistema, a segurança e a usabilidade.
13
 ● Requisitos de domínio, por sua vez, refletem ne-
cessidades relacionadas ao domínio da aplicação 
e incluem uma terminologia específica de domínio 
ou fazem referência a conceitos do domínio. Podem 
estar relacionados com: velocidade de execução, 
confiabilidade, interoperabilidade com outros siste-
mas e leis que estejam relacionadas ao domínio da 
aplicação (vide figura 2) (SOMMERVILLE, 2019, p. 60).
Requisitos de 
eficiência
Requisitos de 
confiança
Requisitos de 
proteção
Requisitos 
reguladores
Requisitos 
éticos
Requisitos de 
usabilidade
Requisitos 
organizacionais
Requisitos não 
funcionais
Requisitos 
legais
Requisitos de 
desenvolvimento
Requisitos 
operacionais
Requisitos 
ambientais
Requisitos de 
segurança/ 
proteção
Requisitos 
contábeis
Requisitos 
externos
Requisitos de 
produto
Diagrama de 
Implantação
Diagrama de 
Pacotes
Figura 2: Figura 2. Tipos de requisitos não funcionais. Fonte: 
Sommerville (2019) adaptado.
14
A especificação de requisitos
Durante a especificação dos requisitos – ou seja, a 
documentação escrita de requisitos – é necessário 
que o texto seja escrito com muita clareza para evitar 
ambiguidades que, eventualmente, ocorrem na escri-
ta de textos em Língua Portuguesa. A escrita clara 
evita má interpretação e a criação de elmentos de 
forma errada. Que elementos são esses? Diagramas, 
códigos, protótipos de interface e planilhas de testes. 
Duas propriedades são muito importantes para evitar 
ambiguidades na escrita: completeza e consistên-
cia. Completeza significa que tudo que o usuário 
precisa que seja implementado esteja definido, e 
consistência significa que os requisitos não devem 
ter definições contraditórias.
FIQUE ATENTO
Observe como exemplo a seguinte definição con-
traditória, escrita em um documento de requisi-
tos: “Inicialmente, nenhum usuário deve vir pré-
-cadastrado no sistema”; mas, em outro trecho, 
lemos uma informação contraditória: “O primeiro 
acesso ao sistema deve ser feito com o perfil de 
adminstrador, que deve vir pré-cadastrado”�
O uso de jargões e siglas computacionais também 
deve ser evitado na escrita dos requisitos� Você per-
ceberá que, para auxiliar a escrita, convém que se 
crie um formato-padrão que garanta que todas as 
definições de requisitos estejam adequadas a ele. 
15
O requisito deve ser expresso em uma única frase. 
A justificativa do requisito pode incluir informações 
sobre quem o propôs (a fonte do requisito), para 
saber quem consultar, caso ele tenha de ser muda-
do� Pode-se destacar as partes fundamentais do 
requisito usando negrito, itálico ou cores� E, sempre 
que possível, tentarassociar uma lógica a cada um 
dos requisitos para identificá-los. Isso ajuda muito, 
quando eles são alterados (SOMMERVILLE, 2019).
Você sabe quais são os tipos de escrita para a espe-
cificação dos requisitos de sistemas? Se não sabe, 
observe:
 Notação Descrição
Sentenças 
em linguagem 
natural
Os requisitos são escritos em frases nume-
radas em linguagem natural� Cada frase deve 
expressar um requisito. Linguagem natural 
estruturada�
Linguagem 
natural 
estruturada
Os requisitos são escritos em linguagem 
natural em um formulário-padrão ou template� 
Cada campo fornece informações sobre um 
aspecto do requisito�
Linguagem de 
descrição de 
projeto
Essa abordagem usa uma linguagem como 
de programação, mas com características 
mais abstratas, para especificar os requisitos, 
definindo um modelo operacional do sistema. 
É útil para especificações de interface.
Notações 
gráficas
Para definição dos requisitos funcionais para o 
sistema são usados modelos gráficos, suple-
mentados por anotações de texto; diagramas 
de caso de uso e de sequência da UML são 
comumente usados�
16
 Notação Descrição
Especificações 
matemáticas
Essas notações são baseadas em conceitos 
matemáticos, como máquinas de estado finito 
ou conjuntos. Embora essas especificações 
inequívocas possam reduzir a ambiguidade 
de um documento de requisitos, a maioria 
dos clientes não entende uma especificação 
formal. Eles não podem verificar que elas re-
presentam o que eles querem e são relutantes 
em aceitá-las como um contrato de sistema�
Tabela 1: Escritas da especificação de requisitos. Fonte: Sommerville 
(2019)
Vamos verificar, a seguir, as especificações 
estruturadas�
As especificações estruturadas
A linguagem natural estruturada trata-se de uma for-
ma de escrever que permite certa liberdade, mas é 
limitada, pois segue um formato-padrão� Isso garante 
a expressividade e a compreensão de uma linguagem 
natural, mas, ao mesmo tempo, faz com que exista 
uma regularidade na especificação. É possível usar 
templates para especificar requisitos do sistema e 
construções de linguagens de programação para 
mostrar alternativas e iteração. A especificação pode 
ser estruturada em torno dos objetos, das funções 
desempenhadas e de eventos processados pelo sis-
tema (SOMMERVILLE, 2019).
17
REFLITA
Vamos fazer uma pausa e pensar um pouco. 
Você consegue visualizar mentalmente qual se-
ria a importância de usar requisitos em um pro-
jeto de desenvolvimento de sistemas? E qual é 
a diferença entre Elicitação e Especificação de 
requisitos? Pense nisso!
No uso de formulários-padrão para especificar re-
quisitos funcionais, devemos incluir as seguintes 
informações:
1. A descrição da função ou entidade a ser 
especificada.
2. Uma descrição de suas entradas e de onde elas 
vieram�
3. Uma descrição de suas saídas e para onde elas irão�
4. Dados sobre a informação necessária para o pro-
cessamento ou outras entidades usadas no sistema�
5. Uma descrição da ação a ser tomada�
6. Se uma abordagem funcional é usada, uma pré-
-condição define o que deve ser verdade antes que a 
função seja chamada, e é chamada uma pós-condi-
ção, especificando o que é verdade depois da função.
7. Uma descrição dos efeitos colaterais da operação 
(caso haja algum) (SOMMERVILLE, 2019, p. 69).
Vamos observar, a seguir, um exemplo de uma espe-
cificação baseada em formulários que, nessa situa-
18
ção, define a forma de calcular a dose de insulina a 
ser fornecida quando o açúcar no sangue está dentro 
de uma faixa de segurança. Nesse sistema, deve-
-se medir o açúcar no sangue e fornecer insulina, se 
necessário, a cada dez minutos; a cada minuto, exe-
cutar uma rotina (r) de autoteste com as condições 
a serem testadas e as ações associadas.
Bomba de insulina/Sofware de Controle
Função: Calcula doses de insulinas: nível seguro de açúcar.
Descrição: Calcula a dose de insulina a ser fornecida quando 
o nível de açúcar está na zona de segurança entre três e setes 
unidades�
Entradas: Leitura atual de açúcar (r2), duas leituras anteriores (r0 
e r1).
Fonte: Leitura atual da taxa de açúcar pelo sensor. Outras leituras 
da memória�
Saídas: CompDose – a dose de insulina a ser fornecida�
Destino: Loop principal de controle.
Ação: CompDose é zero se o nível de açúcar está estável ou em 
queda ou se o nível está aumentando, mas a taxa de aumento 
está diminuindo. Se o nível está aumentando e a taxa de aumen-
to está aumetando, então CompDose é calculado dividindo-se 
a diferença entre o nível atual de açúcar e o nível anterior por qua-
tro e arredondando-se o resultado� Se o resultado é arredondado 
para zero, então CompDose é definida como a dose mínima que 
pode ser fornecida�
Requisitos: Duas leituras anteriores, de modo que a taxa de varia-
ção do nível de açúcar pode ser calculada�
Pré-condição: O reservatório de inslina contém, no mínimo, o 
máximo de dose única permitida de insulina.
Pós-condições: r0 é substituída por r1 e r1 é substituída por r2�
Efeitos colaterais: Nenhum.
Tabela 2: Especificação estruturada de um requisito para uma bomba 
de insulina. Fonte: Sommerville (2019)
19
Estrutura de documentos de 
especificação de requisitos
Vamos entender (Tabela 2) como se pode estruturar 
um documento de especificacão de requisitos.
Capítulo Descrição
Prefácio Deve definir os possíveis leitores do documento 
e descrever seu histórico de versões, incluindo 
uma justificativa para a criação de uma nova 
versão e um resumo das mudanças feitas em 
cada versão�
Introdução Deve descrever brevemente as funções do 
sistema e explicar como ele vai funcionar com 
outros sistemas� Também deve descrever 
como o sistema atende aos objetivos globais 
de negócio ou estratégicos da organização que 
encomendou o software�
Glossário Deve definir os termos técnicos usados no 
documento. Você não deve fazer suposições 
sobre a experiência ou o conhecimento do 
leitor�
Definição de 
requisitos de 
usuário
Deve descrever os serviços fornecidos ao usu-
ário. Os requisitos não funcionais de sistema 
também devem ser descritos nessa seção� 
Essa descrição pode usar a linguagem natural, 
diagramas ou outras notações compreensí-
veis para os clientes� Normas de produto e 
processos que devem ser seguidos devem ser 
especificados.
Arquitetura de 
sistema
Deve apresentar uma visão geral, em alto nível, 
da arquitetura do sistema previsto, mostrando 
a distribuição de funções entre os módulos do 
sistema� Componentes de arquitetura que são 
reusados devem ser destacados�
Especificação 
de requisitos 
do sistema
Deve descrever em detalhes os requisitos 
funcionais e não funcionais� Se necessário, 
também podem ser adicionados mais detalhes 
aos requisitos não funcionais� Interfaces com 
outros sistemas podem ser definidas.
20
Capítulo Descrição
Modelos do 
sistema
Pode incluir modelos gráficos do sistema que 
mostram os relacionamentos entre os compo-
nentes do sistema, o sistema e seu ambiente� 
Exemplos de possíveis modelos são modelos 
de objetos, modelos de fluxo de dados ou mo-
delos semânticos de dados.
Evolução do 
sistema
Deve descrever os pressupostos fundamen-
tais em que o sistema se baseia, bem como 
quaisquer mudanças previstas, em decorrência 
da evolução de hardware, de mudanças nas 
necessidades do usuário, etc� Essa seção é útil 
para projetistas de sistema, pois pode ajudá-los 
a evitar decisões capazes de restringir possí-
veis mudanças futuras no sistema�
Apêndices Deve fornecer informações detalhadas e 
específicas relacionadas à aplicação em desen-
volvimento, além de descrições de hardware e 
banco de dados, por exemplo. Os requisitos de 
hardware definem as configurações mínimas 
ideais para o sistema� Requisitos de banco de 
dados definem a organização lógica dos dados 
usados pelo sistema e os relacionamentos 
entre esses dados�
Índice Vários índices podem ser incluídos no docu-
mento. Pode haver, além de um índice alfabéti-
co normal, um índice de diagramas, de funções, 
entre outros pertinentes�Tabela 3: Estrutura de documento de especificação de requisitos. 
Fonte: Sommerville (2019, p. 65) adaptado.
Acompanhe, a seguir, quais são as principais estra-
tégias para análise de requisitos�
21
ANÁLISE DE REQUISITOS
Após a especificação de requisitos, com o documen-
to em mãos, os analistas poderão estudá-lo, a fim de 
fazer um detalhamento e um refinamento por meio 
de modelos para, por fim, chegarem a uma aproxi-
mação da solução final. A análise é muito importante 
porque permite que se compreenda melhor os re-
quisitos para auxliar no posterior projeto do siste-
ma. Podemos dizer que a fase de análise faz uma 
tradução das especificações dos requisitos que se 
encontram na linguagem do cliente para uma repre-
sentação que use a linguagem do desenvolvedor. Os 
modelos de casos de uso são exemplo de represen-
tação de funcionalidades para os desenvolvedores 
(BEZERRA, 2007).
FIQUE ATENTO
Você sabe qual é a diferença entre a fase de aná-
lise e de projeto? A fase de análise busca respon-
der as seguintes perguntas, do ponto de vista da 
equipe de desenvolvimento: O quê? O que o siste-
ma deve fazer? O que o sistema deve ser? O que 
o sistema realiza? Já a fase de projeto buscará 
responder as seguintes perguntas: Como? Como 
o sistema fará? Como o sistema será? Como o sis-
tema realiza?
22
A arquitetura de sistema caracteriza a organização 
e a disposição em camadas de classes, componen-
tes, e demais elementos do sistema� A arquitetura 
de sistemas pode ter o padrão Modelo de Visão e 
Controle que prevê a separação dos sistemas em 
três camadas:
 ● Visão: Nesta camada é mantido o código relacio-
nado à visualização gráfica dos elementos;
 ● Controle: Esta camada mapeia as ações requisi-
tadas pela visão ao Modelo e vice-versa;
 ● Modelo: Esta camada é responsável por acessar o 
banco de dados (ou outras formas de persistência) 
e pela lógica de negócio (BEZERRA, 2007).
 ● Existem propostas para identificar as diferentes 
entidades do sistema. Dentre elas temos:
 ○ A análise gramatical do documento de requisitos, 
que consiste em definir que as classes e os atributos 
são representados por substantivos nos documentos 
de requisitos e os verbos representam as operações 
(Métodos). Por exemplo: O usuário pode salvar e 
editar disciplinas para cursar. Nesse exemplo, o subs-
tantivo disciplinas representa uma classe e salvar 
e editar representam operações a ser implantadas.
 ○ As entidades de domínio devem ser levadas em 
consideração quando têm significado para sistemas, 
como tipos de veículos em um sistema de transporte 
rodoviário�
 ○ A análise baseada em cenários faz com que cada 
um deles seja identificado e analisados um por vez. 
23
Por exemplo, em uma entidade disciplina analisamos 
suas atribuições, que podem ser: conhecer seus pré-
-requisitos; seu nome; a quantiade de créditos e seu 
código (BEZERRA, 2007, GONÇALVES, 2015).
Na fase de projeto é possível fazer um refinamento 
dos elementos criados durante a análise, especifican-
do de maneira pormenorizada os modelos gerados e 
concluindo o projeto de arquitetura iniciado na fase 
anterior� Podem ser criados outros diagramas para 
complementar e prosseguir com o desenvolvimento� 
Existem algumas definições das atividades específi-
cas da fase de projeto. Dessa forma, temos:
 ● Refinamento dos Aspectos Estáticos e Estruturais 
que consiste no detalhamento do modelo de classes 
de análise, definindo-se atributos e métodos, além 
dos relacionamentos entre as classes como herança, 
por exemplo.
 ● Projeto de algoritmos é a especificação de quais 
algoritmos serão usados para determinados elemen-
tos dos diagramas�
 ● Detalhamento dos Aspectos Dinâmicos está re-
lacionado à forma como a aplicação deve se com-
portar, ou seja, preocupa-se em expressar o fluxo de 
execução de uma determinada funcionalidade, de 
um caso de uso ou do sistema inteiro�
 ● Inclusão de Padrões de Projeto descreve uma situ-
ação problema recorrente no desenvolvimento, junta-
mente com a solução genérica adequada, exemplos 
de uso e outros padrões relacionados.
24
 ● Inclusão de Frameworks trata-se de um conjunto 
de classes concretas, classes abstratas e interfaces 
para facilitar o desenvolvimento de um determina-
do foco específico dentro do projeto. Existem fra-
meworks de interações de usuários e de persistência 
de dados que mapeiam as relações dos atributos de 
objetos e os campos de banco de dados�
 ● Persistência dos dados consiste em garantir que 
os dados persistentes sejam armazenados com con-
sistência e eficiência.
 ● Projeto de interface gráfica é quando existe a pre-
ocupação de que a interface seja projetada para 
ter uma identidade visual com os usuários� Deve 
ter por objetivo utilizar termos e conceitos que as 
pessoas que mais utilizarão o sistema conheçam 
além da manutenção de operações semelhantes. 
Preocupa-se também com a padronização de cores, 
de mensagens de erro, logotipo que deve aparecer, 
posicionamento dos campos, etc� (BEZERRA, 2007; 
GONÇALVES, 2015).
Podcast 2 
Acompanhe, a seguir, quais são os principais tipos 
de verificação de requisitos.
25
https://famonline.instructure.com/files/707595/download?download_frd=1
VALIDAÇÃO DE REQUISITOS
Você sabe o que é validação de requisitos? É o pro-
cesso pelo qual se verifica se os requisitos que fo-
ram definidos são o que o cliente realmente quer. A 
validação é muito importante, pois pode se consta-
tar erros antes de finalizar o projeto. No decorrer do 
processo de validação, existem diferentes tipos de 
verificações que necessitam ser realizadas com os 
requisitos no documento de requisitos� Dentre as 
verificações, temos:
1. Verificações de validade: por meio de uma aná-
lise mais aprofundada é possível identificar fun-
ções necessárias, adicionais ou diferentes. Os sis-
temas têm diversos stakeholders com diferentes 
necessidades�
2. Verificações de consistência: os requisitos no do-
cumento não devem entrar em conflito, ou seja, não 
deve haver restrições contraditórias ou descrições 
diferentes da mesma função do sistema�
3. Verificações de completude: o documento de 
requisitos deve incluir requisitos que definam todas 
as funções e as restrições pretendidas pelo usuário 
do sistema�
4. Verificações de realismo: os requisitos devem 
ser verificados mediante uso de tecnologias para 
assegurar que realmente podem ser implementados, 
considerando o orçamento e o cronograma para o 
desenvolvimento do sistema�
26
5. Verificabilidade: para reduzir o potencial de 
conflito entre o cliente e o contratante os requisi-
tos do sistema devem ser passíveis de verificação 
(SOMMERVILLE, 2019, p. 77).
Destacamos técnicas de validação de requisitos que 
podem ser usadas individualmente ou em conjunto:
6. Revisões de requisitos, ou seja, analisá-los siste-
maticamente por meio de uma equipe de revisores 
que verifica erros e inconsistências.
7. Prototipação é uma abordadem que possibilita 
a demonstração para usuários finais e clientes de 
um modelo executável do sistema. Dessa forma, 
estes podem verificar se o sistema atende suas 
necessidades�
8. Geração de casos de teste, ou seja, os requisitos 
devem ser testáveis� Se os testes forem concebidos 
como parte do processo de validação, isso frequen-
temente revela problemas de requisitos� Se é difícil 
ou impossível projetar um teste, isso normalmente 
significa que os requisitos são difíceis de serem 
implementados e devem ser reconsiderados�
Vamos estudar, agora, algumas das principais ferra-
mentas de modelagem�
27
FERRAMENTAS DE 
MODELAGEM
Existem ferramentas que auxiliam a criação de códi-
gos e possibilitam o aumento da produtividade dos 
desenvolvedores� Normalmente são ferramentas 
desenvolvidas para detectar erros nas linhas de co-
mando realizadas pelos programadores. Conforme 
estudado anteriormente, são chamadas de ferra-
mentas CASE, ou seja, ajudam nas atividades de en-
genharia de software, desde a análise de requisitos, 
modelagem, programação e testes�
No caso específicodas ferramentas de modelagem, 
também auxiliam os desenvolvedores, pois propiciam 
a boa formação dos modelos gerados, reduzindo 
erros e aumentando a produtividade na execução 
das atividades de análise e projeto�
SAIBA MAIS
Para saber mais sobre ferramentas CASE, leia a 
PARTE III (páginas 235-236), do livro “Utilizando 
UML e padrões”, de Craig Larman, que traz o con-
ceito de ferramentas CASE e exemplos em que 
são usados UML. O livro está disponível em sua 
biblioteca virtual (Minha Biblioteca).
Podemos citar algumas ferramentas que têm por 
base a modelagem de UML:
28
 ● Astah – desenvolvida por uma empresa japonesa. 
Possui uma versão gratuita e uma versão trial apenas 
para teste� É bastante usada na comunidade acadê-
mica e industrial� Possui tutoriais com boa facilidade 
de entendimento. Está disponível em: http://astah.net.
 ● ArgoUML – é uma aplicação open source, ou seja, 
de código aberto� Possui recursos cognitivos para 
construção de modelos. Está disponível em: http://
argouml.tigris.org.
 ● Umbrello – auxilia no processo de modelagem e 
pode gerar códigos a partir dos diagramas� Pode ser 
trabalhada com linguagens como C++, Java, PHP5, 
dentre outras. Está disponível em: http://uml.sour-
ceforge.net�
29
http://astah.net.
http://argouml.tigris.org.
http://argouml.tigris.org.
http://uml.sourceforge.net
http://uml.sourceforge.net
CONSIDERAÇÕES FINAIS
Por meio dos estudos explorados neste módulo, 
você aprendeu que a elicitação (ou levantamento 
de requisitos) é uma fase muito importante na ela-
boração de softwares e de sistemas� Percebeu que 
ela envolve muito diálogo entre desenvolvedores, 
clientes e usuários finais para que, assim, o produto 
possa ter sucesso�
Você descobriu quem são os principais atores en-
volvidos no desenvolvimento de um sistema: proje-
tistas, gerentes, dentre outros; além de conhecer as 
principais técnicas de elicitação de requisitos, como 
entrevistas, observações, etc.
Com a leitura deste material, você estudou os requisi-
tos e identificou seus principais tipos, assim como os 
tipos de escritas da especificação de requisitos, na 
fase de escrita de documentação. Verificou, também, 
que, por meio da análise de projetos, é necessário 
identificar as fases que ajudam a ter detalhes porme-
norizados do projeto, como elaboração de algoritmos, 
projeto de interface gráfica, dentre outros; com isso, 
você conheceu as principais verificações e técnicas 
de validação de requisitos, bem como alguns exem-
plos de ferramentas de modelagem�
Espero que tenha aproveitado o conteúdo!
30
SÍNTESE
ESPECIFICAÇÃO, DOCUMENTAÇÃO, 
VISUALIZAÇÃO E CONSTRUÇÃO DE PROJETOS DE 
SISTEMAS DE SOFTWARES COM UML
1) Requisitos é a nomeção dada ao conjunto de documentos de descrições dos 
serviços que serão oferecidos pelo sistema e restrições operacionais de modo que 
satisfaça as necessidades/desejos do cliente�
3) Principais atores no desenvolvimento de sistemas: gerentes de projetos, 
analistas, projetistas, arquitetos de softwares, progradores, especialistas de domínio e 
negócios�
5) A Especificação de requisistos de sistemas orientados a objetos é a 
documentação escrita de requisitos, evitando-se o uso de jargões e siglas computacionais�
2) A Elicitação de um requisito ou levantamento de requisitos é quando a 
equipe de desenvolvimento relaciona-se com os clientes e usuários para ouvir e levantar 
quais são as suas necessidades�
4) Técnicas para elicitação de requisitos: entrevistas, observação do 
ambiente, etnografia, estudo de documentos em papel (formulários, relatórios, etc), 
demonstração de tarefas específicas, aplicação de questionários, brainstorming, 
prototipação, dentre outras�
6) A análise de requisitos permite que se compreenda melhor os requisitos para 
auxliar no posterior projeto do sistema� Podemos dizer que a fase de análise faz uma 
tradução das especificações dos requisitos que encontram-se na linguagem do cliente 
para uma representação que use a linguagem de desenvolvedor�
7) Fases de refinamento dos elementos criados durante a análise: 
especificação de algoritmos, fluxo de execução de funcionalidades, padrões de projetos 
e projeto de interfáce gráfica� 
8) Validação de requisitos é o processo pelo qual se verifica se os requisitos que 
foram definidos são o que o cliente realmente quer� 
ANÁLISE E PROJETO 
DE SISTEMAS
Referências Bibliográficas 
& Consultadas
BEZERRA, E� Princípios de análise e projeto de 
sistemas com UML. Rio de Janeiro: EIsevier, 2007.
FOWLER, M. UML essencial: um breve guia para 
a linguagem-padrão de modelagem de obje-
tos. 3. ed. Porto Alegre: Bookman, 2005. [Minha 
Biblioteca]
GONÇALVES, E. J. T. Análise e projeto de sistemas� 
3. ed. Fortaleza: EdUECE, 2015.
GUEDES, G� T� A� UML 2: uma abordagem prática. 
2. ed. São Paulo: Novatec, 2011.
LARMAN, C. Utilizando UML e padrões� 3� ed� 
Porto Alegre: Bookman, 2004. [Minha Biblioteca]
MARINHO, A. L. Análise e modelagem de sis-
temas. São Paulo: Pearson Education do Brasil, 
2016. [Biblioteca Virtual]
MEDEIROS, E. Desenvolvendo software com UML 
2.0: definitivo. São Paulo: Pearson Makron Books, 
2004. [Biblioteca Virtual]
PAGE-JONES, M. Fundamentos do desenho orien-
tado a objeto com UML. 1. ed. São Paulo: Makron 
Books, 2001. [Biblioteca Virtual]
PAULA FILHO, W. P. Engenharia de software: funda-
mentos, métodos e padrões. 3. ed. Rio de Janeiro: 
LTC, 2009. Disponível em: [Minha Biblioteca]
PRESSMAN, R� S�; MAXIM, B� R� Engenharia de sof-
tware: uma abordagem profissional. 8. ed. Porto 
Alegre: AMGH, 2016. [Minha Biblioteca]
SOMMERVILLE, I. Engenharia de software� 10� ed� 
São Paulo: Pearson Brasil, 2019. [Biblioteca Virtual]
	Introdução
	Elicitação de requisistos de sistemas orientados a objetos
	Elicitação de um requisito
	Técnicas para elicitação de requisitos
	Dificuldades para elicitação de requisitos
	Especificação de requisistos de sistemas orientados a objetos
	Requisitos
	A especificação de requisitos
	As especificações estruturadas
	Estrutura de documentos de especificação de requisitos
	Análise de requisitos
	Validação de Requisitos
	Ferramentas de modelagem
	Considerações finais
	Síntese