Existe um grupo finito de requisitos a serem considerados quando for feita a captura dos requisitos globais do sistema, das qualidades ou das restrições. Muitos deles são estranhos aos Analistas de Negócios e, conseqüentemente, eles podem achar difícil responder as perguntas relacionadas a tópicos tais como disponibilidade, desempenho, escalabilidade ou localização. Você pode usar esta diretriz e o Checklist: Lista de Requisitos associado quando for conversar com os Analistas de Negócios para assegurar-se de que todos os tópicos sejam discutidos. Certifique-se de que os Analistas de Negócios compreendam o custo de suas escolhas e não acabem querendo tudo o que está na lista.

Funcionais

• Auditoria: Existe a necessidade de rastrear quem usou o sistema e quando foi usado? Declare requisitos para fornecer trilhas de auditoria quando da execução do sistema.

• Autenticação: O acesso ao sistema será controlado? Declare requisitos de autenticação.

• Licenciamento: O sistema ou partes do sistema serão licenciados? Caso seja usado algum software de código livre no sistema, todos os acordos de código livre foram respeitados? Declare requisitos para adquirir, instalar, rastrear e monitorar licenças.

• Impressão: A capacidade de impressão será necessária? Declare requisitos para impressão.

• Relatórios: A capacidade de geração de informes será necessária? Declare requisitos para Relatórios.

• Agendamento: A execução de alguma ação no sistema necessita ser agendada? Declare requisitos para capacidade de agendamento.

• Segurança: Os elementos ou os dados do sistema necessitam estar seguros? Declare requisitos de proteção de acesso para determinados recursos ou informações.

Usabilidade

Os requisitos de usabilidade são críticos para o sucesso de qualquer sistema. Infelizmente, os requisitos de usabilidade são normalmente os mais mal especificados. Considere este simples requisito: O sistema deve ser fácil de usar. Ele não ajuda muito, porque não pode ser verificado.

Ao capturar requisitos de usabilidade, é uma boa idéia identificar primeiro as questões e preocupações, e então refiná-las em requisitos verificáveis posteriormente (veja Guideline: Escrevendo Bons Requisitos). De acordo com uma definição tradicional, a usabilidade consiste de cinco fatores:

• Facilidade de Aprendizagem: Um usuário com um nível especificado de experiência deve aprende como usar o sistema em um determinado prazo especificado.

• Eficiência da Tarefa: Um usuário deve poder terminar uma determinada tarefa em um prazo especificado (ou em uma quantidade de cliques do mouse).

• Facilidade de Recordação: Um usuário deve poder recordar como se realizam determinadas tarefas, após um prazo especificado de não utilização do sistema.

• Entendimento: Um usuário deve entender as mensagens e os alertas do sistema e o que o sistema faz.

• Satisfação Subjetiva: Uma porcentagem especificada da comunidade de usuários deve expressar a satisfação de usar o sistema.

Você pode querer usar o seguinte método para identificar e especificar requisitos de usabilidade:

Confiabilidade

A confiabilidade inclui a habilidade do sistema de continuar funcionando sob stress e circunstâncias adversas. No caso de uma aplicação, a confiabilidade relaciona-se à quantidade de tempo que o software fica disponível e funcionando em oposição ao tempo de indisponibilidade. Especifique níveis de aceitação da confiabilidade e também como serão medidos e avaliados. Descreva critérios de confiabilidade em termos mensuráveis. Isto é normalmente expresso como o tempo permissível entre falhas ou a taxa total de falhas permissível. Outras considerações importantes sobre confiabilidade são:

• Exatidão: Especifica requisitos para precisão (resolução) e para exatidão (por algum padrão conhecido) que são exigidos em qualquer cálculo executado ou nas saídas do sistema.

• Disponibilidade: Especifica requisitos para a porcentagem de tempo que o sistema deverá estar disponível para uso, horas de uso, acesso de manutenção e operações de modo degradado. A disponibilidade é normalmente especificada em termos de Tempo Médio Entre Falhas (MTBF).

• Recuperabilidade: Especifica requisitos para a recuperação à falhas. Isto é especificado normalmente em termos de Tempo Médio para Reparar (MTTR).

