Classificação FURPS

Olá sejam bem-vindos ao canal engenharia de software com ênfase o IM Eu sou professor Janes gues eu já atuo na área de modelagem de software há vários anos eu tenho quatro Dios publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos so modelagem de software utilizando a linguagem uml Nesta aula eu vou falar sobre a classificação furps que está dentro das atividades realizadas durante a fase de análise requisitos Então vamos iniciar a nossa aula então como eu falei nós vamos explanar a classificação furps mais então a classificação furps Mais na verdade ela

foi introduzida pelos pelo método up pelo método pelo processo Unificado não método pelo processo de desenvolvimento Unificado então o objetivo é categorizar os requisitos de software tanto requisitos funcionais como requisitos não funcionais na verdade a a classificação FS ela também é uma maneira de priorizar requisitos mas basicamente ela tem um objetivo Mais amplo que é identificar basicamente todos os requisitos que deverão ser de alguma forma atendidos pelo projeto então furps é o acrônimo das iniciais functionality usability readability performance supportability e o mais representa outras possíveis categorias de requisitos que possam eventualmente existir então ah com

exceção da functionality eh todas todas as categorias representam o requisitos não funcionais Lembrando que requisitos podem ser funcionais ou não funcionais requisitos funcionais representam funcionalidades do software ou seja serviços eh funções que o software deve oferecer aos seus usuários enquanto que os requisitos não funcionais são os requisitos de qualidade são requisitos que identificam H características que o software como um todo deve atender como escalabilidade proteção segurança confiabilidade usabilidade manutenibilidade desempenho esse tipo de coisa então ah esse tipo de classificação ele ajuda o engenheiro de requisitos a pensar de forma abrangente sobre os diversos aspectos de

qualidade do produto também é uma forma de priorizar requisitos nós já abordamos priorização de requisitos num vídeo anterior eh que foca nos requisitos mais críticos para o sucesso do projeto principalmente eh os requisitos não funcionais nesse caso e também eles procura a auxiliar engenheiro de requisitos a especificar um sistema de alta qualidade que atenda tanto aos requisitos funcionais quanto aos requisitos não funcionais então falar sobre a a categoria functionality Então os requisitos dessa categoria eles basicamente representam os requisitos funcionais do software ou seja como eu falei as funcionalidades os serviços as funções que o software

deve oferecer basicamente identifica o que o software deverá fazer bom H além desses requisitos terem sido categor izados nessa categoria obviamente eles precisam ser priorizados utilizando outras técnicas de acordo com o seu nível de importância o seu nível de estabilidade eh isso já foi ensinado no vídeo anterior e os requisitos do tipo functionality Eles são considerados bem sucedidos Quando forem efetivamente implementados bom Ah já o os requisitos da da categoria usability Ou usabilidade eles tentam estabelecer as formas de tornar o produto o mais fácil e agradável possível para os usuários finais então basicamente ele se

concentra na definição da interface H máquina tento estabelecer uma interface H máquina de alta qualidade ã então esses requisitos eles são considerados bem sucedidos quando o software produzido ele é considerado fá de usar pelos usuários finais tem um bom suporte um bom auxílio um bom help uma boa ajuda de forma que e ajude o cliente a o usuário a entender o software e a prevenir a ocorrência de euros eh também ele deve estar de acordo com os padrões de interface estabelecidos deve utilizar o mesmo formato os mesmo mesmo formato de cores o mesmo tamanho de

letras o mesmo estilo de mensagens etc Ah ele deve ser intuitivo fácil de aprender e ter um nível de ajuda adequado Ah já o requisito de reliability Ou confiabilidade ele se concentra em determinar quão confiável um software deve ser um software é confiável se ele não apresenta ecos E se ele consegue estar sempre em execução tá mesmo que ocorram mesmo que falas ocorram ele continua executando Mesmo que às vezes um pouco mais lento então software confiável se ele é capaz de evitar que falhas ocorram e caso ocorrerem que o software continue funcionando apesar da da

das falhas e de forma transparente sem que o usuário perceba ainda o software deve ser capaz de recuperar o mais rápido possível ainda falando sobre confiabilidade como eu falei quando ocorrerem falhas preferencialmente que não ocorram mas se ocorrerem a a correção dessas falhas e a própria ocorrência delas deve ser transparente pro usuário o usuário não deve perceber que ocorreu uma falha e também que eh se ela ocorrer que ela está sendo corrigida o software deve continuar sendo sendo disponível para o usuário final Então esse tipo de requisito não funcional ele considera fortemente uso de cópia

