Engenharia de Sistemas e Requisitos

(1)

Betina Carol Zanchin

betinacarolz@hotmail.com

Max Mauro

maxsantos@utfpr.edu.br

(2)

1. Introdução

1.1. Motivação

1.2. Engenharia Sistemas 1.3. Modelo em V

1.4. Engenharia de Requisitos

2. Análise Requisitos

2.1. Estudo Viabilidades 2.2. Identificação Requisitos 2.3. Análise e Negociação

2.4. Especificação e Documentação 2.5. Validação

3. Conclusão 4. Referências

Sumário

(3)

 A importância da engenharia de requisitos

http://www.devmedia.com.br/engenharia-de-requisitos-introducao-e-certificacao/28058

(4)

 De acordo com a INCOSE (International Council on Systems Engineering);

"a Engenharia de Sistemas é uma abordagem interdisciplinar que torna possível a concretização de 'Sistemas' de elevada complexidade. O seu foco encontra-se em definir, de maneira precoce no ciclo de desenvolvimento de um sistema, as necessidades do usuário, bem como as funcionalidades requeridas, realizando a documentação sistemática dos requisitos, e abordando a síntese de projeto e a etapa de validação de forma a considerar o problema completo".

1.2. Engenharia Sistemas

(5)

Modelo V

 É um modelo conceitual de Engenharia de Sistemas, adotado como conceito padrão após 1980.

 Ele permite que, durante a integração de um sistema em seus diversos níveis, os testes sejam feitos contra os próprios requisitos do sistema que está sendo testado.

 Em modelos anteriores o sistema era testado contra a especificação do sistema.

 Notar a diferença entre requisito e especificação.

 Requisito: condição para se alcançar determinado fim.

 Especificação: descrição minuciosa das características

(6)

 Podemos perceber que temos dois lados do modelo:

 um é especifico para verificação, onde vamos testar tudo que se é estático;

 e do outro lado a validação, onde executamos o programa em si, e os testes já não são mais estáticos;

1.3. Modelo V

(7)

1.3. Modelo V

(8)

1.3. Modelo V

(9)

(10)

1.3. Modelo V

(11)

(12)

1.3. Modelo V

(13)

(14)

1.3. Modelo V

(15)

(16)

1.3. Modelo V

(17)

(18)

Vantagens do Modelo V

 Os testes têm resultados de maior efetividade, uma vez que são testados contra requisitos e não contra especificações;

 Este modelo possibilita que se encontre erros durante os processos de se derivar especificações de requisitos;

 Ajuda a desenvolver novos requisitos;

 Melhora a qualidade do produto resultante, uma vez que valida o processo de engenharia de sistemas durante a integração do sistema.

1.3. Modelo V

(19)

Desvantagens do Modelo V

 Não considera o paralelismo que geralmente ocorre em projetos de maior complexidade;

 Não considera as diversas dimensões do projeto;

 Há ciclos de revisão em etapas tardias do processo, quando se encontra erros, sua correção pode ser cara.

(20)

O que é Engenharia de Requisitos

 É um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos.

 Requisitos são condições ou capacidades que o usuário necessita, para solucionar um problema ou alcançar os objetivos do sistema.

 Em um processo de engenharia de requisitos há basicamente quatro atividades a serem cumpridas;

 Estudo de Viabilidades;

 Identificação de requisitos;

 Análise e Negociação;

 Especificação e Documentação;

 Validação;

1.4. Engenharia de Requisitos

(21)

Análise de Requisitos

 A análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas.

 É nesta fase do processo de desenvolvimento de novos projetos, que acontecem as primeiras reuniões com os clientes e/ou usuários para se conhecer as funcionalidades do sistema que será desenvolvido.

 É nesta fase também que ocorre a maior parte dos erros, pois a falta de clareza e inconsistências na obtenção dos requisitos fazem com que todo o processo seguinte da análise seja conflitante, ocasionando um possível mal funcionamento no sistema projetado.

(22)

Etapa: Estudo de Viabilidades

 É a primeira fase da análise de requisitos.

 Deve ser realizado sempre que um novo projeto esteja em fase de avaliação.

 Nesta etapa busca-se determinar se o projeto em questão é viável ou não, através das restrições de projeto.

 As seguintes indagações devem ser feitas:

 Dadas as restrições tecnológicas, o sistema pode ser implementado?

 Caso haja a necessidade de integração entre diferentes sistemas, será que esta é possível?

