Requisitos Nao Funcionais

1

Adaptado a partir de Gerald Kotonya and Ian Sommerville

5HTXLVLWRV�1mR�)XQFLRQDLV5HTXLVLWRV�1mR�)XQFLRQDLV

Anál ise e Conc epç ão de Anál ise e Conc epç ão de Sist em as de Inform aç ãoSist em as de Inform aç ão

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville�

RequisitosRequisitos nãonão funcionaisfuncionais

� 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 �

O O queque sãosão RNFsRNFs??

� 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


RequisitosRequisitos funcionaisfuncionais e e nãonão funcionaisfuncionais

� Não existe uma distinção clara entre estes doistipos de requisitos!!

� O facto de um requisito ser funcional ou nãofuncional 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.


ExemploExemplo�� R102 R102 -- O O sistemasistema devedeve garantirgarantir queque osos dados dados estãoestão protegidosprotegidos de de

acessosacessos nãonão autorizadosautorizados..

Convencionalmente, este seria um requisito não funcional porque nãodescreve especificamente a funcionalidade que deve ser suportada pelosistema.

�� R102 R102 -- O O sistemasistema devedeve incluirincluir um um procedimentoprocedimento de de autorizaçãoautorização de de utilizadoresutilizadores, , ondeonde cadacada utilizadorutilizador se se devedeve identificaridentificar atravésatravés de um de um username e password. username e password. ApenasApenas osos utilizadoresutilizadores autorizadosautorizados destadesta forma forma podempodem acederaceder aosaos dados do dados do sistemasistema..

Nesta forma, o requisito já tem a forma de um requisito funcional visto queespecifica a função a incorporar no sistema.

RequisitosRequisitos funcionaisfuncionais e e nãonão funcionaisfuncionais


TiposTipos de de RNFsRNFs

� Requisitos de desempenho� Requisitos de interface� Requisitos operacionais� Requisitos de recursos� Requisitos de verificação� Requisitos de aceitação

