ESW - Aula8 - Engenharia de Requisitos

Engenharia de
Software
Aula8 – Engenharia de Requisitos
O GRUPO DA DISCIPLINA
1
ENGENHARIA DE REQUISITOS
Tratados pela
Documentação,
Garantia da
Qualidade e
Gestao de
Configuração
2
Levantamento de Requisitos:
Nesta fase, os usuários, clientes e especialistas de
domínio são identificados e trabalham junto com os
engenheiros de requisitos para entender a
organização, o domínio da aplicação, os processos de
negócio a serem apoiados, as necessidades que o
software deve atender e os problemas e deficiências
dos sistemas actuais.
Os diferentes pontos de vista dos participantes do processo,
bem como as oportunidades de melhoria, restrições existentes
e problemas a serem resolvidos devem ser levantados.
3
Levantamento de Requisitos - Cont
O levantamento de requisitos é uma actividade de
descoberta de informações.
Diversas fontes podem ser pesquisadas, dentre elas
material bibliográfico, manuais de funcionamento da
organização, documentos da organização e as
pessoas envolvidas, dentre elas especialistas do
domínio, clientes e usuários.
É uma actividade complexa que não se resume
somente a perguntar às pessoas o que elas desejam e
também não é uma simples transferência de
conhecimento.
4
Algumas técnicas que podem ser empregadas:
entrevistas, questionários, prototipação, investigação
de documentos, observação, dinâmicas de grupo etc.
Importante:
 Enfoque em uma visão do cliente / usuário.
 Lembre-se que ainda não se está procurando
definir a estrutura interna do sistema, mas sim
procurando saber que funcionalidades o
sistema deve oferecer ao usuário e que
restrições elas devem satisfazer.
5
Quatro dimensões devem ser consideradas nesta
fase:
1. Entendimento do domínio da aplicação:
entendimento geral da área na qual o software
a ser desenvolvido está inserido;
2. Entendimento do problema: entendimento dos
detalhes do problema específico a ser
resolvido com o auxílio do sistema a ser
desenvolvido;
6
3. Entendimento do negócio: entender como o
sistema afectará a organização e como contribuirá
para que os objetivos do negócio e os objetivos
gerais da organização sejam atingidos;
4. Entendimento das necessidades e das restrições
dos interessados: entender as demandas de apoio
para a realização do trabalho de cada um dos
interessados no sistema, entender os processos de
trabalho a serem apoiados pelo sistema e o papel
de eventuais sistemas existentes na execução e
condução dos processos de trabalho
7
Analise de Requisitos:
Esta fase visa estabelecer um conjunto acordado de
requisitos consistentes e sem ambiguidades, que
possa ser usado como base para as actividades
subsequentes do processo de software.
Para tal, diversos tipos de modelos são construídos.
Assim, a análise de requisitos é essencialmente uma
actividade de modelagem.
A análise de requisitos pode incluir, ainda, negociação entre
usuários para resolver conflitos detectados.
8
Analise de Requisitos (Cont):

 Enfoca a estrutura interna do sistema (procura
definir o que o sistema tem de ter internamente
para tratar adequadamente os requisitos
levantados).
 É uma actividade de construção de modelos.
 Um modelo é uma representação de alguma coisa
do mundo real, uma abstração da realidade, e,
portanto, representa uma seleção de
características do mundo real relevantes para o
propósito do sistema em questão
9

Modelos são fundamentais no desenvolvimento de
sistemas. Tipicamente eles são construídos para:
 enfocar os aspectos chave, em detrimento de
detalhes irrelevantes;
 possibilitar o estudo do comportamento do
sistema;
 facilitar a comunicação entre membros da
equipe de desenvolvimento e clientes e
usuários;
10

 possibilitar a discussão de correções e
modificações com o usuário;
 servir como base para a tomada de decisão;
11

No desenvolvimento de sistemas, há duas
perspectivas principais:
 Perspectiva estrutural: tem por objectivo
descrever as informações que o sistema deve
representar e gerir. Provê uma visão estática
das informações que o sistema necessita tratar.
Ex.: diagramas de classes e modelos ER.
12

No desenvolvimento de sistemas, há duas
perspectivas principais:
 Perspectiva comportamental: visa especificar
as acções (funcionalidades / serviços) que o
sistema deve prover, bem como o
comportamento de certas entidades do modelo
estrutural em relação a essas ações.
Ex.: diagramas de casos de uso, diagramas de
estados, etc.
13

Para realizar a Análise de Requisitos, é preciso
escolher o paradigma de desenvolvimento a ser
seguido.
Paradigmas de desenvolvimento estabelecem a

