Engenharia de Requisitos - Parte II - Profundidade de Requisitos

Olá sejam bem-vindos ao canal engenharia de software com ênfase o ML eu sou o professor julianes Guedes e eu já atuo na área de modelagem de software H vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema de engenharia de requisitos dessa vez falando sobre profundidade de requisitos e requisitos funcionais e não funcionais Então vamos iniciar a nossa aula então vou falar sobre profundidade dos requisitos os requisitos eles podem

ser descritos em diversos níveis de detalhe e profundidade então uma forma de classificar os requisitos é em requisitos de negócio requisitos de usuários e requisitos de sistema ou requisitos de solução cada um desses requisitos possui um nível de detalhamento um nível de profundidade maior Então vamos iniciar falando sobre os requisitos de negócio Ah os requisitos de negócio eles consideram o ponto de vista do cliente eles são os requisitos de nível mais alto e menos detalhado e basicamente eles servem de justificativa para o desenvolvimento de um software Ah eles determinam Qual será o lucro qual será

a vantagem qual quais serão os benefícios para a empresa do desenvolvimento do software ou Qual será o prejuízo evitado se o software não se o software for desenvolvido Então esse tipo de requisito está ligado diretamente ao âmbito do domínio do problema então os requisitos de negócio eles definem de maneira geral o problema que se pretende solucionar a justificativa para desenvolver o software os objetivos que se pretende atingir que serão posteriormente utilizados para medir a qualidade do produto final quais serão os benefícios proporcionados pelo software assim os requisitos de negócio eles descrevem as necessidades as necessidades

da empresa como um todo ou dos clientes quando se trata de um software voltado para um grande público ã eles não se atém às necessidades de um grupo de partes interessado específico mas sim da empresa ou do grande público alvo como um todo Vamos falar agora sobre requisitos de usuário ah obviamente esse tipo de requisito considera o ponto de vista dos usuários que irão utilizar o software são uma ligação entre os requisitos de negócio e os requisitos de sistema eh eles ainda apresentam uma descrição em Alto Nível das necessidades de cada ator que irá utilizar

o software mas já com seu nível de detalhe um pouquinho maior bom mas o que são atores Como já foi falado em outros vídeos um ator ele representa um grupo de usuários que interpreta um papel quando utilizam o software como por exemplo eh o papel de gerente o papel de programador ou papel de digitador cada um desses papéis possui um nível de permissão maior ou menor e utilizam determinadas funcionalidades tem acesso ao maior ou menor número de funcionalidades Ah quando se tratar de um papel que é assumido por um grande número de usuários é muito

importante consultar as necessidades de alguns elementos desse grupo Na verdade deve se fazer isso para todos os papéis mas principalmente quando é um papel que tem um grupo de usuários muito grandes Ah então os usuários eles costumam ser bastante críticos para o sucesso do produto muitos usuários não vem o desenvolvimento de um software novo com bons olhos Eles não gostam da ideia de ter que um software novo eles estão acostumados com Talvez um software antigo que possa ter pode ter problemas mas eles conhecem então é necessário uma dedicação maior para a identificação dos requisitos de

usuário e é importante trazer os requisitos de usuário para o lado da equipe de desenvolvimento convencendo os usuários que o software irá auxiliar melhorar o trabalho deles irá melhorar a vida deles trazer os usuários para o lado da equipe é importante porque em algumas situações os usuários podem até sabotar tentar sabotar o desenvolvimento do software eh por não gostarem de ter que aprender um software novo de ter que dispender horas de Treinamento esse tipo de coisa então os requisitos de usuário eles definem como o usuário irá interagir com o sistema e o que o sistema

deverá fazer para o usuário Ah esse tipo de requisito ele pode ser expressado por meio de casos de uso casos de uso eles são bastante bons para demonstrar as interações entre usuário e o sistema e também para detalhar os diversos cenários que os usuários H por meio dos quais usuários interagiram com o software e alternativamente os requisitos de usuários também podem ser expressados por meio de histórias de usuário então Eh existe um outro problema que é o de conseguir levantar descobrir os requisitos dos usuários porque isso não é uma tarefa muito fácil porque os usuários

às vezes eles não sabem o que eles querem as necessidades Eles não sabem expressar suas necessidades h de maneira concreta as ideias que eles têm sobre as necessidades deles são vagas e Nebulosas então a função do engenheiro de requisitos traduzir essas necessidades em conceitos concretos tangíveis compreensíveis isso não é uma tarefa fácil muitas vezes o engenheiro de requisitos Tem que ajudar dar os usuários a se expressarem a formalizarem as suas necessidades e até sugerir funcionalidades que seriam úteis para os usuários Então os requisitos do usuário eles devem ser enfocados no início porque isso permite estabelecer

