ricardo ajax dias kosloski, msc, cfps [email protected] pós-graduação em engenharia de requisitos...

Ricardo Ajax Dias Kosloski, MSC, [email protected]

Pós-Graduação em Engenharia de Requisitos de

Software

Engenharia deRequisitos

Apresentações

2 Pós-Graduação em Engenharia de Requisitos de Software

Ricardo Ajax Dias kosloskiEngo. Eletricista - UnBAnalista de Sistemas - UcBPos-graduação em Enga. Software (UcB)MSC – MGCTI (UcB)

10 anos como analista de Sistemas6 Anos em Gerência de Projetos9 anos em Métricas e Qualidade de Software

Certificado CFPS desde 2003

Ricardo Ajax Dias kosloskiEngo. Eletricista - UnBAnalista de Sistemas - UcBPos-graduação em Enga. Software (UcB)MSC – MGCTI (UcB)

10 anos como analista de Sistemas6 Anos em Gerência de Projetos9 anos em Métricas e Qualidade de Software

Certificado CFPS desde 2003

Apresentações


Pós-graduandos

• Nome• Formação básica• Atuação• Expectativa quanto ao curso e à disciplina

Apresentações


Plano de Ensino

05 encontros (20 h.a)

• Apresentação do Professor, da disciplina e da metodologia de trabalho; revisão de conceitos (sistemas de informação, Engenharia de Software e Requisitos – conceitos/ tipos); Engenharia de Requisitos e Processos em Engenharia de Requisitos.

• Processo de produção de Requisitos; Elicitação de requisitos; Analise de requisitos; Documentação dos Requisitos; Validação dos Requisitos

• Processo de produção de Requisitos; Estudo de Caso; Exercício

• Processo de Gerencia de Requisitos; Gerência de Mudanças; Gerência de Configuração e Mudança; Rastreabilidade de requisitos; Gerência da Qualidade do Requisito

• Apresentação de trabalhos finais, avaliações.

Apresentações


Plano de Ensino

Metodologia de Ensino

• Aulas expositivas com recursos de projeção• Trabalho para avaliação• Leitura e discussão de artigos e trabalhos técnicos da área

Bibliografia


• PFLEEGER, Shari Lawrence. Engenharia de Software – Teoria e Prática. 2ª. Ed. – São Paulo: Pearson – Prentice Hall, 2007 ;

• PRESSMAN, Roger. S. Engenharia de software: um enfoque prático. 3. ed. São Paulo: Makron Books, 1995.

• SOMMERVILLE, Ian.Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003

• SWEBOK - Guide to the Software Engineering Body of Knowledge (www.swebok.org)

• WIEGERS, Karl E. More About Software Requirements. 1a. Ed. –Redmond, Washington: Microsoft Press, 2006

http://www.swebok.org/

Avaliação


• 01 Trabalho individual – a partir da PDS• 01 Prova de conceitos• Participação...


• Horário– Das 19:00 às 22:30

• Intervalos– Das 20:45 às 21:00

• Perguntas– A qualquer momento

Planejamento

• Objetivos do curso

Revisão dos conceitos gerais sobre Sistemas de Informação, Processos e Engenharia de Software. Conceitos gerais sobre Engenharia de Requisitos e seus processos de produção e gerencia de requisitos. Processo eXtreme Requirements para documentação de requisitos; Tipos de Requisitos e Estudos de Caso.

Objetivos

Pós-Graduação em Engenharia de Requisitos de Software9

1. Motivação2. Conceituação 3. Mais sobre Requisitos...

Agenda da Aula 01


Motivação

11

• Um projeto bem sucedido é aquele para o qual se aplicam os seguintes aspectos :

– Cliente/usuário satisfeito;– Auxiliou positivamente na obtenção da meta do

negócio; – Executou o escopo exatamente como previsto e

o software está sendo utilizado como previsto;– Atendeu às especificações técnicas de qualidade