forma de se ver o mundo e, portanto, definem as
características básicas dos modelos a serem
construídos.
14
Por exemplo:
Paradigma Estruturado: adopta uma visão de
desenvolvimento baseada em um modelo entrada-
processamento-saída. No paradigma estruturado,
os dados são considerados separadamente das
funções que os transformam e a decomposição
funcional é usada intensamente.
Paradigma Orientado a Objectos: parte do
pressuposto que o mundo é povoado por objectos,
ou seja, a abstração básica para se representar as
coisas do mundo são os objectos
15
Documentação de Requisitos:
Esta fase é a actividade de representar os resultados
da Engenharia de Requisitos em um documento (ou
conjunto de documentos), contendo os requisitos do
software e os modelos que os especificam.
16
Os requisitos devem ser registrados em um
Documento de Definição de Requisitos
17
Estrutura do Documento:
 Introdução (contém a organização do documento)
 Propósito do Sistema (contém o propósito do
sistema descrito de forma bastante objectiva –
tipicamente, em um parágrafo)
 Descrição do Minimundo (visão geral do
domínio, do problema a ser resolvido, bem como as
principais ideias do cliente sobre o sistema a ser
desenvolvido)
 Requisitos de Usuário (requisitos de usuário em
linguagem natural)
18
Documentação de Requisitos: Exemplo
Sistema de Video Locadora
Requisitos Funcionais (o que o sistema deve fazer?)
Identificador Descricao Prioridade Req Relacionados
RF01 O Sistema deve registrar locacoes, Alta
indicando o nome e identificacao do
cliente e os itens locados bem como a
data e o valor da locacao e a data de
devolucao prevista de cada item
RF02 O Sistema deve registrar a reserve de Media
filmes a clients, permitindo indicar
ainda o tipo de midia desejado
19
Regras de Negócio (regras que devem ser obedecidas pelo
sistema)
Identificador Descricao Prioridade Req Relacionados
RN01 O Sistema deve permitir que sejam Media

dados descontos nas locacoes, bem como
que sejam ampliados os prazos de
devolucao de itens em funcao da politica
da empresa.
RN02 O Sistema deve manter o historico de Alta

