Diretrizes:
|
 Especificação de Requisitos do Software |
A Especificação de Requisitos de Software (SRS) abrange todos os requisitos do software para o sistema ou uma parte do sistema. |
Essas informações derivam parcialmente do conteúdo fornecido pela IBM Corporation. 
A Especificação de Requisitos de Software (SRS) se concentra na coleta e na organização de todos os requisitos envolvendo o projeto. Consulte o Plano de Gerenciamento de Requisitos para determinar a localização e a organização corretas dos requisitos. Por exemplo, talvez seja desejável ter uma SRS para descrever todos os requisitos de software para cada característica de um determinado release do produto. Isso pode incluir vários casos de uso do modelo de casos de uso do sistema para descrever os requisitos funcionais dessa característica, 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 você ache útil coletar alguns (ou todos os) requisitos funcionais nos casos de uso e ache prático usar uma ferramenta adequada às necessidades de definição do modelo de casos de uso.
Para nós, não há um motivo forte para destacar as diferenças entre as ferramentas usadas. 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 denominado Especificação de Requisitos de Software (SRS).
O Pacote SRS está obviamente relacionado ao documento de visão. Na verdade, o documento de 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 características do sistema para os detalhes de como essas características serão implementadas na solução.
O que precisamos agora é de um conjunto (ou seja, um pacote) de artefatos que descreva o comportamento externo completo do sistema, isto é, um pacote que diga especificamente: "Aqui está o que o sistema deve fazer para oferecer essas características." É 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. Na verdade, ele tem vários usos à medida que os desenvolvedores entram no trabalho de implementação: Ele serve como uma base de comunicação entre todas as partes, isto é, entre cada um dos 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 contrato 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 funciona como o padrão de referência do gerente do projeto. Provavelmente, o gerente do projeto não terá tempo, energia ou capacidade para ler o código que está sendo gerado pelos desenvolvedores e compará-lo diretamente com o documento de visão. Ele deve usar 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 características que culminaram na produção do documento de 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 controle de qualidade e teste do software. Esses grupos também deveriam estar envolvidos em algumas das discussões preliminares, e é obviamente útil que eles tenham uma ampla compreensão 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 Casos de Uso e Diretrizes: Caso de Uso para obter uma discussão completa da abordagem recomendada para definir requisitos funcionais dentro de um Modelo de Casos de Uso e dos Casos de Uso.
Os requisitos não funcionais do sistema devem estar documentados em Artefato: Especificações Suplementares. Abaixo estão as diretrizes a serem seguidas ao definir esses requisitos.
Enquanto estiver recolhendo e validando os requisitos não funcionais, mantenha listas de Pressupostos e 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 usados 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 usará 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 definir algumas das decisões de design do sistema é o uso de um pacote específico de aplicativos que ofereça organização predefinida de dados e lógica do software. 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:
É importante compreender quais as influências que um pacote de dados terá no design. Se você tiver um pacote de "dados", verifique se você tem disponível a habilidade e o conhecimento corretos sobre o pacote. Suas fontes podem ser:
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:
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 caraterí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 usados 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 especificado 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:
Os requisitos especificam o uso de dados existentes? Em caso afirmativo, isso influenciará o design do sistema. Documente:
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:
Em uma arquitetura tecnológica, talvez você encontre alguns dos seguintes itens definidos para você:
· Serviços de nomes e de diretórios que controlam os atributos e os recursos da rede
· Serviços de segurança que protegem os recursos da rede contra uso não autorizado, registrando os usuários e seus níveis de autorização
· Serviços de tempo que regulam data e hora na rede
· Serviços de gerenciamento de transações que coordenam a recuperação de recursos entre vários sistemas de uma rede
· Hardware
· Software de controle do sistema
· Software de ampla aplicação como o "Office"
· Uso do centro de ajuda
· Regras de segurança
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:
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 usados (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 cliente já possui alguma política para conexões?
Mesmo que não haja arquiteturas técnica ou de rede, ainda pode haver algumas políticas de conexão.
Documente todas as políticas considerando:
O cliente possui outras políticas, padrões ou regras não definidas explicitamente nos requisitos? Por exemplo:
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:
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ócio (por exemplo, "gerenciamento de pedidos de clientes") geralmente será implementado por um "aplicativo" (um termo da tecnologia da informação) ou poderá abranger mais de um aplicativo. Dentro de cada aplicativo, haverá sempre várias "transações" de tecnologia da informação, por exemplo, "pesquisar 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 uma 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 unidade em 4.1: "Unidades de medidas", por exemplo:
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:
A abordagem recomendada para estabelecer os requisitos de disponibilidade inclui:
Siga essas diretrizes ao formar os requisitos de disponibilidade:
Alguns exemplos:
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 usar 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:
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, custos com juros, multas reguladoras etc.).
Forneça quantas respostas forem necessárias para refletir as diferenças nos custos e riscos associados com inatividades 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:
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 programadas (consulte "Horas programadas de serviço"), o impacto da interrupção geralmente variará de acordo com a duração da inatividade e outras condições. Algumas inatividades podem ter um impacto mínimo na capacidade de os usuários executarem os processos de negócios (inatividades breves, aquelas que ocorrem durante períodos do dia de uso reduzido, aquelas que afetam apenas um subconjunto do grupo de usuários, ou aquelas para as quais existe um procedimento de recuo manual aceitável). Outras inatividades, como aquelas que são longas ou ocorrem durante um período "crítico" do dia, terão um impacto mais significativo.
Alguns exemplos:
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 desligamento extensos de toda a instalação de computação.
Com base nos riscos e custos comerciais/financeiros identificados em "Custos da inatividade do serviço", especifique os critérios de disponibilidade que devem ser cumpridos para evitar a restrição significativa de grupos de usuários em realizar os processos de negócios atribuídos a eles. Esses critérios devem ser especificados das seguintes formas:
Seja específico o suficiente para indicar fatores como diferenças entre inatividades planejadas e não planejadas, a hora em que ocorre a inatividade (por exemplo, períodos "críticos" versus períodos de pouco uso), se todos os usuários são afetados ou apenas alguns 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 programadas de serviço" foi sugerido que essas horas provavelmente mudarão, e/ou em "Custos da inatividade do serviço" foi sugerido que os riscos ou os custos de negócios/financeiros associados à interrupção de um serviço provavelmente mudarão durante a vida projetada do sistema, calcule como seria a mudança resultante nos critérios de disponibilidade.
Se alguma criptografia for usada, haverá outras considerações sobre recuperação e disponibilidade. Por exemplo:
A recuperação de desastre é obrigatória dentro do escopo deste projeto de design (disponibilidade durante situações de "desastre", como perda ou desligamento extensos de toda a instalação 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.
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 solicitações 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 inatividade que exija recuperação de dados, é mais importante:
c. Restaurar o sistema o mais rápido possível, ainda que usando 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 uma solicitação do usuário estiver "em processo" no momento da falha, será possível contar com o usuário para redigitar a solicitação após a recuperação do serviço?
4. Existem considerações não técnicas que podem afetar a disponibilidade do sistema (como uma política de negócio que estabelece que o processo A não deve estar disponível 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:
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. Existe alguma política geral, como estatutos de Liberdade de Informação, que pode influenciar o design de segurança do 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 usar 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). Como exemplos, podemos citar: 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 sistema. 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:
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 orientações de design do sistema.
|
Partes deste texto foram usadas sob licença da IBM Corporation |
|
|
Rational Unified Process
|