2.1. Estudo de Viabilidades

(23)

Etapa: Identificação de Requisitos

 Em todos os processos, a identificação de requisitos é o ponto de partida, saber o que deve se produzir.

 É a etapa onde se identifica os requisitos e monta-se a matriz de requisitos, que será a matéria prima para a definição do escopo do projeto.

 Um bom levantamento de requisitos se inicia sempre pela seleção das melhores fontes de informação, os chamados stakeholders.

 Frequentemente os requisitos são completados em conjunto com o desenvolvimento do sistema, ou seja, requisitos evoluem, são redefinidos, refinados ou reorganizados.

(24)

 Primeiramente os requisitos são obtidos informalmente por texto estruturado. Após passam mais formalmente para diagramas, e por fim passam para itens.

 Requisitos devem ter clareza, plenitude, evitar ambiguidades , inconsistências e redundâncias.

 Na definição para cada requisito é sempre útil perguntar questões relacionadas a:

 Possíveis condições de erros;

 Casos especiais, exceções que se apliquem ao requisito;

 O que acontece quando uma ou mais condições do requisito, não são verificadas.

2.2 Identificação de Requisitos

(25)

Abordagem

 Abordagem proposta para a dissertação dos requisitos:

 Devem ser únicos e identificáveis (detalhados por labels).

 Devem ser testáveis ou verificáveis (um caso teste para cada requisito).

 Devem ser breves e claros, e utilizar desses verbos:

 shall – requisito obrigatório;

 must – suposição;

 will – comportamento garantido;

 should – característica desejável, não obrigatória;

 Requisitos negativos não devem ser escritos, pois dificultam o entendimento (usados em requisitos de segurança).

(26)

(27)

Entrevistas Vantagens

1) Com um plano geral bem elaborado, o analista terá facilidade em descobrir que informação o usuário está mais interessado e usar um estilo adequado ao entrevistar;

2) Poder alterar o curso da entrevista de forma a obter informações sobre aspectos importantes que não tinham sido previstos no planejamento da entrevista;

3) Poder alterar a ordem sequencial das perguntas;

4) Poder eliminar perguntas anteriormente planejadas;

5) Poder incluir perguntas que não estavam na programação da entrevista;

6) Poder motivar o entrevistado no decorrer do processo;

(28)

Entrevistas Desvantagens

1) Podem ocorrer desvios de curso, no decorrer da entrevista;

2) Consumir mais tempo e recursos com sua realização;

3) Tratamento diferenciado para os entrevistados;

4) É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados;

5) O usuário tem dificuldade de concentração em reuniões muito longas;

6) O entrevistado pode não saber expressar corretamente suas necessidades ao analista.

(29)

Questionários

 Diferente da entrevista, essa técnica é interessante quando temos uma quantidade grande de pessoas para extrair as mesma informações.

Vantagens

1) Atinge um grande número de pessoas;

2) Menores custos;

3) Permite que os participantes respondam no momento em que acharem conveniente;

4) Questões padronizadas garantem uniformidade.

(30)

Questionários Desvantagens

1) Não há garantia de que a maioria dos participantes respondam o questionário;

2) Os resultados são bastante críticos em relação ao objetivo, pois as perguntas podem ter significados diferentes a cada participante questionado.

(31)

Workshops

 Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada.

Vantagens

1) Obtêm um conjunto de requisitos bem definido;

2) Trabalho em equipe tornando o levantamento de requisitos mais eficaz;

3) Baixo custo e resposta relativamente rápida;

4) Tempo de obtenção de informações é reduzido.

(32)

Workshops Desvantagens

1) Por ser realizado por convocação com dia e horários marcados, pode ocasionar problemas no presenciais dos stakeholders;

2) Não abre caminho para ideias externas além da equipe de analistas;

3) Dados excessivamente agregados.

(33)

BrainStorming

 Seu objetivo é uma apresentação do problema/necessidade a um grupo específico, requerendo assim soluções.

Vantagens

