Capacidade do sistema realizar e manter seu funcionamento em circunstâncias de rotina, bem como em circunstâncias hostis e inesperadas.

Referências: [1,2,3,4,5,7]

Período de tempo que o software deverá estar disponível para os usuários.

Referências: [3,4,5,6,7]

Período de tempo necessário para retornar ao funcionamento após uma falha.

Referências: [3,5,7]

Políticas e procedimentos para recuperação de desastres naturais ou induzidos pelo homem.

Referência: [7]

Capacidade de executar perfeitamente uma tarefa conforme previamente planejado.

Exemplo: o sistema deverá apresentar uma eficácia superior a 998 para cada 1000 saques em caixas 24 horas.

Referência: [7]

Grau de exatidão ou precisão no processamento e apresentação dos resultados.

Referências: [5,7]

Referencia o número máximo de defeitos por unidade.

Exemplo: máximo de 20 defeitos por cada mil linhas

de código (KLOC).

Referência: [7]

Grau de maturidade indica o quão sólido o

software é. Pode ser avaliado principalmente pelo número de defeitos, que deve estar em declínio com o amadurecimento do software.

Referência: [3]

Capacidade de estimar a confiabilidade ou o número de defeitos latentes do produto quando ele estiver disponível para os clientes.

Exemplo: em um sistema médico, a consulta de resultados de exame precisa estar funcional 97% do tempo.

Referência: [5]

Capacidade do sistema funcionar mesmo em condições anormais.

Exemplo: o sistema médico deve permitir a consulta de prontuários locais quando perder a comunicação com o sistema central, sinalizando a situação anormal.

Referências: [3,7]

Tempo médio entre as falhas encontradas.

Referências: [5, 7]

Frequência e gravidade de falhas encontradas.

Referência: [5]

Capacidade do produto de software, sistema ou componente trocar informações com outros produtos, sistemas ou componentes e/ou realizar suas funções necessárias, mesmo compartilhando o mesmo hardware, software ou ambiente.

 Compatibilidade entre softwares, ferramentas e normas [7]

 Compatibilidade entre plataformas [7]

 Compatibilidade com ambientes operacionais [7]

Referências: [3, 5, 7]

Capacidade de um produto de software coexistir com outros produtos em ambiente comum.

Referência: [3]

Define como o sistema interage com sistemas em outras organizações.

Referências: [1, 3, 7]

Especifica detalhes sobre a interface entre diferentes sistemas ou componentes externos.

Referências: [4, 5, 6]

Restrições de formatos, tempos ou outros fatores usados por tal interação, especifica como o sistema deve interagir, quais as restrições de formatos e outros fatores para essa interação.

Exemplo: Para consultar o nome da rua por meio do

CEP, deve ser utilizada a interface CEPBusca enviando o CEP no formato #####-###.

Referência: [5]

Utilização adequada dos recursos de forma a maximizar os resultados pré-determinados.

Exemplo: o relatório é finalizado em tempo menor do que o esperado.

Referências: [1, 3, 5, 7]

Definição da capacidade atual e formas de crescimento para o sistema.

Exemplo: o cadastro de clientes deve comportar um crescimento de cem mil clientes por ano.

Referências: [6,7]

Capacidade de processamento simultâneo do sistema.

Referência: [6]

Capacidade de armazenamento do sistema (BD).

Referência: [6]

Índice ou taxa na qual o sistema deve ser capaz de executar como, por exemplo, 10 inscrições por minuto.

Referências: [5, 6, 7]

Especificar o tempo de resposta para uma solicitação.

Referências: [1, 3, 4, 5, 6, 7]

Capacidade do produto de software atender às exigências dos limites máximos de um parâmetro de produto ou sistema.

Referência: [3]

Capacidade do produto de software de usar a quantidade de recursos apropriada.

Referência: [3]

Capacidade ou facilidade do produto de software ser modificado, incluindo tanto melhorias quanto correções de defeitos e falhas.

Referências: [3, 4, 5, 7]

Capacidade do software de evitar efeitos colaterais decorrentes de modificações introduzidas.

Exemplo: número de erros decorrentes de odificações inferior a 5 para cada mil linhas de código (KLOC).

Referências: [3, 7]

Esforço necessário para diagnosticar deficiência ou causa das falhas e identificar as partes do software a serem modificadas.

