Conforme visto no post anterior, requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003).
Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).
Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.
Requisitos Funcionais:
Os requisitos funcionais tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001).
Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais, normalmente subdivididos como (SOMERVILLE, 2001):
- Requisitos Funcionais de Usuário: Normalmente descritos de um modo geral;
- Requisitos Funcionais de Sistema: Descrevem a função de sistema detalhadamente, suas entradas, saídas e exceções.
A especificação de requisitos funcionais deve ser completa e consistente. Isto consiste em deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, não devem ter definições contraditórias.
Requisitos Não Funcionais:
Os requisitos não funcionais dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, padrões, etc. (PRESSMAN, 2001).
Isto é, são aqueles requisitos que não dizem respeito às funções específicas fornecidas pelo sistema. Logo, estão diretamente relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço em disco. Podem definir restrições para o sistema, como a capacidade de dispositivos de entrada e saída relacionados e as representações de dados utilizados em um padrão de interface.
Contudo, requisitos não funcionais também dizem respeito ao sistema como um todo e não a características individuais do sistema. Em razão disso, podemos considerá-los mais importantes que requisitos funcionais individuais. Além disso, se houver falhas ao cumprir um requisito não funcional poderá tornar todo o sistema inútil.
Os requisitos funcionais normalmente surgem conforme a necessidade de usuários, de restrições de orçamentos, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas ou devido a fatores externos, como regulamentações ou legislação, por exemplo. Assim, podemos classificar os requisitos não funcionais de diversas formas para poder organizá-los (SOMMERVILLE, 2003):
- Requisitos de Produto
---------- Requisitos de Facilidade de Uso;
---------- Requisitos de Eficiência;
-------------------- Requisitos de Desempenho;
-------------------- Requisitos de Espaço;
---------- Requisitos de Confiabilidade;
---------- Requisitos de Portabilidade;
- Requisitos Organizacionais;
---------- Requisitos de Entrega;
---------- Requisitos de Implementação;
---------- Requisitos de Padrões;
- Requisitos Externos;
---------- Requisitos de Interoperabilidade;
---------- Requisitos Éticos;
---------- Requisitos Legais;
-------------------- Requisitos de Privacidade;
-------------------- Requisitos de Segurança;
Requisitos de Domínio:
Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).
Se estes requisitos não forem atendidos satisfatoriamente, poderá ser impossível fazer a aplicação operar adequadamente.
Referências Bibliográficas
PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).
Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.
Requisitos Funcionais:
Os requisitos funcionais tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001).
Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais, normalmente subdivididos como (SOMERVILLE, 2001):
- Requisitos Funcionais de Usuário: Normalmente descritos de um modo geral;
- Requisitos Funcionais de Sistema: Descrevem a função de sistema detalhadamente, suas entradas, saídas e exceções.
A especificação de requisitos funcionais deve ser completa e consistente. Isto consiste em deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, não devem ter definições contraditórias.
Requisitos Não Funcionais:
Os requisitos não funcionais dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, padrões, etc. (PRESSMAN, 2001).
Isto é, são aqueles requisitos que não dizem respeito às funções específicas fornecidas pelo sistema. Logo, estão diretamente relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço em disco. Podem definir restrições para o sistema, como a capacidade de dispositivos de entrada e saída relacionados e as representações de dados utilizados em um padrão de interface.
Contudo, requisitos não funcionais também dizem respeito ao sistema como um todo e não a características individuais do sistema. Em razão disso, podemos considerá-los mais importantes que requisitos funcionais individuais. Além disso, se houver falhas ao cumprir um requisito não funcional poderá tornar todo o sistema inútil.
Os requisitos funcionais normalmente surgem conforme a necessidade de usuários, de restrições de orçamentos, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas ou devido a fatores externos, como regulamentações ou legislação, por exemplo. Assim, podemos classificar os requisitos não funcionais de diversas formas para poder organizá-los (SOMMERVILLE, 2003):
- Requisitos de Produto
---------- Requisitos de Facilidade de Uso;
---------- Requisitos de Eficiência;
-------------------- Requisitos de Desempenho;
-------------------- Requisitos de Espaço;
---------- Requisitos de Confiabilidade;
---------- Requisitos de Portabilidade;
- Requisitos Organizacionais;
---------- Requisitos de Entrega;
---------- Requisitos de Implementação;
---------- Requisitos de Padrões;
- Requisitos Externos;
---------- Requisitos de Interoperabilidade;
---------- Requisitos Éticos;
---------- Requisitos Legais;
-------------------- Requisitos de Privacidade;
-------------------- Requisitos de Segurança;
Requisitos de Domínio:
Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).
Se estes requisitos não forem atendidos satisfatoriamente, poderá ser impossível fazer a aplicação operar adequadamente.
Referências Bibliográficas
PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Caro Marcelo.
ResponderExcluirEste material postado é preciso nos termos porém não extenso nas explicações o que torna instigante a busca de mais conhecimentos.
Como não tenho conhecimento prático sobre estas questões, apenas em trabalhos da Faculdade, confesso-te que irei buscar aprofundar os tópicos aqui relatados afim de agregar mais conhecimentos, obrigado pelo post.
Thiago Corrêa
Olá, Thiago.
ResponderExcluirVisando ser mais prático e menos conceitual. podes compreender requisitos de software da seguinte forma:
Requisito Funcionais: O que o software tem que fazer, na prática, para atender à necessidade do usuário? Por exemplo, "Cadastro de usuários", "Salvar relatório em arquivo digital", "Permitir busca de alunos pelo nome". São todos requisitos funcionais;
Não-Funcionais: o que é necessário ter no software para que ele atenda os requisitos funcionais sem restrições? Por exemplo, "a interface precisa ser web". "O sistema deve rodar em qualquer plataforma, windows ou linux". "A arquitetura precisa ser em 3 camadas (Client, Server e Banco de Dados)". Todos estes exemplos são enquadrados como requisitos não funcionais;
Requisitos de Domínio: podem ser requisitos funcionais ou não. Por exemplo, você tem uma biblioteca (DLL) que integra dados cadastrais de alunos via webservice, desenvolvida em .NET e que precisa do framework instalado para funcionar. A necessidade do framework é um requisito não funcional, mas pode ser enquadrado como um requisito de domínio, pois sem ele a aplicação simplesmente não funciona.
Espero ter lhe ajudado a esclarecer um pouco mais sobre o que são requisitos de software e suas diferenças.
Abraço,
Marcelo Schumacher
Este comentário foi removido por um administrador do blog.
ResponderExcluirPrezado.
ResponderExcluirA intenção é citar o autor do conteúdo, dar o crédito para a pessoa certa, independente de em qual página o autor escreveu. Só para esclarecer a intenção a você.