Introdução
Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou não.
Requisitos Não Funcionais e Arquitetura de Software
O projeto de arquitetura de software tem um papel essencial em sistemas de grande porte e complexos. A arquitetura de software é fundamental para a produção de sistemas onde se tem um conjunto de funcionalidades. Entretanto anterior a fase de projeto há a necessidade de fazer o levantamento de requisitos.
O conjunto de requisitos de um sistema é definido durante as fases iniciais do processo de desenvolvimento. Tal conjunto é visto como uma especificação do que deveria ser implementado.
Durante a fase de levantamento de requisitos um arquiteto de software faz uso da sua experiência a fim de levantar características do sistemas a ser desenvolvido. Contudo há ainda outros recursos a serem usados pelo projestita, como a construção de cenários, que auxiliam tanto na elicitação de requisitos como na analise dos mesmos. É importante observar que o uso de cenários de e uma re-análise do requisitos é útil para refinar a arquitetura que será empregada no sistema a ser desenvolvido.
De posse desses requisitos o arquiteto de software pode então buscar e identificar qual o melhor estilo ou combinação destes oferece o suporte mais adequado a esses requisitos.
Vale ressaltar que a complexidade de um software é determinada tanto pelos seus requisitos funcionais – o que ele faz – e seus requisitos não funcionais – como ele faz.
Na Engenharia de Sistemas de Software são aqueles que descrevem não o que o sistema fará, mas sim como ele fará. Como por exemplo requisitos de desempenho, requisitos da interface externa do sistema restrições de projeto e atributos de qualidade.
Os requisitos são avaliados, em parte, por meio de testes e em outras partes é avaliado de maneira subjetiva.
Os requisitos não funcionais são de suma importância no desenvolvimento de um software, esses requisitos também são chamados de atributos de qualidade e tem papael relevante no desenvolvimento de um sistema atuando como critério de seleção e/ou composição de uma arquitetura de software.
Requisitos Não Funcionais
O requisitos não funcionais não estão diretamente relacionados às funcionalidades do sistema, mas sim relacionados a um processo de qualidade do sistema a ser desenvolvido, podendo ser usados como critério de seleção na escolha de alternativas de projeto, estilo arquitetural e implementação. Desconsiderar tais requisitos é dispendioso, pois torna a correção difícil uma vez que o sistema tenha sido implantado.
Os requisitos abordam um aspecto de qualidade. Se tais requisitos não forem levados em consideração, então o sistema poderá ser inconsistente e de baixa qualidade.
Ao se desenvolver um novo sistema, os projetistas apresentam um conjunto de atributos de qualidade ou requisitos não funcionais que o sistema deveria suportar, como por exemplo requisitos de desempenho, portabilidade, manutenibilidade e escaliabilidade. É importante lembrar que cada estilo arquitetural suporta requisitos não funcionais especifícos. A estruturação e um fator determinante no suporte à esses requisitos. Por exemplo o uso de camadas para separar funcionalidades torna o sistema modular e facilita sua manutenção.
O padrão IEEE-Std 830 [IEEE 1993] (http://www.scribd.com/doc/453557/ieee830Traducao) lista um conjunto de 13 requisitos não funcionais a serem considerados no desenvolvimento de um software. O Padrão inclui, desempenho, confiabilidade, portabilidade e segurança, dentre outros.
Em, [Sommerville 2007] é apresentado um conjunto de 7 requisitos não funcionais, sendo alguns destes ainda decompostos, como mostra a figura abaixo:
Usabilidade
É um atributo de qualidade de qualquer sistema interativo, no qual ocorre interação entre sistema e seres humanos. A noção de usabilidade vem do fato de que qualquer sistema que é utilizado por pessoas seja fácil de aprender e fácil de usar. Requisitos de usabilidade especificam tanto o nível de desempenho quanto o nível de satisfação do usuário do sistema.
Dessa forma a usabilidade por ser expressa em:
• Facilidade de aprender – associado ao tempo e esforço mínimo exigido para alcançar determinado nível de desempenho no uso do sistema;
• Facilidade de uso – relacionado à velocidade de execução de tarefas e à redução de erros no uso o sistema;
A usabilidade é um dos atributos de qualidade que tem sido cada vez mais levada em consideração durante o desenvolvimento de um software, já que ela pode ser afetada pelos componentes funcionais (ou de aplicação). Mesmo que esses componentes sejam bem projetados a usabilidade ainda assim poderá ser comprometida se a arquitetura do sistema não levar em consideração a facilidade de efetuar uma modificação.
Manutenibilidade
É o termo empregado quando nos referimos às modificações no software após ele ter sido disponibilizado para uso. Na verdade o termo manutenibilidade é bem abrangente já que envolve tanto a parte de reparos (bugs) como também a parte de evolução do sistema(upgrade).
A capacidade de efetuar um reparo depende do número de componentes do sistema. Um sistema monolítico, ou seja, que é construído com um componente só torna se mais difícil de ser reparado quando é de grande porte. Já em um sistema modularizado esse tipo de reparo tende a ser mais fácil, já que o erro fica confinado a uns poucos módulos e com funcionalidades adequadamente separadas.
De um modo geral a manutenibilidade é um dos requisitos mais relacionados com a arquitetura do software, assim também como a facilidade de fazer alteração no sistema, seja adicionando ou modificando alguma funcionalidade sem que esta comprometa o desempenho atual do sistema em funcionamento.
Confiabilidade
Confiabilidade de software é a probabilidade de o software não causar uma falha no sistema durante um determinado período de tempo sob condições especificadas. Em outras palavras é o tempo médio em que o sistema trabalhará de forma desejada até apresentar algum tipo de erro.
Para avaliar a confiabilidade um sistema utiliza-se os seguintes critérios:
• Disponibilidade - É o quão o sistema está disponível para uso. Ex: para cada 1000 solicitações ao software, 999 serão atendidas;
• Taxa de ocorrência de falha - É o período de tempo no qual um comportamento inesperado acontece quando observado. Ex: 2/1000;
• Probabilidade de falha durante a fase operacional - É a probabilidade de falhas que um sistema pode ocasionar quando estiver em operação;
• Tempo médio até a ocorrência de falha ou Mean Time To Failure: É o indicativo de quanto tempo o sistema permanecerá operacional antes que uma falha aconteça.
Desempenho
Desempenho é um dos mais importantes requisitos não funcionais, porém ele está diretamente ligado a conflitos entre outros requisitos não funcionais, como por exemplo, a usabilidade, se um sistema de software é lento ele pode reduzir a produtividade dos funcionários fazendo com ele não atenda a necessidade proposta. Se o sistema exige muita memória ou ocupa muito espaço no HD, a execução de outros programas pode ser comprometida.
Ao desenvolver um sistema de software é necessário avaliar:
• Tempo de resposta: É o tempo em que o usuário realiza uma operação e tem o retorno disso. Ex: Quando inserimos um cartão no caixa eletrônico, é recomendável que o sistema exiba uma nova janela de operações após alguns segundo.
• Requisitos de processamento (throughput) - Representa a quantidade de dados que o sistema deveria processar em um determinado período de tempo.
• Requisitos de temporização - Especifica o quão rapidamente o sistema coletará dados e como fará para sobrescrever os dados anteriores.
• Requisitos de espaço- Em alguns casos os requisitos de espaço podem ser considerados já que estão diretamente relacionadas à execução de um sistema.
Portabilidade
Portabilidade pode ser definido como a facilidade na qual o software pode ser transferido de um sistema computacional para outro. De modo geral refere-se à habilidade do sistema de ser executado em diferentes plataformas. Com as constantes mudanças entre custos de software e hardware torna-se cada vez mais importante a avaliação de portabilidade dentro de um projeto de software, com isso além de diminuir custos ao aderir a uma nova tecnologia de desenvolvimento, o processo de transferência para outra plataforma ocorre de forma mais segura.
Reusabilidade
Com o crescente intuito de maximizar os lucros e diminuir o tempo de desenvolvimento, a reusabilidade tem sido muito utilizada. Ao invés de começar um sistema do zero, pode-se fazer o uso de projetos existentes a fim de reutilizar componentes já desenvolvidos, objetivando minimizar esforços e buscar um elevado índice de qualidade já que os recursos utilizados já foram devidamente testados e validados. Quase tudo pode ser reaproveitado dentro de um sistema, desde que o mesmo já tenha sido produzido com este intuito.
Segurança
Este requisito não funcional implica na construção de um sistema de forma que o mesmo possua restrições a usuários não autorizados e dados sigilosos. Dessa forma, a segurança é vista como a probabilidade de qualquer tipo de ameaça seja repelida. É Impossível afirmar que um sistema é cem por cento seguro, conforme as tecnologias avançam, novos métodos de invasão são descobertos, fazendo com que a segurança de um software seja por diversas vezes reavaliada. Algumas práticas ajudam na prevenção da quebra da segurança como, por exemplo:
Apenas usuários com permissões autenticadas por um componente de autenticação poderão visualizar informações confidencias;
• Permissões de acessos aos usuários somente podem ser alteradas por administradores do sistema;
• Backups do sistema devem ser feitos periodicamente, de preferência em máquinas diferentes da qual o sistema está em uso;
• Todas as informações transmitidas entre o servidor de dados e os clientes devem estar criptografadas;
• Impedir que atualizações do sistema ou liberações de acessos sejam feitas de forma não autorizada;
• Limitar o tempo de acesso ao sistema pelo usuário, a fim de reduzir qualquer tipo de acesso;
• Logs de realizações de eventos no sistema, com isso identificar qual usuário realizou determinado processo;
• Detecção de invasores a fim de alarmar os administradores do sistema;
• Simulações de invasão;
• Antivírus atualizado;
Conclusão
A elicitação de requisitos funcionais e não funcionais, é uma etapa fundamental no desenvolvimento de sistemas de software. Aliado a isso, a experiência do arquiteto de software é de grande importância. Como saída tem-se um conjunto de requisitos funcionais dando suporte as funcionalidades do sistema e um conjunto de requisitos não funcionais dando suporte a arquitetura do software.
Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou não.
Requisitos Não Funcionais e Arquitetura de Software
O projeto de arquitetura de software tem um papel essencial em sistemas de grande porte e complexos. A arquitetura de software é fundamental para a produção de sistemas onde se tem um conjunto de funcionalidades. Entretanto anterior a fase de projeto há a necessidade de fazer o levantamento de requisitos.
O conjunto de requisitos de um sistema é definido durante as fases iniciais do processo de desenvolvimento. Tal conjunto é visto como uma especificação do que deveria ser implementado.
Durante a fase de levantamento de requisitos um arquiteto de software faz uso da sua experiência a fim de levantar características do sistemas a ser desenvolvido. Contudo há ainda outros recursos a serem usados pelo projestita, como a construção de cenários, que auxiliam tanto na elicitação de requisitos como na analise dos mesmos. É importante observar que o uso de cenários de e uma re-análise do requisitos é útil para refinar a arquitetura que será empregada no sistema a ser desenvolvido.
De posse desses requisitos o arquiteto de software pode então buscar e identificar qual o melhor estilo ou combinação destes oferece o suporte mais adequado a esses requisitos.
Vale ressaltar que a complexidade de um software é determinada tanto pelos seus requisitos funcionais – o que ele faz – e seus requisitos não funcionais – como ele faz.
Na Engenharia de Sistemas de Software são aqueles que descrevem não o que o sistema fará, mas sim como ele fará. Como por exemplo requisitos de desempenho, requisitos da interface externa do sistema restrições de projeto e atributos de qualidade.
Os requisitos são avaliados, em parte, por meio de testes e em outras partes é avaliado de maneira subjetiva.
Os requisitos não funcionais são de suma importância no desenvolvimento de um software, esses requisitos também são chamados de atributos de qualidade e tem papael relevante no desenvolvimento de um sistema atuando como critério de seleção e/ou composição de uma arquitetura de software.
Requisitos Não Funcionais
O requisitos não funcionais não estão diretamente relacionados às funcionalidades do sistema, mas sim relacionados a um processo de qualidade do sistema a ser desenvolvido, podendo ser usados como critério de seleção na escolha de alternativas de projeto, estilo arquitetural e implementação. Desconsiderar tais requisitos é dispendioso, pois torna a correção difícil uma vez que o sistema tenha sido implantado.
Os requisitos abordam um aspecto de qualidade. Se tais requisitos não forem levados em consideração, então o sistema poderá ser inconsistente e de baixa qualidade.
Ao se desenvolver um novo sistema, os projetistas apresentam um conjunto de atributos de qualidade ou requisitos não funcionais que o sistema deveria suportar, como por exemplo requisitos de desempenho, portabilidade, manutenibilidade e escaliabilidade. É importante lembrar que cada estilo arquitetural suporta requisitos não funcionais especifícos. A estruturação e um fator determinante no suporte à esses requisitos. Por exemplo o uso de camadas para separar funcionalidades torna o sistema modular e facilita sua manutenção.
O padrão IEEE-Std 830 [IEEE 1993] (http://www.scribd.com/doc/453557/ieee830Traducao) lista um conjunto de 13 requisitos não funcionais a serem considerados no desenvolvimento de um software. O Padrão inclui, desempenho, confiabilidade, portabilidade e segurança, dentre outros.
Em, [Sommerville 2007] é apresentado um conjunto de 7 requisitos não funcionais, sendo alguns destes ainda decompostos, como mostra a figura abaixo:
Usabilidade
É um atributo de qualidade de qualquer sistema interativo, no qual ocorre interação entre sistema e seres humanos. A noção de usabilidade vem do fato de que qualquer sistema que é utilizado por pessoas seja fácil de aprender e fácil de usar. Requisitos de usabilidade especificam tanto o nível de desempenho quanto o nível de satisfação do usuário do sistema.
Dessa forma a usabilidade por ser expressa em:
• Facilidade de aprender – associado ao tempo e esforço mínimo exigido para alcançar determinado nível de desempenho no uso do sistema;
• Facilidade de uso – relacionado à velocidade de execução de tarefas e à redução de erros no uso o sistema;
A usabilidade é um dos atributos de qualidade que tem sido cada vez mais levada em consideração durante o desenvolvimento de um software, já que ela pode ser afetada pelos componentes funcionais (ou de aplicação). Mesmo que esses componentes sejam bem projetados a usabilidade ainda assim poderá ser comprometida se a arquitetura do sistema não levar em consideração a facilidade de efetuar uma modificação.
Manutenibilidade
É o termo empregado quando nos referimos às modificações no software após ele ter sido disponibilizado para uso. Na verdade o termo manutenibilidade é bem abrangente já que envolve tanto a parte de reparos (bugs) como também a parte de evolução do sistema(upgrade).
A capacidade de efetuar um reparo depende do número de componentes do sistema. Um sistema monolítico, ou seja, que é construído com um componente só torna se mais difícil de ser reparado quando é de grande porte. Já em um sistema modularizado esse tipo de reparo tende a ser mais fácil, já que o erro fica confinado a uns poucos módulos e com funcionalidades adequadamente separadas.
De um modo geral a manutenibilidade é um dos requisitos mais relacionados com a arquitetura do software, assim também como a facilidade de fazer alteração no sistema, seja adicionando ou modificando alguma funcionalidade sem que esta comprometa o desempenho atual do sistema em funcionamento.
Confiabilidade
Confiabilidade de software é a probabilidade de o software não causar uma falha no sistema durante um determinado período de tempo sob condições especificadas. Em outras palavras é o tempo médio em que o sistema trabalhará de forma desejada até apresentar algum tipo de erro.
Para avaliar a confiabilidade um sistema utiliza-se os seguintes critérios:
• Disponibilidade - É o quão o sistema está disponível para uso. Ex: para cada 1000 solicitações ao software, 999 serão atendidas;
• Taxa de ocorrência de falha - É o período de tempo no qual um comportamento inesperado acontece quando observado. Ex: 2/1000;
• Probabilidade de falha durante a fase operacional - É a probabilidade de falhas que um sistema pode ocasionar quando estiver em operação;
• Tempo médio até a ocorrência de falha ou Mean Time To Failure: É o indicativo de quanto tempo o sistema permanecerá operacional antes que uma falha aconteça.
Desempenho
Desempenho é um dos mais importantes requisitos não funcionais, porém ele está diretamente ligado a conflitos entre outros requisitos não funcionais, como por exemplo, a usabilidade, se um sistema de software é lento ele pode reduzir a produtividade dos funcionários fazendo com ele não atenda a necessidade proposta. Se o sistema exige muita memória ou ocupa muito espaço no HD, a execução de outros programas pode ser comprometida.
Ao desenvolver um sistema de software é necessário avaliar:
• Tempo de resposta: É o tempo em que o usuário realiza uma operação e tem o retorno disso. Ex: Quando inserimos um cartão no caixa eletrônico, é recomendável que o sistema exiba uma nova janela de operações após alguns segundo.
• Requisitos de processamento (throughput) - Representa a quantidade de dados que o sistema deveria processar em um determinado período de tempo.
• Requisitos de temporização - Especifica o quão rapidamente o sistema coletará dados e como fará para sobrescrever os dados anteriores.
• Requisitos de espaço- Em alguns casos os requisitos de espaço podem ser considerados já que estão diretamente relacionadas à execução de um sistema.
Portabilidade
Portabilidade pode ser definido como a facilidade na qual o software pode ser transferido de um sistema computacional para outro. De modo geral refere-se à habilidade do sistema de ser executado em diferentes plataformas. Com as constantes mudanças entre custos de software e hardware torna-se cada vez mais importante a avaliação de portabilidade dentro de um projeto de software, com isso além de diminuir custos ao aderir a uma nova tecnologia de desenvolvimento, o processo de transferência para outra plataforma ocorre de forma mais segura.
Reusabilidade
Com o crescente intuito de maximizar os lucros e diminuir o tempo de desenvolvimento, a reusabilidade tem sido muito utilizada. Ao invés de começar um sistema do zero, pode-se fazer o uso de projetos existentes a fim de reutilizar componentes já desenvolvidos, objetivando minimizar esforços e buscar um elevado índice de qualidade já que os recursos utilizados já foram devidamente testados e validados. Quase tudo pode ser reaproveitado dentro de um sistema, desde que o mesmo já tenha sido produzido com este intuito.
Segurança
Este requisito não funcional implica na construção de um sistema de forma que o mesmo possua restrições a usuários não autorizados e dados sigilosos. Dessa forma, a segurança é vista como a probabilidade de qualquer tipo de ameaça seja repelida. É Impossível afirmar que um sistema é cem por cento seguro, conforme as tecnologias avançam, novos métodos de invasão são descobertos, fazendo com que a segurança de um software seja por diversas vezes reavaliada. Algumas práticas ajudam na prevenção da quebra da segurança como, por exemplo:
Apenas usuários com permissões autenticadas por um componente de autenticação poderão visualizar informações confidencias;
• Permissões de acessos aos usuários somente podem ser alteradas por administradores do sistema;
• Backups do sistema devem ser feitos periodicamente, de preferência em máquinas diferentes da qual o sistema está em uso;
• Todas as informações transmitidas entre o servidor de dados e os clientes devem estar criptografadas;
• Impedir que atualizações do sistema ou liberações de acessos sejam feitas de forma não autorizada;
• Limitar o tempo de acesso ao sistema pelo usuário, a fim de reduzir qualquer tipo de acesso;
• Logs de realizações de eventos no sistema, com isso identificar qual usuário realizou determinado processo;
• Detecção de invasores a fim de alarmar os administradores do sistema;
• Simulações de invasão;
• Antivírus atualizado;
Conclusão
A elicitação de requisitos funcionais e não funcionais, é uma etapa fundamental no desenvolvimento de sistemas de software. Aliado a isso, a experiência do arquiteto de software é de grande importância. Como saída tem-se um conjunto de requisitos funcionais dando suporte as funcionalidades do sistema e um conjunto de requisitos não funcionais dando suporte a arquitetura do software.
Seminário de Requisitos Não FuncionaisGrupo:Roberto G. de Oliveira, RA 1801276381
Adenilson B. Oliveira, RA 0850219
Nenhum comentário:
Postar um comentário