1-Engenharia - de - Requisitos 2020

ENGENHARIA DE SOFTWARE
ENGENHARIA DE REQUISITOS
CONCEITOS
GERALMENTE O CICLO DE VIDA DE UM SOFTWARE
PODE SER DIVIDIDO EM 7 FASES
ENGENHARIA ANÁLISE PROJETO CODIFICAÇÃO TESTE IMPLANTA- MANUTENÇÃO

DOS DOS DO DO DO ÇÃO DO DO
REQUISITOS REQUISITOS SOFTWARE SOFTWARE SOFTWARE SOFTWARE SOFTWARE
REQUISITO:
❑ Condição necessária para obtenção de certo objetivo,
ou para preenchimento de certo fim; quesito
❑ Exigência necessária para certos efeitos
EXTRAÇÃO E ESPECIFICAÇÃO DE REQUISITOS
Estudos da área
Situação de alvo e seus
processos, Dados da
Interesse entrevistas e Atividade
questionários com
os usuários
EXTRAÇÃO
ESPECI
FICAÇÃO
Especificação de Requisitos
(Funcionais e Não Funcionais)
Modelo Anterior da
Novo Modelo da Atividade (se houver)
Atividade
Extração ou Elicitação
EXTRAÇÃO E ESPECIFICAÇÃO DE REQUISITOS de Requisitos
Estudos da área
processos, Dados da
questionários com
os usuários
EXTRAÇÃO
ESPECI
FICAÇÃO
Modelo Anterior da
Atividade
PRINCIPAIS FONTES DE REQUISITOS
❑ Clientes (stakeholders)
❑ Processo alvo
❑ Metas e restrições da organização e do meio
ambiente (concorrência, legislação etc.) onde se
insere a organização
❑ Estudo de documentos usados no processo
❑ Estudo do sistema antigo (se existir)
PRINCIPAIS FONTES DE REQUISITOS
TIPOS DE REQUISITOS
❑ FUNCIONAIS:
❑ Funcionalidade do produto DECISÃO FINAL DO USUÁRIO
❑ Processos da área alvo
TIPOS DE REQUISITOS
❑ NÃO FUNCIONAIS:
❑ Desempenho, Portabilidade
❑ Manutenibilidade, Segurança, etc.
❑ Compatibilidade com a plataforma DECISÃO FINAL NOSSA
❑ Restrições da legislação
❑ Padrões da instalação
❑ Objetivos econômicos e técnicos
TÉCNICAS DE EXTRAÇÃO (ELICITAÇÃO) DE
REQUISITOS
❑ INFORMAIS:
❑Entrevistas
❑Questionários
❑Estudo dos Processos
❑Estudo dos Documentos
❑Estudo de SI atual (se houver)
❑Pieces
❑Brainstorming
❑JAD – Joint Application Development
❑FAST - Facilitaded Application Specification Techniques
❑METHOD – Performance Resource, Inc.
❑etc.
TÉCNICAS DE EXTRAÇÃO (ELICITAÇÃO) DE
REQUISITOS
❑ FORMAIS:
❑Modelagem conceitual de dados, funcionalidade, componentes,
etc.
❑Prototipação exploratória de requisitos
❑Métodos formais
❑etc
EXTRAÇÃO DE REQUISITOS
❑ A extração de requisitos não é um processo
totalmente formal (a entrada do processo não é
formal), logo não permite sua automação por meio de
ferramentas CASE
❑ O desenvolvedor deve contar com técnicas de
Entrevista, Questionário, Mapeamento (e
entendimento) do Processo-Alvo e conhecimento de
Psicologia Comportamental e das Organizações
❑ Para produtos complexos, deve-se usar o principio da
decomposição
❑ Em produtos complexos, a extração de requisitos é
uma fase imprecisa e difícil, além de não ser formal.
❑ Face a essas dificuldades, como fazer para atender a
norma ISO 9000-3 ?
❑ Completo
❑ Correto
❑ Não ambíguo
❑ Não redundante
❑ Sem características de implementação
EXTRAÇÃO E ESPECIFICAÇÃO DE REQUISITOS
Estudos da área
processos, Dados da
questionários com
os usuários
EXTRAÇÃO
ESPECI
FICAÇÃO
Modelo Anterior da
Atividade
Especificação de
EXTRAÇÃO E ESPECIFICAÇÃO DE REQUISITOS Requisitos
Estudos da área
processos, Dados da
questionários com
os usuários
EXTRAÇÃO
ESPECI
FICAÇÃO
Modelo Anterior da
Atividade
ESPECIFICAÇÃO DE REQUISITOS
❑Seu objetivo é fornecer representações dos “Dados" e das
“Funcionalidades" que:
❑Sirvam para a comunicação entre desenvolvedores e
usuários;
❑Possam ser transformadas (traduzidas) em "projeto” de
dados, arquitetura, interface e procedimentos;
❑Sirvam como um meio de determinar a qualidade do
software.
❑Permitam sua validação final (por parte do usuário).
PRINCÍPIOS DE ESPECIFICAÇÃO DE REQUISITOS
1. Os requisitos devem ser especificados sem características de
implementação, ou seja: qual a funcionalidade desejada e
não como ela será obtida (separar funcionalidade de
implementação) Escada em espiral.
2. Cada requisito exige uma especificação.
3. Use uma linguagem de especificação de sistema Orientada a
Processos (entradas, processo/atividades, saídas).
4. A Especificação deve abranger todo o escopo do qual o
software é um componente.
5. A Especificação deve abranger o ambiente no qual o sistema
será usado.
6. Uma Especificação de Sistema deve ser um modelo cognitivo
(transmite conhecimentos).
7. Especifique o que deve ser feito e o que não deve ser feito
(outros aspectos do projeto que estarão a cargo do usuário
ou de outra empresa)
8. Uma Especificação deve ser operacional (útil, possível de ser
usada nas fases seguintes).
9. A especificação do sistema deve ser tolerante a não-
completeza (desde que o Modelo de Ciclo de Vida escolhido
seja Evolucionário) e ser expansível.
10.Uma especificação deve ser clara o suficiente para permitir
sua implementação (transformar-se em modelos) e sirva
para a posterior validação do produto desenvolvido.
❑ Especificação de Requisitos é o documento fundamental da
Engenharia de Software de um novo produto, pois define O
QUE deverá ser projetado e construído;
❑ Permite que o requisito seja gerenciável (planejamento,
controle e feedback);
❑ A revisão dos requisitos pelos desenvolvedor e usuários, é
fundamental para garantir que todos tenham a mesma
“percepção” do sistema que será desenvolvido.
❑ Como a Descrição Funcional (parte da Especificação de
Requisitos) é um documento de comunicação entre os
desenvolvedores (equipe) e entre desenvolvedores e
usuários, deve ser um documento inteligível, preciso,
completo, consistente e sem ambiguidades.
ATIVIDADES DA ENGENHARIA DE REQUISITOS
(EXTRAÇÃO E ESPECIFICAÇÃO DOS REQUISITOS)
❑ Procedimentos:
❑ Entender o domínio do problema e da área de aplicação
do produto
❑ Levantar as questões fundamentais (anteprojeto) (A SEGUIR)
❑ Analisar os requisitos (problema) e as possíveis soluções
❑ Organizar requisitos por afinidade e por prioridade
❑ Resolver inconsistências, conflitos e descobertas de
omissões.
❑ Procedimentos:
❑ Entender o domínio do problema e da área de aplicação
do produto
❑ Levantar as questões fundamentais (anteprojeto) (A SEGUIR)
❑ Analisar os requisitos (problema) e as possíveis soluções
❑ Organizar requisitos por afinidade e por prioridade
❑ Resolver inconsistências, conflitos e descobertas de
omissões.
❑ Questões fundamentais (anteprojeto)

