Download - Definição e classificação dos requisitos
Introdução ao Desenvolvimento de Sistemas
Janynne L. S. Gomes
AULA 2LEVANTAMENTO 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 SoftwareJanynne 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 automatizaro agendamentode consultas e exames
Porque queremosque o próprio paciente escolha o melhorhorá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)Funcionais2)Não funcionais3)De domínio4)Do usuário5)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 deuma 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_informacao_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: [email protected]
www.eteit.univale.br