e desempenho;– Atendeu às restrições de prazo e custo.

Resultado: Pouquíssimos projetos de T.I. seriam classificados como bem sucedidos.

Pós-Graduação em Engenharia de Requisitos de Software

Motivação


• Leffingwell ressalta que 40% a 60% de todos os problemas encontrados em um projeto são causados por falhas no processo de requisitos (ausência ou à não utilização de um processo de definição de requisitos adequado).

• As consequências da falta de um processo de requisitos eficaz têm sido a produção de softwares que não refletem as necessidades reais dos clientes.

• Como os requisitos constituem a base para o desenvolvimento do software, então, requisitos de má qualidade geram software com qualidade inadequada.

• Segundo Finkelstein, a análise final da qualidade de um software é determinada pelo atendimento aos requisitos dos stakeholders (envolvidos).

Motivação


Principais causas de fracasso

• Poucos analistas fazem uso de técnicas no momento de elicitar e analisar os requisitos de um sistema.

• Não é incomum encontrarmos desenvolvedores que definem, eles próprios, os requisitos dos sistemas e depois agem como se não soubessem o porquê do cliente não homologar tal aplicação.

Falhamos por não termos método e técnicas para produzir os requisitos

• Desenvolvedores, de uma forma geral, têm uma visão simplista do processo de software. É comum que projetos sejam iniciados e continuados mesmo com falhas nas informações dos usuários

• É necessário obter o conhecimento do negócio e das necessidades do usuário

Falhamos quando não entendemos o negócio do cliente

Motivação


Principais causas de fracasso

Falhamos quando perdemos o controle do

processo, permitindo que cliente e

gerentes interfiram diretamente na

equipe e no processo de

desenvolvimento do sistema.

Motivação


Por que requisitos são importantes?

Qualidade de Software: “Conformidade a requisitos funcionais e de desempenho, explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo o software profissionalmente desenvolvido.” (Pressman)

Uma compreensão completa do problema e a definição dos requisitos do software e sua especificação minuciosa é fundamental para o processo de desenvolvimento obter um software com alta qualidade.

Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor.

Falha na definição dos requisitos Defeitos do software Principal defeito: Não atender as expectativas de negócios do

usuário (cliente)

Motivação


O alto custo dos erros de requisitos

• Estudos realizados pela GTE, TRW e IBM, mediram e avaliaram os custos dos erros de requisitos ocorridos em várias fases do ciclo de vida de projetos de desenvolvimento de software.

• Se uma unidade de custo 1 é associada ao esforço requerido para detectar e reparar um erro durante a fase de codificação, – o custo para detectar e

reparar um erro durante a fase de requisitos está entre 5 a 10 vezes menor.

• Por outro lado, o custo para detectar e reparar um erro durante a fase de manutenção é 20 vezes maior.

Motivação


O alto custo dos erros de requisitos

• Em um estudo realizado por Sheldon, em um projeto da US Air Force, os erros foram classificados pela origem.

• Descobriu-se que os erros de requisitos totalizavam 41% dos erros descobertos, enquanto que erros de projeto lógico contabilizavam apenas 28% do total de erros encontrados.

Fontes de erros em um projeto da US Air Force

17

Conceitos


SISTEMA DE INFORMAÇÃO – S.I.

18

Conceitos


Sistemas de Informação

• A transformação de dados em informação é um processo ou uma série de atividades logicamente relacionadas, executadas para atingir um resultado definido.

• O processo de definição das relações entre atividades requer conhecimento.

• Conhecimento são regras, diretrizes e procedimentos usados para selecionar, organizar e manipular dados, com a finalidade de torná-los úteis para uma tarefa específica.


Conceitos


Processo

• “Conjunto de recursos e atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas).” (ISO, 1990)

• “Conjunto de atividades inter-relacionadas, que transformam entradas em saídas.” (Pfleeger, 2002)

