Você está na página 1de 52

Universidade Federal de Pernambuco

Departamento de Informtica
Tpicos Avanados em Engenharia de Software 2
(Engenharia de Requisitos e CASE)
Prof. Jaelson Brelaz Castro
Prof. Alexandre Marcos Lins de Vasconcelos

Requisitos No-funcionais
Wilson Jos dos Santos
Pedro Luciano Leite Silva
Juliano Manabu Iyoda
Outubro / 1998

Introduo
Requisitos No-funcionais
Temas:

Classificao de Requisitos No-Funcionais


Derivando Requisitos No-Funcionais
Requisitos para Sistemas Crticos
Engenharia de Requisitos para Safety-Related
System

Introduo
Objetivos

Colocar restries Antes e durante o processo


desenvolvimento
Definir as qualidades globais do sistema
Segurana (Safety ,Security)
Usabilidade
Confiana
Requisitos de desempenho
Colocar restries no servio do sistema sobre
exigncias do usurio (Interfaces, Qualidades,
Recurso, Tempo)

Introduo

Requisitos No-funcionais/funcionais
Exemplo: Requisito de segurana

O sistema s permitir acesso aos dados, com


autorizao.
O sistema ter um procedimento de autorizao
de usurios, nos quais tenham que se identificar
usando um (login) e uma senha. Somente
usurios autorizados tero acesso aos dados

Classificao de Requisitos
No-funcionais
CONTINUAO

Boehm-1976,( Deutsh e Willis,1998)

Qualidades exibidas por um software

Davis, 1992

No-comportamental

Portabilidade
Confiabilidade
Eficincia
Engenharia humana
Testabilidade, Understandabilidade, Modificabilidade

Classificao de Requisitos
No-funcionais

IEEE-Std 830 -1993

3 Specific Requeriments
3.1 Functional requeriments
3.2 Performance requeriments
3.3 Interface requirements
3.4 Operational requirements
3.5 Resource requirements
3.6 Verification requirements
3.7 Acceptance requirements
3.8 Documentation requirements
3.9 Security requirements
3.10 Portabiliry requirements
3.11 Quality requirements
3.12 Reliabiliry requirements
3.13 Maintainabiliry requirements
3.14 Safety requirements

Classificao de Requisitos
No-funcionais
CONTINUAO

Sommerville

Considera:

Interoperabilidade de software e hardware


Processos de desenvolvimento seguidos
Fatores externos, como Safety e Security regulations

Classificao de Requisitos
No-funcionais
CONTINUAO

Sommerville

Classificao de Requisitos
No-funcionais
CONTINUAO

Requisitos de Produtos

Requsitos que podem ser formulado precisamente


O sistema X ter uma disponibilidade de 999/1000 ou 99%.
Isso significa, que a cada 1000 pedidos no servio 999 devem
ser satisfeitos.
Um sistema X processar 8 transaes por segundo .

O cdigo executvel em Z de um sistema est limitado em 512


Kb.

Classificao de Requisitos
No-funcionais
CONTINUAO

Requisitos de Produtos

Requistos declarados no estado informal

O sistema ser desenvolvido para PC e MACINTOSH.


O sistema codificar todas as comunicaes externas em algoritmo
RSA.
O sistema X Ser implementado usando a verso 5 da BIBLIOTECA
Y.

Conflitos em requisitos de Produto

Requisito de utilizao de espao pode entrar em conflito com o


requisito que especifica um compilador padro, no qual no gerar o
cdigo compacto a ser usado.

Classificao de Requisitos
No-funcionais
CONTINUAO

Requisitos de Processos

O processo de desenvolvimento deve ser definido


claramente conforme o padro ISO 9000

O sistema deve ser desenvolvido usando a seqncia XYZ


da ferramenta CASE.

O gerenciamento de relatrios deve ser produzido a cada


duas semanas, informando o esforo gasto, com a
identificao do componente do sistema.

Um esquema de recuperao no desenvolvimento do


sistema deve ser especificado para o caso de acidentes.

Classificao de Requisitos
No-funcionais
CONTINUAO

Requisitos Externos

So requisitos que podem ser colocados no produto e no


processo e so derivados do ambiente que desenvolvido.

Eles podem fundamentar-se nas informaes de domnio


da aplicao.

Consideraes Oeganizacionais

Necessidades com outros sistemas

