REQUISITOS_FUNCIONAIS-NAO_FUNCIONAIS

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

1 
Análise de Requisitos 
•Funcionais 
•Não Funcionais 
2 
Análise de Sistemas 
•Qualquer que seja o método utilizado no 
desenvolvimento de sistemas, o primeiro passo deve 
ser o de obtenção de requisitos => ponto 
fundamental; 
 
•Diversas técnicas existem para que os 
dados/informações sejam obtidos: entrevistas, 
questionários, observação direta, brainstorming, entre 
outras. 
 
3 
Requisitos 
 É o 1º passo no modelo do processo. O que devo fazer 
e não a forma como será implementado. Serve como 
contrato entre desenvolvedor e comprador. 
 É o processo de aquisição, refinamento e verificação 
das necessidades do sistema. 
 O objetivo é sistematizar o processo de definição dos 
requisitos, obtendo uma especificação correta e 
completa do mesmo para elaboração do Documento de 
Requisitos. 
 Definição de requisito no dicionário: 
condição exigida para a consecução de 
um certo fim; 
exigência legal e necessária; 
condição; 
4 
Requisitos 
5 
Definição de Requisitos do Sistemas 
 Obter os requisitos do sistema como um todo 
estabelecendo um conjunto de objetivos gerais 
que o sistema deve cumprir; 
 Características do que o sistema deve fazer e 
não o que deve ser implementado; 
 Utilizados pelos: usuários finais de sistemas, 
desenvolvedores de software e arquitetos de 
sistemas. 
 Os requisitos são divididos em duas categorias: 
 Requisitos Funcionais e Requisitos Não 
Funcionais. 
 
6 
Requisitos Funcionais 
São declarações de funções de como o sistema 
deve reagir a entradas específicas e como deve 
comportar em determinadas situações. É uma 
interação entre o sistema e o seu ambiente. 
 
Algumas vezes, os requisitos funcionais podem 
também explicitamente declarar o que o sistema 
não deve fazer. A especificação deve ser completa 
e consistente. 
 
7 
Requisitos Funcionais 
 Exemplo: 
 O sistema deve permitir a inclusão, alteração 
e remoção de funcionários com os seguintes 
atributos: nome, endereço, cidade,etc). 
 O usuário deve ser capaz de buscar todo o 
conjunto inicial do BD ou selecionar um 
subconjunto a partir dele. 
 O sistema fornecerá telas apropriadas para 
o usuário ler documentos. 
 Cada pedido tem um único identificador. 
 
 
8 
Requisitos Não Funcionais 
 São restrições colocadas sobre como o 
sistema deve realizar seus requisitos 
funcionais. 
 Indicam as limitações no sistema e em seu 
desenvolvimento. 
9 
Requisitos Não Funcionais 
 Exemplo: 
 Ser executado em várias plataformas. 
 Funcionar em um computador com 64 
Gb de RAM. 
 Estar pronto em seis meses. 
 
10 
Requisitos Não Funcionais 
Algumas categoria dos requisitos não funcionais 
 Organizacionais: refere-se a políticas e 
procedimentos nas organizações do cliente e do 
desenvolvedor. 
 “de entrega, de implementação, padrões de 
processo” 
 Exemplo: O processo de desenvolvimento de 
sistema e os documentos a serem entregues 
deverão estar de acordo com o processo e os 
produtos a serem entregues definidos em 
XYZKL. 
 
11 
Requisitos Não Funcionais 
 Externos: refere-se a fatores externos ao 
sistema e ao seu processo de 
desenvolvimento. 
 “interoperabilidade (interação do sistema 
com outros), éticos, legais (privacidade e 
de segurança)”. 
 Exemplo: o sistema não deverá revelar 
aos operadores nenhuma informação 
pessoal sobre os clientes. 
 
 
12 
Requisitos Não Funcionais 
 De produto: especificam o comportamento do 
produto. 
 “eficiência (desempenho, espaço, rapidez, 
memória), confiabilidade, portabilidade.” 
 Exemplo: toda comunicação necessária entre o 
ambiente X e o usuário deve ser expressa no 
conjunto padrão de caracteres ANSI “Instituto 
Nacional Americano de Padronização” Seu 
equivalente no Brasil seria a ABNT Associação 
Brasileira de Normas Técnicas.. 
 
 
 
 
13 
Requisitos Não Funcionais 
 Ambiente físico : Onde o equipamento 
funcionará ? 
 Interfaces: A saída vai para outro ou 
outros sistemas ? 
 Funcionalidade: Existem limitações 
quanto à velocidade de execução, ao 
tempo de resposta, ou a saída? 
 Os usuários e os fatores humanos: 
Haverá diversos tipos de usuários? 
 
14 
Requisitos Não Funcionais 
 Documentação: Essa documentação deve 
ser online, no formato de livro, ou ambos? 
 Dados: Qual será o fluxo de dados do 
sistema? 
 Segurança: O acesso ao sistema ou às 
informações deve ser controlado? 
 Recursos: Quanto espaço físico será 
ocupado pelo sistema. 
 
15 
Como identificar requisitos? 
• Objetivo: mostrar o papel da análise 
de requisitos de sistemas e as 
principais atividades relacionadas. 
16 
Técnicas existentes: 
 Entrevista 
 Questionário 
 Observação direta 
 Sessões brainstorming. 
 
17 
Entrevista 
 Usando poucas pessoas que conhecem as 
informações necessárias para o 
desenvolvimento do sistema. 
 Precisa ser preparada antecipadamente. 
 Ter perguntas objetivas. 
 Evitar constrangimento dos participantes. 
 
18 
Entrevista 
 Antes: planejar, identificar a posição e 
responsabilidade do entrevistado, marcar 
horário, escolher local sossegado. 
 Durante: apresente-se informando a 
finalidade da entrevista, explique as 
anotações que fizer, não demore mais do 
que 2 horas, agradeça a contribuição. 
 Depois: documente os pontos relevantes; 
envie a documentação ao entrevistado 
(aprovação final), envie os resultados para os 
usuários e seus gerentes. 
 
19 
Questionário 
 Usando muitas pessoas conhecem as 
informações necessárias para o 
desenvolvimento do sistema. 
 Preparar antecipadamente com questões 
objetivas. 
 Desvantagem: comunicação restrita com 
o usuário e não há troca de informação 
face a face. A preparação exige tempo. 
 
20 
Questionário 
 Preparação: identificar o tipo de informação que 
deseja obter. Enviar carta acompanhando o 
questionário enfatizando a sua importância. 
 Identificar quem responderá: nome, função e 
localização. 
 Distribuir com instruções detalhadas de como 
preencher e o prazo de devolução 
 Analisar e consolidar as informações recebidas, 
documentar as principais descobertas e enviá-las 
juntamente com cópia do relatório para todos os 
respondentes. 
 
21 
Exemplo de requisitos 
 E o que são requisitos? 
◦ Declaração sobre um produto pretendido que especifica 
o que ele deveria fazer ou como deveria operar 
 
 Objetivos do estabelecimento de requisitos 
◦ Especificidade 
◦ Retirar ambiguidades 
◦ Clareza 
 
 Exemplos de requisitos para um site: 
◦ “Tempo de download de uma página completa em 5 s” 
◦ “Os adolescentes devem achar o site atrativo” 
◦ “Tempo de resposta rápido” 
◦ “Estrutura de menu fácil de utilizar” 
22 
Exemplo de requisitos 
3.2 TIPOS DE REQUISITOS 
 
◦ Requisitos funcionais – dizem o que o sistema deve 
fazer. Exs.: 
 Suporte a formatações 
 
 Formatação por parágrafo 
 
 Formatação por caractere 
 
◦ Requisitos não-funcionais – indicam as limitações no 
sistema e em seu desenvolvimento 
 Ser executado em várias plataformas 
 Funcionar em um computador com 64 Gb de RAM 
 Estar pronto em seis meses 
 
23 
 CUIDADOS NA ANÁLISE DE 
REQUISITOS 
 
◦ Se perguntar não sobre COMO deve ser feita 
alguma tarefa para construir o sistema, mas sobre O 
QUE é exigido 
 
◦ Estar preparado para ambiguidades: 
 “sei que você acredita que entendeu o que acha que eu 
disse, mas não estou certo de que percebe que aquilo que 
ouviu
não é o que eu pretendia dizer…” 
 
◦ Etapas que antes eram construídas posteriormente 
devem ser pensasadas em conjunto com a análise: 
 Construção do manual do usuário 
 Plano dos testes de usabilidade 
 
24 
CUIDADOS NA ANÁLISE DE 
REQUISITOS 
◦ Um analista deve exibir nos seus esforços traços característicos… 
 Compreensão de conceitos abstratos 
 Absorver fatos pertinentes 
 Entender o ambiente do usuário 
 Aplicar elementos do sistema aos elementos do usuário 
 Comunicar-se bem nas formas escrita e verbal 
 Capacidade de “ver as florestas entre as árvores” 
◦ … e coordenar cada uma das tarefas associadas à análise de requisitos de 
software 
25 
Stakeholders 
 É alguém que tem um determinado interesse no 
atual ou novo Sistema de Informação, podendo 
ser técnicos ou não-técnicos; 
 Num Sistema de Informação podem classificar-
se como: 
 Proprietários do Sistema 
 Utilizadores do Sistema 
 Analistas do Sistema 
 Projetistas do Sistema 
 Construtores (programadores) do Sistema 
 Vendedores e consultores das TI 
 
26 
Stakeholders de um SI 
 São as pessoas facilitadoras no processo de 
desenvolvimento de um sistema. Coordenam os 
esforços do proprietário, utilizadores, projetistas e 
construtores. Estes levam a cabo a análise e desenho do 
sistema; 
 Estudam os problemas e as necessidade na organização, 
determinando como as pessoas, dados, processos, 
comunicações e TI podem melhorar os processos de 
negócio.