6 - engenharia de requisitos - fenix.tecnico.ulisboa.pt · engenharia de requisitos 21 técnicas...

1

(QJHQKDULD�GH�6RIWZDUH

Engenharia de Requisitos

Carla [email protected]

Engenharia de Requisitos 2

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


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, R�TXr, 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 UHTXLVLWRV�IXQFLRQDLV descrevem uma

interacção entre o sistema e o seu ambiente� Os UHTXLVLWRV�QmR�IXQFLRQDLV descrevem

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

� Os UHTXLVLWRV�GR�GHVHQYROYLPHQWRdescrevem 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


Actividades1. 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� 'HILQLomR�GH�5HTXLVLWRV 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.

� (VSHFLILFDomR�GH�5HTXLVLWRV 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

ser realizável

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 peritos

13


Axiomática – Exemplo (1)


Axiomática – Exemplo (2)

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

não está baseado em funções

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

Libraryuser

Checkuser

Item database

Checkitem

Librarycard

User status

requesteditem

Issueitem

Itemstatus

issueditem

updateuser

details

UserID

ItemID

Update detailsitem details

Libraryassistant

return date

User database

update detailsuser 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

� Facilita a classificação de entidades

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


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 seguido em termos dos seus casos de uso

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


Figuras Densas

26


Validação de Requisitos

List of problems

Agreed actions

Requirementsdocument

Organisationalstandards

Organisationalknowledge

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 Distributedocuments

Prepare forreview

Hold reviewmeeting

Follow-upactions

Revisedocument


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

ser verificada durante o desenvolvimento

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* Não se entende e não é 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

+ http:/ /www.bell-labs.com/people/cope/Patterns/Process/RAPPeL/rapel.html

6 - engenharia de requisitos - fenix.tecnico.ulisboa.pt · engenharia de requisitos 21 técnicas...

Documents