Safety ou regulamentos de proteo dos dados

Leis bsicas da fsica natural

Requisitos Externos
Exemplo 1

O sistema de registro de estudante.


O formato dos dados de registro de estudante disponvel pelo
SREC (Student Record System)
Seqncia de registro de dados usada na anotao como se segue:
Admission_No + Name + Address + University + Course
The individual data items are defined thus:
Admission_No = Year + Personal_Number
Year = 4{Digit}4
Personal_Number = 5{Dgit}5 Digit = 0 |1| 1 | .. | 9
Name = Surname + (Middlename) + Frstname
Surname =1[Letter}15+ (Hyphen) +1{Lettex}15
Middlename = {Letter)10
FirstrLame =1{Letter}15
Letter= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|X|Y|Z
Hyphen = Address =1{Char}140 Char = Digit |1| Letter | - | | ,
University =1{Letter}20
Course = 1{Letter}20

Requisitos Externos
Exemplo 2

Sistema de dados mdicos.


Organizao de proteo de dados oficial deve
certificar que todos os dados mantido, estejam de
acordo com a legislao de proteo de dados,
antes do sistema entrar em operao.

Requisitos Externos
Exemplo 3
Sistema de proteo nos
trens.
O tempo requerido para um trem
obter uma parada completa usa a
seguinte funo computadorizada:
trem = controle+gradiente
onde
gradiente= 9,8ms-2/gradiente
compensado/alpha e esses
valores so conhecidos para os
diversos tipos de trens

Derivando Requisitos no Funcionais

No so abordados adequadamente devido:

Dificuldade de elicitar

Limites relacionados ao projeto

Subjetivas => avaliaes empricas complexas.

Derivando Requisitos no Funcionais

Requisitos no funcionais esto relacionados a


requisitos funcionais.

Requisitos no funcionais tendem a conflitar entre


si.

No h regras para os requisitos no-funcionais.

Uma soluo uma proposta para uma nova


soluo

Propostas de Modelos

Chung modelo-orientado-a-metas
Dobson modelos lgicos
Kotonia (Kotonia and Sommerville, 1996)
pontos-de-vista

Traduzir objetivos gerais ou metas em


declaraes que se refiram s propriedades
mensurveis do sistema

Requisitos de Software (Preocupaes)

Os interessados tem preocupaes


importantes mas difcil de articular

So tipicamente no-funcionais

Objetivos crticos do negcio (padronizao)

Caractersticas essenciais do sistema como

segurana

desempenho

funcionalidade

manutenabilidade

Requisitos de Software (Preocupaes)


Atender as preocupaes em cada estgio
prioritrio

Atender requisitos funcionais

Expressam requisitos crticos "holsticos

sub-preocupaes

lista de verificao

Preocupaes x prioridades globais

Relacionamento entre necessidades do


usurio e requisitos no funcionais
Necessidades do
usurio
Funo
Desempenho

Alterao

Preocupaes do
usurio
1. Facilidade de uso
2. Acesso no autorizado
3. Possibilidade de falha
4. Utilizao de recursos
5. Desemp. de
verificao
6. Facilidade
comunicao
7. Facilidade de reparar
8. Facilidade de alterar
9. Facilidade de
transportar
10.Facilidade de
expandir

Requisitos nofuncionais
1. Usabilidade
2. Segurana
3. Confiana
4. Eficincia
5. Verificabilidade
6. Interoperabili.
7. Mantenabilidade
8. Flexibilidade
9. Portabilidade
10.Expansibilidade

Decomposio de Preocupaes
Sistema de Proteo de Trem
Safety
Coliso Descarrilamento
Excesso de Velocidade
para as condies de trajeto
O Sistema deve estar
apto a detectar e evitar
causas de descarrilamento

Acidente Pessoal
Dano de trajeto
Que informao sobre
dano de trajeto solicitado
pelo sistema ?
Como fornecida ?

O que sig. na verdadeexcesso


de velocidade ?
Sob que condies o excesso velocidade pode causar descarrilamento ?

Decomposio de Preocupaes
Sistema de Proteo de Trem
Compatibilidade
Hardware
Ambiente de
Execuo

Software
Tempo
Um requisito
afetar o
desempenho
do software ?

Fsica
Interface