de segurança redundância espelhamento de dados e outros recursos de forma que caso um servidor caia por exemplo outro servidor com todas as informações espelhadas assuma imediatamente ã então a medida de sucesso para esse tipo de requisito considera algumas eh algumas características como tempo médio entre falhas ou medium time between failures mtbf eh não somente a frequência dos erros mas também o nível de gravidade certo então quanto maior o tempo médio entre falhas maior o nível de sucesso do sistema o tempo de médio de reparo ou mttr medium time to repair que mede a quão rápido

o sistema se recupera degradação a Mena ou graceful degradation que determina a capacidade do software continuar funcionando mesmo que algum recurso se torne indisponível ã isso também inclui a capacidade de repor esse recurso utilizando utilizando outros recursos redundantes Ah nós temos requisito não não funcional de performance ou seja desempenho então ele também define necessidades de hardware basicamente desempenho identifica o tempo de resposta do software existem alguns softwares que precisam ter um tempo de resposta muito rápido como sistemas de tempo real e outros nem tanto Então esse requisito não funcional ele também dá ênfase nas necessidades

de hardware Já que é preciso haver um grande poder de processamento uma grande capacidade de memória um grande poder de armazenamento para atender as necessidades de alguns softwares mais complexos e que exigem um nível de desempenho muito alto então isso também às vezes muitas vezes implica adquirir software auxiliar outras ferramentas de software e também é necessário investir bastante em redundância e espelhamento de recursos e nós temos requisito de supportability ou suportabilidade que na verdade abrange diversos requisitos não funcionais que estão interrelacionados com manutenibilidade e evolução compatibilidade reusabilidade adaptabilidade instalab bilidade escalabilidade configur abilidade e testabilidade

Ah então com relação à manutenibilidade e evolução basicamente determina quão fácil de manter e evoluir um software deve ser preferencialmente um software deve ser o mais fácil de manter e evoluir possível às vezes nem sempre isso é possível de atender porque às vezes eh esse requisito não funcional pode entrar em conflito com outros requisitos como requisito às vezes de desempenho que pode não favorecer a manutenibilidade mas de qualquer maneira um software com alta capacidade de manter e evoluir ele precisa ser bem documentado precisa ter uma forte documentação uma especificação de requisitos detalhada ã modelos uml

que que ajuda a entender o a complexidade do software modelos de caso de uso modelos de classe modelo de sequência esse tipo de coisa e ele deve ser construído deve ser desenvolvido utilizando padrões e Convenções de codificação ã de tal forma que seja possível modificá-lo facilmente e também adicionar novas funcionalidades evoluir o software no futuro ainda com relação à manutenibilidade e evolução ã o requisito não funcional de manutenibilidade é bastante importante Principalmente quando se sabe que o software poderá ter muitas versões o que acontece com bastante frequência ou ainda que os seus requisitos funcionais eles

poderão sofrer alterações frequentes às vezes até ainda durante o desenvolvimento do software já um software mais estável eh o que não é tão comum eh ele não precisa se preocupar tanto em atender a esse requisito não funcional mas na verdade eu não acredito muito nesse tipo de de software a maioria dos softwares irá sofrer evolução um software que não não não não sofre evolução normalmente é um software que não está sendo muito utilizado pela empresa e nós temos o requisito de reusabilidade que basicamente a capacidade de eu reutilizar software que já foi Pronto já já

foi desenvolvido anteriormente ou adquirir módulos componentes de software de outros fabricantes ou gratuitamente pela internet eh então isso permite o desenvolvimento do produto mais rápido e nós temos requisitos de instabilidade que como o nome já diz é a facilidade que um usuário tem de instalar um software normalmente quanto mais fácil de instalar melhor mas existem situações quando o software se destina a usuários com pouco conhecimento técnico que o grau de instabilidade deve ser alto caso contrário ele simplesmente não vai poder ser instalado pelo pela maioria dos usuários a que ele se destinam então ele acaba