• Freqüência e Severidade das Falhas: Especifica a taxa máxima de defeitos (expressa normalmente como defeitos/KSLOC ou defeitos/ponto de função) e a severidade das falhas. A severidade pode ser categorizada em termos de defeitos pequenos, significativos e críticos. Os requisitos devem definir cada um destes termos de forma inequívoca. Por exemplo, um defeito crítico pode ser definido como um que resulta na perda de dados ou da inabilidade completa de usar determinada funcionalidade do sistema.

Desempenho

• Tempo de Resposta Especifica a quantidade de tempo disponível para o sistema para terminar tarefas e transações especificadas (médio, máximo). Use unidades de medida. Exemplos:

  • Toda interface entre um usuário e o sistema deverá terá um tempo de resposta máximo de 2 segundos.
  • O produto deve carregar os novos parâmetros de status após 5 minutos de uma mudança.
    
• Taxa de Transferência: Especifica a capacidade do sistema de suportar um determinado fluxo de informações (por exemplo, transações por segundo).
  
• Capacidade: Especifica os volumes que o produto deve tratar e as quantidades de dados armazenados pelo produto. Certifique-se que a descrição do requisito é quantificável, podendo assim ser testado. Use uma unidade de medida tal como: a quantidade de clientes ou transações que o sistema pode acomodar, uso dos recursos (memória, disco, etc) ou modos de degradação (qual é o modo de operação aceitável quando o sistema estiver degradado de alguma forma) Exemplos:
  • O produto pode atender a 300 usuários simultâneos no período de 9:00h as 11:00h.
  • A carga máxima em outros períodos será de 150.
    
• Partida: O tempo necessário para o sistema entrar em funcionamento.
  
• Parada: O tempo necessário para o sistema parar de funcionar.

Suportabilidade

• Adaptabilidade: Existe algum requisito especial que considere a adaptação do software (incluindo atualizações)? Liste os requisitos para facilidade com que o sistema se adapte a novos ambientes.

• Compatibilidade: Existe algum requisito que considere este sistema e sua compatibilidade com versões anteriores deste sistema ou de sistemas legados que fornecem a mesma capacidade?

• Configurabilidade: o produto será configurado após ter sido implantado? De que forma o sistema será configurado?

• Instalação: Declare qualquer requisito especial a respeito da instalação do sistema.

• Nível de Suporte: Qual é o nível de suporte que o produto necessita? Isto é feito normalmente usando um "Help-desk". Se for necessário existirem pessoas que forneçam suporte ao produto, esse suporte é considerado como parte do que você está fornecendo ao cliente? Existe algum requisito para esse suporte? Você pôde também construir o suporte no próprio produto, neste caso este é o lugar para escrever esses requisitos. Considere o nível de suporte que você deseja fornecer e de que forma ele pode ser obtido.
  
• Manutenção: Existe algum requisito especial que considere a manutenção do sistema? Quais são os requisitos para o ciclo de liberação desejado para o produto e a forma que a liberação irá acontecer? Quantifique o tempo necessário para fazer as mudanças especificadas para o produto. Podem também existir requisitos especiais para a manutenção, tal como um requisito onde o produto deva ser mantido por seus usuários finais ou desenvolvedores que não são da sua equipe de desenvolvimento. Isto tem um efeito na forma com que o produto é desenvolvido, e podem existir requisitos adicionais para documentação ou treinamento. Descreva o tipo de manutenção e a quantidade de esforço necessária. Exemplos:
  
• • Uma nova estação de tempo deve ser adicionada ao sistema durante a noite.
  • As liberações de manutenção serão oferecidas aos usuários finais uma vez ao ano.
    
• Escalabilidade: Qual o volume de usuários e dados o sistema irá suportar? Especifica o crescimento previsto que o produto deve suportar à medida que os negócios cresçam (ou que se espera que cresçam), os produtos de software devem aumentar suas capacidades para lidar com novos volumes. Isto pode ser expresso como uma tendência no tempo.
  
• Testabilidade: Existe algum requisito especial a respeito da testabilidade do sistema?

Restrições (+)

• Restrições de Design: Existe alguma decisão de design obrigatória que o produto tenha que aderir?

• Componentes de Terceiros: Especifica qualquer legado, COTS ou componentes de código livre que tenha sido exigido seu uso com o sistema.

• Linguagens de implementação: Especifica os requisitos sobre as linguagens de implementação a serem usadas