O requisito
O Sistema deve
necessita de
ser executado num
dados que
ambiente de execuo
no esto
ADA
disponveis
na Interface ?
Pode esta funo ser fornecida pelo ambiente de execuo ?

Processo Modelo de Empresa

Loucopulos and Karakostas (1995)

metas da empresa

sub-metas

no-funcionais

Vantagem rastrear os requisitos nofuncionais

Relacionamento entre Empresa e


Metas do Sistema

Meta

Meta secundria

Visualizar os cenrios
de trfego areo

Requer sistema de
resposta em tempo real

Requisitos no-funcionais
Todos os dados
dos cenrios devem
ser mostrados
Requisitos
no-funcionais
quantitativos
Mostrar 100
trajetos

Mostrar 100
vetores

Os dados do radar
devem ser mostrados
em tempo real
A posio da aeronave
deve ser mostrada em
menos de 0.165s
Mostrar 500 tabelas
de smbolos

Atributos de requisitos no-funcionais


(Deutsch and Willis, 1988; Sommerville, 1996)

eles devem ser objetivos

um requisito no-funcional objetivo se no


expressa um desejo, uma meta, ou uma opinio
pessoal.

eles devem ser testveis

um requisito no-funcional testvel se h algum


processo pelo qual o requisito possa ser testado

Exemplos de medidas mtricas para


requisitos no-funcionais
Propriedade
Desempenho
Confiana
Disponibilidade
Tamanho
Usabilidade

Robustez
Portabilidade

Mtrica
transaes processadas por segundo
tempo de resposta para entrada do usurio
taxa de ocorrncia de falha
tempo mdio de falha
probabilidade de falha na demanda
kbytes
tempo necessrio para aprender 80% das
facilidades
nmero de erros cometidos pelo usurio
num dado perodo de tempo
tempo para reiniciar aps uma falha no
sistema
nmero de sistemas alvo

Requisitos no Funcionais
Pericles Loucopoulos e Vassilios Karakostas

Declaraes
de Requisitos
dos stakeholders
Modelo

Representao
das atividades
NFR

Empresarial

NFR
Estruturados

Modelo
requisitos
Funcionais

Requisitos para Sistemas Crticos


Sistemas crticos so sistemas cuja falha
causam danos significativos para as pessoas
ou organizaes.

econmicos
fsicos
humanos

Requisitos para Sistemas Crticos


H trs tipos principais:

Comerciais => dano econmico


Misso => realizao de tarefas

Safety => dano humano/ambiental

Requisitos para Sistemas Crticos

As principais restries no-funcionais:

confiana

desempenho

security (segurana para o sistema)

usabilidade

safety (segurana para o usurio/meio


ambiente )

Requisitos para Sistemas Crticos


requisitos no-funcionais so:

requisitos do sistema como um todo

pode levar a requisitos funcionais especficos


para o software ou outros sub-sistemas.

ocorre conflito entre eles

Requisitos para Sistemas Crticos

Identificados explicitamente e negociados

Cdigo => Desempenho => Confiana


Cdigo => Desempenho => Confiana
Segurana => Usabilidade

Safety contradiz Disponibilidade do sistema


compromisso entre os interessados para
satisfazer o sistema

Requisitos de Confiana
So Restries no comportamento do sistema
durante a execuo

Disponibilidade

exemplo: 3 minutos de indisponibilidade em 24


horas

Taxa de falha

ROCOF - taxa de ocorrncia de falhas num dado


perodo de tempo
MTTF - tempo mdio entre falhas no sistema

Requisitos de Desempenho
limitam a velocidade de operao de um
sistema:

Requisitos de resposta

Requisitos throughput

sistema deve responder a uma solicitao do usurio


dentro de 2 segundos.
processar pelo menos 10 transaes por segundo.

Requisitos de tempo

o sistema deve registrar os dados dos sensores pelo


menos 6 vezes por segundo

Requisitos de Desempenho

A memria RAM pode afetar

o comportamento do sistema na execuo


a velocidade de operao do sistema.

Devem ser especificados quantitativamente

Requisitos de Segurana (Security)


Os requisitos de segurana so includos num
sistema para

assegurar que no seja permitido o acesso


no autorizado ao sistema e aos seus dados

para assegurar integridade do sistema


quando de danos acidentais e maliciosos.

Requisitos de Usabilidade
Especificam a interface do usurio final e
interaes com o sistema.

