Análise e Concepção de
Sistemas de Informação
Engenharia de Requisitos
Validação e Gestão
Adaptado a partir de
Gerald Kotonya and Ian Sommerville
Carla Ferreira
[email protected]
Engenharia de Requisitos






Introdução
Processo de Engª de Requisitos
Levantamento de Requisitos
Análise de Requisitos
Negociação de Requisitos
Validação de Requisitos
– Revisão

Listas de Revisão
– Prototipagem
– Validação de Modelos
– Definição de Testes

Gestão de Requisitos
– Requisitos Estáveis e Voláteis
– Gestão de Mudança
– Rastreabilidade
ACSI/Adaptado por Carla Ferreira
Modelo Espiral para ER
Decision point:
Accept document
or re-enter spiral
Informal statement of
requirements
Requirements elicitation
Requirements analysis and
negotiation
START
Requirements
document and
validation
report
Agreed
requirements
Requirements validation
Draft requirements
document
ACSI/Adaptado por Carla Ferreira
Requirements documentation
Objectivos da Validação


Certificar que o documento de requisitos é
uma descrição aceitável do sistema a
implementar
Verificar se o documento de requisitos é:
– Completo e consistente
– Está em conformidade com os standards da
organização
– Não existem conflitos entre requisitos
– Não existem erros técnicos
– Não existem requisitos ambiguos
ACSI/Adaptado por Carla Ferreira
Análise vs. Validação

Análise
– Usa os requisitos tal como foram “extraidos” dos
stakeholders
– “Have we got the right requirements”

Validação
– Usa um versão preliminar do documento de
requisitos, i.e., usa os requisitos que já foram
acordados entre os stakeholders após a fase de
negociação
– “Have we got the requirements right”
ACSI/Adaptado por Carla Ferreira
Entradas e saídas da validação
Requirements
document
Organisational
knowledge
Organisational
standards
ACSI/Adaptado por Carla Ferreira
List of problems
Requ irements
validation
Agreed actions
Técnicas de Verificação




Revisão
Prototipagem
Validação de modelos
Definição de Testes
ACSI/Adaptado por Carla Ferreira
Revisão dos Requisitos

Um grupo de pessoas que:
–
–
–
–
lê e analisa os requisitos
procura problemas nesses requisitos
reune-se e discute os problemas encontrados
Acorda um conjunto de acções que abordam
esses problemas
ACSI/Adaptado por Carla Ferreira
Checklist para a Revisão

Compreensão
– Será que os leitores do documentos conseguem
compreender os requisitos?

Redundância
– Será que existe informação desnecessariamente repetida no
documento de requisitos?

Completude
– Será que falta algum requisito ou falta informação na
descrição de algum requisito?

Ambiguidade
– Será que os requisitos estão expressos usando termos que
são claros e explicitos? Será que leitores com diferentes
backgrounds podem dar interpretações diferentes dos
requisitos?
ACSI/Adaptado por Carla Ferreira
Checklist para a Revisão

Consistência
– As descrições dos diferentes requisitos têm contradições?
As contradições são entre requisitos individuais e requisitos
gerais do sistema?

Organização
– O documento está bem estruturado? As descrições dos
requistos estão organizadas de forma que os requisitos
relacionados estejam agrupados?

Conformidade com standards
– O documento de requisitos e os requisitos individuais estão
em conformidade com os standards definidos?

Rastreabilidade
– Os requisitos têm um identificador único, incluem links para
os requisitos relacionados e existe justificação para a
inclusão desses requisitos?
ACSI/Adaptado por Carla Ferreira
Exemplo de um Requisito com Problemas
“4. EDDIS will be configurable so that it will
comply with the requirements of all UK and
(where relevant) international copyright
legislation. Minimally, this means that EDDIS
must provide a form for the user to sign the
Copyright Declaration statement. It also
means that EDDIS must keep track of
Copyright Declaration statements which have
been signed/not-signed. Under no
circumstances must an order be sent to the
supplier if the copyright statement has not
been signed.”
ACSI/Adaptado por Carla Ferreira
Problemas

Incompletude
– Que legislação internacional sobre copyright é relevante?
– O que acontece quando a declaração de copyright não é
assinada?
– Se a assinatura é uma assinatura digital, como é que esta é
atribuida?

Ambiguidade
– O que significa assinar um formulário electrónico? É uma
assinatura fisica ou digital?

Standards
– Mais do que um requisito. Manutenção de copyright é um
requisito; emissão de documentos é outro requisito
ACSI/Adaptado por Carla Ferreira
Artigo de A. Florence

"Reducing Risks Through Proper Specification of Software
Requirements“ in CrossTalk 15(4):13-15, 2002.
– http://www.stsc.hill.af.mil/crosstalk/2002/04/florence.html
– “Requirement definition, specification, analysis, and validation and
verification are some of the biggest challenges faced by software
engineers. In many software requirements documentation, the
requirements are ambiguous and inconsistent. They may not be
uniquely identified, making them untraceable and difficult to test. In
many cases, they are specified at a level too high or too low at the
system or at the design level, not at the software requirements
level. If these challenges are addressed, the risk of developing
systems that do not satisfy requirements will be mitigated.”
ACSI/Adaptado por Carla Ferreira
Artigo de A. Florence – Exemplo 1

Example 1
Initial specification: Software will not be loaded from unknown
sources onto the system without first having the software tested
and approved.
Critique: If the software is tested and approved, can it be
loaded from unknown sources? If the source is known, can it be
loaded if it has not been tested and approved? This requirement
is ambiguous, which makes it difficult to implement and test. It is
stated as a negative requirement making it difficult to implement.
A unique identifier is not provided, which makes it difficult to
trace. The word "shall" is missing.
Re-specification: 3.2.5.2 Software shall be loaded onto the
operational system only after it has been tested and approved.
ACSI/Adaptado por Carla Ferreira
Artigo de A. Florence – Exemplo 4

Example 4
Initial specification: 3.2.5.9 All computer-resident information that
is sensitive shall have system access controls to ensure that it is
not improperly disclosed, modified, deleted, or rendered
unavailable. Access controls shall be consistent with the
information being protected and the computer system hosting the
data.
Critique: Two "shalls" under one identifier thus two requirements.
The requirement is vague and incomplete. What does "consistent"
mean? The requirement needs to identify the sensitive information.
As specified, it cannot be implemented or tested.
Re-specification: 3.2.5.9 All sensitive computer-resident
information shall have system access controls consistent with the
level of protection required to ensure that the information is not
improperly disclosed, modified, deleted, or rendered unavailable.
(Reference Sensitive Information Table 5.4.1 and Levels of
Protection for Sensitive Information Table 5.4.2.)
ACSI/Adaptado por Carla Ferreira
Artigo de A. Florence – Exemplo 11

Example 11
Initial specification: 3.2.8.6 When doing
calculations the software shall produce correct
results.
Critique: Really? This is not a requirement. This type
of requirements should not be specified. It should be
deleted.
Re-specification: Requirement deleted.
ACSI/Adaptado por Carla Ferreira
Words that flag unverifiable requirements*












flexible
easy or user-friendly
accommodate
safe
sufficiente or adequate
usable
when required or if required
fast or quickly
portable
light weight
small
maximise, minimise, optimise
* Retirado de “Effective Requirements Practices”
ACSI/Adaptado por Carla Ferreira
Prototipagem

Protótipos para a validação de requisitos
– demonstram os requisitos
– ajudam os stakeholders a descobrir problemas


Protótipos de Validação devem ser
completos, razoavelmente eficientes e
robustos. Deve ser possível usá-los da
mesma forma que o sistema a desenvolver
Os utilizadores devem ter acesso a manuais
de utilização e formação
ACSI/Adaptado por Carla Ferreira
Prototipagem para Validação
Choose
prototype
testers
Develop
test
scenarios
Execute
scenarios
Document and extend prototype system
ACSI/Adaptado por Carla Ferreira
Document
problems
Desenvolvimento do Manual de Utilizador

Escrever o manual do utilizador obriga a uma
análise detalhada dos requisitos
– Pode revelar problemas no documento

Informação para o manual do utilizador
– Descrição da funcionalidade e como é
implementada
– Partes dos sistema ainda não implementadas
– Como ultrapassar problemas
– Como instalar e usar o sistema
ACSI/Adaptado por Carla Ferreira
Validação de Modelos

Objectivos:
– Demonstrar que cada modelo é consistente
– Se existem diferentes modelos do sistema,
demonstrar que estes são interna e externamente
consistentes
– Demonstrar que os modelos refletem os requisitos
reais dos stakeholders do sistema

Parafrasear o modelo é uma técnica efectiva
de verificação
ACSI/Adaptado por Carla Ferreira
Validação de modelos

