TCC - UMA ABORDAGEM CONCEITUAL SOBRE ENGENHARIA DE

Tais requisitos não são simplesmente impostos ou presumidos, e sim, são artefatos que refletem as necessidades e expectativas dos clientes e demais interessados com relação ao sistema ao qual os mesmos pertencem (SOMMERVILLE, 2009). A atividade do processo de levantamento de requisitos é composta de quatro fases: estudo de viabilidade, levantamento e análise de requisitos, documentação e validação dos requisitos. No ‘levantamento e análise de requisitos’ o analista irá compreender e definir quais necessidades do usuário o software deve atender. Conforme Wilson de Pádua (2001) é nesse estágio que se encontra um dos problemas básicos da engenharia de software, que é a má especificação dos requisitos. Isso pode ser explicado por diversos motivos, tais como a escolha inadequada da técnica de levantamento de requisitos ou informações descritas incorretamente pelos usuários.

que propõe que o documento seja estruturado da seguinte forma: a) introdução: propósito do documento, escopo do produto, definições, referências e resumo geral do resto do documento; b) descrição geral: perspectiva do produto, funções, características do usuário, restrições de ordem geral, opções de projeto e dependências; c) requisitos específicos: devem ser especificados requisitos funcionais e nãofuncionais do sistema; d) apêndices; e) índice. Após a completa utilização destas técnicas e ferramentas, espera-se como resultado um documento de requisitos deste software. Este documento será uma declaração oficial do que deve ser tratado pela equipe de desenvolvimento do software nas etapas futuras de seu projeto. Para atingir este objetivo, sabe-se que há a necessidade de estudar e utilizar alguns recursos que permitam analizar a modelagem e diagramação dos requisitos, o que permitirá uma melhor visualização dos mesmos, conforme sugerido por Pressman (2011), através da utilização da UML (Unified Markup Language).

OBJETIVO 2. Com isso é possivél não só aprimorar técnicas, como criar novas formas de desenvolver com mas agilidades esse trabalho. ESTADO DA ARTE Através do estudo de artigos e livros, foi possível levantar o conhecimento de engenharia de requisitos e suas técnicas de levantamento atualmente utilizadas pelas empresas de software do Brasil. O primeiro artigo, de Samuel Fabiano, é divido em três partes, sendo: Engenharia de Requisitos, Técnicas de levantamento de requisitos e análise comparativa de técnicas de levantamento de requisitos. Na primeira parte ele explica sobre os requisitos, a viabilidade, a expectativa, o desenvolvimento dos requisitos, fala sobre a validação, e a importância de se obter um documento com todas as informações dos requisitos solicitados pelo cliente. Na segunda parte ele contextualiza sobre as técnicas de levantamento , explicado cada uma, começando com a técnica de JAD (Joint Application Development) que traz como “ benefícios alcançados podem ser a redução de 20 a 50% no tempo do desenvolvimento do sistema e ainda promover o trabalho em equipe.

DESENVOLVIMENTO TEÓRICO Para que um sistema seja desenvolvido é necessário ter uma clareza das necessidades apresentadas pelo cliente que precisam ser atendido com eficiência. Essas necessidades são apresentadas de formas diferentes, de acordo com cada sistema. No livro Engenharia de Requisitos 8º edição, lançado em março de 2009, é possível compreender com clareza algumas dessas necessidades, de acordo com as palavras do autor: “refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de engenharia de requisitos. ” Sommerville (2009, p. Por exemplo: Calcular os juros compostos à taxa de 14% ao ano, de um depósito fixo, por período de três anos.

Requisitos não funcionais descrevem restrições sobre os serviços ou funções oferecidos pelo sistema (Sommerville, 2009). Especificam os atributos de qualidade gerais que o sistema deve satisfazer. Por exemplo: Postabilidade; Confiança; Desempenho; Testabilidade; Modificabilidade; Segurança; Apresentação; Reusabilidade; Aceitação; Interoperabilidade. Regras de Negocio são regras que geralmente incluem terminologia especifica do domínio e fazem referência a conceitos do dominio (Sommerville, 2009). Para analisar a solicitação realizado pelo cliente sobre o sistema que deverá ser desenvolvido, segue-se os documentos que serão analisados. Os artefatos recebem as informações em detalhes, com isso fica mais fácil a análise e o desenvolvimento do sistema. Os artefatos devem um modelo que consiste de: - Breve descrição do sistema desejado; - um modelo conceitual; - um glossário; - uma lista de requisitos funcionais; - uma lista de requisitos não funcionais; - diagramas de interação com o sistema; Esses artefatos serão: - Documento de visão (DV); - Especificações de tela (ET); - Casos de uso (UC); A análise será verificar os itens presentes no documento seguido da critica ou observação quando houver necessidade.

As informações devem bem claras e devem seguir o uso de padrões do cliente. No caso de não aprovação da documentação, a mesma deve voltar para a equipe de desenvolvimento dos artefatos para serem realizadas as alterações necessárias, e assim, poder ser novamente avaliada, seguindo em seguida para a equipe de desenvolvimento do sistema. Convém que o entrevistador dê espaço ao entrevistado para esclarecer as suas necessidades. É uma discussão do projeto desejado com diferentes grupos de pessoas. Principais Vantagens: - 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; - 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; - Poder alterar a ordem seqüencial das perguntas; - Poder eliminar perguntas anteriormente planejadas; Poder incluir perguntas que não estavam na programação da entrevista; Poder motivar o entrevistado no decorrer do processo; Principais Desvantagens: - Podem ocorrer desvios de curso, no decorrer da entrevista; - Consumir mais tempo e recursos com sua realização; - Tratamento diferenciado para os entrevistados; - É 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; - O usuário tem dificuldade de concentração em reuniões muito longas; - O entrevistado pode não saber expressar corretamente suas necessidades ao analista.

WorkShop: Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos. Principais Vantagens: - Capacidade de observar o comportamento do ambiente, gerando maior profundidade no conhecimento. Apóia no comportamento real; - Permite uma abordagem integral. Principais Desvantagens: - Dificuldades para analisar e interpretar situações; - A amostra pode ser reduzida; - Requer treinamento especializado; - As observações podem ter uma interpretação complicada. Observação (Observation): A técnica resume-se em visitar o local em foco com a finalidade de observação do mesmo.

Permitindo assim, coletar informações de acordo com o cotidiano das operações e execução dos processos diários do local. Principais Desvantagens: - Documentos com problemas podem levar a uma falha na definição dos requisitos; Laddering: É um método de entrevistas estruturadas, um-a-um, utilizado para o levantamento de conhecimento (o que é importante e por que) de especialistas, e que consiste na criação, revisão e modificação da hierarquia de conhecimento dos especialistas geralmente na forma de diagramas hierárquicos (ex. diagrama em árvore). Principais Vantagens: - Cobre um amplo domínio de requisitos; - Necessita de menos tempo para a preparação e execução das sessões de levantamento; - Necessita de menos experiência para a execução das sessões de levantamento; - Provê um formato padrão que é adaptável para a automação computadorizada; Principais Desvantagens: - Não é capaz de extrair todos os tipos de requisitos; - Necessita da execução combinada de outras técnicas de levantamento de requisitos para sua complementação em determinados domínios; - Não é compatível com todo e qualquer domínio de  requisitos, sendo necessário a verificação de sua adequação ao levantamento a ser feito; 4.

Método de sintético Algumas vezes em projetos complexos um único método de levantamento de requisitos não é suficiente para capturar os requisitos detalhadamente. Para solucionar este problema os analistas de requisitos tentam utilizar diferentes métodos de levantamento de requisitos. Principais Vantagens: - As discussões que ocorrem na fase de sessões são altamente produtivas porque resolvem dificuldades entre as partes enquanto se dá o desenvolvimento do sistema para a empresa; - Melhor aplicado para grandes e complexos projetos; Principais Desvantagens: - Somente projetos que possuem pelo menos uma das características abaixo podem utilizar o JAD:- Possuir alto número de stakeholders responsáveis por departamentos cross na empresa; - Primeiro projeto na empresa o qual é considerado crítico para o futuro da mesma; - Requer mais recursos se comparado à métodos tradicionais; Prototipação: Utilizado no estágio inicial do projeto.

Ajuda aos stakeholders a desenvolver uma forte noção sobre a aplicação a qual ainda não foi implementada, que através da visualização da mesma eles podem identificar os reais requisitos e fluxos de trabalho do sistema. É 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. Principais Vantagens: - Permite alcançar um feedback antecipado dos stakeholders; - Redução de tempo e custo de desenvolvimento devido a detecção dos erros em uma fase inicial do projeto; - Prove alto nível de satisfação dos usuários devido a sensação de segurança ao ver algo próximo do real; Principais Desvantagens: - Demanda um alto custo de investimento, em relação à outros métodos, para ser realizado; - Demanda um tempo maior para sua realização devido a complexidade do sistema e a limitações técnicas; Figura 3 – Principios fundamentais de análise de requisitos Fonte: http://goo.

gl/4XLLA9 < acesso em 26/11/2015> A figura 3 demonstra como o cliente e do desenvolvedor podem se comunicar no momento do levantamento de requisitos do software. Fonte: http://goo. gl/ah5bGY <acesso em 03/07/2015> A figura 4 demonstra como realizar o mapeamento das informações de solicitação de um sistema pelo cliente. Diagrama de fluxo de dados (DFD) Foca sobre a circulação dos dados através do sistema e suas transformações. Ele é dividido em nivés: - Nível 0: também conheciso por diagrama de contexto, define o escopo do sistema. È composto por agentes externos, limites de sistema e os dados circulam entre os agentes e o sistema. Duplicações não são permitidas. Figura 6 - Demostra os processos Fonte: http://goo. gl/FcmvBK <acesso em 03/07/2015> Na figura 6 é possivél ver um exemplo de como desmonstrar as informações com claresa seguindo a regra que não pode haver duplicações.

Repositórios de dados São áeras usadas para armazenar informações e não são visualizadas no nível 0. Todos os repositorios de dados devem ser exibidos no nível 1. Fonte: http://goo. gl/FcmvBK <acesso em 03/07/2015> Exemplo 2: A empresa recebe um pedido de contratação. Checa as condições de qualificação. Convida os candidatos qualificados para uma entrevista de acordo com o desejado pela administração. Figura 8. Entidade Representa um coleção de objetos ou coisas reais cujos membros individuais ou ocorrências possuem as seguintes características: - De algum modo, cada um pode ser identificado com exclusividade. Cada um desempenha um papel necessário no sistema que está sendo desenvolvido. Cada um pode ser descrito por um ou mais atributos. Entidades geralmente correspondem a pessoas, objetos, localizações, eventos etc.

Por exemplo: funcionários, vendedores, fornecedores, materiais, datas, etc. Os atributos que possuem valores únicos são chamados de chaves candidatas e um deles é chamado de chave principal. Os domínios dos atributos devem ser predefinidos. Por exemplo, se ‘nome’ for um atributo de um entidade, seu domínio é o conjunto de características alfabéticos com tamanho predefinido. Relacionamento Descrevem a associação entre entidades e podem ser: - Obrigatório: Significa que se, um valor for associado a qualquer ocorrência da primeira entidade haverá pelo menos um ocorrência dele na segunda entidade. Opcionais: Poderá haver ocorrência na primeira entidade que não estejam associadas a nenhuma ocorrência da segunda entidade. Exemplo: um ou mais professores podem ensinar uma ou mais disciplinas, conforme na figura 10. C.

Figura 10. C - Exemplo 3: - Entidade muitos-para-muitos Fonte: http://goo. gl/FcmvBK <acesso em 03/07/2015> 5. Repositório de dados: Como o fluxo de dados, é composto de uma combinação de estruturas de dados e/ou elementos de dados. A descrição é similar aos fluxos de dados. Mini especificações de processos do sistema: informam as formas nas quais os fluxos de dados que entram no processo primitivo são transformados em fluxos de dados que deixam o processo. Apenas o esboço amplo é dado, não os passos detalhados. Elas precisam existir para todo processo primitivo. Árvore de decisão e Tabelas de decisão 7. Árvore de decisão Uma árvore d decisão representa decisões complexas sob a forma de uma árvore. Embora seja visualmente atraente, ela pode fugir do controle quando o numero e complexidades das decisões aumentam.

Exemplo: Existem regras para cobrança de energia elétrica, que são como as abaixo: - Se o medidor estiver “OK”, calcule a base de consumo (ou seja, medição). Se o medidor aparecer “BAIXO”, então verifique se a casa está ocupada. Clientes não domésticos são cobrados duplamente em relação aos usuários domésticos (taxa mínima e especial são duplas). Tabela 1 – tabela de decisão do consumo de energia elétrica Fonte: http://goo. gl/FcmvBK <acesso em 03/07/2015> Na tabela 1 é possível compreender como uma empresa de energia elétrica pode realizar sua cobrança para seus usuários. Como as árvores de decisão, as tabelas de decisão de valor binário podem ficar maiores se o numero de regras aumentar.

Tabelas de decisão de valor múltiplo possuem uma margem. Se transação é ‘PAGAMENTO’ então faça: - Atualize recebimento no arquivo mestre de contas. Atualize o valor total de recebimento no arquivo de controle. Diagrama de Transição de Estado O diagrama de transição de estado é outro diagrama útil. Ele pode ser usado para modelar as alterações de estado do sistema. Um sistema está em um estado e permanecerá nele até que uma condição ou uma ação o forcem a mudar. Um diagrama de atividades é um dos diagramas que compõem a visão dinâmica da UML e permite que o comportamento do sistema seja modelado, identificando os caminhos lógicos que determinado processo pode seguir, permitindo a visualização das pré e pós-condições de cada evento interno a este processo (LIMA, 2007).

Este diagrama especifica a coordenação de execuções de comportamentos, fazendo utilização de fluxo de controle e de dados. O fluxo de execução é modelado como nós de atividades, quem são conectados por extremidades. Cada um destes nós pode ser a execução de um comportamento subordinado, como, por exemplo, um cálculo, uma chamada a uma operação específica ou até a manipulação de conteúdos de objetos. Os nós de atividade também incluem construções de fluxo de controle, tais como: sincronização, decisão e controle de execuções paralelas. Em seguida constrói um protótipo da tela, que será encaminhado ao cliente para aprovação. Sendo aprovado, o sistema será desenvolvido utilizando a tela aprovada. Como exemplo, vamos realizar o processo descrito com a tela de Controle de Pedido, onde serão gerados os requisitos e os artefatos que condiz com a mesma.

Para aprovação do artefato, será encaminhada para o cliente, uma planilha de análise do documento, utilizando como um exemplo, será mostrado ao final do capítulo, a planilha de Especificação de tela, que consta na página 59 deste documento. Nesta planilha é possível observar que foi realizada uma primeira análise que foi rejeitada, sendo que o documento de tela precisou de ajustes, no qual após ser realizada, a planilha demonstrou a aceitação pelo cliente, como pode ser observado na página 63. Ele é auxiliado por compradores e pela equipe de funcionários do escritório. A força total do departamento é de 20 pessoas. A principal função do departamento de compras é adquirir material para produção, manutenção e para outros departamentos em tempo hábil para que não haja situações nas quais as atividades tenham de ser interrompidas devido à falta de algum material solicitado.

Atualmente, existem mais de 300 ordens de compra (OCs) abertas simultaneamente (uma OC é considerada fechada quando o material é recebido e a fatura paga) e tornou-se impossível manter-se a par das atividades de compra e fornecer o status atualizado aos departamento interessados. A idéia por trás do uso de um computador é a de acessar s informações de maneira rápida e monitorar a atividade de compra eficientemente. Os fornecedores enviam uma cotação técnica e comercial (licitação de 2 etapas). Se qualquer discrepância for encontrada, essas cotações são rejeitadas após a data de fechamento da consulta. Todas as cotações comerciais recebidas são abertas pelo comprador envolvido (na presença do gerente de compras e dos fornecedores) e depois são analisadas pelo valor total (custo básico dos materiais, impostos, frete de seguro da embalagem).

Com base do menor custo, uma oferta é selecionada e uma proposta de ordem de compra é elaborada. Uma proposta de OC é enviada ao departamento financeiro e um aval é obtido. Lista de eventos 1. Recebimento de solicitações de compra dos departamentos 2. Recebimento dos dados do departamento de estoque 3. Recebimento de cotação de fornecedores 4. Aceitação da ordem de compra por parte do fornecedor 5. ATORES ID NOME [AT – 001] Usuário cadastrado no sistema PRÉ – CONDIÇÕES Seleciona o documento que será integrado ao arquivo – pedido. PÓS – CONDIÇÕES Arquivo integrado ao documento. FLUXO PRINCIPAL (FP) 1. O sistema exibe opção de adicionar um arquivo - pedido ao documento. ET 01] [FA01] [FA02] [FE01] 2. O sistema exclui todos os documentos selecionados; 5. O sistema exibe a mensagem de sucesso da exclusão;[RM01] 6. FA encerrado.

FA02 – Visualizar o arquivo Obs: Este FA pode ser acionado em qualquer momento. O ator aciona a opção para visualizar; 2. DETALHAMENTO DOS REQUITOS Funcionais ID Titulo Descrição Uc's Situação RF 01 Manter alterações em documento O sistema deve manter as alterações realizadas no documento. UC0001 Nova Não funcionais Não se aplica a tela. Regra de negocio Não se aplica a tela. Regra de interface Não se aplica a tela. Regra de mensagem ID Descrição Situação RM01 Registro excluído com sucesso. No momento, tantos sistemas em construção, como sistemas que já existem e vão apenas atualizar, utilizam as técnicas de engenharia de requisitos para sua implementação. Este documento cumpriu seu papel de contextualizar sobre engenharia de requisitos e como realizar o levantamento dos requisitos para um software.

REFERÊNCIAS SOMMERVILLE, Ian. ENGENHARIA DE SOFTWARE: 8. ed. Rio de Janeiro, 2002. NBR 14724: informação e documentação - trabalhos acadêmicos - apresentação. Rio de Janeiro, 2011. MEZZAROBA, Orides & MONTEIRO, Cláudia Servilha. Manual de Metodologia da Pesquisa em Direito.