APS Aula02 PressmanEngReq

Análise e Projeto de Software
Engenharia de Requisitos
Profa. Alessandra Alaniz Macedo

Slides adaptados de Taciana Kudo
Fases dos Modelos Clássicos
de Processo de Software
1 2 3
DEFINIÇÃO CONSTRUÇÃO MANUTENÇÃO
Análise de Sistema
Planejamento Entendimento Projeto
Modificação Codificação
Análise de Revalidação Teste
Requisitos
● Engenharia de Requisitos
○ O que é?
○ O que são requisitos de
software?
Tópicos ○
○
Quem faz?
Por que é importante?
○ Qual resultado esperado?
○ Quais os passos?
■ concepção
■ levantamento
■ elaboração
■ negociação
■ especificação
■ validação
● Gestão de Requisitos
● Ferramentas
1. Engenharia de Requisitos
O que é?
● É uma atividade da engenharia de software

● Ajuda os engenheiros de software a compreender o
problema
● Conjunto de tarefas para melhor entendimento
○ do impacto do software sobre o negócio
○ do que o cliente quer
○ de como os usuários vão interagir com o software
engenharia (análise) de sistemas
engenharia de software
engenharia de
requisitos
de software
O que são requisitos de software?
● Requisitos são a descrição das necessidades de um

produto (sistema)
● Objetivo da análise de requisitos: identificar e
documentar o que é realmente necessário para sistema
○ troca clara de informações entre cliente(s)/usuários e desenvolvedores
(práticos)
● Desafio: definir requisitos de maneira não-ambígua

○ identificação de risco para evitar “surpresas”
○ não adianta projetar e construir um programa de computador
elegante que resolva o problema errado!
Qual resultado esperado?
Entendimento do problema por escrito

● cenários de usuário
● lista de funções
● lista de características
● modelos de análise
● especificação
Quais os passos?
Concepção Elaboração Especificação

2 4 6
1 3 5
Levantamento Negociação Revisão ou
validação
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
● Especificação
● Revisão ou validação
Passo 1 - Concepção
● Surge quando...
○ uma necessidade de negócio é identificada
○ um mercado ou um serviço potencialmente novo é descoberto
● Objetivo é estabelecer...
○ um entendimento básico do problema
○ quem quer uma solução
○ a natureza da solução desejada
○ a efetividade da comunicação e da colaboração entre cliente e
desenvolvedor
Passos para iniciar a engenharia de requisitos

● Identificação dos interessados
● Reconhecimento de diversos pontos de vista
● Trabalho em busca da colaboração
● Formulação das primeiras questões
Identificação dos interessados

● Interessado:
○ "quem se beneficia, de modo direto ou indireto, do sistema que
está sendo desenvolvido"
● Cada interessado tem uma visão diferente, benefícios
diferentes, riscos diferentes, etc...
● Na concepção, o engenheiro de requisitos deve criar uma lista
de pessoas que fornecerão entradas à medida que os requisitos
forem levantados
● Essa lista vai crescer, pois a cada interessado será perguntado
"com quem mais você acha que eu deveria falar?"
Reconhecimento de diversos pontos de vista

● Cada participante contribuirá com informações para
o processo de engenharia de requisitos
● Requisitos podem ser inconsistentes ou conflitantes
● O engenheiro de requisitos deve categorizar as
informações dos interessados e permitir que os
tomadores de decisão escolham um conjunto de
requisitos do sistema internamente consistentes
Trabalho em busca da colaboração

● O engenheiro de requisitos deve identificar áreas de
concordância e áreas de conflito ou inconsistência
Formulação das primeiras questões

● Quem está por trás da solicitação deste trabalho?
● Quem vai usar a solução?
● Qual será o benefício econômico de uma solução
bem-sucedida?
● e outras...
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
Passo 2 - Levantamento
Técnicas de Levantamento/Elicitção: extrair, descobrir requisitos

● Reuniões
● Entrevista
● Leitura de documentos
● Questionários
● Análise de protocolos
● Participação ativa dos usuários em Cenários
● Observações e análise sociais (etinografia)
● Reuso de requisitos
Coleta colaborativa de requisitos

● reuniões entre engenheiros de software e cliente
● para identificar problemas, propor soluções, negociar
abordagens e especificar um conjunto preliminar de
requisitos
Problemas encontrados:
● problema de entendimento: clientes/usuários
○ não sabem o que é realmente necessário
○ têm pouca compreensão das capacidades e limitações do
seu ambiente computacional
○ não têm pleno entendimento do domínio do problema
○ têm dificuldade de informar as necessidades
○ omitem informações que admitem ser "óbvias"
○ especificam requisitos conflitantes
○ etc...
Problemas encontrados:
● problema de volatilidade
○ requisitos mudam ao longo do tempo
● problema de escopo
○ limite mal definido
Gestão de Requisitos
● Solução: coleta dos requisitos de forma organizada

Implantação da Função de Qualidade

● traduz as necessidades do cliente para requisitos técnicos
do software
● Tipos de requisitos segundo Larman
○ funcionais: funcionalidades do sistema
■ Requisitos Evidentes ou Visíveis
■ Requisitos Ocultos
■ Enfeite/Luxo/Decoração
○ não-funcionais: requisitos de qualidade ou atributos do sistema
Implantação da Função de Qualidade

● Tipos de requisitos segundo Pressman
○ requisitos normais: objetivos e metas estabelecidos
durante as reuniões com os clientes
○ requisitos esperados: são implícitos e podem ser tão
fundamentais que o cliente não se refere a eles
explicitamente
○ requisitos excitantes: características que vão além das
expectativas dos clientes e se tornam satisfatório quando
apresentados
Desenvolvimento de Casos de Uso

● "contrato...que descreve o comportamento do sistema sob várias
condições em que o sistema responde a uma solicitação de um dos
seus interessados" (Alistair Cockburn)
● história estilizada sobre como um usuário final interage com o
sistema sob um conjunto específico de circunstâncias
● pode ser um texto narrativo, um delineamento das tarefas ou
interações, uma descrição baseada em gabarito, uma
representação diagramática
Desenvolvimento de Casos de Uso [Jacobson,92]

● Quem são os atores principais e os secundários?
● Quais são as metas dos atores?
● Que tarefas ou funções principais são desempenhadas pelo
ator?
● Que exceções deveriam ser consideradas?
● Que variações na interação dos atores são possíveis?
● Que informações do sistema o ator vai adquirir, produzir ou
modificar?
● Que informações o ator deseja do sistema?
● e outras...
Instalar
Desenvolvimento de software
um Diagrama de Casos Desinstala
Instalador de r software
de Uso SW
Gerenciar os
eventos do
sistema
Casos de Uso serão Configurar
apresentados na o sistema
próxima aula Administrador Otimizar o

do sistema sistema
Produtos do levantamento
● declaração da necessidade e viabilidade
● escopo limitado
● lista de clientes, usuários e outros interessados
● descrição do ambiente técnico do sistema
● lista de requisitos e restrições de domínio
● conjunto de cenários de uso
● protótipos desenvolvidos para definir melhor os requisitos
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
Passo 3 - Elaboração
● Ação de modelagem de análise

○ objetivo: fornecer descrição dos domínios informacional,
funcional e comportamental
● Informações obtidas do cliente na concepção e
levantamento são expandidos e refinados na
elaboração
● Criação e refinamento de cenários que descrevem
como o usuário vai interagir com o sistema
Elementos do modelo de análise

● elementos baseados em cenários
○ ex: diagrama de atividades
● elementos baseados em classe
○ ex: diagrama de classes
● elementos comportamentais
○ ex: diagrama de estado
● elementos orientados a fluxo
○ ex: diagrama de fluxo de dados (DFD)
Padrões de Projeto
● é uma descrição nomeada de um problema e uma
solução, que pode ser aplicado em novos contextos
● Aceleram o desenvolvimento de modelos de análise
● Facilitam a transformação do modelo de análise em um
modelo e de projeto sugerindo padrões
● Ex: características e funções de interfaces de usuários
(http://hillside.net/patterns/)
"A elaboração é boa, mas você tem que saber quando

parar. A chave é descrever o problema de modo que uma
base firme para o projeto seja estabelecida. Se essa fase
se prolongar além desse ponto, o projeto já começou..."
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
Passo 4 - Negociação
● Requisitos devem ser analisados, combinados e/ou

modificados de modo que cada parte alcance algum
grau de satisfação
● São discutidos
○ Conflitos de prioridade
○ Riscos associados
○ Estimativas de esforço de desenvolvimento x Custo
○ Prazos de entrega
Passo 4 - Negociação
Atividades
● identificação dos interessados-chave
● determinação das "condições de ganho" dos
interessados
● negociação das condições de ganho dos interessados
para conciliá-las em um conjunto de condições onde
todos ganham
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
Passo 5 - Especificação
● Deve considerar os acordos feitos na negociação

● Especificação pode ser
○ Documento escrito
○ Modelo gráfico
○ Modelo matemático formal
○ Coleção de cenários de uso
○ Protótipo
○ Combinação dos elementos acima
● Produto de trabalho final produzido pelo engenheiro

de requisitos
● Serve como fundamento das atividades de
engenharia de software subseqüentes
● Descreve a função e o desempenho de um sistema
baseado em computador e as restrições que
governarão o seu desenvolvimento
Balzer e Goldman propõem 8 princípios da boa especificação

1. Separe funcionalidade de implementação
2. É necessária uma linguagem de especificação de sistemas
orientada ao processo
3. A especificação deve abranger o sistema do qual o software é um
componente
4. Uma especificação deve abranger o ambiente no qual o sistema
opera
Balzer e Goldman propõem 8 princípios da boa especificação

5. Uma especificação de sistema deve ser um modelo cognitivo
6. Uma especificação deve ser operacional
7. A especificação do sistema deve ser tolerante com a não
completitude e ser expansível
8. Uma especificação deve ser localizada e fracamente acoplada
Exemplo de formato da Especificação de Requisitos

● I. INTRODUÇÃO
○ Declara as metas e os objetivos do software,
descrevendo-os no contexto do sistema baseado em
computador
● II. DESCRIÇÃO DA INFORMAÇÃO
○ Apresenta uma descrição detalhada do problema que o
software deve resolver

● III. DESCRIÇÃO FUNCIONAL
○ Engloba uma descrição de cada função exigida para resolver
o problema
● IV. DESCRIÇÃO COMPORTAMENTAL

○ Examina a operação do software como uma seqüência de
eventos

● VII. APÊNDICE
○ Traz informações que complementam a especificação
A Especificação pode ser acompanhada de um

PROTÓTIPO executável (ou em papel) e/ou um
MANUAL PRELIMINAR DE USUÁRIO
Quais os passos?
● Concepção
● Levantamento
● Elaboração
● Negociação
Passo 6 - Revisão ou validação
● Avaliar os produtos de trabalho resultantes da

engenharia de requisitos
● Especificação é examinada para garantir que
○ requisitos do software tenham sido declarados de modo não
ambíguo
○ inconsistência, omissões e erros tenham sido detectados e
corrigidos
○ produtos estejam de acordo com as normas estabelecidas
Passo 6 - Revisão ou validação
● Principal mecanismo
○ revisão técnica formal
● Equipe de revisão
○ engenheiros de software, clientes, usuários, e outros
interessados
2. Gestão de Requisitos
● Atividades que ajudam a equipe de projeto a
identificar, controlar e rastrear requisitos e
modificações de requisitos ao longo do projeto
● Tabelas são criadas para facilitar o entendimento de
como uma modificação feita em um requisito afetará
os aspectos do sistema
● Identificação
○ um identificador para cada requisito
● Tabelas de rastreamento
○ tabela de rastreamento de característica
■ como os requisitos se relacionam com características
importantes do sistema observáveis pelo usuário
○ tabela de rastreamento de fontes

■ identifica as fontes de cada requisito
● Tabelas de rastreamento
○ tabela de rastreamento de dependência
■ indica como os requisitos estão relacionados uns aos outros
○ tabela de rastreamento de subsistemas
■ caracteriza os requisitos pelos subsistemas que eles
governam
○ tabela de rastreamento de interface
■ mostra como os requisitos se relacionam com as interfaces do
sistema
3. Ferramentas de Software
Ferramentas de Software
● Ferramentas apóiam a obtenção, modelagem, gestão
e validação de requisitos
● Constroem uma variedade de modelos gráficos (ex:
UML) para representar aspectos informacionais,
funcionais e comportamentais de um sistema
● Modelos formam a base para outras atividades do
processo de software
Ferramentas de Software
● Lista de ferramentas de engenharia de requisitos
○ http://www.volere.co.uk/tools.htm
● Ferramentas para gestão de requisitos
○ EasyRM, Cybernetic Inteligence GmbH
○ OnYourMark Pro, Omni-Vista
○ Rational RequisitePro, Rational Software
○ RTM, Integrated Chipware
RESUMO
Resumo
● É necessário entender os requisitos antes de
começar o projeto e construção de um sistema
● Funções de engenharia de requisitos
○ concepção, levantamento, elaboração, negociação,
especificação, validação e gestão
Resumo
● Logo que a Revisão for concluída, a Especificação de
Requisitos de Software é "assinada" pelo cliente e
pelo desenvolvedor
● A especificação torna-se mais um "contrato" de
desenvolvimento de software
Resumo
● Mudanças solicitadas depois que a especificação for
concluída serão consideradas, porém cada mudança
posterior pode aumentar o custo e/ou alongar o
prazo de entrega
● Mesmo com os melhores procedimentos de revisão
em andamento, uma série de problemas de
especificação ainda persiste
Próximas ● Métodos, técnicas e
ferramentas de análise
aulas ● Planejar e elaborar
casos de uso
● Elaborar diagrama de
sequência
● Elaborar modelo
conceitual
Principal ● Pressman, R.S.
Engenharia de Software,
Referência McGraw-Hill, 2006.

APS Aula02 PressmanEngReq

Enviado por

Dados do documento

Título original

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

APS Aula02 PressmanEngReq

Enviado por

Direitos autorais:

Formatos disponíveis

Análise e Projeto de Software

Profa. Alessandra Alaniz Macedo

● É uma atividade da engenharia de software

engenharia (análise) de sistemas

● Requisitos são a descrição das necessidades de um

● Desaﬁo: deﬁnir requisitos de maneira não-ambígua

Entendimento do problema por escrito

Concepção Elaboração Especiﬁcação

Passos para iniciar a engenharia de requisitos

Identiﬁcação dos interessados

Reconhecimento de diversos pontos de vista

Trabalho em busca da colaboração

Formulação das primeiras questões

Técnicas de Levantamento/Elicitção: extrair, descobrir requisitos

Coleta colaborativa de requisitos

● Solução: coleta dos requisitos de forma organizada

Implantação da Função de Qualidade

Implantação da Função de Qualidade

Desenvolvimento de Casos de Uso

Desenvolvimento de Casos de Uso [Jacobson,92]

próxima aula Administrador Otimizar o

● Ação de modelagem de análise

Elementos do modelo de análise

"A elaboração é boa, mas você tem que saber quando

● Requisitos devem ser analisados, combinados e/ou

● Deve considerar os acordos feitos na negociação

● Produto de trabalho ﬁnal produzido pelo engenheiro

Balzer e Goldman propõem 8 princípios da boa especiﬁcação

Balzer e Goldman propõem 8 princípios da boa especiﬁcação

Exemplo de formato da Especiﬁcação de Requisitos

Exemplo de formato da Especiﬁcação de Requisitos

● IV. DESCRIÇÃO COMPORTAMENTAL

Exemplo de formato da Especiﬁcação de Requisitos

A Especiﬁcação pode ser acompanhada de um

● Avaliar os produtos de trabalho resultantes da

○ tabela de rastreamento de fontes

Você também pode gostar