ENGENHARIA
DE
REQUISITOS
Análise e Modelação de Sistemas
2006
Engenharia de Requisitos
• A engenharia de requisitos (no contexto
da engenharia de software)
• É um processo que engloba todas as
actividades
• Que contribuem para a produção de um
documento de requisitos
• E sua manutenção ao longo do tempo.
Engenharia de Requisitos
• Este processo deve ser precedido de
estudos de viabilidade
• Que a partir das restrições do projecto,
determinam se este é ou não viável
•E se se deve prosseguir para a
identificação dos requisitos.
Conceito de Requisitos
O que são requisitos de um sistema?
• descrições de como o sistema se deve
comportar
• descrições de propriedades do sistema
• descrições de restrições do sistema ou
condicionantes no seu desenvolvimento
Conceito de Requisitos
•
mais definições...
•uma capacidade de um sistema de software
que um utilizador necessita para resolver um
problema ou atingir um objectivo
•uma capacidade que um sistema de software
deve possuir para satisfazer um contracto,
especificação, norma, ou qualquer outra
documentação imposta
Conceito de Requisitos
requisitos funcionais
descrevem o que o sistema deve fazer
exemplos
"o sistema deve possibilitar armazenar os pedidos de orçamento"
"o sistema deve possibilitar a paragem de emergência do motor
requisitos não-funcionais
descrevem as restrições na implementação dos requisitos funcionais
exemplos
"o sistema deve permitir armazenar pelo menos 500 pedidos de
orçamento por ano"
"o sistema operativo a usar deve ser linux"
"a paragem de emergência deve ser realizada em menos de 3
segundos"
Onde terminam os requisitos?
• "Os requisitos terminam onde começa a liberdade do
implementador"
• Idealmente, todas as decisões que têm de ser validadas
pelo cliente (que o implementador não pode tomar
isoladamente), devem estar contidas no documento de
requisitos
• Na prática, não é possível ou economicamente viável
prever tudo à partida, e é necessário manter um diálogo
constante com o cliente
• O nível de detalhe desejável varia de situação para
situação
Conceito de Requisitos
•
níveis de requisitos
•alto nível: missões, objectivos, regras do
negócio
•baixo nível: necessidades dos utilizadores,
funcionalidades, restrições
O processo de Engenharia
de Requisitos
• É constituído por quatro actividades de
alto nível (Soares, 2005):
•
•
•
•
Identificação.
Análise e negociação.
Especificação e documentação.
Validação.
O processo de engenharia de
requisitos:
modelo de actividades de alto nível
documento
de requisitos
identificação,
descoberta de
requisitos
análise e
negociação de
requisitos
documentação,
especificação
de requisitos
validação de
requisitos
necessidades dos utilizadores,
sistemas legados,
informação do domínio,
normas organizacionais,
etc.
O processo de engenharia de
requisitos:
entradas e saídas
sistemas
legados
necessidades
dos
utilizadores
normas
da
organização
regulamentos
informação
do
domínio
processo de
engenharia de
requisitos
requisitos
(acordados)
especificação
do
sistema
(Kotonya e Sommerville, 1998)
O processo de engenharia de requisitos
*qualidade do processo de ER
modelo de maturidade
nível 3. definido
PER baseado
em melhores práticas;
melhoria contínua
nível 2. repetível
PER obedecendo
a normas
nível 1. inicial
PER adhoc
O processo de engenharia de requisitos
actores no processo
engenheiro de requisitos / analista
especialista do domínio
responsável de projecto
processo de
engenharia de requisitos
utilizador final
engenheiro de software
O processo de engenharia de requisitos
actores no processo: stakeholders
•
Quem são os "interessados no sistema"
(stakeholders)?
•São as pessoas que serão afectadas pelo
sistema
•E que têm uma influência directa ou indirecta
na elaboração dos requisitos:
O processo de engenharia de requisitos
actores no processo: stakeholders
•
Quem são os "interessados no sistema"
(stakeholders)
• Utilizadores finais, gestores e outros envolvidos
nos processos organizacionais que o sistema
influencia, responsáveis pelo desenvolvimento e
manutenção do sistema
• Clientes da organização que possam vir a usar o
sistema, organismos de regulação e certificação, etc.
Processo de descoberta de requisitos "orientado ao
problema"
• análise de problemas - processo de compreender um problema
e propor soluções para resolver esse problema
identificar
os
stakeholders
entender as
causas do
problema
acordar na
definição do
problema
definir as
fronteiras
da solução
identificar
as
restrições
da solução
identificar os stakeholders
• compreender as necessidades dos
interessados no sistema é um factor
decisivo no desenvolvimento de uma
solução efectiva para um problema
–
–
–
–
quem
quem
quem
quem
são os utilizadores do sistema?
é o cliente (comprador) do sistema?
será afectado pelas saídas que o sistema produz?
fará a manutenção do sistema?
Definir as fronteiras da solução
– quem fornece, utiliza, remove informação do sistema? quem
opera o sistema? quem faz manutenção do sistema? onde é
que o sistema é usado? como obtém o sistema a sua
informação? que outros sistema interactuam com o
sistema?
fronteira do sistema
solução
utilizadores
outros sistemas
identificar as restrições da solução
• restrições no grau de liberdade que temos
para desenvolver o sistema
– económicas
– políticas
– tecnológicas
– sistemas existentes
– ambiente
– recursos
Acordar na definição do problema
• exemplo de formulação do problema
"o problema de se passar demasiado tempo a produzir a
documentação do projecto afecta os parceiros do projecto
e resulta em atrasos significativos no cumprimento dos
prazos;
os benefícios do sistema que gerisse a documentação à
medida que é produzida residiriam numa menor
percentagem de incumprimento de prazos e numa melhor
relação com os parceiros"
O processo de engenharia de
requisitos
boas práticas
•
algumas boas práticas
• definir uma estrutura normalizada para o documento de requisitos
• identificar univocamente cada requisito
• definir políticas de gestão de requisitos
• usar checklists de problemas para a análise de requisitos
• usar cenários para identificar os requisitos
• especificar os requisitos quantitativamente
• usar prototipagem para animar os requisitos
• reutilizar requisitos
• especificar sistemas formalmente
• etc.,
IDENTIFICACÃO
DOS
REQUISITOS
Processo de engenharia de requisitos:
modelo de actividades de alto nível
identificação
, descoberta
de requisitos
documento
de
Requisitos
análise e
negociação
de requisitos
especificação,
documentação
de requisitos
necessidades dos utilizadores,
sistemas legados,
informação do domínio,
normas organizacionais,
etc.
validação de
requisitos
Processo de engenharia de requisitos:
modelo em espiral
(Kotonya e Sommerville, 1998; SWEBOK)
Dimensões da descoberta de
requisitos
conhecimento geral do
domínio
compreender o
domínio de
aplicação
compreender as
necessidades e
restrições dos
interessados
que actividades devem ser
suportadas pelo sistema?
qual o papel de sistemas
existentes?
etc.
estende e especializa
conhecimento geral do
domínio
compreender o
problema a
ser resolvido
compreender o
contexto de
negócio
como é que o sistema contribui para os
objectivos do negócio?
etc.
Kotonya, 1998
Estágios do Processo
• Estabelecimento de objectivos
– Objectivos gerais do negócio, descrição genérica do problema a resolver,
necessidade do sistema e restrições sobre o sistema.
• Aquisição de conhecimento de background
– informação sobre a organização em que o sistema vai ser instalado, o
domínio de aplicação do sistema e informação sobre sistemas existentes
• Organização do conhecimento
– Organizar a grande quantidade de conhecimento (informação?) recolhida no
estágio anterior.
• Recolher requisitos dos stakeholders
– Consultar os interessados no sistema para descobrir os seus requisitos.
Fontes de requisitos (1)
(fonte: SWEBOK)
– objectivos gerais de alto nível do sistema
• objectivos gerais de alto nível do sistema, problema
que o sistema deve resolver, motivação para a
implementação do sistema, factores críticos de
sucesso, interesse para o negócio, ...
• necessário avaliar custos e benefícios de atingir os
objectivos, por exemplo com estudo de viabilidade
– conhecimento do domínio de aplicação
• necessário para inferir conhecimento tácito que os
stakeholders não explicitam, avaliar trade-offs entre
requisitos conflituosos, etc.
• pode ser obtido junto de especialistas do domínio,
documentos, etc.
– stakeholders do sistema
• fundamental identificar, representar e gerir os pontos
de vista, interesses e necessidades de todos os
interessados no sistema (utilizadores, clientes, etc.)
Fontes de requisitos (2)
(fonte: SWEBOK)
– ambiente operacional
• o ambiente operacional em que o sistema vai executar pode
impor diversos requisitos
– aproveitamento de infra-estruturas físicas e lógicas existentes
– interoperabilidade com sistemas existentes (internos ou
externos)
– etc.
– ambiente organizacional
• muitos sistemas destinam-se a suportar processos de
negócio, devendo-se adequar à estrutura, cultura, políticas,
regras e normas internas da organização (intra/inter)
– ambiente externo
• normas, regulamentos, legislação, etc.
• podem impor requisitos
• exemplos: lei de protecção de dados pessoais, normas de
acessibilidade, POC, ...
Técnicas de descoberta de
requisitos
–
–
–
–
análise de documentação
análise de sistemas existentes
entrevistas
encontros facilitados (workshops,
brainstorming)
– cenários
– protótipos
– observação e análise social, estudos
etnográficos
– soft systems methods
– reutilização de requisitos
ENTREVISTAS
Entrevistas
• entrevistar os futuros utilizadores e outros
stakeholders é a técnica mais vulgar e
simples de obter informação para
identificar requisitos
Entrevistas
• a entrevista é uma técnica simples, mas
não é fácil de aplicar
Entrevistas
– Enviesamento de quem conduz a
entrevista:
– Relação pessoal entre os intervenientes na
entrevista:
– predisposição do entrevistado:
– Capacidade de seguir um "plano" para a
entrevista:
Entrevistas
• tipos de entrevistas
– estruturadas vs. não estruturadas
– descontextualizadas vs. contextualizadas
pela solução
Entrevistas
• Entrevistas e Questionários: esta é talvez a técnica mais simples de
utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção
de dados (e mesmo de esclarecimento de algumas dúvidas), está
condicionada a alguns factores:
• Enviesamento de quem conduz a entrevista: convém que o
entrevistador dê margem ao entrevistado para expor as suas ideias
sem as enviesar logo à partida).
• Relação pessoal entre os intervenientes na entrevista.
Entrevistas
• Predisposição do entrevistado: caso, por exemplo, o
papel do entrevistado venha a ser afectado pela
introdução de um sistema na organização, este pode
propositadamente dificultar o acesso à informação.
• Capacidade de seguir um "plano" para a
entrevista: na ausência destes planos é natural que
haja tendência para que os intervenientes se dispersem
um pouco, levando a que a entrevista demore mais
tempo do que seria suposto. Caso a entrevista se torne
demasiado longa, as pessoas podem cair na tentação de
"querer despachar" sendo os últimos pontos da
entrevista abordados de forma superficial (ou podem
nem chegar a ser abordados).
Elaboração das perguntas
Perguntas de contexto livre
• Como exemplo de perguntas deste género,
podemos ter:
•
•
•
•
Quem são os utilizadores?
Quem é o cliente?
Têm necessidades diferentes?
Onde podem ser encontradas outras soluções
para este problema?
Elaboração das perguntas
Perguntas centradas na solução
• Após terem sido feitas as perguntas
de contexto livre, pode começar-se a
explorar as soluções propostas com
estas perguntas mais direccionadas:
• (Apresentar as capacidade gerais de uma
solução) E se pudesse fazer ... e ...?
• Como classificaria a importância de cada
uma das funcionalidades apresentadas?
Aqui ficam algumas dicas para uma
entrevista de sucesso:
• Prepare uma entrevista de contexto livre apropriada, e
tome nota para que isso sirva como referência no
decorrer da entrevista. Faça uma revisão às questões a
colocar nos momentos que antecedem a entrevista.
• Antes da entrevista faça uma pesquisa ao background
do stakeholder e da empresa a serem entrevistados. Não
mace a pessoa a ser entrevistada com perguntas que
poderia facilmente saber a resposta à priori. Ainda
assim, pode confirmar brevemente essas respostas
dando a mostrar o seu interesse e conhecimento da
pessoa e empresa em questão.
Aqui ficam algumas dicas para uma
entrevista de sucesso:
• Anote as respostas no seu bloco de notas durante a entrevista. (Não
tente capturar a informação de forma electrónica nesta fase!)
• Consulte as notas da estrutura da entrevista no decorrer da mesma.
Desta forma tem a certeza que está a fazer as perguntas correctas e
que não se está a desviar dos objectivos definidos.
• Discuta os problemas com o utilizador. Esclareça situações que
possa observar no ambiente. Faça sugestões e observações
baseadas em conhecimento teórico e familiarização com outros
sistemas.
Entrevista e Compilação
• O guião da entrevista não deve ser demasiado
•
restritivo. Depois de estabelecida uma ligação
positiva com o entrevistado, é normal que a
entrevista acabe por entrar numa dinâmica
própria.
Após a realização das entrevistas, o analista já
deve ter ficado com um leque de necessidades
identificadas. Para compilar o conjunto de
necessidades gerais dos utilizadores
entrevistados deve ser usado um método que
pode ser denominado de "Resumo do Analista".
Vantagens
• É a forma mais fácil de descobrir as necessidades de um sistema, pois
passa por perguntar directamente aos stakeholders.
• Permite uma melhor compreensão do problema e seu domínio.
• Pode ser utilizada em praticamente qualquer situação.
• É uma solução de baixo custo.
• Uma vez bem definidas as perguntas e estrutura da entrevista, é possível
encontrar requisitos reais, e não apenas necessidades de alto nível.
• É um método que aproxima as entidades envolvidas no projecto.
Desvantagens
• Consome bastante tempo.
• Utilizadores diferentes podem ter
necessidades contraditórias.
• Pode originar grandes discrepâncias entre
o funcionamento actual do processo de
negócio, e o plano para o futuro.
Workshops
de
Requisitos
Workshops
• uma workshop de requisitos é uma
técnica de grupo para o debate e
acordo das questões asociadas à
identificação dos requisitos
– levada a cabo através da formação de um
grupo de representantes dos stakeholders
– facilitada por alguém com competência
para conduzir o processo de identificação e
análise de requisitos
Workshops
• preparação
– "vender" o conceito
– assegurar a participação dos stakeholders
adequados
– garantir os aspectos logísticos
– fornecer materiais para discussão
antecipadamente
– escolher o facilitador
– estabelecer uma agenda
Note-se que uma workshop, apesar de
se assemelhar a uma reunião, difere
em alguns pontos:
• Reuniões são lideradas por um gestor (líder, que geralmente, faz pouca
preparação). As workshops são lideradas por um facilitador neutro que se
prepara intensivamente;
• As reuniões não requerem trabalho prévio por parte da assistência. As
workshops requerem muito trabalho prévio, incluíndo a criação de produtos
que servem de candidatos a inputs do workshop;
• As decisões numa reunião são tomadas pelo gestor, e podem não ser tópico
de discussão. Numa workshop cada decisão está associada a uma regra.
Existe um processo de decisão e a tomada de decisão pode estar associada
a uma ou mais pessoas (mas não ao facilitador);
• As reuniões prendem-se com troca de informação. Já ás workshops
prendem-se com a descoberta e criação da informação;
Note-se que uma workshop, apesar de
se assemelhar a uma reunião, difere
em alguns pontos:
• Numa reunião existe pouca interacção entre os presentes. Nas workshops a
participação é intensa e variada e os participantes realizam actividades
individualmente, como membros de sub-grupos, ou colectivamente;
• Reuniões não permitem quase nenhuns momentos de descontracção. Já as
workshops encorajam a descontracção como forma de promoção da
inovação e do trabalho de equipa.
• As reuniões normalmente não envolvem a prodção de documentação. Já
nas workshops os participantes criam e verificam documentos como p.ex
diagramas de casos de uso;
• As reuniões usam raramente meios visuais. Nas workshops sao fortemente
utilizados meios visuais como posters, post-it, cartões diagramas.
Planear uma workshop
•
Planear o horário da sessão: em que altura do dia se realizará,
quanto tempo durará, ...
•
Planear o local: a sessão deve decorrer num local arejado, com
boa luz; as cadeiras devem estar dispostas de forma que todos os
participantes se vejam
•
Planear as regras básicas:
–
–
Todos os membros devem participar o máximo possível
Como a sessão é só uma, é importante que seja estabelecido um
conjunto de regras básicas que regulem a participação. Ex: nunca se
deve desviar do objectivo da sessão, nunca se deve desviar da
questão base do momento, não se deve ultrapassar a vez dos outros,
...
Planear uma workshop
•
Planear a agenda a seguir:
–
–
–
–
–
–
–
Dar as boas-vindas
Rever a agenda
Rever o objectivo da sessão
Rever as regras básicas de participação
Fazer uma introdução ao projecto
Lançar as questões e conduzir as respostas
Terminar agradecendo a participação
•
Escolher os participantes (ver quadro abaixo)
•
Planear a gravação da sessão
–
–
Deve estar presente um ajudante (co-facilitador) que vá tirando notas ao
longo da workshop
Para além disso, pode ser útil gravar a sessão em suporte áudio ou video
Conduzir uma workshop
• De seguida será descrita uma possível
abordagem ao modo como o mediador
deverá conduzir a sessão:
Conduzir uma workshop
• Forming - Fase de orientação do grupo e introdução dos objectivos da
sessão. Nesta fase o facilitador deve:
–
–
–
–
Apresentar-se e apresentar o co-facilitador
Agradecer a disponibilidade das pessoas
Explicar os modos de gravação da sessão (só papel, gravador audio ou video)
Apresentar/relembrar a agenda
• Storming - divulgação de todas as ideias que os intervenientes possam ter,
mesmo que estas sejam incompatíveis com outras áreas de negócio ou
mesmo com o sistema que foi inicialmente idealizado. O facilitador deve:
– Introduzir todas as questões antes de se iniciar o debate. Dar algum tempo aos
participantes para pensarem sobre cada uma (e registarem as suas respostas).
De seguida conduzir a discussão à volta das respostas a cada questão, sendo
tratada uma de cada vez
– Quando terminada uma questão, o facilitador deve fazer um breve resumo sobre
as respostas dadas e a conclusão a que se chegou (pode ser o co-facilitador a
fazer isto)
Conduzir uma workshop
• Norming - Promover a harmonia, a compreensão e o apoio das ideias uns
dos outros, aumentando a coesão dos grupos intervenientes. O facilitador
deve:
– Garantir que as regras básicas de participação são respeitadas, dando voz a
todos os participantes
– O facilitador não deve participar no debate/discussão (nunca justificar a sua
posição)... O seu papel fundamental é ouvir e coleccionar informação
– Assegurar a participação uniforme - se 1/2 pessoas estão a liderar a discussão, o
facilitador deve promover e incentivar os outros intervenientes, chamando-os a
responder. Uma boa abordagem é usar uma mesa redonda, seguindo uma
direcção, dando a cada participante 1 min para transmitir a sua opinião.
• Performing - Nesta fase já deverá estar interiorizado no pensamento dos
stakeholders uma actuação como equipa. Aqui já deverão emergir soluções.
Os requisitos já deverão ser tratados com mais detalhe e ser prioritizados.
Conduzir uma workshop
• Adjourning - Deverá ser feita uma retrospectiva do
projecto, e das soluções encontradas. Esta fase não
deverá ser descurada, já que é essencial para que os
intervenientes percebam que o papel que
desempenharam foi tomado em conta e é essencial para
este e futuros projectos. O facilitador deve:
– Notificar os participantes da breve recepção de uma cópia do
relatório resultante da sessão (contendo as principais propostas
e conclusões)
– Agradecer aos participantes a sua presença e participação
– Terminar a sessão
Como tirar mais proveito dos
Workshops?
• As tomadas de decisão devem seguir processos bem
definidos e devem resultar de um processo de
negociação, mediado pelo facilitador.
• Uma técnica que é também útil em workshops é o uso
de brainstorming como forma de gerar um elevado
número de ideias numa pequena quantidade de tempo.
• Como resultado dos workshops deve ser produzida
documentação que reflicta os requisitos e decisões
tomadas sobre o sistema a implementar.
Brainstorming
• brainstorming é uma técnica para a geração
de novas ideias por um conjuto de pessoas
– encoraja a participação de todos
– permite o aproveitamento e refinamento de outras
ideias
– pode ser bastante produtiva (nº de ideias/hora)
– o resultado pode ser um conjunto de soluções
– encoraja o pensamento livre... (maluquices...)
Brainstorming: reduzir ideias
• "podar" ideias
• agrupar ideias
• definir as características de cada ideia
• estabelecer prioridades
Brainstorming
• regras do brainstorming
– não permitir críticas ou debate
– deixar a imaginação voar...
– gerar tantas ideias quanto for possível
– mutar e combinar ideias
– Atraso do julgamento
– Criatividade em quantidade e qualidade
Há 3 principais partes no
brainstorming:
• Encontrar os factos,
• Geração da ideia,
• Encontrar a solução.
Há 3 principais partes no
brainstorming:
• Da busca dos factos na resolução de um
problema existem duas sub partes:
• Definição do problema,
• Preparação.
Há 3 principais partes no
brainstorming:
• Inicialmente, define-se o problema. Poderá ser necessário subdividir
o problema em várias partes. A técnica de Brainstorming funciona
para problemas que têm muitas soluções possíveis tal como a
geração de ideias para o seu desenho.
• Depois é necessário colher toda a informação que pode relacionarse com o problema.
• Geração de idéias por brainstorming.
• Busca da solução. Avaliar e seleccionar as melhores idéias.
Brainstorming na educação
• A técnica de brainstorming não é uma actividade
exclusiva de um ambiente empresarial: pelo contrário,
na escola esta, pode ser uma técnica muito importante
na educação dos estudantes. Este grande ou pequeno
grupo de actividade encoraja os estudantes a manteremse focados num tópico e contribuir para uma fluidez de
ideias em liberdade.
• O professor pode começar por propôr uma questão ou
problema, ou introduzindo um tópico. Os estudantes,
depois expressam e divulgam as possíevis respostas e
soluções, palavras, expressões ou ideias relevantes.
CENÁRIOS
cenários
• abordagem para colocar os interessados
num sistema perante uma situação realista
em que simulam ou apenas antevêem a
sua interacção com o sistema
– materializam-se em histórias que explicam
como é que o sistema poderá ser usado
Cenários
• uma forma de levar as pessoas a imaginar o
•
comportamento de um sistema é o uso de
cenários. Através de exemplos práticos
descritivos do comportamento de um sistema,
os seus utilizadores podem comentar acerca do
seu comportamento e da interacção que
esperam ter com ele.
Trata-se de uma abordagem informal, prática e
aplicável a qualquer tipo de sistema. De um
modo geral, os cenários devem incluir os
seguintes elementos:
Cenários
• Estado do sistema no início do cenário.
• Sequência de eventos esperada (na
ausência de erros) no cenário.
• Listagem de erros que podem ocorrer no
decorrer dos eventos do cenário e de
como estes erros serão tratados.
Cenários
• Listagem de erros que podem ocorrer no
decorrer dos eventos do cenário e de
como estes erros serão tratados.
• Outras actividades que podem estar a ser
executadas ao mesmo tempo que as deste
cenário.
• Estado do sistema depois de o cenário
terminar.
Cenários: conteúdo
fluxo normal de eventos
excepções ao
fluxo normal de eventos
informação sobre
outras actividades que
ocorrem ao mesmo tempo
descrição do sistema antes de se entrar no cenário
descrição do estado do sistema depois de completado o cenário
Cenários: definição
• mais definições
– uma história ou exemplo de eventos retirados
da experiência do mundo real; incluem
detalhes do contexto do sistema (cenas)
– um caminho ou instância de um modelo
(normalmente de casos de utilização)
– a visão futura de um sistema a ser desenhado,
com sequências de comportamento e
descrições contextuais
Sutcliffe, 2002
Cenários: objectivos
• identificar e clarificar requisitos
– adicionar detalhe a requisitos mais gerais
– compreender a relação entre requisitos
• validar requisitos
– compreender um requisito no seu contexto de
utilização
– verificar se a sua relação com outros requisitos
faz sentido
Principais vantagens do uso de
cenários em Engenharia de Requisitos
• Tem em conta o ponto de vista do utilizador
• Especificações parciais
• Fácil de compreender
• Ciclos de feedback curtos
• Servir de base para os testes do sistema
CENÁRIOS: conclusão
• Engenharia de requisitos baseada em
cenários é definitavamente um passo na
direcção certa.
• Em particular, cenários são uma chave
que permite um novo estilo de engenharia
de requisitos evolucionário e incremental.
CENÁRIOS: conclusão
• Os cenários focam-se nos utilizadores, em
•
•
descrições concretas e instâncias específicas.
O desenho de sistemas baseado em cenários
atribui um grande ênfase aos utilizadores;
articula qual o seu papel, o que fazem, como
fazem, e sobre que circunstâncias o fazem.
Um cenário é uma descrição concreta do
trabalho e actividades, descrevendo assim uma
instância específica e um caso de uso.
Cenários versus casos de uso
• Existem diferentes opiniões sobre a relação
existente entre casos de uso e cenários:
– Há quem os considere sinónimos
– Há quem considere que um cenário corresponde a um
conjunto de casos de uso (fluxo normal de eventos, e
cada fluxo excepcional seriam casos de uso
separados)
– Há quem considere que um caso de uso corresponde
a um conjunto de cenários
• Em UML, um caso de uso admite variantes, podendo-se
considerar cada variante como um cenário
• Cada cenário pode ser representado por um diagrama de
interacção (normalmente um diagrama de sequência)
cenários: exemplo – reservar livro através
do site da biblioteca
• Entrar no sistema (log on)
• Procurar o livro pretendido por autor, título ou
•
•
•
•
ISBN
Seleccionar um dos exemplares disponíveis
Dar ordem para reservar esse exemplar
Seleccionar o modo de entrega: levantamento
na biblioteca, ou envio por funcionário
Sair do sistema (logout)
PROTOTIPAGEM
Prototipagem
• um protótipo é uma versão inicial de um
sistema usado para apoiar essencialmente
as fases de identificação, análise e
validação de requisitos
Prototipagem
• características
– desenvolvimento rápido
– funcionalidades limitadas
– requisitos não funcionais pouco considerados
– várias tecnologias
– pode ir desde maquetas a protótipos evolutivos
Prototipagem: custos
• a decisão de usar a prototipagem deve ser
tomada com recurso a uma análise custobenefício
• custos envolvidos na prototipagem
– formação, desenvolvimento, prazos mais
alargados, protótipos incompletos
Prototipagem: benefícios
• benefício principal
– os clientes e utilizadores finais têm contacto com
um sistema realista cedo o que lhes permite
compreender melhor os requisitos que pretendem
identificar e analisar
• outros benefícios
– ajuda a estabelecer a viabilidade e utilidade do
sistema
– é a única forma efectiva de desenvolver IPC
– pode ser usado na validação
– o estudo cuidadoso dos requisitos ajuda a revelar
inconsistências e lacunas
Prototipagem: tipos
Existem 3 tipos de protótipos (Sommerville, Sawyer,
1997):
– Protótipo em papel: é desenvolvido um conjunto de
interfaces associadas a cenários de utilização que são
apresentados aos utilizadores. Este tipo de prototipagem é
barata e eficiente (Rogers, Sharp, Preece, 2002)(Kotonya,
Sommerville 1998). È mais indicada quando o sistema a
desenvolver é software. Não é necessário desenvolver
software executável. Os analistas e utilizadores percorrem
estes cenários, simulando a utilização do sistema, sendo
analisado as reacções dos utilizadores, a informação
requerida e a forma de interacção com o sistema. Este
método é muito eficiente para sistemas interactivos. Este
tipo de protótipo é de baixa fidelidade (Rogers, Sharp,
Preece, 2002).
Prototipagem: tipos
– Protótipo “wizard of Oz”: uma pessoa simula
as respostas dos sistemas em resposta as acções
dos utilizadores. Este tipo de prototipagem é
relativamente barata visto apenas a interface do
sistema ter de ser desenvolvida (Kotonya,
Sommerville 1998). Os utilizadores interagem com
o que parece ser o sistema em que as suas
acções são analisadas por um pessoa que simula
a resposta do sistema. É particularmente útil
quando o sistema a desenvolver tem por base
numa interface existente. Este tipo de protótipo é
de baixa fidelidade (Rogers, Sharp, Preece, 2002).
Prototipagem: tipos
– Protótipo automático: é utilizado linguagens 4GL ou
outras linguagens que permitem um rápido desenvolvimento
de protótipos executáveis. Este tipo de prototipagem é a
mais cara (Kotonya, Sommerville 1998). Envolve o
desenvolvimento de software, recorrendo a linguagens de
programação de alto nível, que simule as funcionalidades do
sistema. O problema principal do desenvolvimento de
protótipos executáveis é de os Stakeholders não simularem
a real utilização do sistema final devido ao facto de muitos
dos requisitos não funcionais do sistema não estarem
provavelmente implementados em conjunção com falta de
treino. Um outro problema poderá surgir se o
desenvolvimento do sistema estiver atrasado. Nesta
situação pode ocorrer a tentação de prosseguir o
desenvolvimento do protótipo com todas as nefastas
consequências anteriormente referidas.
Prototipagem: tipos
• prototipagem evolutiva
– o objectivo é proporcionar um sistema "produtivo"
o mais rápido possível ao cliente
– os requisitos objecto dos protótipos iniciais
deverão ser aqueles mais facilmente
compreendidos e que podem dar rapidamente um
valor acrescentado útil ao utilizador
ESTUDOS ETNOGRÁFICOS
Etnografia
• Técnica onde o sociólogo gasta um
tempo considerável no ambiente de
trabalho a observar e a anotar como os
participantes envolvidos trabalham
• Interacções implícitas são reveladas. As
pessoas não têm que explicar o seu
trabalho
Estudos Etnográficos:
• Este tipo de estudos são uma análise da
•
componente social das tarefas desempenhadas
numa dada organização.
Quando um dado conjunto de tarefas se torna
rotineiro para uma pessoa, é de esperar que
esta sinta dificuldade em articular todos os
passos que segue ou todas as pessoas com as
quais interage para as levar a cabo.
Estudos Etnográficos:
• Através de uma observação directa das actividades
•
•
realizadas durante um período de trabalho de um
funcionário é possível encontrar requisitos que não
seriam observáveis usando técnicas convencionais.
Esta observação pode ser acompanhada de registos
áudio/vídeo, porém não convém usá-los em demasia
visto que o tempo necessário para os processar pode ser
demasiado.
Nesta técnica assume-se que o stakeholder observado
desempenha as suas funções "correctamente", pelo que
convém ter algum cuidado na escolha do(s)
stakeholder(s) a observar.
Observação e Análise Social
• estudos etnográficos e identificação de
requisitos
– há requisitos que não se conseguem identificar
através das técnicas convencionais
– os estudos etnográficos ajudam a fazer
emergir requisitos derivados de formas
rotineiras e tácitas de trabalhar
Observação e Análise Social
• grande parte dos sistemas que
desenvolvemos visam apoiar o trabalho
das pessoas
• o trabalho é uma actividade social que
envolve grupos de pessoas que cooperam
para levar a cabo diferentes tarefas
Kotonya, 1998
observação e análise social
• as pessoas encontram frequentemente
dificuldade em tornar explícita a forma como
realizam tarefas e como trabalham em conjunto
com outros
• quando as tarefas se tornam rotina e as pessoas
tendem a não pensar nelas conscientemente,
torna-se difícil que articulem como é que o
trabalho é realizado
• as pessoas usam artefactos (ferramentas,
documentos, etc.) de uma forma intuitiva
Estudos Etnográficos
• algumas directrizes
– assumir que as pessoas que se estão a estudar são boas a
realizar o seu trabalho
– estabelecer relações de confiança com as pessoas
envolvidas no estudo; os analistas devem ser externos à
organização
– escrever notas detalhadas e regulares das práticas de
trabalho estudadas
– realizar entrevistas abertas
– não recorrer demasiado às gravações vídeo e áudio, porque
são difíceis de tratar em tempo útil
– realizar sessões de crítica por parte de elementos externos
ao projecto
observação e análise social
• estudos etnográficos
– observação detalhada das práticas sociais de uma
sociedade
– uma compreensao total destas práticas só é possível
pela observação do detalhe e a partir do interior da
comunidade
– um grupo de funcionários numa biblioteca, num banco,
num laboratório têm características dos elementos de
uma sociedade
Estudos Etnográficos
reuniões de
crítica
análise
etnográfica
prototipage
m
experiências
dos
utilizadores
etnografia
focada
protótipo
ANÁLISE
E
NEGOCIAÇÃO
O processo de engenharia de requisitos
modelo de actividades de alto nível
identificação
, descoberta
de requisitos
documento
de requisitos
análise e
negociação
de requisitos
documentaçã
o de
requisitos
necessidades dos utilizadores,
sistemas legados,
informação do domínio,
normas organizacionais,
etc.
validação de
requisitos
Processo de engenharia de
requisitos: modelo em espiral
(Kotonya e Sommerville, 1998; SWEBOK)
Análise e Negociação de Requisitos
objectivos
• análise e negociação de requisitos
– actividades que visam descobrir problemas com os
requisitos e chegar a acordos para a sua resolução de
forma a satisfazer todos os interessados no sistema
– na realidade, na fase de identificação de requisitos já
se desenrolam actividades de análise e negociação
– análise e negociação de requisitos são actividades que
incidem sobre conjuntos incompletos de requisitos
Análise e Negociação de Requisitos
características
• a análise e negociação de requisitos é
normalmente um processo complexo
– requer pessoas com competências
específicas
– baseia-se muito no julgamento e
experiência dos participantes
– não é possível transformar este processo
numa abordagem estruturada e sistemática
– é custoso e moroso
Análise de Requisitos
necessidade, consistência e
completude
• no conjunto de requisitos identificados
pode
– haver requisitos que se sobrepõem
– haver requisitos que estão em conflito ou
que são contraditórios
– faltar requisitos...
Análise de Requisitos
técnicas: check-lists
• listas de questões que um analista usa para
avaliar os requisitos
– são um "lembrete" do que é importante
considerar na análise
– não devem ter mais do que 10 items
– evoluem com a experiência ganha no processo
de análise
Análise de Requisitos
técnicas: check-lists
• exemplo
–
–
–
–
–
–
–
–
o
o
o
o
o
o
o
o
requisito
requisito
requisito
requisito
requisito
requisito
requisito
requisito
inclui aspectos de desenho ou implementação
poderia ser decomposto em sub-requisitos?
é mesmo necessário?...
implica a utilização de software não standard?
está de acordo com os objectivos do negócio?
é ambíguo?
é realista?
é "testável"?
Sutcliffe, 2002
Análise de Requisitos
análise quanto ao âmbito
definir as
fronteiras do
sistema
diagramas de contexto
diagramas de casos de uso
analisar e decidir
se o requisito está
dentro ou fora
Análise de Requisitos
análise de prioridades
• definir prioridades na análise e
implementação dos requisitos
• classificação
– alta, média, baixa, não/sabe
– essencial, útil, pouco interesse, a ser decidido
Análise de Requisitos
organização dos requisitos
• hierarquização
– relações de composição ou "pai-> filhos" ou
"requisito-> sub-requisito"
– os requisitos são definidos a vários níveis de
abstracção
• a organização em hierarquias é adequada a
uma abordagem iterativa (espiral) ao
processo de engenharia de requisitos
Análise de Requisitos
hierarquia de requisitos e casos de uso
1. marcação de consulta (caso de uso)
– 1.1 a consulta pode ser marcada pelo médico ou
pela assistente
– 1.2 um médico pode marcar uma consulta para
outro médico
– 1.3 não se podem marcar duas consultas para a
mesma data, hora e médico (restrição)
– 1.4 o sistema deve alertar o utilizador no caso do
doente ter outras consultas marcadas (alerta)
– 1.5 o sistema deve ajudar o utilizador a encontrar
vagas (ajuda)
– (...)
Negociação de Requisitos
aspectos gerais
• negociação para quê?
– chegar a acordo em relação a opções mais
adequadas aos interesses dos stakeholders
– definir as prioridades a dar aos requisitos
para novas iterações de identificação e
análise e para o desenvolvimento
– chegar a acordo em relação a
compromissos entre requisitos que entram
em conflito
Negociação de Requisitos
tarefas na negociação
estruturar
opções
e escolhas
estabelecer
critérios de
avaliação
explicar opções
disponíveis e a
escolha a fazer
chegar a um
acordo
diagnosticar
causas de
desacordo
Negociação de Requisitos
intervenientes na negociação
• stakeholders primários
– os que operam o sistema
– preocupam-se com os requisitos funcionais e
questões de usabilidade
– pretendem sistemas fáceis de usar e aprender
Negociação de Requisitos
intervenientes na negociação
• stakeholders secundários
– não operam o sistema mas consomem o que
este produz
– o sucesso das suas actividades depende da
qualdade do sistema
– são tipicamente gestores que usam a
informação do sistema para controlar,
monitorar e ajustar processos organizacionais
Negociação de Requisitos
intervenientes na negociação
• stakeholders terciários
– gestores de topo que raramente consomem as
saídas do sistema (directamente)
– usam-nas indirectamente para planear e
controlar estrategicamente o negócio
– interessam-se pelo papel que o sistema
desempenha na prossecução dos objectivos
estratégicos do negócio tais como aumentar a
vantagem competitiva ou melhorar o serviço
ao cliente
Negociação de Requisitos
gerir a negociação
• problemas num processo de negociação
– separar os aspectos a debater das questões
pessoais
– falta de entendimento partilhado e de pontos
de vista pessoais
– atitudes interpessoais
Negociação de Requisitos
técnicas para gerir a negociação
• lidar com os ataques pessoais
– evitá-los...
– se acontecerem: mudar de assunto, fazer um
intervalo...
– resolver o problema fora da reunião
Negociação de Requisitos
técnicas para gerir a negociação
• bloqueio
– reacções negativas sem justificação: "isso não
resulta", "não se pode fazer", "dá muito
trabalho“.
– desafiar os participantes a justificarem a sua
posição negativa
Negociação de Requisitos
técnicas para gerir a negociação
• conflitos entre grupos
– choque de pontos de vista entre grupos
– exemplos: qualidade vs. prazos, custos vs.
desenvolvimento, segurança vs. acesso,
complexidade funcional vs. usabilidade, etc.
– deferir decisões, os ânimos arrefecem...
Negociação de Requisitos
técnicas para gerir a negociação
• outras técnicas
– testar e provar assunções (pressupostos)
– relaxar restrições
– tentar encontrar potenciais benefícios para
todos
– evitar tomar partidos
ESPECIFICAÇÃO
E
DOCUMENTAÇÃO
O processo de engenharia de requisitos
modelo de actividades de alto nível
+ protótipo
identificação,
descoberta
de requisitos
+ modelo
documento
de requisitos
análise e
negociação
de requisitos
documentação
de requisitos
validação de
requisitos
necessidades dos utilizadores,
sistemas legados,
informação do domínio,
normas organizacionais,
etc.
Documento de Requisitos
• O que é um Documento de Requisitos?
– é uma descrição oficial dos requisitos de um
sistema para os clientes, utilizadores e
desenvolvedores
– outras designações: especificação funcional,
definição de requisitos, especificação de
requisitos, caderno de encargos
Documento de Requisitos
• como se escreve um Documento de Requisitos?
– depende de quem o escreve, para quem, onde, ...
– normalmente é escrito em linguagem natural e pode
ser complementado com diagramas, tabelas,
fotografias, imagens, etc.
– existem directrizes e recomendações para a escrita
de documentos de requisitos
– o grau de detalhe depende de quem o escreve, da
organização em que está inserido, do seu propósito,
Documento de Requisitos
• Documento de Requisitos é usado para
comunicar o que se pretende que um
determinado sistema faça
– destina-se aos clientes, utilizadores, gestores e
desenvolvedores do eventual sistema
– especifica que serviços o sistema deve prestar, as
propriedades do sistema (fiabilidade, eficiência,
etc.) e restrições impostas à operação e
desenvolvimento do sistema
– tanto pode ser um documento muito sucinto e
genérico como um documento extenso e muito
detalhado.
Documento de Requisitos
• O que é que normalmente se encontra num documento de requisitos?
– uma visão geral do sistema e dos benefícios decorrentes do
desenvolvimento do sistema
– um glossário explicando os termos técnicos usados
– uma definição dos serviços ou requisitos funcionais do sistema
– uma definição das propriedades do sistema (requisitos nãofuncionais) tais como fiabilidade, segurança, etc.
Documento de Requisitos
• O que é que normalmente se encontra num documento de requisitos?
– as restrições à operação do sistema e ao processo de
desenvolvimento
– uma definição do ambiente em que o sistema vai operar e as
mudanças previstas para esse ambiente
– especificações detalhadas recorrendo a modelos e outras
ferramentas
Documento de Requisitos
• Estrutura sugerida por IEEE/ANSI (830-1993)
• 1. Introdução
– 1.1
– 1.2
– 1.3
– 1.4
– 1.5
Propósito do documento
Âmbito do sistema
Definições, acrónimos e abreviaturas
Referências
Resenha do resto do documento
Documento de Requisitos
• Estrutura sugerida por IEEE/ANSI (830-1993)
(cont.)
• 2. Descrição geral
– 2.1
– 2.2
– 2.3
– 2.4
– 2.5
Perspectiva do produto
Funções do produto
Características dos utilizadores
Restrições gerais
Assunções e dependências
Documento de Requisitos
• Estrutura sugerida por IEEE/ANSI (830-1993) (cont.)
• 3. Requisitos específicos
– requisitos funcionais, requisitos não funcionais,
requisitos da interface com o utilizador:
• funcionalidade, interfaces externas, requisitos de
desempenho, restrições de concepção, atributos do
sistema, características de qualidade, ...
• Apêndices
• Índice
Documento de Requisitos
• Orientações
– explicar como se usa o documento
– descrever um ou mais cenários de utilização
– definir claramente os termos especializados
– formatar o documento para uma boa
legibilidade
– ajudar os leitores a encontrar informação
– fazer o documento fácil de alterar
Manual do Utilizador como
Documento de Requisitos
• Steve McConnel, no seu livro "Software
Project Survival Guide", defende que, na
maioria dos situações, é mais vantajoso
documentar os requisitos através de um
manual do utilizador e um protótipo da
interface com o utilizador, facilmente
percebidos por todos, do que através de
um documento formal de requisitos
• (documento formal deve ser apenas
um complemento)
VALIDAÇÃO
DE
REQUISITOS
O processo de engenharia de requisitos
modelo de actividades de alto nível
identificação
, descoberta
de requisitos
documento
de requisitos
análise e
negociação
de requisitos
documentaçã
o de
requisitos
necessidades dos utilizadores,
sistemas legados,
informação do domínio,
normas organizacionais,
etc.
validação de
requisitos
Processo de engenharia de
requisitos: modelo em espiral
(Kotonya e Sommerville, 1998; SWEBOK)
Validação de Requisitos
• Consiste em demonstrar que os requisitos
definem o sistema que o cliente realmente
quer.
Revisões de Requisitos
• Revisões regulares devem ser realizadas
enquanto a definição dos requisitos está
sendo formulada
• Ambos o cliente e o analista devem estar
envolvidos nas revisões
O processo de Engenharia de
Requisitos
validação de Requisitos
• validação de requisitos diz respeito à
verificação dos requisitos quanto à sua
consistência, completude e precisão
• envolve




