Análise e Levantamento de Requisitos de Software

Prévia do material em texto

Análise e Levantamento de Requisitos
de Software
Aplicações no Cotidiano
Serão apresentadas a seguir os conceitos de engenharia de requisitos no que se 
refere a aplicações no cotidiano no desenvolvimento de soluções tecnológicas para 
o ambiente WEB, para sistemas ERP, CRM, mobile, IOT e IA.
No atual cenário, para que o desenvolvimento de software seja bem-sucedido, é 
importante saber analisar qual o tipo de software a ser desenvolvido e considerar 
suas particularidades e características para ser assertivo na análise e levantamento 
de requisitos do software que será desenvolvido
WEB – WORLD WIDE WEB
Estamos vivendo na era da informação e da tecnologia, movendo-se para a era da 
criatividade e da tecnologia. E em ambas as eras, o desenvolvimento de software é e 
continua a ser uma das atividades mais aquecidas no mercado.
Essa transformação tecnológica e digital está associada à World Wide Web ou 
simplesmente WEB, que é o termo inglês que significa rede mundial. E, nesse 
mundo, a internet e a computação estão fazendo parte, cada vez, mais da vida diária 
das pessoas.
Essa transformação tecnológica e digital tem mudado a forma como os softwares 
para WEB estão sendo desenvolvidos, levando em consideração como o negócio 
está chegando ao usuário final.
Dessa forma, um software web, ao ser desenvolvido, deve levar em consideração o 
desenvolvimento de um tipo de interface descentralizada e de amplo acesso. Além 
disso, estes sistemas precisam ser compatíveis com os diferentes tipos de 
navegadores utilizados pelos usuários finais. 
Quando você considera a possibilidade de desenvolver um software de economia 
compartilhada de objetos entre os condôminos de um condomínio, esse software 
pode ser um sistema web.
Neste caso, por meio de um acesso por um usuário e senha, cada condômino pode 
cadastrar o objeto que deseja compartilhar com a rede de condôminos e também 
ter acesso aos objetos que os outros condôminos estão compartilhando.
E, este mesmo sistema web pode realizar os agendamentos de utilização dos 
objetos com data marcada de retirada e devolução com os valores ou pontuação 
incorporados nesse processo de utilização e empréstimo do objeto a ser 
compartilhado.
ERP – ENTERPRISE RESOURCE PLANNING
Enterprise Resource Planning (ERP) é o termo em inglês utilizado para a gestão 
integrada de um negócio. Um sistema ERP tem o objetivo de proporcionar 
planejamentos que simplifiquem e melhorem os processos de um negócio, 
permitindo aumento de produtividade e crescimento dos negócios de uma empresa.
Um sistema ERP bem desenvolvido e administrado permite que as áreas do negócio 
sejam geridas com um padrão alto de qualidade e tecnologia. Com isso, o negócio 
passa a ter informações controladas, de acordo com uma hierarquia administrativa, 
e que permite uma análise dessas informações para potencializar os resultados dos 
negócios.
Quando um negócio está sendo gerido por meio de um sistema de ERP, ela passa a 
ter otimização dos processos do negócio, com as áreas integradas, o que permite a 
diminuição dos gastos necessários para a produção e o aumento da produtividade.
Além disso, as informações passam a ter mais segurança para uma gestão de 
tomada de decisão mais assertiva que proporciona, inclusive, integração com 
ferramentas de business intelligence.
Para um negócio que envolve uma economia compartilhada de objetos entre 
famílias de um condomínio, um sistema de ERP pode ser utilizado para gerir as 
cobranças de devolução dos objetos compartilhados, envio de comunicados de 
novos objetos que passaram a ser compartilhados, prestação de contas dos 
movimentos que estão acontecendo em relação aos objetos compartilhados.
CRM – CUSTOMER RELATIONSHIP MANAGEMENT
Customer Relationship Managemente (CRM) é o termo em inglês utilizado para a 
gestão de relacionamento com o cliente. Neste caso, é um software que é 
desenvolvido para o gerenciamento da relação que um negócio tem com o seu 
cliente.
Este tipo de software de CRM tem a intenção de gerir o relacionamento do negócio 
com o seu usuário final para garantir sua satisfação e sua fidelização por meio de 
processos bem-organizados e automatizados, que ajudam inclusive na diminuição 
dos gastos e elevam os lucros do negócio.
Com um software de CRM, é possível que uma empresa consiga gerir estratégias 
dos negócios envolvidos e relacionados com o departamento de marketing, de 
vendas, de suporte e de todos os departamentos que estão envolvidos com o 
negócio da empresa.
Quando uma empresa possui um software de CRM e sabe otimizar sua utilização, 
ela consegue ter uma visão 360 graus do negócio, um ganho de produtividade 
sustentável, com a capacidade de desenvolver um planejamento estratégico 
inteligente com acompanhamento do negócio em tempo real.
No caso de um negócio que envolve uma economia compartilhada em um 
condomínio, um software de CRM pode ser utilizado para monitorar e gerar as 
cobranças das despesas do condomínio e, de alguma forma, gerar benefícios para 
quem participa dessa economia compartilhada, gerando uma espécie de bonificação 
por meio da gamification.
MOBILE
O desenvolvimento de software mobile, os famosos aplicativos para smartphones, é 
um dos segmentos que mais tem crescido no mundo da tecnologia, isso, porque, os 
aplicativos são de fácil acesso com informações de forma prática e o usuário final 
pode utilizá-lo para qualquer lugar que ele for inclusive durante seu trajeto para 
este lugar.
Porém, como essa tendência atinge muitos desenvolvedores de aplicativos, é 
importante que o desenvolvimento desse tipo de software seja bastante assertivo, 
buscando apresentar um aplicativo para um produto ou serviço atrativo com uma 
experiência única para o usuário final.
Desenvolver um software mobile tem seus desafios, pois há diferentes sistemas 
operacionais e plataformas para serem desenvolvidos para diferentes marcas de 
smartphones.
Neste caso, há necessidade de desenvolvedores com diferentes conhecimentos de 
programação para cada sistema operacional e plataforma mobile, além disso, é 
importante manter manutenção e suporte frequente aos aplicativos.
Para um aplicativo que possa satisfazer uma necessidade de um condomínio que 
quer ter a possibilidade de compartilhar alguns objetos de pouco uso entre os 
condôminos, um aplicativo de economia compartilhada seria bastante interessante.
Neste caso, os condôminos podem cadastrar seus objetos que desejam compartilhar 
em troca de poder também utilizar objetos que não possui e que não tema intenção 
de comprar porque vai utilizar apenas eventualmente.
Desta forma, além de economizar em não precisar adquirir um objeto, pode receber 
recompensas e/ou incentivos por estar compartilhando seus objetos com a 
comunidade do condomínio em que vive.
IOT – INTERNET OF THINGS
A Internet das Coisas ou do inglês Internet of Things (IoT) é uma nova abordagem 
para o desenvolvimento de softwares que tem mudado a forma como consumimos 
a tecnologia no nosso dia a dia.
A IoT considera alguns pequenos sensores com gadgets inteligentes que utilizam 
uma forma de conexão wireless para conectar objetos que podem ser algum tipo de 
aparelho e também aplicações, com o objetivo de obter informações e fazer uso 
dela com alguma inteligência para resolver algum problema do usuário final.
A utilização da IoT nos negócios tem sido bastante considerada, pois os softwares e 
os aparelhos estão muito próximos da interação com o usuário final, 
proporcionando uma oportunidade de entregar uma maior experiência de uso, 
sendo capaz de ter uma fidelização do usuário final.
Para um negócio que envolve uma economia compartilhada de um condomínio, por 
exemplo, se um aparelho identifica a necessidade de trocar o vaso de uma planta 
que cresceu e precisa de mais espaço, um software que faz a leitura desses dados 
informados pelo aparelho, comunica com as pessoas do condomínio esta 
necessidade.
E, em contrapartida, alguém pode ter um vaso do tamanho necessário deste 
condômino, um vaso que já não está maisem uso e que até poderia ser descartado, 
mas que pode ser utilizado nesta economia compartilhada deste condomínio, 
gerando reutilização, troca ou empréstimos de objetos entre os condôminos, 
aproximando, inclusive, para uma convivência harmoniosa entre eles.
IA – INTELIGÊNCIA ARTIFICIAL
Atualmente, muitas empresas têm buscado por software que utilizam a inteligência 
artificial. O desenvolvimento de softwares com inteligência artificial precisa 
considerar tecnologias que envolvem as redes neurais que utilizam de algoritmos de 
aprendizado de máquina.
Quando se desenvolve software tradicionais sem a inteligência artificial, o resultado
são softwares determinísticos, ou seja, para estes softwares para uma dada 
determinada entrada, sua saída será sempre a mesma.
Quando se considera o desenvolvimento de software com os recursos da 
inteligência artificial, o resultado dos softwares deixa de ser determinístico, desta
forma, para uma mesma entrada, é possível ter diferentes saídas como resultado.
 
E, isso acontece porque os softwares consideram algoritmos de otimização que tem 
por base a inteligência artificial que levam a um leque de possibilidades de 
resultados, buscando sempre determinar o melhor possível dentre eles.
 
No caso de um software de inteligência artificial para uma economia compartilhada 
em um condomínio, de acordo com as informações e as possibilidades em relação, 
por exemplo, o desapego de objetos de um bebê de 8 meses, o próprio software de 
inteligência artificial pode sugerir o compartilhamento desses objetos com o 
condômino x que possui um bebê de 7 meses, do mesmo gênero e que já recebeu 
objetos de desapego de outros condôminos.
 
Neste caso, a probabilidade de o condômino que está realizando o desapego ser 
assertivo em entrar em contato com o condômino x é maior do que uma escolha 
aleatória de famílias que possuem crianças bebês, até porque o condômino x já tem 
o histórico de ter aceitado desapego de outros condôminos.
Processo de Desenvolvimento
Vamos iniciar essa aula com a apresentação do conceito de processo de 
desenvolvimento de software, Sommerville define como: “Um processo de software 
é um conjunto de atividades relacionadas que levam a produção de um sistema de 
software” (SOMMERVILLE, 2019, pp 29)
 
Vamos apresentar alguns conceitos básicos sobre processo de desenvolvimento de
software.
Portanto, o processo de desenvolvimento de software deve ter suas atividades bem 
definidas com a indicação precisa de quem irá realizar as atividades e com quais 
ferramentas essas atividades serão realizadas.
Usaremos a seguinte definição livre para o termo processo: é um conjunto de 
atividades realizado por pessoas podendo usar ferramentas.
 
Esta aula envolve as definições de ADIT, a engenharia de requisitos, e os ciclos de 
vida de desenvolvimento de software.
 
ADIT
O processo de desenvolvimento ADIT consiste em definir as fases, os papeis e as 
ferramentas, pois trata-se de um meta-modelo. Podemos destacar que é um 
processo trivial organizado em 4 fases organizadas da seguinte forma:
•         fase 1 - Análise: indica as atividades para se analisar as necessidades e metas 
dos usuários e dessa forma realizar a descoberta dos requisitos;
•                fase 2 – Design: indica as atividades para organizamos a estruturas e 
arquiteturas de um sistema de software, aqui desenhamos as especificações;
•         fase 3 - Implementação: indica as atividades realizadas para codificar o código 
que vai ser executado no ambiente de produção;
•                fase 4 – Teste: indica as atividades para verificar as conformidades do 
aplicativo com as necessidades e metas dos usuários.
 
Requisito
Segundo Sommerville, os requisitos de um sistema são as descrições dos serviços 
que o sistema deve prestar e as restrições à sua operação. Esses requisitos refletem 
as necessidades dos clientes de um sistema que atende a um determinado 
propósito. (SOMMERVILLE,2019 pp 85)
 
Engenharia de Requisitos
A engenharia de requisitos define as atividades realizadas nos processos de 
descoberta, análise, documentação e conferência dos serviços e restrições de um 
sistema.
Na engenharia de requisitos são definidas as seguintes fases:
1) Elicitação;
2) Análise;
3) Especificação;
4) Validação.
 
Até esse ponto da aula vimos algumas definições triviais que são utilizadas em todas 
as metodologias de desenvolvimento de sistemas e softwares. Em continuidade a 
aula vamos utilizar uma divisão para organizar o entendimento sobre os ciclos de 
vidas de desenvolvimento de software. Sendo: Ciclo de vida tradicional para 
modelos antigos; E ciclo de vida ágil para os processos modernos utilizados nas 
empresas.
 
Ciclo de vida Tradicional
Os ciclos de vidas tradicionais foram organizados para tentar resolver um problema 
que foi conhecido com uma crise do software na década de 70, na qual a gente teve 
um grande desenvolvimento do hardware da máquina do computador e o software 
ficou para trás. Dessa forma esses ciclos de vidas ajudaram a organizar os 
pensamentos para a construção de projetos de maior porte.
Os processos mais conhecidos e definidos que nós podemos encontrar na literatura. 
São: 
cascata (waterfall); - 
O entrave visto nesse tipo de processo é que você só passa para a próxima etapa 
depois que terminar a atual, dificultando assim uma maior interação entre as etapas 
do processo. (particionamento inflexível). utilizado mais para projetos pequenos ex: 
IOT 
incremental:
É possível entregar pedaços do software, evitando assim um longo período do 
software. Dependendo, sendo um  problema que a depender do projeto pode ser 
grande. 
espiral - 
É seguido uma sequência, na qual vai quebrando em pequenos pedaços criando a 
ideia de protótipo.
 Processo unificado da Rational (RUP).
Modelo no qual está preocupado com a construção do software e o gerenciamento 
do processo de construção do Software. 
Esses processos foram os percursores na organização do desenvolvimento dos 
projetos de sistemas.
 
Ciclo de Vida Ágil
Mesmo com a grande melhora na arte de desenvolver sistemas com os ciclos 
tradicionais, os clientes e sistemas ainda tinham muitos problemas. Então no final da 
década de 90 um grupo de engenheiros da indústria do software se reuniram para 
atacar o problema da necessidade de desenvolvimento rápido e lidar com a 
mutabilidade dos requisitos, surgiu o movimento ágil e divulgaram o manifesto ágil.
Manifesto Ágil
O manifesto ágil enumera diretivas e princípios para produzir software útil e de 
maneira rápida. Podemos destacar que as mudanças de requisitos são benvindas; a 
entrega de software funcionando como medida de progresso e o cliente envolvido 
conjuntamente no processo de desenvolvimento.
Vários modelos ágeis foram desenvolvidos e destacamos:
1) Scrum;
2) XP programação extrema
3) Lean startup 
Kanban - usado em vários processos de desenvolvimento, servindo como 
ferramenta de apoio.
Modelos de softwares 
Abstração 
Abstração é um processo mental no qual utilizamos o pensamento cognitivo para 
organizar os elementos de um cenário. Nós utilizamos abstração, na fase de análise, 
quando vamos fazer a descoberta dos requisitos, o uso da abstração é fundamental 
para determinarmos quais são os conceitos e definições do negócio que serão 
fundamentais para o desenvolvimento do sistema.
Sabemos que a abstração destaca os aspectos relevantes de um conceito e omite 
aqueles aspectos irrelevantes para um certo propósito.
Podemos pegar como exemplo a palavra ou o conceito “salário” que com o 
propósito de desenvolver um sistema para o setor de recursos humanos de uma 
empresa, para criar a folha de pagamento dos colaboradores vamos ter um 
conjunto de valores, um conjunto de impostos que deverão ser utilizados para 
realizar os cálculos. Diferentemente do uso do conceito de salário, no propósito, de 
um sistema bancário no qual é preciso apenas o valor do salário para definir regras 
de crédito.
Portanto o conceitode abstração é fundamental para o desenvolvimento de 
sistemas pois a partir desse processo mental o analista de negócios será capaz de 
definir com exatidão o significado dos elementos de um sistema e desta forma 
conseguir eliminar os pensamentos que tem outros propósitos fora do contexto.
 
No modelo, é feita a representação de elementos de um mundo de acordo com um 
certo proposito. A abstração está contido na cabeça enquanto o modelo é a 
materialização do pensamento em algum artefato. 
Erros de Abstração
Ao tratarmos da abstração como um processo mental ficamos suscetíveis a 
cometermos erros num processo de análise de um negócio, vamos ilustrar os erros 
de abstração possíveis de serem realizados no processo de análise. Conhecer os 
erros de abstração vai auxiliar na construção de modelos melhores e com qualidade 
mais efetiva.
Podemos destacar uma característica que os requisitos têm que diz respeito à 
ambiguidade pois podemos falar de uma coisa e imaginarmos outra coisa isso vai 
depender do seu conhecimento sobre os assuntos ao realizar uma análise de 
requisitos.
Os erros de abstração são divido em 4 tipos:
Elemento omisso – omissão de detalhes relevantes ao conceito
Elemento detalhe – detalhamento com um conceito já definido
Elemento Estranho – detalhamento de elementos que ainda vão surgir em 
outras partes do desenvolvimento.
Elemento Alienígena – são dados e informações que não fazem parte do 
propósito.
 
Modelo de Domínio
O modelo de domínio é uma técnica para se descobrir objetos que representam 
elementos e conceitos do “mundo real” dentro do propósito do sistema. Podemos
considerar como uma atividade essencial do processo.
O modelo de domínio pode ser representado com o diagrama de classe da UML( 
linguagem de modelagem unificada), no qual na fase de análise utilizamos apenas o 
nome da abstração.
Associação: Uma classe conversa e usa elementos da outra classe;
Dependência: Uma classe depende de outra;
Agregação: uma classe é recipiente da outra, ex: água e garrafa
composição: Necessidade de existência, um só existe se o outro existir.
Generalização: um classe faz parte de outro
No processo inconix de desenvolvimento de sistemas tem a seguinte recomendação 
de fases para se construir um modelo de domínio.
Primeiramente encontrar os conceitos que representam as abstrações do 
domínio do problema.
O modelo de domínio é fundamental para auxiliar a escrita do glossário de termos 
do projeto. Pois cria-se um vocabulário comum ao projeto e a todos os envolvidos 
no desenvolvimento do sistema.
 
