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](http://www.crvs-dgb.org/wp-content/uploads/2016/08/14.jpg)
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](http://www.crvs-dgb.org/wp-content/uploads/2016/08/15.jpg)
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.
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
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.