• “Um processo é um grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes.” (Hammer e Champy, 1994)

Conceitos


Processo

• Todo trabalho importante realizado nas empresas faz parte de algum processo (Graham e LeBaron,1994).

Conceitos


Análise de Negócio

Conceitos


23


• De forma genérica:

É uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os objetivos de negócio do cliente

Mas... O que é um requisito?

Conceitos

• A identificação dos requisitos de um sistema pode ser exemplificado pela metáfora do “problema da pedra”:

1.Cliente solicita: “Traga-me uma pedra”

2. Você, ao entregar a pedra, ouve: “Ok, mas, na verdade, o que eu

realmente queria era uma pequena pedra de cor azul.”

Exemplificando

Conceitos

• A identificação dos requisitos de um sistema pode ser exemplificado pela metáfora do “problema da pedra”:

3. Você entrega a pedrinha azul, mas o cliente observa: “Ora, mas a pedra que eu queria é

esférica !!!”

Exemplificando

Conceitos

• Resultado: – cliente e desenvolvedor frustrados

• Problemas adicionais:– No mundo real, há o envolvimento de

mais pessoas– Não há tempo para trazer várias

“pedras” até acertar

Exemplificando

Conceitos

• Sistemas de software são, por sua natureza, intangíveis, abstratos, complexos e mutáveis.

• O cliente inicia a articulação de requisitos vagos para o seu sistema “pedra”.

• O cliente, frequentemente, acredita que pode detalhar melhor o que precisa ao longo do desenvolvimento.

• Não há como criar, testar, desenvolver e manter um sistema “pedra” a custo zero e prazo indefinido.

Exemplificando

Conceitos

• Supor que um Cliente apresente a seguinte necessidade:

Um programa que calcule a área de um retângulo.

Exemplificando

Conceitos

• Agora...


• O usuário deve informar o valor (em metros) de cada um dos lados, com precisão de duas casas decimais.

• A fórmula a ser utilizada é: L1 * L2• O valor calculado deve ser informado também com

precisão de duas casas decimais, com truncamento simples.

• O cálculo deve ser disparado após comando do usuário.

Suficiente ???

Exemplificando

Conceitos

• E mais ...


• Apresentar mensagem de erro quando, ao acionar o comando de cálculo, L1 e/ou L2 for(em) zero ou não for(em) especificado(s).

• Apresentar mensagem de erro se L1 = L2.• Definir um limite máximo para as entradas L1 e L2.• Incluir uma opção para limpar as entradas de dados.• O programa deve operar em no sistema operacional

Windows XP ou superior.• Não há necessidade de impressão ou salvamento do

resultado.• O programa deve ser capaz de operar sem o uso do mouse.• O resultado deve ser apresentado em até 1 segundo após o

acionamento do comando de cálculo.• Definir as mensagens. Melhorou ???

O Maravilhoso Programa de Cálculo

de Áreas de Retângulos

Exemplificando

Conceitos

Evolução do ProblemaEvolução do Problema

• Esse problema é tão antigo e conhecido na área de desenvolvimento de software, que na década de 70 alguém teve a idéia de fazer o seguinte desenho ilustrando a situação.

Evolução do Problema

• Alguém que esteja começando uma carreira de analista ou desenvolvedor de software poderá imaginar que um problema tão antigo já foi solucionado, ou, que pelo menos, o seu impacto nos projetos de software tenha sido minimizado.

• Que grande engano!

• O problema é ainda tão crítico, que o desenho foi revisto e adequado aos nossos dias.


• O que é um REQUISITO?

1. Uma capacidade do software necessária ao usuário para resolver um problema ou atingir um objetivo.

2. Uma capacidade do software que deve existir no sistema ou em algum componente para satisfazer um contrato, um padrão, uma especificação ou outra documentação formalmente imposta.

(Dorfman e Thayer, 1990)

Conceitos

Mapeamentodo

Processo

Identificação do

