Requisitos não funcionais

Transcrição

1 Análise e Concepção de Sistemas de Informação Requisitos Não Funcionais Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Requisitos não funcionais Definir requisitos não funcionais (RNFs) Esquemas de classificação de RNFs Técnicas de derivação de RNFs RNFs testáveis e métricas RNFs em sistemas críticos ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 2

2 O que são RNFs? Definem qualidades globais ou atributos do sistema Colocam/definem restrições no produto a ser desenvolvido e no processo de desenvolvimento externas que o produto deve manter Exemplos: Requisitos de integridade (safety), segurança, usabilidade, fiabilidade e desempenho ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 3 Requisitos funcionais e não funcionais Não existe uma distinção clara entre estes dois tipos de requisitos!! O facto de um requisito ser funcional ou não funcional pode depender de vários factores: Nível de detalhe a incluir no documento de requisitos. Grau de confiança existente entre o cliente do sistema e a equipa de desenvolvimento. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 4

3 Requisitos funcionais e não funcionais Exemplo R102 - O sistema deve garantir que os dados estão protegidos de acessos não autorizados. Convencionalmente, este seria um requisito não funcional porque não descreve especificamente a funcionalidade que deve ser suportada pelo sistema. R102 - O sistema deve incluir um procedimento de autorização de utilizadores, onde cada utilizador se deve identificar através de um username e password. Apenas os utilizadores autorizados desta forma podem aceder aos dados do sistema. Nesta forma, o requisito já tem a forma de um requisito funcional visto que especifica a função a incorporar no sistema. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 5 Tipos de RNFs Requisitos de desempenho Requisitos de interface Requisitos operacionais Requisitos de recursos Requisitos de verificação Requisitos de aceitação Segundo o IEEE-Std Requisitos de documentação Requisitos de segurança Requisitos de portabilidade Requisitos de qualidade Requisitos de fiabilidade Requisitos de manutenção Requisitos de integridade (safety) ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 6

4 Classificação de RNFs Non-functional requirements Process requirements Delivery requirements implementation requirements standards requirements Product requirements Usability requirements Reliability requirements Safety requirements Efficiency requirements Performance requirements Capacity requirements External requirements Legal constraints Economic constraints Interoperability requirements NFRs may be classified in terms of qualities that a software must exhibit (Boehm) ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 7 Requisitos do Produto Especificam as características que um sistema ou subsistema deve ter. Alguns requisitos de produto podem ser formulados de uma forma precisa, e por esta razão são fáceis de quantificar: Desempenho Capacidade Outros requisitos são mais difíceis de quantificar, e por consequência são descritos de forma mais informal: Usabilidade ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 8

5 Requisitos do Produto Exemplos Requisito de fiabilidade: O serviço X do sistema deve ter uma disponibilidade de 999/1000 ou 99%. Requisito de desempenho: O sistema Y deve conseguir tratar pelo menos 8 transacções por segundo. Requisito de espaço (e.g., RAM ou HD): O executável do sistema Z não pode ser superior a 512 Kbytes. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 9 Requisitos do Produto Conflitos entre requisitos É comum os requisitos do produto apresentarem conflitos entre si. Por exemplo: Um requisito de desempenho pode inviabilizar requisitos de fiabilidade e segurança E.g., para aumentar o desempenho desactivar o mecanismo de segurança de um servidor de base de dados O processo de obtenção de compromissos entre conflitos depende de vários factores: o nível de importância associado ao requisito; as consequências de alterações noutros requisitos; os objectivos gerais do negócio. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 10

6 Requisitos do Processo Requisitos do processo são restrições colocadas no processo de desenvolvimento do sistema. Requisitos do processo incluem: Requisitos aos standards de desenvolvimento e métodos a usar. Ferramentas CASE que devem ser usadas. Relatórios de gestão que devem ser produzidos. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 11 Requisitos do Processo Portabilidade O sistema deve ser desenvolvido para as plataformas PC e Macintosh. Afecta a forma como o sistema pode ser desenhado. Segurança Requisitos de implementação O sistema de encriptar todas as comunicações externas através do algoritmo RSA. Especifica que um determinado algoritmo deve ser usado no produto ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 12