1. O problema requer solução informatizada ?
Em caso positivo, quais as opções disponíveis?
❑ Computação de usuário final
❑ Produto similar já existe em outro departamento ou
filial ? (Benchmarking)
❑ Adquirir produto pronto (pacote)
❑ Desenvolver produto específico (in-house ou
terceirizado)

2. Pré-estudo de viabilidade econômica
❑ Análise Custo X Benefício
❑ Real necessidade
❑ Quantificar o benefício
❑ Exceções:
❑ Mandatório (Prazo)
❑ Desenvolvimento já planejado - PDI (Plano Diretor de
Informática)

3. Pré-estudo de viabilidade técnica
❑ Disponibilidade de equipe
❑ Disponibilidade das tecnologias desejadas
❑ Existência de Plataforma necessária
❑ Integração com sistemas legados
❑ Pré-levantamento de volumes
❑ Habilidades que auxiliam na Extração de Requisitos
❑ Facilidade de negociação (flexibilidade)

❑ Hábito de reflexão sobre problemas
❑ Hábito da observação
❑ Técnicas de tomada de decisão
❑ Criatividade
❑ Disposição de atender as necessidades do usuário e até de
exceder as expectativas
❑ Fatores que dificultam a Extração de Requisitos
❑ Dificuldade de Comunicação entre usuários e