revisão de requisitos
prototipagem
validação de modelos
teste de requisitos
Validação de Requisitos
análise vs. validação
assegurar que os
requisitos vão ao
encontro das
necessidades dos
stakeholders
assegurar que os
requisitos estão
correctamente descritos
temos os requisitos certos?
análise e
negociação
de requisitos
validação de
requisitos
temos os requisitos correctamente?
requisitos em "bruto",
informais e pouco estruturados,
escritos numa mistura de notações
stakeholders
draft final do documento de
requisitos,
isento de inconsistência e
incompletude,
segue normas de qualidade,
Validação de Requisitos
análise vs. validação
• exemplos de problemas que aparecem na
fase de validação




não conformidade com normas de qualidade
requisitos mal descritos, ambíguos
erros na modelação do sistema ou problema
conflictos entre requisitos que não foram
detectados no processo de análise
Validação de Requisitos
processo de validação
documento de
requisitos
normas da
organização
conhecimento
organizacional
lista de problemas
validação de
requisitos
acções acordadas
Kotonya, 1998
Validação de Requisitos
Revisão de requisitos
planear
revisão
distribuir
documentos
preparar
para
a revisão
reunião
de revisão
acções de
continuidad
e
rever o
documento
Kotonya, 1998
Validação de Requisitos
revisão de requisitos
• reunião de revisão de requisitos




