Engenharia de Requisitos PDF

CURSO ENGENHARIA DE REQUISITOS 1
Mdulo 01 Introduo
Objetivos
Estabelecer a importncia/relevncia das especificaes de requisitos em desenvolvimento de
softwares.
Levantar os problemas envolvidos na especificao de requisitos.
Ilustrar o uso de tcnicas de modelagem para minimizar problemas na especificao de requisitos.
Definio de Requisitos
Condio ou capacidade que um usurio deve ter para que possa solucionar um problema ou atingir
um objetivo.
Condio ou capacidade que um sistema deve ter para atender a um contrato padro, especificao
ou outro documento formalmente imposto.
Por exemplo:
Um gerente de fornecimento deve estabelecer os requisitos que atendam s suas exigncias quanto
eficincia no gerenciamento do fornecimento.
Um gerente de banco deve estabelecer os requisitos que atendam s suas exigncias quanto
melhoria no tempo de atendimento s necessidades dos clientes.
Trabalho do Analista
trabalho do analista entender esses requisitos e fornecer uma soluo adequada. Para isso, ele
precisa entender o negcio do cliente:
a) Quem sero os usurios?

b) Qual a influncia dos usurios?
c) Quais sero as restries?
d) Quais sero as variveis etc.
Viso do Analista
O analista no pode presumir que o desenvolvimento de um sistema (software) seja a nica soluo
que pode ser oferecida ao cliente.
Ele deve ter uma viso mais ampla. Algumas vezes, a redefinio dos processos do negcio pode ser
tudo o que necessrio para melhorar a sua eficincia!
Anlise
Se a anlise realizada levar concluso de que um sistema deve ser desenvolvido, o analista ter que
elaborar um documento detalhado de tudo o que o sistema precisar para atender s necessidades do
cliente.
Especificao de Requisitos de Software

Esse documento chamado de Especificao de Requisitos de Software (SRS Software Requirements
Specification). Veja abaixo um exemplo de SRS:
1 Introduo
1.1 Motivo
(Motivo deste documento)
1.2 Escopo
(Deve consistir de uma descrio clara e concisa do assunto abrangido)
1.3 Definies, Acrnimos e Abreviaes
(Uma lista alfabtica das abreviaes e acrnimos)
1.4 Viso geral do documento
(Resuma o motivo e o contedo deste documento)
2 Caractersticas Gerais
2.1 Introduo
(Descreva as caractersticas e limites do sistema)
2.2 Perspectiva de sistema
(Determine o motivo do sistema)
2.3 Atividade de sistema (ou) Recursos de sistema
(Descreva os recursos do sistema. Exemplo: Em um "sistema de monitoramento de Emprstimo"
as atividades/recursos sero autenticao, clculo de parcelas, gerao de multas, clculo de
vencimento, gerao de fatura etc.)
2.4 Caractersticas de usurio
(Descreva as caractersticas gerais dos usurios do produto incluindo nvel educacional,
experincia e especializao tcnica)
2.5 Restries gerais
(Fornea uma descrio geral de quaisquer outros itens que limitaro as opes do desenvolvedor
para projetar o sistema. Eles podem incluir: Polticas regulamentares, limitaes de hardware,
Interface a outros aplicativos, operao paralela, funes de auditoria, funes de controle,
requisitos de linguagem de maior ordem, urgncia do aplicativo, consideraes de proteo e
segurana)
2.6 Presunes e Dependncias
(Liste cada um dos fatores que afetam os requisitos declarados na SRS. Esses fatores no so
restries de projeto no software; mas so, na verdade, quaisquer alteraes neles que possam
afetar os requisitos na SRS)
3 Requisitos especficos
3.1 Requisitos funcionais
(Entradas, resultados, clculos e casos de uso)
3.2 Requisitos externos de interface
(Usurio, hardware, software, comunicaes Interface de usurio, layouts de tela)
3.3 Requisitos de desempenho
(Se existem requisitos de desempenho para o produto sob vrias circunstncias, determine-os
aqui e explique-os para ajudar os desenvolvedores a entender a inteno e fazer escolhas de
projeto adequadas. Especifique os relacionamentos de timing para sistemas em tempo real)
3.4 Limitaes de Projeto
(Formatos de arquivo, linguagens, padres, compatibilidade etc.)
3.5 Atributos
(Atributos de software que podem servir como requisitos... Eficincia, Flexibilidade,
Interoperabilidade, Confiabilidade, Reusabilidade, Testabilidade etc.)
3.6 Outros requisitos
4 Diagrama de fluxo de dados (Nvel 0, Nvel 1 e Nvel 2)
5 Diagrama de Entidade - Relacionamento
6 Grfico de estrutura
7 Telas
8 Pseudocdigo
9 Informao de Suporte
Elas podem incluir:
- Formatos modelo I/O
- Informaes de motivo que podem ajudar os leitores da SRS
- Descrio dos problemas a serem solucionados pelo software
- O histrico, motivo, experincia e caractersticas operacionais da organizao a ser auxiliada
- Instrues especiais de pacote para o cdigo para a mdia
10 Apndice
(Dicionrio de dados e outras informaes).
Entender Requisitos
Determinar e entender os requisitos no uma tarefa fcil. Vamos ver alguns exemplos.
Declarao
O valor do contador foi retirado do ltimo registro.
Nesta declarao, a palavra "ltimo" ambgua, ou seja, pode significar o ltimo registro acessado
em um arquivo aleatrio ou o ltimo registro em um arquivo sequencial.
Clculo
Calcule o inverso de uma matriz quadrada M de tamanho n de tal forma que LM=ML=In onde
L a matriz inversa e In a matriz identidade de tamanho n.
A declarao, aparentemente completa, no menciona o tipo de elementos da matriz. So