não sendo útil os usuários precisam ser capazes de instalar o software sem grandes dificuldades e nós temos um requisito ã associado que é o de configur bilidade que é a capacidade que o usuário tem de poder configurar e customizar o software e da mesma forma que o requisito de instal idade o software deve ser pensado de tal maneira que ele possa ser facilmente configurado Principalmente quando se tratar quando se o público alvo for um conjunto de usuários Possivelmente com pouco conhecimento técnico então se o software for difícil de configurar eles não vão configurar o software

por falta de conhecimento temos ainda o requisito de compatibilidade basicamente ele determina ativo o produto deve ser Ou seja que H que o software seja executado sobre o maior número possível de hardwares e softwares que ele possa rudar em mú múltiplas plataformas e que ele não entre em conflito com outros softwares e ou hardwares eh do ambiente que ele vai eh ser executado existe o requisito de adaptabilidade que determina com adaptável software deveria ser então isso se refere à capacidade de um software de se adaptar a vários Ambientes diferentes por exemplo no caso dele ser

portável ã então sem ser necessária qualquer ação do usuário então existem softwares que se que são bastante portáveis que são bastante adaptáveis que podem rodar em múltiplas plataformas e existem outros softwares que não que eles são nativos de por exemplo uma plataforma específica um sistema operacional específico então eles só rodam naquele ambiente específico Ahã e existe ainda o requisito não funcional de escalabilidade que diz respeito à capacidade do software eh evoluir em termos de passar a suportar um número maior de usuários o número maior de solicitações número maior de recursos do que ele foi projetado

inicialmente então a capacidade do do software passar a atender mais pedidos mais usuários a capacidade que ele tem de eh crescer em termos de poder atender mais eh pessoas mais usuários Ah então a a escalabilidade implica a capacidade do software de continuar executando de maneira transparente mesmo quando novos recursos de hardware e o software forem adicionados na verdade isso se confunde um pouco com requisito não funcional de confiabilidade também isso é necessário para permitir o aumento das demandas dos usuários tá então no momento que eu quero que o meu software atenda mais usuários permita a

solicitação de mais recursos eu tenho que ser capaz de adicionar mais hardware eventualmente mais software para permitir ISO então o software tem que ser suficientemente escalável para permitir a adição de novo hardware de novo software de preferência de forma transparente para os usuários e nós temos requisito não funcional de testabilidade que como o nome já diz o intuitivamente nós sabemos que a capacidade de que eu tenho de testar o meu software então quanto mais testes possíveis eu puder executar sobre o software melhor Eh claro que quanto maior o risco que o software traz consigo maior

o nível de teste que eu tenho que aplicar a ele então quando se trata de software dos quais dependem vidas humanas que exige um grande grau de proteção de segurança que pode causar grandes tragédias ecológicas ou grandes prejuízos econômicos Então os níveis de teste e a preocupação com os resultados muito exatos então ele precisa ser muito alto ah e o mais finalmente ele leva a consideração outros requisitos não previstos como por exemplo exemplo requisitos de projeto que podem impor o uso de um determinado processo de desenvolvimento um determinado padrão de codificação ou padrão de documentação

ou ainda estabelecer eh que o software deverá rodar em um determinado ambiente sobre um determinado sistema operacional utilizar uma linguagem de programação específica um ambiente de desenvolvimento específico um sistema gerenciador de banto de dados específico entre outras restrições possíveis H na verdade esses últimos aí se confundem com requisitos de implementação que estabelece justamente isso o uso de uma determinada linguagem ou do sistema gerenciador de banco de dados ã e nós temos requisitos físicos que estabelecem Qual o hardware necessário para que o software seja executado onde as suas informações serão armazenadas onde Elas serão mantidas o

tipo de topologia de rede que será necessário onde o software deverá ser eh transmitir informações esse tipo de coisa ainda nós temos requisitos de interface com outros softwares isso não se trata de interface humano computador em sim forma de comunicação lógica entre o software que estamos desenvolvendo e outros softwares integrados por exemplo e existe os requisitos legais que precisam ser obedecidos como leis normas entre outras características normativas que estabeleçam requisitos não aliás estabeleçam normas de negócio que precisam ser eh obedecidas pelas funcionalidades do software e é isso nós terminamos a classificação furps mais eu espero

que essa aula tenha sido considerada útil por vocês se vocês gostaram desse vídeo eu peço que compartilhe com que possa ter interesse curtam a esse vídeo e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas