Olá!
Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software:
Vamos começar pela sigla FURPS: o que significa cada uma dessas letras?
Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema.
Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário.
Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema.
Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema.
Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema.
As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não antes de elucidarmos alguns conceitos:
____________________________________________________________
O que é um Requisito Funcional?
Em Engenharia de Software, um requerimento funcional define uma função do software. Uma função é descrita como um conjunto de entradas, comportamento e saídas.
Requisito Funcional pode ser um cálculo, detalhes técnicos, manipulação de dados, processamento e outras funcionalidades que definem o que um sistema deve fazer.
O que é um Requisito Não-Funcional?
Requisito não-funcional, por sua vez, é um requerimento que especifica critérios que podem ser usados no modo em que um sistema opera, e não em comportamentos específicos do mesmo.
De maneira geral, requisitos funcionais especificam O QUE um sistema deve FAZER. Enquanto requisistos não-funcionais especificam COMO um sistema deve SER.
____________________________________________________________
FURPS em detalhes
Functionality
Com os conceitos acima assimilados, podemos dizer que o F representa todos os requisitos funcionais de um sistema os quais, teoricamente, deveriam estar documentados.
É a parte que mais está ligada com as regras de negócio – conjunto de diretrizes que determinam como determinado negócio deve funcionar – de um produto, pois representam a implementação das mesmas.
Usability
Usabilidade inclui a parte visual de um sistema, a facilidade de interagir com o mesmo, a intuitividade. A parte de acessibilidade também está presente no conceito de Usabilidade, assim como a parte estética e cosmética da aplicação em questão. Uma imagem que não é carregada corretamente em um website, pode ser definida como uma erro de usabilidade.
Reliability
A Confiabilidade de um sistema reside em aspectos como disponibilidade (dependendo do sistema a disponibilidade deve ser 24x7), exatidão e poder de recuperação após falhas, talvez a mais importante, pois todo o sistema, mesmo aqueles mais próximos de serem inertes a falhas, devem ter poder de recuperação imediato após uma falha crítica. De outra forma, o sistema ficaria indisponível por tempo indeterminado, causando transtorno aos seus usuários finais.
Performance
Esse assunto vai permear muito de nossos posts. Performance está diretamente ligada a tempos de respostas de um sistema e quanto tal sistema suporta de carga de dados e também de usuários e suas ações. É um assunto muito vasto e amplamente discutido em testes. Testes de performance avaliam diversas capacidades de um sistema, dentre elas avalia se um sistema está lento ou está respondendo satisfatoriamente os usuários finais.
Supportability
Como o nome já diz, suportabilidade consiste em quão prático é o processo de suporte de um sistema. Por exemplo, possibilidade de testes no sistema, adaptabilidade, facilidade de manutenção do sistema, compatibilidade e portabilidade, facilidade de configuração e customização, entre outros.
Podemos que ressaltar que o F é a única letra que representa requisitos funcionais. As demais letras representam requisitos não-funcionais.
Lembramos também que existe um conceito ainda mais complexo que ilustra atributos de qualidade de um software. Tal conceito denomina-se FURPS+. Vamos deixar o + para um próximo post.
Até a próxima!
PS.: Listei duas leituras bem interessantes nas quais me inspirei pra escrever o artigo. Ambas estão em inglês:
Capturing Architectural Requirements
What, no supplementary specification?
Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software:
Vamos começar pela sigla FURPS: o que significa cada uma dessas letras?
Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema.
Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário.
Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema.
Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema.
Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema.
As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não antes de elucidarmos alguns conceitos:
____________________________________________________________
O que é um Requisito Funcional?
Em Engenharia de Software, um requerimento funcional define uma função do software. Uma função é descrita como um conjunto de entradas, comportamento e saídas.
Requisito Funcional pode ser um cálculo, detalhes técnicos, manipulação de dados, processamento e outras funcionalidades que definem o que um sistema deve fazer.
O que é um Requisito Não-Funcional?
Requisito não-funcional, por sua vez, é um requerimento que especifica critérios que podem ser usados no modo em que um sistema opera, e não em comportamentos específicos do mesmo.
De maneira geral, requisitos funcionais especificam O QUE um sistema deve FAZER. Enquanto requisistos não-funcionais especificam COMO um sistema deve SER.
____________________________________________________________
FURPS em detalhes
Functionality
Com os conceitos acima assimilados, podemos dizer que o F representa todos os requisitos funcionais de um sistema os quais, teoricamente, deveriam estar documentados.
É a parte que mais está ligada com as regras de negócio – conjunto de diretrizes que determinam como determinado negócio deve funcionar – de um produto, pois representam a implementação das mesmas.
Usability
Usabilidade inclui a parte visual de um sistema, a facilidade de interagir com o mesmo, a intuitividade. A parte de acessibilidade também está presente no conceito de Usabilidade, assim como a parte estética e cosmética da aplicação em questão. Uma imagem que não é carregada corretamente em um website, pode ser definida como uma erro de usabilidade.
Reliability
A Confiabilidade de um sistema reside em aspectos como disponibilidade (dependendo do sistema a disponibilidade deve ser 24x7), exatidão e poder de recuperação após falhas, talvez a mais importante, pois todo o sistema, mesmo aqueles mais próximos de serem inertes a falhas, devem ter poder de recuperação imediato após uma falha crítica. De outra forma, o sistema ficaria indisponível por tempo indeterminado, causando transtorno aos seus usuários finais.
Performance
Esse assunto vai permear muito de nossos posts. Performance está diretamente ligada a tempos de respostas de um sistema e quanto tal sistema suporta de carga de dados e também de usuários e suas ações. É um assunto muito vasto e amplamente discutido em testes. Testes de performance avaliam diversas capacidades de um sistema, dentre elas avalia se um sistema está lento ou está respondendo satisfatoriamente os usuários finais.
Supportability
Como o nome já diz, suportabilidade consiste em quão prático é o processo de suporte de um sistema. Por exemplo, possibilidade de testes no sistema, adaptabilidade, facilidade de manutenção do sistema, compatibilidade e portabilidade, facilidade de configuração e customização, entre outros.
Podemos que ressaltar que o F é a única letra que representa requisitos funcionais. As demais letras representam requisitos não-funcionais.
Lembramos também que existe um conceito ainda mais complexo que ilustra atributos de qualidade de um software. Tal conceito denomina-se FURPS+. Vamos deixar o + para um próximo post.
Até a próxima!
PS.: Listei duas leituras bem interessantes nas quais me inspirei pra escrever o artigo. Ambas estão em inglês:
Capturing Architectural Requirements
What, no supplementary specification?
Muito bom!
ResponderExcluir