Modelagem de Sistemas de Informação

Prévia do material em texto

UNIVERSIDADE PAULISTA
SISTEMAS DE INFORMAÇÃO
MSOO – CLÍNICA ODONTOLÓGICA
SÃO PAULO
2023
SUMÁRIO
1. Objetivo do trabalho..............................................................................................03
2. Introdução.............................................................................................................04
3. Conceitos Gerais...................................................................................................05
3.1 Requisitos Funcionais..........................................................................................06
3.2 Requisitos Não Funcionais...................................................................................08
1. Objetivo do trabalho
Nesta Atividade Prática Supervisionada temos o objetivo de compreender, entender e colocar em prática tudo aquilo que se refere a modelagem de sistemas. Desde a parte inicial que são conversas entre Sponsors e Stakeholders a fim de entender o que é desejado no projeto, até a parte de modelar como será esse projeto, para que o mesmo aconteça dentro dos conformes e dentro daquilo que está sendo solicitado que o desenvolvedor faça.
Está etapa de modelagem é muito mais importante do que muitos acham, pois através dela é onde se encontram muitos erros de comunicação entre os idealizadores do projeto com os desenvolvedores de qual realmente é o objetivo do projeto e com isso evita a perda de investimento ou até mesmo de prazo para entrega do sistema pretendido.
Nesta atividade, foi desenvolvido um exemplo de modelagem de sistema através de um caso de uso sobre clínica odontológica que desejava um sistema que auxiliasse os funcionários, dentistas e pacientes. Ou seja, um projeto onde pacientes possam ter acesso a um website para marcar suas consultas com os doutores que desejarem e no horário e dia que mais se encaixar, além de facilitar para o próprio dentista e funcionários a conseguir dados dos pacientes e agilizar todo o encaminhamento de uma consulta ou de um relatório pós consulta.
2. Introdução
3. Conceitos gerais
3.1. Requisitos Funcionais
Requisitos funcionais são necessidades dentro da engenharia de software, que serve para solucionar os problemas dentro de um projeto que está sendo feito e é indispensável para qualquer sistema a ser desenvolvido. É um artifício do sistema o qual o usuário deseja. Em palavras mais simples, pode ser dito que esses requisitos são uma maneira de como o sistema deve agir e quais são as funções as quais ele deve seguir. Na maioria das vezes, esses recursos são bastante fáceis de enxergar, por exemplo, ao fazer uma conta em algum site é necessário confirmar o e-mail. Nesse caso, o requisito funcional do sistema é que o sistema deve mandar o e-mail de confirmação do usuário. Muitas vezes o requisito pode ser algo mais difícil de identificar, mas é importante identificar que são bem diferentes dos requisitos não funcionais que são aqueles que definem como o sistema deve ser executado na forma interna dele. Enquanto os requisitos funcionais são exatamente as funções que um sistema deve seguir, os requisitos não funcionais não são obrigatórios dentro do sistema, mas sim uma preferência do usuário.
É possível separar os requisitos funcionais em duas partes, sendo elas função e comportamento. A função é o que o sistema deve executar, enquanto o comportamento é como deve ser executado tal função. Ou seja, tem que ser especificado como o software deve processar as informações pedidas. São requisitos importantes e chave para qualquer projeto que seja desenvolvido, assim como as regras de negócio. 
O processo de vida de um requisito começa no levantamento de requisitos, que assim são estudados e enfim compreendidos a ponto de serem validados para a construção de um software. Isso vale para qualquer tipo de software, logo é sempre importante gerenciar e definir bem esses requisitos a fim de que não causem problemas e dores de cabeça aos programadores e também para que eles possam sempre fazer bem feito. Para bem defini-los, é preciso escrevê-los de maneira compreensível e fácil de entender, de modo que seja bem legível e entendível para os desenvolvedores. A clareza ao definir qualquer coisa dentro de um software é uma das coisas mais importantes no processo, assim se pode ter certeza que tudo será bem feito. Além de definir bem, é necessário que definam os limites, os dados coletados, as medidas de segurança tomadas para proteger os dados e a função exata de cada requisito, a fim de que atendam as necessidades exigidas pelos clientes.
As formas de identificarem os requisitos funcionais podem ser variadas, afinal existem muitas técnicas, entre elas conversas com os clientes, analisar os documentos escritos pelos Stakeholders e entre outras. Quando forem identificados, eles devem ser separados entre requisitos de segurança, requisitos de dados e entre outros.
Requisitos são um conjunto de ideias pedidas pelos usuários de um sistema. A análise de requisitos, que é onde os requisitos são levantados, é definido tudo o que o software deve fazer e isso tudo é definido pelos clientes.
De maneira geral é de bastante relevância que se entenda o papel dos requisitos funcionais e sempre saibam entendê-lo bem, a fim de que o organizem bem para também planejar a maneira que o sistema será desenvolvido, para que atenda as necessidades dos Stakeholders.
3.2. Requisitos Não Funcionais
3.3. Regras de Negócio
Uma regra de negócio é um aspecto, uma diretriz, do negócio que define ou restringe a estrutura e o comportamento de um programa, cobrindo cada situação específica de um negócio que deva ser padronizado de acordo com a decisão da empresa. Normalmente são definidas por stakeholders e os líderes das áreas técnicas.
As regras de negócio definem as necessidades do negócio, como validações, restrições e especificações de uso e comportamento como regras lógicas, permitindo que sejam aplicadas durante o desenvolvimento de um novo programa com a finalidade do programa estar de acordo com as visões e ideais da empresa e possibilitando os desenvolvedores a criarem o programa seguindo essas regras e garantindo a aplicação das mesmas da maneira mais clara possível.
Da visão empresarial, as regras de negócio permitem que as empresas expressem suas visões, objetivos, determinações, procedimentos e limitações de seus produtos de uma forma mais calara e simples tanto para desenvolvedores envolvidos na criação do programa ou trabalhando em um projeto como para os usuários.
É comum existirem regras de negócio para situações em que a empresa precise estabelecer regras claras, como no cadastro, autenticação, cálculos em geral e políticas de um produto, como a política de proteção de dados de usuário ou o Acordo de licença do usuário final (EULA), por exemplo.
Por definição, uma regra de negócio deve ser clara, sucinta e compreensível, cobrindo apenas um aspecto ou atividade do negócio, definindo procedimentos para esses aspectos.
Para explicar regras de negócio, pode-se fazer uma ligação com a programação. Se um programa é um grande conjunto de tomadas de decisões (if e else), as regras de um negócio também podem ser pensadas dessa mesma forma.
 As regras de negócio também estão ligadas com os requisitos de um programa, já que muitas vezes existem requisitos que são criadas especialmente para lidar com as regras de negócio de um programa, como no momento de efetuar um cadastro ou autenticar um usuário ou no momento de realizar um cálculo ou procedimento de uma maneira específica.
Os principais motivos para implementação das regras de negócio são a padronização de processos (consistência), a eficiência no fluxo de trabalho, principalmente na comunicação entre um stakeholder e o desenvolvimento e o entendimento dos processos, esclarecendo as regras utilizadas para o núcleo de desenvolvimento e necessidade geral do programa.