Adaptado a partir de Gerald Kotonya and Ian Sommerville Engenharia de Requisitos Validação e...

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]

mailto:[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


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


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


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”


Entradas e saídas da validaçãoEntradas e saídas da validação

List of problems

Agreed actions

Requirementsdocument

Organisationalstandards

Organisationalknowledge

Requirementsvalidation


Técnicas de VerificaçãoTécnicas de Verificação

Revisão Prototipagem Validação de modelos Definição de Testes


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


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?


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?


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.”


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


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.”


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.



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.)



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.


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”


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


Prototipagem para ValidaçãoPrototipagem para Validação

Chooseprototype

testers

Document and extend prototype system

Developtest

scenariosExecute

scenariosDocumentproblems


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


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


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


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


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


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


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


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


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


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?



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:



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:


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.


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


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


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


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


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


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


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


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


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


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


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


Rastreabilidade Rastreabilidade backward/forwardbackward/forward

Business plan Design SpecificationRequirements DocumentForward-to traceability Forward-from traceability

Backward-from traceability Backward-to traceability


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


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


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


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


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.


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”

Adaptado a partir de Gerald Kotonya and Ian Sommerville Engenharia de Requisitos Validação e...

Documents

Transcript of Adaptado a partir de Gerald Kotonya and Ian Sommerville Engenharia de Requisitos Validação e...