7 Requisitos do Processo Standards O processo de desenvolvimento usado deve ser explicitamente definido e deve estar em conformidade com o standard ISO Ferramentas de desenvolvimento O sistema deve ser desenvolvido com a suite XYZ de ferramentas CASE. Gestão de projecto Todas as semanas deve ser produzido um relatório que descreve o esforço dispendido em cada componente existente no sistema. Gestão de riscos Mais exemplos Deve ser especificado um plano de recuperação de problemas no desenvolvimento do sistema. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 13 Requisitos Externos Podem ser colocados quer no produto quer no processo Derivados do ambiente onde o sistema está a ser desenvolvido Requisitos externos estão baseados em: informação do domínio de aplicação; considerações organizacionais; a necessidade do sistema interagir com outros sistemas; regulamentos de segurança ou de protecção de dados; e leis da natureza (e.g., leis da física). ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 14

8 Requisitos Externos Sistema de Dados Médicos Exemplos O responsável pela protecção dos dados da organização deve certificar que todos os dados são mantidos de acordo com legislação sobre protecção de dados antes de o sistema estar operacional. Sistema de Protecção em Comboios O tempo necessário para que um comboio pare é calculado usando a seguinte função: A desacelaração do comboio deve ser considerada como sendo: γ comboio = γ controlo + γ gradiente onde ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 15 Requisitos Externos Exemplos O primeiro requisito tem por base a necessidade do sistema estar em conformidade a legislação sobre protecção de dados O segundo requisito tem por base o domínio da aplicação e é uma especificação das caracteristicas físicas da travagem de um comboio. Os requisito externos raramente têm a forma o sistema deve... ou o sistema não deve.... Em geral, estes requisitos são descrições a ter conta do contexto do sistema. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 16

9 Técnicas de derivação de RNFs RNFs são difíceis de expressar Um conjunto de factores contribui para o acréscimo de dificuldade em expressar requisitos não funcionais: Algumas restrições estão relacionadas com a solução de desenho, a qual é desconhecida na fase dos requisitos. Algumas restrições são muito subjectivas e apenas podem ser determinadas através de avaliações empíricas complexas. Cada requisito não funcional tende a estar relacionado com um ou mais requisitos funcionais. Requisitos não funcionais tendem a criar conflitos e contradições com os restantes requisitos. Não existem regras universais para determinar se os requisitos não funcionais foram atingidos. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 17 Concerns Stakeholders normalmente têm um conjunto de concerns. Concerns são tipicamente não funcionais. E.g., Objectivos críticos do negócio. Caracteristicas essenciais do sistema (e.g. segurança). Integridade, desempenho, funcionalidade e facilidade de manutenção. Os concerns dos utilizadores podem estar relacionados com RNFs. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 18

10 Relação entre as necessidades dos utilizadores, concerns e RNFs User s need User s concern Non-functional requirement Function 1. Ease of use 2. Unauthorised access 3. Likelihood of failure 1. Usability 2. Security 3. Reliability Performance Change 1. Resource utilisation 2. Performance verification 3. Ease of interfacing 1. Ease of repair 2. Ease of change 3. Ease of transport? 4. Ease of expanding or upgrading capacity or performance? 1. Efficiency 2. Verifiability 3. Interoperability 1. Maintainability 2. Flexibility 3. Portability 4. Expandability ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 19 Concerns Forma de expressar requisitos críticos de forma holística. Os concerns podem ser decompostos em subconcerns até se atingir questões específicas. As questões agem como uma lista de verificação que garante que os requisitos não entram em conflito com as prioridades globais. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 20

11 Decomposição de concerns Safety Compatibility Collision Derailment Personal accident Hardware Software Physical Excess speed for track conditions Track damage Execution Environment Timing Interface System must be able to detect and avoid excess speed Under what conditions can excess speed cause derailment? What information about track damage is required by the system? How is this provided? System must execute in the trusted Ada execution environment Will a requirement affect the performance of the existing software? Does a requirement need data that isn't available through the HST interface? What does 'excess speed' mean in reality? Can this function be provided on the existng execution environment? ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 21 Derivação baseada em objectivos Relaciona os requisitos não funcionais com os objectivos da organização. A derivação baseada em objectivos é uma aproximação composta por três passos: Identificar os objectivos da organização. Decompor os objectivos em sub-objectivos. Identificar requisitos não funcionais. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 22

12 Exemplo de uma derivação baseada em objectivos Go al Visualise air traffic scenarios OM motivates IS-goal The system should perform in real-time motivates IS-NFR Display radar data in real-time IS-NFR The display must accommodate all data from the scenario motivates IS-NFR Aircraft position should be displayed in less than 3/16 sec of the radar sweep period motivates IS-NFR Display 100 tracks IS-NFR Display 100 meteorological plots IS-NFR Display 200 vectors IS-NFR Display 500 table symbols ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 23 RNFs Testáveis Stakeholders podem ter objectivos vagos que não são expressos de forma precisa. Requisitos vagos e imprecisos são problemáticos. Os RNFs devem satisfazer duas propriedades: Devem ser objectivos Devem ser testáveis (usar métricas mensuráveis) Mas, nem sempre é possível expressar RNFs objectivamente ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 24

13 Exemplos de métricas para RNFs Property Performance Reliability Availability Size Usability Robustness Portability Metric 1. Processed transactions per second 2. Response time to user input 1. Rate of occurrence of failure 2. Mean time to failure Probability of failure on demand Kbytes 1. Time taken to learn 80% of the facilities 2. Number of errors made by users in a given time period Time to restart after system failure Number of target systems ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 25 Requisitos para sistemas críticos Sistemas cujas falhas causam danos económicos, físicos ou humanos significativos (nas organizações ou pessoas). Existem três tipos principais de sistemas críticos: Sistemas críticos de negócio. Sistemas de missão-crítica. Sistemas críticos de segurança. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 26

14 RNFs para sistemas críticos Principais restrições não funcionais relevantes para sistemas críticos: Fiabilidade. Desempenho. Segurança. Usabilidade. Integridade. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 27 Fiabilidade Restrições no comportamento em tempo de execução do sistema. Podem ser consideradas sobre duas perspectivas: Disponibilidade o sistema deve estar disponível quando algum serviço é pedido pelos utilizadores. Nível de falhas a frequência com que o sistema não providencia um serviço pedido pelos utilizadores. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 28

15 Desempenho Restrição à velocidade da operação do sistema. Tipos de requisitos de desempenho: Requisitos de resposta Requisitos de débito (throughput) Requisitos temporais ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 29 Segurança Garantir que não é permitido acesso (não autorizado) ao sistema e seus componentes a integridade do sistema contra danos acidentais ou maliciosos Exemplos Permissões de acesso A gestão de utilizadores está restringida apenas ao administrador do sistema. Backup de dados Dever ser feito um backup dos dados do sistema cada 24 horas e as cópias de backup devem ser guardadas num local seguro que não seja no mesmo edificio onde se encontra o sistema. Comunicação Todas comunicações externas entre os servidor do sistema e os clientes devem ser encriptadas. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 30

16 Usabilidade Relacionado com a especificação de interfaces com o utilizador e interacções dos utilizadores com o sistema Aspectos relevantes manuais bem estruturados mensagens de erro informativas e interfaces consistentes ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 31 Usabilidade Atributos mensuráveis para requisitos de usabilidade Requisitos de acesso Medido em termos de anos de experiência com uma classe de aplicações ou simplesmente baseado na idade do utilizador. Requisitos de aprendizagem Denota o tempo necessário a aprender a usar o sistema. Este atributo pode ser medido em termos da velocidade de aprendizagem, por exemplo, horas de formação necessárias até ser possível o utilizador usar de forma independente o sistema. Requisitos de handling Denota o nível de erros dos utilizadores do sistema. Este atributo pode ser medido em termos de erros cometidos quando o utilizador trabalha a uma velocidade normal. Likeability Denota facilidade de utilização. A forma mais directa de medir o nível de satisfação dos utilizadores é a realização de inquéritos aos utilizadores directos e registar a proporção dos que gostam de trabalhar com o sistema. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 32

17 Integridade (safety) Definição formal: Os requisitos de integridade são os requisitos não deve que excluem situações inseguras do espaço de soluções possíveis do sistema. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 33 Integridade (safety) Exemplos O sistema de corte de papel não deve permitir a sua operação a não ser que a protecção da guilhotina esteja accionada O sistema não deve permitir que a dose do sedativo dada ao doente seja maior do que o valor máximo determinado pelo médico responsável O sistema não deve operar se a temperatura externa for inferior a 4º Celsius. ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 34

18 Resumo dos pontos-chave RNFs definem qualidades globais ou atributos do sistema RNFs podem ser classificados em três tipos: Requisitos do produto Requisitos do processo Requisitos externos Os requisitos do produto especificam as características que o sistema deve possuir. Os RNFs tendem a entrar em conflito entre si e ou com os restantes requisitos do sistema. Principais RNFs relevantes para os sistemas críticos: Fiabilidade, desempenho, segurança, usabilidade, integridade ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 35 Exercícios Um banco pretende desenvolver um sistema que permita aos seus clientes transferir dinheiro entre diferentes contas. Identifique os requisitos não funcionais deste sistema. Justifique a inclusão e importância de cada requisito não funcional. Definir requisitos de usabilidade para a sistema bibliotecário EDDIS ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville 36