Logo no início do desenvolvimento as necessidades desses usuários e quando se for levantar os requisitos como eu já falei os requisitos de usuário obviamente como eu já falei é importante convencer os usuários da importância do sistema para eles é importante trazer os usuários pro lado da equipe de desenvolvimento convencer eles que isso vai ser bom para eles que vai auxiliar que vai melhorar o trabalho deles hã Então os usuários às vezes eles são reticentes quanto ao desenvolvimento de novo software eles podem não gostar da ideia porque talvez eles já usem o sistema anterior que pode

não funcionar tão bem mas eles conhecem e porque simplesmente eles não querem aprender algo novo Muitas pessoas não gostam de aprender algo novo exceto se isso Estiver dentro da sua área de interesse então eles não gostam de ter que gastar muitas horas às vezes Dias sendo treinados para aprender a desenvolver um software novo então é importante fazer com que os usuários ã falem sobre os problemas que eles enfrentam nos trabalho como um novo software poderia melhorar facilitar a a sua vida isso ajuda a produzir requisitos agora nós vamos falar sobre os requisitos de sistema eles

são os requisitos mais profundos e eles consideram o ponto de vista do sistema eles como eu falei possuem um detalhamento bem mais profundo e formal das funcionalidades do software e eles são produzidos Somente durante a fase de análise de requisitos como eu falei a engenharia de requisitos ela tem quatro fases principais elicitação de requisitos análise de requisitos eh especificação de requisitos e validação de requisitos durante análise de requisitos os requisitos de usuário eles são melhor avaliados e detalhados mais mais profundamente ah os requisitos de negócio e os requisitos de usuário eles também são analisados melhorados

e até corrigidos durante a análise requisitos mas os eh porém esses requisitos de usuário de negócio Eles já começam a ser eh concebidos e licitados identificados durante a licitação de requisitos já os requisitos de sistema só passam a ser produzidos durante a fase de análise de requisitos certo agora eu vou falar sobre requisitos funcionais ah os requisitos funcionais como o nome diz eles expressam funcionalidades explícitamente declaradas são requisitos de sistemas ã E essas funcionárias idades elas precisam ser suportadas pelo software basicamente funcionalidades são as funções do serviços que o software oferece a seus usuários Ah

então esse serviço ou função ele deve ser disponibilizado pelo sistema a um grupo de usuários específico Ah então os requisitos funcionais eles incluem a reação do sistema a determinados estímulos e o comportamento em cada possível cenário Então os requisitos funcionais eles descrevem aquilo que o software precisa fazer aquilo que o software precisa oferecer a seus usuários e nós temos os requisitos não funcionais os requisitos não funcionais eles estabelecem restrições ao funcionamento de um software eh que podem ser as condições à quais o software deverá se adequar e obedecer na verdade existe três tipos de requisitos

não funcionais os requisitos não funcionais mais comuns são os requisitos de produto que identificam características mais Gerais que devem ser atendidas pelo software como um todo por grande parte dele como usabilidade desempenho escalabilidade confiabilidade portabilidade manutenibilidade segurança proteção entre outros então esse tipo de requisito ele também pode definir condições para que o software seja desenvolvido por exemplo ferramentas processos e o ambiente de desenvolvimento nós vamos falar um pouco sobre sobre cada tipo de requisito não funcional Ah então os requisitos não funcionais eles definem condições atributos e características que o software precisa suportar de tal maneira

que as funcionalidades atendam à necessidades e expectativas das partes interessadas então requisitos não funcionais eles descrevem como o software deve ser de maneira geral Então os requisitos não funcionais eles podem ser classificados em três grupos requisitos não funcionais de produto requisitos não funcionais organizacionais e requisitos não funcionais externos vamos falar um pouquinho sobre cada um deles os requisitos não funcionais de produto são os requisitos mais conhecidos ou mais comuns eles são complementares os requisitos funcionais e enfocam eh determinam fatores de qualidade para o produto então eles muitas vezes eles são são também chamados requisitos de

qualidade então não adianta o software atender somente aos requisitos funcionais se os requisitos não funcionais não são atendidos então não adianta se atender a todos os requisitos funcionais se o desempenho se o tempo de resposta ou se a confiabilidade são fracos e não atende as necessidades do software o software é lento demais ele não é suficientemente confiável ele não tem uma capacidade escalável suficiente para as necessidades do software esse tipo de coisa Ah aqui nós vamos falar nós temos algumas listas alguma lista de alguns de alguns elementos ao que podem ser classificado como requisitos não

