SlideShare uma empresa Scribd logo
Introdução ao Desenvolvimento de Sistemas
Janynne L. S. Gomes
AULA 2
LEVANTAMENTO E ANÁLISE DE
REQUISITOS – PARTE 1
2
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
3
Agenda
• O que é um requisito?
• Classificação dos requisitos
●
Funcionais
●
Não Funcionais
●
De produto
●
Organizacionais
●
Externos
●
De domínio
●
Do usuário
●
Do sistema
• Vocabulário
• Referências
3
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
4
O que é um requisito?
"Uma condição ou capacidade que um usuário necessita para
resolver um problema ou alcançar um objetivo. Uma condição ou
capacidade que deve ser satisfeita por um sistema para satisfazer um
contrato ou um padrão" IEEE - Institute of Electrical and Electronics
Engineers
"Os requisitos para um sistema de software estabelecem o que o sistema
deve fazer e definem restrições sobre sua operação e implementação."
Sommerville
"Condição necessária para a obtenção de certo objetivo, ou para o
preenchimento de certo fim." Dicionário Aurélio
5
O que é um requisito?
Para que o processo de
desenvolvimento de software
seja bem sucedido é
fundamental que haja uma
compreensão completa dos
requisitos de software.
Tanto o desenvolvedor como o
cliente desempenham um
papel ativo na análise e
especificação dos requisitos.
6
O que é um requisito?
Tentativa de solução do problema
Desenvolvedor Cliente
Indagações
O que?
Tentativa de passar informações do
negócio
Um sistema sob encomenda
Pra que?
Como?
Por que?
Pra automatizar
o agendamento
de consultas e exames
Porque queremos
que o próprio paciente
escolha o melhor
horário, sem necessitar
ocupar nossa secretária
Através de uma
ferramenta online
7
Objetivos dos requisitos

Estabelecer e manter concordância
com os clientes e outros envolvidos
sobre o que o sistema deve fazer;

Oferecer aos desenvolvedores uma
compreensão melhor do sistema a
ser desenvolvido;

Delimitar o sistema;

Planejar o desenvolvimento do
sistema;

Fornecer uma base para estimar o
custo e o tempo de desenvol-
vimento do sistema.
8
Classificação
De acordo com Sommerville (2007), os requisitos são classificados como:
1)Funcionais
2)Não funcionais
3)De domínio
4)Do usuário
5)Do sistema
9
Requisitos Funcionais(RF)
São requisitos que descrevem a funcionalidade (funções
que o sistema deve realizar) ou os serviços que se
espera que o sistema faça.
Exemplos:

cadastro de cliente

emissão de nota fiscal

consulta ao estoque

geração de pedido

emissão de relatório de vendas

lançamento de notas de aluno
10
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno
11
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno Cadastro de avaliação
12
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno Cadastro de avaliação
Cadastro de aluno
na turma
13
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno Cadastro de avaliação
Cadastro de aluno
na turma
Cadastro de nota de
uma avaliação do aluno
14
Requisitos Não-Funcionais(RNF)
São requisitos que não dizem respeito diretamente à
funcionalidade do sistema, mas expressam propriedades
do sistema e/ou restrições sobre os serviços ou funções por
ele providas.
Se categorizam em 3 tipos:

Requisitos de produto

Requisitos Organizacionais

Requisitos Externos
15
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:

Requisitos de Facilidade de Uso ou de Usabilidade:
referem-se ao esforço para utilizar ou aprender a utilizar
o produto. Estão relacionados com a interação do usuário
junto ao sistema.
16
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:

Requisitos de Confiabilidade: referem-se à frequência de
ocorrência de falhas e recuperabilidade em caso de falha,
como:
●
tempo médio de falhas
●
probabilidade de indisponibilidade
●
taxa de ocorrência de falhas; tempo de reinício após falha
●
percentual de eventos causando falhas
●
probabilidade de corrupção de dados após falha
17
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:

Requisitos de Eficiência: referem-se ao desempenho do
sistema e estão associados à eficiência, uso de recursos e
tempo de resposta da aplicação, como: transações
processadas/segundo; tempo de resposta do
usuário/evento, entre outros.
18
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:

Requisitos de Portabilidade: são relativos à capacidade
de transferir o produto para outros ambientes
19
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:

Requisitos de Implementação: ligados às regras de
codificação e restrições de software e hardware usados
para desenvolver ou executar o sistema
20
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:

Requisitos de Padrões: referem-se à definição da
linguagem de programação e às normas que devem ser
seguidas pelo sistema ou no processo de desenvolvimento.
21
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:

Requisitos de entrega: referem-se ao modo como será
implantada a solução como configurações necessárias e
ordem de instalação dos pacotes.
22
Requisitos Não-Funcionais(RNF)
Requisitos Externos
São requisitos procedentes de fatores externos ao sistema e ao seu
processo de desenvolvimento, como por exemplo:
●
Requisitos Éticos
●
Requisitos Legais (como política de privacidade e direitos autorais)
●
Requisitos de Interoperabilidade
Exemplos: o sistema não deverá revelar aos operadores nenhuma
informação pessoal sobre os clientes, além de seus nomes e o número
de referência (legislação de privacidade); em razão das restrições
referentes aos direitos autorais, alguns documentos devem ser excluídos
imediatamente ao serem fornecidos.
23
Requisitos Não-Funcionais(RNF)
Taxonomia dos RNF
24
Requisitos de Domínio
São requisitos derivados do domínio da aplicação do
sistema. Ao invés de serem obtidos a partir das necessidades
específicas dos usuários do sistema, eles podem se
transformar em novos requisitos funcionais, ou serem regras
de negócios específica do domínio do problema. Por
exemplo:

Utilização de uma interface padrão utilizando a norma
Z39.50;

Disponibilização de arquivos somente para leitura devido
aos direitos autorais;
25
Requisitos do Usuário
São os requisitos funcionais e
não funcionais do sistema sob o
ponto de vista do usuário. Em
geral apresentam problemas
como falta de clareza, confusão e
fusão, ou seja, requisitos
diferentes escritos como um
único requisito.
26
Requisitos do Sistema
São descrições mais detalhadas
dos requisitos do usuário. São a
base para que os engenheiros de
software possam fazer o projeto
do sistema. Servem como base
para um contrato destinado à
implementação do sistema.
27
Referência
LEITE, Jair C. Ciclo de vida de Software. 2007.
• Disponível em: http://engenhariadesoftware.blogspot.com/2007/02/ciclo-
de-vida-do-software-parte-1.html
• PINTAUD, Marcelo e OLIVEIRA, Elisamara. Engenharia de Software e
Engenharia de Requisitos. 2014.
• FIGUEIREDO, IRIA LUPPI. 2008.
http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informaca
o_na_empresa
27
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
28
Extras
Algumas empresas que trabalham com desenvolvimento de software
no Brasil:
• http://www.totvs.com
• http://www.thoughtworks.com
• http://www.hbsis.com.br
• http://www.ciandt.com/br-pt
• http://www.bhsistemas.com.br
• http://www.lambda3.com.br
29
Vocabulário
Stakeholders (Influenciadores / Envolvidos):
São as partes interessadas no projeto, ou seja,
são pessoas e organizações envolvidas no
projeto ou que possuem interesses que podem
ser afetados pelo projeto, podendo exercer
influência sobre os resultados do projeto.
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
30
Vocabulário
DERS - Documento de Especificação de Requisitos de Software:
De acordo com o IEEE este documento deve ser completo e não
ambíguo, sendo responsável por auxiliar os clientes de software a
descrever com precisão o que eles desejam obter, e desenvolvedores
de software a entender exatamente o que o cliente deseja. Para os
clientes, desenvolvedores e outros indivíduos ligados ao projeto, um
bom DERS deve prover diversos benefícios, tais como:
●
Estabelecer a base de acordo entre os clientes e a empresa fornecedora
sobre o que o software irá fazer;
●
Reduzir o esforço de desenvolvimento;
●
Prover uma base para estimativas de custo e prazos;
●
Prover uma base para validação e verificação do produto;
●
Facilitar a manutenção do produto de software final.
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
31
Praticando
Responda ao questionário:
1. Stakeholder é qualquer pessoa que vá comprar o software em
desenvolvimento.
(a)Verdadeiro
(b)Falso
2) É relativamente comum para diferentes usuários propor requisitos
conflitantes, cada qual argumentando que sua versão é a mais
adequada ou melhor.
(a) Verdadeiro
(b) Falso
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
32
Praticando
Responda ao questionário:
3) Qual a definição de requisitos segundo o IEEE?
4) Defina Requisitos Funcionais e Requisitos Não-Funcionais.
5) Exemplifique requisitos :
●
Funcionais
●
Não funcionais
●
Do usuário
●
Do sistema
●
De domínio
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
33
Disciplina: Introdução ao Desenvolvimento de Sistemas
Professora: Janynne L. S. Gomes
Contato: janynne.gomes@outlook.com
www.eteit.univale.br

Mais conteúdo relacionado

Mais procurados

