Requisitos de Software

REQUISITOS DE SOFTWARE
Stefani Valmini
REQUISITOS DE SOFTWARE 2
SUMÁRIO
Introdução 3 Associações 36
Princípios da Engenharia 4 Diagrama de Classe 38
Fundamentos 5 Abstração 40
Métodos da Engenharia de Software 8 Encapsulamento 40
O que é Requisito: 12 Associações 41
Stakeholder 13 Associações Unárias ou Reflexivas 41
CENTRO UNIVERSITÁRIO UNIFTEC
Artefato 13 Associações Binárias 42 Rua Gustavo Ramos Sehbe n.º 107.
Engenharia de Requisitos 15 Associações Ternárias ou N-árias Caxias do Sul/ RS
42
Etapas da Engenharia de Requisitos 16 Associação de Agregação 42 REITOR
Classificação de Requisitos 21 Associação de Composição 43
Claudino José Meneguzzi Júnior
PRÓ-REITORA ACADÊMICA
Requisito de Qualidade/ Não Funcionais 21 Associação de Generalização 43
Débora Frizzo
PRÓ-REITOR ADMINISTRATIVO
Análise e Negociação de Requisitos 22 Diagrama de Sequência 46 Altair Ruzzarin
DIRETORA DE EDUCAÇÃO A DISTÂNCIA (NEAD)
Qualidade de Software 26 Lígia Futterleib
Elementos do Diagrama de Sequência 48
Modelos de Qualidade 27 Diagrama de Máquinas de Estados 49 Desenvolvido pelo Núcleo de Educação a
CMMI 28 Auto Transições 51 Distância (NEAD)
Designer Instrucional
MPS.BR 29 Barra de União 51 Sabrina Maciel
Diagramação, Ilustração e Alteração de Imagem
UML 32
Diagrama de Atividades 52 Igor Zattera, Gabriel Olmiro de Castilhos
Revisora
Diagrama de Caso de Uso 34 Referências 55 Ana Clara Garcia
Introdução
A nossa disciplina de Requisitos de Software

proporcionará a experiência de criar a documentação
(do zero) de um software seguindo as boas práticas
da Linguagem de Modelagem Unificada, UML. Nela
estudaremos desde as técnicas para entender o que o
cliente deseja, como classificamos essas informações, até
os modelos de modelagem que podem ser usados para
documentar as diversas visões de um software.
Nosso conteúdo está dividido em quatro grandes
capítulos de estudo. O primeiro refere-se a “Princípios
da Engenharia”, o segundo “Engenharia de Requisitos”, o
terceiro a área da “Qualidade de Software” e, por último,
a “UML (Unified Modeling Language )”.
Ao final desta disciplina vocês serão capazes de identificar
as necessidades dos usuários de software, classificá-
los, documentá-los, propor melhorias e sugestões na
construção e arquitetura do software, dos processos e
modelar qualquer sistema usando a linguagem unificada
de modelagem (UML).
PRINCÍPIOS DA
ENGENHARIA
Entenda conceitos básicos da engenharia e
sua importância no processo de criação de
software
Você acha que o software já passou por alguma crise?
Você já se questionou se para “fazer” software precisa de
planejamento ou se é possível sair escrevendo os códigos e
depois tudo funcionar/integrar?
Por que leva tanto tempo para concluir um software?
Por que os custos de desenvolvimento são tão altos? Por

que os erros não são detectados antes das liberações? Por que
é tão difícil e custa tanto tempo manter os programas?
Como ponto de partida precisamos entender que fato-

res ocorreram na área de software, quais as lições aprendidas
com estes erros e/ou acertos que ajudaram a construir essas
metodologias para modelar softwares.
Fundamentos diferente da maneira que fazemos hoje. O computador principal e o backup

deram shutdown (desligaram) ao mesmo
Vamos ver alguns exemplos de fa- tempo. Isso ocorreu, porque o programa
O que é Software? São instruções
lhas e erros bem graves de projetos: que convertia um valor para inteiro, rece-
que quando executadas produzem a função
beu como entrada um valor fora da faixa
e o desempenho esperados; São estrutu-
• Foguete Ariane V permitida. E o mais interessante é que esta
ras de dados que permitem manipular as
conversão não era mais necessária após a
informações; ou ainda Documentos para
decolagem.
desenvolver, operar e manter os programas.
• Denver International Airport
Segundo Pressman “O software
ultrapassou o hardware como chave
para o sucesso de muitos sistemas
baseados em computador”.
Ou seja, o Software é a chave para

o sucesso, ele é estratégico. Hoje em dia
O projeto da Agência Espacial Eu- O projeto custou 4,9 bilhões de dó-
até o mercadinho da esquina precisa de
ropeia custou 10 anos e oito bilhões de lares. O aeroporto atendia 100 mil passa-
um software para enviar uma nota fiscal
dólares. A capacidade do foguete era de geiros por dia, com 1200 voos e 94 portões
eletrônica. Para cada situação, cada ne-
6 toneladas. O voo inaugural foi no dia 4 de entrada e saída.
cessidade tem um programa que auxilia
de junho de 1996.
as pessoas.
Houve erro no sistema automático
O resultado deste projeto foi: ex- de bagagens, atrasando a abertura. O que
Percebam que este crescimento
plosão após 40 segundos da decolagem, custou 360 milhões de dólares e mais 86
ocorreu muito rápido. A maneira que se
destruição do foguete e carga avaliada em milhões de dólares para consertar o sis-
produzia software nos primórdios é muito
500 milhões de dólares. tema.
• Caso Federal Aviation Adminis- Ao final do projeto a FAA acabou mostram que houve melhorias nos proje-
tratuin USA (FAA) pagando de 700 a 900 dólares por linha tos de software, porém continuam altos
de código, foram canceladas duas partes os percentuais. É possível concluir com
do projeto. Mesmo assim houve atraso na estes dados que o grande problema é a
entrega e o sistema estava cheio de bugs. falta de planejamento, gerenciamento de
projeto. Para minimizar devemos utilizar
Segundo pesquisas do “CHAOS” as práticas da engenharia.
em 1994, as empresas dos Estados Uni-
dos gastavam 81 milhões de dólares em “O estabelecimento e uso de sólidos
projetos de software que eram cancelados, princípios de engenharia para que
31% dos projetos eram cancelados antes se possa obter economicamente
de serem concluídos.
um software que seja confiável e
Mais da metade dos projetos exce- que funcione eficientemente em
diam mais do que 50% a sua estimativa máquinas reais” (BAUER, Fritz 1969)
de custo e somente 9% eram entregues no
tempo e dentro do orçamento, em grandes
Um projeto de um novo sistema de empresas.
tráfego aéreo chamado AAS. Era um pro-
grama arrojado, com milhões de linhas Em 2012, o mesmo relatório atuali-
de código distribuidas entre centenas de zado mostra uma evolução de planejamen-
computadores funcionando em tempo real, to. A porcentagem de projetos entregues
feita pela IBM. dentro do prazo, custo e especificações
subiu para 39%. O índice de projetos que
O custo estimado era de 500 dólares ultrapassam o orçamento e prazo ficou
por linha de código, cinco vezes mais cara em 43%. E houve uma redução dos proje-
que a média do mercado na época. tos cancelados antes de serem concluídos,
ficando em 18%. WEstas pesquisas nos
Mas como fazer isso? Existem métodos que funcionam como uma receita de Desta forma, percebam que não é
bolo e se seguidos podem ajudar a construir projetos melhores dentro do tripé custo, simplesmente especificar, projetar e manter
prazo e qualidade. São eles: o código fonte, mas sim todos os artefatos
gerados no processo do desenvolvimento,
como a modelagem do sistema, manuais,
documentos em geral.
Tanto o produto quanto o processo