nmeros reais e inteiros ou nmeros complexos? Dependendo da resposta a esta pergunta, o
algoritmo ser diferente.
Facilidade do Sistema
O sistema deve ser de fcil utilizao para o usurio. Como se pode determinar se este requisito ser
satisfeito ou no?
O resultado de uma solicitao ao sistema dever ser exibido dentro de 10 segundos.
Quais so as excees para a exigncia dentro de 10 segundos?
SRS
Em um SRS:
Todos os requisitos devem estar corretos. No podem existir erros reais.
Todas os requisitos devem ter apenas uma interpretao. Lembre-se dos exemplos de declaraes
ambguas.
SRS completo
O SRS deve ser completo em todos os aspectos. Na prtica, difcil atingir este objetivo. Muitas
vezes os clientes mudam os requisitos medida que o desenvolvimento do software progride ou
novos requisitos so adicionados.
Metodologias
As geis metodologias de desenvolvimento so especificamente projetadas para levar esse fator em
considerao. Elas dividem as exigncias em subconjuntos chamados de cenrios e cada um
implementado separadamente. No entanto, cada cenrio deve estar completo.
Requisitos
Todos os requisitos devem ser verificveis, ou seja, deve ser possvel constatar se eles foram atendidos
ou no. Palavras como altamente e geralmente, no devem ser utilizadas.
Todos os requisitos devem ser consistentes e no-conflitantes.
Como definimos anteriormente, os requisitos mudam. Ento, o formato da SRS deve ser tal que as
mudanas possam ser facilmente incorporadas.
Mdulo 02 Entendendo os Requisitos

Requisitos Funcionais e No Funcionais
Os requisitos podem ser classificados como:
a) Funcionais: especificam o que o sistema deve fazer. Por exemplo:

Calcular os juros compostos taxa de 14% ao ano, de um depsito fixo, por um perodo de trs
anos.
Calcular o imposto taxa de 30% em uma renda anual igual a e acima de R$ 200.000, mas no
superior a R$ 300.000.
Inverter uma matriz quadrada de nmeros reais (tamanho mximo 100x100).
b) No funcionais: especificam os atributos gerais de qualidade que o sistema deve satisfazer. Por
exemplo:
Portabilidade
Confiabilidade
Desempenho
Testabilidade
Modificabilidade
Segurana
Apresentao
Reusabilidade
Entendibilidade
Aceitabilidade
Interoperabilidade
Alguns exemplos de requisitos no funcionais so:
O nmero significativo de dgitos para o qual a preciso deve ser mantida em todos os clculos
numricos 10.
O tempo de resposta do sistema deve ser sempre inferior a 5 segundos.
O software deve ser desenvolvido usando linguagem C em um sistema baseado no UNIX.

Um livro pode ser deletado do Sistema de Gerenciamento de Biblioteca apenas pelo
Administrador de Banco de Dados.
A rotina de diagonalizao da matriz deve zerar todos os elementos diagonais, que sejam iguais
a ou inferiores a 10-3.
Executivos experientes devem ser capazes de usar todas as funes do sistema aps um
treinamento total de duas horas. Aps esse treinamento, o nmero mdio de erros cometidos
por eles no deve exceder a dois por dia.
Outras Classificaes
Os requisitos tambm podem ser classificados nas seguintes categorias:
a) Nvel de satisfao - Existem trs tipos:

Normal: so declaraes especficas das necessidades do usurio. O nvel de satisfao do
usurio diretamente proporcional ao grau em eles so satisfeitos pelo sistema.
Esperado: podem no ser declarados pelos usurios, mas espera-se que o desenvolvedor os
atenda. Se os requisitos forem atendidos, o nvel de satisfao dos usurios poder no
aumentar, mas se no forem, eles podero ficar extremamente insatisfeitos.
Os requisitos esperados so muito importantes do ponto de vista do desenvolvedor.
Alm da expectativa: alm de no serem declarados pelos usurios, sequer so esperados por
eles. Mas se o desenvolvedor os fornece ao sistema, o nvel de satisfao do usurio ser muito
alto.
A tendncia ao longo dos anos tem sido a de que os requisitos acima da expectativa se tornem
normais e que alguns dos requisitos normais se tornem esperados.
Observe o exemplo a seguir:
O recurso de auxlio online foi utilizado pela primeira vez no sistema UNIX, na forma de
pginas gerenciadas pelo usurio.
Naquela poca, era um recurso acima da expectativa. Mais tarde, outros usurios
comearam a exigir esse recurso como parte de seus sistemas.
Hoje em dia, os usurios no pedem por isso, mas espera-se que o desenvolvedor fornea
esse recurso.
b) Prioridade: Forma de priorizar os requisitos. Eles podem ser classificados como:

Necessrios
Desejveis
No essenciais
Essa classificao feita em conjunto com os usurios e ajuda na determinao de foco em um
modelo de desenvolvimento interativo.
c) Estabilidade: Os requisitos podem ser estveis ou instveis. Requisitos estveis no mudam
frequentemente, ou pelo menos o perodo de tempo para mudana longo.
No entanto, alguns requisitos podem mudar frequentemente (instveis). Por exemplo, se estiver
ocorrendo alteraes no processo do negcio juntamente com o desenvolvimento do software, os
requisitos correspondentes podem mudar at que o processo se estabilize.
d) Categorias de usurio: Como definimos na introduo, haver muitos interessados em um sistema.

De modo geral, eles so de dois tipos:
Aqueles que definem as polticas para o sistema
Aqueles que utilizam o sistema
Eles podem ainda ser captados entre essas classes dependendo das necessidades de informao e
servios necessrios. importante que todos os interessados sejam identificados e suas exigncias
sejam captadas.
Mdulo 03 Requisitos de Modelagem

Viso Geral
Todo sistema de software possui as seguintes caractersticas essenciais:
Possui um limite, ou seja, rea que separa o que faz parte de seu escopo do que no faz.
Capta inputs de agentes externos e gera resultados.
Possui processos que colaboram entre si para gerar os resultados.
Os processos permitem criar, modificar, excluir ou consultar dados.
O sistema pode tambm usar repositrios de dados para armazenar dados que possam ser
utilizados em outros sistemas (em uma migrao de plataforma, por exemplo).
A seguir, descreveremos os elementos usados na Metodologia de Anlise e Design de Sistemas

Estruturados (Structured Systems Analysis and Design Methodology SSADM).
Diagrama de Fluxo de Dados (Data Flow Diagram DFD):
Um DFD usado para processos de modelagem e suas interaes.
Diagrama de Relacionamento de Entidade (Entity Relationship Diagram ERD):
Um ERD utilizado para modelagem dos dados e seus relacionamentos.
Dicionrio de Dados:
Contm uma lista organizada da estrutura dos dados.
Figura 1: Diagrama de Relacionamento de Entidade - ERD.

Figura 2: Diagrama de fluxo de dados - DFD.
Figura 3: Dicionrio de dados.

Tabelas de Deciso e rvores de Deciso:
So utilizadas para modelar decises complexas.
Figura 4: rvores de Deciso.
Portugus estruturado:
Para especificar processos estruturados (algoritmos), utiliza-se termos em Portugus.
Figura 5: Portugus Estruturado.

Diagrama de Transio de Estado:
utilizado para modelar alteraes do estado do sistema.
Figura 6: Diagrama de Transio de Estado.
Diagrama de Fluxo de Dados

O DFD foca sobre a circulao dos dados atravs do sistema e suas transformaes. Ele dividido em
nveis.
Nvel 0: tambm conhecido por diagrama de contexto, define o escopo do sistema. composto por
agentes externos, limites de sistema e os dados circulam entre os agentes externos e o sistema.
Nvel 1: uma expanso do nvel 0, na qual todos os principais processos, repositrios de dados e
o fluxo de dados entre eles exibido.
Nvel 2, nvel 3 etc.: exibe detalhes de processos individuais.
Notaes DFD
Agentes externos:
o So externos ao sistema, mas

interagem com ele.
o Devem ser desenhados no nvel 0, mas

no precisam ser desenhados a partir
do nvel 2.
o Devem receber nomes significativos.
o As duplicidades devem ser

identificadas.
Processo:
o As atividades de processamento de informaes devem ser indicadas em todos os nveis.
o No nvel 0, exibido um nico processo, representando o sistema.
o Em nveis subsequentes, o nmero de processos deve ser limitado a 7 2.
o Duplicaes no so permitidas.
Figura 7: Notao de Processo.
Repositrios de dados:
o So reas usadas para armazenar informaes e no so visualizadas