Referência: [3]

Esforço necessário para modificar um software, seja removendo erros ou melhorando seu desempenho.

Exemplo: o sistema deve permitir adicionar extensões (bibliotecas) sem a necessidade de reiniciar.

Referências: [5, 6, 7]

Indica a necessidade de gerenciar falhas, como por exemplo, registrar no log as falhas ocorridas no sistema.

Referência: [7]

Indica a necessidade de controle contínuo das mudanças. Compreende a identificação da configuração, o controle das mudanças efetuadas e a rastreabilidade.

Referências: [5, 6, 7]

Possibilidade de executar determinadas operações na forma de serviços.

Exemplo: o sistema deve possuir um serviço para atualizações automáticas de versões.

Referência: [5]

Facilidade em executar testes e encontrar problemas no software.

Exemplo: o sistema deve possuir 80% de cobertura nos testes automatizados.

Referências: [3, 5, 7]

Capacidade do produto de software ser composto de componentes modulares de forma que uma mudança em um componente tenha impacto mínimo nos outros componentes.

Referência: [3]

Capacidade de um módulo ser utilizado em mais de um produto de software, ou ser utilizado como base para se desenvolver outros módulos.

Referência: [3]

Facilidade de transpor um software de um ambiente a outro.

Referências: [1,3,4,7]

Capacidade do software se adaptar a diferentes ambientes sem a necessidade de ações adicionais (configurações).

Exemplo: o sistema deve funcionar em sistemas 32 bits e 64 bits.

Referências: [3, 5]

Capacidade e esforço necessário para substituir outro software ou componente, com o mesmo propósito e mesmo ambiente.

Exemplo: as versões disponíveis para o sistema devem ser compatíveis com a versão original.

Referência: [3]

Grau de facilidade para instalar e atualizar o sistema ou parte dele.

Referências: [3,5, 6]

Grau de facilidade de utilização do software.

Referências: [1,2,3,5,7]

Extensão em que um sistema ou parte dele deve ser acessível por pessoas com certo tipo de deficiência ou outra necessidade específica.

Referências: [3,6,7]

Indica a necessidade de ajuda on-line e contextual.

Referência: [5]

Indica a necessidade de assistentes e agentes.

Referência: [5]

Diretrizes gerais aplicáveis à criação da interface do usuário. Exemplo: a interface do usuário deve ser elaborada utilizando o conceito de janelas e menus gráficos.

Referência: [5]

Diretrizes gerais aplicáveis na aparência do software.

Exemplo: utilizar fonte Ariel tamanho 12 na cor preta com fundo claro.

Referência: [3, 5]

Esforço necessário para aprender a utilizar as potencialidades oferecidas pelo sistema.

Exemplo: em um jogo infantil, haver uma apresentação inicial em que os comandos básicos são apresentados por um personagem.

Referência: [3]

Indica a facilidade com que o usuário pode compreender as funcionalidades do software e avaliar se elas podem ser usadas para satisfazer suas necessidades.

Exemplo: o sistema deve exibir tooltips sobre os menus e botões com uma breve descrição da funcionalidade.

Referência: [3]

Indica a necessidade de elaboração de manual do usuário.

Referência: [5]

Indica a necessidade de materiais de treinamento.

Referência: [5]

Especifica que o software deve acomodar múltiplas empresas e moedas ao mesmo tempo.

Referência: [6]

Especifica que um sistema deve apresentar sua interface em mais de uma língua.

Referências: [5, 6]

Atributos do software que evidenciam o esforço do usuário para sua operação e controle.

Exemplo: em um sistema para biblioteca, o empréstimo e devolução de um livro devem ser realizados em uma única janela/tela.

Referência: [3]

Capacidade do sistema proteger o usuário de cometer erros.

Referência: [3]

Especifica os requisitos de segurança.

Referências: [1,2,3,4,6,7]

Especificam os aspectos a serem contemplados para viabilizar a auditoria e controle.

Referência: [7]

Capacidade do produto de software prevenir acessos ou modificações de programas de computador ou dados

Referência: [3]

Quantidade de ações ou eventos que podem ter sua ocorrência comprovada, de modo que os eventos ou ações não possam ser contestados mais tarde, bem como registro de ações de uma entidade podendo identificar exclusivamente as ações à uma entidade.