Interface com o Ambiente
Eliminar conceitos ambíguos, incorretos e itens desnecessários, isto é, eliminar 
os erros de abstração;
Fazer generalização, se necessário;
Revisar o diagrama construído, analisando principalmente as associações e 
generalizações.
A técnica Interface com o ambiente (ICA) ajuda na identificação de requisitos 
funcionais a serem satisfeitos por um modelo de análise. O ICA explicita 3 elementos 
de essenciais:
1) Valores de entrada;
2) Mecanismos de acionamento de funcionalidade;
3) Valores de saída.
Num sistema de aluguel de equipamentos podemos ilustrar os valores de entrada 
são: qual equipamento será alugado e em qual data. O mecanismo de acionamento 
vai gerar os seguintes comportamentos: verificar a disponibilidade do equipamento 
para a data solicitada e calcular o valor do aluguel. E os valores de saída são: se a 
ferramenta está ou não disponível para a data solicitada, caso positivo, exibe o valor 
do aluguel, e caso negativo, notifica com uma mensagem de indisponibilidade para 
a data.
Observe que a técnica (ICA) é uma importante ferramenta para a descoberta e 
definição dos requisitos.
Desenhar o ICA auxilia na definição dos requisitos o que prepara a análise para criar 
o planejamento dos testes, pois permite uma validação direta de valores e 
comportamentos que o sistema irá tratar.
Tipos de Dados
Ao se desenvolver um sistema computacional os dados são fundamentais para que 
ocorra a computação, sendo, que os dados podem ser de diversos tipos como: 
numérico; uma cadeia de caracteres; um valor verdadeiro ou falso. Essas definições 
são essenciais para a construção de um sistema computacional.
Na fase de análise é fundamental a identificação dos dados que estarão envolvidos 
com os propósitos que o sistema vai ter, sendo essencial descobrir quais são as 
regras e as restrições que esses dados vão sofrer.
Uma vez definido, o dado no sistema computacional será importante para se 
determinar qual é o tipo de dado associado ao elemento, pois isso irá refletir 
diretamente sobre quais valores o sistema poderá manipular.
Ao desenvolver o sistema de aluguel de equipamentos, focando apenas na 
aplicação de realizar o aluguel de um equipamento, podemos exemplificar alguns 
dados e seus respectivos tipos de dados. O nome de um equipamento é 
representado por um conjunto de caracteres (letras), exemplo “martelo”; A data de 
aluguel ou reserva vamos utilizar uma representação numérica, mas essa 
representação define o tipo de dados “data”. O que significa que nós vamos ter 
números para representar os dias, números para representar os meses, e números 
para representa o ano. E a representação do aluguel também vai ser numérica, mas 
representaremos um valor monetário em uma determinada moeda.
IMC
OBs: o IMC deveria estar pintado.
FURPS+
REQUISITOS FUNCIONAIS
Os requisitos funcionais estão associados às funcionalidades do sistema e está 
diretamente ligado aos resultados de comportamento do sistema. Isso significa que 
o que será desenvolvido no sistema resolva as necessidades que os usuários finais 
do sistema estão buscando.
Os requisitos funcionais dependem do tipo de sistema que vai ser desenvolvido, 
quem são os clientes finais e podem ser classificados em requisitos funcionais de 
usuário e requisitos funcionais de sistemas.
O sistema aplicativo para uma economia compartilhada que promove o empréstimo 
ou aluguel de objetos entre condôminos de um condomínio pode ter como 
requisitos funcionais a capacidade de o cliente final realizar o agendamento, dentro 
de um período, do objeto que será emprestado ou alugado.
Por exemplo, no caso do aluguel, o sistema deve permitir pagamento por cartão de 
débito ou crédito ou mesmo permitir que o valor possa ser deduzido contabilizado 
para ser utilizado por benefícios de isenção no condomínio, como utilização do 
salão de festar.
Além disso, outro requisito funcional, permite que o sistema forneça telas que sejam 
apropriadas para que o cliente final possa conhecer as características do objeto que 
deseja compartilhar.
Podemos considerar também que cada objeto a ser compartilhado, possa ser 
emprestado apenas para um único condômino por vez, podendo, neste caso, haver 
a possibilidade de uma fila de empréstimo para cada objeto.
REQUISITOS FUNCIONAIS REGRAS DE NEGÓCIO
As regras de negócio estão relacionadas com as premissas observadas em um 
negócio necessárias para que ele aconteça.
Os requisitos funcionais estão relacionados ao que o sistema deve fazer. As regras 
de negócio estão relacionadas a como o sistema deve fazer.
Observando pelo lado do negócio, ou seja, o negócio do cliente que o sistema está 
sendo desenvolvido, tanto os requisitos funcionais quanto as regras de negócio são 
necessidade, porém, cada uma dessas necessidades possui focos diferentes.
Para o negócio de uma economia compartilhada de objetos em um condomínio, 
vamos supor que este negócio é administrado pelo zelador do condomínio. O 
zelador pode controlar os objetos compartilhados entre os condôminos por meio de 
um aplicativo.
O zelador até pode conseguir realizar essa economia compartilhada sem a utilização 
da tecnologia, pode ser por meio de um caderno de empréstimos que pode ficar na 
portaria. Porém, dificilmente, ele conseguirá realizar esse trabalho sem ter uma regra 
para esse negócio.
Algumas regras de negócio associadas ao negócio de economia compartilhada de 
objetos em um condomínio:REQUISITOS NÃO FUNCIONAIS USABILIDADE
Os requisitos não funcionais estão dissociados das funções específicas que o sistema 
fornece. Os requisitos não funcionais estão associados às propriedades do sistema 
como a usabilidade.
Os requisitos não funcionais de usabilidade são bastante críticos para que o sistema 
seja um sucesso. É importante saber especificar bem os requisitos de usabilidade, 
considerando que o sistema deve ser fácil de ser usado.
Um condômino pode compartilhar um objeto por meio de cadastro do objeto.
Condôminos que compartilham objetos tem uma pontuação que pode gerar 
descontos em aluguel do salão de festas.
Caso algum condômino atrasar na devolução do objeto compartilhado, 
alguma penalidade deve ser realizada.
O zelador precisa ter um controle do período em que um objeto pode 
permanecer compartilhado com um condômino.
Fotos do objeto compartilhado antes e depois do acesso pelo condômino 
devem ser realizados para garantir a qualidade do objeto.
Quando se definem os requisitos de usabilidade é importante considerar o tempo 
de aprendizado do cliente final no sistema, a capacidade do cliente final terminar 
uma tarefa no sistema, a facilidade de o cliente final lembrar da sequência no 
sistema para realizar uma tarefa, a capacidade de o cliente final entender a 
comunicação do sistema e o que o sistema faz e deve haver uma porcentagem 
significativa de clientes satisfeitos com o sistema.
Para um sistema de economia compartilhada de objetos em um condomínio, 
algumas dos requisitos não funcionais de usabilidade podem ser verificada por meio 
da verificação da facilidade e do tempo de cada condômino em utilizar o sistema.
É possível verificar o tempo necessário para que um condômino termine um 
cadastro ou agendamento no sistema e mesmo se o condômino consegue se 
lembrar da sequência para realizar um cadastro ou agendamento de objetos no 
sistema.
Além disso, a capacidade de um condômino de entender a comunicação do 
aplicativo e o que o aplicativo faz, bem como, ter uma grande porcentagem dos 
condôminos que usam o aplicativo satisfeitos com a utilização do sistema.
REQUISITOS NÃO FUNCIONAIS PERFORMANCE
Performance é um dos requisitos não funcionais no desenvolvimento de um 
sistema. Neste caso, o requisito de performance especifica o tempo necessário para 
que o sistema termine a execução de uma tarefa ou transação.
O requisito de performance verifica a capacidade de o sistema suportar uma 
quantidade determinada de fluxo de dados. É o requisito de performance que 
especifica quais os volumes de dados que o sistema consegue tratar e quanto de 
dado o sistema consegue armazenar.
No requisito de performance, o tempo necessário para que o sistema entre em 
funcionamento, bem como, o tempo necessário para que o sistema pare de 
funcionar são definidos.
No aplicativo da economia compartilhada de objetos entre condôminos de um 
condomínio, pode-se aplicar um tempo máximo de dois segundos para que o 
aplicativo dê uma resposta ao condômino para cada interação. E o tempo máximo 
para que o aplicativo carregue e apresente a tela do aplicativo o cadastro de um 
novo objeto é de 5 minutos.
O aplicativo deve ser capaz de suportar um cadastro ou agendamento em alguns 
segundos, sendo capaz de ter acesso simultâneo de 100 condôminos no período 
das 5h às 23h30, sendo a carga máxima, nos demais horários, de 50 condôminos.
E, o tempo necessário para que o aplicativo entre me funcionamento ou para parar 
de funcionar é de 15 segundos.
REQUISITOS NÃO FUNCIONAIS SEGURANÇA 
Segurança é um dos requisitos não funcionais no desenvolvimento de um sistema. 
Os requisitos de segurança estão relacionados às necessidades de segurança que 
um sistema precisa ter.
Os requisitos de segurança estão associados à política de segurança do próprio 
negócio. E como um requisito não funcional, o requisito de segurança consiste em 
ter procedimentos necessários para que o sistema continue com suas 
funcionalidades sendo executadas mesmo de forma indevida.
A validação dos dados de entrada no sistema, a necessidade de registro dos eventos 
em log de auditoria para posterior análise são requisitos de segurança de um 
sistema são requisitos de segurança e todos definem necessidades de proteção que 
são exigidas para o sistema.
Para o sistema de economia compartilhada de objetos em um condomínio, é 
importante considerar um usuário e senha para cada condômino. Cadastro de 
informações de cada condômino com validação por correio eletrônico.
A validação dos dados de entrada no aplicativo pelo usuário e senha. Registro dos 
logs para o cadastro, agendamento, permanência e devolução dos objetos 
compartilhados entre os condôminos.
REQUISITOS NÃO FUNCIONAIS CONFIABILIDADE
Confiabilidade é um dos requisitos não funcionais no desenvolvimento de um 
sistema. Neste caso, o requisito de confiabilidade permite a verificação do sistema 
continuar a funcionar mesmo que em ocasiões adversas e mesmo sobre acesso 
simultâneo por vários clientes finais.
O requisito de confiabilidade para um sistema está relacionado ao tempo em que o 
sistema está disponível e funcionando para o cliente final, considerando também o 
tempo de inoperabilidade do sistema.
No caso do requisito de confiabilidade, é importante definir os níveis de aceitação 
para a confiabilidade, ou seja, que o sistema fique inoperante, além de definir como 
essa confiabilidade será medida e avaliada.
Quando o requisito de confiabilidade está sendo tratado, é importante considerar o 
que será realizado para resolver a instabilidade do sistema e como será tratado para 
que não aconteça novamente, considerando o tempo cabível e contratado para que 
o sistema esteja disponível e confiável.
Em caso de falhas, é importante considerar como estas falhas serão recuperadas, 
especificando também um índice máximo de falhas aceitas e a intensidade dessas 
falhas no impacto das funcionalidades para o cliente final.
Para o sistema de economia compartilhada de objetos em um condomínio, é 
importante considerar que há a possibilidade de manutenção do sistema e 
momentos em que o aplicativo pode ficar inoperante.
Porém, precisa ser de conhecimento dos condôminos, quais são as ações que são 
realizadas para resolver o problema de o aplicativo ficar fora do ar, bem como, o 
tempo de permanência do aplicativo sem poder ser acessado pelos condôminos.
É importante que os condôminos tenham conhecimento de quais são as ações para 
a recuperação do aplicativo em caso de falhas, por exemplo, no cadastro ou 
agendamento de objetos a serem compartilhados.
Quais as ações do aplicativo em casos de falhas em agendamentos perdidos, ou 
falhas em objetos cadastrados que não aparecem no sistema que podem ser 
classificados como críticos.
Fases
No processo ADIT as atividades são organizadas em: Análise, Design, 
Implementação e Testes. A engenharia de requisitos está caracterizada na fase de 
Análise, pois são as atividades relacionadas com a descoberta das necessidades e 
metas dos usuários, e desta forma caracterizamos a definição do contrato que 
define qual sistema será construído ao término do projeto.
Vamos usar nessa aula a seguinte definição de requisito, baseado em Sommerville, 
um requisito é uma descrição de um serviço que o sistema deve prestar com a 
definição das restrições para a sua operação quando o sistema estiver pronto.
Ainda em Sommerville, podemos separar os requisitos em diferentes níveis de 
descrição, sendo, requisitos do usuário e requisitos do sistema, e podemos definir 
da seguinte forma (SOMMERVILLE, 2019 pp 86):
1. requisitos do usuário são declarações em uma linguagem natural somada a 
diagramas dos serviços que se espera que o sistema forneça para os usuários e das 
limitações sobre as quais ele deve operar.
2. requisitos de sistema são descrições mais detalhadas das funções dos serviços das 
restrições operacionais do sistema.
Agora vamos detalhar um pouco mais as fases da engenharia de requisitos 
organizadas pela ordem elicitação uma análise, especificaçãoe validação.
 