são aspectos da Engenharia de Software,
por este motivo iremos estudar ambos.
Processo é o conjunto de atividades

que serão feitas e resultarão no sistema,
produto. A necessidade é entregar produtos
de software de qualidade, que atendam
as expectativas dos clientes, desenvolvi-
dos através de processos consistentes e
gerenciados.
Etapas de um projeto de software Fonte: Autor 2017
A Engenharia “..é a ciência e a arte de especificar, projetar, implementar e manter

atualizados e corretos, com economia, em tempo útil e de forma elegante,
programas, documentação e procedimentos operacionais para sistemas
computacionais de utilidade para a humanidade” A. Brown, A. Earl e J. McDermid
Os princípios da Engenharia de Requisitos são: Métodos da Engenharia de

Software
Os métodos são abordagens estrutu-

radas para o desenvolvimento de software
que contém modelos de software, nota-
ções, regras e ciclos de desenvolvimento.
Os modelos são uma representação

simplificada de um processo de software,
eles mostram as atividades e a ordem em
que devem ser executadas.
Vamos conhecer os principais mo-

delos (ciclos de vida):
• Modelo Cascata
Neste modelo o software é feito

como um todo em cada etapa/atividade,
o que é justamente um dos seus proble-
mas, pois é muito difícil fazer o levanta-
mento completo dos requisitos no início
do projeto. Por exemplo, ao se projetar
Princípios da Engenharia Fonte: Autor (2017)
uma ponte, levantam-se todos os requisi-
tos ou características necessárias para sua
fabricação, uma vez feito isso, é iniciada
a fabricação. Caso os requisitos mudem pode ocorrer que todo o projeto tenha que Projeto - Nesta fase são detalhadas
ser refeito e as partes fabricadas descartadas. Outro ponto negativo é a demora da as partes que compõe o projeto.
entrega do produto e também o fato de que raramente os projetos seguem o fluxo
sequencial como proposto. Fabricação - É onde o projeto é
implementado de fato.
Testes - São avaliados os requisitos

do projeto com o produto.
Manutenção - São as alterações ne-

cessárias ou o acompanhamento para que
o produto resultante do projeto permaneça
funcional.
O ciclo de vida clássico serve para

projetos de engenharias clássicas, porém
tudo é muito volátil e muda rapidamente
não seguindo e não comportando o mesmo
fluxo de etapas tradicional.
FIGURA – Ciclo de vida modelo Cascata (PRESSMAN, 2011)
Modelo em V
As fases de um ciclo de vida dos modelos clássicos são:
Planejamento - É o início do projeto. Nesta fase são estabelecidos os Neste modelo temos as etapas muito
parecidas com o modelo anterior, porém
objetivos do projeto, em linhas gerais. para cada etapa da horizontal há uma veri-
ficação. Desta forma os problemas encon-
Requisitos - Nesta fase são especificados os requisitos técnicos do projeto. trados em cada etapa já são identificados
FIGURA – Ciclo de vida modelo Incremental (Adaptação PRESSMAN, 2011)
e corrigidos evitando que todo o processo • Modelo de Prototipação

seja executado para somente depois ver
que estava errado. Protótipos na área de Tecnologia da Informação, é similar as maquetes na ar-
quitetura. Com os protótipos, que são versões iniciais, é possível realizar verificações
• Modelo Incremental e experimentações do sistema antes dele ser construído de fato. O uso desta técnica
torna algo abstrato em algo concreto, e auxilia muito no entendimentos dos clientes
O modelo incremental possui etapa e/ou pessoas chaves.
de Levantamento de Requisitos, Aquisição
dos Requisitos, Projeto, Implementação,
Testes e Implantação. Percebam que, nova-
mente, estamos falando da mesma “receita
de bolo”, porém neste o sistema é dividido
em módulos e vão incrementando o sis-
tema até que o mesmo esteja completo.
Neste modelo são obtidos os requisi- próxima com o cliente, definindo de forma • Maximização na qualidade do sof-
tos e a partir deles é feito um projeto rápido imediata as especificações do sistema. tware desenvolvido;
e a construção do protótipo. O usuário
Início
avalia este protótipo, que pode ser ou não • Software final mais adequado às
funcional e através dessa avaliação o pro- necessidades do usuário.
duto de fato é construído. A prototipação Fim
poderá ser implementada de três maneiras Obtenção dos
requisitos Métodos Ágeis – SCRUM
diferentes:
Construção Projeto
• Protótipo baseado em papel ou do produto O SCRUM é um método ágil, ou
rápido
em computador pessoal com a intenção seja, um processo que foi criado para aten-
de exibir a interface a ser desenvolvida e Refinamento Construção der a flexibilidade e agilidade dos nossos
permitir a rápida identificação dos requi- do protótipo protótipo dias atuais.
sitos do sistema.
Avaliação do Nele temos uma lista de tarefas, que
• Protótipo criado para implemen- protótipo precisam encaixar no intervalo definido
tação de alguma rotina a fim de testar do Sprint (período de tempo ), que deve
requisitos específicos a serem agregado ser de 2 a 4 semanas. Em métodos ágeis
FIGURA – Ciclo de vida da prototipação (PRESSMAN, 2011)
ao sistema. a documentação é somente a extritamente
As principais vantagens da proto- necessária, desta forma, exige maior inte-
• Programa já existente dentro do tipação são: ração das equipes. Por este motivo, neste
sistema com a possibilidade de ser melho- método são feitas reuniões diárias para
rado a fim de justificar o custo do desen- • Menor prazo para o sistema entrar que o time saiba o que está sendo feito e
volvimento da solução específica. em produção; quais são as dificuldades.
O ciclo de vida da prototipação é • Acompanhamento do usuário nas Ao final das 2 ou 4 semanas é ne-
diferente de um projeto de engenharia, fases do desenvolvimento minimizando cessário que seja entregue um produto
e ocorre através de uma interação mais possíveis erros; funcional finalizado para o cliente.
Esta é a parte mais crítica e propensa a erros no desenvolvimento de um sistema.
Já viram aquela imagem famosa das árvores? Ela mostra exatamente o que
acontece com um software que não tem os requisitos identificados corretamente.
O processo de desenvolvimento pode ser comparado a um telefone sem fio, que

vai passando a informações e ela vai se perdendo e modificando. Mas isso pode ser
solucionado com planejamento, técnicas corretas para levantamento dos requisitos,
organização, comunicação e documentação.
O que é Requisito:
Requisitos expressam características

e restrições do produto de software, do
ponto de vista de atender as necessida-
des do usuário, em geral, não tem ligação
com a tecnologia que será utilizada para
a construção da solução.
Stakeholder
São dos clientes, usuários diretos e

indiretos, forncedores, investidores, geren-
tes, atendimento (suporte) e manutenção.
Ou seja, qualquer pessoa que é afetada
pelo resultado do projeto.
Artefato
São produtos tangíveis de um proje-

