Visão geral

Os requisitos do sistema são declarações articuladas de forma clara sobre o que um sistema deve ser capaz de fazer para satisfazer as necessidades e requisitos dos intervenientes e que derivam de requisitos negociais e de requisitos do utilizador, de acordo com a figura “Hierarquia dos Requisitos” abaixo. Devem ser definidos em duas categorias claras, funcionais e não funcionais. Os requisitos funcionais descrevem o comportamento exigido e as funções do sistema. Os requisitos não funcionais descrevem os critérios específicos que podem ser usados para avaliar o funcionamento de um sistema, exemplo, desempenho, segurança, disponibilidade.

Requirements Hierarchy

Hierarquia de Requisitos

Passos:

A Arquitetura do Sistema Alvo descreve o estado final pretendido do sistema, mas a implementação de todas as funcionalidades ao mesmo tempo numa versão é provável que seja incontrolável e não atenda as expetativas dos intervenientes. Consoante a lacuna entre as capacidades atuais e o estado final pretendido, irá precisar de definir o escopo para cada versão em termos de funções do negócio e processos de CRVS a apoiar, tendo em conta o que é realista e trará benefícios iniciais.

1

Documente um roteiro de implementação de alto nível que defina o escopo de todas as versões e o seu calendário de implementação para realização dos Processos de CRVS Alvo e de Arquitetura do Sistema Alvo. Este roteiro deverá mostrar as versões a implementar ao longo do tempo através de uma abordagem modular e gradual, conforme a figura representativa a seguir.

Siga os passos abaixo para cada versão.

Implementation-Roadmap

2

Defina os casos de utilização do sistema para o escopo da versão usando o Modelo de Casos de Uso de CRVS, com base nas interações do utilizador/sistema definidas nos processos de CRVS alvo.

Como elaborar um bom caso de utilização

  • Identificar todos os utilizadores diferentes do sistema e os papéis que desempenham no mesmo
  • Para o papel de cada utilizador, identificar todos os objetivos importantes que estes têm sobre o que o sistema irá apoiar.
  • Criar um objetivo para cada caso de uso, seguindo o modelo de casos de uso. Manter o mesmo nível de detalhes em todos os casos de uso. Os passos nos casos de uso de nível superior podem ser tratados como objetivos para os de nível inferior (ou seja, mais detalhados).
  • Estruturar os casos de uso, mas com atenção ao excesso de estruturação visto que isto pode fazer com que os casos sejam mais difíceis de acompanhar.
  • Rever e validar junto dos utilizadores
3

Documentar personas para todos os atores participantes nos casos de uso do sistema para o escopo da versão usando o Modelo de Personas­ de forma a identificar as características principais do utilizador. A utilização de entradas da pesquisa do utilizador no ponto central das decisões do design assegura que o sistema funcione de uma forma que atenda as necessidades do utilizador.

4

Definir a lista completa de requisitos funcionais para o escopo da versão revendo a arquitetura do sistema alvo, processos, casos de uso e personas para identificar a funcionalidade exigida.

5

Definir a lista completa de requisitos não funcionais para o escopo da versão tendo em consideração os padrões operacionais exigidos e os padrões não funcionais Definir uma lista abrangente de requisitos não funcionais reduz o risco do sistema não funcionar como esperado, permitindo-lhe que defina os padrões de desempenho.

Tipo de Requisitos Não Funcionais Descrição

Desempenho comunicado, requisitos observáveis

Estes requisitos permitem-lhe definir de que forma deseja e precisa que o sistema funcione dentro de parâmetros definidos para assegurar o desempenho superior, minimizar o tempo de inatividade e atender as necessidades do utilizador. Isto incluirá a confiança, disponibilidade, usabilidade e segurança.

Requisitos que apoiem a evolução do sistema de apoio com o tempo

Estes requisitos permitem-lhe definir formas nas quais o sistema pode ser adaptado e evoluir à medida que aumentar o número de utilizadores e quantidade de dados no sistema, e os requisitos se desenvolverem ainda mais. Isto incluirá escalabilidade, adaptabilidade, possibilidade de manutenção e extensibilidade

Principais Requisitos Não Funcionais: Definir os Padrões de Desempenho

Considere os padrões abaixo ao definir os seus requisitos não funcionais para tirar partido dos padrões pré-existentes reconhecidos internacionalmente.

 

Categoria

Subcategoria

Amostras de Padrões

Técnica

Rede de TI

ISO/IEC/IEEE 8802
 

Desenvolvimento do sistema de gestão de qualidade do software

ISO 9001:2000
 

Biometria

ISO/IEC 19784/5
 

Digitalização (de registos históricos em papel)

Departamento das Nações Unidas de Arquivos de Gestão e Secção de Gestão de Registos, Padrão, abril de 2009, Requisitos de Conservação de Registos para Digitalização

Lei das Comunicações e Transações Eletrónicas, 2002 (Lei No. 25 de 2002) África do Sul
 

Telecomunicações

ISO ICS 33.040

Segurança

Gestão de Informação e Registos

ISO 15489 
 

Gestão de Segurança da Informação

ISO/IEC 27002
 

Gestão da Continuidade de Negócio

ISO 223.1

Privacidade

Proteção de Dados

ISO/IEC 27001
 

Liberdade de Informação

PAIA Lei No. 2, 2000, África do Sul
 

Biometria

ISO/IEC 19794/5

Auditoria

Gestão de Informação e Registos

ISO 15489 

 

6

Definir os requisitos de integração do sistema para o escopo da versão, considerando os dados consumidos e fornecidos por cada aplicação e em concordância com o diagrama da entidade-relação.

7

Definir os requisitos de migração de dados:

  • Que dados irão precisar de ser migrados para o novo sistema?
  • Que nível de transformação, erradicação e limpeza é necessário para assegurar que os dados cumpram os requisitos e restrições do sistema alvo?
8

DICA – Seleção de uma Plataforma para Longo Prazo

Ao considerar propostas de potenciais fornecedores, é essencial que avalie qual o tipo de plataforma que se adequa ao seu contexto e que se irá adaptar e crescer à medida que a solução evoluir; isto também irá ajudar a evitar o aprisionamento do fornecedor e tecnologia, um facto que o Kit de Ferramentas de Identidade Digital do Banco Mundial, A Guide for Stakeholders in Africa (Um Guia para os Intervenientes em África) (junho de 2014), identifica de forma clara como constituindo também um desafio para os sistemas de ID Nacional.

“O aprisionamento do fornecedor e tecnologia é uma consideração importante visto que os sistemas de identidade tendem a desenvolver um efeito de rede, ou seja, aumentam de dimensão e valor à medida que aumentam os registos das pessoas e mais programas governamentais e não-governamentais dependem deles. Esta dependência – cujo efeito é frequentemente visto na altura da renovação do contrato, na forma de incumbente ou vantagem de sistema antigo – torna mais difícil (ou mais dispendioso) migrar de um fornecedor ou tecnologia para outro.”

Considerar se quer definir que tipo de plataforma deverá ser desenvolvida. Se desenvolver o sistema internamente, irá precisar de considerar atentamente as opções abaixo. Se adquirir o sistema a partir de um fornecedor externo, pode também pedir uma justificação específica em relação ao uso de um tipo de plataforma, e decidir tendo por base diferentes propostas.

A tabela abaixo traça os prós e contras dos diferentes tipos de plataformas.

Tipo de Plataforma Prós Contras

Software out-of-the-box

  • Custos iniciais menores

  • Sabe o que está a obter

  • Prazo de entrega mais curto

  • Apoio frequentemente incluído

  • Atualizações frequentemente gratuitas /a um custo reduzido

  • Já testado/aperfeiçoado através de outras implementações

  • Disponível apoio comunitário (através de fóruns e utilizadores experientes)

  • Pode ter que ajustar os processos para atender as limitações do software

  • Ignorados os pedidos de recursos se a maioria dos cliente não o exigirem

  • Taxas de personalização elevadas

  • Se os custos forem cobrados por utilizador, estes podem ser muito elevados

Software personalizado

  • Obtém o que precisa/deseja

  • Liberdade de alterar o software consoante as necessidades do empreendimento

  • Desenvolvimento do sistema contextualizado , que toma em consideração as especificações do empreendimento em causa e os funcionários envolvidos

  • Potencial para envolver o setor de TI local

  • Sem custos de licenciamento

  • Capacidade para mudanças no software

  • Apoio de aplicações específicas de pessoas que conheçam a plataforma

  • Custos iniciais elevados

  • Todas as alterações ao software têm custos associados

  • O software pode ainda não satisfazer todas as necessidades do utilizador

  • Dependente das capacidades técnicas da equipa contratada para o desenvolvimento

  • Apoio dependente da disponibilidade dos desenvolvedores e pessoas que conheçam o software personalizado

Software Open Source

  • Poucas, ou nenhumas taxas de licenciamento.

  • Fácil de gerir devido à ausência de requisitos de licenciamento

  • Em contínua evolução à medida que o desenvolvedor faz adições ou mudanças

  • Capacidade para atualizar o software consoante as necessidades do seu negócio

  • Não fica preso a uma plataforma de um fornecedor em particular que só funciona com os seus outros sistemas

  • Sem apoio garantido, dependente da comunidade de utilizadores para responderem ou corrigirem problemas

  • O software pode ficar órfão quando os desenvolvedores deixarem de o atualizar

  • Evolui à medida dos necessidadesdo desenvolvedor ao invés das necessidades do utilizador/negócio

  • Utilizadores dolosos podem atualizar negativamente o software

Solução Hospedada em Nuvem

  • Rentável – custos iniciais menores,  elimina a necessidade de comprar software dispendioso e pagar por licenciamento, e menores custos de servidor tradicional

  • Reduz a necessidade de competências especializadas para a manutenção do serviço

  •  Acessibilidade – permite o acesso a partir de várias plat

  • Adaptabilidade – permite o uso quase imediato sem configuração e instalação da aplicação

  •  Centralização dos dados – todos os seus dados num único lugar que pode ser acedido remotamente

  •  Escalabilidade – permite uma escalabilidade mais fácil e mais flexível para lidar com o aumento das cargas das transações consoante as necessidades

  • Segurança em nuvem

  • Fornece um ambiente de testes flexível

  • A largura de banda baixa  afetará negativamente o desempenho

  • Falta de perspetiva sobre a sua rede – dificuldade na resolução de erros

  • A legislação de proteção de dados e/ou políticas governamentais podem proibir o uso de armazenamento de dados em nuvem
9

Rever os Requisitos do Sistema com os intervenientes relevantes de acordo com a Matriz RACI definida no seu Documento de Implementação do Projeto.

10

Definir um processo de controlo de mudanças que irá assegurar que quaisquer mudanças sejam aprovadas através dos canais adequados e comunicadas a todas as partes. Consultar Guia de Controlo de Mudanças para orientação sobre como fazer isso.