no Nvel 0.
o Todos os repositrios de dados devem ser exibidos no Nvel 1.
o As duplicaes precisam ser indicadas.
Fluxos de Dados:
o Indicam o fluxo das informaes.
o Precisam ser exibidos em todos os

nveis e devem ter nomes significativos.
Exemplos:
O pedido do cliente emite uma ordem de venda. O

sistema checa a disponibilidade do produto e atualiza as
informaes da venda.
A empresa recebe um
pedido de contratao.
Checa as condies de
qualificao. Convida os
candidatos qualificados
para uma entrevista.
Mantm uma lista desses
candidatos. Atualiza as
condies de qualificao
de acordo com o
desejado pela
administrao.
Iniciando um DFD
Identifique as entradas ou eventos que do origem ao sistema, bem como seus resultados ou
respostas.
Identifique as fontes correspondentes e os destinos (agentes externos).
Elabore um diagrama de contexto (nvel 0) que exiba os limites do sistema, os agentes externos e
os fluxos de dados que conectam o sistema aos agentes externos.
Elabore o diagrama de nvel 1 que exiba todos os agentes externos, todos os processos principais,
todos os repositrios de dados e todos os fluxos de dados conectando os vrios componentes. Os
componentes devem ser colocados com base na precedncia lgica ao invs de precedncia
temporal. Evite cruzamentos de fluxos de dados.
Refina o diagrama de nvel 1.
Expanda os processos individuais conforme necessrio.
Lembre-se, em um DFD:
Diagrama de Entidade-Relacionamento
O ERD complementa o DFD. Enquanto o DFD foca
em processos e no fluxo de dados entre eles, o
ERD foca em dados e nos relacionamentos entre
eles.
O ERD ajuda a organizar os dados de maneira

disciplinada, garantindo a preciso,
adaptabilidade e estabilidade deles. uma
ferramenta efetiva para se comunicar com a
administrao snior (quais so os dados
necessrios para executar os negcios?),
administradores de dados (como gerenciar e
controlar dados), projetistas de bancos de dados
(como organizar os dados de maneira eficiente e
remover redundncias).
O ERD consiste de trs componentes:
1. Entidade:
Representa uma coleo de objetos ou coisas

reais cujos membros individuais ou
ocorrncias possuem as seguintes
caractersticas:
De algum modo, cada um pode ser
identificado com exclusividade.
Cada um desempenha um papel necessrio
no sistema que est sendo desenvolvido.
Cada um pode ser descrito por um ou mais
atributos.
Entidades geralmente correspondem a
pessoas, objetos, localizaes, eventos etc. Por exemplo, funcionrios, vendedores, fornecedores,
materiais, armazns, data de entrega etc.
A seguir, esto os cinco tipos de entidades.
Entidade Fundamental: Ela no depende de nenhuma outra entidade para existir. Por exemplo,
materiais. (Tijolos, Materiais de cobertura, Isolamento e laterais, chapas artificiais).
Entidade Subordinada: Depende de outra entidade para sua existncia. Por exemplo, em um
sistema de gerenciamento de estoque, ordem de compra pode ser uma entidade e ela
depender dos materiais sendo adquiridos. De maneira semelhante, as faturas dependero das
ordens de compra.
Entidade Associativa: Depende de duas ou mais entidades para sua existncia. Por exemplo,
notas de um aluno dependero do aluno e do curso.
Entidade de Generalizao: Ela encapsula caractersticas comuns de muitas entidades
subordinadas. Por exemplo, um carro de quatro rodas um tipo de veculo. Um caminho um
tipo de carro de quatro rodas.
Entidade de Agregao: Ela consiste de uma agregao de outras entidades. Por exemplo, um
carro consiste de motor, chassi, caixa de engrenagens etc. Um veculo tambm pode ser
considerado como uma entidade de agregao, porque um veculo pode ser considerado como
uma agregao de muitas peas.
2. Atributos:
Expressam as propriedades das entidades.

Toda entidade ter muitos atributos, mas apenas
um subconjunto, que relevante para o sistema sob
estudo, ser escolhido.
Por exemplo, uma entidade funcionrio ter
atributos profissionais como nome, designao,
salrio etc. e tambm atributos fsicos como peso,
altura, etc., mas apenas um conjunto ser escolhido
dependendo do contexto.
Os atributos so classificados como chaves de entidade e descritores de entidade.

As chaves de entidade so usadas unicamente para identificar as ocorrncias de entidades. Os
atributos que possuem valores nicos so chamados de chaves candidatas e um deles chamado
de chave principal.
Os domnios dos atributos devem ser predefinidos. Por exemplo, se nome for um atributo de uma
entidade, seu domnio o conjunto de caracteres alfabticos com tamanho predefinido.
3. Relacionamentos
Descrevem a associao entre entidades, que podem ser:
Obrigatrios: Significa que, se um valor for associado a qualquer ocorrncia da primeira entidade
haver pelo menos uma ocorrncia dele na segunda entidade.
Por exemplo, para que possamos visualizar o nome do cargo de um funcionrio tendo por base
o cdigo do cargo, obrigatrio criar um relacionamento entre a tabela funcionrios e a tabela
de cargos.
Opcionais: Significa que poder haver ocorrncias na primeira entidade que no estejam
associadas a nenhuma ocorrncia da segunda entidade.
Por exemplo, o relacionamento entre a tabela de funcionrios e a de cnjuges deve ser opcional,
pois pode haver funcionrios solteiros.
Os relacionamentos podem ser de trs tipos:
Um-para-um: Significa que uma ocorrncia

da primeira entidade est associada a
apenas uma ocorrncia da segunda
entidade e vice-versa.
Por exemplo, a entidade A tem os cdigos

dos clientes e a entidade B tem os nomes. O
ideal que essas informaes estejam na
mesma entidade.
Um-para-muitos: Significa que uma ocorrncia da primeira entidade est relacionada a muitas
ocorrncias da segunda entidade, enquanto uma ocorrncia da segunda entidade est associada
a apenas uma ocorrncia da primeira entidade.
Por exemplo, em uma nota fiscal, um cliente

(entidade A), pode comprar vrios produtos
(entidade B), mas no podemos ter vrios
clientes na mesma nota.
Muitos-para-muitos: No relacionamento muitos para muitos uma ocorrncia da primeira

entidade est relacionada a muitas ocorrncias da segunda entidade e vice-versa.
Por exemplo, em uma nota fiscal (entidade

A), podemos ter diversos produtos
(entidade B) e ao mesmo tempo, o produto
pode estar em vrias notas fiscais.
Notao ERD:
Existem dois tipos de notaes:
Notao de Peter Chen

Notao de Bachman
Abaixo seguem alguns exemplos de diagramas ERD usando notao de Bachman:
1. Em uma empresa, cada diviso gerenciada somente por um administrador e cada

administrador gerencia apenas uma diviso.
2. Entre as indstrias automobilsticas, cada uma produz vrios carros, mas determinado carro
fabricado em apenas uma delas.
3. Em uma escola, todos os alunos tm muitos cursos e todos os cursos so frequentados por
muitos alunos.
4. Em uma biblioteca, um scio pode tomar emprestado muitos livros e pode haver livros que no
so emprestados por nenhum scio.
5. Um professor ensina muitos alunos e um aluno ensinado por muitos professores. Um professor
aplica avaliao para muitos alunos e um aluno avaliado por muitos professores.
6. Uma extenso do exemplo 3 de que as notas dos alunos dependem tanto do aluno quanto do
curso. Desta forma, este caso uma entidade associativa.
7. Um funcionrio pode desempenhar o papel do administrador. Dessa forma, um funcionrio se

reporta a outro funcionrio.
8. Uma proposta emitida para materiais ou servios, mas no para ambos.
9. Um carro consiste de um motor e um chassi.
Dicionrio de Dados
Contm:
Elemento de dados: (Uma lista organizada de...) a parte do dado que no pode ser dividida no
contexto atual do sistema. Exemplos:
Ordem_de_compra_n
Nome_do_funcionrio
Taxa_de_juros etc.
Cada elemento de dados um membro de um domnio. A entrada de dicionrio de um elemento

de dados deve especificar o domnio.
Estrutura dos dados: composta de elementos de dados ou outras estruturas de dados. Exemplos:
Detalhes_do_cliente, que pode ser composto pelo Nome_do_Cliente e Endereo_do_Cliente.
Endereo_do_Cliente, por sua vez, uma estrutura.
Fatura, que pode ser composta de nmero_da_fatura, detalhes_do_cliente,
endereo_de_entrega e detalhes_da_fatura.
Fluxos de dados: Fluxo de dados composto de estruturas de dados e/ou elementos de dados. As
definies de estruturas dependentes de dados/elementos de dados precedem a definio do fluxo
de dados.
Ao se definir o fluxo de dados, os pontos de conexo devem ser mencionados.
Tambm til se incluir o volume de fluxo/frequncia e as taxas de crescimento.
Repositrio de dados: como o fluxo de dados, composto de uma combinao de estruturas de

dados e/ou elementos de dados. A descrio similar aos fluxos de dados.
Mini especificaes de processos primitivos

