25226_23292_RequisitosParteII

Prévia do material em texto

Processo de Requisitos 
2 
Elicitação 
• Formulários 
• Entrevistas 
Análise 
• Protótipos 
• Caso de 
Uso 
Especificação 
de requisitos 
• Documentos 
Validação de 
Requisitos 
• Documento 
de 
Validação 
Obetivo do processo: Criar e Manter um Documento de Requisitos 
• Documento de 
Requisitos 
Análise de Requisitos 
3 
� Etapa que possui como objetivo: 
� detectar e resolver conflitos entre requisitos; 
� descobrir os limites do software e como ele deve interagir 
com a sua organização e ambiente operacional 
Análise de Requisitos 
4 
� Modelagem Conceitual: 
� desenvolvimento de modelos de um mundo real 
� problema é a chave para a análise de requisitos de 
software. 
� ajuda na compreensão da situação em que ocorre o 
problema , bem como a descreve uma solução. 
� Assim, modelos conceituais compreendem modelos de 
entidades do problema domínio, configurado para refletir 
sua real relacionamentos e dependências . 
� Este tópico é intimamente relacionado com os modelos 
de engenharia de software e Métodos no guia de 
conhecimento 
Análise de Requisitos 
5 
� Vários tipos de modelos podem ser desenvolvidos 
nessa fase como: 
� Diagramas de casos de uso 
� Modelos de fluxo de dados 
� Modelos de estado 
� Interações com o usuário 
� Modelos de objetos 
� Modelos de dados 
� E muitos outros. 
� Muitas destas notações de modelagem são parte da 
Unified Modeling Language (UML). 
Análise de Requisitos 
6 
� Qual modelo usar???? 
� Não confundir UML com MODELO 
Análise de Requisitos 
7 
� Os fatores que influenciam a escolha da modelagem 
� notação incluem os seguintes: 
� Natureza do problema 
� Tempo real: SysML (Systems Modeling Language) 
� Experiência do Engenheiro de Software 
� Imposição do cliente 
 
� **Necessário conhecer todos para tomar a decisão 
 
8 
� O uso de diagramas de casos , por exemplo , são rotineiramente utilizados para 
descrever situações em que os separa de fronteira os atores ( usuários ou sistemas 
no ambiente externo ) do comportamento interno onde cada caso de uso descreve 
uma funcionalidade do sistema . 
� Os fatores que influenciam a escolha da modelagem 
� notação incluem os seguintes: 
� A natureza do problema . 
� Tipo de software - Por exemplo , modelos de estado e paramétricas , que são parte 
de SysML [4] , são susceptíveis de ser mais importante para software em tempo real 
do que por informações 
� A experiência do engenheiro de software. É muitas vezes mais produtivo adotar uma 
modelagem notação ou método com o qual o software engenheiro tem experiência. 
� • Os requisitos do processo do cliente: Os clientes podem impor a sua notação 
favorecido ou método ou proibir qualquer com o qual eles não estão familiarizados . 
este fator podem entrar em conflito com o fator anterior. 
� Note-se que , em quase todos os casos , é útil começar através da construção de um 
modelo de software de contexto o contexto software fornece uma conexão entre o 
software pretendido e seu ambiente externo . 
Análise Formal 
9 
� Métodos formais são técnicas baseadas em 
formalismos matemáticos para 
a especificação, desenvolvimento e verificação dos 
sistemas de softwares e hardwares. 
� Alto custo do uso dos métodos formais faz com que, 
de modo geral, sejam usados apenas no 
desenvolvimento de sistemas de alta-integridade, 
nos quais há alta probabilidade de as falhas 
provocarem perda de vidas ou sério prejuízo. 
Análise de Requisitos 
10 
� Prototipação 
� São subconjuntos de prototipação: 
� StoryBoard, Wiframe, etc 
Análise de Requisitos 
2009- Protótipo de um novo trem de levitação magnética. Instituto de pós-graduação e 
Pesquisa em engenharia da UFRJ (Coope). 
Fonte:http://www.ct.ufrj.br/boletim/anteriores/v4n4/index.htm 
Análise de Requisitos 
Fonte: http://www.cin.ufpe.br/~asg/publications/files/WDDS_Final.pdf 
Prototipação pode servir como técnica de análise 
Análise de Requisitos 
Prototipação Feita na ferramenta 
Gratuíta Proface 
Prototipação pode servir como técnica de análise 
Análise de Requisitos 
Prototipação feita no Excel 
Prototipação pode servir como técnica de análise 
Análise de Requisitos 
Prototipação feita no sistema paga Delphi 
Análise de Requisitos 
� Prototipação 
� Segundo o padrão IEEE-830 [Byrne 1994], os 
protótipos são úteis pelas seguintes razões: 
� Antecipam aspectos do comportamento do sistema, produzindo 
não apenas respostas mas também novos questionamentos; 
� Permitir aos usuários ter uma visão mais amigável quando 
comparado a leitura de um Documento de Especificação dos 
Requisitos (DER). Isso possibilita uma maior agilidade na 
valdidaçõ dos requisitos elicitados. 
� Um documento de especificação de requisitos baseado em 
protótipos tende a apresentar menos mudanças durante o 
desenvolvimento, diminuindo assim o tempo gasto nessa fase. 
Análise de Requisitos 
� Ferramentas 
� Proface 
� Baixar em: 
http://sourceforge.net/search/?type_of_search=soft&words=proface 
� Comentários em: 
� http://zeluisbraga.wordpress.com/2007/04/11/prototipacao-de-
interfaces-o-proface/ 
 
� Pencil Project : http://pencil.evolus.vn/ 
Processo de Requisitos 
18 
Elicitação 
• Formulários 
• Entrevistas 
Análise 
• Protótipos 
• Caso de 
Uso 
Especificação 
de requisitos 
• Documentos 
Validação de 
Requisitos 
• Documento 
de 
Validação 
Obetivo do processo: Criar e Manter um Documento de Requisitos 
• Documento de 
Requisitos 
Especificação de Requisitos 
19 
� Especiação de requisitos: normalmente se refere à 
produção de um documento que pode ser 
sistematicamente revistos, avaliado e aprovado. 
� Para sistemas complexos três diferentes tipos de 
documentos são produzidos: 
� Documento de Definição do Sistema (DDS) 
 
Documento de Definição do Sistema (DDS) 
20 
� Este documento (também conhecido como o usuário 
documento de requisitos ou documento de conceito de 
operações) 
� Registra os requisitos do sistema e define os requisitos 
do sistema de alto nível 
� Em geral, os leitores são: representantes do usuários do 
sistema e clientes 
� O documento lista o requisitos do sistema , juntamente 
com fundo informações sobre os objetivos globais para o 
sistema , o seu ambiente de destino , e uma declaração 
das restrições, suposições e requisitos não funcionais. 
� Pode incluir modelos conceituais concebida para ilustrar 
o contexto do sistema , o uso cenários, e as principais 
entidades de domínio , como bem como os fluxos de 
trabalho . 
Documento de Especificação de Requisitos 
de Sistema 
21 
 
� Os desenvolvedores de sistemas com software substancial 
� e componentes de um avião de passageiros moderno , nonsoftware 
� por exemplo , muitas vezes separar a descrição 
� dos requisitos do sistema a partir da descrição 
� de requisitos de software. Neste ponto de vista , o sistema de 
� requisitos especificados , os requisitos de software 
� são derivados dos requisitos do sistema, 
� e , em seguida, os requisitos para os componentes de software 
� são especificadas . Estritamente falando , o sistema de 
� especificação de requisitos é uma engenharia de sistemas 
� atividade e está fora do escopo deste 
� Guia . 
Especificação de Requisitos de Software 
 
22 
� A Especificação de Requisitos de Software 
estabelece a base para um acordo entre clientes e 
empreiteiros ou fornecedores 
� Contém o que o software deve fazer, bem como o 
que não se espera fazer. 
� As organizações também podem usar esse 
documento como base para desenvolvimento de 
verificação e validação 
 
Especificação de Requisitos de Software23 
� Os requisitos de software são muitas vezes escritos em linguagem natural, 
mas, pode ser completada por descrições formais ou descrições 
semiformais. Seleção de notações apropriadas permite requisitos 
particulares e aspectos da arquitetura de software para ser descrito com 
mais precisão e concisa de linguagem natural. 
� A regra geral é que as notações devem permitir que os requisitos sejam 
descritos de forma tão precisa quanto possível. isto é particularmente 
crucial para a segurança crítica, regulamentar , e outros tipos de software 
confiável. 
� No entanto , a escolha de notação é frequentemente afetada pela formação 
, habilidades e preferências dos autores e leitores do documento. 
� Uma série de indicadores de qualidade pode ser utilizado para relacionar a 
qualidade de especificação de requisitos de software com outras 
variáveis ​​do projeto , como custo , aceitação, performance, cronograma e 
reprodutibilidade. 
� Os indicadores de qualidade para o documento de requisitos de software 
incluem o tamanho , legibilidade , especificação , a profundidade e estrutura 
do texto . 
Especificação de Requisitos de Software 
24 
Clientes do 
Sistema 
Especificam os requisitos e os lêem para 
verificar se eles atendem suas 
necessidades. Especificam as mudanças 
nos requisitos. 
Gerentes 
 
Utilizam o documento de requisitos para 
planejar um pedido de proposta para o 
sistema e planejar o processo de 
desenvolvimento do sistema 
Engenheiros do 
Sistema 
Utilizam os requisitos para compreender 
que sistema deve ser desenvolvido. 
Especificação e os atores 
25 
Engenheiros de 
Teste do 
Sistema 
Utilizam os requisitos para 
desenvolver testes de validação para 
o sistema. 
Engenheiros de 
Manutenção do 
Sistema 
Utilizam o documento de requisitos para 
ajudar a compreender o sistema e as 
relações entre suas partes. 
Especificação de Requisitos 
26 
1. Seguiremos o padrão IEE 
2. É o resultado da Elicitação dos requisitos 
3. Servirá como documento de Escopo – MUITO 
IMPORTANTE 
1. Preços 
2. Cronogramas 
3. Gerenciamento de mudanças 
4. Linguagem fácil de entender e ler 
5. Pode necessitar de visões diferentes de acordo com o 
perfil do usuário 
6. Complementar com prototipação 
 
 
 
Especificação de Requisitos 
27 
1. Descrição dos Casos de Uso 
1. Gerado a partir do documento de especificação de 
requisitos 
2. MUITO importante, pois a partir dele serão gerados 
outros documentos 
3. Servirá de guia inicial para a elaboração dos outro 
diagramas 
4. Servirá de guia inicial para os desenvolvedores 
1. Não pode ser ambíguo 
5. Servirá para divisão de tarefas 
 
Especificação - Padrão IEEE para o 
Documento de Requisitos 
28 
1. Introdução 
1.1 Propósito do documento de requisitos 
� Motivações, público alvo, … 
1.2 Escopo do produto 
� Explicitar o que o produto faz (e o que não faz). 
� Descrever a aplicação. 
1.3. Definições, acrônimos e abreviações 
1.4. Referências 
� Listar todos os documentos referenciados. 
� Especificar a origem dos documentos. 
1.5. Visão Geral do restante do documento 
� Estrutura / Organização. 
 
 
Espeficificação - Padrão IEEE para o 
Documento de Requisitos 
29 
2. Descrição Geral 
2.1 Perspectiva do Produto 
� Relacionamento: sistema, usuário, hardware, software, 
comunicação. 
2.2 Funcionalidades do produto 
2.3. Características do Usuário 
2.4. Restriçoes Gerais 
� Limitações de hardware, consideraçoes sobre segurança. 
2.5. Suposições e Dependências 
� Máquina específica, SO, ... 
 
 
Espeficificação - Padrão IEEE para o 
Documento de Requisitos 
30 
3. Requisitos específicos 
� Abrangem requisitos funcionais, não funcionais e de interface. 
 
� Os requisitos podem documentar interfaces externas, descrever 
funcionalidade e desempenho do sistema, especificar requisitos 
lógicos de banco de dados, restrições de projeto, propriedades 
emergentes do sistema e características de qualidade. 
 
4. Apêndices 
 
5. Índice 
 
 
Especificação 
31 
 
Especificação 
32 
 
Especificação 
 
 
 
 
 
� Quais campos para cadastro? 
� Quais são obrigatórios? 
� Qual a diferença entre um campo e outro? 
Especificação 
34 
 
Especificação 
35 
 
Especificação 
36 
 
Especificação 
37 
 
Especificação 
38 
 
Especificação 
39 
 
Especificação 
40 
 
Especificação 
41 
� Link para o documento completo 
� Link para o Caso de Uso referente a este 
documento 
42 
� Outras especificações: 
� Especificação de Caso de Uso 
� Dicionário de Dados 
� Especificação de Classes e Objetos 
Processo de Requisitos 
43 
Elicitação 
• Formulários 
• Entrevistas 
Análise 
• Protótipos 
• Caso de 
Uso 
Especificação 
de requisitos 
• Documentos 
Validação de 
Requisitos 
• Documento 
de 
Validação 
Obetivo do processo: Criar e Manter um Documento de Requisitos 
• Documento de 
Requisitos 
44 
 
 
 
 
 
Como produzido 
pelos programadores 
 
 
Como projetado pelo 
Analista Sênior 
Como instalado no 
site do usuário 
O que o 
usuário desejava. 
Como especificado 
Na requisição do projeto 
 
Como proposto pelo 
 patrocinador do Projeto 
45 
 
46 
� Pergunta: 
 
� Qual a diferença entre requisitos e regras de 
negócio? 
Bibliografias 
47 
� Utilizadas 
� Sommerville, I. Engenharia de Software, 8a. edição. São 
Paulo: Pearson Addison-Wesley. 2007 
� Pressman R. Engenharia de Software - 6a edição - 
McGraw-Hill Interamericana do Brasil. 2006. 
� Notas de aula Profa. Simone Rocio Senger de Souza 
� Recomendadas 
� Bibliografias utilizadas 
� Artigo 1: Soluções Concretas para Problemas Práticos 
da Engenharia de Requisitos (Edição 10 Revista de 
Engenharia de Software) 
� Artigo 2: “Recommended practice for requirements 
specification” (Thayer e Dorfman, 1997) 
 
 
Em suma 
48 
1.Concepção e Levantamento 
odefinição do escopo 
oestudo de viabilidade 
oobtenção dos requisitos 
2.Análise 
omodelos técnicos 
odefinições das prioridades, etc 
3.Relatório 
oEspecificação dos Requisitos de Software (ERS) 
4.Validação e Gestão 
oRevisão Técnica Formal, prototipação e geração de 
casos de teste 
oacompanhamento e rastreabilidade