Adaptado a partir de Gerald Kotonya and Ian Sommerville

Apresentação em tema: "Adaptado a partir de Gerald Kotonya and Ian Sommerville"— Transcrição da apresentação:

1 Adaptado a partir de Gerald Kotonya and Ian Sommerville
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

2 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

3 Modelo Espiral para ER

4 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

5 Análise vs. Validação Análise Validação
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”

6 Entradas e saídas da validação
Requirements document Should be a complete version of the document, not an unfinished draft. Formatted and organised according to organisational standards Organisational knowledge Knowledge, often implicit, of the organisation which may be used to judge the realism of the requirements Organisational standards Local standards e.g. for the organisation of the requirements document Problem list List of discovered problems in the requirements document Agreed actions List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions

7 Técnicas de Verificação
Revisão Prototipagem Validação de modelos Definição de Testes

8 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

9 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?

10 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?

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

12 Problemas Incompletude Ambiguidade Standards
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

13 Artigo de A. Florence "Reducing Risks Through Proper Specification of Software Requirements“ in CrossTalk 15(4):13-15, 2002. “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.”

14 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: Software shall be loaded onto the operational system only after it has been tested and approved.

15 Artigo de A. Florence – Exemplo 4
Example 4 Initial specification: 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: 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 and Levels of Protection for Sensitive Information Table )

16 Artigo de A. Florence – Exemplo 11
Example 11 Initial specification: 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.

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

18 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

19 Prototipagem para Validação

20 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

21 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

22 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

23 Diagrama de Fluxo de Dados

24 Parafrasear Modelos

25 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

26 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

27 Template para Registo de Testes
10.(iv) When users access EDDIS, they will be presented with web pages and all services available to them

28 Exemplo Defina testes que validem os seguintes requisitos de um sistema de controlo de acessos centralizado O sistema deve permitir que um administrador imprima os nomes e os números dos cartões dos utilizadores de uma sala O sistema deve permitir que o administrador altere a permissão de acesso de um utilizador O sistema deve permitir definir para utilizadores individuais um horário de acesso a determinadas salas

29 Definição de testes – Exemplo 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?

30 Definição de testes – Exemplo 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:

31 Definição de testes – Exemplo 3
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:

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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 Análise da mudança e custos associados

42 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

43 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

44 Rastreabilidade backward/forward

45 Tabela de rastreabilidade
As tabelas de rastreabilidade mostram as relações entre requisitos ou entre componentes do desenho

46 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

47 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

48 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

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

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