6HJXQGR�R�,(((�6WG��± ��«

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


ClassificaçãoClassificação de de RNFsRNFs

Non-functionalrequirements

Processrequirements

Product requirements Externalrequirements

Deliveryrequirements

implementationrequirements

standards

requirements

Usability requirements

Reliability requirements

Safety requirements

Efficiency requirements

Performance requirements

Capacity requirements

Legalconstraints

Economicconstraints

Interoperabilityrequirements

1)5V PD\�EH�FODVVLILHG�LQ�WHUPV�RI�TXDOLWLHV�WKDW�D�VRIWZDUH�PXVW�H[KLELW´(Boehm)

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville

RequisitosRequisitos do do ProdutoProduto

� Especificam as características que um sistema ou subsistemadeve ter.

� Alguns requisitos de produto podem ser formulados de umaforma precisa, e por esta razão são fáceis de quantificar: – Desempenho– Capacidade

� Outros requisitos são mais difíceis de quantificar, e porconsequência são descritos de forma mais informal:– Usabilidade

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville


�� RequisitoRequisito de de fiabilidadefiabilidade: : –– O O serviçoserviço X do X do sistemasistema devedeve terter umauma disponibilidadedisponibilidade de 999/1000 de 999/1000

ouou 99%. 99%.

�� RequisitoRequisito de de desempenhodesempenho: : –– O O sistemasistema Y Y devedeve conseguirconseguir tratartratar pelopelo menosmenos 8 8 transacçõestransacções porpor

segundosegundo.

�� RequisitoRequisito de de espaçoespaço (e.g., RAM (e.g., RAM ouou HD): HD): –– O O executávelexecutável do do sistemasistema Z Z nãonão podepode ser superior a 512 Kbytes.ser superior a 512 Kbytes.

ExemplosExemplos

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville � �

� É comum os requisitos do produto apresentarem conflitosentre 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 conflitosdepende 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.

ConflitosConflitos entreentre requisitosrequisitos


ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville ��

RequisitosRequisitos do do ProcessoProcesso

� Requisitos do processo são restrições colocadasno 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.


� Portabilidade–– O O sistemasistema devedeve ser ser desenvolvidodesenvolvido parapara as as plataformasplataformas

PC e Macintosh.PC e Macintosh.� Afecta a forma como o sistema pode ser desenhado.

�� SegurançaSegurança–– O O sistemasistema de de encriptarencriptar todastodas as as comunicaçõescomunicações

externasexternas atravésatravés do do algoritmoalgoritmo RSA.RSA.� Especifica que um determinado algoritmo deve ser usado no

produto

RequisitosRequisitos do do ProcessoProcessoRequisitosRequisitos de de implementaçãoimplementação


� Standards– O processo de desenvolvimento usado deve ser explicitamente

definido e deve estar em conformidade com o standard ISO 9000.� Ferramentas de desenvolvimento

– O sistema deve ser desenvolvido com a suite XYZ de ferramentasCASE.

� 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

– Deve ser especificado um plano de recuperação de problemas no desenvolvimento do sistema.

RequisitosRequisitos do do ProcessoProcessoMaisMais exemplosexemplos……


RequisitosRequisitos ExternosExternos

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


� Sistema de Dados Médicos– 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 estaroperacional.

� 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 …

RequisitosRequisitos ExternosExternosExemplosExemplos……


Exemplos de requisitos externos (cont.)Exemplos de requisitos externos (cont.)

γgradiente = 9.81 ms-2 * gradiente compensado / alpha

onde os valores de 9.81 ms-2/ alpha são conhecidos para os diferentes tipos de comboios.γcontrolo é inicializado a 0.8 ms-2 – este valor é parametrizado de forma a permanecer ajustável.

� A figura seguinte ilustra um exemplo da desaceleração de um comboio usando as parábolas derivadas da formula acima.


Exemplos de requisitos externos (cont.)Exemplos de requisitos externos (cont.)

γ = γ + γcontrol gradient1

γ = γ + γcontrol gradient2

V

DistanceFront of train Change of gradient

Speed of train on application of brakes

Speed of rain at change of gradient


� O primeiro requisito tem por base a necessidade do sistemaestar 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 sistemadeve...” ou “o sistema não deve...”. Em geral, estes requisitossão descrições a ter conta do contexto do sistema.

RequisitosRequisitos ExternosExternosExemplosExemplos……


TécnicasTécnicas de de derivaçãoderivação de de RNFsRNFs

� RNFs são difíceis de expressar…

� Um conjunto de factores contribui para o acréscimo de dificuldade emexpressar 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 maisrequisitos funcionais.

– Requisitos não funcionais tendem a criar conflitos e contradições com osrestantes requisitos.

– Não existem regras universais para determinar se os requisitos nãofuncionais foram atingidos.


&RQFHUQV&RQFHUQV

� Stakeholders normalmente têm um conjunto de FRQFHUQV.

� &RQFHUQV 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 FRQFHUQV dos utilizadores podem estarrelacionados com RNFs.


RelaçãoRelação entreentre as as necessidadesnecessidades dos dos utilizadoresutilizadores, , FRQFHUQVFRQFHUQV e e RNFsRNFs

� �"!$# % �'&(!(!() � �(!*# % �,+.-/&"+0!*#�& 12-/&"3 4�5*&"+06�7 -/&.8*9# !":/5$7 # !$;<!*&.6

Function 1. Ease of use2. Unauthorised access3. Likelihood of failure

1. Usability2. Security3. Reliability

Performance 1. Resource utilisation2. Performance verification3. Ease of interfacing

1. Efficiency2. Verifiability3. Interoperability

Change 1. Ease of repair2. Ease of change3. Ease of transport ?4. Ease of expanding or upgrading capacity

or performance ?

1. Maintainability2. Flexibility3. Portability4. Expandability


&RQFHUQV&RQFHUQV

� 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 quegarante que os requisitos não entram em conflito com as prioridades globais.

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville ��=

DecomposiçãoDecomposição de de FRQFHUQVFRQFHUQV

CompatibilitySafety

Collision DerailmentPersonalaccident

Hardware Software Physical

Excess speed for track conditions

Track damage

System must be able todetect and avoid excessspeed

Under what conditions can excess speed cause derailment?

What information about track damage is required by the system? How is this provided?

InterfaceExecutionEnvironment

Timing

Will a requirement affectthe performance of theexisting software?

Does a requirement needdata that isn’t availablethrough the HST interface?

System must execute in the trustedAda execution environment

Can this function beprovided on the existngexecution environment?

What does ’excess speed’ mean in reality?

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville �>�

DerivaçãoDerivação baseadabaseada emem objectivosobjectivos

? Relaciona os requisitos não funcionais com osobjectivos da organização.

? A derivação baseada em objectivos é umaaproximaçã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 @�A

ExemploExemplo de de umauma derivaçãoderivação baseadabaseada emem objectivosobjectivos

Go alVisualise air traffic scenarios

OM

IS-g o alThe system should perform inreal-time

motivates

motivates

IS-NFRThe display must accommodateall data from the scenario

IS-NFRDisplay radar datain real-time

IS-NFRAircraft position should be displayed in lessthan 3/16 sec of the radar sweep period

motivates

IS-NFRDisplay 500 tablesymbols

IS-NFRDisplay 200 vectors

motivates

IS-NFRDisplay 100meteorological plots

IS-NFRDisplay 100 tracks

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville @�B

RNFsRNFs TestáveisTestáveis

C Stakeholders podem ter objectivos vagos que não sãoexpressos de forma precisa.

C Requisitos vagos e imprecisos são problemáticos.

C Os RNFs devem satisfazer duas propriedades:– Devem ser objectivos– Devem ser testáveis (usar métricas mensuráveis)

C Mas, … nem sempre é possível expressar RNFsobjectivamente…

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville @�D

ExemplosExemplos de de métricasmétricas parapara RNFsRNFs

3URSHUW\ 0HWULFPerformance 1. Processed transactions per second

2. Response time to user inputReliability 1. Rate of occurrence of failure

2. Mean time to failureAvailability Probability of failure on demandSize KbytesUsability 1. Time taken to learn 80% of the facilities

2. Number of errors made by users in a given timeperiod

Robustness Time to restart after system failurePortability Number of target systems

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville @�E

RequisitosRequisitos parapara sistemassistemas críticoscríticos

C Sistemas cujas “falhas” causam danos económicos, físicosou humanos significativos (nas organizações ou pessoas).

C 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 @�F

RNFsRNFs parapara sistemassistemas críticoscríticos

? Principais restrições não funcionais relevantespara sistemas críticos:

– Fiabilidade.

– Desempenho.

– Segurança.

– Usabilidade.

– Integridade.

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville G�H

FiabilidadeFiabilidade

C Restrições no comportamento em tempo de execução do sistema.

C Podem ser consideradas sobre duas perspectivas:

– Disponibilidade – o sistema deve estar disponível quandoalgum serviço é pedido pelos utilizadores.

– Nível de falhas – a frequência com que o sistema nãoprovidencia um serviço pedido pelos utilizadores.

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville G�I

DesempenhoDesempenho

? 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 G�@

SegurançaSegurança

J Garantir– que não é permitido acesso (não autorizado) ao sistema e seus

componentes– a integridade do sistema contra danos acidentais ou maliciosos

J Exemplos– Permissões de acesso

K A gestão de utilizadores está restringida apenas ao administrador do sistema.

– Backup de dadosK 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 edificioonde se encontra o sistema.

– ComunicaçãoK Todas comunicações externas entre os servidor do sistema e os clientes devem

ser encriptadas.

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville G�G

UsabilidadeUsabilidade

C Relacionado com a especificação de– interfaces com o utilizador e – interacções dos utilizadores com o sistema

C Aspectos relevantes– manuais bem estruturados– mensagens de erro informativas e – interfaces consistentes

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville G>L

UsabilidadeUsabilidade

J Requisitos de acesso– Medido em termos de anos de experiência com uma classe de aplicações

ou simplesmente baseado na idade do utilizador. J Requisitos de aprendizagem

– Denota o tempo necessário a aprender a usar o sistema. Este atributo podeser medido em termos da velocidade de aprendizagem, por exemplo, horasde formação necessárias até ser possível o utilizador usar de forma independente o sistema.

J 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 umavelocidade normal.

J 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 utilizadoresdirectos e registar a proporção dos que gostam de trabalhar com o sistema.

Atributos mensuráveis para requisitos de usabilidade

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville G�A

IntegridadeIntegridade

M Definição formal:Os requisitos de integridade são os requisitos“ não deve…” que excluem situações insegurasdo espaço de soluções possíveis do sistema.

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville N�O

IntegridadeIntegridade

C O sistema de corte de papel não deve permitir a suaoperação a não ser que a protecção da guilhotina estejaaccionada

P O sistema não deve permitir que a dose do sedativo dada ao doente seja maior do que o valor máximo determinadopelo médico responsável

P O sistema não deve operar se a temperatura externa for inferior a 4º Celsius.

ExemplosExemplos……

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville N�Q

Resumo dos pontosResumo dos pontos--chavechave

J RNFs definem qualidades globais ou atributos do sistema

J RNFs podem ser classificados em três tipos: – Requisitos do produto– Requisitos do processo– Requisitos externos

J Os requisitos do produto especificam as características que o sistema deve possuir.

J Os RNFs tendem a entrar em conflito entre si e ou com osrestantes requisitos do sistema.

J Principais RNFs relevantes para os sistemas críticos:– Fiabilidade, desempenho, segurança, usabilidade, integridade

ACSI/Requisitos NF, Adaptado de Kotonya&Sommerville N�R

ExercíciosExercícios

M 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 necessidade e importância de cada

requisito não-funcional.

M Definir requisitos de usabilidade para a sistema bibliotecário EDDIS

Education

Requisitos Nao Funcionais