a reunião de revisão é uma reunião formal
deve ser conduzida por alguém que não esteve
envolvido na produção dos requisitos
cada requisito deve ser apresentado à vez para
discussão pelo grupo
os problemas identificados são registados para
posterior discussão
Validação de Requisitos
revisão de requisitos
acções
problemas
clarificação, reescrita
dos requisitos
requisitos mal escritos
falta de informação
conflictos
descobrir a informação
que falta no documento
os stakeholders devem
negociar para resolver o
conflicto
requisitos não realistas
o requisito deve ser
modificado ou removido
Validação de Requisitos
revisão de requisitos: equipa
especialista do
domínio
utilizador-final
ou representante
equipa de
revisão de
requisitos
engenheiro de
requisitos
representante
do cliente
responsáveis pelo
desenho do sistema
Validação de Requisitos
revisão de requisitos: checklists
• checklists de revisão


devem ser genéricas
não devem incidir sobre requisitos
individualmente mas com as propriedades de
qualidade do documento como um todo e com
as relações entre requisitos
Validação de Requisitos
revisão de requisitos: checklists
questões
cada requisito está identificado de
forma única?
os termos especializados aparecem
no glossário?
o requisito depende de outros para se
compreender o seu significado?
há requisitos que usam o mesmo termo com
sentidos diferentes?
o mesmo serviço é solicitado em vários
requisitos? há contradições nestas solicitações?
se os requisitos fazem referência a outras facilidade,
isso está descrito algures no documento?
os requisitos relacionados estão agrupados? se não
como se referenciam mutuamente?
atributo de qualidade
rastreabilidade, conformidade com normas,
compreensibilidade
compreensibilidade, completude
ambiguidade
consistência, redundância
completude
organização, rastreabilidade
Validação de Requisitos
revisão de requisitos: checklists
• atributos de qualidade dos requisitos