do sistema: informam as formas nas quais os
fluxos de dados que entram no processo
primitivo so transformados em fluxos de
dados que deixam o processo.
Apenas o esboo amplo dado, no os
passos detalhados. Elas precisam existir
para todo processo primitivo. Portugus
estruturado usado para informar as minis
especificaes.
E quaisquer outros detalhes que fornecero informaes teis sobre o sistema.
Elementos de Notao do Dicionrio de Dados:
Os elementos de notao usados no dicionrio de dados so os seguintes:
[nome_do_cnjuge]: indica que nome_do_cnjuge opcional.

{nome_do_dependente, relacionamento} * (0 a 15): indica que a estrutura de dados pode ser
repetida de 0 a 15 vezes.
{descrio_da_despesa, nome_da_empresa, cobrana} * (1 a N): indica que a estrutura de dados
pode ser repetida de 1 a N onde N no est estabelecido.
nmero_de_identidade_do_eleitor/nmero_da_conta_do_cliente: indica que os dois elementos
estaro presentes.
Ateno:
Uma vez criados o DFD, ERD e o Dicionrio de dados, eles devem ser comparados entre si. O DFD e o
ERD podem ser criados paralela e independentemente.
Todo repositrio de dados no DFD deve corresponder a pelo menos uma entidade no ERD.
Devem haver processos no DFD que criam, modificam e deletam ocorrncias das entidades no ERD.
Para todo relacionamento no ERD deve ser utilizado por um processo no DFD.
Para cada descrio no dicionrio de dados, devem haver elementos correspondentes no DFD e no
ERD.
rvore de Deciso e Tabelas de Deciso

rvore de Deciso
Uma rvore de deciso representa decises complexas sob

a forma de uma rvore. Embora seja visualmente atraente,
ela pode fugir do controle quando o nmero e
complexidade das decises aumentam.
Veja um exemplo a seguir:
Regras para cobrana de energia eltrica so como as que

aparecem abaixo:
o Se o medidor estiver OK,

calcule a base de consumo
(ou seja, medio).
o Se o medidor aparecer
BAIXO, ento verifique se a
casa est ocupada.
o Se a casa estiver ocupada,
calcule a base de consumo
sazonal ou, caso contrrio,
calcule a base de consumo.
o Se o medidor estiver
danificado, calcule com base
no uso mximo de energia
eltrica possvel.
Tabela de Deciso
Existem dois tipos de tabelas de

deciso, com valor binrio (sim ou no)
e valor mltiplo. Veja um exemplo:
Calculo do consumo de energia eltrica

com base na classificao do cliente
o Se o cliente usa energia eltrica para

fins domsticos e o consumo for
inferior a 300 unidades por ms,
ento cobrar com a taxa mnima.
o Se o cliente domstico consumir mais de 300 unidades por ms, cobrar a taxa especial.
o Clientes no domsticos so cobrados duplamente em relao aos usurios domsticos (taxas
mnimas e especiais so duplas).
Como as rvores de deciso, as tabelas de deciso de valor binrio podem ficar maiores se o nmero
de regras aumentar.
Tabelas de deciso de valor mltiplo possuem uma margem. No exemplo ao lado, adicionamos uma
nova classe de clientes, chamada Acadmico, com as seguintes regras:
Se o consumo for inferior a 300 unidades por ms, cobrar com a taxa concessional. Caso contrrio,
cobre duas vezes a taxa concessional.
Portugus Estruturado
Para especificar os processos (mini especificaes), usa-se o portugus estruturado.
Ele consiste de:
Sequncias de instrues
(declaraes de ao)
Decises (se houver)
Loops (repetir at)
Caso
Grupos de instrues
Diagrama de Transio de Estado

O diagrama de transio de estado outro diagrama til.
Ele pode ser usado para modelar as alteraes de estado do sistema. Um sistema est em um estado
e permanecer nele at que uma condio ou uma ao o forcem a mudar.
Mdulo 4 - Concluso
O resultado da etapa de engenharia dos requisitos o documento de especificaes de requisitos do
software (SRS).
No mnimo, ele deve conter o DFD, o ERD e o dicionrio de dados, assim como as minis especificaes.
Os outros diagramas podem ser usados conforme exigido.
O rgo de padres do Instituto de Engenheiros Eltrico-Eletrnicos (IEEE) definiu um conjunto de

prticas recomendadas chamadas Prtica Recomendada do IEEE para Especificaes de Requisitos de
Software, padres IEEE 830-1998. Ele pode ser usado como documento diretriz para o SRS.
Mdulo 5 Estudo de Caso