1) Várias pessoas pensam melhor do que uma (grupo pensante);

2) Rompe a inibição de ideias;

3) Generaliza a participação do membros do grupo.

Desvantagens

1) Disponibilidade de todos pode inviabilizar o levantamento de dados.

(34)

Prototipagem

 É muito utilizado quando os stakeholders são incapazes de expressar os seus requisitos ou se os mesmos não têm nenhuma experiência com o sistema.

Vantagens

1) Permite alcançar um feedback antecipado dos stakeholders;

2) Redução de tempo e custo de desenvolvimento devido a detecção dos erros em uma fase inicial do projeto;

3) Prove alto nível de satisfação dos usuários devido a sensação de segurança ao ver algo próximo do real;

(35)

Prototipagem

Desvantagens

1) Demanda um alto custo de investimento, em relação à outros métodos, para ser realizado;

2) Demanda um tempo maior para sua realização devido a complexidade do sistema e a limitações técnicas;

(36)

Cenários (Storyboards)

 São sessões interativas, que descrevem uma sequência de atividades e eventos, para um caso em específico.

Vantagens

1) Método muito eficiente no esclarecimento de requisitos relacionados a processos, fluxos de dados e tarefas;

2) Método relativamente barato de ser executado;

(37)

Exemplo de modelo controlado por controlador

S = Especificação.

F = Descrição da funcionalidade do sistema do controlador de realização.

C = Conjunto de restrições.

P = Planta.

CF = Partição, comportamento do sistema e restrições.

CI = Características da implementação.

A = Características.

S={ F, C, P, A } C={ CF, CI}

(38)

Dicionário de Dados

 O dicionário de dados é um repositório que contém a descrição de todos os objetos de dados alimentados ou produzidos pelo projeto.

 Deve se obter sem ambiguidades, nome e definição de parâmetros, entradas e saídas.

 Nomes no dicionário de dados não se referem a variáveis do projeto, mas sim a entidades funcionais, não refere-se a tipos concretos, mas sim a tipos abstratos (real, inteiro...)

(39)

 Exemplo de um dicionário de dados para entradas e saídas.

 Exemplo de um dicionário de dados para parâmetros. (um pouco diferente do DD de entradas/saídas).

(40)

Análise e Negociação dos Requisitos

 As principais atividades da etapa de análise e negociação de requisitos são:

 classificação: agrupamento de requisitos para facilitar a visão global do funcionamento pretendido do sistema;

 resolução de conflitos: é inevitável a existência de conflitos nos requisitos identificados, dada a diversidade de papéis envolvidos na captura e análise de requisitos, portanto é primordial a resolução dos conflitos encontrados o mais breve possível;

 priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa);

 confirmação: é a etapa onde se confirmam os requisitos encontrados, sua consistência e validade (de acordo com o que se pretende do sistema).

 A identificação e análise de requisitos são processos que evoluem em conjunto com a evolução do projeto, ou seja podem mudar.

2.3. Análise e Negociação dos Requisitos

(41)

Especificações e Documentos

 É a etapa onde se é produzido o documento de especificações de requisitos.

 Documentos de requisitos são produzidos frequentemente depois de o sistema ser desenvolvido e ainda mais frequente são escritos pelos próprios desenvolvedores documentando o que o sistema faz.

 Existem diversos padrões para este documento, embora não se possa apontar nenhum como o "ideal". Uma estrutura proposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-1993.

(42)

Classificação de Requisitos Requisitos Funcionais:

 Traduz os serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas, e até mesmo o que o sistema não deve fazer.

 Requisitos de usuário e requisitos de sistema, são subcategorias dentro dos requisitos funcionais

 A especificação de requisitos funcionais deve ser completa, ou seja, todos os requisitos desejados pelo usuário devem ser satisfeitos,

 Deve ser consistente, ou seja, não deve haver definições contraditórias

 Em resumo um requisitos funcionais descrevem o que o sistema faz

2.3. Análise e Negociação dos Requisitos

(43)

 Requisitos do Usuário:

 Linguagem natural, formulários e diagramas muito simples;

 Evitar usar termos demasiado técnicos;

 Distinguir claramente entre comportamentos esperados e desejáveis do sistema;

 Requisitos do Sistema:

 Têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador;

 Destinam-se ainda aos usuários do sistema, e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento.

