Processos da Engenharia de Requisitos do Software

Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 1 ENGENHARIA DE SOFTWARE CAPÍTULO 3 PROCESSOS DA ENGENHARIA DE REQUISITOS DO SOFTWARE r04 Sumário 31 Conceito de processo da engenharia de requisitos de software 32 Processo da Engenharia de Requisitos do software 321 O documento de requisitos de software 33 Estudo da Viabilidade do sistema 34 Elicitação e Análise de requisitos 341 Elicitação 342 Levantamento e Análise de Requisitos 35 Especificação Documentação e Modelagem dos requisitos 351Requisitos do Usuário RU 352 Requisitos Funcionais RF 353 Requisitos Não Funcionais RNF 354 Requisitos do Sistema RS 36 Validação 31 CONCEITO DE PROCESSO DA ENGENHARIA DE REQUISITOS DO SOFTWARE Entender os requisitos de um problema está entre as tarefas mais difíceis enfrentadas por um engenheiro de software Quando se começa a pensar sobre isso a engenharia de requisitos não parece tão difícil Afinal de contas o cliente não sabe o que é necessário Os usuários finais não deveriam ter um bom entendimento das características e funções que vão oferecer benefícios E mesmo que clientes e usuários finais sejam explícitos quanto às necessidades essas vão se modificar ao longo do projeto PRESSMAN 2007 32 PROCESSO DA ENGENHARIA DE REQUISITOS DO SOFTWARE Sommerville 2003 declara A Engenharia de Requisitos do Software é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos do softwaresistema O documento de requisitos de software pode ser usado em contratos e licitações para o desenvolvimento de software escolha de fornecedores de componentes do sistema acompanhamento de mudanças e especificação do software Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 2 321 O documento de requisitos de software A Especificação de Requisitos de Software SRS Software Requirements Specification captura todos os requisitos de software para o sistema ou para uma parte do sistema É a declaração oficial do que é exigido dos desenvolvedores de sistema Ele deve incluir os requisitos de usuário para um sistema e uma especificação detalhada dos requisitos de sistema abrangendo desde a alta gerência da organização até os analistas responsáveis pelo desenvolvimento Pressman 2011 sugere o Modelo de especificação de requisitos de software descrito abaixo Sumário Histórico de revisão 1 Introdução 11 Propósito 12 Convenções do documento 13 Públicoalvo e sugestões de leitura 14 Escopo do projeto 2 Descrição geral 21 Perspectiva do produto 22 Características do Produto 23 Classes de usuários e características 24 Ambiente operacional 25 Restrições de projeto e implementação 26 Documentação para usuários 27 Hipóteses e dependências 3 Características do sistema 31 Características do sistema 1 32 Características do sistema 2 e assim por diante 4 Requisitos de interfaces externas 41 Interfaces do usuário 42 Interfaces de hardware 43 Interfaces de software 44 Interfaces de comunicação 5 Outros requisitos não funcionais 51 Necessidades de desempenho 52 Necessidades de proteção 53 Necessidades de segurança 54 Atributos de qualidade de software 6 Outros requisitos 7 Resultados a serem obtidos Referências Glossário Apêndice A Modelos de análise Apêndice B Lista de problemas As principais atividades do Processo da Engenharia de Requisitos do softwaresistema são Estudo da Viabilidade do sistema Elicitação Análise Especificação Modelagem Validação Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 3 A Figura abaixo mostra o fluxo de atividades do processo da engenharia de requisitos do softwaresistema Observe que o desenvolvimento do processo de engenharia de requisitos só ocorre após a validação dos requisitos caso os requisitos não sejam validados ocorre uma iteração o que significa que todo o processo será revisado incluindo abordagens para o levantamento dos requisitos Figura Modelo do processo da engenharia de requisitos do softwaresistema Estudo da Viabilidade do sistema Especificação Modelagem e Documentação Elicitação e Análise de requisitos Validação Nova Iteração Início Desenvolvimento do Sistema Fonte MORENO 2020 Sommerville 2011 define que as atividades do Processo da Engenharia de Requisitos do softwaresistema podem ser decompostas em quatro níveis distintos de serviços NÍVEL 1 Estudo da viabilidade do sistema este estudo é de grande importância pois garante que as necessidades do cliente para implementação do sistema estão de acordo com os interesses organizacionais e que os recursos necessários estejam disponíveis para o desenvolvimento ou integração do novo softwaresistema Um estudo de viabilidade deve ser relativamente barato e rápido O resultado deve informar a decisão de avançar ou não com uma análise mais detalhada SOMMERVILLE 2011 NÍVEL 2 Elicitação e análise de requisitos nesta fase são feitas várias reuniões entre cliente e desenvolvedor com objetivo de extrair com detalhes o conhecimento do negócio para que se destine o softwaresistema NÍVEL 3 Especificação modelagem e documentação dos requisitos após a interpretação e entendimento dos detalhes do negócio iniciase a preparação do documento de requisitos que deve ser composta pelos vários requisitos discutidos em reunião Esta fase deve ser feita pelo desenvolvedor com acompanhamento do cliente São descritos textos breves interpretativos sobre cada requisito acompanhados sempre que necessário de um modelo visual e consequentemente à elaboração do documento de requisitos do softwaresistema NÍVEL 4 Validação de requisitos a validação é a apresentação do documento de requisitos em reunião com a participação do grupo formado pelos interessados no sistema O objetivo é aprimorar incluir mudanças propostas e aprovar o início do projeto e desenvolvimento do softwaresistema O documento a ser validado pode ser elaborado para um único sistema parte do sistema ou para cada funcionalidade do sistema Vale o bom senso a análise decisiva deve ter base no tamanho e complexidade do sistema ou da funcionalidade associada ao seu prazo e custo Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 4 33 ESTUDO DA VIABILIDADE DO SISTEMA Identificação concepção A maioria dos projetos começa quando uma necessidade de negócio é identificada ou um mercado ou serviço novo é descoberto Os desenvolvedores fazem uma série de perguntas com a intenção de estabelecer um entendimento básico do problema Deve haver uma colaboração entre cliente e desenvolvedor Para todos os sistemas novos e de acordo com a Figura abaixo o processo de engenharia de requisitos de sistema deve começar com o estudo de viabilidade antes mesmo da obtenção e a análise de requisitos A entrada para o estudo de viabilidade é uma descrição geral do sistema e de como ele será utilizado dentro de uma organização Os resultados do estudo de viabilidade devem ser um relatório que recomenda se vale ou não a pena realizar o processo de engenharia de requisitos e o processo de desenvolvimento de sistemas O estudo de viabilidade é um estudo breve direcionado que se destina a responder algumas perguntas 1 O Sistema proposto contribui para os objetivos gerais da organização No caso são considerados os aspectos culturais da organização a hierarquia de comando na tomada de decisão e o processo de negócio Neste aspecto são consideradas se as regras de negócio estão de acordo com a organização 2 O Sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo 3 O que o cliente quer está dentro do orçamento e prazo para entrega do sistema 4 O Sistema pode ser integrado com os outros sistemas já em operação Qual o impacto das mudanças no ambiente operacional do cliente 5 A tecnologia a ser implementada é adaptável ao sistema do cliente se este existir 34 ELICITAÇÃO E ANÁLISE DE REQUISITOS 341 Elicitação Elicitação dos requisitos é a tarefa de comunicarse com os usuários e clientes para determinar quais são os requisitos Na elicitação o analista deve ter habilidade e sutileza para extrair informações durante uma conversa Os analistas podem empregar várias técnicas para elicitar os requisitos dos clientes As técnicas mais utilizadas são Organizar reuniões entrevistas ou grupos focais workshops e consequentemente a criação da lista de requisitos O workshop de requisitos consiste na realização de reuniões estruturadas e delimitadas entre os analistas de requisitos do projeto e representantes do cliente Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 5 Prototipação e casos de uso onde o analista irá aplicar uma combinação de métodos para estabelecer os requisitos exatos de seus stakeholders qualquer pessoa que terá influência direta ou indireta sobre os requisitos do sistema de forma que um sistema que atenda as necessidades do negócio seja produzido O protótipo é recomendado para avaliar a interface do usuário os problemas de comunicação com outros produtos e a possibilidade de atendimento aos requisitos de desempenho Métodos mais utilizados para elicitar requisitos são Questionários dirigidos Perguntas abertas e Brainstorming Grupos de desenvolvimento de sistemas do tipo JAD Joint Application Design Projeto de Aplicação Conjunta O JAD é uma técnica de captura de requisitos baseada em reuniões As técnicas JAD aplicam os conceitos de visões refinadas sendo três as visões da aplicação overview geral macro e detalhe FOURNIER 1994 Formulação das Primeiras Questões Quem está por trás da solicitação deste trabalho Quem vai usar a solução Qual será o benefício econômico de uma solução bem sucedida Há outra fonte para a solução que você necessita Os modelos de processos de negócio ou diagrama de atividades e principalmente os cenários de uso são técnicas reconhecidas como eficientes e efetivas na elicitação dos requisitos Cenários de uso um caso de uso representa uma descrição breve de uso de uma determinada funcionalidade do sistema que é requisitada pelo usuário O diagrama de casos de uso Figura abaixo mostra a relação entre os casos de uso e a entidade ator Esse diagrama que faz parte do padrão de diagramas UML Unified Modeling Language Linguagem de Modelagem Unificada Ele é composto pelos elementos cenário casos de uso interações atores agentes ou entidades e o relacionamento de comunicação Na elicitação o diagrama de casos de uso como mostra a figura abaixo apresenta um cenário de uso específico do sistema em que apenas as interações do usuário com o sistema são mostradas servindo como um modelo para o processo de negócio Os detalhes técnicos de construção do sistema não são mostrados nesse diagrama eles são apresentados em outros diagramas da UML Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 6 Figura Diagrama de caso de uso em UML para a função de gerenciamento de compras do centro de distribuição Rodoalimenta Fonte MORENO 2020 342 Levantamento e Análise de Requisitos Na análise os membros da equipe técnica trabalham com o cliente e usuários para descobrir informações sobre o domínio da aplicação que serviços o sistema deve fornecer desempenho exigido do sistema restrições de software e de hardware SOMMERVILLE 2003 Figura Processo de levantamento e análise de requisitos Fonte SOMMERVILLE 2003 Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 7 35 ESPECIFICAÇÃO DOCUMENTAÇÃO E MODELAGEM DOS REQUISITOS Em sistemas e software o termo especificação significa coisas diferentes para pessoas diferentes A especificação e a modelagem são os produtos do trabalho final produzido pelo engenheiro de requisitos Ela serve como fundamento das atividades de engenharia de software subsequentes São descritas a função e o desempenho do sistema e as restrições que acompanharam seu desenvolvimento Uma especificação pode ser um documento escrito um modelo gráfico um modelo matemático formal casos de uso protótipos ou qualquer combinação desses elementos Os stakeholders interpretam os requisitos de maneiras diferentes e muitas vezes notamse conflitos e inconsistências inerentes aos requisitos SOMMERVILLE 2011 Existem vários requisitos que deveram ser levantados e deduzidos Contudo as atividades e tarefas descritas na preparação do documento de requisitos se baseiam em quatro principais grupos de requisitos que serão descritos neste mesmo tópico Os principais grupos de requisitos para elaboração do contrato do softwaresistema são Requisitos do Usuário Requisitos do Sistema Requisitos Funcionais e Requisitos Não Funcionais 351 Requisitos do Usuário RU São declarações em linguagem natural formulários e diagramas simples sobre as funções que o sistemasoftware deve fornecer e as restrições sobre as quais deve operar Este documento pode ser elaborado pelo representante do usuário A modelagem do negócio é um modelo de fácil interpretação que se utiliza normalmente um modelo construído com o diagrama de atividade da UML que é uma ferramenta fácil de usar e que inclusive o cliente se sente a vontade para expor suas ideias em um desenho o que auxilia muito o analista Os cenários de uso são construídos com o diagrama de casos de uso da UML É uma resposta do analista de sistemas para apresentar o escopo ou partes do software que será construído 352 Requisitos Funcionais RF Requisitos funcionais são declarações mais detalhadas dos requisitos do usuário com uma especificação completa e consistente de toda a funcionalidade ou serviços que se espera que o sistema forneça A atividade de elaboração dos requisitos funcionais consiste em extrair dos casos de uso as funções necessárias que irão operar no sistema Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 8 O objetivo é preparar um material detalhado para que possa ser passado para a codificação É aconselhável que para uma maior clareza dos objetivos das funções seja feito um quadro de especificações das funções do software como é mostrado na Figura abaixo e que contenha um código que identifique o requisito e a descrição do requisito como é mostrado no quadro Figura Tabela de especificação de Requisitos Funcionais RF Requisito Funcional RF Especificação RF01 Chamada de menu Relatórios deverá exibir o menu de relatórios disponíveis RF011 Função Relatório de compras relatório com as compras efetuadas no período desejado Exibindo Fornecedor produto comprado quantidade e valor RF012 Função Relatório de pagamentos efetuados relatório com os pagamentos efetuados a fornecedores no período desejado Exibindo Fornecedor produto comprado quantidade e valor pago Fonte MORENO 2020 As especificações das funcionalidades do software normalmente são refinadas por meio da prototipagem que é uma forma colaborativa de participação do cliente no desenvolvimento do software 353 Requisitos Não Funcionais RNF Neste instante você deve pensar Será que os requistos não funcionais é sobre aquilo que não irá funcionar no sistema Totalmente errado Os requisitos não funcionais determinam a qualidade do software que é o diferencial que faz de uma aplicação ser boa Uma forma de memorizar o que são requisitos não funcionais é saber que Requisito não funcional é tudo aquilo que o cliente não pede Mas se der problema ele vai reclamar Observe essa situação Um determinado usuário levou uma hora preenchendo um formulário na rede local de um sistema servidorcliente Ao finalizar e salvar o formulário o software emite um aviso de tela inteira de sistema fora do ar Se o software possuir o recurso de recuperação do arquivo mesmo que seja no computador local o usuário vai encarar isso de forma mais amena Diferente do que se ele perder o formulário já preenchido Ele vai reclamar de um problema de confiabilidade De acordo com Sommerville 2011 na Figura abaixo são mostrados os tipos de requisitos não funcionais formados pelos grupos Requisitos do Produto Requisitos Organizacionais e Requisitos Externos Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 9 Figura Tipos de requisitos não funcionais Fonte SOMMERVILLE 2003 O quadro apresentado na Figura abaixo apresenta as principais métricas de requisitos do produto Essas métricas servem como base para o desenvolvimento do produto software São determinadas principalmente como meta para estabelecer a qualidade exigida em que o software irá operar Figura Métricas de requisitos do produto Propriedade Medida Velocidade Desempenho Transações processadassegundo Tempo de resposta ao usuárioevento Tempo de atualização da tela Tamanho Espaço Tamanho em MegaBytes do software final Tamanho da memória Facilidade de uso Usabilidade Tempo de treinamento necessário Número de frames de ajuda Confiabilidade Tempo médio para falhar Probabilidade de indisponibilidade Disponibilidade Taxa de ocorrência de falhas Robustez Tempo de reinício após falha Percentual de eventos que causam falhas Probabilidade de corrupção de dados em caso de falha Portabilidade Percentual de declarações dependentes do sistemaalvo Número de sistemasalvo Fonte SOMMERVILLE 2011 Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 10 354 Requisitos do Sistema RS São descrições mais detalhadas dos requisitos do usuário com o foco no sistema com uma especificação completa e consistente de todo os componentes do sistema Podem ser apresentados vários modelos que mostram objetos ou fluxo de dados Servem como base para o contrato destinado a implementação do sistema Os componentes podem ser divididos em dois grupos 1 A visão estática da arquitetura promove a visão da organização e relações dos componentes do software com elementos de dados banco de dados arquivostexto etc com o hardware e outros ambientes operacionais 2 A visão dinâmica da arquitetura promove a visão comportamental do sistema e de seus componentes São definidos como os componentes reagem a eventos internos e externos e a forma como eles se comunicam ou trocam mensagens Seguindo o mesmo padrão aplicado para requisitos funcionais Os requisitos do sistema são especificados em um quadro de nome Especificação dos requisitos do sistema como mostra a Figura abaixo Figura Quadro de especificação de requisitos do sistema Requisito do Sistema RS Especificação RS01 Computador cliente modelo PC com médio desempenho RS02 Sistema operacional do computador cliente Windows Ver RS01 RS03 Navegador para internet A aplicação irá funcionar em uma rede intranet Fonte MORENO 2020 Para a modelagem dos requisitos do sistema são utilizados basicamente os diagramas de componentes e o diagrama de implantação da UML 36 VALIDAÇÃO DOS REQUISITOS A validação dos requisitos ocorre formalmente Os produtos de trabalho resultantes da engenharia de requisitos são avaliados e aprovados A atividade de validação é a última fase do processo da engenharia de requisitos responsável por autorizar o desenvolvimento do sistemasoftware É a tarefa de apresentar o documento de requisitos em reunião com a participação do grupo formado pelos interessados no sistema O objetivo é aprimorar incluir mudanças propostas e aprovar o início do projeto e desenvolvimento do softwaresistema O documento a ser validado pode ser elaborado para um único sistema parte do sistema ou para cada funcionalidade do sistema Vale o bom senso a análise decisiva deve ter base no tamanho complexidade ou qualidade exigida do sistema ou da Prof Ms Eng Edson Quedas Moreno Engenharia de Software REPRODUÇÃO PROIBIDA 11 funcionalidade associada ao seu prazo e custo Este documento pode ser interpretado como o Aceite do cliente O cliente valida os requisitos como compromisso das informações fornecidas e reconhecimento dos elementos que irão permitir a construção do sistema bem como custos e prazos acordados com o desenvolvedor Na validação os desenvolvedores se comprometem em desenvolver o sistema no custo e prazo determinado No desenvolvimento irão ocorrer algumas ou muitas mudanças nos requisitos o que impactará em nova verificação dos requisitos incluindo custo e prazo para novas implementações BIBLIOGRAFIA PFLEEGER Shari Lawrence Engenharia de software teoria e prática 2a ed São Paulo PrenticeHall 2004 PRESSMAN PhD Roger S Engenharia de Software 7ed Rio de Janeiro McGrawHill 2011 PRESSMAN PhD Roger S Engenharia de Software 6ed Rio de Janeiro McGrawHill 2007 PRESSMAN PhD Roger S Engenharia de Software 5ed Rio de Janeiro McGrawHill 2002 SOMMERVILLE Ian Engenharia de software São Paulo Pearson Addison Wesley 2003