Sistema de aquisio de material
XYZ uma empresa que fabrica fertilizantes e produtos qumicos para uso em agricultura. Sua matriz
est localizada em Dlhi e uma das fbricas em Surat.
A fbrica supervisionada por um Diretor de Operaes, que auxiliado por vrios chefes
departamentais na execuo das operaes dirias. Produo, Manuteno, Financeiro, Compras e
Transporte so alguns dos principais departamentos dessa empresa.
Nosso estudo se restringe s operaes de compra e s interfaces relacionadas. Atualmente, todas as

operaes de compras esto sendo executadas manualmente. A Gerncia decidiu dinamizar a
execuo dessas operaes com o uso de um computador.
Um documento com as discusses entre o gerente de compras e sua equipe relacionadas aos
procedimentos atuais encontra-se anexo.
Viso Geral do Departamento

O Departamento de Compras dirigido por um gerente de compras que se reporta diretamente ao
Diretor de Operaes. Ele auxiliado por compradores e pela equipe de funcionrios do escritrio. A
fora total do departamento 20.
A principal funo do departamento de compras adquirir material para produo, manuteno e

para outros departamentos em tempo hbil para que no haja situaes nas quais as atividades
tenham de ser interrompidas devido falta de algum material solicitado.
Atualmente, existem mais de 300 ordens de compra (OCs) abertas simultaneamente (uma OC
considerada fechada quando o material recebido e a fatura paga) e tornou-se impossvel manter-se
a par das atividades de compra e fornecer o status atualizado aos departamentos interessados.
A ideia por trs do uso de um computador a de acessar as informaes de maneira rpida e monitorar
a atividade de compra eficientemente. Tambm se espera que aps a informatizao, com a mesma
fora de trabalho, o carregamento futuro de compras (relacionado a planos de diversificao da
empresa) tambm possa ser atendido.
Os vrios procedimentos acompanhados pelo departamento de compras j foram analisados e

ajustados por um consultor e, a menos que seja realmente necessrio, nenhum procedimento deve
ser alterado pelo uso do computador.
Detalhes do procedimento de compras

Os departamentos usurios (Produo, Manuteno etc.) preparam sua prpria solicitao de compra
de material (MPR) e a enviam para o departamento de compras conforme e quando uma necessidade
surge. Mais de um detalhe de aquisio de material pode ser dado na mesma MPR que contm o
cdigo do material, a descrio e a quantidade.
O departamento de Compras valida as MPRs somente se a quantidade necessria no estiver

disponvel nos estoques (Departamento de Estoques) e o departamento envolvido no tiver esgotado
seu oramento. Os oramentos so fornecidos pelo departamento Financeiro no incio do exerccio
financeiro e esto disponveis para consulta do departamento de Compras.
Sempre que um comprador que lida com um grupo particular de materiais (25 grupos de materiais
foram formados com base em similaridade de materiais) acredite ser necessrio, ele revisa o registro
das MPRs e consolida a necessidade de material para esses grupos.
Em seguida, faz uma cotao com fornecedores cadastrados para uma classe especfica de itens. Uma
consulta pode conter um material de um grupo de materiais (por exemplo, parafusos de 1,5" ou 1")
que possuem cdigos diferentes. Toda consulta possui apenas uma data de fechamento, ou seja, a
data de recebimento da cotao do fornecedor.
Todas as cotaes comerciais recebidas so abertas pelo comprador envolvido (na presena do
gerente de compras e dos fornecedores) e depois so analisadas pelo valor total (custo bsico dos
materiais, impostos, frete de seguro da embalagem).
Com base do menor custo, uma oferta selecionada e uma proposta de ordem de compra elaborada.
Uma proposta de OC enviada ao departamento Financeiro e um aval obtido.
s vezes, mais de uma OC emitida para uma consulta. Por exemplo, de 4 materiais, 2 so mais baratos
de um fornecedor e 2 de outro. Em uma OC todo material solicitado possui uma data limite para
entrega. Ainda em algumas ordens de compra, quando a quantidade solicitada grande (esta situao
tpica em aquisio de materiais por atacado, cimento, ao etc.), menciona-se a entrega distribuda.
A OC considerada efetiva a partir da data de aceitao pelos fornecedores. Os fornecedores

entregam o material para o departamento de Estoque e enviam uma fatura para o departamento de
Compras.
Ao receber a declarao de Aceitao do departamento solicitante, o departamento de Compras checa

a fatura e envia a solicitao de pagamento para o departamento Financeiro. Em caso de quaisquer
discrepncias em termos e condies, essa fatura rejeitada. Ao enviar as faturas, so feitos ajustes
de qualquer material que rejeitado pelos solicitantes (esses dados so mencionados pelos
solicitantes na declarao de Recebimento de Material).
Os fornecedores enviam uma cotao tcnica e comercial (licitao de 2 etapas). Se qualquer

