Explicação

A SRS (Especificação de Requisitos de Software) concentra-se na coleta e na organização de todos os requisitos que envolvem o projeto. Se você tiver um Plano de Gerenciamento de Requisitos, deverá consultá-lo para determinar o local e a organização corretos dos requisitos. Por exemplo, talvez seja desejável ter uma SRS separada para descrever todos os requisitos de software para cada recurso em uma determinada liberação do produto. Isso pode incluir vários casos de uso do sistema Modelos de Caso de Uso, para descrever os requisitos funcionais desse recurso, juntamente com o conjunto relevante de requisitos detalhados em Especificações Suplementares.

Como você pode se deparar com diferentes ferramentas para coletar esses requisitos, é importante entender que a coleta dos requisitos pode ser feita com vários e diferentes artefatos e ferramentas. Por exemplo, talvez você ache adequado coletar requisitos textuais, como requisitos não funcionais, Restrições de Design, etc., com uma ferramenta de documentação de texto nas Especificações Suplementares. Por outro lado, talvez ache útil coletar alguns (ou todos) dos requisitos funcionais nos casos de uso e ache prático utilizar uma ferramenta adequada às necessidades de definição do Modelo de Casos de Uso.

Um Documento ou um Pacote?

Para nós, não há um motivo forte para destacar as diferenças entre as ferramentas utilizadas. Afinal, você está coletando requisitos e deve se concentrar na coleta eficiente e na organização dos requisitos sem considerar as ferramentas disponíveis. Como nos concentramos nos requisitos e não nas ferramentas, assumiremos que a coleta de requisitos na SRS constitui um pacote  de informações. A elaboração dos vários requisitos do sistema é incorporada em um pacote chamado SRS (Especificações de Requisitos de Software).

Da Visão para o SRS

O Pacote SRS está obviamente relacionado ao documento Visão. Na verdade, o documento Visão serve como uma entrada para a SRS. Mas os dois artefatos atendem a diferentes necessidades e, geralmente, são escritos por vários autores. Neste estágio do projeto, o foco do projeto se desloca da declaração genérica das necessidades do usuário, metas e objetivos, mercados-alvo e recursos do sistema para os detalhes de como esses recursos serão implementadas na solução.

O que precisamos agora é de uma coleta, ou pacote, de artefatos que descreva o comportamento externo completo do sistema, isto é, de um pacote que diga especificamente: "Aqui está o que o sistema deve fazer para entregar esses recursos". É isso que denominamos Pacote SRS.

Um Artefato Ativo

O Pacote SRS não é um volume congelado, produzido para cumprir o ISO 9000 e depois ser colocado em um canto e ignorado durante a continuação do projeto. Em vez disso, ele é um artefato ativo, vivo. Realmente, ele possui várias utilizações quando os desenvolvedores iniciam seu esforço de implementação: Ele serve como uma base de comunicação entre todas as partes, isto é, entre os próprios desenvolvedores e entre os desenvolvedores e os grupos externos (usuários e outros envolvidos) com os quais eles devem se comunicar. Formal ou informalmente, ele representa um acordo contratual entre as várias partes - os desenvolvedores não deverão trabalhar em algo que não esteja no Pacote SRS. E eles serão responsáveis por oferecer a funcionalidade de tudo que estiver no Pacote SRS.

O Padrão de Referência dos Membros do Projeto

A SRS serve como o padrão de referência do Gerenciador de Projetos. Provavelmente, o coordenador de projeto não terá tempo, energia ou habilidades para ler o código que está sendo gerado pelos desenvolvedores e compará-lo diretamente com o documento Visão. Ele deve utilizar o Pacote SRS como a referência padrão para discussões com a equipe do projeto.

Como foi observado anteriormente, ele serve como entrada para os grupos de design e de implementação. Dependendo de como o projeto foi organizado, talvez os implementadores estiveram envolvidos nas tarefas preliminares de resolução de problemas e definição de recursos que culminaram na produção do documento Visão. Mas é no Pacote SRS que eles precisam se concentrar para decidir o que o código deve fazer. Ele serve como entrada para os grupos de teste e de QA do software. Esses grupos também deveriam estar envolvidos em algumas das discussões preliminares e é obviamente útil que eles tenham um bom entendimento da "visão" apresentada nos documentos de Visão. Mas a missão deles é criar casos de teste e procedimentos de controle de qualidade para assegurar que o sistema desenvolvido preencha de fato os requisitos apresentados no Pacote SRS. O Pacote SRS também serve como a referência padrão para as suas tarefas de planejamento e de teste.

Definindo os Requisitos Funcionais

Consulte a Diretriz: Modelo de Caso de Uso e a Diretriz: Caso de Uso para obter uma discussão da abordagem recomendada para definir os requisitos funcionais dentro de um Modelo de Caso de Uso e os Casos de Uso.

Definindo Requisitos Não Funcionais

Os requisitos não funcionais do sistema devem ser documentados em Produto de Trabalho: Especificações Suplementares.  A seguir, estão as diretrizes a serem seguidas ao definir esses requisitos.

1 Geral

1.1 Premissas e Problemas

Ao reunir e validar requisitos não funcionais, mantenha listas de Pressupostos e de Problemas. 

Algumas tarefas não lhe darão respostas satisfatórias. Isso pode ocorrer por falta de informação ou simplesmente porque você considera que a resposta ameaça a viabilidade do design. Portanto, crie duas listas e as mantenha durante o estudo do design:

Todos os pressupostos feitos durante o processo de requisitos e de design, incluindo os processos racionais ou ponderados subjacentes a esses pressupostos. Os pressupostos podem ser utilizados para identificar subprojetos relacionados ou itens de trabalho que estão fora do escopo do projeto ou são posteriores a ele.

Todos os maiores problemas (preocupações significativas que podem se tornar alvo das atenções)

Esses problemas devem ser examinados com o cliente no fim de cada fase. Os pressupostos também precisam ser examinados no fim de cada fase, mas talvez o cliente não seja sempre a pessoa correta para examinar os pressupostos menos importantes.

As premissas e os problemas aplicam-se a todos os produtos de trabalho, embora sejam especialmente comuns para os requisitos não funcionais.

1.2 Organização Geográfica

Documente a organização geográfica do cliente.

Documente os locais geográficos da parte do negócio afetada pelo sistema. A definição deve incluir também os locais não afetados, que hospedam as maiores instalações de tecnologia da informação. Faça observação especial de qualquer parte da organização que seja móvel. Por exemplo, uma equipe de vendas que viajará e utilizará estações de trabalho. Anote qualquer local geográfico onde o suporte ao idioma nacional (NLS) for necessário.

2 Dados

2.1 Pacotes de Aplicativos Pré-selecionados?

Os requisitos especificam o uso de algum pacote de aplicativos? Um "dado" muito importante que pode determinar firmemente algumas das decisões de design do sistema é o uso de um pacote de aplicativos específico que forneça lógica de software e organização de dados predefinidas. Alguns pacotes de softwares são flexíveis e permitem uma ampla personalização; outros são muito rígidos e não permitem. Os pacotes podem definir componentes e decisões como:

• Tipo de estação de trabalho
• Métodos de conexão
• Tipo de processador e Dispositivo de Armazenamento de Acesso Direto (DASD)
• Programa de Controle do Sistema
• Organização, colocação e gerenciamento dos dados
• Linguagem de programação
• Interfaces batch
• Relacionamentos de dados e de processos
• Lógica do negócio
• Design de tela e interfaces do usuário
• Características de desempenho e de disponibilidade
• Qualquer arquitetura existente ou obrigatória para impressão, como formatos preferidos de dados impressos (por exemplo, PostScript, PCL, IPDT)
• Suporte ao Idioma Nacional (NLS - National Language Support)

É importante compreender quais as influências que um pacote de dados terá no design. Se você tiver um pacote de "dados", verifique se tem disponível as habilidades e o conhecimento corretos sobre ele. Suas fontes podem ser:

• O fornecedor do pacote
• Consultores externos
• Membros da equipe de design especialmente treinados

Não pressuponha que esse conhecimento estará prontamente disponível. Verifique se ele estará disponível quando você precisar dele.

2.2 Outros Dados

Documente quaisquer outros dados nos requisitos que limitarão a flexibilidade do design.

Isso é para abranger todos os requisitos específicos não abordados explicitamente nas tarefas anteriores que possam limitar a flexibilidade do design. Procure um dos seguintes:

• O uso de imagens do sistema operacional ou de processadores existentes
• O uso de equipamento de estação de trabalho existente
• O uso de uma rede existente
• O uso de práticas existentes de gerenciamento de sistema
• O uso de um modelo específico, como: 'você deve utilizar um modelo de sistema cliente/servidor para o design que mostre claramente Apresentação/Negócios/Lógica de Acesso a Dados e onde e como há interface entre eles'.

Algum desses dados afetará o novo sistema? Se o novo sistema precisar ser executado em um processador existente, em uma imagem do sistema operacional ou em uma configuração da rede, as características da carga de trabalho e da plataforma existente afetarão o novo sistema?

Quanto da capacidade de processamento e de conexão é utilizada pelas cargas de trabalho existentes?

Quais controles de segurança são utilizados pelas cargas de trabalho existentes? Anote esses itens e verifique-os nos requisitos de segurança do novo sistema quando o estudar.

Quais são as características de disponibilidade da carga de trabalho existente?

Anote tudo que possa afetar o design posterior de disponibilidade para o novo sistema. Por exemplo, a carga de trabalho insiste em desligar o processador todas as noites?

2.3 Hardware Especial?

Os requisitos especificam o uso de algum hardware especial?

Isso pode ser indicado em termos genéricos ("o sistema deve suportar uma plotadora de mesa de alta velocidade") ou ser mais específico ("haverá suporte para os caixas eletrônicos da Panda Corp existentes"). Documente o máximo possível:

• Todos os pré-requisitos de hardware ou software
• Os fornecedores e suas organizações de suporte
• Considerações sobre Idioma Nacional (NLS)
• Equipamento de criptografia

2.4 Dados Existentes?

Os requisitos especificam o uso de dados existentes? Em caso afirmativo, isso influenciará o design do sistema. Documente:

• Em que sistema(s) os dados estão atualmente
• Sua estrutura (como arquivo relacional ou simples)
• Seu tamanho
• Quais usuários e quais sistemas usam esses dados hoje
• Considerações de disponibilidade (como os períodos de indisponibilidade dos dados por causa de manutenção do banco de dados ou de tarefa de lote)
• Esses dados podem ser movidos ou copiados?

3 Padrões

3.1 Plano Estratégico / de Arquitetura Técnica

O cliente tem uma arquitetura técnica e/ou um plano estratégico de tecnologia da informação (ou um conjunto equivalente de padrões)?

Uma arquitetura técnica é aproximadamente equivalente ao seguinte:

• Plataforma técnica empresarial
• Infra-estrutura técnica empresarial
• Arquitetura de tecnologia

Em uma arquitetura tecnológica, talvez você encontre alguns dos seguintes itens definidos para você:

• O número e o uso dos centros de computação
• A conectividade de rede da empresa (WAN)
• A conectividade localizada de determinados estabelecimentos (LAN)
• A cobertura dos serviços de infra-estrutura cliente/servidor (middleware)

· Serviços de diretório e de nomes que mantêm o controle de recursos da rede e de atributos
· Serviços de segurança que protegem os recursos da rede contra o uso não autorizado por meio do registro de usuários e de seus níveis de autorização
· Serviços de hora que regulam data e hora na rede
· Serviços de gerenciamento de transações que coordenam a recuperação de recursos entre os vários sistemas em uma rede

• Os métodos de desenvolvimento que serão utilizados para os novos aplicativos 
• O conjunto aceito de produtos suportados, como:

· Hardware
· Software de controle do sistema
· Software aplicativo amplo, como o "Office"
· Uso do Helpdesk
· Regras de segurança

• Arquitetura do subsistema de impressão

A lista pode ser muito extensa e os itens podem ser controlados rigidamente ou, então, nem ser controlados.

Documente todos os requisitos que pedem especificamente, ou excluem, o uso de subarquiteturas, como:

• OSI ou SNA
• UNIX**
• SAA
• PS/2* com OS/2* EE.

Arquiteturas especiais que podem ser implementadas com o uso de um pacote de soluções de aplicativos. Lembre-se de que alguns pacotes de aplicativos são definições de arquitetura.

Documente o grau de abertura (ou seja, independência do fornecedor e interoperabilidade com ele) exigida pelo cliente. Se houver uma arquitetura técnica, então, o design certamente terá de obedecê-la. Você deve ler a arquitetura e compreender as regras que influenciarão o design do sistema.

3.2 Arquitetura de rede

O cliente tem uma arquitetura de rede à qual o sistema deve se ajustar? Uma arquitetura de rede é um conjunto comum de regras para a conectividade de alto nível, mais uma infra-estrutura comum de transporte. Isso pode incluir a definição de uma rede backbone, incluindo concentradores e linhas. Se houver essa arquitetura, familiarize-se com a topologia e as regras essenciais e documente:

As considerações sobre a topologia física (isto é, se a rede é essencialmente rural ou metropolitana, e se as conexões de rede estão densamente ocupadas ou distribuídas livremente).

Quais funções de conexão de alto nível são suportadas pela infra-estrutura de rede atual.

Quais padrões de comunicação são utilizados (por exemplo, SNA, OSI, TCP/IP) para suportar essas funções de conexões.

Quais interfaces de programação são suportadas.

Qualquer definição de arquitetura de rede da conectividade entre as camadas de cliente/servidor ou as camadas do modelo de sistema base, como:

• O acesso a dados relacionais entre estações de trabalho cliente e servidores relacionais da LAN devem ser através de protocolos de um produto específico de banco de dados relacional.
• A lógica da apresentação deve estar sempre na estação de trabalho, e a lógica de acesso a dados deve estar sempre em um sistema host centralizado.

3.3 Políticas de Conexão

O cliente já possui alguma política para conexões?

Mesmo que não haja arquiteturas técnicas ou de rede, você ainda poderá ter algumas políticas de conexão.

Documente todas as políticas considerando:

• O uso de determinados protocolos ou recursos de comunicação (para conexões dentro de um único prédio ou externas ao prédio ou à organização).
• Se determinados protocolos são implicitamente obrigatórios para suportar software ou equipamento existente.
• Se os recursos existentes de conectividade física devem ser utilizados (isto é, cabeamento ou fiação, controladores de periféricos ou rede, e recursos comuns de portadora). Se não for o caso, pode haver restrições ao tipo de recursos físicos que podem ser utilizados (políticas, leis governamentais, espaço físico, propriedade dos edifícios, envolvimento de terceiros). Documente esses itens.
• Se houver necessidade de instalação ou modificação de recursos físicos, talvez seja necessário envolver um ou mais terceiros (como fornecedores ou portadoras comuns). Compreenda como será gerenciada a contratação ou a responsabilidade. Isso será especialmente importante caso as interações de negócios envolvam conexões internacionais.
• Suporte para usuários móveis.