podem ser especificados quantitativamente


so pouco concretos
preocupados em achar consistncia atravs
de diferentes sistemas

decises de projeto de sistema afetam que


formulrios sero usados.

Requisito de Segurana (Safety)

No h concenso sobre o que significa o termo


requisito seguro (safety requirement)
requisitos que esto diretamente relacionados
para assegurar operao segura
requisitos de sistemas de proteo que so
projetados para proteger contra acidentes.
o uso especfico do termo geralmente depende
da cultura e prtica da organizao na qual
usado.

Requisito de Segurana (Safety)


Requisitos safety so os requisitos no
devem que excluem situaes inseguras das
solues do sistema.

o sistema no deve permitir operao a


menos que o responsvel pela operao
esteja presente

Requisito de Segurana (Safety)

o sistema no deve permitir que seja


aplicado ao paciente uma dose de sedativo
maior que o valor mximo determinado pelo
mdico do pciente.
o sistema no deve operar se a temperatura
externa estiver menor que 4 graus Celsius.

Os requisitos safety podem no definir a


funcionalidade de um sistema mas, ao inves
disso, descrever um comportamento
inaceitvel ou indesejado do sistema.

ER em sistemas relacionados com


segurana (safety)

Sistemas em que uma falha pode causar


danos aos operadores, clientes, organizao,
ambiente ou pblico em geral

Controle de trfego areo

Controle de rotas de trem

Controle industrial

Produtos domsticos

ER em sistemas relacionados com


segurana (safety)

A segurana (safety) do sistema depende de


vrios requisitos no-funcionais (no apenas
de segurana):

Confiabilidade

Segurana de acesso (security)

Desempenho

Usabilidade

ER em sistemas relacionados com


segurana (safety)

Como derivar requisitos ?

Atividade de anlise de segurana

Preocupa-se em garantir que o sistema produzido


no coloca em perigo os usurios finais ou o
ambiente

Ciclo de vida de sistemas crticos


Anlise de danos

Avaliao de riscos

BCS
BCSand
and
IEE
1989
IEE 1989

Especificao dos requisitos de segurana


requisitos
funcionais

requisitos de
segurana

Definio dos sistemas de


segurana
Planejamento da validao

Projeto e implementao

Validao da segurana
Manuteno operacional

Verificao

Derivando requisitos

Guilhotina automtica para cortar papel

Lmina vertical

Motor

Software de controle (controlador)

Botes de incio e fim do corte

Um nico operador

Sensores

Derivando requisitos
requisitos abstratos
Elicitao

Anlise

Processo de requisitos
Documentao

Validao

Requisitos

Identificar consideraes de
segurana associados
requisitos de segurana
abstratos

Identificar
danos
Avaliar riscos

Analisar danos
Sugestes de
requisitos

Anlise de segurana

Derivando requisitos
Esmagar a mo do operador

Fault-tree
Fault-tree

Levenson
Levensonand
andHarvey
Harvey

Falha mecnica

Falha na
trava

Erro do operador

Falha no mecanismo
da lmina

Erro de implementao

Falha do controlador

Falha de software

Erro de projeto

Falha eltrica

Erro de especificao

Derivando requisitos

Falha mecnica

O sistema deve manter um log para verificar se a


manuteno est em dia. Se a manuteno
atrasar por 2 dias, o sistema desabilitado

A lmina da guilhotina deve estar ligada a duas


travas, ambas controladas pelo software
(controlador). Caso haja uma falha em alguma
trava, o sistema desabilitado

Derivando requisitos

Erro do operador

Dois botes fisicamente separados por 30 cm


devem ser pressionados simultaneamente

Se algum dos botes (ou ambos) estiverem


pressionados por mais de 0,25 segundos o
sistema deve ser desabilitado

Derivando requisitos

Falha do controlador

O software de controle deve ser formalmente


especificado em Z e a consistncia da
especificao deve ser demonstrada com
argumentos matemticos

A integridade dos dados do sistema deve ser


checada duas vezes a cada segundo. Se alguma
inconsistncia for detectada, o sistema
desabilitado

Resumo

Requisitos no-funcionais definem


qualidades ou atributos gerais do sistema

Existem trs tipos: produto, processo e


requisitos externos

As principais restries so:

Confiabilidade, desempenho, usabilidade e


segurana (safety e security)