Banco de Dados - Conceitos Básicos
Banco de Dados - Conceitos BásicosBanco de Dados - Conceitos Básicos
Banco de Dados - Conceitos Básicos
Adriano Leite da Silva
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
Paulo Furtado
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
Rildo (@rildosan) Santos
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
Leinylson Fontinele
 
engenharia-de-requisitos
engenharia-de-requisitosengenharia-de-requisitos
engenharia-de-requisitos
Fábio Nogueira de Lucena
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
Diagrama de caso de uso
Diagrama de caso de usoDiagrama de caso de uso
Diagrama de caso de uso
Stefanie Martins
 
Aula 1 - Introdução a Engenharia de Software
Aula 1 -  Introdução a Engenharia de SoftwareAula 1 -  Introdução a Engenharia de Software
Aula 1 - Introdução a Engenharia de Software
Leinylson Fontinele
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
Jefferson Bessa
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasGustavo Gonzalez
 
Introdução a Web Services
Introdução a Web ServicesIntrodução a Web Services
Introdução a Web Services
Fabio Leal
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
Mailson Queiroz
 
Aula UML - Unified Modeling Language
Aula UML - Unified Modeling LanguageAula UML - Unified Modeling Language
Aula UML - Unified Modeling Language
Cloves da Rocha
 
UML
UMLUML
Descrição formal de Casos de Uso
Descrição formal de Casos de UsoDescrição formal de Casos de Uso
Descrição formal de Casos de Uso
Natanael Simões
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
sergiocrespo
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidor
Marcia Abrahim
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais okMarcos Morais de Sousa
 

Mais procurados (20)

Banco de Dados - Conceitos Básicos
Banco de Dados - Conceitos BásicosBanco de Dados - Conceitos Básicos
Banco de Dados - Conceitos Básicos
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
 
engenharia-de-requisitos
engenharia-de-requisitosengenharia-de-requisitos
engenharia-de-requisitos
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Diagrama de caso de uso
Diagrama de caso de usoDiagrama de caso de uso
Diagrama de caso de uso
 
Aula 1 - Introdução a Engenharia de Software
Aula 1 -  Introdução a Engenharia de SoftwareAula 1 -  Introdução a Engenharia de Software
Aula 1 - Introdução a Engenharia de Software
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de Sistemas
 
Introdução a Web Services
Introdução a Web ServicesIntrodução a Web Services
Introdução a Web Services
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Aula UML - Unified Modeling Language
Aula UML - Unified Modeling LanguageAula UML - Unified Modeling Language
Aula UML - Unified Modeling Language
 
UML
UMLUML
UML
 
A Linguagem UML
A Linguagem UMLA Linguagem UML
A Linguagem UML
 
Descrição formal de Casos de Uso
Descrição formal de Casos de UsoDescrição formal de Casos de Uso
Descrição formal de Casos de Uso
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidor
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok
 

Semelhante a Definição e classificação dos requisitos

Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
Felipe Oliveira
 
Modelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfModelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdf
IvanFontainha
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitosGlauber Aquino
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
Jaffer Veronezi
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Cris Fidelix
 
06 Requisitos
06 Requisitos06 Requisitos
06 Requisitos
Waldemar Roberti
 
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
IedaRosanaKollingWie
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
Marcelo Yamaguti
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
José Vieira
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
Manuel Menezes de Sequeira
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Rosanete Grassiani dos Santos
 
Analise de requisitos estudo para prova
Analise de requisitos estudo para provaAnalise de requisitos estudo para prova
Analise de requisitos estudo para prova
Leonardo Almeida
 
Aula03
Aula03Aula03
Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 

Semelhante a Definição e classificação dos requisitos (20)

Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
 
Modelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfModelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdf
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
 
06 Requisitos
06 Requisitos06 Requisitos
06 Requisitos
 
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
Analise sistemas 04
Analise sistemas 04Analise sistemas 04
Analise sistemas 04
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Analise de requisitos estudo para prova
Analise de requisitos estudo para provaAnalise de requisitos estudo para prova
Analise de requisitos estudo para prova
 
Aula03
Aula03Aula03
Aula03
 
Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03
 
Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05
 

