ENGENHARIA DE SOFTWARE PII

Prévia do material em texto

Engenharia de 
Software 
Engenharia de 
Software 
1ª edição
2019
Autoria
Parecerista Validador
Juliana Padilha
Sandra Gavioli Puga / Paulo Lacerda
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
30
 3Unidade 3
3. Engenharia de Requisitos e 
Modelagem de Software 
Para iniciar seus estudos
Nesta unidade, você verá os conceitos de requisitos de software e os 
processos envolvidos na descoberta e documentação de requisitos. 
A compreensão dos requisitos de software está entre as tarefas mais 
difíceis da engenharia de software. Vamos lá?
Objetivos de Aprendizagem
• Definir requisitos de software.
• Definir os requisitos de usuário e de sistemas.
• Identificar e explicar as diferenças entre os requisitos de software 
funcionais e não funcionais.
• Identificar a importância do levantamento dos requisitos para 
projetos de software.
• Identificar as técnicas ideais para descobrir (levantar) os requisitos 
do software a ser desenvolvido.
31
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Introdução da unidade
Nesta unidade, iniciaremos os estudos sobre conceitos que lhe permitirão entender a importância dos requisitos 
de software e também realizar a descoberta e a validação destes. Apresentaremos algumas técnicas utilizadas 
para a elicitação (ou levantamento) dos requisitos de software. Para isso, trabalharemos com base nos seguintes 
questionamentos:
• O que são requisitos de software?
• Quais são os tipos de requisitos de software e como diferenciar requisitos funcionais dos requisitos não 
funcionais?
• Quais são as técnicas utilizadas para levantamento dos requisitos de software? 
• É possível combinar uma ou mais técnicas no momento do levantamento de requisitos?
3.1 Engenharia de requisitos
Segundo Sommerville (2011), os requisitos de software consistem em detalhar o que o sistema deve fazer, quais 
serviços deve oferecer e quais as limitações em relação ao seu funcionamento. A compreensão de requisitos 
de software está entre as tarefas mais difíceis enfrentadas pelos engenheiros de software. Isso ocorre porque o 
cliente muitas vezes não sabe verbalizar suas necessidades ou não sabe o que é realmente necessário que o seu 
software faça. Outro problema é a alteração de requisitos ao longo do processo do software, pois, à medida que o 
desenvolvimento avança, o cliente pode sentir a necessidade de alguma funcionalidade ou mesmo considerar 
outra como desnecessária. 
Diante dessas dificuldades, surgiu a necessidade da criação de uma técnica – a engenharia de requisitos – para 
facilitar o entendimento das necessidades dos clientes antes de se projetar o software. A engenharia de requisitos 
fornece um mecanismo para entender aquilo que o cliente deseja por meio da análise de suas necessidades, 
avaliação da viabilidade, negociação de uma solução razoável, especificação da solução sem ambiguidades, 
validação da especificação e gerenciamento das necessidades à medida que são transformadas em um sistema 
operacional (PRESSMAN, 2016). 
A engenharia de requisitos abrange sete tarefas distintas; algumas delas ocorrem em paralelo, e todas são 
adaptadas às necessidades do projeto. De acordo com Pressman (2016), as sete tarefas são:
1. Concepção – consiste em compreender o problema, propor uma solução para resolvê-lo e entender 
o que o cliente deseja. A eficácia da comunicação e colaboração iniciais entre o cliente e a equipe de 
software também é essencial. 
2. Levantamento – esta tarefa transparece ser a mais simples; no entanto, é um equívoco. Inicialmente, 
parece que basta perguntar ao cliente o que ele deseja que o seu software tenha e faça, qual será a 
sua utilização, quantos usuários finais o sistema terá, entre outras informações. Porém, existem alguns 
problemas como: (i) problemas de escopo (os clientes/usuários especificam de forma precária ou com 
detalhes desnecessários as necessidades do sistema, o que pode levar à confusão dos objetivos globais 
do software que será desenvolvido); (ii) problemas de entendimento (os clientes/usuários têm dificuldade 
em transmitir suas necessidades, omitem informações que, para eles, parecem ser desnecessárias 
ou então especificam requisitos ambíguos; tal fato ocorre porque os clientes/usuários não estão 
32
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
completamente certos do que será preciso no software que desejam); (iii) problemas de volatilidade (os 
requisitos mudam à medida que o projeto do software avança; para amenizar esse problema, devemos 
realizar o levantamento de requisitos de forma organizada). 
3. Elaboração – consiste em descrever o problema com base nas informações obtidas nas duas tarefas 
anteriores; dessa forma, será estabelecida uma base concreta para o projeto. A elaboração é orientada 
pela criação e refinamento de cenários de usuários que descrevem como o usuário final interagirá 
com o sistema. Após a análise desses cenários, será possível extrair classes, seus atributos e métodos. 
As relações e a colaboração entre as classes serão identificadas; além disso, outros diagramas da UML 
(unified modeling language) poderão ser produzidos.
4. Negociação – esta tarefa é a responsável por mediar possíveis conflitos. Por exemplo, clientes e 
usuários podem solicitar mais recursos do que o permitido – considerando a limitação dos recursos de 
negócio – ou, então, clientes e usuários podem propor necessidades conflitantes, argumentando que 
sua necessidade é mais importante do que a do outro. Por exemplo, clientes e usuários podem solicitar 
mais recursos do que é possível atingir devido à limitação dos recursos de negócio ou, então, propor 
necessidades conflitantes, argumentando que sua necessidade é maior do que a do outro. Todos esses 
conflitos devem ser conciliados por meio da negociação. Para que a negociação aconteça, é solicitado 
aos clientes e usuários que decidam qual será a prioridade dos requisitos a serem implementados. Após a 
reunião dos clientes e usuários, alguns requisitos podem ser eliminados, combinados ou modificados, de 
forma que todos os envolvidos no projeto fiquem satisfeitos.
5. Especificação – esta tarefa pode ser um documento por escrito, um conjunto de modelos gráficos, 
um modelo matemático formal, um conjunto de cenários (diagramas) de casos de uso, um protótipo 
ou qualquer combinação dos fatores anteriores. Para sistemas pequenos, bastam diagramas de casos 
de uso; no entanto, para sistemas grandes, se faz necessário um documento por escrito, que contenha 
descrições claras para o cliente e modelos gráficos. O importante é que a especificação seja clara e 
relate a necessidade que o cliente solicitou nas tarefas anteriores. A Figura 1 ilustra o sumário (títulos e 
subtítulos esperados) de um pequeno modelo de especificação de requisitos de software. Trata-se de um 
documento com uma descrição mais detalhada de todas as características do software que se pretende 
desenvolver. A especificação de requisitos deve ser feita antes do início do projeto do software. 
Quadro 1 – Modelo de especificação de requisitos de software
Sumário
Histórico de Revisão
1. Introdução
1.1. Propósito
1.2. Convenções do documento
1.3. Público-alvo e sugestão de leitura
1.4. Escopo do projeto
1.5. Referências
33
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
2. Descrição geral
2.1. Perspectiva do produto
2.2. Características do produto
2.3. Classes de usuários e características
2.4. Ambiente operacional
2.5. Restrições de projeto e implementação
2.6. Documentação para usuários
2.7. Hipótesese dependências
3. Características do sistema
3.1. Características do sistema 1
3.2. Características do sistema 2
3.3. Características do sistema n
4. Requisitos de interfaces externas
4.1. Interfaces do usuário
4.2. Interfaces de hardware
4.3. Interfaces de software
4.4. Interfaces de comunicação
5. Outros requisitos não funcionais
5.1. Necessidades de desempenho
5.2. Necessidades de proteção
5.3. Necessidades de segurança
5.4. Atributos de qualidade de software
6. Outros requisitos
Apêndice A: Glossário
Apêndice B: Modelos de análise
Apêndice C: Lista de problemas
Fonte: Adaptado de PRESSMAN; MAXIM, 2016.
34
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
6. Validação – é nesta tarefa que se avalia a qualidade dos artefatos (documentos, diagrama UML). Essa 
avaliação é feita através da verificação da especificação de requisitos; assim, é possível garantir que 
todos os requisitos tenham sido declarados sem ambiguidade, sem inconsistências, sem omissões e 
sem erros. A tarefa de validação também permite verificar se os artefatos seguem o padrão estabelecido 
para o processo e projeto do software. A principal forma de validação é por meio da revisão técnica, cuja 
equipe responsável é formada, geralmente, pelos desenvolvedores, clientes e usuários. Essa equipe tem 
a tarefa de examinar a especificação de requisitos procurando por erros no conteúdo do documento, por 
informações faltantes, inconsistências de requisitos, requisitos heterogêneos ou mesmo requisitos falsos. 
7. Gestão de requisitos – a gestão de requisitos é relevante, pois a necessidade de alterações nos requisitos 
de software persiste ao longo da vida de um sistema. Essa tarefa consiste em um conjunto de atividades 
para ajudar a equipe da revisão técnica a reconhecer, inspecionar e conduzir as alterações que decorrem 
enquanto o projeto continua. 
3.2 Requisitos de software
Requisitos de software consistem no detalhamento dos serviços e restrições do software que será desenvolvido. 
Todos os requisitos que os clientes/usuários desejam e/ou precisam devem ser reproduzidos em um documento 
denominado documento de especificação do sistema. 
O processo – que envolve as tarefas de levantamento (descobrir), análise, documentação e verificação de 
requisitos – é denominado engenharia de requisitos, conforme explicado na seção anterior.
A tarefa de levantamento de requisitos pode produzir diferentes níveis de descrição do sistema. Essas descrições 
podem se aproximar mais dos usuários ou dos desenvolvedores. Sommerville (2011) apresenta dois níveis de 
abstração: 
• Requisitos de usuário – são utilizados para expressar os requisitos abstratos de alto nível. Referem-se às 
declarações de quais serviços o sistema fornecerá a seus usuários e as restrições com as quais este deve 
operar. Utiliza-se de uma linguagem natural com diagramas.
• Requisitos de sistema – são utilizados para expressar a descrição detalhada do que o sistema deve 
fazer. Referem-se às descrições mais detalhadas das funções, dos serviços e restrições operacionais 
do sistema de software. O documento de requisitos do sistema deve definir exatamente o que deverá 
ser implementado. Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores do 
software.
O Quadro 2 apresenta a distinção entre os requisitos de usuários e de sistemas. Apresenta também como um 
requisito de usuário pode ser expandido em vários requisitos de sistemas. Para ilustrar esses tipos de requisito, 
utilizaremos um exemplo de um sistema de vendas.
Quadro 2 – Requisitos de usuário e de sistemas
Definição de Requisitos de Usuários
1- O sistema deve gerar relatórios mensais que mostrem a quantidade de produtos vendidos no mês 
vigente.
35
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Especificação de Requisitos de Sistemas
1.1- No último dia útil de cada mês deve ser gerado um resumo dos produtos mais vendidos.
1.2- O acesso aos relatórios deve ser restrito a usuários autorizados.
Fonte: Elaborado pela autora.
Os requisitos precisam ser escritos em termos de detalhamento de acordo com o tipo de leitores 
existentes. Os requisitos de usuários possuem os seguintes leitores: gerentes clientes, usuários 
finais do sistema, engenheiros clientes, engenheiros contratantes e arquitetos de sistema. 
Esses leitores geralmente não se preocupam com a forma como o sistema será implementado. 
Já os leitores dos requisitos de sistemas são: usuários finais do sistema, engenheiros clientes, 
arquitetos de sistemas e desenvolvedores de software. Esses leitores precisam saber as 
informações com mais detalhes, pois eles estão envolvidos na implementação do sistema.
Fique atento!
Além dos tipos de requisitos (de usuário e de sistema), os requisitos de software são classificados como requisitos 
funcionais e requisitos não funcionais, conforme veremos na seção abaixo.
3.3 Requisitos funcionais
Os requisitos funcionais descrevem o que um sistema deve fazer e como deve se comportar em determinadas 
situações, ou seja, capturam as funcionalidades sob o ponto de vista do cliente. No entanto, os requisitos funcionais 
dependem do tipo de software que será desenvolvido, de quem são seus possíveis usuários e da metodologia 
de escrita dos requisitos adotada pela empresa. Por exemplo, em um sistema de comércio eletrônico alguns 
requisitos funcionais seriam: (i) permitir a consulta de produtos por preço; (ii) permitir a consulta dos produtos por 
nome; (iii) permitir a consulta dos produtos mais vendidos; (iv) permitir pagamento online via cartão de crédito ou 
boleto bancário; e (v) cadastramento de clientes. 
A imprecisão na especificação dos requisitos causa muitos problemas na engenharia de software. Por isso, a 
especificação dos requisitos funcionais de um sistema deve ser completa (todos os serviços requeridos pelo 
usuário devem ser definidos) e consistente (os requisitos não devem ter definições contraditórias).
36
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
3.4 Requisitos não funcionais
Os requisitos não funcionais referem-se às restrições a serviços ou funções oferecidos pelo sistema, ou seja, 
trata-se dos requisitos que não estão diretamente relacionados com os serviços oferecidos pelo sistema a seus 
usuários. Em um sistema de comércio eletrônico, por exemplo, normalmente os clientes não têm paciência para 
aguardar o carregamento de uma página demorada e desistem da compra. Assim, esse tipo de sistema deverá 
ter como requisito não funcional o carregamento rápido de páginas, com o limite de tempo de, no máximo, 2 
segundos, por exemplo.
Ao desenvolver um novo software, os desenvolvedores e engenheiros de software indicam um conjunto de 
requisitos não funcionais que o software deverá possuir, como:
• Confiabilidade – refere-se à capacidade do software de preservar o seu nível de desempenho quando 
usado em condições predeterminadas. Exemplo: o software deve evitar falhas resultantes de defeitos. 
• Desempenho – refere-se ao tempo de execução e aos recursos disponíveis no computador. Exemplo: o 
sistema não deve consumir muitos recursos (como memória) do computador, nem demorar muito para 
executar os processos.
• Segurança – refere-se à capacidade do software de proteger informações e dados de forma que usuários 
não autorizados não tenham acesso, nem mesmo para leitura. Exemplo: o sistema deve garantir a 
segurança dos dados por meio do uso de senhas criptografadas.
Os requisitos não funcionais surgiram da necessidade dos usuários e também das restrições de orçamento, das 
políticas das organizações, das necessidades de interoperabilidade com outros sistemas de software ou hardware 
e de fatores externos, como regulamentos de segurança ou leis sobre privacidade. A Figura 10 apresenta a 
classificação dos requisitos não funcionais, que estão divididos em: 
• Requisitos de produto – são utilizados paraespecificar ou restringir o comportamento do software, 
como, por exemplo, os requisitos de confiabilidade que estabelecem a taxa aceitável de falhas. 
• Requisitos organizacionais – são os requisitos gerais de sistemas derivados a partir da política interna da 
empresa do cliente e do desenvolvedor. Exemplo: os requisitos operacionais que definem como o sistema 
será usado. 
• Requisitos externos – abrangem todos os requisitos que derivam de fatores externos ao sistema e seu 
processo de desenvolvimento, como, por exemplo, os requisitos legais que devem ser seguidos para 
garantir que o sistema opere dentro da lei.
37
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 10 – Tipos de requisitos não funcionais
Requisitos não
funcionais
Requisitos do
produto
Requisitos de
eficiência
Requisitos de
facilidade de uso
Requisitos de
desempenho
Requisitos de
espaço
Requisitos de
privacidade
Requisitos de
segurança
Requisitos de
entrega
Requisitos de
implementação
Requisitos de
padrões
Requisitos legais
Requisitos de
confiabilidade
Requisitos de
portabilidade
Requisitos de
interoperabilidade
Requisitos éticos
Requisitos 
organizacionais
Requisitos 
externos
Fonte: SOMMERVILLE, 2011.
3.5 Levantamento de requisitos
O levantamento de requisitos, também conhecido como elicitação de requisitos, é uma atividade que combina 
elementos de resolução de problemas, elaboração, negociação e especificação de requisitos. Nesta atividade, 
os engenheiros de software trabalham com clientes e usuários finais do software que será produzido para obter 
informações sobre os serviços que o sistema deve oferecer, o contexto da aplicação, o desempenho do sistema, 
as restrições de hardware, entre outros. 
A Figura 11 apresenta um modelo do processo de levantamento de requisitos. É importante ressaltar que cada 
empresa deve ter sua própria versão, pois essa atividade sofre influência de fatores locais, como conhecimento 
dos usuários finais, do tipo e tamanho do sistema a ser produzido, da política interna da empresa, entre outros.
38
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 11 – Processo de levantamento e análise de requisitos
1. Descoberta
de requisitos
2. Classificação e
organização de
requisitos
3. Priorização e
negociação de
requisitos
4. Especificação
de requisitos
Fonte: SOMMERVILLE, 2011.
As atividades do processo de levantamento e análise de requisitos são:
1. Descoberta de requisitos – nesta atividade, ocorre um diálogo com os clientes e usuários finais a fim de 
se descobrir os requisitos do software a ser desenvolvido. 
2. Classificação e organização de requisitos – após a realização da atividade de descoberta dos requisitos, 
são feitas a classificação e a organização destes. Assim, os requisitos comuns são agrupados no mesmo 
grupo, e os requisitos redundantes são descartados. Essa atividade permite a eliminação de requisitos 
desnecessários e garante que todos os requisitos comuns tenham sido agrupados corretamente para 
facilitar a criação das funcionalidades do software.
3. Priorização e negociação de requisitos – essa atividade está relacionada à priorização, ou seja, dentre 
os requisitos listados pelos clientes e usuários finais, quais deverão ser desenvolvidos primeiro. Para 
decidir a priorização dos requisitos é realizada uma reunião entre os clientes e usuários finais para que 
eles decidam qual a prioridade ou qual a precedência das funcionalidades na hora da implementação do 
software.
4. Especificação de requisitos – consiste em escrever os requisitos de usuários e de sistema em documento 
de requisitos. Documentos formais podem ser produzidos conforme modelo apresentado anteriormente. 
No estágio inicial, uma versão do documento de requisitos com seções faltantes e requisitos incompletos 
pode ser produzida. Uma alternativa a esse modelo fechado é documentar em cartões os requisitos, pois 
é mais fácil para os clientes e usuários finais se organizarem e modificarem os requisitos.
39
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
O processo de elicitar e compreender requisitos é árduo, pois frequentemente os clientes e usuários finais 
(também chamados de partes interessadas) possuem opiniões distintas sobre a importância e prioridade dos 
requisitos, e geralmente as opiniões são conflitantes. Diante desse problema, a engenharia de software propôs as 
seguintes técnicas de elicitação de requisitos: 
• Descoberta de requisitos sob ponto de vista.
• Entrevistas.
• Casos de uso.
• Etnografia.
Assista ao vídeo <http://www.no-ads-youtube.com/video/b-son-treinamentos/o-que-
levantamento-de-requisitos-t-picos-de-engenharia-de-software?v=VcOeM2AD8Yk> para 
saber sobre os requisitos de software.
Saiba mais
3.6 Descoberta de requisitos sob ponto de vista
A descoberta de requisitos consiste no processo de reunir informações como documentação, clientes e usuários 
finais, e especificações similares sobre o sistema a ser produzido. Dessas informações serão separados os 
requisitos de usuários e de sistemas. 
As partes interessadas de um software variam muito, seja pelo tamanho da empresa, quantidade de usuários 
(partes interessadas), tipos de sistemas que interagem ou simplesmente pelo tamanho do sistema a ser 
desenvolvido. Durante o processo de levantamento de requisitos, todas essas fontes de requisitos devem 
ser consideradas. Porém, como existem muitas fontes, consequentemente têm-se muitos pontos de vistas 
distintos sobre o mesmo problema. Em suma, pessoas distintas “enxergam” o mesmo requisito sob um ponto 
de vista diferente umas das outras, mas, apesar de os requisitos serem expressados de formas distintas, não são 
completamente independentes; basta os engenheiros de software realizarem uma “filtragem” dos requisitos 
duplicados e inconsistentes.
Portanto, a técnica de descoberta de requisitos sob pontos de vistas é utilizada para estruturar a elicitação e a 
documentação dos requisitos do software. A Figura 12 apresenta os requisitos sob o ponto de vista de um titular 
e de um não titular de uma conta em alguma agência bancária.
http://www.no-ads-youtube.com/video/b-son-treinamentos/o-que-levantamento-de-requisitos-t-picos-de-engenharia-de-software?v=VcOeM2AD8Yk
http://www.no-ads-youtube.com/video/b-son-treinamentos/o-que-levantamento-de-requisitos-t-picos-de-engenharia-de-software?v=VcOeM2AD8Yk
40
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 12 – Exemplo de descoberta de requisitos sob pontos de vista
Titular da conta
 Lista de Serviços
