1 IAS trabalho 17.8.2020

Prévia do material em texto

Introdução a Análise de Sistemas
FAETERJ – Faculdade de Educação Tecnológica do Estado do Rio de Janeiro
DISCIPLINA: Introdução a Análise de Sistemas
DISCENTE: Bruno Rolemberg de Albuquerque
TURNO: Noite
REGRAS DE NEGÓCIO
Regra de negócio é a lógica que guia o comportamento e define O QUE, ONDE, QUANDO, POR QUE e COMO será feito, além de como o negócio será gerenciado ou governado. As regras podem assumir muitas formas, de simples decisões booleanas a decisões que envolvem regras de lógica mais complexas. 
Regras são declarativas e não podem ser decompostas sem perder seus significados
Algumas regras podem estar muito bem definidas e claras dentro da empresa, mas algumas regras não são tão bem difundidas entre os colaboradores e algumas delas acabaram virando um compromisso tácito. No fundo as regras de negócio são um patrimônio da empresa e devem ser tratadas como qualquer outro patrimônio, com os devidos cuidados.
No mundo dos negócios estas regras tem um cuidado especial, pois em sua essência, os negócios devem ter um padrão capaz de lhe dar diretrizes, descrever seus interesses e objetivos, definir seus compromissos éticos e sociais, estabelecer metas, criar métricas de avaliação dos objetivos alcançados, planos de contingência, análise de riscos, entre outros aspectos.
Regra de negócio em um termo fechado e pacífico, ela apresenta algumas características bem marcantes tais como: são expressas através de declarações visando comunicar a essência da regra de maneira mais clara possível; elas expressam o que deve ser feito e não como deve ser feito; Regras de negócio não dependem de tecnologia; Regras de negócio são atômicas. 
As Regras de Negócio podem ser definidas sob duas perspectivas: a do negócio e a de sistemas de informação do ponto de vista do negócio, uma regra destina-se a influenciar ou guiar o comportamento do negócio, como suporte a uma política que é formulada em função de uma oportunidade e ameaças do ambiente no qual a organização está inserida. Por estrutura do negócio pode-se considerar o modelo estático do negócio com seus dados (termos) e os relacionamentos entre eles (fatos).
A relação entre regras de negócio e sistemas informatizados, mas é importante destacar que as regras de negócio servem aos gestores do negócio e não ao pessoal de TI, não que o pessoal de TI não faça uso dela, mas as regras de negócio precisam ter a flexibilidade necessária para se adaptar aos diferentes momentos e necessidades da empresa, não podendo estar presas a uma tecnologia, além disso, os softwares que tratam desse tipo de informações devem fornecer os dados necessários para os gestores de modo que eles tenham recursos de dados para analisar a melhor decisão a ser tomada.
As regras de negócio em um software podem ajudar empresas a tomar decisões de forma ágil e segura. Mas muitas pessoas têm dúvidas sobre como isso funciona na prática. Para que fique tudo mais claro, nada como analisar alguns exemplos de regras de negócio: 
Exemplos de regras de negócios em um banco: Para descontar um cheque no caixa: “Cheques até R$ 100,00 reais, compensar sem verificar a assinatura; entre R$ 100,01 e R$ 500,00, verificar assinatura; acima de R$ 500,00, verificar qualidade do papel e outros itens de segurança, além da assinatura”.
Exemplos de regras de negócios em fábricas e escritórios: Em um escritório de advocacia, para decidir que nível de advogado será responsável por uma causa: “Para causas até R$ 5.000,00, advogados júnior; entre R$ 5.000100 e R$ 25.000,00, advogados plenos; entre R$ 25.000,00 e R$ 75.000,00, advogados sênior. Independentemente do valor da causa, clientes da lista “Premium” devem ter os processos encaminhados para um sócio da empresa que definirá que advogado será responsável pela causa”.
REQUISITOS 
Os Requisitos podem ser de toda ordem, mas apenas os requisitos interessantes ao sistema são trabalhados pela Análise de Requisitos ou Engenharia de Requisitos. Os Requisitos são reconhecidos na fase de Levantamento de Requisitos através da utilização de várias técnicas para este determinado fim, e tem origem em uma demanda, uma necessidade, uma condição, de alguém para se atender, em primeiro plano um usuário e em segundo plano um contrato ou um padrão. 
Na Engenharia de Software o Requisito é encarado como uma necessidade, um recurso, uma necessidade que precisa ser atendida de forma computacional a um determinado fim de um sistema, uma organização ou uma pessoa.
O requisito funcional normalmente é descrito de duas maneiras, através de Requisito Funcional e Requisito Não Funcional.
Um requisito funcional pode conter dentro de si diversos requisitos não funcionais. Importante salientar que mesmo não expressando uma ação, o requisito não funcional não expressa algo genérico aberto. Na especificação do requisito não funcional ele deve ser apresentado com algum tipo de valor que possa ser avaliado e testado.
FUNCIONAIS 
O Requisito Funcional utiliza sentenças de alto nível que descreve o que o sistema deve fazer. São obtidos em propostas, manuais e procedimentos. 
Normalmente são identificados no início do projeto e geralmente tem um verbo no infinitivo e uma entidade.
O Requisito funcional descreve a funcionalidade do produto, software, serviço ou sistema.
Características dos Requisitos Funcionais: 
Implicam uma ação e, portanto, devem ser indicados no infinitivo: manter, inserir, cadastrar, cancelar, excluir, logar, gerar relatório e sacar. 
Acionar entidades: efetuar compras, estornar produto, selecionar tipo de pagamento e alertar sobre limite de estoque. 
Devem mostrar a inteligência do sistema: emitir relatório de produtos mais vendidos, relacionar produtos a perfil do consumidor e identificar o tipo de compra por período. 
Exemplos de Requisitos Funcionais: 
O usuário pode pesquisar todo ou um subconjunto do banco de dados.
O sistema deve oferecer telas apropriadas para o usuário ler documentos armazenados.
Cada pedido deve ser associado a um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta. 
NÃO FUNCIONAIS
Definem propriedades e restrições do sistema, podem ser do sistema todo ou de partes do sistema, apresentando um caráter qualitativo de requisito.
Requisitos não funcionais podem ser mais críticos que requisitos funcionais. Se não satisfaz, o sistema é inútil. 
O Requisito Não Funcional apresenta descrições de como, de qual forma, e de que maneira o sistema deve fazer algo. 
Características dos Requisitos Não Funcionais: 
Não estão presos a utilização de verbos no infinitivo, já que expressam um como fazer em caráter qualitativo. 
Podem ter origens em processos e padrões organizacionais. 
Requisitos externos que são externos ao sistema e ao processo de desenvolvimento do sistema. 
Exemplos de Requisitos Não Funcionais: 
Requisitos do Produto - A interface do usuário deve ser implementada como simples HTML. 
Requisitos Organizacionais - Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00. 
Requisitos Externos - Informações pessoais dos usuários não podem ser vistas pelos operadores do sistema. 
CONCLUSÃO
Lidamos com regras em todas as esferas de nossa vida, podemos definir regra como um padrão de comportamento aceito que define padrões de decisões que os indivíduos se comprometem em seguir, podendo haver, ou não, alguma contramedida para recuperar a regra quebrada e punibilidade do responsável pelo desrespeito do padrão estabelecido.
Em termos gerais o Requisito é algo que tem origem em uma demanda, uma necessidade, uma condição, de alguém para se atender, em primeiro plano um usuário e em segundo plano um contrato ou um padrão. 
Na Engenharia de Software o Requisito é encarado como uma necessidade, um recurso, uma necessidade que precisa ser atendida de forma computacional a um determinado fim de um sistema, uma organização ou uma pessoa.
Saber utilizar todo esse processo é muito importante pois cada vez mais se exige que as empresas possuam um sistema de qualidade e rastreabilidade de forma quetodo o seu processo de desenvolvimento seja acompanhado pelo cliente e implementado com êxito permitindo a manutenção por desenvolvedores no futuro. 
REFERÊNCIAS
ALENQUER, Pablo Lopes. Regras de Negócio para Análise em Ambientes OLAP. - Rio de Janeiro, 2002. Disponível em: HTTPS://www.cin.ufpe.br/~sfa/Regras%20de%20Neg%F3cio%20para%20An% E1lise%20em%20Ambientes%20OLAP.pdf Acessado em: 17 de agosto de 2020. 
G. DIAS, Felipe; P. MORGADO, Gisele; E. MARTINS, Alissandra; M. SEABRA, Célia; S. SILVEIRA, Denis; J. ALENCAR, Antônio; M. V. LIMA, Priscila; A. SCHMITZ, Eber. ANAIS PRINCIPAIS DO I SIMPÓSIO BRASILEIRO DE SISTEMAS DE INFORMAÇÃO. 2004 Disponível em: https://sol.sbc.org.br/index.php/sbsi/article/view/63833. Acessado em: 17 de agosto de 2020.
Exemplos-de-regras-de-negocio/ 2002-2020 Venki Disponível em https://www.venki.com.br/blog/exemplos-de-regras-de-negocio/ visitado em 17 de agosto de 2020. 
FIGUEIREDO, Eduardo. Requisitos Funcionais e Requisitos Não Funcionais Disponível em: https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/req-funcional-rnf_v001.pdf Acessado em: 17 de agosto de 2020.
SOUZA, Adler Diniz. MOOC UNIFEI – Engenharia de Software I. Disponível em: HTTPS://mooc.unifei.edu.br/course/view.php?id=7 Acessado em: 17 de agosto de 2020. 
XAVIER, Neila. Elicitação de Requisitos. Disponível em: HTTPS://drive.google.com/file/d/1Xq4WdOqhyXxxw1U5GQgz35HApOXSnRL/view. Acessado em: 17 de agosto de 2020.