Definição e classificação dos requisitos

  • 1. Introdução ao Desenvolvimento de Sistemas Janynne L. S. Gomes
  • 2. AULA 2 LEVANTAMENTO E ANÁLISE DE REQUISITOS – PARTE 1 2 Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 3. 3 Agenda • O que é um requisito? • Classificação dos requisitos ● Funcionais ● Não Funcionais ● De produto ● Organizacionais ● Externos ● De domínio ● Do usuário ● Do sistema • Vocabulário • Referências 3 Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 4. 4 O que é um requisito? "Uma condição ou capacidade que um usuário necessita para resolver um problema ou alcançar um objetivo. Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão" IEEE - Institute of Electrical and Electronics Engineers "Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação." Sommerville "Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim." Dicionário Aurélio
  • 5. 5 O que é um requisito? Para que o processo de desenvolvimento de software seja bem sucedido é fundamental que haja uma compreensão completa dos requisitos de software. Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise e especificação dos requisitos.
  • 6. 6 O que é um requisito? Tentativa de solução do problema Desenvolvedor Cliente Indagações O que? Tentativa de passar informações do negócio Um sistema sob encomenda Pra que? Como? Por que? Pra automatizar o agendamento de consultas e exames Porque queremos que o próprio paciente escolha o melhor horário, sem necessitar ocupar nossa secretária Através de uma ferramenta online
  • 7. 7 Objetivos dos requisitos  Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer;  Oferecer aos desenvolvedores uma compreensão melhor do sistema a ser desenvolvido;  Delimitar o sistema;  Planejar o desenvolvimento do sistema;  Fornecer uma base para estimar o custo e o tempo de desenvol- vimento do sistema.
  • 8. 8 Classificação De acordo com Sommerville (2007), os requisitos são classificados como: 1)Funcionais 2)Não funcionais 3)De domínio 4)Do usuário 5)Do sistema
  • 9. 9 Requisitos Funcionais(RF) São requisitos que descrevem a funcionalidade (funções que o sistema deve realizar) ou os serviços que se espera que o sistema faça. Exemplos:  cadastro de cliente  emissão de nota fiscal  consulta ao estoque  geração de pedido  emissão de relatório de vendas  lançamento de notas de aluno
  • 10. 10 Requisitos Funcionais(RF) Cada requisito deixa sua contribuição para a construção de uma parte do sistema. Cadastro de aluno
  • 11. 11 Requisitos Funcionais(RF) Cada requisito deixa sua contribuição para a construção de uma parte do sistema. Cadastro de aluno Cadastro de avaliação
  • 12. 12 Requisitos Funcionais(RF) Cada requisito deixa sua contribuição para a construção de uma parte do sistema. Cadastro de aluno Cadastro de avaliação Cadastro de aluno na turma
  • 13. 13 Requisitos Funcionais(RF) Cada requisito deixa sua contribuição para a construção de uma parte do sistema. Cadastro de aluno Cadastro de avaliação Cadastro de aluno na turma Cadastro de nota de uma avaliação do aluno
  • 14. 14 Requisitos Não-Funcionais(RNF) São requisitos que não dizem respeito diretamente à funcionalidade do sistema, mas expressam propriedades do sistema e/ou restrições sobre os serviços ou funções por ele providas. Se categorizam em 3 tipos:  Requisitos de produto  Requisitos Organizacionais  Requisitos Externos
  • 15. 15 Requisitos Não-Funcionais(RNF) Requisitos de produto São requisitos que especificam o comportamento do produto, como por exemplo:  Requisitos de Facilidade de Uso ou de Usabilidade: referem-se ao esforço para utilizar ou aprender a utilizar o produto. Estão relacionados com a interação do usuário junto ao sistema.
  • 16. 16 Requisitos Não-Funcionais(RNF) Requisitos de produto São requisitos que especificam o comportamento do produto, como por exemplo:  Requisitos de Confiabilidade: referem-se à frequência de ocorrência de falhas e recuperabilidade em caso de falha, como: ● tempo médio de falhas ● probabilidade de indisponibilidade ● taxa de ocorrência de falhas; tempo de reinício após falha ● percentual de eventos causando falhas ● probabilidade de corrupção de dados após falha
  • 17. 17 Requisitos Não-Funcionais(RNF) Requisitos de produto São requisitos que especificam o comportamento do produto, como por exemplo:  Requisitos de Eficiência: referem-se ao desempenho do sistema e estão associados à eficiência, uso de recursos e tempo de resposta da aplicação, como: transações processadas/segundo; tempo de resposta do usuário/evento, entre outros.
  • 18. 18 Requisitos Não-Funcionais(RNF) Requisitos de produto São requisitos que especificam o comportamento do produto, como por exemplo:  Requisitos de Portabilidade: são relativos à capacidade de transferir o produto para outros ambientes
  • 19. 19 Requisitos Não-Funcionais(RNF) Requisitos Organizacionais São requisitos derivados das políticas organizacionais do cliente e do desenvolvedor, como por exemplo:  Requisitos de Implementação: ligados às regras de codificação e restrições de software e hardware usados para desenvolver ou executar o sistema
  • 20. 20 Requisitos Não-Funcionais(RNF) Requisitos Organizacionais São requisitos derivados das políticas organizacionais do cliente e do desenvolvedor, como por exemplo:  Requisitos de Padrões: referem-se à definição da linguagem de programação e às normas que devem ser seguidas pelo sistema ou no processo de desenvolvimento.
  • 21. 21 Requisitos Não-Funcionais(RNF) Requisitos Organizacionais São requisitos derivados das políticas organizacionais do cliente e do desenvolvedor, como por exemplo:  Requisitos de entrega: referem-se ao modo como será implantada a solução como configurações necessárias e ordem de instalação dos pacotes.
  • 22. 22 Requisitos Não-Funcionais(RNF) Requisitos Externos São requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento, como por exemplo: ● Requisitos Éticos ● Requisitos Legais (como política de privacidade e direitos autorais) ● Requisitos de Interoperabilidade Exemplos: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade); em razão das restrições referentes aos direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos.
  • 24. 24 Requisitos de Domínio São requisitos derivados do domínio da aplicação do sistema. Ao invés de serem obtidos a partir das necessidades específicas dos usuários do sistema, eles podem se transformar em novos requisitos funcionais, ou serem regras de negócios específica do domínio do problema. Por exemplo:  Utilização de uma interface padrão utilizando a norma Z39.50;  Disponibilização de arquivos somente para leitura devido aos direitos autorais;
  • 25. 25 Requisitos do Usuário São os requisitos funcionais e não funcionais do sistema sob o ponto de vista do usuário. Em geral apresentam problemas como falta de clareza, confusão e fusão, ou seja, requisitos diferentes escritos como um único requisito.
  • 26. 26 Requisitos do Sistema São descrições mais detalhadas dos requisitos do usuário. São a base para que os engenheiros de software possam fazer o projeto do sistema. Servem como base para um contrato destinado à implementação do sistema.
  • 27. 27 Referência LEITE, Jair C. Ciclo de vida de Software. 2007. • Disponível em: http://engenhariadesoftware.blogspot.com/2007/02/ciclo- de-vida-do-software-parte-1.html • PINTAUD, Marcelo e OLIVEIRA, Elisamara. Engenharia de Software e Engenharia de Requisitos. 2014. • FIGUEIREDO, IRIA LUPPI. 2008. http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informaca o_na_empresa 27 Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 28. 28 Extras Algumas empresas que trabalham com desenvolvimento de software no Brasil: • http://www.totvs.com • http://www.thoughtworks.com • http://www.hbsis.com.br • http://www.ciandt.com/br-pt • http://www.bhsistemas.com.br • http://www.lambda3.com.br
  • 29. 29 Vocabulário Stakeholders (Influenciadores / Envolvidos): São as partes interessadas no projeto, ou seja, são pessoas e organizações envolvidas no projeto ou que possuem interesses que podem ser afetados pelo projeto, podendo exercer influência sobre os resultados do projeto. Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 30. 30 Vocabulário DERS - Documento de Especificação de Requisitos de Software: De acordo com o IEEE este documento deve ser completo e não ambíguo, sendo responsável por auxiliar os clientes de software a descrever com precisão o que eles desejam obter, e desenvolvedores de software a entender exatamente o que o cliente deseja. Para os clientes, desenvolvedores e outros indivíduos ligados ao projeto, um bom DERS deve prover diversos benefícios, tais como: ● Estabelecer a base de acordo entre os clientes e a empresa fornecedora sobre o que o software irá fazer; ● Reduzir o esforço de desenvolvimento; ● Prover uma base para estimativas de custo e prazos; ● Prover uma base para validação e verificação do produto; ● Facilitar a manutenção do produto de software final. Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 31. 31 Praticando Responda ao questionário: 1. Stakeholder é qualquer pessoa que vá comprar o software em desenvolvimento. (a)Verdadeiro (b)Falso 2) É relativamente comum para diferentes usuários propor requisitos conflitantes, cada qual argumentando que sua versão é a mais adequada ou melhor. (a) Verdadeiro (b) Falso Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 32. 32 Praticando Responda ao questionário: 3) Qual a definição de requisitos segundo o IEEE? 4) Defina Requisitos Funcionais e Requisitos Não-Funcionais. 5) Exemplifique requisitos : ● Funcionais ● Não funcionais ● Do usuário ● Do sistema ● De domínio Introdução ao Desenvolvimento de Software Janynne L. S. Gomes
  • 33. 33 Disciplina: Introdução ao Desenvolvimento de Sistemas Professora: Janynne L. S. Gomes Contato: janynne.gomes@outlook.com www.eteit.univale.br