Modelagem de Software

Requisitos de Software
Prof. MSc. Jonathan Bandeira - jonathan.bandeira@ulife.com.br
 Resolução – Exercício Aula 1 (Questão 2)

2. Admita que você foi contratado(a) para desenvolver um software para hospital
com o objetivo de gerenciar as marcações de consultas e histórico de pacientes
do empreendimento. Enumere quais atividades seriam realizadas em cada
etapa do desenvolvimento e o que seria produzido em cada uma delas (quais
artefatos), considerando o modelo escolhido na questão anterior.

• Vamos supor que o modelo escolhido foi o cascata.

• As fases/etapas do modelo cascata são: Comunicação, Planejamento,
Modelagem, Construção e Implantação.
• As atividades a desenvolver são: Estudo de viabilidade, levantamento de
requisitos, Análise de requisitos, Projeto, Implementação, Testes e
Manutenção/Evolução.
2
 Resolução – Exercício Aula 1 (Questão 2)

• No modelo em cascata, o estudo de viabilidade será feito na etapa de comunicação do

modelo. Essa etapa tem o objetivo de avaliar se o projeto é viável de ser construído ou não
e vai produzir um relatório de viabilidade.
• Já na etapa de Planejamento, serão executadas as atividades de levantamento de
requisitos e análise de requisitos. Aqui vão ser estudadas as necessidades do hospital, de
quem frequenta esse hospital, dos médicos e outros funcionários que trabalham no local
para elaborar um documento de requisitos com as funcionalidades e restrições do
produto que se deseja fazer. Também são tomadas algumas decisões sobre que
ferramentas, linguagens de programação e outros recursos serão usados para fazer o
produto.
• Na etapa de Modelagem, será executada a atividade de Projeto. Nesta etapa, serão
elaborados os diagramas que vão especificar a estrutura do produto, a arquitetura do
software, o fluxo das atividades, os componentes da aplicação, etc.

3
 Resolução – Exercício Aula 1 (Questão 2)

• Na etapa de Construção, serão executadas as atividades de

implementação e testes. A implementação vai cuidar da
elaboração do código na linguagem de programação escolhida,
preparação de um banco de dados para aplicação e validação do
que foi produzido, checando se está de acordo com o projeto e o
documento de requisitos. Aqui também entram os testes, que vão
verificar se conseguem se encontrar erros na solução
implementada e todas as funcionalidades do produto são
executadas da forma esperada. São feitos aqui o código-fonte da
aplicação, os casos de testes, cenários de testes e relatório de
testes.
4
 Resolução – Exercício Aula 1 (Questão 2)

• A última etapa do modelo cascata é a de implantação. A

atividade executada aqui é de Manutenção/Evolução. Nela,
são feitas as novas funcionalidades e correções de bugs do
produto e essas modificações são incorporadas a novas
versões do produto, que vão sendo lançadas durante o
período de vida do software. São feitos aqui manuais de
utilização e instalação do produto, canais de suporte, notas
de versão (patch notes) e um histórico de controle de
versões do software.
5
 Roteiro

• Requisitos de Software
• Definição
• Engenharia de Requisitos
• Principais Atividades da Engenharia de Requisitos
• Tipos de Requisitos: Funcionais e Não-Funcionais
• Regras de Negócio
• Documento de Requisitos
• Problemas da Etapa de Requisitos
• Exercícios
• Bibliografia

6
 Por onde Começar o Desenvolvimento do
Software?
• Planejamento, análise e
validação de requisitos.

7
 O que é Requisito ?
• “Condição que se deve satisfazer para alcançar um objetivo”.

8
 O que é Requisito ?
• “Exigência que deve ser cumprida para atingir um objetivo”.

9
 O que é Engenharia de Requisitos (ER) ?
• É a ciência que estuda como realizar a criação, construção, análise, desenvolvimento e
manutenção dos requisitos que devem ser cumpridos por um sistema.
• Estabelece os serviços que o cliente requer de um sistema e as restrições sob as quais
tal sistema operará e será desenvolvido.
• Tais serviços e restrições são chamados de requisitos.