Problema

Análise doProblema

Análise do

Negócio

Viabilidade

Produção eGerência

deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Funcionalidadese

Recursos

Definiçãodos

Requisitos

Engenhariade

Requisitos

Sistema de informações / Processos / Requisitos

Relacionando Conceitos


Entendemos o negócio do

Cliente?

Mapeamentodo

Processo

Identificaçãodo

Problema

Análise doProblema

Análise do

Negócio


deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Definiçãodos

Requisitos




Conseguimos entender o

problema do Cliente?

Mapeamentodo

Processo

Identificaçãodo

Problema

Análise doProblema

Análise do

Negócio


deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Definiçãodos

Requisitos




Definimos o Problema a

ser automatizad

o?

Mapeamentodo

Processo

Identificaçãodo

Problema

Análise doProblema

Análise do

Negócio


deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Definiçãodos

Requisitos




Conseguimos identificar as necessidades do Cliente?

Mapeamentodo

Processo

Identificaçãodo

Problema

Análise doProblema

Análise do

Negócio


deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Definiçãodos

Requisitos




Conseguimos definir os requisitos

que o cliente esperava?

Mapeamentodo

Processo

Identificaçãodo

Problema

Análise doProblema

Análise do

Negócio


deRequisitos

Definição dos

Objetivos

Proposta de

Solução

Definiçãodos

Requisitos




Identificar e analisar REQUISITOS ?– Trabalha-se com o cliente

• Entrevistas, simulações, documentos de referencia,...• Identificar as pessoas, os processos e as relações• Definir o limite do sistema

– Registram-se os requisitos• Desenvolvedores e Cliente em consenso• Documento de Definição de Requisitos - DDR

– Verificam-se os requisitos• Completos, corretos e consistentes

– Validam-se os requisitos• Elaboração de Protótipos

Monitora e controla as mudanças nos requisitos



Documento de Requisitos


Necessidades

Características

Requisitos de Softwareou de Sistema

Domínio doPROBLEMA

Domínio da

SOLUÇÃO

Requisitos doNegócio

Funcionais Não Funcionais

Recursos,Perfil,

Prazo e Custo(Requisitos de Usuário)


Regras de NegócioComplementares

• Dois tipos de DOCUMENTO de REQUISITOS

Clientes Projetistas

Especificaçãodos Requisitos

Definiçãodos Requisitos

•Lista do que o Cliente espera que o sistema faça;

•Compreensível ao Cliente;•Consenso entre Cliente e Analista;

•Redefine os requisitos em termos técnicos;

•Compreensível para o Projetista•Consenso entre Analista e Desenvolvedor

•Envolve Modelagem


• Documentação de Requisitos

– Não importa o método, deve-se manter um conjunto de documentos que registrem os requisitos

– Esse conjunto será utilizado durante todo o desenvolvimento e manutenção do sistema


• A importância do processo de requisitos fez por definir uma outra “engenharia” dentro da Engenharia de Software:– Engenharia de Requisitos

• Objetivo: – criar e manter a documentação de

requisitos do sistema.

Engenharia de Requisitos

• A ER é uma sub-área da Engenharia de Software que estuda o processo de produção e gerência dos requisitos que o software deverá atender.

• O objetivo da ER é fornecer métodos, técnicas e ferramentas que forneçam suporte adequado às tarefas de produção (elicitação, análise, documentação e modelagem) e gerência dos requisitos do sistema.

• Foi estabelecida como disciplina independente em 1993, quando da criação do IEEE International Symposyum on Requirements Engineering (RE’93). A área tem crescido desde então.

• Para isso estabelece um processo no qual o que deve ser feito é elicitado,

analisado , documentado e modelado.


• Os 4 subprocessos da Produção de Requisitos:

– Elicitação• Identificação da fonte de informação. Obtenção

dos dados e fatos. Reunião com o cliente para entendimento do negocio.