Referência: [3]

Especifica a utilização de logs para registrar alterações no software.

Referência: [6]

Capacidade do produto de software identificar que um objeto ou recurso é realmente quem ele declara ser.

Referência: [3]

Capacidade do produto de software de garantir que os dados estarão acessíveis somente aos usuários que possuem autorização de acesso.

Referências: [3,6]

Especifica como novos usuários são registrados.

Referência: [6]

Especifica que uma pessoa deve ser autenticada para acessar áreas não públicas.

Referência: [6]

Especifica que um conjunto de usuários está autorizado ou não a fazer ou ver coisas.

Referência: [6]

Especifica que a autorização do usuário é configurável.

Referência: [6]

Especifica que uma determinada ação deve ser aprovada.

Referência: [6]

Referências: [5, 4, 7]

Indica como o sistema deverá ser instalado e acessado pela equipe de atualização.

Referência: [2]

Especifica ou restringe a construção de um sistema. Como, por exemplo, a especificação da linguagem de implementação, da arquitetura, do banco de dados, dos ambientes operacionais.

Referências: [1, 5]

Especifica as regras para criação dos backups.

Referência: [7]

Indica as restrições de banco de dados.

Referência: [4]

Especifica a movimentação ou cópia dos dados de um local para outro.

Referência: [6]

Especifica quanto tempo um dado deve ser mantido ou estar disponível para acesso.

Referência: [6]

Eestrições sobre políticas de integridade de banco de dados.

Referência: [5]

Referência: [6]

Especifica o formato e abrangência da documentação.

Referências: [6, 7]

Especificar quais requisitos externos devem ser atendidos como requisitos presentes no projeto.

Referência: [6]

Eestringe a utilização de determinada tecnologia.

Referências: [6, 7]

Restringe a utilização de determinada linguagem de implementação.

Referência: [5]

Especifica a utilização de determinado padrão.

Referências: [1, 5, 6]

Requisitos de hardware do sistema.

Referência: [2]

Requisitos específicos tendem a ser extensivas quando se trata de um sistema não trivial, por isso os requisitos devem ser organizados de uma forma simples de compreender.

Exemplo: organização por módulos.

Referência: [4]

Requisitos físicos do produto.

Exemplo: deve ser construído com material resistente a pequenas quedas (até 1 metro), com tamanho não ultrapassando 10x15 cm e peso máximo de 300 gramas.

Referência: [5]

Restrições quanto aos materiais utilizados no produto.

Referência: [5]

Restrições quanto ao formato do produto.

Referência: [5]

Restrições quanto ao tamanho do produto.

Referência: [5]

restrições quanto ao peso do produto.

Referência: [5]

Especificam as restrições de recursos como, por exemplo, velocidade do processador, memória, espaço em disco, largura de banda de rede, entre outros.

Referências: [5, 7]

Referência: [6]

Especificam quando o produto e seus documentos devem ser entregues.

Referência: [1]

Especificam limites quanto ao preço do produto.

Referência: [7]

Especifica um tipo de estrutura organizacional que o sistema deve suportar.

Exemplo: o sistema deve ser capaz de suportar múltiplas empresas simultaneamente. Cada empresa terá seus próprios empregados que utilizam o sistema. Uma instalação do sistema deverá acomodar até uma dúzia de empresas.

Referência: [6]

Devem ser seguidos para assegurar que o sistema opere de acordo com a lei.

Referência: [1]

Especifica as certificações ou padrões mínimos

exigidos para o funcionamento do sistema.

Exemplo: o sistema deve apresentar o certificado “site blindado”.

Referência: [7]

Estabelece restrições relativas à custódia

do software.

Referência: [7]

Estabelece restrições relativas à privacidade do

software.

Referências: [1, 7]

Contrato de licença de usuário final ou acordo de licença de software entre o concedente e o comprador, estabelecendo o direito do comprador de utilizar o software.

Referência: [7]

Definir que o sistema poderá ser instalado em outras empresas/filiais ou vendido.

Referência: [6]

Estabelece a necessidade de controlar a violação de patentes.

Referência: [7]

Requisitos definidos para garantir a aceitação do software pelos seus usuários e o público em geral. Exemplo: em um sistema médico, o sistema não deve apresentar aos usuários quaisquer dados de cunho privativo.

Referência: [1]