desenvolvedores
❑ Falta de conhecimentos dos usuários sobre suas reais
necessidades
❑ Idem sobre o processo (processo novo/usuário novo)
❑ Falta de conhecimentos dos desenvolvedores sobre o
domínio do problema
❑ Desenvolvedores negligenciam necessidades dos usuários,

privilegiando suas próprias ideias sobre “como o produto
deveria ser”
❑ Dificuldade do usuário tomar decisões
❑ Usuário não representativo da comunidade de usuários do
sistema (Stakeholders)
❑ Problemas comportamentais (relacionamento) entre
usuários e desenvolvedores
❑ Dificuldade em obter a participação dos usuários durante

todo o processo (tempo, hierarquia, resistência,
desinteresse, etc.)
❑ O Processo-alvo ou o produto desejado contém aspectos
técnicos de grande complexidade
(REVISÃO E VALIDAÇÃO DOS REQUISITOS)
❑ Revisão e Validação:
❑ Atividade realizada conjuntamente com desenvolvedores e

usuários
❑ Fundamental para garantir que ambos (usuários e
desenvolvedores) tenham a mesma “percepção” do
produto a ser gerado.
(REVISÃO E VALIDAÇÃO DOS REQUISITOS)
❑ Revisar:
❑ Avaliar, Revisar e Corrigir toda a documentação produzida
na extração de requisitos.
❑ Validar:
❑ Verificar (validar) se os requisitos são completos e
condizentes com suas necessidades e desejos para o
produto a ser desenvolvido. Só o usuário pode validar.
(ESTABELECER CONTRATO)
❑ Definir claramente (entre usuário e desenvolvedor):
❑ Objetivos do contrato
❑ Representantes de ambas as partes para atividades
específicas ao longo do desenvolvimento.
❑ Responsabilidades em todas as fases, inclusive no que
se refere a subcontratados.
❑ Possíveis contingências ou riscos.
❑ Acesso a instalações, rede, sistemas, etc. na fase de
testes no ambiente de produção (instalações do cliente).
❑ Informações reservadas que devem ser protegidas.

❑ Critérios para aceitação do produto em cada fase e na
validação final.
❑ Propriedade do código fonte.
❑ Caso o código fonte seja de propriedade do
desenvolvedor, prever a condição em que a empresa
desenvolvedora encerre suas atividades (custódia da
cópia mestre).
❑ Responsabilidades por eventuais manutenções

(especificando cada tipo de manutenção).
❑ Prazos, produtos a serem entregues e correspondentes
pagamentos (milestones).
❑ Tratamento de eventuais alterações durante o
desenvolvimento.
❑ Tratamento de eventuais alterações após a conclusão do
desenvolvimento.
❑ Recursos, ferramentas e itens de software a serem

fornecidos pelo “comprador” (usuário).
❑ Normas, procedimentos e legislação aos quais o produto
deve estar em conformidade.
❑ Mídia de distribuição do produto, número de cópias,
forma e tipo da documentação.
❑ Fornecimento de eventuais cópias da mídia e da
documentação e qual o período dessa obrigação.
❑ Responsabilidades específicas quanto ao ambiente