3.4 Outras Políticas?

O cliente possui outras políticas, padrões ou regras não definidas explicitamente nos requisitos? Por exemplo:

• Todas as novas interfaces do sistema para usuários devem ser projetadas de acordo com princípios orientados ao objeto para permitir ações de arrastar e soltar.
• Todos os novos sistemas devem se basear no modelo de aplicativo cliente/servidor.
• Todos os novos sistemas devem ser definidos com padrões abertos.
• Padrões e políticas para Suporte ao Idioma Nacional (NLS), como operação de texto da direita para a esquerda.
• Política de segurança que define a responsabilidade de gerenciamento e os padrões para autenticação de usuários, controle de acesso e proteção aos dados.
• Padrões de trocas entre aplicativos (como UNEDIFACT ou VISA) que podem implicar o uso de equipamento especial para conexão ou segurança.

Se houver outras políticas, verifique se você as compreende e tem acesso a elas para assegurar que o design estará de acordo com os padrões nas fases posteriores do processo de design. O uso de um pacote de soluções de aplicativos pode trazer com ele alguns padrões implícitos.

Qual é a política para permitir que usuários e departamentos acrescentem e/ou desenvolvam os próprios programas locais em:

• Estações de trabalho
• Servidores (especialmente o uso de espaço em disco)

Se não houver controle, talvez o uso local utilize rapidamente os recursos necessários aos sistemas de produção, para os quais os componentes locais foram originalmente comprados. Talvez você não possa instalar o sistema de produção quando ele estiver finalmente pronto para o lançamento.

4 Números

4.1 "Unidades de medida"

Trabalhe com o pessoal de desenvolvimento de aplicativos para fragmentar os processos de negócios em pequenas unidades como transações ou processos de negócios menores.

A razão para fazê-lo é que você coletará números na próxima pergunta, e você deverá decidir o que irá contar.

Lembre-se de que um processo de negócio pode iniciar várias instâncias de transações de negócios menores (por exemplo, vários pedidos de itens por pedido de cliente) e esses multiplicadores devem ser lembrados quando você documentar os números. No entanto, não se atenha a muitos detalhes, principalmente no caso de um sistema complexo.

Um "processo" de negócios (por exemplo, "manipulação de pedidos do cliente") será implementado normalmente por um "aplicativo" (um termo de TI) ou poderá estender-se por mais de um aplicativo. Dentro de cada aplicativo, haverá geralmente várias "transações" de TI, por exemplo, "consultar nível de estoque" ou "gerar carta do cliente".

Cada comunidade usa seus próprios nomes para identificar as unidades que estamos tentando reconhecer. Por exemplo, "transação" pode ter um significado para pessoas com conhecimento em desenvolvimento de aplicativos e ter outro significado completamente diferente para a equipe de infra-estrutura. É importante trabalhar em conjunto para definir a correlação dos nomes para, então, coletar as informações.

4.2 "Volumes e Tamanhos Comerciais"

Identifique e documente as informações sobre volume e tamanho de cada uma das unidades em 4.1: "Unidades de Medida", por exemplo:

• Quantos usuários deverão utilizar cada aplicativo ou processo de negócio em horas normais e de pico?
• Quando ocorrem os picos (diariamente, semanalmente, mensalmente etc., conforme o caso)?
• A que taxa as transações precisarão ser processadas no pico e na média?
• O número de elementos de dados e de instâncias em cada grupo de dados e seus tamanhos.

4.3 "Critérios de Desempenho dos Processos de Negócios"

Talvez o cliente tenha critérios de desempenho especificados para alguns ou todos os processos de negócios. Contudo, lembre-se de documentar também os objetivos de desempenho para processos de suporte ao sistema (como backup do sistema) e processos de desenvolvimento de aplicativos, se houver. Para cada categoria, documente:

• Os requisitos de resposta/retorno para cada categoria
• Onde eles serão medidos
• Se critérios diferentes são aceitos em momentos diferentes (por exemplo, fora de pico/madrugada)
• Se os critérios deverão ser atendidos durante uma recuperação ou um recuo
• Se é obrigatória uma garantia de desempenho
• Qual será o impacto em todas as partes se os requisitos de desempenho não forem cumpridos
• Expresse as condições mínimas de desempenho necessárias ao processo de negócios que devem ser consideradas disponíveis (isto é, o ponto abaixo do qual o sistema é considerado "indisponível", em vez de "lento").
• Se um pacote de soluções de aplicativos já tiver sido escolhido, verifique se você tem acesso às suas características de desempenho. Talvez você não precise delas agora, mas saiba onde obtê-las, pois, provavelmente, serão necessárias nas tarefas futuras. Também é possível que leve muito tempo para que terceiros enviem os números pedidos, então, peça-os agora.

5 Disponibilidade

5.1 Requisito de Disponibilidade

A abordagem recomendada para estabelecer os requisitos de disponibilidade inclui:

1. Identificar os verdadeiros usuários do sistema, os processos de negócios que eles executam e as horas em que eles realizam esses processos
2. Analisar o impacto da disponibilidade (ou indisponibilidade) do serviço na capacidade de os usuários realizarem os objetivos de negócios
3. Especificar os requisitos de disponibilidade que refletem diretamente as exigências dos usuários para atingir os objetivos de negócios.
4. Saber que, se um pacote de soluções de aplicativos já tiver sido escolhido, sua estrutura e design poderão afetar significativamente as características de disponibilidade do aplicativo do ponto de vista dos usuários. Um pacote poderá ter dificuldade em operar continuamente caso não tenha sido projetado para isso, especialmente em relação a janelas de lote e manutenção.

Siga essas diretrizes ao formar os requisitos de disponibilidade:

• Em vez de especificar requisitos "globais" para o sistema inteiro, especifique requisitos de disponibilidade em granularidades de baixo nível (por exemplo, por processos individuais, grupo de usuários, grupo de dados, etc.). Isso proporciona ao designer mais flexibilidade para atender às necessidades dos usuários. Isso é especialmente importante para sistemas com requisitos de disponibilidade contínua muito alta.

Alguns exemplos:

• A instrução "O sistema deve estar ativo 24 horas por dia para servir usuários em Nova York e em Hong Kong" deixa muito menos flexibilidade ao designer do que a instrução "Os usuários de Nova York podem executar transações em SEUS dados das 7h às 19h no horário de Nova York e os usuários de Hong Kong podem executar transações em SEUS dados das 7h às 19h no horário de Hong Kong". No último caso, o designer tem a flexibilidade de executar manutenção nos dados ou nos componentes do sistema de um fuso horário, enquanto o outro fuso horário ainda está no meio do seu dia de trabalho.
• Em um aplicativo de caixa eletrônico, pode ser crítico aceitar depósitos e distribuir dinheiro às 3:00 da madrugada de segunda-feira, mas a capacidade de fornecer saldos bancários exatos à essa hora deve ser menos crítica.
• Diferencie as características de disponibilidade DESEJÁVEIS daquelas que são OBRIGATÓRIAS. Por exemplo, "O caixa eletrônico DEVE ser capaz de aceitar depósitos e distribuir dinheiro 24 horas por dia. É DESEJÁVEL que o caixa eletrônico possa fornecer ao cliente o saldo exato de sua conta 24 horas por dia, no entanto, pode haver interrupções ocasionais no processo de pesquisa do saldo da conta, mas elas DEVEM durar menos de 10 minutos e ocorrer entre 3h e 4h da madrugada".
• Se o impacto do não cumprimento de um determinado destino de disponibilidade não puder estar relacionado diretamente à capacidade de os usuários realizarem seus objetivos de negócios, talvez esse destino não seja bom para ser indicado como um requisito de disponibilidade para o sistema.
• Os requisitos de disponibilidade que refletem apenas indiretamente a disponibilidade como ela é percebida pelo usuário (por exemplo, "A região de controle IMS deve estar ativa") tendem a não ser tão úteis como aqueles que refletem diretamente (por exemplo, "Caixas bancários devem ser capazes de executar os processos X e Y").

5.2 "Horas de serviço planejadas"

Para cada processo de negócio e cada grupo de usuários que deve realizá-lo, identifique as horas em que o usuário poderá executar o processo. Lembre-se também de fazer o mesmo para aqueles processos que não estão diretamente associados com grupo(s) de usuários.

Se houver grupos de usuários em diferentes fusos horários (como Nova York/Hong Kong no exemplo anterior), trate-os como grupos separados de usuários.

Mostre também se haverá períodos ocasionais, como feriados comerciais, quando talvez o aplicativo não for necessário. (Isso dá ao designer a flexibilidade de utilizar esses períodos para manutenção prolongada). Quais mudanças são previstas nessas horas de serviço ao longo da vida projetada do aplicativo?

As horas de serviço deste sistema também podem ser afetadas pelas de outros sistemas com os quais ele faz interface.

Como as horas programadas de serviço deste sistema deverão ser mudadas ao longo de sua vida projetada?

5.3 "Custos de Interrupção do Serviço"

Familiarize-se com o IMPACTO DOS NEGÓCIOS, CUSTOS FINANCEIROS E RISCOS associados às interrupções de serviço durante as horas programadas de serviço.

Para identificar quais requisitos de disponibilidade são realmente importantes para o sistema, considere o conjunto de processos de negócios e grupos de usuários, e identifique o possível impacto dos negócios resultante:

• Uma interrupção breve ou um período de tempo de resposta inaceitavelmente baixo durante as horas programadas. Defina "artigo" e "inaceitavelmente baixo", pois se relacionam a esse determinado aplicativo (consulte "Critérios de Desempenho de Processos de Negócios")
• Várias interrupções de longa duração no serviço durante as horas acima (um minuto, alguns minutos, 15 minutos, 30 minutos, uma hora, duas horas, quatro horas etc.)
• Interrupções prolongadas no serviço (um turno, um dia, vários dias etc.).
• Considere também os processos que não estão diretamente associados a um grupo de usuários (por exemplo, compensação noturna de cheques).