– Análise de Requisitos• Identificação dos requisitos a partir do processo

de negócio. Acordo com o cliente do que se vai automatizar.

– Documentação• Definição dos requisitos. Elaboração do

documento de definição dos requisitos e regras de negocio. Documentação

– Validação• Avaliar, junto ao cliente, se os requisitos

realmente definem o sistema que o cliente deseja; Protótipo.


Porém...

“Caminhar sobre a água e desenvolver software a partir de uma especificação de requisitos

é fácil se ambos estão congelados”

Edward V. Berard


•Requisitos são por natureza voláteis. Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudanças de legislação, erros incorridos no processo de requisitos, entre outros

•Tais alterações precisam ser conduzidas de forma ordenada para que não se perca controle sobre o prazo e o custo do desenvolvimento

•Denominamos a atividade de administrar os requisitos ao longo do tempo de gerenciamento de requisitos


• Os 4 subprocessos da Gerência de Requisitos:

– RastreabilidadeRelação entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefato

– Gerência de MudançasControla as solicitações de mudança do cliente

– Gerência de ConfiguraçãoControla as versões dos artefatos

– Gerência de Qualidade dos RequisitosDefine o padrão de produção e verificação da qualidade dos requisitos. Capacita os analistas de requisitos e elabora o plano de gerencia de requisitos.


• A tendência natural das organizações que trabalham sem um processo de ER tem sido identificar os requisitos rapidamente de maneira informal e iniciar a codificação.

• Este é o processo “codifica-remenda” até a produção de uma versão com qualidade adequada ou o cancelamento do projeto.

• Estes projetos freqüentemente estouram o prazo e o orçamento. – Note que o esforço e o custo do retrabalho são maiores do que

os investimentos em ER, buscando desenvolver o projeto certo da primeira vez.

• Assim, torna-se importante desenvolver métodos atrativos para implantação das atividades da ER que motivem a indústria a investir em um processo completo de ER.


• A indústria de software vem demonstrando crescente interesse na engenharia de requisitos, isto é, entender o que se deseja construir antes de começar a fazê-lo (Ex.: MPS.BR).

• A visão atual é que o tempo utilizado no entendimento do problema é um excelente investimento.

• Os requisitos de software são a base a partir da qual a qualidade é medida (Ex.: APF)

• Desta forma, a falta de conformidade aos requisitos significa falta de qualidade.


• O modelo de avaliação de maturidade do processo de desenvolvimento CMMI-SW (Capability Maturity Model Integration-SW) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcançar a maturidade organizacional.

• E para haver o gerenciamento é preciso que o processo de produção de requisitos esteja implantado na empresa.


• Este processo deve lidar com diferentes pontos de vista, e usar uma combinação de métodos, ferramentas e pessoal.

• Tem início junto aos clientes durante a fase de elicitação ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software.

• O produto desse processo é um documento chamado de documento requisitos (DR) e um modelo (representado utilizando Análise Estruturada ou Orientada a Objetos) do Sistema de Informação a partir do documento de requisitos.


59

Processo XR

eXtreme Requirements

(Eduardo Castro, Direitos Reservados)

Processo XR

eXtreme Requirements

(Eduardo Castro, Direitos Reservados)

Próxima Aula

60

Análise do Negócio

Definição dos Requisitos

Disciplinas

FasesAnálise ValidaçãoElicitação Documentação

Proposta de Solução

Prototipação

Teste

Gerência de Requisitos

Disciplinas de ApoioGerência de Projeto

Métrica de Software

Administração de Dados

Processo eXtreme Requirements®

Eduardo José Ribeiro de Castro

Estudo de Caso

(Estudar para a próxima aula)

Estudo de Caso

(Estudar para a próxima aula)

Perguntas?

Para o sistema descrito a seguir (Compras NET), escrever os

requisitos funcionais, complementares, regras de

negócio e não funcionais que forem identificados.

Estudo de Caso