• Suporte a Plataformas: Especifica os requisitos sobre as plataformas que o sistema suportará

• limites de Recursos: Especifica os requisitos sobre o uso de recursos de sistema, tais como memória e espaço de disco rígido

• Restrições Físicas: Especifica requisitos sobre forma, tamanho e peso do hardware para abrigar o sistema

Requisitos de Interface (+)

Descreve as interfaces de usuário e com sistemas externos.

Interface de Usuário

Descreve os requisitos relacionados às interfaces de usuário que devem ser implementadas pelo software. A intenção desta seção é declarar os requisitos, mas não descrever a própria interface de usuário, porque o design da interface pode sobrepor o processo de obtenção dos requisitos. Isto é particularmente verdadeiro se você estiver usando a prototipagem como parte de seu processo de coleta de requisitos. À medida que você desenvolver os protótipos, é importante capturar os requisitos que se relacionam aos aspectos visuais da interface de usuário. Ou seja, esteja certo que você compreende as intenções do seu cliente para os aspectos visuais do produto. Registre-os como requisitos, ao invés de meramente usar um protótipo para aprovação.

• Aspectos Visuais: Uma descrição da aparência e da disposição estética da interface. Seu cliente pode ter lhe solicitado demandas específicas, tais como estilo, cores, grau de interação, etc. Esta seção captura os requisitos para a interface, e não o design da interface. A motivação é capturar as expectativas, as restrições e as demandas do cliente para a interface antes de projetá-la. Exemplos:

  • O produto terá a mesma disposição dos mapas do distrito para o departamento de engenharia.
  • O produto usará a cor da empresa.
    
• Requisitos de layout e de navegação: Especifica os requisitos das principais áreas de tela e como devem ser agrupadas.
  
• Consistência: A consistência na interface de usuário permite aos usuários predizer o que irá acontecer. Esta seção declara os requisitos sobre o uso dos mecanismos a serem empregados na interface de usuário. Isto se aplica ao sistema, e a outros sistemas e pode ser aplicado em diferentes níveis: controles de navegação, formas e tamanhos das áreas de tela, locais para entrada ou apresentação de dados e terminologia.
  
• Requisitos de personalização do usuário: Requisitos sobre o conteúdo que deve ser automaticamente exibido aos usuários ou estar disponível baseado nos atributos de usuário. Às vezes os usuários autorizados a personalizar o conteúdo exibido.

Interfaces para sistemas externos ou dispositivos

• Interfaces de Software: Existe algum sistema externo com o qual este sistema deve se conectar? Existe alguma restrição na natureza da interface entre este sistema e algum sistema externo, tal como o formato dos dados passados entre estes sistemas? Eles usam algum protocolo em particular? Descreva as interfaces de software com outros componentes. Podendo ser componentes comprados, componentes reutilizados de uma outra aplicação, ou componentes que estão sendo desenvolvidos para subsistemas fora do escopo do sistema em questão, mas com o qual ele deve interagir. Para cada sistema, considere as interfaces fornecidas e requeridas.

• Interfaces de Hardware: Define qualquer interface de hardware que deve ser suportada pelo software, incluindo estrutura lógica, endereços físicos, comportamento previsto, etc.

• Interfaces de Comunicação: Descreve todas as interfaces de comunicação com outros sistemas ou dispositivos, tais como redes de área local (LANs), dispositivos seriais remotos, etc.

Regras de Negócio (+)

Além dos requisitos técnicos, considere também o domínio de negócio em particular no qual o sistema deve existir. As regras de negócios devem ser documentadas na Lista de Regras de Negócio.

Regras de negócio são políticas que o sistema deve estar em conformidade para poder restringir a funcionalidade do sistema. As regras de negócio são referenciadas pelos casos de uso de sistema e podem estar na forma de tabelas de decisão, regras de computação, árvores da decisão, algoritmos, etc. Descrever as regras nos fluxos dos casos de uso, normalmente desordena a especificação do caso de uso. Sendo assim, são capturadas normalmente em artefatos separados ou como anexos relacionados às especificações de caso de uso. Em muitos casos, uma regra de negócio aplica-se a mais de um caso de uso. As regras de negócio compartilhadas devem ser armazenadas em um único repositório, tal como um documento de requisitos suplementares.