Ao estimar o impacto de cada inatividade, identifique os procedimentos de recuo e considere como eles podem reduzir o verdadeiro impacto de negócio da inatividade.

Tente quantificar esse impacto em termos financeiros (custo da produtividade perdida da equipe ou do equipamento, valor de negócios atuais perdidos, perda estimada de negócios futuros devido à insatisfação do cliente, despesas com juros, multas reguladoras, etc.).

Forneça quantas respostas forem necessárias para refletir as diferenças nos custos e riscos associados a interrupções de diferentes durações, em diferentes momentos do dia, planejadas ou não, quais processos de negócios ou usuários são afetados, etc.

Como o impacto comercial/financeiro de uma interrupção de serviço é antecipado para mudar durante a vida projetada do sistema?

Analise cada processo de negócio importante reconhecido para identificar alternativas que permitam a continuação dos elementos mais críticos desses processos, caso partes do sistema fique temporariamente indisponível. A capacidade de operar temporariamente com função de negócio reduzida pode ser uma forma de ajudar a reduzir o impacto de disponibilidade das interdependências entre os dados e os processos críticos.

Alguns exemplos:

• FUNÇÃO TOTAL 1 Ler e atualizar registros de estoque.
• FUNÇÃO REDUZIDA 1 Inserir atualização de registro de estoque e criar fila para atualização futura.
• FUNÇÃO TOTAL 2 Ler o saldo mais recente do cliente.
• FUNÇÃO REDUZIDA 2 Ler o saldo do cliente em uma fonte alternativa, que pode não ser tão atual.
• FUNÇÃO TOTAL 3 Atualizar a agenda do computador.
• FUNÇÃO REDUZIDA 3 Atualizar cópia em papel impresso da agenda.

Lembre-se de que, quando o sistema estiver trabalhando com função reduzida, poderá haver um limite de aceitação para os processos de negócios. Por exemplo, um saldo desatualizado do cliente não deve estar mais de 24 horas desatualizado.

Se o serviço for interrompido durante as horas planejadas (consulte "Horas Planejadas de Serviço"), o impacto da interrupção geralmente variará de acordo com a duração da interrupção e de outras condições. Algumas interrupções podem ter um impacto mínimo na capacidade de os usuários executarem os processos de negócios (interrupções breves, aquelas que ocorrem durante períodos de pouco uso do dia, aquelas que afetam apenas um subconjunto do grupo de usuários ou aquelas para as quais existe um procedimento de compensação manual aceitável). Outras interrupções, como aquelas que são mais longas ou que ocorrem durante um período "crítico" do dia, podem ter um impacto mais significativo. 

Alguns exemplos:

• Uma inatividade breve nos processos de controle de uma linha de manufatura pode ter um impacto mínimo na produtividade, pois o trabalho poderá continuar baseado em ordens de trabalho previamente impressas e as mudanças poderão ser anotadas manualmente para serem inseridas posteriormente. No entanto, uma inatividade superior a sessenta minutos pode resultar no desligamento da linha no turno seguinte.
• Uma inatividade de um sistema de liquidação financeira de grande volume de dinheiro durante a última hora da negociação poderá resultar em juros muito altos ou multas reguladoras.
• As respostas do distrito de polícia a emergências com risco de vida poderão continuar utilizando procedimentos de recuo manual se um sistema de expedição estiver indisponível. Todavia, os tempos de respostas poderão aumentar e, potencialmente, ameaçar vidas, devido à carga de trabalho aumentada do expedidor.
• Uma inatividade durante período de pico no sistema de reservas de uma companhia aérea ou de um hotel pode resultar não apenas na perda do negócio atual quando os clientes ligarem para um concorrente para fazer suas reservas, mas também poderá resultar na perda de negócios futuros caso os clientes fiquem tão insatisfeitos a ponto de ligarem primeiro para outra companhia aérea ou outro hotel na próxima vez que precisarem desses serviços.

5.4 "Critérios de Disponibilidade e Recuperação"

Identifique os CRITÉRIOS DE DISPONIBILIDADE E RECUPERAÇÃO que se aplicariam em situações "normais".

Exclua situações de "desastre", como perda ou encerramento extensivo de todo o recurso de computação.

Com base nos custos e riscos comerciais/financeiros identificados em "Custos da Interrupção de Serviço", desenvolva uma especificação dos critérios de disponibilidade que devem ser atendidos para evitar a restrição significativa de grupos de usuários na execução dos processos de negócios designados a eles. Esses critérios devem ser especificados das seguintes formas:

• Percentual de inatividades recuperadas dentro de um limite de minutos/segundos
• Quantidade máxima de vezes em um dado período (semana/mês/ano) em que o usuário não pode executar determinada função

Seja específico o suficiente para refletir fatores como diferenças entre interrupções planejadas e não planejadas, a hora em que ocorre a interrupção (por exemplo, períodos "críticos" versus períodos de pouco uso), se todos os usuários ou apenas alguns serão afetados, etc.