Compras NET

• O cliente navega pelo site e adiciona itens desejados ao carrinho de compras. Se não encontrar o produto desejado, pode usar a opção de busca.

• Durante sua navegação no site, o cliente pode ver o conteúdo de seu carrinho de compras, alterando quantidades ou excluindo itens.

• Quando o cliente finalizar a compra, ele deve se identificar com seu login/senha. Caso não seja ainda cadastrado, deverá fazê-lo antes de prosseguir. Em seguida, informa o endereço de entrega daquela compra e detalha a opção de pagamentos (dados do cartão de crédito ou para pagamento por boleto bancário).

• Confirmada a compra, o sistema fecha a venda e envia um e-mail informando ao cliente o status da compra (aguardando confirmação do cartão de credito ou do pagamento do boleto).

Estudo de Caso

Busca ProdutoBusca Produto

AdicionaProdutoAdicionaProduto

Achou ? Achou ?

PossuiCadastro?PossuiCadastro?

SolicitaUsuário e Senha

SolicitaUsuário e Senha

FIMFIM

Cadastra Usuario e Senha

Cadastra Usuario e Senha

CadastraEndereço de Entrega

CadastraEndereço de Entrega

Sim

Não

Finaliza? Finaliza?

Sim

Não

Não

SimSelecionaOpção de Compra

SelecionaOpção de Compra

Confirma CompraConfirma Compra

Sistema Envia e-mail

Sistema Envia e-mail

Valida Usuário e Senha

Valida Usuário e Senha

Fecha a VendaFecha a Venda

VisualizaProdutoVisualizaProduto

ModificaProdutoModificaProduto

InicioInicio Processo de Compra na WEB

Estudo de Caso

Requisitos Funcionais

Sub-Processo Seleciona Produto

RF1 – O sistema deve buscar produto (rc01)RF2 – O sistema deve adicionar produto (itens do carrinho) (rc02)RF3 – O sistema deve visualizar produtos (itens do carrinho) (rc3) (rng1) (rng2)RF4 – O sistema deve excluir produto (itens do carrinho) (rc01)RF5 – O sistema deve alterar quantidade produto (itens do carrinho) (rc02)RF6 – O sistema deve finalizar pedido (fechar carrinho) (rc04) (rgn3) (rgn4) (rgn5) (rgn6)

Sub-Processo Seleciona Realiza Compra

RF7 – O sistema deve identificar cliente (rc5)RF8 – O sistema deve cadastrar cliente (rc6)RF9 – O sistema deve cadastrar endereço de entrega (rc7)RF10 – O sistema deve permitir ao cliente selecionar opção de pagamento (rc08)RF11 – O sistema deve confirmar a compra (rc9) (rng7)RF12 – O sistema deve enviar e-mail de status (rc10)

Estudo de Caso

Requisitos Complementares

Sub-Processo Seleciona Produto

RC1 – o sistema deve permitir selecionar nome do produto (RF1) (RF4)RC2 – o sistema deve permitir selecionar nome e quantidade (RF2) (RF5)RC3 – o sistema deve exibir produto, quantidade, valor e total ao visualizar produto (carrinho) (RF3)RC4 – o sistema deve permitir registrar nome, data e hora ao finalizar o pedido (RF6)

Sub-Processo Seleciona Realiza Compra

RC5 – o sistema deve identificar o cliente por usuário e senha ao finalizar o pedido (RF7)RC6 – o sistema deve cadastrar usuário e senha (RF8)RC7 – o sistema deve cadastrar endereço, bairro, cidade e cep (RF9)RC8 – o sistema deve exibir as seguintes opções de pagamento: cartão de crédito e boleto bancário (RF10)RC9 – o sistema deve registrar nome, data, hora, produto e quantidade ao confirmar o pedido (RF11)RC10 – o sistema deve informar o status da compra (aguardando confirmação do cartão de credito ou do pagamento do boleto) ao finalizar a compra (RF12)