Elicitação
A fase de elicitação dos requisitos envolve o processo de entendimento de como 
os  Stakeholders  realizam o seu trabalho e como eles preveem a realização do 
trabalho com o novo sistema implantado.
Durante o processo de elicitação o engenheiro de software deverá realizar a 
descoberta das necessidades e metas dos usuários, que compreende o 
entendimento sobre o domínio da aplicação, isto é, onde essa aplicação será 
utilizada, sobre as características dos serviços a serem realizados, sobre qual é o 
desempenho esperado da aplicação e sobre a definição de restrições de uso da 
aplicação.
Alguns pontos de atenção no processo de elicitação, pois nem sempre os 
stakeholders sabem o que querem do sistema, muitas vezes eles utilizam seus 
próprios termos e omitem passos do seu trabalho, e a visão do sistema pode ser 
diferente entre os stakeholders, assim como os cargos podem influenciar nas 
decisões para o sistema e o mais relevante é que os requisitos podem mudar 
durante o processo de elicitação.
 Para lidar com essas dificuldades, o processo de elicitação deve ser iterativo com a 
fase de análise, vista a seguir, para tratar os requisitos e suas mudanças.
 
Análise
Com a finalidade de melhorar o entendimento dos requisitos dos stakeholders, na 
fase de análise são realizadas as atividades de classificação, organização, priorização 
e negociação dos requisitos.
 
Uma sequência para realizar a análise é começar pela organização dos requisitos e 
para realizar essa organização o caminho mais interessante é organizar os 
stakeholders em grupos conforme o ponto de vista que eles têm sobre o sistema, e 
dessa forma você vai criar agrupamentos sobre o sistema.
 
Uma vez, com os requisitos organizados você terá condições de criar uma 
classificação, bem definida, sobre os requisitos e dessa forma conseguir realizar a 
priorização necessária para que o entendimento dos requisitos seja completa.
Durante o processo de engenharia de requisitos a atividade mais intensa que vai 
ocorrer está ligada com a negociação entre os requisitos o seu entendimento e os 
anseios dos stakeholders pois só com a negociação será possível definir um contrato 
para o desenvolvimento do projeto do software da aplicação.
O processo de análise envolve a partir da classificação a criação de uma lista dos 
requisitos até o momento descobertos e atribuir a esses requisitos um conjunto de 
atributos podemos destacar nesse momento os atributos do tipo prioridade, e do 
tipo complexidade e do tipo de risco que este requisito pode ter em relação ao 
produto de software.
 
Especificação
Na fase de especificação vamos realizar a escrita dos requisitos no documento de 
requisitos, pois nas fases de elicitação e análise você produz e organiza os requisitos 
no formato de rascunho e você vai melhorando a medida em que o entendimento 
se amplia. E na fase de especificação é um momento de formalizar a escrita e o 
detalhamento do requisito que vai ser fundamental para definir o contrato a ser 
produzido para execução do projeto.
 
A especificação pode ser estruturada em diversas notações, sendo: uma lista de 
sentenças em linguagem natural, onde cada frase expressa um requisito; um 
formulário com campos que fornecem informações sobre os aspectos dos 
requisitos; modelos gráficos usando notação UML (Unified Modeling Language); e 
ainda utilizando a notação matemática para se ter uma especificação formal.
Cada processo de desenvolvimento de software tem seus próprios formatos e 
artefatos para criar a especificação dos requisitos. Portanto, ao ingressar no mercado 
de trabalho, a empresa que você escolher para trabalhar vai te apresentar e indicar 
como preencher a especificação dos requisitos.
Um documento de requisitos pode ser organizado, de forma genérica, com os 
seguintes itens: prefácio; introdução; glossário; requisitos do usuário; arquitetura do 
sistema; requisitos do sistema; modelo do sistema; evolução do sistema; apêndices e 
índice. Mais detalhes podem ser visto em Sommerville, 2019 pp 111.
Por mais detalhado e trabalhado que estejam os requisitos você deve ter em mente 
que eles poderão e vão sofrer mudanças, e organização é fundamental para futuras 
mudanças e manutenções.
Validação
Nesta fase vamos conferir se os requisitos irão atender as necessidades e metas dos 
usuários. Toda vez que realizamos uma validação estamos próximos de realizar 
testes para ficar dentro dos aspectos de conformidade. Indicamos o sucesso de um 
teste quando encontramos um defeito. Portanto, realizar a validação tem como uma 
das atividades descobrir os defeitos nos requisitos.
 
No processo ADIT, caso um defeito passe da fase de Análise para a fase de Design 
temos um alto custo de correção e assim por diante.
Durante a fase de validação, Sommerville lista diversos tipos de conferência que 
incluem: a) conferência da validade, reflete as reais necessidades dos usuários; b) 
conferência da consistência, não devem existir conflitos entre os requisitos 
especificados no documento de requisitos; c) conferência da completude, ter todas 
as funções e restrições pretendidas pelos usuários; d) conferência do realismo, 
assegurar que os requisitos possam ser implementados dentro das tecnologias 
existentes e dentro do orçamento e cronograma proposto; e e) verificabilidade, os 
requisitos devem ser testáveis e desta forma diminuir potenciais conflitos entre o 
cliente e contratante.
Algumas técnicas de validação podem ser utilizadas nesta fase, como: o uso da 
revisão sistemática por equipes de revisores; o uso da prototipação com a criação 
de modelos executáveis do sistema; e o uso de casos de testes, no qual teremos a 
visão de testes dos requisitos e se são possíveis de serem implementados.
 
Elicitação interativa 
Uma entrevista é uma das formas mais comuns de buscas pela elicitação de 
requisitos por meio de pessoas. Numa entrevista, duas pessoas conversam de forma 
que uma está provocando a conversa e a outra está sendo abordada.
O objetivo de uma entrevista é que o contato pessoal permita que, a pessoa 
abordada para a entrevista, tenha o sentimento de que faz parte do processo de 
resolução das necessidades do problema proposto.
ENTREVISTA ESTRUTURADA
 
A entrevista estruturada, também conhecida como entrevista fechada, é uma forma 
de entrevista em que as perguntas já foram devidamente e cuidadosamente 
realizadas para que a pessoa entrevistada possa respondê-las de forma direta.
Numa entrevista estruturada, as perguntas seguem um roteiro e as respostas, 
geralmente, são objetivas com quatro ou cinco alternativas, onde apenas uma é a 
correta, ou mesmo com questões de sim ou não e verdadeiro ou falso.
Na entrevista estruturada, as perguntas são desenvolvidas pela equipe de negócios 
e de desenvolvimento de acordo com os requisitos levantados e que precisam ser 
investigados e que não permite que a pessoa entrevistada tenha condições de 
explicar as respostas.
No formato de uma entrevista estruturada, há a possibilidade de a entrevista ter 
muitas perguntas para elucidar requisitos pontualmente, manter aqueles que ainda 
causam dúvidas e seguir por outra forma de entrevista, eliminando as dúvidas de 
forma mais assertiva.
No caso do sistema de economia compartilhada de objetos em um condomínio, um 
conjunto de perguntas objetivas pode ser realizada para o entendimento dos 
requisitos funcionais e não funcionais do aplicativo.
Neste caso, os condôminos seriam abordados por um entrevistador que faria as 
perguntas e anotaria as respostas para posteriormente serem computados. 
Atualmente, este tipo de entrevista tem sido feito pelos meios tecnológicos por 
meio de formulários.
Algumas perguntas que podem fazer parte de uma entrevista estruturada para o 
aplicativo de economia compartilhada em condomínio:
Você tem objetos que deseja compartilhar? Sim ou não.
Você gostaria de ter a possibilidade de pegar emprestado um objeto de pouco 
uso por meio de outro condômino? Sim ou não.ENTREVISTA NÃO ESTRUTURADA
 
A entrevista não estruturada, também conhecida como entrevista aberta, é uma 
forma de entrevista em que algumas poucas perguntas já foram devidamente e 
cuidadosamente realizadas para que a pessoa entrevistada possa respondê-las de 
forma aberta.
Numa entrevista não estruturada, as perguntas seguem um roteiro que pode ser 
alterado de acordo com as respostas do entrevistado. Neste formato, há poucas 
perguntas para elucidar requisitos com mais detalhes.
Na entrevista não estruturada, as perguntas são desenvolvidas pela equipe de 
negócios e de desenvolvimento de acordo com os resultados da entrevista 
estruturada e que precisam ser investigados com mais detalhes e que permite que a 
pessoa entrevistada tenha condições de explicar as respostas de forma totalmente 
livre e aberta.
O entrevistado, na entrevista não estruturada, tem total liberdade para responder 
sem interferências e o entrevistador se limita a ser um ouvinte, anotando ou 
gravando as respostas.
No caso do sistema de economia compartilhada de objetos em um condomínio, um 
conjunto de poucas perguntas subjetivas pode ser realizada para o esclarecimento 
de detalhes dos requisitos.
Neste caso, os condôminos seriam abordados por um entrevistador que faria as 
perguntas e anotaria ou gravaria as respostas para posteriormente serem 
analisados. Este tipo de entrevista é realizado pessoalmente, principalmente, para 
analisar as emoções e sentimentos do entrevistado.
Algumas perguntas que podem fazer parte de uma entrevista não estruturada para 
o aplicativo de economia compartilhada em condomínio:
Por quanto tempo você compartilharia um objeto? 1h, 6h, 12h, 1 dia, 2 dias
Por quanto tempo você ficaria com um objeto emprestado? 1h, 6h, 12h, 1 dia, 
2 dias.
Quais as etapas que você acha necessário para um aplicativo de economia 
compartilhada para o seu condomínio?
Quais abordagens de aplicativos que você gostaria que não tivessem no 
aplicativo de economia compartilhada do seu condomínio?
Como você se sente compartilhando objetos no seu condomínio?
 
ENTREVISTA SEMIESTRUTURADA
A entrevista semiestruturada, meio estruturada e meio não estruturada, é uma forma 
de entrevista em que as perguntas já foram devidamente e cuidadosamente 
realizadas para que a pessoa entrevistada possa respondê-las de forma aberta ou 
fechada.
Numa entrevista semiestruturada, as perguntas seguem um roteiro que pode ser 
alterado de acordo com as respostas do entrevistado. Neste formato, há um misto 
de perguntas objetivas e subjetivas para elucidar requisitos.
Na entrevista semiestruturada, as perguntas são desenvolvidas pela equipe de 
negócios e de desenvolvimento de acordo com a necessidade dos requisitos que 
precisam ser investigados e que permite que a pessoa entrevistada tenha condições 
de explicar as respostas de algumas das perguntas de forma livre e aberta.
O entrevistado, na entrevista semiestruturada, segue por perguntas abertas e 
fechadas com liberdade para responder sem interferências as perguntas abertas e 
seguir de forma objetiva com as perguntas fechadas. Nas perguntas abertas, o 
entrevistador fica atento às respostas passando a ser ouvinte.
No caso do sistema de economia compartilhada de objetos em um condomínio, um 
conjunto de perguntas subjetivas e objetivas que se complementam pode ser 
realizada para o esclarecimento de detalhes dos requisitos. 
Neste caso, os condôminos seriam abordados por um entrevistador que faria as 
perguntas e anotaria ou gravaria as respostas para posteriormente serem analisados.
 Este tipo de entrevista é realizado pessoalmente, principalmente, para analisar as 
emoções e sentimentos do entrevistado.
Algumas perguntas que podem fazer parte de uma entrevista semiestruturada para 
o aplicativo de economia compartilhada em condomínio:
 
QUESTIONÁRIO
Como você se sente pegando emprestado objetos no seu condomínio?
Você tem objetos que deseja compartilhar? Sim ou não.
Quais as etapas que você acha necessário para um aplicativo de economia 
compartilhada para o seu condomínio?
Por quanto tempo você compartilharia um objeto? 1h, 6h, 12h, 1 dia, 2 dias
Como você se sente compartilhando objetos no seu condomínio?
O questionário, também conhecido como pesquisa de opinião, é uma ferramenta de 
elicitação que busca obter informação sobre o negócio e sobre a interação com o 
usuário final, porém, que estejam distantes fisicamente ou pela necessidade de um 
grande volume de informações.
O questionário pode ser composto por perguntas abertas ou fechadas e que 
tenham sido construídas com cuidados que seguem uma sequência lógica e 
sequencial. Um questionário é frio e impessoal e os resultados não são tão ricos.
Porém, os resultados de um questionário, geralmente, são utilizados para 
tratamentos estatísticos. Até porque o cuidado que se tem ao realizar as perguntas 
de um questionário considera perguntas curtas e rápidas, sem direcionar as 
respostas, mas que tenham respostas que o analista de requisitos realmente precisa.
Quando consideramos o negócio de economia compartilhada de objetos em um 
condomínio, ao aplicarmos a ferramenta de questionário, é importante elaborar as 
perguntas com cuidado, com linguagem clara e simples, estimar quanto tempo será 
necessário para responder cada pergunta, realizar uma simulação de possível análise
e concluir um teste piloto antes mesmo de realizar a pesquisa com o questionário.
Para o questionário da economia compartilhada do condomínio, colocamos uma 
breve introdução, esclarecendo o objetivo do questionário, com perguntas que 
testam a coerência das respostas e que esgotem o assunto sobre a economia 
compartilhada dos objetos no condomínio.
OBSERVAÇÃO
A observação é uma ferramenta de elicitação que o analista de requisitos utiliza com 
aplicação em campo, para entender de perto mais sobre o negócio e as 
necessidades que precisam ser resolvidas.
  Com a observação, o objetivo está além de apenas escutar e olhar, mas em 
conseguir perceber situações específicas que são fundamentais e precisam ser 
considerados para a assertividade do negócio.
A observação tem o objetivo de ser realizada sem qualquer interferência no 
ambiente, porém, a presença de uma pessoa que está dissociada do ambiente 
natural, acaba criando uma certa curiosidade ou desconforto.
A ferramenta de observação acontece pelo período necessário até que o observador 
tenha alcançado os objetivos da observação, realizando as anotações pertinentes.
Para o negócio de um aplicativo de economia compartilhada de objetos em um 
condomínio, a ferramenta de observação pode ser utilizada para entender como 
ocorre o fluxo das atividades de agendamento e cadastro de objetos no aplicativo.
Com a ferramenta de observação, você pode verificar se existe picos em que o 
aplicativo é mais utilizado para o compartilhamento de objetos. Você também pode 
verificar o que é feito caso o aplicativo falhar num agendamento ou no cadastro de 
objetos.
Com a ferramenta de observação, é possível observar a possibilidade de fluxos 
alternativos ou casos que precisam de um tratamento especial na manipulação do 
objeto no aplicativo.
PROCESSO DE NEGÓCIO
Um processo de negócio é o desenvolvimento de ações que, de forma estruturada e 
ordenada, promovem o desenvolvimento de um produto ou serviço que satisfaz as 
dores, necessidades e desejos de um público-alvo.
O processo de negócios implementa as estratégias, as metas e objetivos de uma 
empresa em seus negócios e no desenvolvimento de software. Neste sentido, o 
processo de negócios é viabilizado pela infraestrutura corporativa.
No processo de negócios, a estrutura e a organização corporativa e dos negócios 
podem estar apresentados na estrutura organizacional por meio de um 
organograma, com os sistemas de informação e pela infraestrutura tecnológica e 
física.
Dessa forma, o processo de negócios está associado à essência do que a 
organização é e faz no dia a dia. O processo de negócios está alinhado com 
estratégias, metas e objetivos corporativose a infraestrutura precisa estar muito 
bem alinhada.
Para um sistema de economia compartilhada de objetos em condomínio, é 
importante considerar o condomínio como uma organização para que o processo 
de negócio faça sentido.
Neste caso, para o processo de negócios de um condomínio é preciso investigar e 
considerar as estratégias, as metas e os objetivos do condomínio quando uma 
economia compartilhada de objetos seja aplicada.
Algumas das características que podem e devem ser aplicadas num condomínio 
como um processo de negócio é a sustentabilidade, o convívio harmonioso, a 
minimização de custos, a otimização de recursos, a administração transparente. 
O aplicativo de uma economia compartilhada de objetos em um condomínio precisa 
estar alinhado com essas estratégias, metas e objetivos de um condomínio que é 
administrado com uma empresa.
Elicitação descritiva
Modelo de Domínio:
Associação: a classe A é ligada com a classe B, uma trocando informação com a a 
outra.
Dependência: a classe A depende da classe B para realizar um serviço.
Agregação: a classe A é um contêiner de elementos da classe B. 
Composição: a classe A é formada por partes da classe B.
Generalização: a classe B é um tipo, exemplar da classe A. A classe A é mais genérica 
e a classe B traz uma especificidade. 
Um modelo de domínio abstrai elementos considerados relevantes para 
elaborarmos a solução de um problema. A modelagem de domínio tem o propósito 
de construir um glossário para subsidiar o processo de comunicação entres todos os 
envolvidos no processo de desenvolvimento.
O modelo de domínio é construído com o diagrama de classes da UML, onde cada 
classe representa um termo associado ao entendimento do negócio em análise. Esse 
modelo ao extrair elementos fundamentais para a solução do problema vai auxiliar 
na escrita e definição do glossário de termos do projeto.
Sobre o diagrama de classe usamos os seguintes desenhos, veja na figura 1.
Na figura 2 estão ilustrados os tipos de ligações entres as classes para melhorar o 
entendimento da relação entre os elementos.
Figura 2 – Tipos de ligação entre as classes
Vamos usar o draw.io como ferramenta para desenhar o modelo de domínio, trata-
se de uma ferramenta disponível na internet e pode utilizá-la diretamente na web 
(online).
http://draw.io/
Análise de documentos
A técnica de elicitação de requisitos conhecido como análise de documentos prevê 
que o analista realize uma coleta de documentos usuais da empresa com o objetivo 
de preparar um estudo e entendimento preliminar do negócio para montagem dos 
questionários utilizados nas entrevistas.
Nesse processo, programas coletam títulos de documentos nas empresas, 
formulários utilizados nas atividades cotidianas da empresa, um conjunto de 
relatórios gerados para o gerenciamento e gestão, possíveis manuais do usuário, 
sistemas já existentes e uma descrição de procedimentos que devem ser realizados 
do ponto de vista de negócio.
Podemos listar algumas vantagens:
* Voltar técnica de análise de documentos como identificação de documentos 
ligados aos processos de negócio;
* Realizar a coleta de dados dos processos e possíveis erros nos documentos;
* Promover análise e refinamento dos processos.
De uma forma geral a técnica permite abstrair necessidades, identificar regras de 
negócio, discrepâncias e redundâncias.
Casos de uso cenários
A técnica de caso de uso é amplamente utilizada pela comunidade de 
desenvolvimento de sistemas em todo o mundo. O modelo de caso de uso está 
especificado pela UML e é uma técnica para a descoberta de requisitos.
Os casos de uso consistem em descrever as interações entre os usuários e um 
sistema, podemos usar diversos formatos para escrever esta descrição, desde um 
texto narrativo informal, até um texto que descreve uma sequência de passos 
realizando o diálogo entre o ator e o sistema.
Podemos resumir que os casos de uso descrevem os cenários de utilização de um 
sistema por um ator. Um ator pode representar uma pessoa ou outros sistemas.
O diagrama de caso de uso é uma representação gráfica dos atores se relacionando 
com os casos de usos e pode expressa as relações entre os casos de uso. Na figura 3 
são ilustrados os elementos de um diagrama de caso de uso.
Figura 3 – Elementos do Diagrama de Caso de Uso
Casos de uso descrição
A descrição do caso de uso é essencial para o entendimento e discussão do cenário 
em questão. A descrição é a materialização das formas de interação do usuário com 
o sistema.
Veja a descrição a seguir: “Para eu agendar uma consulta no consultório médico, eu
vou ligar e falar com a secretária, vou perguntar se o médico pode me atender no 
dia “d” e hora “h”, a secretária vai olhar na agenda do médico e me dizer que sim, 
então eu solicito que ela agende a consulta para mim. E ela vai me pedir alguns 
dados, como: meu nome, meu telefone, meu e-mail e qual o meu plano de saúde. E 
vai colocar meu nome na agenda.”
Observe que no texto ocorre a descrição de um cenário para de agendar uma
consulta. Deste cenário ainda podemos ter um conjunto de outros cenários, como 
não ter o dia e hora disponível. Ou o médico não atender o plano de saúde.
Dessa descrição podemos listar uma série de requisitos, como; o médico tem uma 
agenda e essa agenda é organizada por dias e horas de atendimento; quem tem 
acesso a agenda é a secretária; o paciente tem acesso a agenda através da 
secretária; pode agendar, então também poderá cancelar; Depois de ocorrer a 
consulta pode-se marcar que a consulta foi realizada, então deve cobrar o plano de 
saúde.
A escrita no caso de uso pode ser formal, e utilizamos a seguinte estrutura do 
documento de caso de uso: nome do caso de uso; descrição; lista de atores; pré-
condição; pós condição; fluxo básico de eventos; fluxos alternativos de eventos e 
fluxos de exceção.
História de Usuário cenários
A história de usuário é uma técnica de descoberta de requisito muito utilizada e 
difundida em equipes de desenvolvimento que utilizam processos ágeis. Pois como 
os requisitos mudam rapidamente, não se gasta tempo com documentações formais.
 
A técnica consiste em organizar as histórias em cartões, e dessa forma a priorização 
dos requisitos ocorre com a discussão dos cartões e se define as prioridades.
 
Mas as histórias têm uma forma pré-estabelecida de escrita que segue o modelo: 
Quem <usuário>, o quê <requisito>, por quê <necessidade>
Um outro modelo de escrita pode ser baseado no: Como/eu quero/para.
Como <tipo de usuário ou produto>, eu quero <requisitos> para <necessidade a 
ser atendida>.
História de Usuário Descrição
A história do usuário deve conter apenas as informações necessárias para 
representar uma conversa entre os desenvolvedores e o PO (Product Owner) sobre 
as necessidades e metas dos usuários.
A técnica de história do usuário é estruturada por 3 elementos, a saber: cartão, ser 
um pequeno espaço para escrever o suficiente; conversa, o requisito é 
compartilhado com a equipe via conversa; e confirmação, ter um método de 
validação com um critério de aceitação.
 
A história do usuário deve passar pelo teste INVEST, ver figura 4.
Figura 4 – INVEST
Elicitação DT Imersão Preliminar
ENTENDIMENTO DOS CONCEITOS
 
 
A imersão é a primeira fase da abordagem do design thinking e, é nessa fase que a 
equipe, envolvida no desenvolvimento do produto ou serviço do negócio, entram 
em contato com o contexto do problema (dor, necessidade, desejo etc.) a ser 
resolvido.
 
 
A fase da imersão considera os dois pontos de vista para análise, tanto o ponto de 
vista do cliente que para o qual a solução está sendo desenvolvida, quanto o ponto 
de vista do usuário final que vai consumir a solução que está sendo desenvolvida.
 
 
A imersão pode ser dividida em dois momentos. A imersão preliminar e a imersão 
em profundidade.
 
 
Na imersão preliminar, algumas técnicas e abordagens podem ser realizadas como o 
reenquadramento, a pesquisa exploratória e a pesquisa de mesa.
 
 
 
IMERSÃO PRELIMINARA imersão preliminar é a primeira etapa da primeira fase de desenvolvimento da 
abordagem do design thinking. As ferramentas da imersão preliminar são o 
reenquadramento, a pesquisa exploratória e a pesquisa de mesa.
 
Na imersão preliminar, todo o entendimento do contexto da necessidade do 
problema a ser resolvido é buscado para ser entendido. Para isso, várias reuniões e 
encontros com a equipe de desenvolvimento, a equipe de negócios, a equipe do 
cliente e até os usuários finais acontecem para que o alinhamento estratégico seja 
estabelecido.
 
Durante essas reuniões, comportamentos do mercado, comportamentos da 
sociedade, o comportamento das pessoas e o comportamento do próprio negócio e 
suas tendências são analisadas.
Comportamentos ao extremo são analisados para o entendimento do 
comportamento médio, além dos comportamentos internos e externos associados.
REENQUADRAMENTO
 
 
O reenquadramento é uma ferramenta da fase de imersão preliminar da abordagem 
do design thinking. O reenquadramento que busca observar os problemas que 
precisam ser melhorados ou inovados em um negócio.
 
O reenquadramento examina e observa o negócio sob perspectivas diversas e 
ângulos diferentes. Com o reenquadramento, é possível descontruir objeções e 
crenças, além dos achismos das ideias dos envolvidos no negócio.
 
Com isso, é possível uma quebra de paradigmas, permitindo alterações no 
pensamento em relação ao negócio, permitindo e abrindo novos caminhos para 
alcançar soluções que sejam inovadoras.
 
O reenquadramento também pode e deve ser utilizado para a criação de novos 
negócios, além da melhoria de negócios existentes. Isso porque as questões são
observadas com um outro e novo olhar.
 
O reenquadramento pode ser realizado num dia de workshop ou em pequenos 
encontros diários até que o resultado esperado de enxergarem o contexto do 
problema do negócio seja alcançado.
 
 
Para o desenvolvimento de um negócio que envolve uma economia compartilhada 
de objetos entre condôminos de um condomínio, o reenquadramento pode ser 
utilizado para responder perguntas como:
* Para quem o produto de economia compartilhada no condomínio está destinado?
* Quem quer compartilhar objetos em um condomínio?
* O que a economia compartilhada no condomínio está entregando para os 
condôminos?
* Quando a economia compartilhada no condomínio será utilizada?
* Por que a economia compartilhada no condomínio é necessária?* Qual o problema 
que a economia compartilhada no condomínio está resolvendo?
* Por que as pessoas querem ter uma economia compartilhada no condomínio?
* Como a economia compartilhada no condomínio resolve o problema dos 
condôminos?
* Como a economia compartilhada será utilizada pelos condôminos?
 
PESQUISA EXPLORATÓRIA
A pesquisa exploratória é uma ferramenta da fase de imersão preliminar da 
abordagem do design thinking.
 
Esta ferramenta realiza uma pesquisa que ajuda a equipe de negócios e a equipe do 
cliente a entender o contexto que precisa ser desenvolvido no negócio.
 
A pesquisa exploratória busca informações sobre o público-alvo, onde eles estão, 
seus comportamentos e qual a vivência deles dentro do ciclo de vida do negócio do 
cliente, seja produto ou serviço.
 
Os resultados da pesquisa exploratória, que envolvem o entendimento e conexão da 
nova realidade do produto ou serviço com os envolvidos no negócio, são utilizados 
na pesquisa em profundidade e na pesquisa de mesa.
 
Na pesquisa exploratória, o usuário final do cliente é observado, é entrevistado, é 
investigado, explorando as necessidades, as dores, os desejos, os comportamentos 
para que o negócio seja assertivo na entrega do produto ou servido para o cliente.
 
A pesquisa exploratória para um negócio que envolve uma economia compartilhada 
em um condomínio considera uma equipe de duplas. Uma delas realiza a entrevista 
e a outra faz as anotações de tudo o que vê e ouve e cuida do áudio da entrevista.
Perguntas que podem ser realizadas na entrevista: Como você se sente podendo 
compartilhar objetos em seu condomínio? Como você gostaria de se sentir ao
compartilhar objetos no seu condomínio? Como você se sentiria se a utilização de 
uma economia compartilhada pudesse lhe fazer ganhar tempo e dinheiro?
 
 
PESQUISA DE MESA
 
