Diretrizes: Especificação de Requisitos de Software
Tópicos
A SRS (Especificação de Requisitos de
Software) concentra-se na coleta e na organização de todos os requisitos
que envolvem o projeto. Por exemplo, talvez seja desejável ter uma SRS separada para
descrever todos os requisitos de software para cada recurso
de uma determinada liberação do produto. Isso pode incluir vários casos de
uso do modelo de casos de uso do sistema
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
caso de uso.
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ção de Requisitos de
Software).
O Pacote SRS está obviamente relacionado ao documento Vision. Na verdade, o documento Vision 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.
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 investidores)
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.
A SRS serve como o padrão de referência do coordenador de projeto. 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 Vision. 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 atividades preliminares de resolução de problemas e definição de recursos que culminaram na produção do documento Vision.
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 atividades de planejamento e de teste.
Consulte Diretrizes: Modelo de Caso de Uso e Diretrizes:
Caso de Uso para obter uma discussão completa da abordagem recomendada para a definição dos
requisitos funcionais dentro de um Modelo de
Caso de Uso e dos Casos de Uso.
Os requisitos não funcionais do sistema devem ser documentados em Artefato:
Especificações Suplementares. A seguir, as diretrizes a serem seguidas ao
definir esses requisitos.
Ao reunir e validar requisitos não funcionais, mantenha
listas de Pressupostos e de Problemas.
Algumas atividades 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.
Os pressupostos e os problemas aplicam-se a todos os artefatos, embora sejam especialmente usuais para os requisitos não funcionais.
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.
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 tais 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
- Interfaces do usuário final e design da tela
- 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.
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 atividades anteriores que possam limitar a flexibilidade do design.
Por exemplo, pesquise:
- 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?
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
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 atividade de lote)
- Esses dados podem ser movidos ou copiados?
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 nomenclatura que mantêm o controle de recursos da rede e de
atributos
· Serviços de segurança que protegem os recursos da rede contra 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ção que coordenam 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 de larga aplicação, 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.
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.
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.
O cliente possui outras políticas, padrões ou regras não definidas explicitamente nos requisitos?
Por exemplo:
- Todas as interfaces do sistema para usuários finais 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.
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.
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.
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 atividades futuras.
Também é possível que leve muito tempo para que terceiros enviem os números pedidos, então, peça-os agora.
A abordagem recomendada para estabelecer os requisitos de disponibilidade inclui:
- Identificar os verdadeiros usuários finais do sistema, os processos de negócios que eles executam e as horas em que eles realizam esses processos.
- Analisar o impacto da disponibilidade (ou indisponibilidade) do serviço na
capacidade dos usuários finais realizarem os objetivos de negócios
- Especificar os requisitos de disponibilidade que refletem diretamente as exigências dos usuários finais para atingir os objetivos de negócios.
- 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 finais.
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 as necessidades dos usuários finais. 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 final (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").
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?
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 como "breve" e como "inaceitavelmente
lento" de acordo com o relacionamento com esse aplicativo específico (consulte "Critérios de
Desempenho do Processo 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.
Identifique os CRITÉRIOS DE DISPONIBILIDADE E DE 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.
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?
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 atividades 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 atividades 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.
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.
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.
|