discrepncia for encontrada, essas cotaes so rejeitadas aps a data de fechamento da consulta.
Modelo Ambiental
(Ref. Sistema de Aquisio de Material)
Lista de Eventos
Recebimento de solicitaes de compra dos departamentos

Recebimento dos dados do departamento de estoque
Recebimento de cotaes de fornecedores
Aceitao da ordem de compra por parte dos fornecedores
Disponibilidade de dados de recebimento de material
Envio de fatura pelos fornecedores
Recebimento do aval do departamento financeiro
Recebimento de oramentos alocados
Diagrama de Contexto Nvel 0

ERD do Sistema de Aquisio de Materiais

Referncias:
Software Requirements - Anlysis and Specification - Alan M. Davis, Printice Hall.
Systems Analysis & Design Methods - J. L. Whitten, L. D. Bentley e V. M. Barlow Richard d. Iriwin Inc -
Galgotia Publications Pvt. Ltd.
Software Engineering - Ian Sommerville Addison - Wesley Publishers Ltd.
Introducing Systems Analysis - Steven Skidmore - BPB Publications.

Engenharia de Requisitos PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Engenharia de Requisitos PDF

Hochgeladen von

Copyright:

Verfügbare Formate

CURSO ENGENHARIA DE REQUISITOS 1

a) Quem sero os usurios?

Especificao de Requisitos de Software

O valor do contador foi retirado do ltimo registro.

A declarao, aparentemente completa, no menciona o tipo de elementos da matriz. So

O resultado de uma solicitao ao sistema dever ser exibido dentro de 10 segundos.

Quais so as excees para a exigncia dentro de 10 segundos?

Todos os requisitos devem estar corretos. No podem existir erros reais.

Todos os requisitos devem ser consistentes e no-conflitantes.

Mdulo 02 Entendendo os Requisitos

a) Funcionais: especificam o que o sistema deve fazer. Por exemplo:

Alguns exemplos de requisitos no funcionais so:

O software deve ser desenvolvido usando linguagem C em um sistema baseado no UNIX.

a) Nvel de satisfao - Existem trs tipos:

b) Prioridade: Forma de priorizar os requisitos. Eles podem ser classificados como:

d) Categorias de usurio: Como definimos na introduo, haver muitos interessados em um sistema.

Mdulo 03 Requisitos de Modelagem

A seguir, descreveremos os elementos usados na Metodologia de Anlise e Design de Sistemas

Diagrama de Fluxo de Dados (Data Flow Diagram DFD):

Um DFD usado para processos de modelagem e suas interaes.

Diagrama de Relacionamento de Entidade (Entity Relationship Diagram ERD):

Um ERD utilizado para modelagem dos dados e seus relacionamentos.

Contm uma lista organizada da estrutura dos dados.

Figura 1: Diagrama de Relacionamento de Entidade - ERD.

Figura 2: Diagrama de fluxo de dados - DFD.

Figura 3: Dicionrio de dados.

Tabelas de Deciso e rvores de Deciso:

So utilizadas para modelar decises complexas.

Figura 4: rvores de Deciso.

Para especificar processos estruturados (algoritmos), utiliza-se termos em Portugus.

Figura 5: Portugus Estruturado.

Diagrama de Transio de Estado:

utilizado para modelar alteraes do estado do sistema.

Figura 6: Diagrama de Transio de Estado.

Diagrama de Fluxo de Dados

o So externos ao sistema, mas

o Devem ser desenhados no nvel 0, mas

o Devem receber nomes significativos.

o As duplicidades devem ser

o As atividades de processamento de informaes devem ser indicadas em todos os nveis.

o No nvel 0, exibido um nico processo, representando o sistema.

o Em nveis subsequentes, o nmero de processos deve ser limitado a 7 2.

Figura 7: Notao de Processo.

o So reas usadas para armazenar informaes e no so visualizadas

o Todos os repositrios de dados devem ser exibidos no Nvel 1.

o As duplicaes precisam ser indicadas.

o Indicam o fluxo das informaes.

o Precisam ser exibidos em todos os

O pedido do cliente emite uma ordem de venda. O

O ERD ajuda a organizar os dados de maneira

O ERD consiste de trs componentes:

Representa uma coleo de objetos ou coisas

Expressam as propriedades das entidades.

Os atributos so classificados como chaves de entidade e descritores de entidade.

Descrevem a associao entre entidades, que podem ser:

Os relacionamentos podem ser de trs tipos:

Um-para-um: Significa que uma ocorrncia

Por exemplo, a entidade A tem os cdigos

Por exemplo, em uma nota fiscal, um cliente

Muitos-para-muitos: No relacionamento muitos para muitos uma ocorrncia da primeira

Por exemplo, em uma nota fiscal (entidade

Notao de Peter Chen

Abaixo seguem alguns exemplos de diagramas ERD usando notao de Bachman: