67961835-requisitos-de-software-casos-de-uso-e-diagramas-de-caso-de-uso-e1651613248

Prévia do material em texto

SISTEMA DE ENSINO
ENGENHARIA DE 
SOFTWARE
Requisitos de Software. Casos de Uso e 
Diagramas de Caso de Uso
Livro Eletrônico
2 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Sumário
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso ................................................3
1. Requisitos de Software ............................................................................................................................................3
1.1. Introdução à Engenharia de Requisitos ......................................................................................................3
1.2. Requisitos de Software ........................................................................................................................................8
1.3. Documento de Requisitos de Software ....................................................................................................18
1.4. Especificação de Requisitos ..........................................................................................................................20
1.5. Processos de Engenharia de Requisitos .................................................................................................21
1.6. Elicitação e Análise de Requisitos .............................................................................................................23
1.7. Validação de Requisitos ................................................................................................................................... 29
1.8. Gerenciamento de Requisitos .......................................................................................................................30
2. Diagrama de Casos de Uso .................................................................................................................................32
Resumo ...............................................................................................................................................................................36
Questões de Concurso ...............................................................................................................................................40
Gabarito ..............................................................................................................................................................................48
Gabarito Comentado ...................................................................................................................................................49
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
3 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
REQUISITOS DE SOFTWARE. CASOS DE USO E 
DIAGRAMAS DE CASO DE USO
1. Requisitos de softwaRe
Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços 
que serão oferecidos, e as restrições do seu funcionamento. Esses requisitos refletem as 
necessidades dos clientes para um sistema que serve a uma finalidade determinada, como 
controlar um dispositivo, colocar um pedido ou encontrar informações. O processo de desco-
brir, analisar, documentar e verificar esses serviços e restrições é chamado de engenharia de 
requisitos (RE, do inglês requirements engineering).
1.1. intRodução à engenhaRia de Requisitos
A engenharia de requisitos (ou análise de requisitos) engloba todas as tarefas que lidam 
com investigação, definição e escopo de novos sistemas ou alterações. A engenharia de re-
quisitos é uma parte importante do processo de desenvolvimento de softwares, no qual o 
engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou 
desenvolvedor de software, identificam as necessidades ou requisitos de um cliente.
Na engenharia de requisitos são realizadas as primeiras reuniões com os clientes e/ou 
usuários do software para conhecer as funcionalidades do sistema que será desenvolvido. 
Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas 
estarão preparados para projetar a solução.
A engenharia de requisitos é o processo de compreensão e identificação das necessida-
des do cliente, que espera a resolução da demanda especificada, a qual será solucionada pelo 
sistema ou aplicativo que será desenvolvido e bem definido em suas funções, ou seja, o que 
este software irá realizar. Também envolve a comunicação entre os membros da equipe do 
projeto e as partes interessadas, além da adequação às mudanças de requisitos ao longo do 
curso do projeto.
A engenharia de requisitos é uma das primeiras atividades do desenvolvimento de softwa-
res. O produto do seu trabalho é a especificação de requisitos, que procura definir o escopo do 
software em duas dimensões: requisito funcional e requisito não funcional.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
4 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Na imagem abaixo, temos diferentes visões de um requisito:
No âmbito da engenharia de software, um requisito consiste na definição documentada de 
uma propriedade ou comportamento que um produto ou serviço em particular deve atender.
Em alguns casos, o requisito é apenas uma declaração abstrata em alto nível de um servi-
ço que o sistema deve oferecer, ou uma restrição a um sistema. No outro extremo, o requisito 
pode ser uma definição detalhada e formal de uma função do sistema.
Podemos trabalhar com uma distinção que envolve os requisitos de usuário, para expres-
sar os requisitos abstratos de alto nível, e os requisitos de sistema, para expressar a descrição 
detalhada do que o sistema deve fazer.
Esses diferentes níveis de descrição de requisitos podem ser definidos como:
• Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de 
quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais 
este deve operar.
• Requisitos de sistema são descrições mais detalhadas das funções, serviços e restri-
ções operacionais do sistema de software. O documento de requisitos do sistema (às 
vezes, chamado especificação funcional) deve definir exatamente o que deve ser im-
plementado.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
5 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Diferentes níveis de requisitos são úteis, pois eles comunicam informações sobre o siste-
ma para diferentes tipos de leitor. Na figura abaixo, podemos observar um exemplo de distin-
ção entre requisitos de usuário e requisitos de sistema:
O exemplo acima é de um Sistema de Gerenciamento da Saúde Mental de Pacientes (MHC–
PMS, do inglês Mental Health Care Patient Management System), e mostra como um requisito 
de usuário pode ser expandido em diversos requisitos de sistemas.
Os requisitos de usuário são mais gerais. Os requisitos de sistema fornecem informaçõesmais específicas sobre os serviços e funções do sistema que devem ser implementados.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
6 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Os requisitos precisam ser escritos em diferentes níveis de detalhamento para que dife-
rentes leitores possam usá–los de diversas maneiras. A figura abaixo mostra possíveis leitores 
dos requisitos de usuário e de sistema.
Os leitores dos requisitos de usuário não costumam se preocupar com a forma como o 
sistema será implementado. Os leitores dos requisitos de sistema precisam saber mais deta-
lhadamente o que o sistema fará, porque estão interessados em como ele apoiará os proces-
sos dos negócios, ou porque estão envolvidos na implementação do sistema.
A engenharia de requisitos abrange sete tarefas distintas: concepção, levantamento, ela-
boração, negociação, especificação, validação e gestão. É importante notar que algumas de-
las ocorrem paralelamente, e que todas são adaptadas às necessidades do projeto.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
7 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Concepção – Na concepção do projeto, é estabelecido um entendimento básico do pro-
blema, as pessoas que querem a solução, a natureza da solução desejada, e a eficácia da 
comunicação e colaboração preliminares entre os demais envolvidos e a equipe de software.
Levantamento – Poderia ser resumida no processo de perguntar ao cliente, aos usuários 
e aos demais envolvidos quais são os objetivos para o sistema ou produto, o que deve ser 
obtido, como o sistema ou produto atende as necessidades da empresa e, por fim, como o 
sistema ou produto deve ser utilizado no dia a dia. Uma parte importante do levantamento é 
estabelecer metas de negócios. Sua tarefa é mobilizar os envolvidos e estimulá–los a compar-
tilhar suas metas honestamente. Uma vez capturadas as metas, deve ser estabelecido um me-
canismo de atribuição de prioridades, podendo ser criado um raciocínio lógico para a possível 
arquitetura do projeto (que esteja de acordo com as metas dos envolvidos).
Elaboração – As informações obtidas através do cliente durante a concepção e o levanta-
mento são expandidas e refinadas durante a elaboração. Essa tarefa concentra–se no desen-
volvimento de um modelo de requisitos refinado que identifique os diversos aspectos da fun-
ção, do comportamento e das informações do software. A elaboração é guiada pela criação e 
pelo refinamento de cenários que descrevem como o usuário (e outros atores) vão interagir 
com o sistema. Cada cenário de usuário é analisado para extrair classes de análise – entida-
des do domínio de negócio visíveis para o usuário. Os atributos de cada classe de análise são 
definidos, e os serviços exigidos de cada uma são identificados. As relações e a colaboração 
entre as classes são identificadas, e uma variedade de diagramas suplementares é produzida.
Negociação – Não é raro clientes e usuários pedirem mais do que é possível, dados os 
recursos limitados de seu negócio. Também é relativamente comum que diferentes clientes 
ou usuários proponham necessidades conflitantes, argumentando que sua versão é “essencial 
para nossas necessidades especiais”. É preciso conciliar esses conflitos por meio de um pro-
cesso de negociação. Devemos solicitar a clientes, usuários e outros envolvidos para que orde-
nem seus requisitos e discutam sua prioridade, usando uma abordagem iterativa que priorize 
os requisitos, avalie seus custos e riscos e trate dos conflitos internos. Os requisitos são elimi-
nados, combinados e/ou modificados, de modo que cada parte atinja certo nível de satisfação.
Especificação – No contexto de sistemas baseados em computador (e software), o termo 
especificação assume diferentes significados para diferentes pessoas. Especificação pode ser 
um documento por escrito, um conjunto de modelos gráficos, um modelo matemático formal, 
um conjunto de cenários de uso, um protótipo, ou qualquer combinação dos fatores citados. 
Alguns sugerem que um “modelo padrão” deve ser desenvolvido e utilizado para a especifica-
ção, argumentando que ele leva a requisitos que são apresentados de forma consistente e, 
portanto, mais compreensível. Entretanto, algumas vezes é necessário permanecer flexível 
quando uma especificação precisa ser desenvolvida. Para sistemas grandes, um documento 
escrito, combinando descrições em linguagem natural e modelos gráficos, pode ser a melhor 
abordagem. Entretanto, talvez sejam necessários apenas cenários de uso para produtos ou 
sistemas menores que residam em ambientes técnicos em compreendidos.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
8 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Validação – Os artefatos produzidos pela engenharia de requisitos possuem sua qualidade 
avaliada durante a etapa de validação. A validação de requisitos examina a especificação para 
garantir que todos os requisitos de software tenham sido declarados de forma não ambígua, 
que as inconsistências, omissões e erros tenham sido detectados e corrigidos, e que os arte-
fatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto. O 
principal mecanismo de validação de requisitos é a revisão técnica. A equipe de revisão que 
valida os requisitos é formada por engenheiros de software, clientes, usuários e outros envol-
vidos que examinam a especificação em busca de erros no conteúdo ou na interpretação de 
áreas em que talvez sejam necessários esclarecimentos de informações faltantes, de incon-
sistências (um problema grave quando são criados produtos ou sistemas grandes), de requisi-
tos conflitantes, ou de requisitos irreais (inatingíveis).
Gerenciamento – Os requisitos para sistemas baseados em computador mudam, e o de-
sejo de mudar os requisitos persiste ao longo da vida de um sistema. A gestão de requisitos é 
um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e acompanhar 
as necessidades e suas mudanças à medida que o projeto prossegue.
1.2. Requisitos de softwaRe
Os requisitos de software são frequentemente classificados como requisitos funcionais 
e requisitos não funcionais:
• 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 com-
portar em determinadas situações. Em alguns casos, os requisitos funcionais também 
podem explicitar o que o sistema não deve fazer;
• Requisitos Não Funcionais: são restrições aos serviços ou funções oferecidos pelo sis-
tema. Incluem restrições de timing, restrições no processo de desenvolvimento, e res-
trições impostas pelas normas. Ao contrário das características individuais ou serviços 
do sistema, os requisitos não funcionais, muitas vezes, aplicam–se ao sistema como 
um todo.
Requisitos Funcionais
Os requisitos funcionais especificam funções queo sistema ou componente deve ser ca-
paz de realizar. São utilizados para definir o comportamento do sistema, ou seja, o processo 
ou transformação que componentes de software ou hardware efetuam sobre as entradas para 
gerar as saídas.
Os requisitos funcionais capturam as funcionalidades sob o ponto de vista do usuário.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
9 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Os requisitos funcionais são utilizados para descrever detalhadamente os serviços e fun-
cionalidades que devem ser fornecidas pelo sistema, indicando suas entradas e saídas, ex-
ceções etc.
Quando expressos como requisitos de usuário, os requisitos funcionais são normalmente 
descritos de forma abstrata, para serem compreendidos pelos usuários do sistema. No entan-
to, os requisitos funcionais mais específicos descrevem em detalhes as funções do sistema, 
suas entradas e saídas, exceções etc.
Os requisitos funcionais podem variar de requisitos gerais, que abrangem o que o sistema 
deve fazer, até requisitos muito específicos, que refletem os sistemas e as formas de trabalho 
em uma organização.
A especificação dos requisitos funcionais de um sistema deve ser completa e consistente. 
Ou seja, deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, 
não devem ter definições contraditórias. Completude significa que todos os serviços requeri-
dos pelo usuário devem ser definidos. Consistência significa que os requisitos não devem ter 
definições contraditórias.
Veja o seguinte exemplo, que trata de um conjunto de requisitos funcionais definidos para 
um sistema de gerenciamento de estoque e vendas:
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
10 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Alguns outros exemplos de requisitos funcionais incluem:
• Inserir dados em um formulário.
• Buscar pratos específicos em um cardápio.
• Consultar o status de um pedido.
• Realizar compras.
• Comunicar–se com um atendente.
• Alterar informações de um registro.
• Elaborar relatórios.
Tudo o que for relacionado a uma ação a ser feita é considerado uma função.
Requisitos Não Funcionais
Os requisitos não funcionais, como o nome sugere, são requisitos que não estão direta-
mente relacionados com os serviços específicos oferecidos pelo sistema a seus usuários.
Os requisitos não funcionais podem estar relacionados às propriedades emergentes do 
sistema, como confiabilidade, tempo de resposta e ocupação de área. Também trata dos re-
quisitos que definem as restrições sobre a implementação do sistema, como as capacida-
des dos dispositivos de E/S ou as representações de dados usadas nas interfaces com ou-
tros sistemas.
Perceba que, tanto os requisitos funcionais, quanto os requisitos não funcionais possuem 
importância no desenvolvimento de um sistema de software. Entretanto, os requisitos não 
funcionais, também denominados de atributos de qualidade, têm um papel relevante durante o 
desenvolvimento de um sistema, atuando como critérios na seleção e/ou composição de uma 
arquitetura de software, dentre as várias alternativas de projeto.
Os requisitos não funcionais são frequentemente mais críticos que requisitos funcionais 
individuais. Os usuários do sistema podem, geralmente, encontrar maneiras de contornar uma 
função do sistema que realmente não atenda a suas necessidades. No entanto, deixar de aten-
der a um requisito não funcional pode significar a inutilização de todo o sistema. Por exemplo, 
se um sistema de aeronaves não cumprir seus requisitos de confiabilidade, não será certifica-
do como um sistema seguro para operar. Se um sistema de controle embutido não atender aos 
requisitos de desempenho, as funções de controle não funcionarão corretamente.
Os requisitos não funcionais surgem por meio das necessidades dos usuários, devido a 
restrições de orçamento, políticas organizacionais, necessidade de interoperabilidade com ou-
tros sistemas de software ou hardware, ou a partir de fatores externos, como regulamentos de 
segurança ou legislações de privacidade.
Enquanto os requisitos funcionais estão focados no que será feito, os requisitos não funcio-
nais procuram descrever como será feito.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
11 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Todos os pré–requisitos do sistema, de hardware, de software e operacionais são docu-
mentados separadamente. Entre as características técnicas que podem ser definidas estão:
• Tipo de sistema operacional.
• Hardware a ser utilizado.
• Processamento.
• Consumo de memória.
• Conexão.
• Banco de dados.
• Tipos de dispositivos em que o software pode ser usado.
A figura abaixo é uma classificação de requisitos não funcionais, conforme apresentado 
por Summerville (2011):
No diagrama acima é possível ver que os requisitos não funcionais podem ser provenien-
tes das características requeridas para o software (requisitos de produto), da organização que 
desenvolve o software (requisitos organizacionais ou requisitos de processo) ou de fontes 
externas (requisitos externos):
• Requisitos de Produto: especificam ou restringem o comportamento do software. Exem-
plos incluem os requisitos de desempenho quanto à rapidez com que o sistema deve 
executar e quanta memória ele requer, os requisitos de confiabilidade que estabelecem 
a taxa aceitável de falhas, os requisitos de proteção, e os requisitos de usabilidade.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
12 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
• Requisitos Organizacionais ou Requisitos de Processo: requisitos gerais de sistemas 
derivados das políticas e procedimentos da organização do cliente e do desenvolve-
dor. Ou seja, o software deve ser desenvolvido de acordo com as políticas e definições 
da empresa para garantir que o produto final gerado esteja em conformidade com as 
normas empresariais. Exemplos incluem os requisitos do processo operacional, que 
definem como o sistema será usado, os requisitos do processo de desenvolvimento que 
especificam a linguagem de programação, o ambiente de desenvolvimento ou normas 
de processo a serem usadas, bem como os requisitos ambientais, que especificam o 
ambiente operacional do sistema.
• Requisitos Externos: abrange todos os requisitos que derivam de fatores externos ao 
sistema e seu processo de desenvolvimento. Podem incluir requisitos reguladores, que 
definem o que deve ser feito para que o sistema seja aprovado para uso, por um regula-
dor, tal como um banco central, temostambém requisitos legais, que devem ser segui-
dos para garantir que o sistema opere dentro da lei, e requisitos éticos, que asseguram 
que o sistema será aceitável para seus usuários e o público em geral.
Requisitos de Usabilidade
A usabilidade é um dos atributos de qualidade ou requisitos não funcionais de qualquer 
sistema interativo, ou seja, no qual ocorre interação entre o sistema e seres humanos (usu-
ários). A noção de usabilidade decorre do fato de que qualquer sistema projetado para ser 
utilizado pelas pessoas deveria ser fácil de aprender e fácil de usar, tornando assim fácil e 
agradável a realização de qualquer tarefa.
Os requisitos de usabilidade especificam tanto o nível de desempenho, quanto a satisfação 
do usuário no uso do sistema. Dessa forma, a usabilidade pode ser expressa em termos de:
• Facilidade de aprender: associada ao tempo e esforço mínimo exigido para alcançar um 
determinado nível de desempenho no uso do sistema.
• Facilidade de uso: relacionada à velocidade de execução de tarefas e à redução de erros 
no uso do sistema.
Os requisitos de usabilidade são coletados juntamente com outros requisitos (de dados 
e funcionais) usando algumas das técnicas de elicitação de requisitos como entrevistas ou 
observação. A coleta desses dados pode ocorrer, por exemplo, verificando o log de ações do 
usuário quando do uso de funcionalidade do sistema.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
13 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Requisitos de Manutenibilidade
O termo manutenção de software é geralmente empregado quando nos referimos às mo-
dificações feitas após o software ser disponibilizado para uso. Na realidade, o termo manu-
tenibilidade é um tanto abrangente já que ele envolve tanto a atividade de reparo (de algum 
defeito existente no sistema de software), quanto a atividade de alteração/evolução de carac-
terísticas existentes, ou a adição de novas funcionalidades não previstas ou não capturadas 
no projeto inicial.
O reparo de um sistema de software ocorre quando defeitos são detectados, fazendo–se 
necessária a correção destes. A capacidade de efetuar um reparo depende do número de 
componentes do sistema. Por exemplo, se o sistema é monolítico, ou seja, constituído de um 
único componente, então torna–se mais difícil efetuar o reparo se este sistema de software é 
de grande porte. No entanto, se o sistema de software é modularizado, então tende a ser mais 
fácil analisar e reparar o existente. Podemos dizer que a modularidade favorece a capacidade 
de fazer reparo, permitindo que defeitos fiquem confinados a poucos módulos, considerando–
se que se tenha a funcionalidade adequadamente separada.
Os sistemas de software também evoluem ao longo do tempo, seja com a adição de novas 
funcionalidades, ou com a modificação das existentes. Essa característica também influencia 
a manutenção do software.
O requisito de manutenibilidade também está relacionado com a arquitetura de um sis-
tema de software. A facilidade de fazer alteração no sistema existente, seja adicionando ou 
modificando alguma funcionalidade, depende muito da arquitetura deste. A arquitetura de sof-
tware define seus os componentes e suas interconexões e, portanto, também define sob que 
circunstâncias componentes ou conectores podem ser alterados. Desta forma, uma arquitetu-
ra ou estilo arquitetural de um sistema de software deveria efetivamente acomodar as modifi-
cações que precisarem ser feitas tanto durante seu desenvolvimento, quanto após o sistema 
entrar em operação.
Requisitos de Confiabilidade
A confiabilidade de software é a probabilidade de o software não causar uma falha em um 
sistema durante um determinado período de tempo sob condições especificadas.
A confiabilidade de software, geralmente definida em termos de comportamento estatís-
tico, é a probabilidade que o software tem de operar como desejado num intervalo de tempo 
conhecido. A confiabilidade também é caracterizada como um atributo de qualidade de sof-
tware, o qual implica que um sistema executará suas funções como esperado.
Os requisitos de confiabilidade compreendem restrições sobre o comportamento do sis-
tema de software em tempo de execução, e são definidos através de um conjunto de métricas 
de confiabilidade de software.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
14 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
As falhas dos componentes de software costumam ser de natureza transitória, ou seja, 
ocorrem apenas para algumas entradas específicas, enquanto o sistema pode continuar ope-
rando normalmente em outras circunstâncias. No caso de falhas de componentes de hardwa-
re, essas podem ser de natureza permanente.
Uma falha trata daquilo que é observado pelos usuários (externamente), enquanto os defeitos 
são de origem interna ao sistema e costumam ser os motivadores das falhas.
Podemos utilizar várias métricas para avaliar a confiabilidade de software:
• Disponibilidade: é uma medida de quão disponível o sistema estaria para efetuar um 
serviço solicitado por algum usuário. Por exemplo, um serviço de um sistema de softwa-
re terá uma disponibilidade de 999/1000. Isto significa que dentre um conjunto de 1000 
solicitações de serviço, 999 deverão ser atendidas.
• Taxa de ocorrência de falha: é uma medida da frequência com que o sistema falha em 
prover um serviço como esperado pelo usuário. Por exemplo, se temos uma taxa de 
ocorrência de falha de 2/1000, isto significa que 2 falhas são prováveis de acontecerem 
para cada 1000 unidades de tempo.
• Tempo médio entre falhas ou Mean Time Between Failures (MTBF): refere–se à quanti-
dade média de tempo que um software, dispositivo ou produto funciona antes de falhar. 
Esta unidade de medida inclui apenas o tempo operacional entre falhas e não inclui 
os tempos de reparo, assumindo que, se houve falha, o item foi reparado e começou a 
funcionar novamente. Os valores de MTBF são frequentemente usados para projetar a 
probabilidade de uma única unidade falhar dentro de um certo período de tempo.
• Tempo médio de reparo ou Mean Time to Repair (MTTR): é uma medida da capacidade 
de manutenção de um software, dispositivo ou produto, que informa o tempo médio 
necessário para reparo e retorno ao status normal de trabalho. A medida inclui o tempo 
de notificação, o diagnóstico, e o tempo gasto no reparo real, além de outras atividades 
necessárias para que o software, dispositivo ou produto possa ser usado novamente.
• Tempo médio para a falha ou Mean Time to Failure (MTTF): é uma medida do tempo en-
tre falhas observadas. Oferece um indicativo de quanto tempo o sistema permanecerá 
operacional antes que uma falha aconteça.
Qualquer métrica que venha a ser utilizada para avaliar a confiabilidade de um sistema 
dependerá da forma como o sistema é usado. Note ainda que o tempo é um fator considerado 
nas métricas. Ele é escolhido de acordo com a aplicação. Há sistemas de software que operam 
de forma contínua, enquanto outros operam de maneira periódica.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civile criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
15 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Requisitos de Desempenho
O desempenho é um atributo de qualidade importante para sistemas de software. Consi-
dere, por exemplo, um sistema de uma administradora de cartões de crédito. Em tal sistema, 
um projetista ou engenheiro de software poderia considerar os requisitos de desempenho para 
obter uma resposta de tempo para autorização de compras por cartão.
Os requisitos de desempenho podem afetar os requisitos de usabilidade de um sistema. 
Se um sistema de software é lento, ele certamente reduz a produtividade de seus usuários ao 
ponto de não atender suas necessidades. Além disso, se o sistema de software requer muito 
espaço em disco para armazenamento de informações, pode ser oneroso utilizá–lo. Se um sis-
tema de software exige muita memória para ser executado, ele pode afetar outras aplicações 
que são executadas no mesmo ambiente.
De um modo geral, os requisitos de desempenho podem ser decompostos em termos de 
tempo e espaço, como ilustrado na figura a seguir:
Requisitos de Portabilidade
A portabilidade pode ser definida como a facilidade com que o software pode ser trans-
ferido de um sistema computacional ou ambiente para outro. Em outras palavras, o software 
é dito portável se ele pode ser executado em ambientes distintos. O termo ambiente pode se 
referir tanto à plataforma de hardware, quanto a um ambiente de software como, por exemplo, 
um sistema operacional específico. De um modo geral, a portabilidade refere–se à habilidade 
de executar um sistema em diferentes plataformas.
Adicionalmente, podemos ter a portabilidade de componentes e a portabilidade de sis-
temas. Esta última situação pode ser vista como caso especial de reusabilidade. O reuso de 
software ocorre quando todo o sistema de software é reutilizado, sendo implementado em 
diferentes sistemas computacionais.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
16 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Dois aspectos relevantes na portabilidade de programas são a transferência e adaptação. 
A transferência é o movimento de componente (código de um programa e dados associados) 
de um ambiente para outro. A adaptação engloba as modificações exigidas para fazer com que 
o programa seja executado em um novo ambiente.
Uma abordagem geral que poderia ser adotada para obter um sistema portável seria sepa-
rar as partes do sistema que dependem do ambiente externo em uma camada ou interface de 
portabilidade, conforme ilustrado na figura abaixo:
A interface de portabilidade poderia ser projetada como um conjunto de tipos de dados ou 
objetos abstratos, onde os elementos não portáveis seriam encapsulados com o objetivo de 
esconder características do software da aplicação. Dessa forma, quando o software muda de 
hardware ou sistema operacional, apenas a interface de portabilidade precisaria ser alterada.
Requisitos de Reusabilidade
Componentes que já tenham sido desenvolvidos e testados podem ser reutilizados. Na en-
genharia de software, uma das formas de reduzir custos de desenvolvimento e manutenção de 
sistemas de software, bem como os custos da obtenção de sistemas com qualidade elevada, é 
considerar a reusabilidade como requisito não funcional no desenvolvimento de novos sistemas.
O reuso pode ser visto sob diferentes perspectivas, pode ser orientado a componentes, 
orientado a processos, ou orientado ao conhecimento específico de um domínio. Exemplos 
desse tipo de reuso são:
• Aplicação: toda a aplicação poderia ser reutilizada.
• Subsistemas: os principais subsistemas de uma aplicação poderiam ser reutilizados.
• Objetos ou módulos: componentes de um sistema, englobando um conjunto de funções, 
podem ser reutilizados.
• Funções: componentes de software que implementam uma única função (como uma 
função matemática) podem ser reutilizados.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
17 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Requisitos de Segurança
Em um software, os requisitos de segurança costumam ser caracterizados para não per-
mitir acessos não autorizados ao sistema ou software e aos seus dados, além de assegurar a 
integridade do sistema ou software quanto a ataques intencionais ou acidentes.
Exemplos de requisitos de segurança são:
• Apenas pessoas que tenham sido autenticadas por um componente de controle de 
acesso (identificação, autenticação e autorização) poderão visualizar informações e 
dados associados.
• As permissões de acesso ao sistema podem ser alteradas apenas pelo administrador 
de sistemas.
• Devem ser feitas cópias (backup) de todos os dados do sistema com uma frequência e 
retenção determinada, e estas cópias devem ser guardadas em um local seguro, sendo 
preferencialmente num local diferente de onde se encontra o sistema.
• Todas as comunicações externas entre o servidor de dados do sistema e clientes devem 
ser criptografadas.
Os requisitos não funcionais de segurança envolvem diferentes aspectos, como podemos 
observar na figura a seguir:
• Disponibilidade: refere–se a assegurar o sistema contra qualquer interrupção de serviço.
• Integridade: possui o objetivo de evitar o acesso ou atualizações não autorizadas.
• Confidencialidade: a ênfase aqui é a de não permitir a revelação não autorizada de in-
formações.
• Segurança operacional: refere–se à fase considerada para o sistema em uso.
Sempre que possível, os requisitos não funcionais devem ser escritos quantitativamente, para 
que possam ser objetivamente testados. A tabela a seguir mostra as métricas que você pode 
utilizar para especificar as propriedades não funcionais do sistema. Você pode medir essas 
características quando o sistema está sendo testado para verificar se ele tem cumprido ou não 
os seus requisitos não funcionais.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
18 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
1.3. documento de Requisitos de softwaRe
O documento de requisitos de software ou Especificação de Requisitos de Software (SRS, 
do inglês Software Requirements Specification) é uma documentação formal do que é exigido 
dos desenvolvedores de sistema.
Um documento de requisitos de software precisa ser claro, consistente e completo, pois 
servirá de referência aos desenvolvedores, gerente de projeto, engenheiros de software (res-
ponsáveis pelos testes e manutenção do sistema), além de servir de base para definir o es-
copo das funcionalidades a serem registradas num contrato. Os requisitos compreendem o 
cerne de qualquer produto, e as mudanças sobre eles podem ocorrer ao longo do ciclo de vida 
de um software.
O documento deve incluir os requisitos de usuários para um sistema e uma especificação 
detalhada dos requisitos de sistema.Em alguns casos, os requisitos de usuário e requisitos 
de sistema podem ser integrados em uma única descrição.
O documento de requisitos tem um conjunto diversificado de usuários, que vão desde a 
alta administração da organização que está pagando pelo sistema, até os engenheiros respon-
sáveis pelo desenvolvimento do software.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
19 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
A figura a seguir mostra os possíveis usuários do documento e como eles o utilizam:
O documento de requisitos de software delimita o escopo do conjunto de funcionalidades 
que um sistema deve prover, bem como descreve os atributos de qualidade que devem ser 
suportados. Este documento deve ser elaborado de maneira precisa, completa, consistente e, 
principalmente, compreensível aos stakeholders (isto é, os principais interessados no sistema).
O documento de requisitos de software será lido por várias pessoas interessadas no pro-
jeto como, por exemplo, clientes, gerente de projeto, engenheiro de testes e programadores e, 
portanto, precisa comunicar com clareza os requisitos do sistema.
O documento de requisitos de software de um projeto tem o objetivo de documentar o 
escopo do sistema a ser desenvolvido. Nesse sentido, o documento de requisitos deve conter:
• Introdução e visão geral do documento;
• Descrição de requisitos funcionais;
• Descrição de requisitos não funcionais;
• Escopo não contemplado (de funcionalidades).
• Documentação de apoio.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
20 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
O documento de requisitos de software serve como um termo de consenso entre a equipe 
técnica (desenvolvedores) e o cliente, e constitui a base para as atividades subsequentes do 
desenvolvimento do sistema, fornecendo um ponto de referência para qualquer validação fu-
tura do software construído.
Além disso, o documento de requisitos de software estabelece o escopo (o que faz parte 
e o que não faz parte) do sistema, abrangendo um conjunto diversificado de usuários, que vai 
desde a alta gerência da organização, que está pagando pelo sistema, até os engenheiros res-
ponsáveis pelo desenvolvimento do software.
O nível de detalhes que será incluído em um documento de requisitos de software de-
pende do tipo de sistema em desenvolvimento e do processo usado. Os sistemas críticos 
precisam ter requisitos detalhados, porque a segurança e a proteção devem ser analisadas 
em detalhes. Quando o sistema está sendo desenvolvido por uma companhia separada (por 
exemplo, através de outsourcing), as especificações de sistema devem ser detalhadas e preci-
sas. Se um processo interno de desenvolvimento iterativo é usado, o documento de requisitos 
pode ser muito menos detalhado, e quaisquer ambiguidades podem ser resolvidas durante o 
desenvolvimento do sistema.
1.4. especificação de Requisitos
A especificação de requisitos é o processo de escrever os requisitos de usuário e requi-
sitos de sistema em um documento de requisitos de software. Os requisitos de usuário e 
os requisitos de sistema devem ser claros, inequívocos, de fácil compreensão, completos e 
consistentes.
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não 
funcionais, de modo que sejam compreensíveis para os usuários do sistema que não possuem 
conhecimentos técnicos detalhados. Desta forma, é interessante que não sejam incluídos de-
talhes da arquitetura ou projeto do sistema.
Os requisitos de usuário são quase sempre escritos em linguagem natural, através do uso 
de tabelas simples, formas e diagramas intuitivos. Os requisitos de sistema também podem 
ser escritos em linguagem natural, mas também em outras notações com base em formulá-
rios, modelos gráficos ou matemáticos de sistema.
A tabela a seguir resume as notações que poderiam ser usadas para escrever os requisitos 
de sistema:
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
21 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
1.5. pRocessos de engenhaRia de Requisitos
Os processos de engenharia de requisitos podem incluir quatro atividades de alto nível. 
Essas atividades procuram avaliar se o sistema é útil para a empresa (estudo de viabilidade), 
descobrir os requisitos do sistema (elicitação e análise de requisitos), converter esses requisi-
tos em algum documento formal ou em alguma forma–padrão (especificação de requisitos), 
e verificar se os requisitos realmente definem o sistema solicitado (validação de requisitos).
A engenharia de requisitos é um processo iterativo em que as atividades são intercaladas. 
A figura abaixo apresenta esta intercalação entre as atividades:
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
22 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
As atividades são organizadas em torno de uma espiral, como um processo iterativo, sen-
do a saída um documento de requisitos de sistema. A quantidade de tempo e esforço dedica-
dos a cada atividade em cada iteração depende do estágio do processo como um todo e do 
tipo de sistema que está sendo desenvolvido. No início do processo, o esforço maior será a 
compreensão dos requisitos de negócio e não funcionais em alto nível, bem como dos requisi-
tos de usuário para o sistema. Mais tarde no processo, nos anéis externos da espiral, o esforço 
maior será dedicado a elicitar e compreender os requisitos de sistema em detalhes.
Isso significa dizer que, nesse modelo em espiral, os requisitos são desenvolvidos em di-
ferentes níveis de detalhamento. Assim, no início do processo, o foco será em compreender 
os requisitos do negócio e requisitos não funcionais em alto nível, de uma forma abstrata, sem 
abordar detalhes, assim como os requisitos de usuário para o sistema. Mais tarde no proces-
so, o foco será na elicitação e na compreensão dos requisitos do sistema de forma mais deta-
lhada, trazendo uma abordagem de baixo nível.
O número de iterações em torno da espiral pode variar, assim, a espiral pode acabar depois 
da definição de alguns ou de todos os requisitos de usuário.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
23 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DESOFTWARE
Sérgio Sierro
A engenharia de requisitos pode ser considerada o processo de aplicação de um método 
de análise estruturada, como a análise orientada a objetos. Trata–se de analisar o sistema e 
desenvolver um conjunto de modelos gráficos de sistema, como modelos de casos de uso, 
que, então, servem como uma especificação do sistema. O conjunto de modelos descreve o 
comportamento do sistema e é anotado com informações adicionais, descrevendo, por exem-
plo, o desempenho ou a confiabilidade requerida do sistema.
Outro ponto que importa mencionar é que, em praticamente todos os sistemas, os requisitos 
podem passar por mudanças, seja para adicionar uma nova funcionalidade, ou uma nova carac-
terística do sistema. As pessoas envolvidas desenvolvem uma melhor compreensão do que que-
rem do software, a organização que compra o sistema também muda, modificações são feitas 
no hardware, no software, ou até mesmo no ambiente organizacional do sistema. O processo de 
gerenciamento das mudanças desses requisitos é chamado de gerenciamento de requisitos.
1.6. elicitação e análise de Requisitos
Após um estudo inicial de viabilidade, o próximo estágio do processo de engenharia de re-
quisitos é a elicitação e análise de requisitos. Serão obtidas informações sobre o domínio da 
aplicação, os serviços que o sistema deve oferecer, o desempenho do sistema, restrições de 
hardware e assim por diante. Pode envolver diversos tipos de pessoas em uma organização.
O termo elicitar pode ser definido como “definir, tonar explícito, obter o máximo de informa-
ções sobre o objeto em questão”. A elicitação de requisitos é o processo de buscar, descobrir, 
adquirir, e elaborar requisitos para sistemas.
Um modelo do processo de elicitação e análise de requisitos é mostrado na figura a seguir:
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
24 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Cada organização terá sua própria versão ou instância desse modelo geral, dependendo 
de fatores locais, como conhecimento do pessoal, o tipo de sistema a ser desenvolvido, as 
normas usadas etc.
As atividades do processo de elicitação e análise de requisitos são:
• 1 – Descoberta de requisitos: essa é a atividade de interação com os stakeholders do 
sistema para descobrir seus requisitos para o sistema;
• 2 – Classificação e organização de requisitos: essa atividade toma a coleção de requisi-
tos não estruturados, agrupa requisitos relacionados, e os organiza em grupos coerentes;
• 3 – Priorização e negociação de requisitos: inevitavelmente, quando os vários stakehol-
ders estão envolvidos, os requisitos entram em conflito. Essa atividade está relacionada 
com a priorização de requisitos e em encontrar e resolver os conflitos por meio da nego-
ciação de requisitos;
• 4 – Especificação de requisitos: os requisitos são documentados e inseridos no próxi-
mo ciclo da espiral.
Descoberta de Requisitos
A descoberta de requisitos é o processo de reunir informações sobre o sistema requerido 
e separar dessas informações os requisitos de usuário e de sistema. Fontes de informação 
durante a fase de descoberta de requisitos incluem documentação, stakeholders do sistema 
e especificações de sistemas similares. São feitas interações com os stakeholders por meio 
da observação (etnografia) e de entrevistas, e cenários e protótipos podem ser usados para 
ajudar na compreensão do sistema.
Os stakeholders variam desde os usuários finais, gerentes do sistema, podendo ser stake-
holders externos, ou reguladores que certificam o sistema. Por exemplo, os stakeholders de 
um sistema de informação da saúde mental de pacientes podem incluir:
• Os pacientes que possuem informações registradas no sistema;
• Os médicos responsáveis pela avaliação e tratamento dos pacientes;
• Os enfermeiros que, alinhados com os médicos, coordenam as consultas e administram 
tratamentos;
• Os recepcionistas dos médicos, que gerenciam as consultas dos pacientes;
• A equipe de TI que é responsável pela instalação e manutenção do sistema;
• A equipe de registros médicos, responsável por garantir que as informações do sistema 
sejam mantidas e preservadas, e que os procedimentos de manutenção dos registros 
sejam devidamente implementados.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
25 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Durante o processo de elicitação de requisitos, os requisitos oriundos do domínio da apli-
cação e de outros sistemas que interagem com o sistema específico devem ser considerados.
Essas diferentes fontes de requisitos (stakeholders, domínio, sistemas) podem ser repre-
sentadas como pontos de vista do sistema, com cada ponto de vista mostrando um subcon-
junto dos requisitos para o sistema. Pontos de vista diferentes sobre um problema percebem 
o problema de maneiras diferentes. No entanto, suas perspectivas não são completamente 
independentes. Em geral, elas se sobrepõem e, dessa forma, apresentam requisitos comuns.
Entrevistas
Entrevistas formais ou informais com os stakeholders do sistema são parte da maioria 
dos processos de engenharia de requisitos. Nessas entrevistas, a equipe de engenharia de 
requisitos questiona sobre o sistema que usam no momento e sobre o sistema que será de-
senvolvido. Requisitos surgem a partir das respostas a essas perguntas.
As entrevistas podem ser de dois tipos:
• Entrevistas fechadas: em que o stakeholder responde a um conjunto predefinido de per-
guntas;
• Entrevistas abertas: em que não existe uma agenda predefinida e a equipe de engenha-
ria de requisitos explora uma série de questões com os stakeholders do sistema, assim, 
desenvolve uma melhor compreensão de suas necessidades.
Na prática, as entrevistas com os stakeholders costumam ser uma mistura de ambos os 
tipos. Você poderá ter de obter a resposta a determinadas questões, mas é comum que estas 
levem a outras, discutidas de forma menos estruturada. Discussões totalmente abertas rara-
mente funcionam bem. Geralmente, é necessário fazer algumas perguntas para começar e, 
então, manter a entrevista centrada no sistema que será desenvolvido.
Entrevistas são boas para obter uma compreensão global sobre o que os stakeholders 
fazem, como eles podem interagir com o novo sistema, e as dificuldades que eles enfrentam 
com os sistemas atuais.
Cenários
Os cenários podem ser úteis para adicionar detalhes a uma descrição geral de requisi-
tos. Cada cenário geralmente cobre um pequeno número de interações possíveis. Diferentes 
cenários são desenvolvidos e oferecem diversos tipos de informação em variados níveis de 
detalhamento sobre o sistema.
Um cenário começa com um esboço da interação. Durante o processo de elicitação, são 
adicionados detalhes ao esboço, para criar uma descrição completa dessa interação. Em sua 
forma mais geral, um cenário pode incluir:
• Uma descrição do que o sistema e os usuários esperam quando o cenário se iniciar;
• Uma descrição do fluxo normal de eventos no cenário;
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.brhttps://www.grancursosonline.com.br
26 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
• Uma descrição do que pode dar errado e como isso é tratado;
• Informações sobre outras atividades que podem acontecer ao mesmo tempo;
• Uma descrição do estado do sistema quando o cenário acaba.
A elicitação baseada em cenários envolve o trabalho com os stakeholders para identificar 
cenários e capturar detalhes que serão incluídos nesses cenários. Os cenários podem ser 
escritos como texto, suplementados por diagramas, telas etc. Além disso, também é possível 
usar uma abordagem mais estruturada, em que cenários de eventos ou casos de uso podem 
ser usados.
Como exemplo de um cenário de texto simples, observe a figura a seguir:
Casos de Uso
Os casos de uso se tornaram uma característica fundamental da linguagem de modela-
gem unificada (UML, do inglês Unified Modeling Language). Em sua forma mais simples, um 
caso de uso identifica os atores envolvidos em uma interação, e dá nome ao tipo de interação. 
Esta é, então, suplementada por informações adicionais que descrevem a interação com o 
sistema. A informação adicional pode ser uma descrição textual ou um ou mais modelos grá-
ficos, como diagrama de sequência ou de estados da UML.
Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O 
conjunto de casos de uso representa todas as possíveis interações que serão descritas nos 
requisitos de sistema.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
27 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Atores, que podem ser pessoas ou outros sistemas, são representados como figuras ‘pali-
to’. Cada classe de interação é representada por uma elipse. Linhas fazem a ligação entre os 
atores e a interação. Opcionalmente, pontas de flechas podem ser adicionadas às linhas para 
mostrar como a interação se inicia.
Essa situação é ilustrada na figura a seguir, que mostra alguns dos casos de uso para o 
sistema de informações de pacientes:
Os casos de uso identificam as interações individuais entre o sistema e seus usuários 
ou outros sistemas. Cada caso de uso deve ser documentado com uma descrição textual. 
Esta, por sua vez, pode ser ligada a outros modelos UML que desenvolverão o cenário com 
mais detalhes.
Cenários e casos de uso são técnicas eficazes para elicitar requisitos dos stakeholders 
que vão interagir diretamente com o sistema. Cada tipo de interação pode ser representado 
como um caso de uso. No entanto, devido a seu foco nas interações com o sistema, eles não 
são tão eficazes para elicitar restrições ou requisitos de negócios e requisitos não funcionais 
em alto nível, ou para descobrir requisitos de domínio.
Etnografia
Os sistemas de software não existem isoladamente. Eles são usados em um contexto so-
cial e organizacional, e requisitos de software do sistema podem ser derivados ou restringidos 
desse contexto. Geralmente, satisfazer a esses requisitos sociais e organizacionais é crítico 
para o sucesso do sistema. Uma razão pela qual muitos sistemas de software são entregues, 
mas nunca são usados, é que seus requisitos não levam em conta a forma como o contexto 
social e organizacional afeta o funcionamento prático do sistema.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
28 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Etnografia é uma técnica de observação que pode ser usada para compreender os proces-
sos operacionais e ajudar a extrair os requisitos de apoio para esses processos. Uma imersão 
é realizada no ambiente de trabalho em que o sistema será usado. O trabalho do dia a dia é 
observado, e são feitas anotações sobre as tarefas reais em que os participantes estão envol-
vidos. O valor da etnografia é que ela ajuda na identificação de requisitos implícitos do siste-
ma que refletem as formas reais com que as pessoas trabalham, em vez de refletir processos 
formais definidos pela organização.
A etnografia é particularmente eficaz para descobrir dois tipos de requisitos:
• Requisitos derivados da maneira como as pessoas realmente trabalham, e não da forma 
como as definições dos processos dizem que deveriam trabalhar. Por exemplo, controlado-
res de tráfego aéreo podem desligar um sistema de alerta de conflitos que detecta aerona-
ves com rotas em colisão, embora os procedimentos de controle normal especifiquem que 
ele deve ser usado. Eles deliberadamente colocam a aeronave em caminhos conflitantes, 
por um curto período, para ajudar no gerenciamento do espaço aéreo. Sua estratégia de 
controle é projetada para assegurar que os aviões sejam afastados dessa rota conflitante 
antes que surjam problemas, e eles acham que o alarme de alerta distrai seu trabalho.
• Requisitos derivados da cooperação e conhecimento das atividades de outras pessoas. 
Por exemplo, controladores de tráfego aéreo podem usar conhecimento do trabalho de 
outros controladores para prever o número de aeronaves que entrarão em seu setor de 
controle. Eles, então, modificam suas estratégias de controle, dependendo do volume 
de trabalho previsto. Portanto, um sistema ATC automatizado deve permitir que os con-
troladores de um setor tenham alguma visibilidade do trabalho em setores adjacentes.
A etnografia pode ser combinada com prototipação, conforme podemos observar na figu-
ra a seguir:
A etnografia informa o desenvolvimento do protótipo, para que menos ciclos de refinamento 
do protótipo sejam necessários. Além disso, a prototipação dá foco para a etnografia, ao identi-
ficar problemas e questões que podem ser discutidos com o etnógrafo. Esse profissional deve 
procurar as respostas para essas perguntas durante a próxima fase do estudo do sistema.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
29 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
1.7. Validação de Requisitos
A validação de requisitos é o processo em que se verifica se os requisitos definem o sis-
tema que o cliente realmente quer. Ela se sobrepõe à análise, uma vez que está preocupada 
em encontrar problemas com os requisitos.
Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser 
efetuados com os requisitos no documento de requisitos. Essas verificações incluem:
• Verificações de validade: um usuário pode pensar que é necessário um sistema para 
executar determinadas funções. No entanto, uma maior reflexão e uma análise mais 
aprofundada podem identificar funções necessárias, adicionais ou diferentes. Os sis-
temas possuem diversas partes interessadas com diferentes necessidades, e qualquer 
conjunto de requisitos é inevitavelmente um compromisso com as partes interessadas.
• Verificações de consistência: requisitos no documento 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.
• Verificaçõesde completude: o documento de requisitos deve incluir requisitos que de-
finam todas as funções e as restrições pretendidas pelo usuário do sistema.
• Verificações de realismo: usando o conhecimento das tecnologias existentes, os requisi-
tos devem ser verificados para assegurar que realmente podem ser implementados, con-
siderando as restrições de orçamento e cronograma para o desenvolvimento do sistema.
• Verificabilidade: para reduzir o potencial de conflito entre o cliente e o contratante, os 
requisitos do sistema devem ser passíveis de verificação. Isso significa dizer que você 
deve ser capaz de escrever um conjunto de testes que demonstrem que o sistema en-
tregue atende a cada requisito especificado.
Existe uma série de técnicas de validação de requisitos que podem ser usadas individual-
mente ou em conjunto:
• Revisões de requisitos: os requisitos são analisados sistematicamente por uma equipe 
de revisores que verifica erros e inconsistências.
• Prototipação: nessa abordagem para validação, um modelo executável do sistema é 
demonstrado para os usuários finais e clientes. Estes podem experimentar o modelo 
para verificar se ele atende a suas reais necessidades.
• Geração de casos de teste: os requisitos devem ser testáveis. Se os testes forem con-
cebidos como parte do processo de validação, isso frequentemente revela problemas de 
requisitos. Se é difícil ou impossível projetar um teste, isso normalmente significa que os 
requisitos serão difíceis de serem implementados e devem ser reconsiderados.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
30 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
1.8. geRenciamento de Requisitos
O processo de gerenciamento de requisitos corresponde ao conjunto de atividades que 
auxilia a equipe do projeto a identificar, controlar e rastrear os requisitos, bem como as al-
terações nos requisitos em muitos momentos do projeto. Em outras palavras, é o processo 
que gerencia mudanças nos requisitos de um sistema. Estas mudanças ocorrem conforme os 
clientes desenvolvem maior entendimento de suas reais necessidades.
Os requisitos para sistemas de software de grande porte estão sempre mudando. Durante 
o processo de software, o entendimento das partes interessadas a respeito do problema está 
em constante mutação. Logo, os requisitos de sistema devem evoluir para refletir essas no-
vas percepções do problema.
O gerenciamento de requisitos é o processo de compreensão e controle das mudanças 
nos requisitos do sistema. É necessário se manter alinhado com as necessidades para conse-
guir avaliar o impacto das mudanças nos requisitos. É preciso estabelecer um processo formal 
para fazer propostas de mudanças e relacionar essas mudanças às exigências do sistema. O 
processo formal de gerenciamento de requisitos deve começar assim que uma versão pre-
liminar do documento de requisitos estiver disponível. No entanto, você deve começar a pla-
nejar como gerenciar mudanças de requisitos durante o processo de elicitação de requisitos.
Podemos definir que o gerenciamento de requisitos trata de um modelo sistemático para:
• Identificar, organizar e documentar os requisitos do sistema;
• Estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variá-
veis do sistema.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
31 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Planejamento de Gerenciamento de Requisitos
O planejamento é o primeiro estágio essencial no processo de gerenciamento de requisi-
tos, e determina o nível de detalhamento requerido no gerenciamento de requisitos. Durante 
o estágio de gerenciamento de requisitos, você deve decidir sobre:
• Identificação de requisitos: cada requisito deve ser identificado unicamente para poder 
ser comparado com outros requisitos e usado em avaliações de rastreabilidade.
• Processo de gerenciamento de mudanças: esse é o conjunto de atividades que avaliam 
o impacto e o custo das mudanças.
• Políticas de rastreabilidade: definem os relacionamentos entre cada requisito e entre os 
requisitos e o projeto de sistema que deve ser registrado. A política de rastreabilidade 
também deve definir como esses registros devem ser mantidos.
• Ferramenta de apoio: gerenciamento de requisitos envolve o processamento de grandes 
quantidades de informações sobre os requisitos. Ferramentas que podem ser usadas 
variam desde sistemas especializados em gerenciamento de requisitos, até planilhas e 
sistemas de banco de dados simples.
Gerenciamento de Mudança de Requisitos
Após a aprovação do documento de requisitos, o gerenciamento de mudança de requi-
sitos deve ser aplicado a todas as mudanças propostas aos requisitos de um sistema, como 
podemos observar na figura a seguir:
A vantagem de se usar um processo formal de gerenciamento de mudanças é que todas 
as propostas de mudanças são tratadas de forma consistente, e as alterações nos documen-
tos de requisitos são feitas de forma controlada.
Existem três estágios principais em um processo de gerenciamento de mudanças:
• Análise de problema e especificação de mudanças: o processo começa com um proble-
ma de requisitos identificado ou, às vezes, com uma proposta específica de mudança. 
Durante esse estágio, o problema ou a proposta de mudança é analisada a fim de se 
verificar sua validade. Essa análise é transmitida a quem solicitou a mudança, que pode 
responder com uma proposta mais específica de mudança de requisitos, ou retirar a 
solicitação.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
32 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
• Análise de mudanças e custos: o efeito da mudança proposta é avaliado por meio de 
informações de rastreabilidade e conhecimentos gerais dos requisitos do sistema. O 
custo de fazer a mudança é estimado em termos de modificações no documento de re-
quisitos e, se apropriado, no projeto e na implementação do sistema. Uma vez que essa 
análise é concluída, será decidido se a mudança de requisitos será ou não incorporada.
• Implementação de mudanças: o documento de requisitos e, quando necessário, o pro-
jeto e implementação do sistema são modificados. Você deve organizar o documento 
de requisitos para poder fazer alterações sem ampla reformulação ou reorganização. 
Tal como acontece com os programas, a mutabilidade nos documentos é obtida minimi-
zando–se as referências externas e tornando as seções do documento o mais modular 
possível. Assim, as seções individuais podem ser alteradas e substituídas sem afetar 
outras partes do documento.
Se um novo requisito precisa ser implementado com urgência, há sempre a tentação de mu-
dar o sistema e, em seguida, retrospectivamente modificar o documento de requisitos. Esse pro-
cedimento deve ser evitado, pois quase inevitavelmente faz com que a especificação de requisi-
tos e a implementação do sistema fiquem defasadas. Uma vez que mudanças no sistemaforam 
feitas, é fácil esquecer de incluir essas alterações no documento de requisitos, ou até mesmo 
acrescentar informações inconsistentes com a implementação no documento de requisitos.
Processos ágeis de desenvolvimento, como o Extreme Programming, foram concebidos 
para lidar com requisitos mutáveis durante o processo de desenvolvimento. Nesses proces-
sos, quando um usuário propõe uma mudança nos requisitos, a mudança não passa por um 
processo formal de gerenciamento de mudanças. Pelo contrário, o usuário precisa priorizar 
essa mudança e, em caso de alta prioridade, decidir quais recursos do sistema planejados para 
a próxima iteração devem ser abandonados.
2. diagRama de casos de uso
O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema que 
será projetado. Trata–se de uma excelente ferramenta para o levantamento dos requisitos 
funcionais do sistema. Um caso de uso é um documento narrativo que descreve a sequência 
de eventos de um ator que usa um sistema para completar um processo.
Um caso de uso representa uma unidade discreta da interação entre um ator (humano, 
dispositivo ou outro software) e o sistema. Um caso de uso é uma unidade de um trabalho 
significante. Por exemplo, o “login para o sistema”, “registrar no sistema” e “criar pedidos” são 
todos casos de uso.
Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema 
proposto. Um caso de uso pode “incluir” outra funcionalidade de caso de uso ou “estender” 
outro caso de uso com seu próprio comportamento.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
33 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Os casos de uso são tipicamente relacionados a “atores”. Um ator é um humano ou entida-
de máquina que interage com o sistema para executar um trabalho significativo.
O objetivo do diagrama de caso de uso é demonstrar as diferentes maneiras com que o usuário 
pode interagir com um sistema. O diagrama de caso de uso não oferece muitos detalhes. Em 
vez disso, oferece uma visão geral do relacionamento entre casos de uso, atores e sistemas.
O diagrama de caso de uso resume os detalhes dos usuários do seu sistema (também 
conhecidos como atores) e as interações deles com o sistema.
O caso de uso é representado por uma forma oval rotulada. Os atores no processo são 
representados por bonecos palito, e a participação do ator no sistema é modelada com uma 
linha entre o ator e o caso de uso. Para representar o limite do sistema, desenhe uma caixa em 
torno do próprio caso de uso.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
34 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Para entender o que é um diagrama de caso de uso, é necessário primeiro saber como é ele 
feito. Assim, vale pontuar seus componentes comuns:
• Atores: os usuários que interagem com o sistema. Ator pode ser uma pessoa, organi-
zação ou sistema externo que interage com seu aplicativo ou sistema. Eles devem ser 
objetos externos que produzam ou consumam dados.
• Sistema: uma sequência específica de ações e interações entre os atores e o sistema. 
O sistema também pode ser chamado de cenário.
• Metas: o resultado final da maioria dos casos de uso. Um diagrama criado corretamente 
deve descrever as atividades e variantes usadas para atingir a meta.
Como podemos observar, o diagrama é composto por desenhos simples que descrevem 
de maneira bem objetiva o que textualmente poderia ficar extenso. Nele, é possível ver as fun-
cionalidades do sistema e as interações dos usuários com elas.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
35 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
Para melhorar um pouco mais esse diagrama, vamos ver o conceito de <>. Include e extend 
são relações entre os casos de uso.
• Include: seria a relação de um caso de uso que, para ter sua funcionalidade executada, 
precisa chamar outro caso de uso.
• Extend: Esta relação significa que o caso de uso estendido vai funcionar exatamente 
como o caso de uso base, porém alguns passos novos serão inseridos no caso de uso 
estendido.
O diagrama de casos de uso corresponde a uma visão externa do sistema e representa 
graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. O dia-
grama tem como objetivo ilustrar, em um nível alto de abstração, quais elementos externos 
interagem com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso 
de uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de 
um sistema e as maneiras que eles as utilizam.
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
https://www.grancursosonline.com.br
https://www.grancursosonline.com.br
36 de 64www.grancursosonline.com.br
Requisitos de Software. Casos de Uso e Diagramas de Caso de Uso
ENGENHARIA DE SOFTWARE
Sérgio Sierro
RESUMO
• Engenharia de Requisitos – Na engenharia de software, a análise de requisitos, ou en-
genharia de requisitos, engloba todas as tarefas que lidam com investigação, definição 
e escopo de novos sistemas ou alterações. A análise de requisitos é uma parte impor-
tante do processo de desenvolvimento de softwares, em que o engenheiro de requisitos 
e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de 
software, identificam as necessidades ou requisitos de um cliente. Um requisito é a 
capacidade pela qual um resultado do projeto (produto ou serviço) deve obedecer. Uma 
vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas 
estarão preparados para projetar a solução. A engenharia de requisitos abrange sete 
tarefas distintas: concepção, levantamento, elaboração, negociação, especificação, 
validação e gestão.
− Requisitos de Software – No âmbito da engenharia de software, um requisito consis-
te na definição documentada de uma propriedade ou comportamento que um pro-
duto ou serviço em particular deve atender. Esses diferentes níveis de descrição de 
requisitos podem ser definidos como:
 ◦ Requisitos de usuário são declarações, em uma linguagem natural com diagra-
mas, de quais serviços o sistema deverá fornecer a seus usuários e as restrições 
com as quais este deve operar.
 ◦ Requisitos de sistema são descrições mais detalhadas das funções, serviços e 
restrições operacionais do sistema de software. O documento de requisitos do 
sistema (às vezes, chamado especificação funcional) deve definir exatamente o 
que deve ser implementado.
− Requisitos Funcionais e Requisitos Não Funcionais – Os requisitos de software são 
frequentemente classificados como requisitos funcionais e requisitos não funcionais:
 ◦ Requisitos Funcionais: são declarações de serviços que o sistema