Requisitos funcionais descrevem os comportamentos (funções ou serviços) do sistema que suporta objetivos do usuário, tarefas ou atividades [MAL2001].

Enquanto várias dos requisitos funcionais serão documentados em Casos de Uso, existem alguns requisitos funcionais que não podem ser aplicados a casos de uso específicos.  Por exemplo, relatar, auditar, imprimir, segurança, reforço/suporte de licenciamento, requisitos de autenticação, etc.  Tais requisitos funcionais devem ser documentados em a Especificação Suplementar.  

Se existir um número significativo de requisitos funcionais de sistema inteiro, é importante pensar um pouco na organização dessa seção.  Uma organização típica é configurada recurso/recurso, mas os métodos da organização alternativa também são possíveis.  Por exemplo, organização por usuário ou organização por sistema, também pode ser apropriado.

Requisitos funcionais representam o 'F' em "FURPS+.  Para obter informações adicionais sobre "FURPS+", consulte Conceito: Requisitos.

Requisitos não funcionais incluem ambas as qualidades e restrições [MAL2001].  Nesta etapa In discutiremos as qualidades.  Restrições serão endereçadas em uma etapa separada.

Qualidades do [Sistema] são propriedades ou características do sistema com as quais seus envolvidos se preocupam e que , portanto, afetarão o seu grau de satisfação com o sistema. [MAL2001]

Qualidades representam o "URPS" em "FURPS+".  As preocupações de cada uma dessas categorias de requisitos são conforme a seguir:

• Funcionabilidade:  Estética e consistência na interface com o usuário.
• Confiabilidade:  Disponibilidade (a quantidade do sistema "funcionando apropriadamente"), exatidão dos cálculos do sistema e a capacidade de recuperação do sistema após falhas.
• Desempenho: Rendimento do processamento, tempo de resposta, tempo de recuperação, tempo de inicialização e tempo de encerramento.
• Suportabilidade: Possibilidade de teste, adaptabilidade, sustentabilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade e possibilidade de localização.

Para obter informações adicionais sobre "FURPS+", assim como capturar requisitos não funcionais, consulte Conceito: Requisitos.

Dependendo do número de qualidades a serem documentadas para o sistema, você pode desejar fornecer subseções para cada um desses tipos de qualidade.

As seguintes seções fornecem alguns exemplos dos tipos de informações que você pode desejar capturar para cada uma dessas qualidades:

Usabilidade

Ao descrever os requisitos de utilidade, você pode desejar especificar:

• O tempo de treinamento requerido para usuários normais e usuários avançados, para tornarem-se produtivos nas operações específicas
• Tempos de tarefas mensuráveis para tarefas típicas
• Requisitos para a conformidade com os padrões de utilização, por exemplo, padrões CUA da IBM ou padrões da GUI da Microsoft

Confiabilidade

Ao descrever os requisitos de confiabilidade, você pode desejar especificar:

• Disponibilidade - especifique o percentual de tempo disponível ( xx.xx%), horas de uso, acesso de manutenção, operações de modo degradado e similares.
• MTBF (Mean Time Between Failures) – isso é especificado normalmente em horas, mas pode também ser especificado em termos de dias, meses ou anos.
• MTTR (Mean Time To Repair) – por quanto tempo o sistema pode ficar fora de operação depois de ter falhado?
• Exatidão – especificar precisão (resolução) e exatidão (por algum padrão conhecido), que são requeridas na saída dos sistemas.
• Erros máximos ou taxa de defeito – normalmente expressos em termos de erros/KLOC (milhares de linhas de código) ou erros/ponto da função.
• Erros ou taxa de defeito – categorizados em termos de erros secundários, significativos e críticos: o(s) requisito(s) deve(m) definir o que significa um erro "crítico"; por exemplo, perda total de dados ou completa incapacidade para utilizar determinadas partes da funcionalidade do sistema.

Desempenho

Ao descrever os requisitos de desempenho, você pode desejar especificar:

• Tempo de resposta para uma transação (médio, máximo)
• Rendimento do processamento (por exemplo, transações por segundo)
• Competência (por exemplo, o número de clientes ou de transações que o sistema pode acomodar)
• Modos de degradação (qual é o modo de operação aceitável quando o sistema foi degradado de alguma maneira)
• Uso do recurso: memória, disco, comunicações e assim por diante

Ao documentar os requisitos de desempenho, assegure-se de incluir os tempos de resposta específicos. Onde aplicável, faça referência relacionada aos Casos de Uso, por nome.

Suportabilidade

Ao descrever os requisitos de suportabilidade, você pode desejar especificar:

• Padrões de codificação
• Convenções de nomenclatura
• Bibliotecas de classes
• Acesso de manutenção
• Utilitários de Manutenção

Nesta etapa você documenta qualquer restrição de design no sistema sendo construído. Em termos gerais, uma restrição é uma limitação no grau de liberdade que temos em fornecer uma solução [LEF2000].  Restrições de design representam decisões de design mandatórias e às quais devemos aderir. 

Uma Restrição representa o '+' em "FURPS+" e pode ser categorizado mais adiante, como segue:

• Restrição de design: Especifica ou restringe as opções para a arquitetura e/ou o design de um sistema. Por exemplo, requerer que um banco de dados relacional seja utilizado para persistência.
• Restrição implementação: Especifica ou restringe a codificação ou construção de um sistema. Por exemplo, padrões requeridos, processos, ferramentas, idiomas de implementação, plataformas de hardware, sistemas operacionais, componentes de terceiras partes, bibliotecas de classes e limites de recursos (uso da memória ou do espaço em disco).
• Restrição de interface: Especifica um item externo com o qual um sistema deve interagir ou restrições em formatos ou outros fatores utilizados dentro de tal interação.  Por exemplo, efetuar interface com um sistema externo através de filas de mensagens.
• Restrição Física: Especifica a restrição física imposta no hardware utilizado para hospedar o sistema — shape, tamanho ou peso, por exemplo.

Dependendo do número de restrições a serem documentadas para o sistema, você pode desejar fornecer subseções para cada um desses tipos de restrição. Adicionalmente:

• Se os requisitos incluírem a compra de componentes de terceiras partes, esteja certo de documentar qualquer licenciamento aplicável ou restrição de utilização e qualquer compatibilidade/interoperabilidade associada ou padrões de interface. É recomendada uma sessão separada por componente comprado.
• Se os requisitos incluírem requisitos de interface específicos, é recomendado que você forneça sessões separadas para os diferentes tipos de interfaces (por exemplo, usuário, hardware, software). Para cada interface, assegure-se de incluir a especificidade adequada, protocolos, portas e endereços lógicos, e assim por diante, de maneira que o software possa ser desenvolvido e verificado contra os requisitos da interface. Especificamente:
  • Para interfaces do usuário, descreva as interfaces do usuário que devem ser implementadas pelo software.
  • Para interfaces de hardware, inclua a estrutura lógica, endereços físicos, comportamento esperado, e assim por diante.
  • Para interfaces de software, inclua uma descrição das interfaces para outros componentes do sistema de software. Esses podem ser componentes comprados, componentes reutilizados de um outro aplicativo ou componentes sendo desenvolvidos para subsistemas fora do escopo desse sistema, mas com os quais esse aplicativo de software deve interagir.

Para obter informações adicionais sobre "FURPS+", assim como capturar restrições, consulte Conceito: Requisitos.

Por conformidade, incluímos conformidade de padrões ( incluído padrões regulatórios, padrões de codificação ou guias de estilo de interface com o usuário), assim como avisos de isenção legais, garantias, avisos de direitos autorais, avisos de patente, marcas, marcas registradas e/ou conformidade de logotipo.

Requisitos de conformidade podem ser realizados em termos de outros requisitos (funcionais, não funcionais e restrições).  Nesses casos, os detalhes daqueles requisitos devem ser documentados nas sessões aplicáveis da Especificação Suplementar, conforme descrito nas etapas anteriores.  No entanto, é importante resumir os padrões e políticas com os quais o sistema deve estar em conformidade.  Os requisitos de conformidade resultantes devem se referir aos requisitos detalhados aplicáveis, conforme necessário.

Dependendo do número de requisitos de conformidade a serem documentados para o sistema, você pode desejar fornecer subseções para os diferentes tipos de conformidade que afetem o sistema.

As seguintes seções fornecem alguns exemplos dos tipos de informações que você pode desejar capturar para diferentes tipos de conformidade:

Requisitos de Licenciamento

Definir qualquer requisito de reforço de licenciamento ou outro requisito de restrição de uso que esteja para ser exibido pelo software.

Jurídico, Copyright e Outros Avisos

Descrever qualquer aviso de isenção, garantia, aviso de copyright, aviso de patente, marca, marca comercial ou problema de conformidade com o logotipo para o software.

Padrões Aplicáveis

Descrever (por referência) qualquer padrão aplicável e as sessões específicas desse tal padrão que se aplique ao sistema sendo descrito. Por exemplo, isso pode incluir padrões legais, de qualidade, de indústria para aplicação, interoperabilidade, internacionalização, conformidade do sistema operacional, e assim por diante.

Nessa etapa, você descreve os requisitos, se houver algum, para a documentação. Os requisitos de documentação devem incluir os requisitos para ajuda on-line, assim como a documentação do usuário final (por exemplo, guias de instalação, guias do usuário, material de treinamento, etc.).  

À semelhança dos requisitos de conformidade, os requisitos de documentação conduzem outros tipos de requisitos. Especificamente requisitos funcionais (o sistema deve fornecer acesso funcional de suporte para a ajuda on-line), bem como requisitos de utilidade (o acesso on demand para informações de uso do sistema suporta a utilidade geral do sistema). 

Assim, como os requisitos de conformidade, requisitos detalhados que suportam requisitos de documentação devem ser documentados nas seções aplicáveis da Especificação Suplementar, conforme descrito nas etapas anteriores; mas também é importante documentar e resumir os requisitos de documentação geral para o sistema. Os requisitos resultantes devem se referir aos requisitos detalhados aplicáveis.

Dependendo do número de requisitos de documentação do sistema, poderá ser necessário fornecer subseções para os diferentes tipos de documentação a serem fornecidas para o sistema.