Adaptado a partir de Gerald Kotonya and Ian Sommerville
Engenharia de Requisitos Engenharia de Requisitos Validação e Gestão Validação e Gestão
Análise e Concepção de Análise e Concepção de Sistemas de InformaçãoSistemas de Informação
Carla FerreiraCarla [email protected]
ACSI/Adaptado por Carla Ferreira
Engenharia de RequisitosEngenharia 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
Requirements elicitation Requirements analysis andnegotiation
Requirements documentationRequirements validation
Informal statement ofrequirements
Agreedrequirements
Draft requirementsdocument
Requirementsdocument and
validationreport
Decision point:Accept documentor re-enter spiral
START
Modelo Espiral para ERModelo Espiral para ER
ACSI/Adaptado por Carla Ferreira
Objectivos da ValidaçãoObjectivos 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çãoAnálise vs. Validação
Análise– Usa os requisitos tal como foram “extraidos” dos
stakeholders– “Have we got the right requirementsright 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 rightrequirements right”
ACSI/Adaptado por Carla Ferreira
Entradas e saídas da validaçãoEntradas e saídas da validação
List of problems
Agreed actions
Requirementsdocument
Organisationalstandards
Organisationalknowledge
Requirementsvalidation
ACSI/Adaptado por Carla Ferreira
Técnicas de VerificaçãoTécnicas de Verificação
Revisão Prototipagem Validação de modelos Definição de Testes
ACSI/Adaptado por Carla Ferreira
Revisão dos RequisitosRevisã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ãoChecklist 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ãoChecklist 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 ProblemasExemplo 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 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. FlorenceArtigo 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 1Artigo de A. Florence – Exemplo 1
Example 1Initial 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 4Artigo de A. Florence – Exemplo 4
Example 4Initial 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 11Artigo de A. Florence – Exemplo 11
Example 11Initial 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 requirementsWords 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
PrototipagemPrototipagem
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çãoPrototipagem para Validação
Chooseprototype
testers
Document and extend prototype system
Developtest
scenariosExecute
scenariosDocumentproblems
ACSI/Adaptado por Carla Ferreira
Desenvolvimento do Manual de UtilizadorDesenvolvimento 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 ModelosValidaçã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 modelosValidaçã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 DadosDiagrama de Fluxo de Dados
Checkuser
Checkitem
Issue item
User details
User status
Item status
Issued item
Update details
Library card
Requested item
ACSI/Adaptado por Carla Ferreira
Parafrasear ModelosParafrasear Modelos
Check userInputs and sources User’s library card from end-userTransformation function Checks that the user is a valid library
userTransformation outputs The user’s statusControl information User details from the databaseCheck i temInputs and sources The user’s status from Check userTransformation function Checks if an item is available for issueTransformation outputs The item’s statusControl information The availability of the itemIssue i temInputs and sources NoneTransformation function Issues an item to the library user. Items
are stamped with a return date.Transformation outputs The item issued to the end user
Database update detailsControl information Item status - items only issued if
available
ACSI/Adaptado por Carla Ferreira
Testar RequisitosTestar 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 TestesTemplate 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 TestesTemplate para Registo de Testes
Requirements tested: 10.(iv)
Related requirements: 10.(i), 10.(ii), 10.(iii),10.(vi), 10. (vii)
Test applied: For each class of user, preparea login script and identify the services expectedfor that class of user.
The results of the login should be a web pagewith a menu of available services.
Requirements problems: We don't know thedifferent classes of EDDIS user and theservices which are available to each user class.Apart from the administrator, are all otherEDDIS users in the same class?
Recommendations: Explicitly list all userclasses and the services which they can access.
10.(iv) When users access EDDIS, they will be presented with web pages and all services available to them
ACSI/Adaptado por Carla Ferreira
Exemplo
Defina testes que validem os seguintes requisitos de um sistema de controlo de acessos centralizado1. 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 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 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 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 ChaveResumo 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 RequisitosEngenharia 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 requisitosGestã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 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 requisitosFactores 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 requisitosFactores 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çaGestã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çaFases da gestão da mudança
Changeimplementation
Change analysisand costing
Problem analysis andchange specification
Identifiedproblem
Revisedrequirements
É 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
ACSI/Adaptado por Carla Ferreira
Formulário para propor mudanças 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 date:
CCB decision:
Comments
ACSI/Adaptado por Carla Ferreira
Análise da mudança e custos associadosAnálise da mudança e custos associados
Check requestvalidity
Find directlyaffected
requirementsFind dependentrequirements
Proposerequirements
changesAssess costs
of changeAssess costacceptability
Acceptedchange
Changerequest
Rejected request
Validrequest
Req. list
Requirements change list
Requirementschanges
Customerinformation
Costinformation
Rejected request
Rejected requestCustomer
information
Rejected request
ACSI/Adaptado por Carla Ferreira
Rejeitar pedidos de mudançaRejeitar 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
RastreabilidadeRastreabilidade
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 Rastreabilidade backward/forwardbackward/forward
Business plan Design SpecificationRequirements DocumentForward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
ACSI/Adaptado por Carla Ferreira
Tabela de rastreabilidadeTabela de rastreabilidade
Depends-onR1 R2 R3 R4 R5 R6
R1 * *R2 * *R3 * *R4 *R5 *R6
As tabelas de rastreabilidade mostram as relações entre requisitos ou entre componentes do desenho
ACSI/Adaptado por Carla Ferreira
Políticas de rastreabilidadePolí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
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
Factores que afectam a política de rastreabilidadeFactores que afectam a política de rastreabilidade
ACSI/Adaptado por Carla Ferreira
Resumo dos pontos-chaveResumo 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-chaveResumo 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
ExemplosExemplos
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 non-digitised”
– “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”
Top Related