Engenharia de Requisitos. Sumário

(1)

(QJHQKDULDGH6RIWZDUH

Engenharia de Requisitos

Carla Ferreira

carla.ferreira@dei.ist.utl.pt

Sumário

Caracterização

Objectivos Problemas Qualidades

Factores Não-Técnicos

Técnicas

Avaliação e Validação

Casos Notáveis

Exemplo

Conclusões

(2)

Engenharia de Requisitos 3

Objectivos

Identificação de quais são as

características do sistema a

desenvolver

Assegurar que essas características

correspondem aos objectivos do

negócio

Verificar se o sistema desenvolvido

satisfaz ou não as características

identificadas

Definição de Requisito

Um

UHTXLVLWR

é uma característica do

sistema, ou a descrição de algo que o

sistema é capaz de fazer para satisfazer

os seus objectivos

Em princípio os requisitos devem versar

sobre o espaço do problema,

_RTXr

, e

não sobre o espaço da solução,

_R

FRPR

, contudo pode acontecer que os

requisitos coloquem restrições ao

espaço da solução

(3)

Tipos de Requisitos

Os _{UHTXLVLWRVIXQFLRQDLV} descrevem uma

interacção entre o sistema e o seu ambiente

Os _{UHTXLVLWRVQmRIXQFLRQDLV} descrevem

restrições ao sistema que limitam as possibilidades de implementação. Têm impacto no desenho

Os _{UHTXLVLWRVGRGHVHQYROYLPHQWR}

descrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores

Requisitos Funcionais

Contexto do sistema

Reacção a estímulos externos

Estados do sistema

Informação manipulada pelo sistema

(4)

Requisitos Não-Funcionais

Usabilidade Desempenho Segurança Robustez Fiabilidade Disponibilidade Portabilidade Tecnologia de implementação

Ambiente físico da instalação

...

Requisitos de Desenvolvimento

Manutenção

Evolução

Documentação

Processo

Orçamento

Recursos humanos

Recursos computacionais

...

(5)

Actividades

1. Estudo de viabilidade – o sistema faz

sentido do ponto de vista do negócio e é realizável com o orçamento disponível

2. Análise de requisitos – entender como vai

ser o sistema analisando diversas fontes

3. Definição de requisitos – descrever os

requisitos de modo a serem entendido pelos utilizadores e clientes

4. Especificação de requisitos – descrever

detalhadamente os requisitos de modo a permitir fazer a ponte com a solução

Análise de Requisitos

Fontes dos Requisitos

Clientes e utilizadores

Organização e outros sistemas existentes Documentação existente

Matriz de tipos de requisitos Reutilização de requisitos Modelos do domínio Modelo do sistema actual

(6)

Análise de Requisitos

Identificar as pessoas, os processos e

os recursos envolvidos no problema e

documentar as suas relações

Identificar a fronteira do sistema

Separar os requisitos em três

categorias:

Têm que ser satisfeitos

É desejável que sejam satisfeitos Podem ser satisfeitos mas é possível eliminar

Documentos de Requisitos

'HILQLomRGH5HTXLVLWRV contém uma lista

de tudo o que o cliente espera que o sistema faça. Define um entendimento entre o cliente e a equipa de desenvolvimento sobre o que é que o sistema deve fazer. É escrito pelos clientes e os analistas de requisitos.

(VSHFLILFDomRGH5HTXLVLWRV rescreve o

documento de definição de requisitos em termos técnicos mais apropriados à equipa de desenvolvimento e às actividades de desenho. É escrito pelos analistas de requisitos.

(7)

Problemas dos Requisitos

Linguagem natural é inevitável no levantamento de requisitos

Dificuldades comunicação entre os utilizadores e a

equipa de desenvolvimento

Os utilizadores não concordam sobre os requisitos

Por vezes não é possível definir completamente o problema

Os requisitos evoluem durante o processo desenvolvimento

O levantamento de requisitos origina problemas de equilíbrio de poder

A descrição do problema é influenciada pela solução

Qualidades dos Requisitos

&RHUrQFLD – não devem ser ambíguos ou incoerentes

&RPSOHWXGH – todos os estados possíveis, alterações de estados, entradas, etc, devem ser descritos

Externamente Completos – todas as ligações com o ambiente desejadas pelo cliente estão descritas

Internamente Completos – não existem

referências indefinidas entre requisitos

5HDOLVPR – o que é pedido pelo cliente deve

(8)

Qualidades dos Requisitos

&ODUH]D– a descrição dos requisitos deve ser simples e clara para os utilizadores

9DOLGDGH – o requisito deve descrever algo que é de facto relativo ao problema

&HUWLILFDomR – deve ser possível escrever testes que demonstram que o requisito foi satisfeito

5DVWUHDELOLGDGH – deve ser possível

relacionar o requisito com a solução e também saber qual é a origem do requisito

Certificação de Requisitos

Os requisitos devem ser escritos de uma forma que permita a sua verificação objectiva. Para isso devem seguir-se as seguintes regras:

Escrever uma quantidade para cada advérbio e

adjectivo de modo a que o significado dos qualificadores seja claro e não ambíguo

Substituir pronomes por nomes de entidades Assegurar que cada substantivo é definido

exactamente uma única vez nos documentos de requisitos

(9)

Factores Sociais e Organizacionais

O sistema vai levar à redução de

gestores intermédios

Contudo, os gestores intermédios são uma importante fonte de informação sobre os requisitos do sistema

Os utilizadores e a equipa de

desenvolvimento não constituem um

todo partilhando os mesmos objectivos

pelo que vão surgir preconceitos entre

os intervenientes

Intervenientes

Existem diferentes intervenientes:

Gestores de Processo, definem a calendarização

Clientes e Utilizadores, entendem os requisitos

Gestores do Negócio, entendem o impacto do

sistema no negócio

Arquitectos do Sistema, usam os requisitos para a

definição da arquitectura

Avaliadores do Sistema, recolhem dados para os

testes e desenvolvem grupos de testes

Os diferentes intervenientes podem ter visões conflituosas sobre os requisitos, e.g., entre o cliente e o utilizador

(10)

Equipa -> Utilizadores

Não sabem o que querem

Não são capazes de exprimir o que

querem

As suas necessidades são políticas

Querem as coisas já

Não conseguem atribuir prioridades às

necessidades

Não assumem responsabilidades

Não aceitam compromissos

...

Utilizadores -> Equipa

Não entendem as necessidades operacionais

Dão demasiada importância aos aspectos técnicos

Tentam dizer-nos qual deve ser o nosso trabalho

Não conseguem implementar requisitos muito claros

Estão sempre fora do orçamento

Estão sempre atrasados

Pedem tarefas aos utilizadores que os desviam da sua tarefa principal

(11)

Técnicas

Representação de Requisitos

Prototipagem

Matriz Volere

Casos de Uso

Figuras Densas (

Rich Pictures

)

Representação de Requisitos

O objectivo das representações de

requisitos é:

Reduzir a imprecisão associada à linguagem natural

Separar a descrição do problema da construção da solução

(12)

Representações

Axiomática

Linguagem

Dados Abstractos

Diagramas de Fluxo de Dados

Tabelas de Decisão

Diagramas de Transição

Baseado em Objectos

Axiomática

Especifica as propriedades básicas do

sistema, como axiomas, e como o

comportamento gera novas

propriedades, os teoremas

Exige que o conjunto de axiomas seja

completo e coerente

Particularmente útil para sistemas

(13)

Axiomática – Exemplo (1)

(14)

Linguagem

Descreve requisitos como cadeias de

caracteres de uma linguagem

Permite automatizar a verificação da

completude e da coerência dos

requisitos

Particularmente útil no

desenvolvimento de compiladores

Dados Abstractos

Descreve o sistema baseado nos dados

Permite ignorar como os dados estão

implementados e são manipulados

Particularmente útil quando o problema

(15)

Diagramas de Fluxo de Dados

Representa

Processamento de dados

Relações de produção e consumo de dados

Repositórios de dados

Permite ignorar o fluxo de execução

DFDs - Exemplo

Library user Check user Item database Check item Library card User status requested item Issue item Item status issued item update user details UserID ItemID Update details item details Library assistant return date User database update details user details

(16)

Tabelas de Decisão

Representam regras estímulo/resposta

quando um conjunto de condições se

verifica

Diagramas de Transição

Representam o sistema em termos da

sua reacção a eventos internos e

externos

Permite ignorar a sequência total de

execução associada a cada interacção

e, desta forma, o comportamento

global do sistema

(17)

Diagramas de Transição

Baseado em Objectos

Estende a abordagem estática dos

dados abstractos com os conceitos de:

Encapsulação Hierarquia de classes Herança Polimorfismo

(18)

Baseado em Objectos

1 ! 1 * * * 1 * 1 * " "#$ "% * 1 *

Linguagens Formais - Z

(19)

Escolher uma Representação

&

É necessário analisar as diferentes técnicas de representação de acordo com os

seguintes itens:

'

Implementação: Ajuda na implementação?

' Testes: Ajuda nos testes?

' Legibilidade: A especificação é legível para os

peritos do domínio?

'

Manutenção: A especificação pode ser útil durante a manutenção?

' Modularidade: Permite decomposição?

' Expressividade: Com que facilidade representa as

abstracções do problema?

Escolher uma Representação

' Correcção: Permite a detecção de incorrecções ou

incoerências?

'

Verificação: A especificação é verificável formalmente?

' Geração: Se possui geração de código este é

eficiente?

'

Suporte Computacional: Possui suporte computacional?

' Incompleta: Suporta informação incompleta? ' Aprendizagem: Qual é a curva de aprendizagem?

'

Disciplina: Conduz a uma disciplina de escrita de requisitos?

(20)

Protótipos para Requisitos

Os protótipos permitem detalhar e

completar a lista de requisitos

A prototipagem pode ser aplicada a:

Interfaces

Validar requisitos funcionais

Validar requisitos não funcionais como o desempenho

Mostrar, à gestão, da viabilidade da

aplicação

Desenho

...

Tipos de Protótipos

Consideram-se dois tipos de protótipos:

Protótipo descartável – o principal

objectivo é validar ou clarificar os requisitos

Protótipo evolutivo – adicionalmente ao

protótipo descartável também tem como objectivo o desenvolvimento incremental do sistema final

(21)

Técnicas para Prototipagem

Linguagens de especificação

executáveis – linguagens formais, e.g.

Z

Linguagens de alto nível – linguagens

dinâmicas, e.g. Smalltalk

Geradores de aplicações – geração de

código, e.g. SQL

Composição de componentes

reutilizáveis – composição de

componentes independentes, e.g. UNIX

Shells

Matriz Volere

Estrutura a linguagem natural

Enumera requisitos não funcionais tipo

Look and feel

Usabilidade Desempenho Operacionais Manutenção e portabilidade Segurança Culturais e políticos Legais

(22)

Matriz Volere

Exemplos de medidas para verificação

da conformância de requisitos

Requisito funcional – o resultado de um

cálculo é o esperado

Desempenho – 98% das transacções têm

um tempo de resposta inferior a 1,5 segundos

Operacionais – 90% de um painel de

trabalhadores conseguem utilizar o produto numa simulação das condições operacionais

(23)

Matriz Volere

Manutenção – cada 10 alterações ao código devem estar operacionais em 3 semanas

Segurança – o produto deve estar conforme uma determinada norma

Legal – o departamento jurídico deve certificar que o produto está de acordo com a legislação

Look and feel

– está de acordo com uma norma

Casos de Uso

Os casos de uso descrevem o sistema

do ponto de vista do utilizador. As

vantagens são:

Delimitam o sistema

Cada caso de uso pode ser isolado dos restantes pelo que facilita a decomposição do espaço do problema

Podem ser usados para estimar o tempo e o esforço necessário ao desenho e

codificação do sistema

O desenvolvimento do sistema pode ser

(24)

Casos de Uso

BANCO Cliente do Banco Levantar Dinheiro Depositar Dinheiro

Transferir Dinheiro entre Contas

Autenticação <<include>>

<<include>> <<include>>

Figuras Densas

Permitem fazer uma análise do negócio

ao nível de abstracção dos clientes e

utilizadores

Registar e raciocinar sobre o contexto do

trabalho e a forma como este influência o desenho

Início da ponte entre o negócio e os

requisitos

Técnica que facilita a interacção e a

comunicação entre os clientes e a

equipa

(25)

Figuras Densas

Consideram os seguintes elementos

Estrutura – refere os aspectos do contexto do trabalho que vão ser alterados

Processo – refere as transformações que

ocorrem no processo de trabalho

Objectivos – refere as motivações de cada um dos intervenientes

Devem-se captar as tensões entre os

intervenientes

(26)

Validação de Requisitos

List of problems Agreed actions Requirements document Organisational standards Organisational

knowledge Requirementsvalidation

Validação de Requisitos

A validação de requisitos é o processo

que determina se a especificação de

requisitos é coerente com a definição

de requisitos, ou seja, se os requisitos

satisfazem as necessidades dos

clientes:

(

Cada especificação está relacionada com um requisito no documento de definição de requisitos

(

Cada requisito está tratado no documento de especificação de requisitos

(27)

Técnicas de Validação

Técnicas manuais

( Leitura ( Cruzamento de informação ( Entrevistas ( Revisões ( Listas de verificação ( Cenários ( Demonstração matemática

Técnicas de Validação

Técnicas automáticas são possíveis se

os requisitos estiverem representados

de modo a poderem ser tratados

computacionalmente – bases de dados,

linguagens formais, protótipos

( Cruzamento de informação ( Prototipagem ( Simulação ( Demonstração matemática

(28)

Revisão de Requisitos

Plan review _documentsDistribute

Prepare for

review Hold reviewmeeting

Follow-up actions Revise document

Revisão de Requisitos

&

Juntar representantes da equipa de desenvolvimento, do cliente e dos utilizadores para:

' Rever objectivos do sistema

' Comparar os requisitos com os objectivos para

confirmar se são todos necessários

' Verificar a completude e correcção dos requisitos ' Se foram identificados riscos avaliar com o cliente

se a abordagem de solução proposta é a melhor

' Definir como é que a satisfação de requisitos vai

(29)

Métricas para Requisitos

&

Desempenho – transacções processadas por segundo, tempo de resposta a um pedido do utilizador, tempo de refrescar o ecrã

)

Usabilidade – tempo de treino, número de menus de ajuda

)

Robustez – tempo de recomeçar após faltas

)

Portabilidade – número de sistemas alvo, número de comandos dependentes do alvo

)

Tempo de desenvolvimento – uma função do número de requisitos dá uma estimativa do esforço de desenvolvimento, e.g., COCOMO

Métricas para Requisitos

)

Impacto – qual o impacto que a alteração de um particular tipo de requisitos tem no

sistema

)

Complexidade – qual a complexidade

associada à implementação dos requisitos. Para isso pode-se perguntar aos arquitectos e avaliadores sobre cada requisito:

*

Conhecido

* Novo mas parecido

* Novo mas será possível encontrar uma solução

*

Não se entende e não se sabe se será possível encontrar uma solução

(30)

Casos Notáveis

Padrões de Interacção com o Cliente

(

Linda Rising

( Customer Interaction Patterns ( In Harrison2000. Capítulo 26.

Um Processo de Análise de Requisitos

para Desenvolvimento com Objectos

( Bruce Whitenack

( RAPPeL: A Requirements Analysis Process

Pattern Language for Object Oriented Development