to, como diagramas de classe, de sequên-
cia, documentação, código fonte, código
executável.
Questões
1. Um dos ciclos de Vida da Engenharia de Software bastante
utilizado é o Modelo Incremental. Explique como funciona este
modelo.
2. Explique o que é um Requisito e cite pelo menos 3 exemplos.
3. Se você trabalha na área de Tecnologia da Informação, diga qual
modelo de ciclo de vida a sua empresa utiliza.
ENGENHARIA DE
REQUISITOS
Entenda conceitos da engenharia de
requisitos e sua importância no software
Etapas da Engenharia de Requisitos conflitantes; definições vagas; requisitos

voláteis, que mudam constantemente; e
o último, mas não menos importante a
Elicitação de Gerência de Gerência de omissão de informações importantes.
Requisitos Escopo Mudanças
Dentro desta etapa temos algumas
atividades, são elas:
Análise e 1. Entendimento do domínio da apli-

Gerência de cação: onde o sistema será aplicado/
Negociação de
Requisitos utilizado.
Requisitos
2. Entendimento do problema: deta-
lhes do problema específico.
Documentação Validação dos
3. Entendimento do contexto do ne-
de Requisitos Requisitos
gócio: qual será a contribuição do
sistema para que sejam atendidos
os objetivos da organização.
Elicitação de Requisitos
4. Entendimento das necessidades e
das restrições dos stakeholders.
A elicitação, sinônimo de extração, de requisitos é o processo de descobrimento
dos requisitos de um sistema. Nesta etapa os engenheiros fazem o levantamento e a
documentação do conhecimento do cliente.
No cenário perfeito, os clientes sabem exatamente o que querem. Mas a realidade

não é bem assim. Ao elicitar requisitos com os usuários chaves se descobre: requisitos
Técnicas de Levantamento de Requisitos Entrevistas tente dos entrevistados e da organização.

Estabelecer objetivo e decidir quem será
entrevistado.
Workshops de Requisitos (Brains- É uma técnica tradicional bem sim-
torming): ples de ser utilizada. Mas para esta técnica Preparar a entrevista em si, deci-
funcionar é preciso algumas diretrizes, dindo sobre os tipos de questões que serão
Técnica de elicitação em grupo, são elas: utilizadas. E por fim, decidir como irá
onde participam analistas e os principais registrar a entrevista, gravação de áudio,
stakeholders. Eles devem sugerir e explorar • Desenvolver um plano geral de de vídeo, anotações no papel, etc.
ideias. entrevistas;
O objetivo é obter um processo de • Certificar-se da autorização para

negociação e tomadas de decisões. Nesses falar com os usuários;
workshops são produzidas documentações
que irão refletir os requisitos e as decisões • Planejar a entrevista para fazer uso
tomadas sobre o sistema. eficiente do tempo;
• Utilizar ferramentas automatiza-

das, que sejam adequadas;
• Usar um estilo adequado ao en-

trevistar;
• Tentar descobrir o que é mais im-

portante para o usuário;
Para o planejamento de uma en-

trevista é preciso estudar o material exis-
Tipos de questões: Questionários peração e conscientização das atividades

de outras pessoas.
Subjetivas
Quando os stakeholdes estão loca-
Vantagens Desvantagens lizados em locais geograficamente dife- Antes de começar a aplicação da
Podem resultar em rentes, esta técnica é indicada. etnografia é importante seguir alguns
Proveem riqueza de passos, são eles:
muitos detalhes
detalhes
irrelevantes Porém, para que funcione é preciso
um domínio elevado do processo de ne- • Identificar as áreas de usuário a
Revelam novos Perda do controle da
questionamentos entrevista gócio. Ele deve ser simples, pode conter serem observadas;
questões de múltipla escolha, listas de • Obter aprovação das respectivas
Colocam o Respostas muito verificação e poucas questões discursivas. gerências;
entrevistado a longas para obter
vontade pouca informação útil É importante que seja encaminha- • Obter nomes e funções das pessoas
Pode parecer que o do o questionário com um documento chaves;
Permitem maior
entrevistador não tem descritivo do objetivo e como ele deve ser
espontaneidade • Explicar a finalidade do estudo.
objetivo preenchido. E controlar quem são as pes-
Objetivas soas que responderão o questionário.
Durante a observação é preciso:
Vantagens Desvantagens
Etnografia (Observação) • Observar os agrupamentos orga-
Podem ser
Ganho de tempo desgastantes para o nizacionais;
A técnica de observação consiste em
entrevistado. compreender os requisitos sociais e organi- • Observar as facilidades manuais e
Podem falhar na zacionais. Para isso o analista é inserido no automatizadas;
Manter o controle da
obtenção de detalhes ambiente de trabalho a fim de identificar
entrevista • Coletar amostras de documentos
importantes tarefas reais onde o sistema será utilizado.
e procedimentos escritos que são usados
De aprofundamento
Assim, os requisitos serão derivados nos processos observados.
Permitem explorar os detalhes de uma questão,
de como as pessoas trabalham e da coo-
como, quantos, quem, por quê?, e etc.
• Acumular informações estatísti- As etapas de um levantamento orientado a ponto de vista são:

cas das tarefas, como frequência, volume,
tempo de duração;
• E observar as exceções dos pro- IDENTIFICAÇÃO ESTRUTURAÇÃO DOCUMENTAÇÃO MAPEAMENTO

DE PONTO DE
cessos. DE PONTOS DE
VISTA VISTA
DE PONTO DE
VISTA
DO SISTEMA DE
PONTO DE VISTA
Depois de feita a etnografia é pre- Etapa 1: utilização da abordagem de brainstorming, ou similar, para identificar
ciso documentar todas as descobertas e os serviços em potencial.
consolidar o resultado, revendo-os com
as pessoas observadas e seus respectivos Exemplo: cliente do banco, cliente do banco conveniado, funcionários do banco,
gestores. gerente, serviços prestados.
Pontos de Vista Etapa 2: agrupamento dos pontos de vista relacionados criando uma hierarquia.
Cada stakeholder possui diferentes Todos os

Serviços:
pontos de vista, ou seja, veem o problema consultar saldo
pontos de
vista
de forma diferente. retirar dinheiro
Funcionários
Cliente
Esta técnica busca identificar os di- (interação)
do banco
(indireto)
ferentes pontos de vista, para estruturar e
organizar os requisitos. Por exemplo:
Cliente Cliente de Gerente de Engenheiro
do banco banco contar de Software
O sistema de um caixa eletrônico conveniado
possui a visão do correntista (visão de

Serviços:
interação), a do gerente (ponto de vista emitir talão de cheques,
indireto), e a comunicação interbancos emitir extrato detalhado
transferir fundos
(ponto de vista de domínio).
Etapa 3: refinamento das descrições Análise de Documentação JAD (Joint Application Design)
dos pontos de vista e serviços.
Identificar documentos, relatórios Técnica para promover cooperação,
Etapa 4: mapear o sistema, identi- impressos ou digitais utilizados pelos usu- entendimento e trabalho em grupo entre
ficar os objetos (no caso de Programação ários em suas tarefas. Após identifica-los os desenvolvedores. Seus princípios são:
Orientada a Objetos), utilizando o encap- com nome e cenário em que é utilizado,
sulamento nos serviços. detalhar as informações e periodicidade 1. Dinâmica de grupo: reuniões para
da utilização. despertar a força e criatividade.
Casos de Uso/Cenários
Técnica utilizada quando já existe 2. Uso de técnicas visuais: aumentar
Análise de situações reais, focando um sistema informatizado na empresa. comunicação e entendimento.
nas atividades que as pessoas realizam. Consiste em ler/analisar interfaces, fun-
Inclui: cionalidades, incluindo se possível código 3. Manutenção do processo organi-
e estrutura do banco de dados. zado e racional, análise top-down
• Descrição da situação inicial; e atividades bem definidas.
Neste cenário é muito importante
• Descrição do f luxo normal de identificar principalmente o que NÃO 4. Utilização de documentação padrão,
eventos; DEVEMOS FAZER. Afinal, se o cliente garantindo a qualidade do projeto.
está trocando de sistema, é por que não
• Descrição do que pode dar errado; está satisfeito com o mesmo. As etapas dessa técnica são o Plane-
jamento, fase de elicitação e especificação
• Informação sobre outras atividades de requisitos. E de Projeto, fase do projeto
concorrentes; de software.
• Descrição do estado quando o ce-