Tome cuidado para não especificar critérios de disponibilidade desnecessariamente rigorosos, porque isso afetaria bastante o custo de implementação. Em geral, se não for possível identificar riscos ou custos de negócios/financeiros significativos com um determinado conjunto de condições de inatividade, isso pode ser uma indicação de que esse conjunto de condições de inatividade não deve ser incluído nos critérios de disponibilidade estabelecidos.

Se em "Horas Planejadas de Serviço" foi sugerido que essas horas provavelmente serão alteradas e/ou em "Custos da Interrupção de Serviço" foi sugerido que os custos ou os riscos comerciais/financeiros associados a uma interrupção de serviço provavelmente serão alterados durante a vida projetada do sistema, calcule como seria a alteração resultante nos critérios de disponibilidade.

Se alguma criptografia for utilizada, haverá outras considerações sobre recuperação e disponibilidade. Por exemplo:

• A capacidade de recuperar informações secretas que podem ser mantidas fora do sistema.
• A necessidade de assegurar que os dados protegidos por criptografia sejam recuperados em coordenação com a recuperação das chaves de criptografia adequadas.

5.5 "Recuperação de Desastres?"

A recuperação de desastre é requerida dentro do escopo deste projeto de design (disponibilidade durante situações de "desastre", como perda ou encerramento extensivo de todo o recurso de computação)? Em caso afirmativo, quais são os critérios para essa recuperação?

Lembre-se de que provavelmente nem todos os processos de negócios exigirão recursos para recuperação de desastre. Selecione apenas os processos que são críticos e exigem recuperação de desastre. Mesmo dentro desses processos, talvez não seja necessário recuperar todas as funções.

• Qual o prazo para restauração do serviço? Esse tempo é medido a partir da ocorrência do desastre, ou a partir da tomada de uma decisão para ir a um local remoto?
• Em que condições a organização optaria por uma recuperação no local remoto em vez de localmente?
• Quão atuais devem ser os dados no site remoto para que o negócio continue a operar (até o último segundo; alguns minutos após a falha; dados do dia anterior são aceitáveis)?
• Assim que o serviço é recuperado a partir do local remoto?
• Em algum momento futuro?
• Qual é a prioridade para recuperação no local remoto desse conjunto de aplicativos em relação a outros aplicativos de negócios dependentes da mesma instalação de computação?

Observe que pode haver diferentes conjuntos de critérios para diferentes partes do sistema ou de acordo com o tipo de desastre.

Quais mudanças nos requisitos acima de recuperação de desastre são previstas durante a vida projetada do aplicativo?

5.6 "Outras Considerações de Design de Disponibilidade"

Para projetar um sistema que se recupere o mais rápido possível, o designer precisa saber quais flexibilidades estão disponíveis para ele ao implementar o aplicativo, ao mesmo tempo em que ainda cumpre os requisitos funcionais do aplicativo. Estas são algumas perguntas que podem ser valiosas ao designer:

1. Para acomodar as tarefas de manutenção necessárias, o sistema poderá operar por períodos curtos durante os quais ele iria:

a. Executar pesquisa mas não atualização?

b. Aceitar pedidos de atualização do usuário, mas não atualizar de verdade o banco de dados até a conclusão das tarefas de manutenção?

2. Para uma interrupção que exija recuperação de dados, é mais importante:

c. Restaurar o sistema o mais rápido possível, ainda que utilizando dados que não foram atualizados completamente, ou:

d. Recuperar o estado atual de todos os dados antes de restaurar o serviço, mesmo que isso demore mais?

3. Se um pedido do usuário estiver "em processo" no momento da falha, será possível contar com o usuário para digitar o pedido novamente após a recuperação do serviço?

4. Há considerações não técnicas que podem afetar a disponibilidade desse sistema (como uma política de negócios que diz que o processo A não deve ser disponibilizado aos usuários, a menos que o processo B também esteja disponível)?

Há previsão de mudança de alguma das considerações de design acima ao longo do tempo?

Para os processos críticos do negócio, é útil identificar alternativas que permitem que os elementos mais críticos desses processos pareçam funcionais, mesmo quando o sistema esteja temporariamente indisponível. A capacidade de operar temporariamente com função de negócio reduzida pode ser uma forma de ajudar a reduzir o impacto de disponibilidade das interdependências entre os dados e os processos críticos.

6 Segurança

6.1 "Requisitos de Segurança"

1. Identifique os dados a serem protegidos

2. Identifique o tipo de ameaça a que cada tipo de dado está exposto:

• Dano ou destruição acidental
• Dano ou destruição intencional
• Inteligência comercial
• Fraude
• Invasão de hackers
• Vírus

1. Identifique as ameaças à segurança física:

• Roubo de componentes
• Acesso físico não autorizado
• Segurança física dos usuários

2. Identifique as pessoas que podem ser a origem dessas ameaças:

• Equipe do centro de processamento de dados
• Outra equipe da tecnologia de informação (por exemplo, desenvolvimento)
• Equipe da organização, mas externa à tecnologia da informação
• Pessoas de fora da organização