Estratégia para tradução de modelos em
linguagem natural
–
–
–
–
Identificar os inputs e a sua origem
Identificar função de transformação
Identificar que outputs são alterados
Identificar a informação de controlo
ACSI/Adaptado por Carla Ferreira
Diagrama de Fluxo de Dados
User details
Library card
Check
user
Requested item
User status
Check
item
Item status
Issued item
Issue item
Update details
ACSI/Adaptado por Carla Ferreira
Parafrasear Modelos
Check us er
Inputs and sources
Transformation function
Transformation outputs
Control information
Check i tem
Inputs and sources
Transformation function
Transformation outputs
Control information
Is s ue i tem
Inputs and sources
Transformation function
Transformation outputs
Control information
ACSI/Adaptado por Carla Ferreira
User’s library card from end-user
Checks that the user is a valid library
user
The user’s status
User details from the database
The user’s status from Check user
Checks if an item is available for issue
The item’s status
The availability of the item
None
Issues an item to the library user. Items
are stamped with a return date.
The item issued to the end user
Database update details
Item status - items only issued if
available
Testar Requisitos

Cada requisito deve ser testável
– Deve ser possível definir testes que verifiquem se
o requisito foi ou não satisfeito

Inventar testes para os requisitos é um
técnica efectiva de validação
– Um requisito com uma descrição ambigua dificulta
a formulação de testes

Cada requisito funcional deve ter um teste
associado
ACSI/Adaptado por Carla Ferreira
Template para Registo de Testes


Identificador do requisito
Requisitos relacionados
– O teste pode ser relevante para estes requisitos

Descrição do teste
– Breve descrição do teste, incluindo entradas e saídas do
sistema

Problemas do requisito
– Descrição dos problemas que tornaram a definição do teste
difícil ou impossível

Comentários e recomendações
– Aconselhar sobre a forma de resolver os problemas
encontrados no requisito
ACSI/Adaptado por Carla Ferreira
Template para Registo de Testes
10.(iv) When users access EDDIS, they will be presented
with web pages and all services available to them
Requ irements tested: 10.(iv)
Related requirements: 10.(i), 10.(ii), 10.(iii),
10.(vi), 10. (vii)
Test applied: For each class of user, prepare
a login script and identify the services expected
for that class of user.
The results of the login should be a web page
with a menu of available services.
Requirements problems: We don't know the
different classes of EDDIS user and the
services which are available to each user class.
Apart from the administrator, are all other
EDDIS users in the same class?
Recommendations: Explicitly list all user
classes and the services which they can access.
ACSI/Adaptado por Carla Ferreira
Exemplo

Defina testes que validem os seguintes
requisitos de um sistema de controlo de
acessos centralizado
1. O sistema deve permitir que um administrador
imprima os nomes e os números dos cartões dos
utilizadores de uma sala
2. O sistema deve permitir que o administrador
altere a permissão de acesso de um utilizador
3. O sistema deve permitir definir para utilizadores
individuais um horário de acesso a determinadas
salas
ACSI/Adaptado por Carla Ferreira
Definição de testes – Exemplo 1
1. O sistema deve permitir que um administrador imprima os
nomes e os números dos cartões dos utilizadores de uma
sala.
Teste:



Introduzir uma lista de nomes e números de cartões
associados a uma sala.
Usar a funcionalidade do sistema que permite imprimir a
lista de nomes associados a uma sala.
Comparar os dados introduzidos com a lista impressa.
Problemas: Como é que o administrador é
autenticado?
ACSI/Adaptado por Carla Ferreira
Definição de testes – Exemplo 2
2. O sistema deve permitir que o administrador altere a
permissão de acesso de um utilizador
Teste:




Usar o mesmo teste do requisito 1, mas adicionar
permissões de acesso.
Imprimir a lista de nome associadas à sala A1 e A4.
De seguida alterar as permissões de acesso a essas
salas e voltar a imprimir a lista de acesso às salas.
As listas de nomes impressos deve refletir as alterações
efectuadas.
Problemas:
ACSI/Adaptado por Carla Ferreira
Definição de testes – Exemplo 3
1. O sistema deve permitir definir para utilizadores individuais
um horário de acesso a determinadas salas.
Teste: Usar o mesmo teste do requisito 1. A listagem
deve incluir horários de acesso.
Problemas:
ACSI/Adaptado por Carla Ferreira
Resumo dos Pontos Chave

Validação de requisitos
– Verifica que o documento de requisitos não contém conflitos,
omissões e desvios aos standards da organização




Usar uma checklist de problemas para direccionar o
processo de revisão
Prototipagem é um método efectivo para a validação
de requisitos
Validar os modelos do sistema traduzindo esses
modelos para linguagem natural
Desenhar testes para os requisitos pode ajudar a
revelar problemas nos requisitos.
ACSI/Adaptado por Carla Ferreira
Engenharia de Requisitos






Introdução
Processo de Engª de Requisitos
Levantamento de Requisitos
Análise de Requisitos
Negociação de Requisitos
Validação de Requisitos
– Revisão

Listas de Revisão
– Prototipagem
– Validação de Modelos
– Definição de Testes

Gestão de Requisitos
– Requisitos Estáveis e Voláteis
– Gestão de Mudança
– Rastreabilidade
ACSI/Adaptado por Carla Ferreira
Gestão de requisitos

Tem como objectivo gerir:
– Alterações aos requisitos acordados
– Ligações entre requisitos
– Dependências entre o documento de requisitos e outros
documentos produzidos no processo de engenharia de
sistemas

Rastreabilidade de requisitos é essencial para uma
gestão efectiva dos requisitos

A rastreabilidade de requisitos tem várias vertentes:




Quem sugeriu o requisito
Porque é que o requisito existe
Que requisitos estão relacionados
Como é que o requisito está relacionado com outra informação,
tal como, o desenho do sistema, a implementação e manuais
do utilizador
ACSI/Adaptado por Carla Ferreira
Requisitos estáveis e voláteis


Alterações aos requisitos ocorrem durante as fases
de levantamento, análise e validação dos requisitos e
após o sistema estar operacional
Alguns requisitos estão mais sujeitos a mudanças do
que outros
– Requisitos estáveis estão associados à essência do sistema
e o seu domínio de aplicação
– Requisitos voláteis são especificos a uma instância do
sistema para um cliente e para um contexto particular
ACSI/Adaptado por Carla Ferreira
Factores de alteração de requisitos

Erros, conflitos e inconsistências nos requisitos
– Durante a análise e implementação dos requisitos, podem
emergir erros e inconsistências que têm que ser corrigidos
– Estes problemas podem ser encontrados durante a fase de
análise e validação dos requisitos ou nas fases seguintes do
processo de desenvolvimento


Evolução do conhecimento do sistema pelos
clientes/utilizadores
Problemas técnicos, de planificação, ou de custo
– Podem surgir problemas durante a implementação de um
requisito. O custo ou o tempo de implementação pode ser
demasiado elevado
ACSI/Adaptado por Carla Ferreira
Factores de alteração de requisitos

Alteração das prioridades do cliente
– As prioridades do cliente podem mudar durante o
desenvolvimento devido a vários factores



novos competidores
mudanças de pessoal na organização, ...
Alterações ao contexto do sistema
– O meio no qual o sistema vai ser instalado pode mudar,
causando alterações nos requisitos do sistema

Alterações na organização
– A organização pode sofrer alterações na sua estrutura e nos
seus processos criando novos requisitos do sistema
ACSI/Adaptado por Carla Ferreira
Gestão da mudança


Involve procedimentos, processos e standards para
gerir alterações aos requisitos do sistema
As politicas de gestão de mudança podem abordar:
– O processo associada aos pedidos de mudança e a
informação necessária para o processamento de cada um
desses pedidos
– O processo usado para analisar o impacto e os custos da
mudança e a informação associada à rastreabilidade
– Definir quem deve pertencer à equipa que considera
formalmente os pedidos de mudança
– O software de suporte ao processo de controlo da mudança
ACSI/Adaptado por Carla Ferreira
Fases da gestão da mudança

É identificado um problema num requisito
– Os requisitos são analisados com base no problema
encontrado e é definida uma proposta de mudança

A proposta de mudança é analisada
– Verificar quantos requisitos são afectados pela mudança e
determinar os custos temporais e monetários dessa
mudança

A mudança é implementada
– Produzir uma nova versão ou um conjunto de emendas ao
documento de requisitos
Identified
problem
Problem analysis and
change specification
ACSI/Adaptado por Carla Ferreira
Change analysis
and costing
Change
implementation
Revised
requirements
Formulário para propor mudanças
Requirements Change Request Form
Project:
Number:
Change requester:
Date:
Requirement number:
Change status:
Requested change:
Reason for change:
Change analyser:
Analysis date:
Related requirements:
Additional changes required:
Change assessment:
Change priority:
Estimated effort:
Date to CCB:
CCB decision:
Comments
ACSI/Adaptado por Carla Ferreira
CCB decision date:
Análise da mudança e custos associados
Rejected request
Change
request
Check request
validity
Valid
request
Find directly
affected
requirements
Req. list
Find dependent
requirements
Requirements change list
Cost
Requirements
information
changes
Propose
Assess cost
Assess costs
requirements
acceptability
of change
changes
Customer
information
ACSI/Adaptado por Carla Ferreira
Rejected request
Customer
information
Rejected request
Accep ted
ch ang e
Rejected request
Rejeitar pedidos de mudança

Se o pedido de mudança é inválido.
– O cliente pode propror uma mudança aos
requisitos que é desnecessária


Se o pedido de mudança resulta em
restrições que os utilizadores consideram
inaceitáveis
Se o custo ou o tempo de implementação da
mudança é demasiado elevado
ACSI/Adaptado por Carla Ferreira
Rastreabilidade

A informação de rastreabilidade permite determinar o
impacto da mudança nos requisitos.

Tipos de informação de rastreabilidade
– Rastreabilidade Backward-from

Ligação entre os requisitos e as suas origens em outros
documentos ou pessoas
– Rastreabilidade Forward-from

Ligação entre os requisitos e as componentes de desenho e
implementação
– Rastreabilidade Backward-to

Ligação entre os componentes de desenho e implementação e
os requisitos
– Rastreabilidade Forward-to

Ligação com outros documentos e requisitos relevantes
ACSI/Adaptado por Carla Ferreira
Rastreabilidade backward/forward
Business plan
Forward-to traceability
Requ irements Document
Forward-from traceability
Backward-from traceability
ACSI/Adaptado por Carla Ferreira
Design Specification
Backward-to traceability
Tabela de rastreabilidade

As tabelas de rastreabilidade mostram as
relações entre requisitos ou entre componentes
do desenho
Depends -on
R1
R1
R2
R3
R4
R5
R6
ACSI/Adaptado por Carla Ferreira
R2
*
R3
*
R4
*
*
R5
R6
*
*
*
*
Políticas de rastreabilidade


Definem que informação de rastreabilidade deve ser
mantida e como a manter
Políticas de rastreabilidade podem incluir
– A informação de rastreabilidade que deve ser mantida
– As técnicas a usar para a manutenção da rastreabilidade
– Definir quando colectar a informação de rastreabilidade
durante a engª de requisitos e o processo de
desenvolvimento do sistema
– Definir os papeis das pessoas responsáveis pela
manutenção informação de rastreabilidade
– Descrever a forma de abordar e documentar políticas de
excepção
– O processo de gestão da informação de rastreabilidade
ACSI/Adaptado por Carla Ferreira
Factores que afectam a política de rastreabilidade






Número de requisitos
Estimar o “tempo de vida” do sistema
Nível de maturidade da organização
Tamanho e composição da equipa do
projecto
Tipo de sistema
Exigências especificas do cliente
ACSI/Adaptado por Carla Ferreira
Resumo dos pontos-chave

Os requisitos mudam, porque ao longo do
desenvolvimento do sistema:
– os clientes desenvolvem um maior conhecimento
sobre as suas necessidades reais
– o meio organizacional e técnico no qual o sistema
será instalado evolui

Requistos estáveis e voláteis
– Os requisitos relacionados com a essência do
sistema tendem a ser mais estáveis
– Os requisitos relacionados com a forma de
implementação do sistema tendem a ser mais
instáveis
ACSI/Adaptado por Carla Ferreira
Resumo dos pontos-chave

Politicas de gestão de mudança definem:
– Os processos usados na gestão de mudança
– A informação a associar a cada pedido de mudança
– As responsabilidades individuais no processo de gestão de
mudança

A informação de rastreabilidade regista:
– Dependências entre requisitos
– A origem dos requisitos
– Dependências entre requisitos e a implementação do
sistema

Colectar e manter informação de rastreabilidade tem
um custo elevado.
ACSI/Adaptado por Carla Ferreira
Exemplos

Determine se os seguinte requisitos são estáveis ou
voláteis
– “EDDIS will be configurable so that it will comply with the
requirements of all UK and (where relevant) international
copyright legislation”
– “EDDIS will support the management of ordering and
supplying all types of documents, both digitised and nondigitised”
– “Users will access EDDIS via standard web browsers such
as Netscape and Internet Explorer”
– “Users will log-in to EDDIS via accounts which will be
created by the administrator. There will be two types of
accounts: individual and group accounts. In general,
individual accounts will have access to more services than
group accounts”
ACSI/Adaptado por Carla Ferreira