A pesquisa de mesa é uma ferramenta da fase de imersão preliminar da abordagem 
do design thinking.
 
Esta ferramenta busca dados e informações sobre o negócio que envolve o produto 
ou serviço que são desenvolvidos. A busca dessas informações pode ser em 
diferentes fontes como artigos, rede mundial (internet), livros, revistas, jornais, entre 
outros.
 
A importância dessa ferramenta é levantar informações e dados de fontes que 
divergem do usuário final. Pois, dessa forma, tendências internas e externas são 
identificadas e utilizadas para o desenvolvimento de um negócio realmente 
inovador.
 
Os resultados são registrados em cartões de insights que basicamente possuam os 
dados de um título sobre o assunto, um breve descritivo, a data e a fonte de onde 
essa pesquisa foi extraída.
Os resultados da pesquisa de mesa são utilizados na fase de análise.
 
Para uma economia compartilhada de objetos em um condomínio, a pesquisa de 
mesa deve verificar as tendências da economia compartilhada e como as pessoas 
em um condomínio sentem com esse tipo de tendência. Os resultados devem ser 
encontrados em buscadores da internet.
 
Elicitação DT Imersão Profundidade
ENTENDIMENTO DOS CONCEITOS
 
A imersão em profundidade é a segunda parte da fase de imersão da abordagem do
design thinking. Na fase da imersão em profundidade, a pesquisa é realizada numa 
profundidade ainda maior, principalmente, em relação ao contexto da vida do 
público-alvo e do tema a ser desenvolvido.
 
O objetivo é observar o ser humano que está por trás do público-alvo do negócio a 
ser desenvolvido, buscando entender seu comportamento em relação ao que estão 
falando, agindo, pensando e sentindo.
 
Uma das palavras-chave na imersão em profundidade é empatia. Nesta fase, 
estamos em busca de ter empatia com o público-alvo para entender suas 
necessidades, dores e desejos somados ao entendimento do que acreditam, suas 
verdades e o que buscam e como estão dispostos a alcançar o que buscam.
 
Na fase da imersão em profundidade, algumas ferramentas são utilizadas como as 
entrevistas, o caderno de sensibilização, a sessão generativa e um dia na vida.
 
ENTREVISTAS
 
A entrevistas é uma das ferramentas da fase de imersão em profundidade da 
abordagem do design thinking. Na ferramenta entrevista, o objetivo é buscar 
informações do público-alvo por meio de perguntas e respostas. As informações a 
serem alcançadas está relacionada ao tema que está sendo desenvolvido e como é a 
vida e o comportamento dos entrevistados.
 
A ideia é que, por meio das entrevistas, seja possível buscar informações que 
estejam relacionadas com as experiências e como vive o entrevistado. É importante 
que as perguntas que estão sendo feitas aos entrevistados busquem os motivos 
pelo qual o entrevistado está trazendo aquelas respostas relacionadas a sua vida.
É importante que as expressões faciais e corporais, bem como, a entonação de voz e 
gestos sejam analisados. As emoções envolvidas na hora das respostas das 
perguntas também trazem informações importantes para o desenvolvimento do 
projeto.
 
As entrevistas podem ocorrer em ambiente neutro como as ruas em horário de 
entrada, saída ou almoço dos entrevistados, podem ser em ambiente familiar ou de 
trabalho, porém que estejam relacionados ao tema do projeto a ser desenvolvido.
Para uma economia compartilhada de objetos em um condomínio, as entrevistas 
devem ser realizadas no próprio condomínio. Os resultados que se buscam devem 
estar relacionados com o que gosta de compartilhar, o que faz sentido compartilhar, 
que tipos de objetos gosta de compartilhar. Qual o sentimento por trás do 
compartilhar objetos no condomínio?
 
CADERNOS DE SENSIBILIZAÇÃO
 
 
O caderno de sensibilização é uma das ferramentasda fase de imersão em 
profundidade do design thinking. Na ferramenta do caderno de sensibilização, o 
objetivo é obter informações sobre o público-alvo envolvido e como é o seu dia a 
dia.
 
A ideia é saber como é o comportamento do público-alvo do negócio para que se 
obtenha informações de como uma ação ou atividade de uma pessoa do público-
alvo possa interferir em seu cotidiano, no ambiente em que convive e as pessoas 
afetadas.
Essas informações podem trazer indícios de como esse cotidiano e comportamento 
podem influenciar nos sonhos, propósito e desejos de forma que o que busca vá 
para ele com o negócio que estamos propondo desenvolver.
No caderno de sensibilização é importante registrar os resultados de tudo o que se 
deseja investigar sobre o usuário final. Os resultados serão utilizados para outras 
atividades que serão realizados pelos usuários finais para que o negócio a ser 
desenvolvido seja bem assertivo às suas necessidades.
 
 
Para uma economia compartilhada de objetos em um condomínio, é importante 
entender o comportamento e sentimentos dos condôminos ao compartilhar seus 
objetos com outros condôminos. No caderno de sensibilização, será utilizado fotos, 
recortes e quaisquer imagens que estejam relacionados com uma economia 
compartilhada em um condomínio.
Quando os condôminos observam as imagens, os resultados das falas e percepções 
são registrados, bem como, os comportamentos, gestos e expressões faciais.
SESSÃO GENERATIVA
A sessão generativa é uma das ferramentas da fase de imersão em profundidade da 
abordagem do design thinking. O objetivo desta ferramenta é a realização de 
atividades presenciais com os usuários finais para que as suas experiências sejam 
observadas e analisadas.
 Na sessão generativa, os participantes que são os clientes finais do projeto a ser 
desenvolvido apresentam suas visões e experiências sobre o assunto do negócio do 
projeto. A ideia é entender com detalhes dia a dia do cliente final em cada detalhe.
 
  A ideia é que o sentimento e as emoções do usuário final, com e sem a 
possibilidade de experimentar o negócio do projeto, traga informações da riqueza 
de se experimentar uma vida que satisfaça suas necessidades por meio do negócio.
Os resultados das atividades das sessões generativas utilizam as informações 
agrupadas no caderno de sensibilização e buscam por memórias, por sentimentos e 
motivações da experiência de se viver diariamente com uma solução que os ajudem 
a viver melhor.
Na sessão generativa para um sistema para uma economia compartilhada em um 
condomínio, você pode considerar um encontro com quinze condôminos foram 
convidados para contarem suas experiências em compartilhar objetos no
condomínio.
É importante considerar condôminos dos mais diversificados, homens, mulheres,
terceira idade, adolescentes, que trabalham ou não, que estudam ou não, entre 
outros.
Neste encontro, cada condômino explica o motivo de ter escolhido determinado 
objeto para ser compartilhado e como se sentiu ao compartilhar aquele objeto. Em 
grupos de três condôminos, cada grupo deve apresentar por meio de um painel de 
imagens, o que representava para o grupo a questão de participar da economia 
compartilhada do condomínio.
UM DIA NA VIDA
 
 
Um dia na vida é uma das ferramentas da fase de imersão em profundidade da 
abordagem do design thinking. O objetivo de um dia na vida é fazer com que uma 
representação de um dia do usuário final seja realizada para que seu 
comportamento e interesses possam ser analisados.
 
A ideia é que as pessoas da equipe de negócio ou de desenvolvimento assumam o 
papel do usuário final do negócio que está sendo desenvolvido. E, com isso, uma 
simulação do dia a dia deste usuário final será realizada para que o ponto de vista 
deste público-alvo seja observado sobre um aspecto diferente.
 
Conhecer em detalhes o dia a dia deste usuário final, desde ações até os 
comportamentos e emoções envolvidas são importantes para simular o cotidiano do 
público-alvo para que a vivência seja o mais real possível.
 
Para um sistema de economia compartilhada em um condomínio, uma simulação de 
um objeto sendo compartilhado é realizado, de forma que um condômino vive seus 
momentos de escolhas e decisões sobre o objeto que compartilha ou vai se 
beneficiar do compartilhamento.
 
As experiências vividas pela equipe no papel do condômino devem considerar todas 
as informações da economia compartilhada no condomínio e, as que foram 
coletadas em outras atividades como a pesquisa de imersão.
 
SOMBRA
 
Sombra é uma das ferramentas da fase de imersão em profundidade da abordagem 
do design thinking. O objetivo é ter alguém que acompanhe o usuário final em toda 
a sua interação com o seu produto ou serviço.
 
 
A pessoa que atua como sombra deve apenas observar o usuário final e jamais 
interagir com ele ou interferir em sua interação com o produto ou serviço.
 
Com a ferramenta sombra, espera-se observar informações importantes para o 
negócio que podem não terem sido observadas ou não foram aparentes nas outras 
ferramentas de imersão como a entrevista ou a sessão generativa.
 
Desta forma, como resultado da aplicação da ferramenta sombra, a interação do 
usuário final com o produto ou serviço traz informações ricas no comportamento, 
nas emoções e sentimentos, nas expectativas e hábitos do usuário final.
 
No negócio de uma economia compartilhada em um condomínio, uma pessoa fica 
responsável por observar todas as ações do condômino ao utilizar o sistema, 
buscando extrair informações sobre comportamento, emoções e sentimentos 
envolvidos no hábito do condômino em utilizar o sistema de economia 
compartilhada em um condomínio.
Análise
TIPOS DE CLASSIFICAÇÃO
 
Para evitar que a especificação de requisitos apresente problemas como falta de 
entendimento do projeto como negócio, falta de comunicação entre usuário final e 
analista do projeto e falta de gestão com os requisitos.
 