10
 Engenharia de Requisitos (ER)
• Objetivos:
• Conhecer os requisitos pertinentes, alcançar um consenso entre os stakeholders sobre esses
requisitos, documentando-os de acordo com as normas dadas e gerenciando-as sistematicamente.
• Compreender e documentar os desejos e necessidades dos stakeholders, que especifica o
gerenciamento de requisitos para minimizar o risco de entregar um sistema que não atende os
desejos das partes interessadas.

11
 O que é Stakeholder ?

• É uma pessoa ou uma organização que tem algum impacto direto ou

indireto sobre os requisitos do sistema.

12
As Quatro Principais Atividades da ER

13
 As Quatro Principais Atividades da ER
(Elicitação)
• Para a etapa de identificação, levantamento e
detalhamento de requisitos, podem ser
utilizadas diversas técnicas, como:
• Entrevista
• Estudo do Negócio da Organização
• Brainstorming
• Outros...

• Um Engenheiro de Requisitos precisa extrair,

sugar todas as informações possíveis dos
stakeholders e identificar requisitos através
de pesquisas.
14
 As Quatro Principais Atividades da ER
(Documentação)
• Para documentar requisitos podem ser
utilizadas algumas técnicas:
• Linguagem Natural
• Modelos Formais
• UML (Diagramas)

• É importante registrar as informações

coletadas e identificadas na etapa de
levantamento de requisitos de forma
adequada.

15
 As Quatro Principais Atividades da ER
(Validação e Negociação)
• Para negociar e validar requisitos, é
importante ter a avaliação de um especialista,
de modo que possa ser verificado se o que foi
levantado condiz com o que foi solicitado.
• Deve ser garantida a qualidade dos requisitos,
validando se estão corretos, Para isso é
importante negociar com o cliente o que
realmente é necessário para o produto.

16
 As Quatro Principais Atividades da ER
(Gerenciamento)
• Gerenciar consiste em manter os dados
consistentes com qualidade, garantindo que
eles possam ser implementados.
• Compreende todas as medidas que são
necessárias as exigências de estrutura para
que as outras três etapas da ER possa ocorrer.

17
 Benefícios da Engenharia de Requisitos
• Entendimento comum entre desenvolvedores, clientes e
usuários sobre o trabalho a ser feito.
• Uma fonte confiável para estimativa de custos, pessoal,
prazos e etc.
• Melhoria na qualidade do software a ser desenvolvido.
• Objetivo traçado gerando assim uma menor manutenção
e customização do software futuramente.

18
Características de uma boa Especificação de
Requisitos
• Clara e não ambígua
• Completa
• Correta
• Consistente
• Concisa
• Confiável

19
Requisitos de Software

20
 Requisitos Funcionais e Não-Funcionais
• Requisitos Funcionais:
• Descrevem os serviços que se espera que o sistema deve fornecer.
• Especificam as funcionalidades do sistema.
• Como o sistema deve reagir a entradas específicas.
• Como o sistema deve se comportar em determinadas situações.

• Requisitos não-funcionais ou de qualidade:

• Descrevem aspectos de qualidade que o software deverá apresentar, ou as restrições a serem
atendidas.
• Os requisitos não-funcionais referem-se às condições nas quais deve funcionar o sistema.
• Podem estar relacionados a propriedades do sistema, tais como: confiabilidade, usabilidade,
segurança, desempenho, etc.
• Restrições sobre serviços ou funções oferecidos pelo sistema, tais como restrições de tempo
de resposta, restrições sobre o processo de desenvolvimento, padrões, etc...

21
 Requisitos - Como Especificar ?
• Casos de Uso:
• Linguagem Natural:
• Um modelo de casos de uso é utilizado
• Os requisitos funcionais podem para representar as funcionalidades do
ser descritos em linguagem sistema de forma detalhada.
natural em nível macro. • Um modelo de casos de uso identifica
quem ou o que interage com o sistema e
o que o sistema deve fazer.
• Casos de uso são técnicas baseadas em
cenários onde são identificados atores e
sua interação com o sistema.

22
Requisitos Funcionais