3. Identifique qualquer requisito de segurança especial ou incomum, especialmente em relação a:

• Acesso ao sistema
• Criptografia de dados
• Possibilidade de auditoria

4. Há alguma política geral, como estatutos de Liberdade de Informação, que pode influenciar o design de segurança desse sistema?

5. Alguns pacotes de soluções de aplicativos possuem seus próprios subsistemas de segurança. Se você tiver um pacote de "dados", preste atenção nos seus recursos de segurança.

Para estabelecer e classificar os requisitos de segurança, convém utilizar o seguinte procedimento:

1. Liste os objetos que exigem proteção por segurança lógica ou física.

2. Identifique a exposição relevante a cada objeto. As categorias usuais são:

• Acesso para visão (abertura de confidencialidade), por exemplo, informações sobre uma conta, lista de clientes, patentes.
• Acesso para atualização, isto é, modificação de dados para fraude, ocultação de dados, desvio de fundos.
• Perda de ativos, isto é, alguém leva algo que não estará mais disponível para o proprietário (diferente da perda por desastre). Exemplos: listas de clientes e expectativas, contratos, etc.

Observe que nem todos os objetos são sensíveis às exposições acima.

3. Identifique todas as ameaças que são relevantes para o ambiente. Como exemplos, podemos citar:

• Funcionários insatisfeitos
• Funcionários não autorizados
• Sessões de terminal aberto em local público
• Hackers
• Linha grampeada
• Perda de equipamento (por exemplo, PCs portáteis)

4. Para cada objeto, estabeleça as possíveis ameaças e as associe a determinada exposição.

Observe que talvez você deva analisar os requisitos de segurança do objeto tanto em um local estático (por exemplo, em um disco rígido) quanto em trânsito (por exemplo, durante uma transmissão).

Como o design pode dilatar a localização do objeto para áreas não seguras, convém voltar a este tema.

Os aspectos de segurança de alguns designs de sistema podem ser muito exigentes. Eles podem dominar as suas decisões de design. Eles podem tornar inaceitáveis as boas opções de estrutura e seleção de componentes. Defina agora se o sistema que você está projetando possui requisitos de segurança muito exigentes. Por exemplo:

• Um sistema militar sensível
• Um sistema de transferência de grandes valores de dinheiro
• Um sistema que administra informações pessoais confidenciais

Se você acha que possui demandas de segurança especiais, você deve encontrar um profissional ou um especialista em segurança para ajudá-lo nas diretrizes de design do sistema.

7 Utilidade

Os requisitos de utilização definem o nível máximo de utilização da interface com o usuário.

Os requisitos de utilização devem ser definidos com o nível mais baixo de utilização que o sistema deve atingir para que possam ser utilizados. Eles não devem ser definidos com aquilo que você acha que o sistema pode atingir. Ou seja, os requisitos de utilização não devem ser considerados como destinos, isto é, como um limite superior. Eles devem definir o nível de usabilidade absoluto mais baixo aceitável para o sistema. Desse modo, você não deve necessariamente parar de melhorar a utilização quando os requisitos de utilização forem preenchidos

Na maioria das vezes, esse nível depende das alternativas de uso do sistema. É razoável exigir que o sistema tenha significativamente mais usabilidade que as alternativas. As alternativas podem servir para utilizar:

• Procedimentos manuais existentes.
• Sistemas legados.
• Produtos concorrentes.
• Versões anteriores do sistema.

Os requisitos de utilização também podem surgir da necessidade de justificar economicamente o novo sistema: se o cliente tiver que pagar R$ 3 milhões pelo novo sistema, é possível que ele prefira impor requisitos de utilização que talvez o levem a economizar R$ 1 milhão por ano devido à menor carga de trabalho de seus recursos humanos.

A seguir, exemplos de alguns requisitos gerais de utilização:

• Tempo máximo de execução - quanto tempo deve levar para que um usuário treinado execute um cenário comum.
• Taxa máxima de erro - quantos erros um usuário treinado produzirá em média para um cenário comum.
  Os únicos erros relevantes a serem medidos são aqueles irrecuperáveis e que terão efeitos negativos na organização, como perder o negócio ou causar danos ao hardware monitorado. Se a única conseqüência de um erro for a demora para corrigi-lo, isso afetará o tempo de execução medido.
• Tempo de aprendizagem - quanto tempo levará para o usuário poder executar um cenário mais rapidamente que o tempo máximo de execução especificado.

A seguir, um exemplo de alguns requisitos específicos de utilização para um Caso de Uso "Gerenciar Mensagens de Correio de Entrada".

• O Usuário de E-mail deve ser capaz de organizar as Mensagens Eletrônicas simplesmente clicando o mouse.
• O Usuário de E-mail deve ser capaz de percorrer os textos da Mensagem Eletrônica simplesmente pressionando as teclas.
• O Usuário de E-mail não deve se deixar distrair pela entrada de Mensagens Eletrônicas enquanto estiver lendo as Mensagens Eletrônicas existentes.