operacional do usuário, no caso de teste no ambiente de
produção.
❑ Idem quanto a pessoal do cliente disponível para testes
em ambiente de produção, horário de trabalho e tempo
estimado para a atividade.
(ELABORAR PLANO DE PROJETO)
❑ O plano de projeto é essencial para o sucesso de um projeto

de software e o gerente de projeto não se separa dele até o
encerramento do mesmo.
❑ O plano de projeto contém um conjunto de informações que

permite ao gerente de projeto não apenas executar o projeto,
mas também monitorar seu progresso e verificar se o
executado está em conformidade com o planejado.
❑ O plano de projeto é um dos documentos produzidos na

elaboração de um projeto.
❑ Ele funciona como:
❑ Um integrador entre diversas ações do projeto;
❑ Um mecanismo de comunicação para os stakeholders (isto
é, as partes interessadas do projeto);
❑ Captura e documenta a evolução do projeto à medida que
ele vai sendo executado e novas informações vão sendo
disponibilizadas.
❑ Durante a execução do plano de projeto, o gerente de projeto

se apoia nesse documento para tomar ações corretivas
visando alcançar o conjunto de metas planejadas em
concordância com o que foi definido no plano.
❑ O plano de projeto deve conter:

❑ Como as mudanças serão monitoradas e controladas;
❑ Milestones com datas de pontos estratégicos para
avaliação do projeto;
❑ Baselines para cronograma, custo e qualidade;
❑ Calendário para recursos utilizados;
❑ Mecanismos de comunicação para os stakeholders;
❑ Definição de revisões para resolução de pontos em aberto
e/ou pendentes;
❑ O plano de projeto é determinante para o sucesso de um

projeto:
❑ Ele identifica quais artefatos deverão ser entregues e

quando
❑ Informa os recursos necessários para realizar as entregas

de artefatos, indicando as dependências existentes para
essas entregas
ENGENHARIA DE REQUISITOS MODELO DE ESPECIFICAÇÃO DE REQUISITOS
1. INTRODUÇÃO
1.1 Identificação e Contexto
Referência: Sigla identificadora do projeto
Nome: Autoexplicativo
Descrição: Descrever sucintamente os principais objetivos ou
funcionalidades do sistema proposto.
1.2 Propósito e Motivação

Descrever em poucas linhas o propósito e / ou motivação que
levaram à identificação da necessidade de desenvolvimento do
sistema.
1.3 Escopo
Descrever, por meio de texto curto e sucinto, a abrangência
(áreas ou unidades da organização) e dar uma ideia aproximada
da complexidade do sistema, descrevendo:
o Os dados relevantes (macro informações) que o sistema usa
e produz;
o As grandes fontes/destino desses dados (origem e destino das
informações);
o Os principais eventos ligados aos processos, rotinas e fluxo de
trabalho associados que serão tratados (reconhecidos) pelo
sistema e que serão automatizados.
1.3 Escopo
Para que este item do documento seja claro, é
imprescindível que o desenvolvedor consiga identificar,
por meio dele:
o Os atores (instâncias, setores, outros sistemas
internos e externos) que representam os elementos
que interagem com o SI que será construído, ou seja
o ambiente no qual o sistema em análise está
inserido;
o Fonte e Destino das informações.
1.4 Usuário-Chave
Definir o usuário-chave (dono das informações) e endereços de
contato. Se forem diversos usuários-chave envolvidos (sistema
misto), indicar os dados por meio de uma lista.
1.5 Definições, siglas ou abreviaturas

Documentar as definições, siglas, abreviaturas ou acrônimos,
alimentando e mantendo o tesauro funcional da organização e
uniformizando o vocabulário usado no sistema.
1.4 Usuário-Chave
SONAR = SOund +
misto), indicar os dados por meio de uma lista. NAvigation + Ranging

1.4 Usuário-Chave
Vocabulário controlado e dinâmico
de descritores, relacionados
semântica e genericamente, que
cobre de forma extensiva um ramo
misto), indicar os dados por meio de uma lista. específico de conhecimento

1.6 Referências
Listar as Referências (documentos) que deram origem
ou serão importantes para a execução do projeto, como
legislação, normas, procedimentos, circulares etc.
2. DESCRIÇÃO DO SISTEMA
O modelo descritivo é a base que permite a definição
de um primeiro nível de refinamento e detalhe do
sistema.
Trata-se de uma descrição das rotinas, fluxos e práticas
de trabalho que se deseja automatizar (eventos –
funcionalidade) e não à solução que será dada.
2. DESCRIÇÃO DO SISTEMA (cont.)

Deve ser escrito de forma narrativa, sem características
de implementação, com linguagem de domínio dos
usuários. Deve oferecer ao desenvolvedor, os subsídios
necessários para a compreensão dos requisitos
funcionais do sistema, permitindo análise das possíveis
formas de solução.
Deverá descrever regras/rotinas de como são
processadas e tratadas as informações (ordenada em
uma sequência lógica), em que periodicidades são
executadas, quais são as informações efetivamente
utilizadas e produzidas durante as rotinas do trabalho
que se deseja automatizar por meio de um SI.
3. REQUISITOS
3.1 REQUISITOS FUNCIONAIS
RF 1 – O sistema deve ...
RF 1 – ...
3.2 REQUISITOS NÃO FUNCIONAIS
RNF 1- O sistema deve ...
RNF 1- ...
4. RESTRIÇÕES INICIAIS
Listar as restrições (legais, recursos materiais e humanos,
tecnológicos etc.) que poderão afetar o desenvolvimento do
SI. Servirá de fonte para que possam ser identificados os
riscos associados ao projeto, permitindo estabelecer um
primeiro esboço da estratégia de mitigação destes riscos.
5. ELABORADO POR / VALIDADO POR:

Identificar as pessoas que elaboraram o documento de
especificação de requisitos (usuários e desenvolvedores)
bem como os usuários que validaram seu conteúdo.

1-Engenharia - de - Requisitos 2020

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

1-Engenharia - de - Requisitos 2020

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE SOFTWARE

PODE SER DIVIDIDO EM 7 FASES

ENGENHARIA ANÁLISE PROJETO CODIFICAÇÃO TESTE IMPLANTA- MANUTENÇÃO

❑ Questões fundamentais (anteprojeto)

❑ Questões fundamentais (anteprojeto)

❑ Questões fundamentais (anteprojeto)

❑ Habilidades que auxiliam na Extração de Requisitos

❑ Facilidade de negociação (flexibilidade)

❑ Fatores que dificultam a Extração de Requisitos

❑ Dificuldade de Comunicação entre usuários e

❑ Fatores que dificultam a Extração de Requisitos

❑ Desenvolvedores negligenciam necessidades dos usuários,

❑ Fatores que dificultam a Extração de Requisitos

❑ Dificuldade em obter a participação dos usuários durante

❑ Atividade realizada conjuntamente com desenvolvedores e

❑ Definir claramente (entre usuário e desenvolvedor):

❑ Definir claramente (entre usuário e desenvolvedor):

❑ Informações reservadas que devem ser protegidas.

❑ Definir claramente (entre usuário e desenvolvedor):

❑ Responsabilidades por eventuais manutenções

❑ Definir claramente (entre usuário e desenvolvedor):

❑ Recursos, ferramentas e itens de software a serem

❑ Definir claramente (entre usuário e desenvolvedor):

❑ Responsabilidades específicas quanto ao ambiente

❑ O plano de projeto é essencial para o sucesso de um projeto

❑ O plano de projeto contém um conjunto de informações que

❑ O plano de projeto é um dos documentos produzidos na

❑ Durante a execução do plano de projeto, o gerente de projeto

❑ O plano de projeto deve conter:

❑ O plano de projeto é determinante para o sucesso de um

❑ Ele identifica quais artefatos deverão ser entregues e

❑ Informa os recursos necessários para realizar as entregas

1.2 Propósito e Motivação

1.5 Definições, siglas ou abreviaturas

1.5 Definições, siglas ou abreviaturas

1.5 Definições, siglas ou abreviaturas

2. DESCRIÇÃO DO SISTEMA (cont.)

5. ELABORADO POR / VALIDADO POR:

Você também pode gostar