23
Requisitos Não-Funcionais

24
 Requisitos Não-Funcionais
• Requisitos do Produto
• São os requisitos que especificam o comportamento do produto.
• Exemplo: requisitos de desempenho, que especificam com que rapidez o sistema
deve operar.
• Requisitos Organizacionais
• São procedentes de políticas e procedimentos nas organizações do cliente e do
desenvolvedor.
• Entre os exemplos estão os padrões de processos que devem ser utilizados; os
requisitos de implementação, como a linguagem de programação; ou a metodologia
de processo de desenvolvimento.
• Requisitos Externos
• Abrange todos os requisitos procedentes de fatores externos ao sistema e ao seu
processo de desenvolvimento.
• Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos, etc.

25
 Exemplos - Requisitos Funcionais
• SISTEMA DE GERENCIAMENTO DE PROJETOS:

26
 Exemplos - Requisitos Não-Funcionais
• SISTEMA DE GERENCIAMENTO DE PROJETOS:

27
28
 Regras de Negócio
• Regras de Negócio:
• São premissas e/ou restrições aplicadas a uma operação comercial de uma
empresa.
• Por exemplo, de forma que atenda ao negócio e funcione da maneira
esperada, ou seja, conforme as regras estabelecidas.

29
 Exemplos
• Requisito Funcional RF01: Efetuar login;
• Regra de Negócio RN01: Ao clicar no campo de senha, animar coruja;
• Requisito Não-Funcional RNF01: Requisitos de portabilidade: o sistema deverá rodar em
qualquer plataforma.

30
 Documento de Requisitos de Sistema
• O documento de requisitos de sistema - DRS - pode ser entendido
como a descrição formal e oficial onde é descrita e comunicada os
requisitos a todos os envolvidos no processo de desenvolvimento de
software (stakeholders). Ele é basicamente composto de:

• os serviços e funções que o sistema deve prover;

• as limitações sobre as quais o sistema deve operar;
• definições de outros sistemas com os quais o sistema deve integrar;
• limitações no processo usado para desenvolver o sistema;
• descrições sobre o hardware no qual o sistema irá executar.

31
Principais Problemas na Etapa de Requisitos
Erros mais comuns cometidos no desenvolvimento:
• Ignorar um cliente ou grupo de clientes
• Omitir um grupo de requisitos
• Permitir inconsistências entre grupos de requisitos
• Aceitar requisito inadequado
• Aceitar requisito incorreto, indefinido, ou impreciso
• Aceitar um requisito ambíguo e inconsistente

32
 Exercício 01
Considere o seguinte sistema descrito:
“Um sistema automático de emissão de passagens vende passagens de trem. A partir de
uma lista de possíveis destinos, os usuários escolhem seu destino e apresentam um cartão
de crédito e um número de identificação pessoal. Os destinos possíveis devem ser
organizados de modo a facilitar a escolha. Após a escolha do destino, o sistema deve
responder prontamente se há espaço disponível no trem. A passagem é emitida e o custo
dessa passagem é incluído em sua conta do cartão de crédito. Quando o usuário pressiona
o botão para iniciar, uma tela de menu com os possíveis destinos é ativada, juntamente
com uma mensagem para que o usuário selecione um destino. Uma vez selecionado um
destino, pede-se que os usuários insiram seu cartão de crédito. A validade do cartão é
checada e o usuário então deve fornecer um número de identificação pessoal. Quando a
transação de crédito é validada, a passagem é emitida. O formato do bilhete de passagem
deve seguir ao padrão definido pelo Sistema Nacional de Tráfego Ferroviário”.
• Para o sistema em questão:
• 1- Identifique os requisitos funcionais e não funcionais.
• 2- Aponte possíveis incertezas nessa descrição.

33
 Exercício 02
Considere o seguinte sistema:
a) Produto para gestão de escola

• O produto deve dar apoio à gestão de cursos oferecidos por uma escola. Cada curso é
composto por um conjunto de disciplinas. Disciplinas têm carga horária, pré-requisitos e
programas. Uma disciplina pode ser ofertada várias vezes por ano, podendo haver turmas
simultâneas da mesma disciplina. Cada instrutor tem um conjunto de disciplinas que pode
oferecer, devendo a alocação de encargos didáticos obedecer a um máximo de horas por
semana. A matrícula dos alunos também deve obedecer a uma carga horária máxima.

• Liste os possíveis stakeholders deste projeto;

• Liste as possíveis principais funcionalidades (requisitos funcionais) e aspectos de
qualidade (requisitos não funcionais) a nível de usuário que o sistema poderia
apresentar de acordo com a descrição. 34
 Exercício 02
Considere o seguinte sistema:
b) Produto para gestão de biblioteca
• O produto deve dar apoio à gestão de uma biblioteca escolar. Os títulos da biblioteca
podem ser livros, periódicos e outros. Cada título tem um número de exemplares, um
período máximo de empréstimo e uma descrição. Um título só pode ser emprestado a
leitores cadastrados, que pagarão multas se ultrapassarem o período de empréstimo.
Professores cadastrados podem pedir reservas de determinados títulos, para que sejam
consultados apenas na biblioteca durante a oferta de determinada disciplina. O produto
deve permitir o tratamento de perdas e dar apoio ao controle de assinaturas de periódicos.

• Liste os possíveis stakeholders deste projeto;

• Liste as possíveis principais funcionalidades (requisitos funcionais) e aspectos de qualidade
(requisitos não funcionais) a nível de usuário que o sistema poderia apresentar de acordo com a
descrição.

35
 Exercício 02
Considere o seguintes sistema:
c) Produto para gestão de clínica médica

• O produto deve dar suporte à gestão de clínica onde trabalha uma equipe de médicos. Será
usado pelos recepcionistas para marcação de consultas e também pelos médicos, para
registro do histórico dos pacientes. Deve ser controlada a recepção de resultados de
exames que sejam enviados diretamente dos laboratórios para os médicos; por opção do
médico, estes resultados podem ser entregues aos pacientes, ou guardados na clínica para
consulta posterior.

• Liste os possíveis stakeholders deste projeto;

• Liste as possíveis principais funcionalidades (requisitos funcionais) e aspectos de
qualidade (requisitos não funcionais) a nível de usuário que o sistema poderia apresentar
de acordo com a descrição.
36
 Bibliografia
PRINCIPAL
• MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0. São Paulo: Pearson Education, 2004.
• https://bv4.digitalpages.com.br/?term=uml&searchpage=1&filtro=todos&from=busca&page=-
20&section=0#/legacy/2921
• RAMAKRISHNAN, Raghu; GEHRKE, Johannes.Sistemas de Gerenciamento de Bancos de Dados. 3.
edição. Porto Alegre: Bookman, 2007.
• https://integrada.minhabiblioteca.com.br/#/books/9788563308771/cfi/0!/4/2@100:0.00
• PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Uma abordagem profissional. 8a. Ed.
Bookman, 2016.
• https://integrada.minhabiblioteca.com.br/#/books/9788580555349/cfi/3!/4/2@100:0.00

37
 Bibliografia
COMPLEMENTAR
• SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
• https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&fil
tro=todos&from=busca&page=_14&section=0#/legacy/276
• PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall,
2004.
• https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&fil
tro=todos&from=busca#/legacy/476
• LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a
objetos e desenvolvimento iterativo. 3. ed Porto Alegre: Bookman, 2007.
• https://integrada.minhabiblioteca.com.br/#/books/9788577800476/cfi/0!/4/2@100:0.00
• FOWLER, Martin; SCOTT, Kendall. UML essencial: um breve guia para a linguagem-padrão de
modelagem de objetos. 3ª. ed. Porto Alegre: Bookman, 2004.
• https://integrada.minhabiblioteca.com.br/#/books/9788560031382/cfi/6/2!/4/2@0:0.131
• HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011.
• https://integrada.minhabiblioteca.com.br/#/books/9788577804528/cfi/0!/4/4@0.00:38.0
38
 Modelagem de Software
Requisitos de Software
Prof. MSc. Jonathan Bandeira - jonathan.bandeira@ulife.com.br