Sacar dinheiro
Depositar dinheiro
Consultar saldo
Solicitar extratos
Transferir dinheiro
Não Titular da conta
 Lista de Serviços
Depositar dinheiro
Fonte: Elaborada pela autora.
3.7 Entrevistas
Outra técnica para descobrir os requisitos de software são entrevistas formais ou informais. As entrevistas podem 
ser de dois tipos: 
• Entrevistas fechadas – consistem nas partes interessadas responderem a um questionário com 
perguntas predefinidas.
• Entrevistas abertas – não têm um conjunto de perguntas predefinidas. A equipe dos engenheiros de 
software se adapta para explorar o conhecimento das partes interessadas. Assim, desenvolve uma melhor 
compreensão das necessidades desses usuários/clientes.
A técnica de entrevista é considerada uma boa forma de compreensão dos requisitos de modo global, mas não 
para os requisitos do domínio da aplicação, pois o conhecimento desse tipo de requisito é tão familiar às partes 
interessadas que elas têm dificuldades em expô-los ou simplesmente não mencionam por não julgar necessário 
aos engenheiros de software.
A técnica de entrevistas pode não capturar informações essenciais do sistema, não devendo 
ser utilizada sozinha, mas, sim, em conjunto com outras técnicas de elicitação de requisitos. 
Fique atento!
Assista ao vídeo Gerenciamento de Requisitos sem Mistério,no YouTube, para saber sobre 
como gerenciar os requisitos de software e saber mais sobre as técnicas de levantar requisitos.
Saiba mais
41
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
3.8 Casos de uso
Os diagramas de casos de uso também são uma técnica de elicitação de requisitos. Sua forma simples permite 
ilustrar às partes interessadas a interação com o sistema por meio de atores (usuário que interagirá com 
determinada tela do sistema) e casos de uso (telas dos sistemas).
A Figura 13 representa um conjunto de casos de usos de todas as possíveis interações que o usuário final terá de 
acordo com os requisitos descobertos. Os atores (o bonequinho palito) representam todas as possíveis interações 
que os usuários finais ou outros sistemas terão com o software a ser desenvolvido. Já as linhas representam a 
ligação dos atores com os seus respectivos casos de uso.
Figura 13 – Exemplo de um caso de uso para parte do sistema de uma biblioteca
Atendente
Emprestar 
Livro
Devolver 
Livro
Incluir Livro
Comprar Livro
Bibliotecária
Fonte: Elaborada pela autora.
Casos de uso são considerados boas técnicas para descobertas de requisitos por mostrar a interação das partes 
interessadas (usuários, por exemplo) com o sistema. No entanto, devido ao fato de o foco do diagrama de caso de 
uso estar nas interações com o sistema (ou seja, com quais funcionalidades os usuários interagirão), o diagrama 
caso de uso não é eficaz para descobrir:
42
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
• As restrições do sistema, que se referem às limitações internas ou externas ao projeto do software. 
Por exemplo, toda a equipe do projeto deverá ser contratada via CLT; portanto, não poderá haver contrato 
terceirizado.
• Os requisitos de negócio ou regras de negócio, que se referem às políticas de negócio, ou seja, 
declarações em relação à forma da empresa realizar as suas atividades. As regras de negócio servem para 
atender os objetivos do negócio (em relação ao sistema) e do cliente e, também, para cumprir às leis/
regras do negócio. Por exemplo: o professor somente poderá lecionar disciplinas relacionadas à sua linha 
de pesquisa do mestrado ou, então, o cliente do Banco do Brasil só poderá realizar um saque na sua conta 
de apenas mil reais por dia. 
• Os requisitos não funcionais (já explicados e exemplificados anteriormente).
Conforme apresentado, o diagrama de caso de uso tem algumas limitações que impedem a captura de todos 
os tipos de requisitos do projeto do sistema. Devido a esse fato, o diagrama de caso de uso deve ser utilizado 
em conjunto com outros diagramas; por exemplo, o diagrama de atividades e os diagramas de sequência e de 
colaboração. O diagrama de atividades descreve o fluxo de atividades de um caso de uso. Já os diagramas de 
sequência e de colaboração descrevem as interações entre o ator e o comportamento dos objetos de um caso 
de uso do sistema.
Visite o site da OMG (Object Management Group) <https://www.omg.org/technology/
readingroom/UML.htm> para saber mais informações sobre os diagramas de casos de uso 
pertencentes à modelagem UML (unified modeling language).
Para saber mais sobre os diagramas de atividades, sequência e de colaboração, acesse o site: 
<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/diagramas.htm>.
Saiba mais
3.9 Etnografia
A etnografia consiste em uma técnica de observação utilizada para descobrir os requisitos sociais e organizacionais. 
Para tal, o engenheiro de software (ou analista) se insere no ambiente de trabalho da empresa para qual será 
desenvolvido o software e observa o dia a dia de trabalho, ou seja, a rotina da empresa. São observadas e anotadas 
todas as tarefas realizadas pelas partes interessadas. 
A vantagem dessa técnica em relação às outras é que ela ajuda na descoberta dos requisitos implícitos, pois, com 
ela, é possível capturar informações sobre situações reais em vez de processos formais definidos pela empresa.
A desvantagem da etnografia é que o seu foco está voltado para o usuário final, o que muitas vezes não permite 
a descoberta dos requisitos organizacionais ou de domínio. Consequentemente, esses usuários não sabem 
identificar e informar novos recursos que devam ser adicionados ao sistema.
43
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Síntese da unidade
Os requisitos de software são muito importantes, pois definem as restrições do sistema e o que ele deve fazer. 
Os requisitos funcionais têm o papel de descrever o que o usuário deseja que o sistema tenha. Já os requisitos 
não funcionais descrevem não o que o sistema fará, mas como ele fará, como, por exemplo, desempenho, 
portabilidade e segurança. É muito importante documentar todos os requisitos extraídos das partes interessadas. 
Para se obter os requisitos dos clientes/usuários finais, existem várias técnicas, e o engenheiro de software deve 
escolher quais são as recomendadas para o tipo e tamanho de software que será desenvolvido.
44
Considerações finais
Esperamos que você tenha assimilado da melhor forma possível o 
conteúdo aqui apresentado. Para ampliar o seu conhecimento, consulte 
o aprofundamento de conteúdo e assista à videoaula da unidade, pois 
ambos contêm informações relevantes para seu aprendizado.
	Unidade 1
	1. Introdução à Engenharia de Software
	Unidade 2
	2. Modelos do Ciclo de Vida do Software
	Unidade 3
	3. Engenharia de Requisitos e Modelagem de Software 
	Unidade 4
	4. Projeto de Interface Homem-Máquina