nário analisado termina.
Prototipagem Classificação de Requisitos
É indicado para estudar as alterna- Requisitos Funcionais

tivas de interface do usuário e viabilidade
de atendimento dos requisitos de desem-
penho. Descrevem o que tem que ser feito pelo sistema, assim como o que deve sair do
sistema, ou seja, define o comportamento e suas ações para cada entrada.
Com a utilização dos protótipos
há uma redução dos riscos, pois permi- Livro Fundamentos da Engenharia de Requisitos:
te que os usuários avaliem o sistema de
uma forma mais concreta, antes dele ser
“Requisito Funcional é um requisito relacionado ao resultado
desenvolvido. de algum comportamento a ser fornecido por uma função do
sistema.”
Tipos de prototipagem:
Requisito de Qualidade/ Não Funcionais
• Em papel: utiliza meios físicos
como papéis, cartolina para criação de
objetos que irão demonstrar o sistema
“Requisitos de qualidade definem qualidades desejadas do sistema
proposto.
a serem desenvolvido e muitas vezes influenciam a arquitetura
• Wireframe: “esqueleto de proje- do sistema mais do que os requisitos funcionais. Tipicamente,
tos” que irá demostrar a arquitetura dos requisitos de qualidade definem o desempenho, a disponibilidade, a
objetos. confiabilidade, a escalabilidade ou a portabilidade de um sistema.”
• Mock-up: protótipo em tamanho Os requisitos de qualidade são classificados também como requisitos não fun-
real do produto com possibilidade de in- cionais. Eles expressam como deve ser feito. Normalmente estão relacionados aos
teração do usário. requisitos funcionais dando suporte a eles.
Requisitos não Análise e Negociação de

funcionais Requisitos
Requisitos de Requisitos Requisitos Após a elicitação dos requisitos, são

produto organizacionais externos
feitas as análises e as verificações dessas
informações, afim de resolver os requi-
sitos conf litantes, faltantes, ambíguos,
Requisitos de Requisitos de Requisitos de Requisitos Requisitos
eficiência confiança proteção reguladores éticos sobrepostos, etc.
Ao final desta etapa teremos o do-

Requisitos de Requisitos Requisitos Requisitos de Requisitos cumento de requisitos acordado com os
usabilidade ambientais operacionais desenvolvimento legais stakeholders.
1. Formam a base para o desenvolvi-

Requisitos de Requisitos de Requisitos Requisitos de
desempenho espaço contábeis segurança mento do sistema. Irão influenciar,
direta e indiretamente, na análise, o
Restrições design, a implementação e as fases
de teste. A qualidade da documen-
Definição: “Uma restrição é um requisito que limita o espaço da solução além do tação terá um forte impacto sobre o
que seria necessário para cumprir os respectivos requisitos funcionais e de qualidade. ” desenvolvimento do projeto.
As restrições não são implementadas, são cumpridas. Por exemplo, o sistema 2. Requisitos tem relevância legal, ou
deverá ser totalmente web, ou o sistema deverá ser lançado até o segundo semestre, etc. seja, são legalmente vinculantes para
Dicas para extração de Requisitos Funcionais o contratante e o contratado. Poden-
• O sistema deve... (realizar cadastro, gerar relatório, etc.) do até mover um processo contra o
• O processo de negócio consiste em... contratado em caso de não cum-
• O tratamento dessas informações é realizado da seguinte forma.... primento.
• Quais informações não podem faltar...
3. Documentos de requisitos são com- Nesta forma o requisito é documentado PROPÓSITO DO DOCUMENTO DE REQUISITOS
plexos, possuem interdependências de forma mais compacta, o que facilita a ESCOPO DO PRODUTO
DEFINIÇÕES, ACRÔNIMOS E ABREVIAÇÕES
em múltiplos níveis, que sem a do- compreensão, diminui a ambiguidade, e REFERÊNCIAS
cumentação adequada, manter a si- tem maior grau de formalidade. INTRODUÇÃO VISÃO GERAL DO RESTANTE DO DOCUMENTO
tuação sob controle pode se tornar

muito difícil. Então qual a melhor opção? É PERSPECTIVA DO PRODUTO
preciso analisar o público-alvo, o tipo de FUNÇÕES DO PRODUTO
4. Requisitos devem ser acessíveis para

CARACTERÍSTICAS DO USUÁRIO
sistema. O ideal é uma combinação da lin-
DESCRIÇÃO RESTRIÇÕES GERAIS
todas as partes envolvidas. Com guagem natural e dos modelos conceituais, SUPOSIÇÕES E DEPENDÊNCIAS
GERAL
o passar do desenvolvimento do assim é possível aproveitar as vantagens de
projeto tanto o conteúdo, quanto ambos e diminuir as desvantagens.
REQUISITOS DE INTERFACES EXTERNAS
o pessoal pode mudar, por isso os REQUISITOS FUNCIONAIS
documentos devem estar disponí- Resumindo, independente da lin-

REQUISITOS DE DESEMPENHO
RESTRIÇÕES DO PROJETO
veis para qualquer membro acessar guagem utilizada, a documentação precisa REQUISITOS ATRIBUTOS DO SISTEMA
OUTROS REQUISITOS
rapidamente. ser formal e descrever os serviços e fun- ESPECÍFICOS

ções, as limitações sobre as quais o sistema
Normalmente a linguagem natural deve operar e definições de outros sistemas
é a mais aplicada para a documentação de que ele precisa se integrar. Validação dos Requisitos
requisitos. Sua vantagem é que qualquer
stakeholder irá entendê-la, diferente de A norma IEEE 830-1998 contém a Será validado se todos os requisitos
uma notação específica que exige um co- seguinte estrutura para o documento de estão corretos, completos, consistentes e
nhecimento prévio. requisitos: descritos de maneira apropriada.
O ponto negativo é que pode resul- Gerência de Requisitos

tar em requisitos ambíguos.
Irá realizar o acompanhamento da
Já a documentação usando modelos evolução dos requisitos. Monitora o de-
conceituais, possuem conceitos universais. senvolvimento e implementação dos requi-
sitos, registrando atributos, dependências,

status a fim de controlar as mudanças e o
andamento do projeto.
Gerência de Escopo
O escopo de um sistema é conjunto

de requisitos que serão entregues no final
do projeto. Nem todas as funcionalidades
levantadas na elicitação de requisitos farão
parte do escopo do projeto.
Nele são priorizados os requisitos

e este processo denomina-se de gerência
de escopo.
Gerência de Mudanças
Mudanças nos requisitos durante o

projeto são corriqueiras, e demandam um
replanejamento do projeto, necessitando de
negociações com relação a custos, prazos
e escopo do sistema.
A função desta gerência é analisar os

