Requisitos Aulas 1

Prévia do material em texto

CCT0415 – Requisitos de Sistemas
2018.1 – Luciana A. Teixeira
1
Definição de requisito – ISO/IEC/IEEE 24765:2010 (revisada em 2017)
ISO - International Organization for Standardization
Responsável por desenvolver e publicar padrões internacionais. A organização cria documentos que definem requisitos, especificações instruções ou características que podem ser usadas de maneira consistente para garantir que materiais, produtos, processos ou serviços sirvam a seus propósitos.
IEC - International Electrotechnical Commission
Principal organização mundial responsável pela publicação de padrões internacionais baseados em consenso. Gerencia sistemas de avaliação de conformidade para produtos elétricos e eletrônicos, sistemas e serviços, coletivamente conhecidos como eletrotecnologia.
IEEE - Institute of Electrical and Electronics Engineers
Associação mundial de profissionais que trabalham para o desenvolvimento, a implementação e a manutenção de produtos e serviços centrados na tecnologia.
Requisitos de Sistemas – Luciana A. Teixeira
2
Definição de requisito – ISO/IEC/IEEE 24765:2010 (revisada em 2017)
A ISO/IEC/IEEE 24765:2010 oferece um vocabulário comum aplicável a todos os sistemas e trabalhos na área de engenharia de software. Ela foi preparada para coletar e padronizar terminologia. Sua intenção é server de referência para aqueles que trabalham na área de tecnologia da informação.
Requisitos de Sistemas – Luciana A. Teixeira
3
DOCUMENTAÇÃO
Definição de requisito – ISO/IEC/IEEE 24765:2010 (revisada em 2017)
(2) Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto;
(1) Uma condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo;
DESEJO
PRODUTO
(3) Uma representação documentada de uma condição ou capacidade como em (1) ou (2).
Especificação de Requisitos
Requisitos de Sistemas – Luciana A. Teixeira
4
A Especificação de Requisitos
Diferentes formatos em função da metodologia de desenvolvimento de software adotada pela empresa;
Na prática, as seções incluídas normalmente são:
Introdução – breve descrição do sistema e sua proposta;
Glossário – definição dos principais termos específicos do contexto do sistema;
Modelos do sistema – modelos que documentem graficamente aspectos do sistema e facilitem, assim, a compreensão dos mesmos;
Lista de requisitos funcionais – tarefas que o sistema realizará para o usuário;
Lista de requisitos não funcionais – como as tarefas a serem realizadas serão entregues aos usuários.
Requisitos de Sistemas – Luciana A. Teixeira
5
A Especificação de Requisitos serve para quem?
Especificação de Requisitos
CLIENTE
Necessidades do cliente
Acordos sobre o projeto
Gerência de Projetos
Análise e Projeto
Implementação
Implantação
Medição e Análise
Testes
EQUIPE 
DO PROJETO
Plano de projeto e controle 
de escopo, prazo e orçamento
Projeto de solução
Projeto de banco de dados
Material de treinamento e suporte
Estimativas e medições
Casos de teste
Serve de base para a criação de:
Requisitos de Sistemas – Luciana A. Teixeira
6
A Especificação de Requisitos como contrato entre as partes
O documento de especificação de requisitos é orientado ao cliente e não à equipe de desenvolvimento;
A especificação de requisitos diz o que o software faz sem entrar em detalhes técnicos e, por isso, deve usar a linguagem do negócio do cliente e não a de T.I.;
Outros documentos mais técnicos precisarão ser criados sem que haja contaminação da especificação de requisitos com tecnicismos que impeçam sua compreensão por parte do cliente;
Um contrato verbal somente funciona se as partes tem um alto nível de confiança entre si e se o objeto do contrato é simples; em qualquer outra situação, é preciso documentar o que se pretende produzir para evitar problemas futuros;
A especificação de requisitos não precisa estar detalhada em excesso ou não será possível concluí-la.
Requisitos de Sistemas – Luciana A. Teixeira
7
Qual o nível de detalhamento da Especificação de Requisitos?
Menor detalhamento
Maior detalhamento
Equipe de desenvolvimento interna
Equipe de desenvolvimento externa
Equipe agrupada
Equipe dispersa
Exigência de estimativas menos precisas
Exigência de estimativas mais precisas
Alto envolvimento dos clientes
Baixo envolvimento dos clientes
Alto conhecimento da equipe do negócio
Baixo conhecimento da equipe do negócio
Sistemas anteriores existentes
Sem sistemas anteriores existentes
Uso de pacotes na solução
Sem uso de pacotes na solução
Baixa rotatividade de pessoal
Alta rotatividade de pessoal
Requisitos de Sistemas – Luciana A. Teixeira
8
Requisitos Funcionais
Descrevem o que a solução deve fazer em termos de tarefas ou serviços do usuário;
Não devem abordar a implementação; portanto, não há preocupação com a linguagem a ser utilizada ou com trechos da programação, por exemplo;
Servem de base para outros modelos que integram a documentação do sistema, como o diagrama de casos de uso.
Exemplos de requisitos funcionais:
Efetuar gestão de cursos;
Emitir certificado de participação do aluno em um curso;
Somente alunos com frequência ≥ 75% podem emitir seu certificado;
Mas esses requisitos parecem ser de tipos diferentes...
Requisito do Usuário
Requisitos de Sistemas – Luciana A. Teixeira
9
Requisitos Funcionais e seus níveis de granularidade
O nível de granularidade é a maior ou menor abrangência na descrição do comportamento esperado para o software em uma especificação funcional;
Requisitos 
Funcionais
Requisitos de Sistemas – Luciana A. Teixeira
10
Requisitos Funcionais com objetivos AGREGADORES
São RF’s com objetivos mais gerais e com foco em processos de negócio de alto nível;
Resumem um conjunto de tarefas do usuário;
Exemplos:
Controlar contas a pagar;
Manter gestão dos cursos;
Gerenciar o aluguel de veículos;
Administrar relacionamento com clientes.
Os requisitos agregadores estão num nível de abstração que demanda refinamento para que possam ser transformados em funcionalidades do sistema a ser construído.
Alguns RF agregadores possuem um comportamento padronizado e, por isso, dispensam o refinamento; como os RF’s relacionados à manutenção de cadastros.
Quantas tarefas serão necessárias para que se alcancem esses objetivos?
Requisitos de Sistemas – Luciana A. Teixeira
11
Requisitos de Negócio x Requisitos Agregadores
Um requisito de negócio é a razão que motiva o cliente a solicitar um sistema e, portanto, pertence ao domínio do problema;
Um requisito agregador é a forma de resolver o problema que se apresenta como requisito de negócio e, portanto, está no domínio da solução.
Exemplo:
RN: Diminuir o risco operacional com serviços contratados mas não formalizados.
RFA: Controlar ativos.
Requisitos de Sistemas – Luciana A. Teixeira
12
Requisitos Funcionais com objetivo de SUBFUNÇÃO
São fragmentos de requisitos que não atendem sozinhos aos objetivos dos usuários, mas que ajudam a defini-los;
São denominados passos ou regras e estão em um nível inferior ao dos objetivos dos usuários;
Os passos descrevem a troca de dados em ambas as direções entre os usuários e o software, e entre o software e os requisitos de armazenamento;
As regras descrevem “leis” que regem o negócio e descrevem de forma complementar o funcionamento de seus processos. Costumam ser chamadas de regras de negócio;
As regras de negócio descrevem políticas corporativas, legislação pertinente, regulamentações governamentais e padrões de mercado aos quais o software em desenvolvimento deverá se subordinar;
As regras de negócio não estão ligadas à solução, mas ao domínio do problema em que se inserem.
Requisitos de Sistemas – Luciana A. Teixeira
13
Requisitos Funcionais com objetivo de SUBFUNÇÃO
Exemplo de um conjunto de passos:
Autenticação de cliente em um serviço de autoatendimento pararealização de transações bancárias 
Verificar se o cartão existe, se está vigente e não está bloqueado;
Verificar se a operação desejada é compatível com o tipo de cartão;
Verificar se a senha informada está correta;
Incrementar erros de senha se a senha informada estiver incorreta;
Zerar erros de senha caso a senha informada seja correta.
Exemplo de regras de negócio:
Somente alunos com frequência igual ou superior a 75% podem emitir seu certificado;
Para serem correntistas, os clientes precisam ter, no mínimo, 18 anos;
Só é possível parcelar compras a partir de R$ 500;
Crianças de até 24 meses transportadas no colo do responsável não pagam passagem;
É possível incluir até duas pessoas como dependentes.
Requisitos de Sistemas – Luciana A. Teixeira
14
Requisitos Não Funcionais
É uma “não funcionalidade”, ou seja, trata-se de algo que não é uma funcionalidade, mas que precisa ser realizado para que o software atenda ao seu propósito;
Normalmente não é declarado pelo cliente, mas é esperado por ele no sistema;
Descrevem como a solução deve se comportar enquanto realiza as tarefas do usuário;
Estabelecem os níveis de serviço esperados para o sistema;
Existem em quantidade muito menor no sistema, mas tem uma enorme amplitude. Uma definição a respeito de usabilidade, por exemplo, impactará todas as interfaces do software;
São também conhecidos como requisitos de qualidade, que impõem restrições sobre o projeto ou execução.
Exemplos de RNF’s:
O sistema de e-commerce precisa estar disponível 24x7.
É necessária a autenticação do usuário para realização de compras.
Os pagamentos com cartão serão realizados via módulo do PagSeguro.
Requisitos de Sistemas – Luciana A. Teixeira
15
Requisitos Não Funcionais e Restrição Técnica
A restrição técnica é uma limitação imposta externamente às possíveis soluções e não pode ser alterada;
O requisito não funcional é uma escolha e surge quando se opta por uma solução em particular;
O RNF pode ser alterado; a RT, não. A RT induz ao RNF.
Exemplos:
Cenário 1
RT: O sistema deve ser Web (Uma aplicação Windows, por exemplo, está descartada)
RNF: O navegador suportado será o MS Edge (As opções de usar o Chrome ou o IE também seriam válidas, mas não foram as escolhidas)
Cenário 2
RT: O navegador a ser suportado é o Chrome (Qualquer outro navegador está descartado)
RNF: O navegador suportado será o Chrome a partir da versão XYZ.
Requisitos de Sistemas – Luciana A. Teixeira
16
Requisitos Não Funcionais e seus tipos
Os RNF’s são separados em categorias, conforme o seu propósito. As principais são:
Desempenho – restrições relacionadas a tempo de resposta etc;
Disponibilidade – definição do tempo em que é necessário poder dispor do sistema etc;
Segurança – diretrizes relacionadas à segurança, como criptografia, por exemplo;
Interoperabilidade – necessidade de integração do software com sistemas externos;
Usabilidade – instruções ligadas ao projeto de interfaces que compõem o sistema;
Compatibilidade – especificidades relacionadas aos programas necessários à execução do sistema em construção;
Confiabilidade – política de backup, MTBF, recursos para restauração automática etc.;
Padrões – metodologia de desenvolvimento do sistema, padrões de projeto etc.;
Legais – exigências de conformidade do software com alguma legislação pertinente.
Requisitos de Sistemas – Luciana A. Teixeira
17
Requisitos Não Funcionais e seus tipos
Exemplos de RNF’s:
O sistema de e-commerce precisa estar disponível 24x7.
É necessária a autenticação do usuário para realização de compras.
Os pagamentos com cartão serão realizados via módulo do PagSeguro.
DISPONIBILIDADE
SEGURANÇA
INTEROPERABILIDADE
Requisitos de Sistemas – Luciana A. Teixeira
18
Classifique os itens conforme a numeração a seguir:
RF. Requisito Funcional | RNF. Requisito Não Funcional | RN. Regra de Negócio
( )
O coordenador pode abrir turmas para uma disciplina, bem como definir um espaço físico e um horário para as aulas.
( )
O professor somente pode visualizar o e-mail de alunos matriculados em suas turmas.
( )
É preciso garantir que o acesso ao sistema seja concedido somente a usuários cadastrados.
( )
O aluno deve ter sua matrícula cancelada se obtiver dois conceitos D ao longo do curso.
( )
A Tesouraria pode emitir relatório de alunos inadimplentes num determinado período.
( )
O app de matrícula deverá ser responsivo.
( )
O aluno pode visualizar seu histórico escolar.
( )
Alunos inadimplentes não podem pegar livros emprestados na biblioteca.
( )
No período de renovação de matrícula, o sistema não poderá sair do ar.
Requisitos de Sistemas – Luciana A. Teixeira
19
Rastreabilidade de requisitos
A rastreabilidade de requisitos é uma característica de sistemas nos quais os requisitos são ligadas às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do sistema baseado nesses requisitos;
Ela estabelece um elo entre mudanças nas necessidades dos usuários e a evolução dos sistemas de computação, servindo de base para o gerenciamento organizacional;
A rastreabilidade pode ser vista como a habilidade de acompanhar e descrever a vida de um requisito, em ambas as direções: 
a pré-rastreabilidade documenta o contexto a partir do qual surgem os requisitos; 
a pós-rastreabilidade vincula os requisitos ao desenho do sistema e sua implementação.
Requisitos de Sistemas – Luciana A. Teixeira
20
Rastreabilidade de requisitos
Na pré-rastreabilidade, a rastreabilidade “para frente” (forward-to) liga os requisitos relevantes aos documentos obtidos no processo de elicitação; a rastreabilidade “para trás” (backward from) liga os requisitos à sua fonte;
Na pós-rastreabilidade, a rastreabilidade “para frente” (forward-to) liga os requisitos aos artefatos de desenho e implementação; a rastreabilidade “para trás” (backward from) liga os artefatos de desenho e implementação de volta aos requisitos.
Plano de Negócios 
e outros documentos
Documento 
de Requisitos
Artefatos de Desenho e Implementação
Pré-rastreabilidade
Pós-rastreabilidade
Requisitos de Sistemas – Luciana A. Teixeira
21
Etapas da Engenharia de Requisitos
Estudo da Viabilidade
Elicitação e Análise de Requisitos
Relatório de Viabilidade
Especificação de Requisitos
Modelos do Sistema
Validação de Requisitos
Requisitos do Usuário e do Sistema
Documento de Requisitos
Requisitos de Sistemas – Luciana A. Teixeira
22
Estudo da viabilidade
Estudo inicial com foco somente na definição a respeito da viabilidade do sistema para a organização;
Base da análise: Esboço da descrição do sistema e um conjunto inicial de requisitos de negócio. Resultado da análise: relatório que recomenda se vale a pena ou não construir o sistema;
O relatório pode propor mudanças de escopo, orçamento e prazo a fim de viabilizar o sistema;
Normalmente dura de uma a três semanas e tem como fonte de informação os stakeholders do sistema;
Dentre as questões a serem respondidas neste estudo estão: 
Como o sistema contribui para os objetivos da organização? 
O sistema pode ser implementado com a tecnologia atual, com o custo previsto e no prazo determinado? 
O sistema pode ser integrado a outros sistemas já implantados?
Requisitos de Sistemas – Luciana A. Teixeira
23
Elicitação e Análise de Requisitos
Esta etapa engloba quatro momentos: 
Obtenção dos requisitos;
Classificação e organização;
Priorização e negociação;
Documentação dos requisitos; 
A forma como essas atividades são executadas depende do processo de desenvolvimento de software utilizado;
Algumas dificuldades podem ser encontradas:
Requisitos conflitantes;
Fatores políticos;
Conhecimento implícito ou tácito; 
Comunicação com os interessados;
O ambiente econômico e de negócios mutável.
“Conhecimento tácito é aquele que o indivíduo adquiriu ao longo da vida, que está na cabeça das pessoas. Geralmente é difícil de ser formalizado ou explicado a outra pessoa, pois é subjetivoe inerente as habilidades de uma pessoa, como know-how". 
Fonte: https://imasters.com.br/artigo/3599/gerencia/conhecimento_tacito_e_explicito/
Requisitos de Sistemas – Luciana A. Teixeira
24
Técnicas para elicitação de requisitos
Entrevistas 
Questionários 
Casos de uso 
Cenários/histórias 
Observações in loco 
Documentos, leis, etc.
FASES DA ELICITAÇÃO DE REQUISITOS
Requisitos de Sistemas – Luciana A. Teixeira
25
Validação dos requisitos
A validação tem o objetivo de mostrar que os requisitos realmente definem o sistema que o usuário deseja que seja construído;
As técnicas de validação aplicadas são: revisões, prototipação, de casos de teste;
A validação dos requisitos ajuda na identificação da necessidade de criação de novas funções e/ou de readequação de funções já definidas;
Muitos problemas podem ser detectados nesta fase:
Não seguimento das normas de qualidade do projeto e da empresa;
Descrição pouco clara dos requisitos;
Falhas na modelação dos requisitos;
Requisitos que não foram detectados;
Requisitos não realistas;
Falta de informação.
Requisitos de Sistemas – Luciana A. Teixeira
26
Validação dos requisitos – Revisão
A revisão de requisitos deverá ser feita numa reunião formal, com a presença de um usuário final, um especialista do domínio, um representante do cliente, os responsáveis pelo projeto do sistema e os analistas de requisitos;
Devem ser preparadas checklists de revisão que não deverão incidir sobre requisitos individuais, mas sim nas relações dos requisitos, assim como as propriedades de qualidade do documento
Os seguintes atributos de qualidade deverão ser tomados em conta na formulação da checklist:
compreensibilidade
redundância
completude
consistência
organização
rastreabilidade
conformidade com as normas
Fonte: https://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos
Requisitos de Sistemas – Luciana A. Teixeira
27
Validação dos requisitos – Prototipação
O protótipo ajuda os stakeholders a identificarem se aquilo que imaginam para o sistema equivale à proposta de solução da equipe do projeto;
Num protótipo visual, é mais fácil detectar inconsistências e problemas nos requisitos ou mesmo ausência deles no sistema proposto;
A partir do protótipo, existe a possibilidade de iniciar-se a redação dos manuais de utilização, já que estarão implementadas as interfaces com as quais os usuários irão interagir.
Fonte: https://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos
Requisitos de Sistemas – Luciana A. Teixeira
28
Validação dos requisitos – Casos de Teste
Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na íntegra;
Se não for possível definir um caso de teste, isso vai significar que o requisito necessita ser revisado; pois, muito provavelmente, ele criará problemas futuros;
Na definição de cada caso de teste, deverão ser considerados os seguintes pontos:
identificador do requisito
requisitos relacionados
descrição do teste
problemas na realização do teste
comentário e recomendações
Fonte: https://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos
Requisitos de Sistemas – Luciana A. Teixeira
29
Gerenciamento de requisitos
Os requisitos dos sistemas podem mudar ao longo do ciclo de vida e o gerenciamento de requisitos é o responsável pela gestão dessas mudanças;
As mudanças podem ocorrer: 
Durante o desenvolvimento: quando (i) há problemas complexos que não podem ser totalmente definidos ou (ii) o entendimento dos interessados sobre o problema muda;
Depois da implantação: quando surgem novos requisitos;
O gerenciamento classifica os requisitos como permanentes ou mutáveis.
Requisitos de Sistemas – Luciana A. Teixeira
30
Gerenciamento de requisitos – Requisitos Permanentes
Os requisitos permanentes são relativamente estáveis e derivados da atividade principal do negócio;
São exemplos deste tipo de requisito:
 Em um Hospital:
O sistema deverá manter um cadastro de seus médicos;
O sistema deverá permitir a atualização do prontuário do paciente pelo médico quando o mesmo realizar uma consulta.
 Em uma Universidade:
O sistema deverá permitir a matrícula de alunos aprovados no vestibular;
O sistema não deverá permitir a exclusão de dados relativos à atividade acadêmica dos alunos.
Requisitos de Sistemas – Luciana A. Teixeira
31