(44)

Exemplo:

2.4. Especificações e Documentos

(45)

Requisitos Não Funcionais

 São as restrições sob as quais o sistema deve operar, podendo se dividir em várias categorias.

 Referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar.

 Costumam ser divididos em subcategorias, requisitos de produto, requisitos organizacionais e requisitos externos, que por sua vez também possuem subcategorias.

(46)

Exemplo:

(47)

(48)

Requisitos de Produto:

 Especificam o comportamento particular do sistema, com relação a eficiência, confiabilidade, portabilidade e facilidade de uso;

 Exemplo: “[RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s”;

Requisitos Organizacionais:

 Consequência de políticas e procedimentos organizacionais, requisitos de implementação, requisitos de entrega e requisitos de padrões;

 Exemplo: “[RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00”;

(49)

Requisitos Externos:

 Consequência de fatores externos ao sistema e ao processo de desenvolvimento, requisitos de interoperabilidade, requisitos legais, de segurança e privacidade, e requisitos éticos;

 Exemplo: “[RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema”;

(50)

Medidas

(51)

Matriz de Rastreabilidade

 Após a determinação de todos os requisitos, e da devida análise, se inicia uma importante etapa que é a confecção da matriz de rastreabilidade.

 A matriz de rastreabilidade surge como uma ferramenta para facilitar a visualização dos relacionamento entre requisitos e outros artefatos ou objetos.

 Sem uma matriz de rastreabilidade, você pode não perceber todo o impacto que uma possível alteração de requisitos possa causar no seu sistema, e acabar tomando decisões equivocadas por não poder realizar uma análise de impacto completa e confiável.

 Com a matriz, facilmente conseguimos identificar quantos e quais requisitos são afetados por qualquer alteração no sistema, e assim tornamos nossa avaliação de impacto muito mais eficaz.

(52)

Exemplos:

(53)

Formatação Básica de um Documento de Especificação de Requisitos:

1 Introdução

1.1 Propósito do documento de requisitos

• Especificar objetivos e público-alvo do DR.

1.2 Escopo do produto

• Explicitar o que o produto faz (e o que não faz).

• Descrever a aplicação (pontos relevantes, objetivos e metas).

1.3 Definições, acrônimos e abreviações 1.4 Referências

• Listar todos os documentos referenciados.

• Identificar cada documento por título, número, data, autor, ...

• Especificar a fonte a partir da qual o documento pode ser obtido.

1.5 Visão geral do documento de requisitos

• Descrever a estrutura/organização do restante do DR.

(54)

2 Descrição Geral

2.1 Perspectiva do Produto

• Descrever os relacionamentos do produto com: sistema, usuário, hardware, software, comunicação, etc.

2.2 Funções do Produto

• Resumo das principais funções que o produto de software irá realizar.

2.3 Características do Usuário

• Descrever as características gerais dos usuários do produto.

2.4 Restrições

• Descrever quais itens podem limitar as possibilidades do desenvolvedor.

2.5 Suposições e Dependências

• Listar os fatores que possam afetar os requisitos estabelecidos.

(55)

3 Requisitos Específicos

3.1 Interfaces Externas

• Descrever detalhadamente todas as entradas e saídas do sistema.

• Complementar as descrições das interfaces apresentadas na seção 2 do documento.

3.2 Requisitos Funcionais

• Descrever as principais ações que devem ser consideradas no produto de software.

3.3 Requisitos de Desempenho

• Descrever os requisitos numéricos que o sistema deve atender.

3.4 Requisitos Lógicos de Banco de Dados

• Descrever os requisitos para qualquer informação a ser colocada na base de dados.

(56)

3.5 Restrições de Projeto

• Descrever restrições de projeto impostas por outros padrões, limitações de hardware, etc.

3.6 Atributos do Sistema de Software

• Descrever atributos do produto (características de qualidade) de maneira que possam ser objetivamente verificados.

3.7 Organização

• Para a maioria dos sistemas a especificação detalhada dos requisitos tende a ser grande.

• Organizar os requisitos funcionais de maneira a otimizar o entendimento.

4 Informações de Apoio 4.1 Índice.

4.2 Apêndices.

(57)

Validação

 Nesta fase busca-se mostrar que o documento de requisitos produzido corresponde de fato ao sistema modelado.

 É necessário checar vários itens do documento criado para que se possa garantir o correto funcionamento do sistema.

 Itens como por exemplo: consistência, compreensibilidade, realismo, completude, rastreabilidade e conformidade com normas.

 Há técnicas variadas para se fazer esta checagem, são as chamadas técnicas de validação.

 Revisão dos requisitos (verificação de validade);

 Prototipação (implementação de um protótipo);

 Geração de casos testes;

(58)

Conclusão

 O objeto de pesquisa foi centrado no conhecimento dos fundamentos conceituais da Engenharia de Requisitos onde a terminologia e a aplicabilidade compõem uma primeira fase de estudo sobre o tema.

 É possível perceber portanto a importância da engenharia de sistemas e de requisitos na atualidade, onde temos processos de desenvolvimento de projetos mais complexos a cada dia, e que necessitam de um alto nível de competência para serem executados.

 A engenharia de requisitos visa facilitar, aprimorar, e organizar os processos de desenvolvimento de novos projetos, tornando-os mais confiáveis.

3. Conclusão

(59)

 Ariane 5 é um sistema de lançamento dispensável Europeia projetado para entregar cargas úteis em órbita de transferência geoestacionária ou baixa órbita da Terra.

 Seu desenvolvimento levou 10 anos e custou US $ 7 bilhões.

 O primeiro voo teste de Ariane 5, em 4 de junho de 1996 falhou. Com o foguete se autodestruindo 37 segundos após o lançamento, por causa de uma avaria no software de controle, que foi sem dúvida um dos bugs de computador mais caros da história.

(60)

 O software de Ariane 5 reutilizou as especificações do Ariane 4, mas trajetória de voo do Ariane 5 foi consideravelmente diferente do Ariane 4.

 A maior aceleração de Ariane 5 ocasionou falha nos computadores de orientação primários e de reserva.

 Testes pré-voo não foram realizados no código de Ariane 5 em condições de voo simulado, assim o erro não foi descoberto antes do lançamento.

3. Conclusão

(61)

FALBO R.A. Engenharia de Requisitos - Notas de Aula. disponível em

http://www.inf.ufes.br/~falbo/files/Notas_Aula_Engenharia_Requisitos.pdf acesso em novembro de 2015.

KOWALEWSKI S. Embedded Software Engineering Part 2: Requirements Basics.

disponível em https://www.embedded.rwth-

aachen.de/lib/exe/fetch.php?media=lehre:sose05:2_20050426_reqsbasics.pdf acesso em novembro de 2015.

LOPES L.T. Um Modelo de Processo de Engenharia de Requisitos para Ambientes de Desenvolvimento Distribuído de Software. disponível em

http://www.inf.pucrs.br/munddos/docs/DisseLTLopes.pdf acesso em novembro de 2015.

NATALE M. Requirements Analysis. disponível em http://retis.sssup.it/~marco/files/lesson1- requirements_analysis.pdf acesso em novembro de 2015.

NATALE M. Introduction to Testing. disponível em http://retis.sssup.it/~marco/files/lesson2- introduction_to_testing acesso em novembro de 2015.

(62)

NATALE M. Functional Testing. disponível em http://retis.sssup.it/~marco/files/lesson3- functional_testing acesso em novembro de 2015.

RAMOS R.A. Introdução a Engenharia de Requisitos. disponível em

http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula08.pdf acesso em novembro de 2015.

SILVA V.T. Princípios de Engenharia de Requisitos. disponível em

http://www2.ic.uff.br/~viviane.silva/2012.1/es1/util/aula5.pdf acesso em novembro de 2015.

IEEE Recommended Practice for Software Requirements Specifications. disponível em http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf acesso em novembro de 2015.

Modelo V e a Qualidade de Software. disponível em

http://www.iterasys.com.br/downloads/Iterasys%20-%20WSI%20-

%20Modelo%20V%20e%20a%20Qualidade%20de%20Software.pdf acesso em novembro de 2015.

Referências

(63)

maxsantos@utfpr.edu.br