Estudo de Caso

Regras de Negócio

RNG1 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir alteração de quantidade de itens (RF3)

RNG2 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir exclusão de itens (RF3)

RNG3 – quando o cliente finalizar o pedido o sistema deve identificar cliente (RF7)

RNG4 – quando o cliente finalizar o pedido e o cliente não for cadastrado o sistema deve permitir cadastrar cliente (RF8)

RNG5 – quando o cliente finalizar o pedido o sistema deve cadastrar endereço de entrega (RF9)

RNG6 – quando o cliente finalizar o pedido o sistema deve permitir selecionar tipo de pagamento (RF10)

RNG7 – quando o cliente confirmar a compra o sistema deve enviar e-mail informando status da compra (RF12)

Estudo de Caso

Requisitos não funcionais • 1. Confiablidade

– O sistema deve garantir que a atualização de dados será feita de forma atômica e imediata, sempre com registro histórico;

– O sistema deve realizar backups diariamente após a 00:00 hrs;• 2. Eficiência

– O sistema deve responder a qualquer pesquisa, inclusão, alteração e exclusão em tempo inferior a 3 (três) segundos;

– O sistema deve garantir que as atualizações dinâmicas de informação única não devem exceder 1 (um) segundo;

• 3. Portabilidade– O sistema deve ser executado em em microcomputadores de

arquitetura IBM PC, com processadores Intel P4 2.5Ghz com 512Mb de memória RAM e HD de 40Gb com sistema operacional Windows XP;

– O sistema deve ser portável para GNU/Linux, com ambiente Desktop GNOME, em máquina de mesma configuração;

• 4. Usabilidade– O sistema deve focar em eficiência, fornecendo teclas de atalho para

todas as ações mais importantes;– O sistema deve seguir as Diretrizes de Interface Humana do projeto

GNOME: http://developer.gnome.org/projects/gup/hig/;

Estudo de Caso

RastreabilidadeRastreabilidade

Rastreabilidade

Requisitos Funcionais x Requisitos Complementares

Req.Complementar

Req. FuncionaisRC01 RC02 RC03 RC04 RC05 RC06 RC07 RC08 RC09 RC10

RF01 xRF02 xRF03 xRF04 xRF05 xRF06 xRF07 xRF08 xRF09 xRF10 xRF11 xRF12 x

Estudo de Caso

Rastreabilidade

Requisitos Funcionais x Regras de Negocio

Regras de Neg.

Req. FuncionaisRNG01 RNG02 RNG03 RNG04 RNG05 RNG06 RNG07

RF03x x

RF07x

RF08x

RF09x

RF10x

RF12x

Estudo de Caso

Modelagem de Requisitos

Analise O.O.


Analise O.O.

– Os requisitos funcionais e regras de negócio são avaliadas de forma a elaborar o diagrama de caso de uso

– Os casos de uso podem modelar 1 ou um conjunto de requisitos funcionais que sejam necessários a um determinado ator realizar sua tarefa.

– Os atores são identificados dos elementos envolvidos no processo e definidos no Documento de Definição de Requisitos - DDR

Estudo de Caso

Estudo de Caso


Analise Estruturada


Analise Estruturada

– Os requisitos funcionais, requisitos complementares e regras de negócio são avaliadas de forma a elaborar o Diagrama de Contexto - DC e posteriormente o Diagrama de Fluxo de Dados - DFD

– Os fluxos de dados se relacionam diretamente aos Requisitos Funcionais - RF, tendo em vista que cada RF obrigatoriamente possui Requisitos Complementar que representa os dados.

– As entidades são identificadas dos elementos envolvidos no processo e definidos no Documento de Definição de Requisitos - DDR

Estudo de Caso

Estudo de Caso

ricardo ajax dias kosloski, msc, cfps [email protected] pós-graduação em engenharia de requisitos...

Documents