Quando analisamos os requisitos, os separamos em requisitos funcionais e não 
funcionais. Os requisitos funcionais tratam do que o sistema precisa fazer em 
relação às suas funcionalidades e informações.
Os requisitos não funcionais tratam dos elementos que qualificam os requisitos 
funcionais. Esses elementos podem ser o de corretude, completude e consistência, 
podendo ser não ambíguos, verificáveis e rastreáveis.
 
A corretude é um dos elementos em que os próprios modelos de processos de 
negócio apresentam como uma atividade estava acontecendo e que estava 
comprometendo as regras de negócio, dessa forma, podendo ser corrigida.
 
A completude está associada à elicitação de requisitos, de forma a completá-la com 
todos os significados que o usuário final espera e está buscando no sistema que 
está sendo desenvolvido.
 
A consistência está associada no alinhamento do requisito individual e isolado com 
o sistema todo funcionando, tudo precisa estar consistente.
 
Os requisitos precisam ser não ambíguos, ou seja, cada requisito precisa ter apenas 
um único significado, um único sentido, com uma única interpretação.
 
Os requisitos precisam ser verificáveis, ou seja, eles precisam ter características que 
sejam possíveis de serem testáveis para serem validados.
  
Os requisitos precisam ser rastreáveis tanto para o modelo de negócio quanto o 
desenvolvimento do sistema. É importante saber a origem dos requisitos e seus 
relacionamentos.
 
PRIORIZAÇÃO
 
Sempre é preciso priorizar a utilização de recursos, justamente porque os recursos 
são limitados, não são infinitos.
 
Neste sentido, é importante saber escolher o que será desenvolvido primeiro e o 
que será desenvolvido depois. É claro que tudo o que é essencial e necessário para 
o funcionamento do sistema terá uma prioridade maior.
Quando você adequa a prioridade do desenvolvimento dos requisitos, a prioridade 
acaba por otimizar os recursos e a diminuir os custos envolvidos com o 
desenvolvimento do sistema.
Num sistema de economia compartilhada de objetos em um condomínio, algumas 
funcionalidades,naturalmente, têm mais prioridade do que outras, principalmente, 
aquelas que são necessárias e essenciais.
 
As maiores prioridades, dentre um conjunto de requisitos, para as funcionalidades 
de uma economia compartilhada em condomínio estão relacionadas com as 
atividades de cadastro e validação dos condôminos, de cadastro e validação de 
objetos e do próprio processo de agendamento.
 
As menores prioridades, dentre um conjunto de requisitos, para as funcionalidades 
de economia compartilhada em condomínio estão relacionadas com as atividades 
de gamification, descontos ou abatimentos e a inteligência artificial.
 
COMPLEXIDADE
 
Os requisitos têm seus níveis de complexidade e, dependendo do nível da 
complexidade de um requisito, seja baixo, médio ou alto, o tempo de 
desenvolvimento desse requisito também muda.
 
A complexidade dos requisitos deve estar alinhada com as estratégias do próprio 
negócio, pois, para negócios diferentes, um mesmo requisito pode ter complexidade 
diferente também.
 
Por exemplo, as características dos requisitos de senha possuem complexidade 
diferente para cada negócio, dependendo das estratégias de segurança do negócio. 
Se for para o acesso de um sistema de banco, a complexidade do requisito de senha 
será muito maior do que para um sistema de um aplicativo de jogo de lógica.
 
Num sistema de economia compartilhada de objetos em condomínio, quando 
consideramos um requisito de complexidade de senha, por exemplo, seja para a 
criação ou alteração da senha, alguns elementos podem ser considerados.
 
Estes elementos podem estar relacionados com ter ou não letras maiúsculas, letras 
minúsculas, dígitos de base 10 (de 0 a 9), caracteres especiais e um mínimo de 8 
caracteres na senha.
 
COMPLETUDE
 
A completude está relacionada com o completo. Pode-se dizer que um conjunto de 
requisitos está completo quando os requisitos abrangem todas as necessidades que 
os usuários finais buscam num sistema.
 
Além disso, o documento de requisitos também precisa estar completo, de fora que 
contenha todos os requisitos relevantes, essenciais e necessárias para que as 
funcionalidades do sistema entregue o que o usuário final espera.
 
No documento de requisitos, os requisitos precisam estar documentados de forma 
completa e a engenharia de requisitos auxilia por meio das métricas que 
proporcionam a completude do documento de requisito, considerando, inclusive, o 
tempo e os recursos disponíveis para o desenvolvimento do sistema.
 
 
Num sistema de economia compartilhada de objetos em um condomínio, um 
documento de requisitos deve considerar todos os requisitos fundamentais para a 
funcionalidade do sistema, bem como, todos os que satisfazem as necessidades do 
usuário final.
 
Para o sistema de economia compartilhada em condomínio, temos que observar a 
completude para os requisitos que envolvem cadastro e agendamento de objetos, 
que são fundamentais para o funcionamento do sistema.
 
No sistema de economia compartilhada em condomínio, o documento de requisitos 
precisa conter todos os requisitos relacionados ao cadastro e o agendamento, além 
de precisar estar completo com todos os requisitos relevantes ao cadastro e 
agendamento.
 
MATRIZES DE REQUISITOS
 
A matriz de requisitos, também conhecida como matriz de rastreabilidade de 
requisitos é uma ferramenta que é utilizada para documentar os requisitos e 
gerenciar as demandas de um projeto.
 
Conforme os requisitos de um sistema estão sendo levantados, eles são inseridos 
adequadamente na matriz de requisitos para já serem organizados e seu 
entendimento mais claro.
 
A matriz de requisitos serve de documentação dos requisitos e garante um 
alinhamento dos objetivos do projeto e do negócio para a entrega de um sistema 
de acordo com o que o usuário final espera.
 
Para um sistema de economia compartilhada de objetos em um condomínio 
podemos organizar a matriz de requisitos com o código do requisito, sua prioridade, 
descrição, tipo, quem solicitou, status e data de conclusão.
 
Para exemplificar, consideramos cinco requisitos com suas características 
armazenadas na matriz de requisitos com diferentes situações para cada tipo de 
requisito. Observe a matriz de requisitos do sistema de economia compartilhada de 
objetos em um condomínio.
Técnicas de Levantamento de Requisitos
Casos de uso Fluxo Básico
Como já expressamos um caso de uso descreve um cenário de utilização do sistema, 
a descrição do fluxo básico reflete a interação do ator com o sistema no cenário de 
sucesso absoluto, ou dia feliz, isto é, ao ator interagir com o sistema todos os passos 
representam o sucesso da interação, tudo deu certo e funcionou perfeitamente.
Essa percepção do fluxo básico é fundamental para estrutura os requisitos do 
sistema, pois neste momento o uso do processo mental de abstração é essencial, 
pois os problemas deverão ser ignorados, eles serão descritos nos outros fluxos. 
Portanto, o fluxo básico realiza com sucesso o propósito do caso de uso.
 
Podemos exemplificar da seguinte maneira, imagine um sistema de e_comerce, o 
caso de uso deverá ser “Realizar Compra”, o cenário de sucesso implica em ter o
produto, e ao realizar o pagamento o comprador tem crédito, e tudo certo. Mas e se 
não passar o cartão de crédito, então, nesse momento do cenário do fluxo básico, 
isso não vai ocorrer
O fator importante está em identificar os atores que utilizarão o sistema e as 
interações que ele vai realizar no sistema.
Casos de uso Fluxos Alternativos
Numa interação entre um ator e o sistema, podemos identificar diversos cenários de 
utilização, o fluxo básico descreve o sucesso perfeito, mas podemos ter interações 
que percorrem caminhos e atalhos para atingir o sucesso do caso de uso. Para estes 
outros caminhos e cenários diferentes do sucesso vamos descrever como fluxos 
alternativos.
 
Observando o cenário de “realizar compra” no sistema de e_comere, podemos 
identificar que o produto desejado não estava disponível na quantidade solicitada, 
nesse caso o sistema indica isso numa mensagem, mas o usuário decide comprar a 
quantidade existente. Veja que o fluxo passar por uma rota alternativa, mas o 
usuário consegue concluir a atividade.
Portanto, ao descrever os fluxos dos casos de uso identificar todos os cenários que 
contornam o fluxo básico. E descrevê-los como fluxos alternativos.
Casos de uso Fluxos de Exceção
O fluxo de exceção descreve os cenários e caminhos nos quais o ator não consegue 
atingir o objetivo do caso de uso. Mesmo assim temos que descrever os passos para 
encerrar a interação de forma estável.
Imagine se um aplicativo simplesmente encerra a execução e não emite uma 
mensagem informativa.
No exemplo de realizar uma compra no e-comerce, no cenário do sistema de 
cobrança do cartão estar inoperante, como deve ser a interação entre o ator e o 
sistema para deixar a compra como um pedido, ou voltar os intens para o carrinho e 
indicar uma tentativa mais tarde. Ou ainda enviar um email notificando quando o 
sistema voltar.
Mas um ponto importante é que naquela interação não foi possível realizar a 
compra. Isso consideramos como uma exceção.
Uma anotação importante sobre os fluxos é que sempre teremos um fluxo básico e 
diversos fluxos alternativos e de exceção.
Glossário
Um dos problemas que temos na área de desenvolvimento de sistemas tem sua 
origem nas falhas de comunicação. O cliente fala uma coisa, o analista entende 
outra e comunica outra para equipe de desenvolvimento que entende e constrói 
uma outra coisa. Esse efeito pode ser visualizado na figura 1.
 
O glossário é um artefato produzido na fase de Análise, nele são colocados os 
termos e seus significados dentro do contexto e propósito do projeto. O processo 
mental de abstração é fundamental nessa atividade.
O glossário é um documento simples, no qual são listados os termos e suas 
respectivas descrições.
Dicionário de Dados
Com a realização das atividades de elicitação de requisitos, diversos dados serão 
descobertos