impactos das mudanças, oferecer subsídios
para estimativas de esforço e estratégias
de priorização.
Questões
1) Cite 4 técnicas de elicitação de requisitos e explique cada uma
delas.
2) Explique o que é um requisito funcional e não-funcional.
3) Cite pelo menos 3 requisitos funcionais e 3 não funcionais.
QUALIDADE DE
SOFTWARE
O que é qualidade para você?
“Propriedade específica. Condição natural
de um ser vivo ou inaminado. Dote; Atributo;
predicado“ (LUFT, 1991, p. 512).
Ao ler o conceito mais recente de qualidade fica explícito
que qualidade é essencial e não é apenas mais um diferencial
nas empresas.
Um dos principais objetivos da Engenharia de Software

é qualidade do produto. A qualidade está diretamente rela-
cionada ao conceito de maleabilidade, ou seja, a facilidade de
mudanças.
As mudanças no produto de software devem ser vistas

como uma mudança de projeto e não apenas no código fonte
“Característica ESSENCIAL. Propriedade. Traço pessoal. Caráter; que é somente uma parte do produto.
natureza. Superioridade de espécie. Excelência, espécie, tipo. Alta
posição social. Virtude. Condição; posição”(Sacconi, 2009).
Além da qualidade do produto de A ISO 9126 é composta de:

software, existe a qualidade de processo
de produção de software, como CMMI, • Modelo de qualidade
MPS.Br que iremos ver ao longo deste • Métricas externas
capítulo. • Métricas internas
• Métricas de qualidade em uso.
Classificação
A ISO 14598 complementa a ISO 9126, inclui modelos para relatórios de
• Qualidade Externa: são as visualli- avaliação, técnicas para medição das características, documentos e fases da avaliação.
zadas pelos usuários e estão diretamente
Norma Nome Finalidade
relacionadas com o atendimentos dos re-
quisitos. Exemplo: confiabilidade. Ensina a utilizar as outras normas do
14598-1 Visão Geral
grupo
• Qualidade Interna: são visuali- Sobre como fazer uma avaliação, de
14598-2 Planejamento e Gerenciamento
zadas e sentidas pelos desenvolvedores. forma geral
Exemplo: manutenbilidade. Como avaliar sob o ponto do vista de
14598-3 Guia para Desenvolvedores
quem desenvolve
Modelos de Qualidade Como avaliar sob o ponto de vista de
14598-4 Guia para Aquisição
quem vai adquirir
Existem modelos que definem e Como avaliar sob o ponto de vista de
14598-5 Guia para Avaliação
organizam os atributos do software que quem certifica
são importantes para a avaliação da sua Detalhes sobre como avaliar cada
qualidade. Temos a ISO/IEC 9126, depois 14598-6 Módulos de Avaliação
característica
surgiu a ISO/IEC 14598 e a ISO 25000
(SquaRE). E por fim a ISO 25000, mais conhecido como SquaRE (Software Product
Quality Requirements and Evolution, que contém o que o software precisa ter, os
requisitos de qualidade, as medições, mo- sua maturidade e capacidade por área de Agrupamento de práticas relaciona-
delos, além de como deve ser feita a gestão processo, como priorizar as melhorias e das a determinado contexto que, quando
da qualidade e como avaliar tudo isso. como implementá-las. executadas de forma coletiva, atingem um
nível de maturidade.
Para entendermos este modelo pre-
cisamos primeiro ver alguns conceitos bá-
sicos.
• Nível de Maturidade
Estágio evolucionário definido que

CMMI pode ser atingido por uma organização que
utiliza modelos CMMI de forma completa Foco na melhoria de processos
ou parcial; Processos são medidos e

O CMMI é um modelo de capaci- controlados
dade e maturidade. Ele é um modelo de Os níveis são uma forma de priori- Processos são caracterizados
referência que contém práticas necessárias zar as ações de melhoria de tal forma que para organização e são proativos
para avaliar a maturidade da organização se aumente a maturidade no processo de Processos são caracterizados por pro-
com relação a engenharia de software. software. jeto e as ações são frequentementes
Processos são imprevisíveis, pouco controlados e reativos

O seu objetivo é melhorar os pro- • Capacidade de Processo Etapas do CMMI detalhado
cessos da organização, gerenciar o desen-
volvimento, aquisição e manutenção de Conjunto de resultados esperados e
produtos e serviços. que podem ser alcançados em um processo
de software.
É formado por modelos de proces-
so manuais, treinamento e avaliação que • Áreas de Processo
orientam a organização a como avaliar a
MPS.BR C. Definido
D. Largamente Definido
O MPS.BR - Melhoria de Proces-
E. Parcialmente Definido
so do Software Brasileiro nasceu de um
projeto que uniu universidades, grupos de F. Gerenciado
pesquisa e empresas, sob a coordenação
G. Parcialmente Gerenciado
da SOFTEX (Associação para Promoção
da Excelência do Software Brasileiro) em
dezembro de 2003.
O MPS.BR é baseado em modelos e

normas internacionais com o objetivo de se
tornar aplicável à indústria de software re-
conhecido nacional e internacionalmente.
Os níveis de maturidade estabele-

cem patamares de evolução de processos,
caracterizando estágios de melhoria da
implementação de processos na organi-
zação. O nível de maturidade em que se
encontra uma organização permite prever
o seu desempenho futuro ao executar um
ou mais processos. O MR-MPS define
sete níveis de maturidade:
A. Em Otimização
B. Gerenciado Quantitativamente
O MPS de Software tornou possí-

Comparação dos Níveis de Maturidade
vel que organizações de pequeno e médio
CMMI MPSBr porte conseguissem implementar e usu-
1 Não definido fruir dos benefícios que a utilização dessas
G boas práticas da engenharia de software
oferecem. Com isso a indústria nacional
2 F
obteve ganhos comprovados de competi-
E tividade, por isso é considerado um marco
D que representa a evolução da qualidade do
3 C software desenvolvido no país.
4 B
Esta iniciativa conta com o finan-
5 A ciamento do Banco Interamericano de
Desenvolvimento (BID), a Financiadora
de Estudos e Projetos (FINEP), o Minis-
tério da Ciência, Tecnologia e Inovação
(MCTI) e o Serviço Brasileiro de Apoio às
Micro e Pequenas Empresas (SEBRAE).
Questões
1. Depois de ter estudado este capítulo, o que é qualidade para
você?
2. Pesquisar sobre Modelos de Maturidade: TIM, TMMI e TPI
3. Pesquisar quais empresas na sua cidade possuem CMMI e
MPS.BR e em qual nível elas estão.
UML
Nos primórdios do software o cenário
era o seguinte: cada grupo ou organização
desenvolvia seu sistema e criava sua própria
maneira de documentar/modelar o software.
Foi aí que percebeu-se a necessidade de um padrão
para a modelagem de sistemas, que fosse aceito e utilizado
amplamente.
Booch [BOOCH], Rumbaugh [OMT] e Jacobson

[OOSE] “Três Amigos” da IBM Rational, reuniram esfor-
ços neste sentido de padronização e com isso surge a UML
(Unified Modeling Language), em 1996, como a melhor can-
didata para ser a linguagem “unificadora” reunindo diversas
notações anteriores.
Em 1997, a UML é aprovada como padrão pelo OMG

e desde então, tem tido grande aceitação pela comunidade de
desenvolvedores de sistemas.
É uma linguagem que continua sendo atualizada e

atualmente está na versão 2.5.
A UML (Linguagem de Modela- • Diagrama de Objetos;

gem Unificada) é uma linguagem padrão
para elaboração da estrutura de projetos • Diagrama de Componentes;
de software, sendo utilizada para:
• Diagrama de Distribuição;
• Visualização;
Para modelar o comportamento do sistema:
• Especificação;
• Diagrama de Casos de Uso;
• Construção de modelos e diagra-
mas; • Diagrama de Interação (Sequência e Colaboração);
• Documentação. • Diagrama de Atividade;
Importante ressaltar que a UML • Diagrama de Estados;

não é um processo de desenvolvimento
Diagrama da
de software, apenas possui modelos para UML
auxiliar engenheiros de software para re-
presentar alguns domínios da aplicação, Diagramas Diagramas
Estruturais Comportamentais
tais como requisitos, comportamento e
sua estrutura lógica. Compreendendo os Diagrama de Diagrama de
Diagrama de
Casos de Uso
Objetos Diagrama de Pacotes
seguintes diagramas: Classes
Diagrama de Diagrama de
Diagrama de Diagrama de Transições de Estados
Estrutura Composta Atividades Sequência
Diagramas de
• Para modelar a estrutura do sis- Implementação
tema: Diagrama de Diagrama de Diagrama de Diagrama de

Sequência Diagrama de Colaboração
Componentes Implantação Temporicação
• Diagrama de Classes; Diagrama de Visão
Geral da Interação
Com o uso da UML podemos iden- Eles permitem visualizar, especificar e documentar o comportamento dos
tificar diversas visões diferentes do projeto, elementos.
como por exemplo, visão de projeto, de
implementação, de caso, de uso, etc. É uma descrição de um conjunto de sequências de ações que um sistema pode
produzir um resultado de valor observável pelo ATOR. A descrição do caso de uso
Conforme mostrada na imagem é feita através de CENÁRIOS.
cada diagrama da UML será importante
para compreender os comportamentos e
estrutura do projeto.
Descreve papéis de usuários/

sistemas que podem utilizar as
funcionalidades do sistema a
ser modelado.
Refere-se aos serviços ou

funcionalidades do sistema
Diagrama de Caso de Uso identificados para atender os
Caso de Uso
requisitos definidos.
Nomenclatura padrão: verbo
Os casos de uso descrevem o com-
portamento do sistema na visão de usuários
no infinitivo.
finais, analistas e testes.
Nome do Caso de Uso Abrir Conta

Atores Cliente
Esse caso de uso descreve as etapas percorridas por um
Resumo
cliente para abrir uma conta corrente
O pedido de abertura precisa ter sido previamente
Pré-condições
aprovado
Pós-condições É necessário realizar um depósito inicial
Fluxo Principal
1. [A] Solicitar abertura de conta
Exemplo de Diagrama de Caso de uso
2. [S] Consultar cliente por CPF ou CNPJ
Para cada elipse é necessário fazer uma tabela de deta-
3. [A]Informar a senha da conta
lhamento, onde será especificado o fluxo principal, “o caminho
4. [S]Abrir conta
feliz”, os fluxos alternativos, as exceções, quais são as pré-con-
dições para que este caso de uso seja executado e quais atores 5. [A]Fornecer valor a ser depositado
estão envolvidos. 6. [S] Registrar depósito
7. [S] Emitir cartão da conta
1a. Para abrir uma conta corrente é preciso ser maior de idade
1b. O cliente precisa fornecer algum comprovante de
Restrições/Validações
residência
5a. O valor mínimo de depósito é R$ 5,00
Fluxo Alternativo – Manutenção do Cadastro do Cliente
1. [S] Executar caso de uso Manter Cliente, para gravar ou atualizar o cadastro do
cliente
Fluxo de Exceção – Cliente menor de idade
1. [S] Comunicar ao cliente que não possui idade mínima para possuir uma conta
corrente.
2. [S] Recusar o pedido.
Associações • Entre Casos de Uso

uc
Podem existir as seguintes representações de relaciona-

Renovar estoque
mentos entre:
Funcionário
• Atores e Casos de Uso

Gerar relatórios
CLIENTE
Gerente
CADASTRAR
Gerar relatório Gerar relatório
financeiro gerencial
• Esteriótipo <<include>> (Inclusão)

• Entre Atores
<<include>> Significa que o caso de uso tem obrigatoriedade de ser

SACAR DINHEIRO
executado para executar o outro caso de uso. Utilizado para re-
<<include>>
presentar rotinas comuns a mais de um caso de uso, por exemplo,
IDENTIFICAR “Logar” normalmente é uma rotina obrigatória e comum aos
USUÁRIO USUÁRIO outros casos de uso, neste caso utilizamos o Include.
DEPOSITAR DINHEIRO
CLIENTE Importante!!! A seta sempre vai em direção ao caso de uso

CAIXA GERENTE
que é obrigatório a execução antes.
<<include>>
ABRIR CONTA DEFINIR CLIENTE
ou não consultar o SPC.

Realizar depósito
<<in
clud • O entregador Entrega pedidos, mas obrigatoriamente
e>>
deverá verificar os pagamentos atrasados
Realizar movimento
de>>
Cliente <<inclu
Realizar saque <<extend>> consulta no
SPC
tirar pedido
• Estereótipo <<extend>> (extensão) <<include>>
Vendedor verificar
Quando cada uma das extensões descreve as diferentes <<include>> pagamentos
atrasados
maneiras com que um passo do caso de uso pode ser executado, entrega
ou seja, os cenários opcionais. Neste caso não tem a obrigato- pedido
riedade de ser executado.
Entregador
Como identificar atores, objetivos e casos de uso?
Encerrar conta
1. Escolher a fronteira do sistema: definir quais são as res-
Cliente Funcionário ponsabilidades internas do sistema;
<<extend>> <<extend>>
2. Identificar os atores principais: aqueles que devem ter

objetivos de usuários atendidos por meio dos serviços do
Realizar saque Realizar depósito
sistema;
No exemplo abaixo interpretamos da seguinte forma: 3. Para cada ator, identifique os objetivos do usuário, ele-
vando até o nível mais alto do objetivo; Diferencie atores
• O vendedor pode tirar pedidos, mas obrigatoriamente principais e secundários.
ele deverá verificar os pagamentos atrasados. Se quiser, pode
4. Defina casos de uso que satisfaçam aos objetivos do usuário, nomeando-os de Diagrama de Classe
acordo com os objetivos.
No final da década de 80 houve o
amadurecimento da Orientação a Objeto,
fronteira do sistema ProxGear comunicação
que é utilizado até hoje, e assim surgiu a
notação AOO, Análise Orientada a Objetos.
alternativa
Processar para um ator
Venda que é um sistema A Análise Orientada a Objetos se
de computador baseia em conceitos simples que o homem
serviço de
Caixa Tratar Autorização adquire desde a infância, como objetos e
Devoluções de Pagamento atributos, classes e membros, todo e partes
<<ator>> do todo.
ator Processar Calculador de
Aluguel Impostos
O sistema é uma coletânea de ob-
<<ator>> jetos que irão interagir entre si, com suas
Abrir Sistema de características, os atributos e operações.
Contabilidade
<<ator>>
Sistema
Atividade de Analisar <<ator>>
Vendas Atividade Sistema RH
Gerenciar
Segurança
Administrador Administrar
Usuários casos de uso
de Sistema
...
Exemplo de uma classe, com atri- Atributos: as variáveis, caracterís- software, que representam instâncias de
butos e métodos: ticas entidades do mundo real. É geralmente
identificado por um substantivo.
Contém atributos (características do

objeto que podem ser alteradas de acordo
com seu estado) e comportamento (forma
que o objeto reage a seus estímulos).
Classe: É um conjunto de objetos

que possuem estados semelhantes (mesma
lista de atributos), comportamento comum
(mesmas operações) e relacionamentos
comuns com outros objetos.
Métodos: são as ações que podem
• Classe: Veículo, Objeto: Automó- ser executadas pela classe.
vel do Fulano
• Classe: Pessoa, Objeto: João da

A partir das classes, criamos os ob-
Silva
jetos que são entidades em um sistema de
software, que representam instâncias de
entidades do mundo real. É geralmente
identificado por um substantivo.
Contém atributos (características do

A partir das classes, criamos os ob- objeto que podem ser alteradas de acordo
jetos que são entidades em um sistema de com seu estado) e comportamento (forma
que o objeto reage a seus estímulos).
Abstração Encapsulamento
Atributos e operações de um obje-

É a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, to devem estar armazenados no próprio
ignorando características menos importantes ou acidentais. objeto (encapsulados no objeto);
Uma classe abstrata é desenvolvida para representar entidades e conceitos abs- O encapsulamento protege os dados
tratos. A classe abstrata é sempre uma superclasse que não possui instâncias. do acesso descontrolado, sendo possível
o acesso somente através de mensagens
Cada uma das classes derivadas, completa a funcionalidade da classe abstrata (execução das operações) trocadas entre
adicionando um comportamento específico. os objetos;
– Privados (private): Visível somente dentro da
própria classe, representado pelo sinal de menos;
+ Públicos (public): Visível por qualquer outra
classe, representado pelo sinal de mais;
# Protegido (protected): Visível dentro da própria
classe e classes filhas, representado pelo sinal de
sustenido.
EMPREGADO
NOME: string
ENDEREÇO: string
DATA_NASC: date
CPF: string
SALARIO: float
+Contratar()
+Demitir()
#Alterar_dados
Associações Associações Unárias ou Reflexivas
A comunicação entre os objetos das classes ocorre pela troca de mensagens. São os casos onde a classe se rela-
Um objeto solicita informações de outro objeto para realizar suas funções. ciona com ela mesma, por exemplo, uma
classe Funcionário, quem irá chefiar os
As mensagens são execuções de operações, que podem ou não enviar parâmetros funcionários também é um funcionário
para outro objeto, assim como podem receber ou não parâmetros. e a representação fica da seguinte forma:
As mensagens/associações são representadas por uma linha contínua entre as

classes, nela deve conter o nome da associação e a expressão de multiplicidade, que
define quantas instâncias da classe A podem estar associadas a uma instância de uma
classe B.
Associações Binárias Associação de Agregação
A ligação mais comum é a ligação binária, entre duas classes. A agregação é utilizada para repre-
sentar a relação do “todo” composto por
“partes”. Objetos “partes” podem ser com-
partilhados por mais de um objeto “todo”.
Associações Ternárias ou N-árias
Ações ternárias entre três classes, ou as N-árias que são associações entre várias
classes.
Associação de Composição
Quando as partes, para existirem, dependem da existência do todo será uma

relação de agregação. Por exemplo, itens de pedido não existem se não existir o pedido.
O objeto “parte” deve estar relacionado a apenas um objeto “todo”.
Associação de Generalização
A generalização é a relação estabelecida entre uma superclasse (classe genérica)

e uma subclasse;
É a abstração, onde o que é comum ficará na superclasse e as subclasses irão

herdar as características da superclasse.
Diagrama de Sequência Lifelines: Participante individual participando ativamente de um processo.

em uma interação (instância de uma classe Representado por uma linha mais grossa.
que participa de uma interação).
O diagrama de Sequência determina
a sequência de eventos que ocorrem em um
determinado Caso de Uso. Ele se baseia
nos casos de uso e diagrama de classe.
Com o Diagrama de Sequência é

possível validar o diagrama de classe.
Atores: No Diagrama de Sequência,

representam instâncias dos atores declara-
dos nos diagramas de caso de uso, repre-
Mensagens: Demonstram a ocor-
sentando entidades externas que interagem
rência de eventos, que indicam a chama-
com o sistema gerando eventos que iniciam
Ela representa o tempo em que um da de um método em algum dos objetos
processos.
objeto existiu durante um processo (re- envolvidos no processo;
presentada por uma linha tracejada). A
linha é interrompida com um “X” quando Se a mensagem representar comu-
o objeto é destruído. nicação entre dois atores, não dispara mé-
todos.
Um objeto não precisa necessaria-
mente ser exibido no topo do diagrama, Podem ser disparadas entre:
podendo ser representado no momento
em que é criado. • Um ator e outro ator;
• Um ator e um objeto, onde um

Foco de Controle ou Ativação: ator produz um evento que dispara um
Indica o período em que um objeto está método em um objeto;
• Um objeto e outro objeto, onde um Eliminando um objeto: Fragmentos: Servem para separar
objeto transmite uma mensagem para ou- blocos de mensagens.
tro solicitando a execução de um método;
• Um objeto e um ator, quando um

objeto envia uma mensagem de retorno
em resposta à chamada de um método.
Mensagens de Retorno: Identifica
Instanciando um novo objeto: uma resposta a um objeto ou ator, po-
dendo conter informações específicas do
método chamado ou um valor indicando
a mensagem de retorno.
Auto-Chamadas:
A um objeto já existente:
Fragmentos Combinados
• Alt (Alternativas): representa uma

escolha entre dois ou mais comportamen-
tos.
• Opt (Opção): trata-se de uma in-

teração opcional, que será executada me-
diante alguma condição.
• Par (Paralelo): representa uma execução paralela de dois Exemplo:

ou mais comportamentos.
• Loop (Laço): representa um laço que será repetido di-

versas vezes.
• Break (Quebra): indica uma “quebra” na execução do

processo. Usado para modelar tratamento de exceções.
Elementos do Diagrama de Sequência
Dicas importantes:
• Os retângulos que são os objetos das classes, devem

coincidir com as classes do seu diagrama de classe.
• As mensagens trocadas devem conter os métodos do

diagrama de classe e estarem de acordo com passos dos fluxos
do Caso de Uso.
• As exceções e fluxos alternativos dos casos de uso, pre-

cisam ser mostrados no diagrama de Sequência, usar os frag-
mentos para isso.
• Façam o diagrama de sequência pensando em como vocês

gostariam que o sistema interagisse e informasse, se vocês fos-
sem os usuários, preferencialmente sempre

com mensagens de retorno para mostrar
aos usuários o que está sendo processado
pelo sistema ou que erro ocorreu.
Diagrama de Máquinas de Estados
Também conhecido como Diagra-

ma de Estados, nas versões anteriores da
UML. Pode ser utilizado para expressar
o comportamento de parte de um sistema
(caso de uso).
Transições
Demonstra o comportamento de
um elemento (instância de uma classe) por
meio de um conjunto finito de transações Representada por uma seta, indica uma mudança no estado de um objeto,
de estado. gerando um novo estado. A seta sempre aponta para o novo estado que será gerado.
Estado
• Situação de um objeto em um de-

terminado momento durante um processo, Estado Inicial
reação a um estímulo ou execução de al-
guma atividade. No estado simples sempre • Determina o início da modelagem de estados de um elemento;
deve estar no gerúndio.
• É representado por um círculo preenchido.
Estado Final Atividades Internas
• Indica o final da modelagem de estados de um elemento; Não mudam o estado do objeto. São representadas dentro
do estado e podem ser:
• É representado por um círculo não-preenchido envol-
vendo um segundo círculo preenchido. • Entry: atividade executada quando o objeto assume um
estado (entra em um estado);
• Do: atividade executada durante o tempo em que o objeto

se encontra em um estado;
• Exit: atividade executada quando um objeto sai de um

estado.
Autotransições Barra de União
Nos casos em que independente das escolhas, os objetos

ficarão no mesmo estado.W
Pseudoestado de Escolha
Ou em casos que poderão ser executados estados em paralelo Uma atividade é composta por um
conjunto de passos necessários (ações) para
que a atividade seja concluída;
Pode ser utilizado para modelar dois

tipos de fluxo: Fluxo de Controle e Fluxo
de Objetos.
• Nó de Ação
• Representa um passo que deve ser

executado em uma atividade. O verbo deve
estar no infinitivo.
• Fluxo de Controle
• Conector que liga dois nós.
Diagrama de Atividades
Oriundo do Diagrama de Máquina de Estados, enfatiza a sequência e condições

para descrever um processo computacional completo de uma atividade. Um dos mais
detalhistas, muito semelhante aos fluxogramas utilizados para lógica de programação.
• Nó Inicial • Nó de Objeto
Representa a instância de uma classe, que pode estar disponível em um deter-

minado momento da atividade.
• Nó Final
Exemplo:
• Nó de Decisão
• Nó de Bifurcação/União
Questões
1) Diferencie associação por Agregação e Composição.
2) Onde você trabalha utilizam algum dos Diagramas? Quais?
3) Se você fizesse um projeto de software para o mercado quais
dos diagramas iria utilizar?
4) Expliquei o que é a UML.
REFERÊNCIAS
Sommerville, Ian. Engenharia de Software. 8a edição. São Paulo. Pearson Addison-Wesley. 2007. (Também disponível na biblioteca virtual da
Pearson).
PRESSMAN, Roger S. Engenharia de Software: uma abordagem prática. 7 ed. São Paulo: Makron Books, 2011.
MACHADO, Felipe Nery. Análise e Gestão de Requisitos de Software: onde nascem os sistemas.1 ed. Érica, 2011.
Luft, Celso Pedro. Minidicionário Luft / colaboradores Francisco de Assis Barbosa, Manuel da Cunha Pereira. São Paulo: Ática, 2000;
Sacconi, Luiz Antônio. Minidicionário Sacconi da Língua Portuguesa. 11, Ed. São Paulo: Nova Geração, 2009;
Guedes, Gilleanes T.A. UML 2 Uma abordagem prática. -- 2. ed. -- São Paulo: Novatec Editora, 2011.
Pohl, Klaus. Rupp, Chris. Fundamentos da Engenharia de Requisitos: Um guia de estudo para o exame CPRE-FL. – , T&M e IBQTS – IREB.
STANDISH Group, The Standish Group Chaos Report, 1995, disponível em http://www.projectsmart.co.uk/docs/chaos_report
STANDISH Group, Chaos Manifesto, 2013, disponível em: https://versionone.com/assets/img/files/CHAOSManifesto2013.pdf
IEEE SOFTWARE V.16, n 6,. p. 80-88, nov./dec. 1999.
Larman, Craig. Utilizando UML e padrões – Uma introdução à análise e projeto orientado a objetos e ao processo unificado. 2ª edição. Porto
Alegre. Bookman, 2004.
Yourdon, Edward. Análise Estruturada Moderna. 3ª edição. Campus, 1990.
Koscianski, André; Soares, Michel dos Santos. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento
de software. São Paulo. Novatec, 2007.
Wazlawick, Raul S. Análise e Projeto de Sistemas de Informação Orientado a Objetos. 1ª edição. São Paulo. Editora Campus, 2004.

Requisitos de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Requisitos de Software

Enviado por

Direitos autorais:

Formatos disponíveis

REQUISITOS DE SOFTWARE

A nossa disciplina de Requisitos de Software

Por que leva tanto tempo para concluir um software?

Por que os custos de desenvolvimento são tão altos? Por

Como ponto de partida precisamos entender que fato-

Fundamentos diferente da maneira que fazemos hoje. O computador principal e o backup

Ou seja, o Software é a chave para

Tanto o produto quanto o processo

Processo é o conjunto de atividades

Etapas de um projeto de software Fonte: Autor 2017

A Engenharia “..é a ciência e a arte de especificar, projetar, implementar e manter

Os princípios da Engenharia de Requisitos são: Métodos da Engenharia de

Os métodos são abordagens estrutu-

Os modelos são uma representação

Vamos conhecer os principais mo-

Neste modelo o software é feito

Testes - São avaliados os requisitos

Manutenção - São as alterações ne-

O ciclo de vida clássico serve para

FIGURA – Ciclo de vida modelo Incremental (Adaptação PRESSMAN, 2011)

e corrigidos evitando que todo o processo • Modelo de Prototipação

Esta é a parte mais crítica e propensa a erros no desenvolvimento de um sistema.

O processo de desenvolvimento pode ser comparado a um telefone sem fio, que

Requisitos expressam características

São dos clientes, usuários diretos e

São produtos tangíveis de um proje-

Etapas da Engenharia de Requisitos conflitantes; definições vagas; requisitos

Análise e 1. Entendimento do domínio da apli-

No cenário perfeito, os clientes sabem exatamente o que querem. Mas a realidade

Técnicas de Levantamento de Requisitos Entrevistas tente dos entrevistados e da organização.

O objetivo é obter um processo de • Certificar-se da autorização para

• Utilizar ferramentas automatiza-

• Usar um estilo adequado ao en-

• Tentar descobrir o que é mais im-

Para o planejamento de uma en-

Tipos de questões: Questionários peração e conscientização das atividades

• Acumular informações estatísti- As etapas de um levantamento orientado a ponto de vista são:

• E observar as exceções dos pro- IDENTIFICAÇÃO ESTRUTURAÇÃO DOCUMENTAÇÃO MAPEAMENTO

Cada stakeholder possui diferentes Todos os

possui a visão do correntista (visão de

• Descrição do estado quando o ce-

Prototipagem Classificação de Requisitos

É indicado para estudar as alterna- Requisitos Funcionais

Requisitos não Análise e Negociação de

Requisitos de Requisitos Requisitos Após a elicitação dos requisitos, são

Ao final desta etapa teremos o do-

1. Formam a base para o desenvolvi-

tuação sob controle pode se tornar

4. Requisitos devem ser acessíveis para

documentos devem estar disponí- Resumindo, independente da lin-

rapidamente. ser formal e descrever os serviços e fun- ESPECÍFICOS

O ponto negativo é que pode resul- Gerência de Requisitos

sitos, registrando atributos, dependências,

O escopo de um sistema é conjunto

Nele são priorizados os requisitos

Mudanças nos requisitos durante o

A função desta gerência é analisar os

Um dos principais objetivos da Engenharia de Software

As mudanças no produto de software devem ser vistas

Além da qualidade do produto de A ISO 9126 é composta de:

Estágio evolucionário definido que

ou parcial; Processos são medidos e

Processos são imprevisíveis, pouco controlados e reativos

O MPS.BR é baseado em modelos e