compreensibilidade
redundância
completude
ambiguidade
consistência
organização
conformidade com as normas
rastreabilidade
Validação de Requisitos
prototipagem
• se num projecto já foram usados protótipos
para a identificação de requisitos, então faz
sentido que o sejam também na validação
Validação de Requisitos
prototipagem
seleccionar os
testadores
do protótipo
desenvolver
cenários de
teste
executar
cenários
documentar
problemas
documentar e estender os protótipos
Kotonya, 1998
Validação de Requisitos
prototipagem
• a reescrita dos requisitos noutro formato pode ajudar
a validá-los
– é necessário compreendê-los bem o que pode revelar
conflictos, omissões e inconsistências
• os manuais de utilização podem começar a ser
produzidos na fase de validação (manual do
protótipo)
– descrição das funcionalidades implementadas e da
forma de as aceder (interfaces)
– menção às partes do sistema não implementadas
– como recuperar de dificuldades
– como instalar o protótipo
Validação de Requisitos
validação de modelos
• parte da especificação de requisitos de um
sistema pode ser constituída por vários modelos
• a validação de modelos tem como objectivos
– 1. avaliar individualmente a consistência de cada
modelo
– 2. avaliar a consistência externa (entre modelos)
– 3. mostrar que os modelos reflectem os requisitos reais
dos stakeholders
Validação de Requisitos
teste de requisitos
• um requisito "testável" significa que se
pode definir um ou mais testes a realizar
no sistema final de forma a poder ser
verificado se o sistema cumpre o
requisito
– cada requisito funcional no documento
de requisitos deve ser analisado e um
teste ser definido de forma a ser
verificado objectivamente se o sistema
satisfaz o requisito
Validação de Requisitos
teste de requisitos
• registo de teste
– 1.
– 2.
– 3.
– 4.
– 5.
identificador do requisito
requisitos relacionados
descrição do teste
problemas na realização do teste
comentários e recomendações
Verificação Automatizada de
Consistência
Requisitos em uma
Relatório dos proble-
linguagem formal
mas com os Requisitos
Processador
Analisador
de requisitos
de requisitos
Bases de dados
de requisitos
Validação de Requisitos
• Erros nos requisitos custam caro, portanto a sua
validação é importante
– corrigir um erro de requisitos = 100 x corrigir erro de
implementação
Validação de Requisitos
• “Checar” requisitos
– Consistência. Há conflitos de requisitos?
– Validade. O sistema provê as funções que atendem
as necessidades do cliente?
– Completude. Todas as funções requeridas pelo
cliente estão incluídas?
– Realismo. Os requisitos podem ser implementados
com o orçamento e tecnologia disponíveis?
– Verificabilidade. Os requisitos podem ser
verificados?
Técnicas de Validação de
Requisitos
• Revisões de requisitos
– Análise manual sistemática dos requisitos
• Prototipação
– Utilização de um modelo executável do
sistema
Técnicas de Validação de
Requisitos
• Geração de casos de teste
– Desenvolver testes para verificar os requisitos
• Análise automatizada da consistência
– Verificar a consistência de uma descrição de
requisitos estruturada
Revisões de Requisitos
• Revisões devem se preocupar com:
– Verificabilidade. O requisito é realisticamente
testável?
– Compreensibilidade. O requisito está bem
compreendido?
– Traço. A origem do requisito está claramente
identificada?
– Adaptabilidade. O requisito pode ser mudado
sem grande impacto noutros requisitos?
Requisitos Voláteis e Permanentes
• Requisitos Voláteis
 Mudança provável durante ou depois do