locacoes e portando, clientes que tenham
feito locacoes nao poderao ser excluidos
20
Requisitos Não Funcionais (segurança, portabilidade,
desempenho, usabilidade, interoperabilidade,…
Ident Descricao Prioridade Escopo Prioridad Req Relacionados
e
RNF O Sistema deve controlar o acesso Seguranca Sistema Alta
01 as funcionalidades. de Acesso
Funcionalidades para controlar o
acervo da locadora devem ser
restritas a administradores.
Funcionalidades de atendimento a
clientes, devem estar restritas a
atendentes.
Funcionalidades de consulta ao
acervo devem estar disponiveis na
Internet
21
Requisitos Não Funcionais (segurança, portabilidade,
desempenho, usabilidade, interoperabilidade,…
Ident Descricao Prioridade Escopo Prioridad Req Relacionados
e
RNF O Sistema deve permitir que a Portabilidad Funcionali Media
02 consulta ao acervo deve estar e dade
disponivel pela Internet a partir
dos principais navegadores
disponiveis no mercado
RNF No Sistema os itens devem ser Usabilidade Funcionali Alta

03 identificados por um codigo de dade
barras sendo possivel a leitura dos
mesmos usando dispositivos de
leitores de codigo de barras
22
Usuarios de um Documento de Requisitos:
Clientes do Sistema - especificam os requisitos e os

leem para conferir se satiafazem suas necessidades
Gestores – usam o documento de requisitos para
planificar uma proposta para o desenvolvimento do
Sistema e planear o seu processo de desenvolvimento
Engenheiros do Sistema – usam os requisitos para
compreender qual o Sistema deve ser desenvolvido.
Engenheiros de Teste do Sistema – usam os requisitos
para desenvolver testes de validacao do Sistema.
Engenheiros de manutencao do Sistema – usam os
requisitos para entender o Sistema e as relacoes entre
suas partes. O GRUPO DA DISCIPLINA
23
Verificação e Validação de Requisitos:

As actividades de Verificação & Validação (V&V)
devem ser iniciadas o quanto antes no processo de
desenvolvimento de software, pois quanto mais tarde
os defeitos são encontrados, maiores os custos
associados à sua correção.
Uma vez que os requisitos são a base para o
desenvolvimento, é fundamental que eles sejam
cuidadosamente avaliados. Assim, os documentos
produzidos durante a actividade de documentação de
requisitos devem ser submetidos à verificação e à
validação. O GRUPO DA DISCIPLINA
24

• O objetivo da verificação é assegurar que o
software esteja sendo construído de forma
correta.
• A verificação de requisitos avalia se os requisitos
estão sendo tratados de forma correcta, de acordo
com padrões previamente definidos, sem conter
requisitos ambíguos, incompletos ou, ainda,
requisitos incoerentes ou impossíveis de serem
testados.
25

• O objetivo da validação é assegurar que o
software que está sendo desenvolvido é o
software correto, ou seja, assegurar que os
requisitos, e o software deles derivado, atendem
ao uso proposto.
• A validação diz respeito a avaliar se os requisitos
do sistema estão correctos, ou seja, se os
requisitos e modelos documentados atendem às
reais necessidades de usuários e clientes.
26

• No caso de requisitos, a verificação é feita,
sobretudo, em relação à consistência entre
requisitos e modelos e à conformidade com
padrões organizacionais de documentação de
requisitos.
• Já a validação tem de envolver a participação de
usuários e clientes, pois somente eles são capazes
de dizer se os requisitos atendem aos propósitos
do sistema.
27

Nas actividades de V&V de requisitos, examinam-se
os documentos de requisitos para assegurar que:
(i) todos os requisitos do sistema tenham sido
declarados de modo não-ambíguo,
(ii) as inconsistências, conflitos, omissões e erros
tenham sido detectados e corrigidos,
(iii) os documentos estão em conformidade com
os padrões estabelecidos e
(iv) os requisitos realmente satisfazem às
necessidades dos clientes e usuários.
28
Em outras palavras, idealmente, um requisito, seja
ele funcional ou não funcional, deve ser:
 Completo: o requisito deve descrever
completamente a funcionalidade a ser entregue
(no caso de requisito funcional) ou a restrição a
ser considerada (no de requisito não funcional).
Ele deve conter as informações necessárias para
que o desenvolvedor possa projetar, implementar
e testar essa funcionalidade ou restrição.
 Correcto: cada requisito deve descrever
exactamente a funcionalidade ou restrição a ser
incorporada ao sistema
29

 Consistente: o requisito não deve ser ambíguo ou
conflitar com outro requisito.
 Realista: deve ser possível implementar o
requisito com a capacidade e com as limitações do
sistema e do ambiente de desenvolvimento.
 Necessário: o requisito deve descrever algo que o
cliente realmente precisa ou que é requerido por
algum fator externo ou padrão da organização.
 Passível de ser priorizado: os requisitos devem
ter ordem de prioridade para facilitar o
gerenciamento durante o desenvolvimento do
sistema. O GRUPO DA DISCIPLINA
30

 Verificável e passível de confirmação: deve ser
possível desenvolver testes para verificar se o
requisito foi realmente implementado.
 Rastreável: deve ser possível identificar quais
requisitos foram tratados em um determinado
artefato, bem como identificar que produtos foram
originados a partir de um requisito
31
Gestão de Requisitos:
Essa fase se preocupa em gerir as mudanças nos
requisitos já acordados, manter uma trilha dessas
mudanças e gerir os relacionamentos entre os
requisitos e as dependências entre requisitos e outros
artefactos produzidos no processo de software, de
forma a garantir que mudanças nos requisitos sejam
feitas de maneira controlada e documentada.
32
Mudanças nos requisitos ocorrem ao longo de todo o
processo de software, desde o levantamento e análise
de requisitos até durante a operação do sistema.
Elas são decorrentes de diversos factores, tais como:
 descoberta de erros,
 omissões,
 conflitos e inconsistências nos requisitos,
 melhor entendimento por parte dos usuários de
suas necessidades,
 problemas técnicos,
33
 de cronograma ou de custo,
 mudança nas prioridades do cliente,
 mudanças no negócio,
 aparecimento de novos competidores,
 mudanças econômicas,
 mudanças na equipe,
 mudanças no ambiente onde o software será
instalado e
 mudanças organizacionais ou legais.
34
O processo de gerência de requisitos envolve as
actividades que ajudam a equipe de desenvolvimento
a identificar, controlar e rastrear requisitos e gerir
mudanças de requisitos em qualquer momento ao
longo do ciclo de vida do software.
Os principais objetivos desse processo são
 Gerir alterações nos requisitos acordados.
 Gerir relacionamentos entre requisitos.
 Gerir dependências entre requisitos e outros
artefactos produzidos durante o processo de
software
35
REFERÊNCIAS BIBLIOGRÁFICAS
 [3] Pressman, Roger (2006). Engenharia de

Software. New York: McGraw Hill.
 [4] Sommerville, Ian (2007). Engenharia de Software,
8ª. São Paulo: Pearson Addison-Wesley.
 [10]Craig Larman - Utilizando UML e Padrões - Um
Guia para a Análise e Projeto Orientados a Objetos -
Ed. Bookman o Schneider, G. e Winters J. - Applying
Use Cases - Addison-Wesley.
 http://www.desenvolvimentoagil.com.br/xp
36

ESW - Aula8 - Engenharia de Requisitos

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

ESW - Aula8 - Engenharia de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de

Analise de Requisitos (Cont):

Analise de Requisitos (Cont):

Analise de Requisitos (Cont):

Analise de Requisitos (Cont):

Analise de Requisitos (Cont):

Analise de Requisitos (Cont):

Paradigmas de desenvolvimento estabelecem a

RN01 O Sistema deve permitir que sejam Media

RN02 O Sistema deve manter o historico de Alta

RNF No Sistema os itens devem ser Usabilidade Funcionali Alta

Clientes do Sistema - especificam os requisitos e os

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

Verificação e Validação de Requisitos:

 [3] Pressman, Roger (2006). Engenharia de

Você também pode gostar