funcionais como por exemplo desempenho confiabilidade escalabilidade segurança proteção usabilidade manutenibilidade portabilidade acurácia e eficiência e essa lista é não exaustiva existem outros tipos de requisitos não funcionais Ah e nós temos requisitos não funcionais organizacionais eles estabelecem condições sobre como o sistema deverá ser utilizado então eles também são chamados requisitos de processo operacional ã também eles estabelece condições que determinam o ambiente operacional em que o software irá ser executado nesse caso eles são chamados de requisitos ambientais e eles também eh pode definir o tipo de processo de desenvolvimento que deverá ser adotado Isso inclui as ferramentas

de desenvolvimento que devem ser utilizadas e as normas que devem ser seguidas durante o o processo de desenvolvimento nesse caso os requisitos não funcionais organizacionais são chamados de requisitos de processo de desenvolvimento e nós temos os requisitos não funcionais externos que eles são normalmente estabelecidos ou influenciados por entidades reguladoras externas que costumam definir requisitos legais leis que devem ser obedecidas requisitos éticos que embora às vezes não sejam h não tenho força de lei Eles são muito importantes que sejam atendidos e normas para aprovação de uso do software entre outros essas essas regras elas precisam ser

obedecidas pelos desenvolvedores vou falar um pouquinho sobre regras de negócio que às vezes podem ser consideradas como a terceira categoria Ah então as empresas Elas costumam possuir políticas regras normas e procedimentos e que ess e essas normas essas regras elas precisam ser obedecidas pelos seus processos pelas funcionalidades que o software suporta então Além disso as empresas muitas vezes elas precisam obedecer e se adequar a leis e normas municipais estaduais Federais e até mesmo internacionais quando o software se destina a um público externo além do Nacional então ah e também existem situações em que a empresa

ela precisa satisfazer obedecer e se adequar a regras normas comportamentos e condições que embora possam não ter força de lei elas são estabelecidas por órgãos de controle por sindicatos por organizações e outras instituições e precisam ser igualmente atendidas ah Ah porque se não forem atendidas isso pode causar problemas protestos prejuízos processos multas descredenciamento e sanções diversas por quê eh porque às vezes eh aliás vamos primeiramente falar isso isso é válido também para softwares que se destinam a grandes públicos Porque eles devem a obedecer a normas leis e comportamentos que são exigidas por órgãos instituições públicos

e privados eh e em outras situações existem regras que não não estão escritas ou não são oficiais mas que elas precisam ser obedecidas precisam precisam ser atendidas porque se não forem isso pode ser considerado inaceitável para o público alvo ou por pessoas ou entidades que estejam relacionadas a esse público alvo como por exemplo pais familiares grupos sócios culturais escolas congregações religiosas esse tipo de coisa então às vezes por exemplo e se tratando de um jogo ã pais ou familiares podem não ficar ã confortáveis que os seus filhos utilizam o jogo porque ele não ã obedece

a certas regras Não aceita não não atende a certas Convenções sociais isso pode forçar com que o software seja retirado do mercado e até mesmo causar a falência da empresa que o desenvolveu Ah então as regras de negócio elas estabelecem como os requisitos devem ser implementados estabelecendo normas práticas condições restrições e validações E essas normas precisam ser respeitadas por funcionalidades específicas e eventualmente pelo software como um todo e nesse sentido as partes interessadas do tipo reguladoras Elas têm normalmente uma influência muito forte na definição dessas regras de negócio agora vamos falar sobre alguns exemplos de

regras de negócio por exemplo em o Sistema de Controle bancário pode pode haver uma regra de negócio em que se estabelece que é preciso ser maior de 18 anos para abrir uma conta corrente e o sistema de biblioteca só se permite fazer um empréstimo de livro se o sócio não tiver atingido o limite máximo de empréstimos e não ter nenhum livro emprestado em atraso então is são regras de negócio que precisam ser atendidas por determinado as funcionalidades E então nós terminamos a segunda parte sobre engenharia de requisitos eu espero que esse vídeo tenha sido útil

para vocês se vocês gostaram do vídeo peço que compartilhem com quem possa ter interesse e se ainda não estão inscritos eu gostaria que vocês se inscrevesse no canal e também se fosse possível que vocês curtisse esse vídeo Ah obrigado pela atenção nós nos vemos nas próximas aulas