desenvolvimento
 Ex: Requisitos dos serviços bancários
 Tipos de requisitos voláteis:
 Mutáveis: mudanças no ambiente
 Emergentes: durante o desenvolvimento
 Consequentes: resulta da introdução do sistema de
computador
 Compatibilidade: depende de sistemas ou processos
particulares dentro da organização
GESTÃO
DE
REQUISITOS
Gestão de Requisitos
• É o processo de gerir as mudanças nos
requisitos durante o processo de
engenharia de requisitos e o processo de
desenvolvimento de sistemas
Gestão de Requisitos
• Requisitos são inevitavelmente
incompletos e inconsistentes
– Novos requisitos emergem durante o
processo, pois as necessidades do negócio
mudam e a compreensão dos requisitos
melhora
– Pode haver contradição no requisitos de
viewpoints diferentes
Gestão de Requisitos
• Mudança de requisitos
– A prioridade dos requisitos de viewpoints
diferentes pode mudar durante o processo de
desenvolvimento
– O negócio pode sofrer alterações durante o
desenvolvimento
Evolução de Requisitos
Compreensão
inicial do
Compreensão
modificada do
problema
problema
Requisitos
Requisitos
iniciais
modificados
Tempo
Plano de Gestão de Requisitos
• Durante o processo de engenharia de
requisitos deve-se planear:
– A identificação dos requisitos
– Um processo de gestão de mudança
– Políticas de traço
– Suporte de ferramentas CASE
referências e informação
adicional
• Gerald Kotonya, Ian Sommerville, Requirements
•
Engineering – Processes and Techniques, Wiley, 1998
(capítulo 3)
User Centerd Requirements Engineering: Theory and
Practice. Alistair Stutcliffe. Springer. 2002.
• Soares (2005). Introdução, Identificação e
Análise em Engenharia de Requisitos.
António Lucas Soares. 2005.
http://twiki.fe.up.pt/twiki/bin/view/ERSS0506/Er
ssDocumentos0506