Licitacion112006bid Anexo4 3requerimientosdealtonivel

CIFI-INFORMATICA – PROCURADURIA GENERAL DE LA NACION
REQUERIMIENTOS DE ALTO NIVEL DEL

SISTEMA DE INFORMACIÓN MISIONAL
Histórico de Revisiones
Fecha Versión Descripción Autor

05-May-05 1.0 Versión Inicial C.García
05-May-05 1.0 Alcance Funcional y Misional C.Díaz
del Sistema
19-May-05 2.0 Revisión observaciones PGN, C. García,
inclusión nuevos
H. Velasquez,
requerimientos y diagramas de
paquetes y casos de uso. D. Rubiano,
C.Díaz
05-Jun-05 3.0 Revisión observaciones PGN. C.García,
C.Díaz
08-Jun-05 4.0 Revisión documentos mapa de D. Rubiano,
sistemas vs requerimientos
C.Díaz
02-Ago-05 4.0 Revisión listado de C.Díaz
requerimientos (sincronización
con documento etapa 7)
Requerimientos de Alto Nivel (Documento Final) Pág. 2

TABLA DE CONTENIDO
CAPÍTULO 1 -INTRODUCCIÓN........................................................................................................ 5
CAPÍTULO 2- OBJETIVOS Y ALCANCE ...................................................................................... 7

2.1 OBJETIVOS.............................................................................................................................. 7
2.2 ALCANCE ............................................................................................................................. 10
CAPÍTULO 3. REQUERIMIENTOS Y RESTRICCIONES GENERALES ................................. 12
3.1 ALCANCE FUNCIONAL Y MISIONAL DEL SISTEMA ................................................................ 12
3.2 SUPUESTOS PARA LA DEFINICIÓN DEL SISTEMA ................................................................... 13
3.3 ACTORES DEL SISTEMA ........................................................................................................ 14
3.4 REQUERIMIENTOS GENERALES ............................................................................................. 15
3.5 RESTRICCIONES GENERALES ................................................................................................ 17
3.6 CARACTERÍSTICAS GENERALES ............................................................................................ 17
CAPÍTULO 4 –REQUERIMIENTOS FUNCIONALES.................................................................. 20
4.1 ALCANCE DE LOS SISTEMAS CON RELACIÓN A LOS PROCESOS ............................................. 20
4.2 LISTADO GENERAL DE REQUERIMIENTOS (CASOS DE USO).................................................. 21

TABLA DE ANEXOS
ANEXO 1 – MATRIZ REQUERIMIENTOS .VS. PROCESOS OPTIMIZADOS … . A1-1
ANEXO 2 – DIAGRAMA DE PAQUETES Y DE CASOS DE USO ….………….... A2-1
ANEXO 3 – DIAGRAMA DE CLASES ……………………………………………… A3-1

CAPÍTULO 1 -INTRODUCCIÓN
El contrato 066 de 2004 suscrito entre la Procuraduría General de la Nación y la Universidad

de los Andes, incluye la formulación de la arquitectura de sistemas de información para las
áreas misionales de la Entidad, para lo cual se ha previsto como una de las fases del trabajo la
formulación de requerimientos de alto nivel.
Este documento de “Requerimientos de Alto Nivel del Sistema de Información Misional”,

corresponde a la versión 4.0, versión final del entregable de la Etapa 4. Paralelamente con la
especificación de requerimientos de alto nivel, la Universidad también definió la arquitectura
del sistema propuesto.
En el capítulo 2, se presentan los objetivos y alcance del documento. En el capítulo 3, se

enumeran los requerimientos y restricciones generales y en el capítulo 4, se describen de
manera general los requerimientos funcionales.
En el Anexo 1 del documento se incluye la matriz de REQUERIMIENTOS POR SISTEMAS

DE INFORMACIÓN VS. PROCESOS OPTIMIZADOS.
Los Anexos 2 y 3 contienen los siguientes diagramas:
ANEXO 2 – DIAGRAMAS DE PAQUETES Y DE CASOS DE USO
ANEXO 3 – DIAGRAMA DE CLASES
Para lograr un mayor entendimiento del documento, la lectura del mismo debe ser
complementada con los documentos “Mapa del Sistema de Información” y “Arquitectura
Seleccionada” que forman parte de los entregables de las etapas 5 y 6, respectivamente del
contrato Uniandes-PGN.
Adicionalmente, en el documento de la Etapa 7 “Requerimientos Detallados Sistema de

Información Misional para la PGN (funcionales)” se incluye como anexo el Glosario para
facilitar la comunicación y el entendimiento de los documentos entregados a la Procuraduría.
En el presente documento y en los restantes documentos del Sistema de Información

Misional de la PGN, el SIAF corresponde al Sistema de Información Administrativo y
Financiero, módulos de Correspondencia y de Recursos Humanos (incluyendo Nómina), que

se encuentren en operación en la Procuraduría en el momento del desarrollo del SIM.

CAPÍTULO 2- OBJETIVOS Y
ALCANCE
En este capítulo se presentan a grandes rasgos, los objetivos y el alcance que debe tener el
sistema de información misional que se define para la PGN. Este sistema debe tener como
usuarios objetivo la PGN, los grupos de interés asociados en un proceso (solicitudes y casos)
y la ciudadanía en general.
2.1 Objetivos
El sistema de información de la PGN debe estar orientado en primera instancia a:
a) Servir de apoyo a los funcionarios de la PGN en la ejecución de las labores para el
cumplimiento de sus funciones misionales de prevención, intervención y disciplinaria.
b) Prestar servicios que permitan una mayor y mejor interacción con la ciudadanía y los
grupos de interés externos de la PGN, facilitándole las actuaciones a la ciudadanía,
contribuyendo además, a la evaluación de percepción sobre el impacto de la función
institucional.
c) Apoyar la labor de coordinación de las actividades propias de la misión de la PGN.
d) Generar información para apoyar, planear y controlar la gestión de las actividades
misionales de los funcionarios de la PGN, así como el control y seguimiento de las
demandas y acciones emprendidas contra la entidad.
e) Generar información para el establecimiento de políticas y programas de la PGN, así
como información requerida para la medición de los indicadores de gestión relacionados
con la misión de la entidad.
f) Apoyar el ejercicio de las funciones conexas: i) legislación y relatoría y ii) de
antecedentes disciplinarios y penales.
El objeto del sistema de información misional para la PGN debe ser el de fortalecer las
actividades propias de la misión con los instrumentos tecnológicos disponibles en la
actualidad para hacer un óptimo uso de los recursos en la entidad. El uso del sistema por los
funcionarios de la entidad debe ser de manera sencilla, amigable, ágil, segura y confiable. El
sistema debe fortalecer los procesos de la entidad de tal manera que agreguen valor dentro de

los propósitos y las funciones que tiene la PGN, y en particular a los grupos de interés de la
entidad. El sistema debe estar basado en las fortalezas de los procesos y productos y debe
apoyar el mejoramiento de las debilidades encontradas en la evaluación de los procesos de la
entidad.
La Universidad en el desarrollo de este proyecto, planteó a la PGN nuevos procesos,
denominados procesos optimizados, que permiten tener una unificación de los eventos más
importantes de las tres funciones misionales. Producto del análisis de estos procesos se han
planteado los requerimientos de alto nivel del sistema de información que debe tener la PGN,
los cuales por consiguiente, están relacionados con las tres funciones misionales de la PGN:
• Función Disciplinaria
• Función de Intervención
• Función Preventiva.
La normalización y homologación de los macroprocesos con anterioridad a la definición del
sistema de información ha permitido tener una mayor claridad en la conceptualización y
definición del sistema misional de la entidad. Se ha buscado homologar los procesos con
miras a estructurar procesos similares que faciliten y simplifiquen la labor de los funcionarios
y que permitan el control y el seguimiento de una manera más adecuada con el sistema.
Con base en lo anteriormente expuesto, la principal característica del sistema de información
misional de la PGN debe ser la de tener un sistema unificado para la ejecución de las tres
funciones misionales de la entidad. Es decir, el sistema debe ser el mismo para la ejecución
de las labores relacionadas con la función preventiva, disciplinaria y de intervención, en
cuanto al manejo de los procesos (solicitudes y casos) y a los mecanismos de actuación. De
igual manera, el sistema de información misional debe ser el mismo para los diferentes
niveles organizacionales de la entidad: central, regional y provincial.
La definición del sistema debe estar enmarcada en los requerimientos funcionales de la PGN
y en los diferentes tipos de información y productos que se manejan en la entidad.
Con respecto a la información, esta debe estar clasificada en:
a) Información relacionada con los procesos misionales (solicitudes y casos) de la PGN
b) Información relacionada con los antecedentes disciplinarios y penales de las personas
c) Información de los recursos disponibles (físicos, humanos, documentales, etc.) para la
ejecución de los procesos misionales (solicitudes y casos) de la PGN
d) Información jurídica relacionada con la legislación utilizada en la PGN y la relatoría de la
misma entidad.
Con base en los análisis previos realizados por la Universidad, la PGN puede ser representada
como una organización orientada por procesos. Por consiguiente, sus sistemas de información
deben estar direccionados por los procesos optimizados, los cuales están orientados a flujos
de trabajo claramente identificables donde siempre se tiene una apertura de un caso, cuando

la solicitud lo amerita, con la verificación de hechos, establecimiento del marco normativo

que aplica al caso, evaluación y decisión del caso y por último, el cierre del caso y archivo de
la respectiva documentación. También es importante destacar que los elementos que se
generan o utilizan en la ejecución de los casos, son comunes a los diferentes tipos de
procesos. Ejemplo de estos elementos son entradas, procesamiento de la información y
salidas similares, definibles e identificables previamente.
El sistema de información misional de la PGN debe estar conformado por dos tipos de sub-
sistemas:
¾ Sub-sistemas de hilo conductor de las actuaciones de la PGN y que sea sensiblemente
similar para todos los procesos misionales de la PGN.
¾ Sub-sistemas de apoyo a las actividades propias del ejercicio de las tres funciones
misionales
Al igual que los procesos optimizados, los sistemas deben cumplir, entre otros, con los
siguientes objetivos generales:
• Unificar los criterios y las actuaciones al interior de la PGN.
• Integrar mejor los recursos/elementos disponibles para la ejecución de las funciones

misionales para aumentar los niveles de productividad y seguridad jurídica en la entidad.
• Asegurar las garantías dentro de los procesos: El sistema debe contribuir a asegurar que
los requisitos que garanticen el proceso (solicitudes y casos) sean aplicados cabalmente
por la PGN, permitiendo que los términos, etapas, etc., sean controlados
automáticamente por el sistema.
• Garantizar la seguridad jurídica del proceso: El sistema debe ayudar a garantizar la

seguridad y rigor jurídico de los procesos (solicitudes y casos), y debe permitir a los
funcionarios de la PGN tener todos la información legal y los antecedentes para soportar
las decisiones; en otras palabras, el objetivo del sistema debe ser el de pasar de un
conocimiento particular a un conocimiento colectivo al interior de la PGN.
• Enfocar esfuerzos en la PGN: El sistema debe apoyar los procesos (solicitudes y casos)
de tal manera que la PGN aumente su cobertura, le permita la fijación de prioridades y
se amplifique el impacto de sus actuaciones por la aplicación de unas mejores prácticas
de trabajo, más eficientes y eficaces alineadas con el plan estratégico de la Procuraduría
y con el modelo de indicadores de nivel gerencial. Esto permitirá un incremento en la
atención y solución de los procesos (solicitudes y casos) de una manera eficaz, eficiente
y confiable jurídicamente.
• Garantizar Transparencia: El sistema misional de la PGN debe brindar información y

garantizar transparencia de las actividades y actuaciones de la PGN hacia la ciudadanía.
• Mejorar la gestión operacional: El sistema debe disminuir la carga operativa en lo que

respecta a manipulación de asuntos, y la asignación y control de actividades por parte
de los funcionarios de la PGN, con el ánimo de concentrar sus esfuerzos en el estudio,

análisis, ampliación de cobertura y seguridad jurídica, lo cual redundará en una mejor

calidad y oportunidad de las decisiones y por ende, en un apoyo decisivo a los propósitos
estratégicos de la PGN.
2.2 Alcance
Los macroprocesos definidos en los procesos optimizados están orientados a gestionar
políticas, ejercer función misional, coordinar y controlar las funciones misionales y ejercer
las funciones conexas. Por consiguiente, el alcance del sistema de información misional para
la PGN debe apoyar:
a) El diseño, formulación y evaluación de las políticas y proyectos relacionados con la
misión de la PGN.
b) Con respecto a la coordinación de funciones misionales, el sistema debe diseñarse de tal
manera que coadyuve a sincronizar las actuaciones de la PGN en todos sus frentes.
c) Con relación al control de las funciones misionales, el sistema debe estar diseñado para
medir, evaluar y producir un mejoramiento continuo de los productos y los procesos
(solicitudes y casos). El mejoramiento continuo se entiende como todas las acciones de
tipo preventivo y correctivo que coadyuven a que las acciones de la PGN tengan el real
impacto sobre la administración pública y sobre la Nación.
d) Ejercer Funciones Misionales: para la ejecución de las funciones misionales, de manera
general el sistema debe:
¾ Manejar las solicitudes y casos de manera unificada para las tres áreas misionales
de prevención, intervención y disciplinario.
¾ Manejar y procesar las solicitudes que llegan a la PGN.
¾ Abrir, administrar y cerrar los casos, controlando el respectivo trámite al interior de
la entidad, ejecutando las actividades requeridas para cada uno.
¾ Tener un control global de los procesos, con puntos de control comunes a los
mismos, bajando en los niveles de detalle en la medida que se requiera para las
funciones de coordinación y control de la función misional.
¾ Manejar todas las variantes que se presentan en los diferentes tipos de procesos
(casos), es decir, manejar las secuencias o flujos de los casos, las cuales pueden ser
invariantes o dinámicas.
e) Ejercer Funciones Conexas
¾ Con respecto a administrar la información legal: Corresponde al registro,
actualización y consulta de documentación en materia de conceptos y decisiones de
la PGN; resoluciones, directivas y circulares; y Jurisprudencia de las Altas Cortes.
¾ Con respecto a administrar información asociada: Corresponde al registro,
actualización y consulta de antecedentes disciplinarios y penales.

El sistema de información para la misión de la PGN no solo debe apoyar los procesos de la
PGN sino también debe brindar todas las ayudas necesarias para la generación de los
productos (resultado de la atención de solicitudes y de la ejecución de los casos), en las
diferentes categorías planteadas por la Universidad, por igual para las tres funciones de la
misión:
¾ Productos principales de los procesos
¾ Productos asociados
¾ Información del proceso
¾ Información asociada (estado y seguimiento)
¾ Información legal y de relatoría
Así como los procesos optimizados han sido clasificados en obligatorios u opcionales y
comunes y específicos, con respecto al alcance, el sistema debe manejar los siguientes tipos
de información para cada uno de los casos que se abren en el sistema:
• Información común obligatoria: la cual aplica para todas las solicitudes y casos que
se abren en el sistema y es la información mínima requerida para la atención de las
solicitudes y la ejecución de los casos.
• Información común opcional: la cual aplica para todos los casos que se abren en el
sistema y es opcional para la ejecución de los casos.
• Información específica obligatoria: la cual aplica para todos los casos de un mismo
tipo (Ej: laboral, derechos humanos, ambiental, menor y familia, etc.) que se abren en
el sistema y es la información mínima requerida para la ejecución de los casos de ese
tipo.
• Información específica opcional: la cual aplica para todos los casos de un mismo tipo
(Ej: laboral, derechos humanos, ambiental, menor y familia, etc.) que se abren en el
sistema y es opcional para la ejecución de los casos de ese tipo.

CAPÍTULO 3.
REQUERIMIENTOS Y
RESTRICCIONES GENERALES
3.1 Alcance Funcional y Misional del Sistema

Para determinar el alcance funcional y misional del sistema, se tomaron como base los
documentos generados en las etapas de Entendimiento y de Levantamiento y Mejoramiento
de Macroprocesos del presente proyecto.
El documento de entendimiento “Entorno de la Entidad y Funciones de cada Área Misional”,
detalla en el Capítulo 4 - Descripción de las Áreas Misionales, las competencias de la PGN
por cada una de las funciones constitucionales. La gráfica siguiente sintetiza dichas
funciones:

Control
disciplinario
Promoción, Vigilancia
protección y superior
Funciones
defensa de lo con fines
D.H preventivos
Actuación
ante las
autoridades
administrativas
judiciales
Estas funciones tienen como fin último garantizar que los funcionarios en el cumplimiento
de sus funciones se ajusten al derecho en sus actuaciones; que los procesos administrativos y
judiciales se desarrollen con la garantía total para las partes; que la vigilancia preventiva
inhiba comportamiento y promueva acciones para la mejor gestión pública y por último que
las relaciones sociales se basen en el respeto de los derechos humanos como marco de
convivencia.
Para el cumplimiento de estas funciones constitucionales, la PGN ejerce funciones misionales
y funciones conexas (de apoyo a la misión), las cuales han sido analizadas en el capítulo
anterior.
Los documentos de la etapa de Levantamiento y Mejoramiento de Macroprocesos, TOMO I-
Procesos Existentes y TOMO II – Propuesta de Optimización, describen en detalle los
macroprocesos que soportan las 3 funciones misionales y los macroprocesos relacionados con
las funciones conexas de administración de información legal e información asociada.
3.2 Supuestos para la Definición del Sistema
La definición del sistema se ha realizado teniendo en cuenta los siguientes criterios:

1. La PGN contará con toda la infraestructura de hardware, software de base,

comunicaciones y redes suficientes para la operación del sistema misional.
2. El sistema debe ser diseñado teniendo en cuenta los macroprocesos institucionales y no

los procesos individuales de cada una de las áreas de la PGN.
3. La arquitectura del sistema de información debe estar orientada y unificada para las tres
funciones misionales de la PGN: prevención, intervención y disciplinaria.
4. La arquitectura del sistema de información debe estar orientada y unificada para la

utilización en los tres niveles organizacionales de la entidad: central, regional y
provincial.
5. La arquitectura tecnológica que apoye el sistema debe estar orientada con base en la
tecnología disponible en el mercado.
6. Con respecto a la información jurídica, manejar en el sistema lo que es exclusivo a las

acciones de la PGN.
7. Los subsistemas del sistema de información misional estarán integrados entre sí y con los
restantes sistemas de la PGN tanto de tipo estratégico como de apoyo administrativo de
forma automática. De igual manera, el sistema debe estar integrado con los sistemas
externos de otras entidades del Estado con los cuales se requiera la integración de forma
automática.
3.3 Actores del Sistema
En el siguiente cuadro se encuentra el esquema de los actores involucrados en el sistema.

3.4 Requerimientos Generales
a) Manejar de manera global el control de las etapas de los casos, y de manera particular,
cada una de las actividades para ejecutar los casos. El sistema debe permitir la selección
de una etapa y dentro de cada una de ellas las actividades correspondientes.
b) Tener un control global de las solicitudes y los casos, con puntos de control comunes
para las diferentes funciones misionales, bajando en las etapas y actividades en la
medida que se requiera para las funciones de coordinación y control de la función
misional respectiva.
c) Permitir el manejo de diferentes casos que involucren las tres áreas misionales
(preventiva, disciplinaria e intervención) para una misma solicitud. No deberían existir
restricciones para que una solicitud sea trabajado por las tres áreas misionales al mismo
tiempo.
d) El sistema, dentro de sus funcionaes misionales, debe incluir las solicitudes y casos
manejados por la Oficina Jurídica de la entidad, relacionados con estas funciones, tales
como demandas, acciones o tutelas contra la PGN.
e) Los procesos (casos) deben tener descriptores que permitan transferir automáticamente la
información al subsistema que maneje la información jurídica (relatoría) para describir

los documentos.
f) Consultar la información del sistema por diferentes aspectos tales como por caso, agente,
dependencia, entidad y otros.
g) Controlar la vigencia de los hechos, para determinar la prescripción de los casos
disciplinarios.
h) Tener relacionados los documentos asociados con el proceso (solicitudes o casos), bien
sean digitalizados, o en cualquier otro tipo de formato (Ej: word, excel, etc.) y su
administración asociada. Estos documentos pueden ser de entrada a los procesos
(solicitudes y casos) o de salida generados por la PGN.
i) El traslado por competencia debe garantizar la identificación única del proceso (solicitud
o caso) para seguirle la pista al interior de la entidad.
j) Estar en capacidad de soportar actuaciones conjuntas tanto externas como internas en la
ejecución de los casos, es decir, el sistema también debe permitir el registro de la
información de seguimiento de las actuaciones de la entidades externas tales como la
Rama Judicial, Fiscalía y Oficinas de Control Interno Disciplinario de las entidades
estatales cuyos procesos se encuentran en intervención por parte de la PGN.
k) Ser simple y amigable, que no se tenga involucrado el “árbol de decisión” del caso en la
herramienta del flujo de trabajo.
l) Contar con un módulo de administración de los casos que permita fraccionarlos,
unificarlos, embeberlos, reasignarlos y registrar los motivos de cada situación. También
debería permitir dar “peso” a los casos según su naturaleza y complejidad.
m) Registrar y manejar los instrumentos como actividades relacionadas a cada caso.
n) Contar con procesos de control de calidad para evitar y/o corregir que los funcionarios
sigan los caminos del “árbol de decisión” que no deben.
o) Manejar la situación donde caso maneja múltiples documentos y un documento puede ser
manejado por varios casos..
p) Registrar el histórico de las diferentes actuaciones de los funcionarios.
q) El sistema debe lanzar alertas de vencimientos y términos para las actividades de un caso.

3.5 Restricciones Generales
A continuación se enumeran las restricciones que se han identificado hasta el momento para
la definición del sistema y para los subsistemas en sí mismos y hasta dónde llegan y qué no
contendrían los sistemas.
a) Disponibilidad de recursos económicos para que la PGN cuente con los recursos
necesarios (hardware, software de base, comunicaciones y redes) para la operación de los
sistemas.
b) Los sistemas estratégicos y de apoyo administrativo de la PGN, así como los sistemas
misionales existentes que continuarán operando en la entidad, deberán ser adaptados para
su integración con el sistema de información misional de la PGN.
c) Los eventos (etapas, actividades y actuaciones) que se registren deben ser los mínimos
necesarios para no volver inoperante el sistema para los abogados que adelantan los
procesos misionales (solicitudes y casos).
d) Con relación a la información jurídica la PGN, solo deberá ingresar información asociada
con su rol, para la restante información jurídica, preferiblemente debe promover
convenios o contratos para adquirir esta información externamente, ya que mucha de esta
información existe en otras entidades del estado o a través de empresas privadas que la
suministran con fines comerciales.
e) Acceso a la red de la PGN, por cualquier medio, físico o móvil en la participación de las
audiencias verbales.
f) El sistema debe ser diseñado considerando los requerimientos de seguridad de la

información, de acuerdo con los niveles de criticidad de la información manejada por los
subsistemas.
3.6 Características Generales
A continuación se enumeran una serie de características o condiciones generales que deben

cumplir los sistemas:
a) El sistema debe definirse considerando los procesos transversalmente, sin suscribirlos a

una Delegada o área específica, permitiendo que los traslados de los procesos de un área
a otra se realicen de manera transparente.
b) La generación de estadísticas y reportes debe ser uniforme y general.

c) Debe ser un sistema homogéneo con entradas y salidas preestablecidas.
d) La navegación por el sistema para los funcionarios de la PGN debe ser similar. La
navegación debe ser uniforme, se deberían tomar algunos conceptos y navegaciones
actuales para hacer una transición suave a los nuevos sistemas.
e) Los términos (plazos) y modalidades de las actividades de los casos deben ser
independientes y deben estar definidas como parámetros en el sistema
f) El sistema debe permitir homogenizar el grado o nivel de detalle con el cual se le hace
seguimiento a los casos.
g) El sistema no solo debe registrar eventos (etapas, actividades y actuaciones), sino que
debe ser inteligente para detectar posibles omisiones, duplicaciones, etc. En algunos
casos, como por ejemplo violaciones a los derechos humanos o infracciones al DIH, el
sistema debería también orientar al funcionario en la calificación de las conductas y las
pruebas relevantes que deben ser solicitadas según el tipo de infracción.
h) La información restringida debe tener los mecanismos de seguridad suficientes para

mantener la confidencialidad de los casos.
i) Por el alto nivel de criticidad de la calidad de información para el buen funcionamiento y

la sostenibilidad del sistema, la información debe filtrarse y generar procesos de alerta
tempana al respecto. El sistema debería manejar diferentes “grados” de seguimiento, por
ejemplo, tipificando los casos como de connotación internacional, nacional, regional o
local, teniendo en cada caso, una escala de seguimiento diferente.
j) Se debe manejar con claridad la dispersión de procesos, duplicidad de procesos y las

múltiples decisiones en casos colectivos.
k) El sistema debe ser autodocumentado funcionalmente, con ayudas automáticas.
l) Generar y hacer un seguimiento a flujos paralelos, atendiendo la naturaleza de los

procesos.
m) El sistema de manejo de la información jurídica debe tener esquemas de ingreso de la

documentación de manera ágil y estandarizada para aumentar la cobertura en cuanto al
contenido de sus bases de datos.
n) El sistema debe estar en capacidad de manejar la parametrización de las etapas y

actividades para las diferentes funciones misionales de la PGN en los casos de cambios
de legislación y adicionalmente, debe poder funcionar en forma simultánea los casos con
las diferentes condiciones de cada una de las leyes. (Ejemplo: procesos que se tramitan
con la Ley 200 de 1995 y procesos con la Ley 734 de 2003).

o) Las interfaces que se desarrollen entre el SIM, SIRI y otros sistemas no misionales de la
PGN, deben ser desarrolladas con el esquema de solicitudes y respuestas entre los
sistemas, con el propósito de que si alguno de los sistemas tiene cambios en el futuro, el
desarrollo de los restantes sistemas se impacte lo menos posible. No obstante, podrán
existir interfaces que por sus características o por las condiciones de los sistemas
existentes como SIRI, puedan requerir otro tipo de interoperabilidad entre ellos. Un
ejemplo de esto sería la interface requerida entre SIMIP y SIRI (SIMIP_INT_2) cuando
se requiere transmitir la información de los fallos sancionatorios en SIMIP a SIRI.

CAPÍTULO 4 –REQUERIMIENTOS
FUNCIONALES
4.1 Alcance de los Sistemas con Relación a los Procesos
Los requerimientos del sistema de información propuestos en el presente documento, cubren

los macroprocesos definidos en la propuesta de optimización, y que se enumeran a
continuación:
a) Comunes obligatorios (COB)

b) Comunes opcionales (COP)
c) Específicos opcionales (EOP)
d) Específicos obligatorios (EOB)
Sub-procesos comunes obligatorios (COB)
COB_Valorar y Radicar Solicitud

COB-Clasificar Asunto y Asignar Competencia
COB-Asignar Servidor Público
COB-Evaluar Asunto
COB-Abrir Caso
COB-Verificar Hechos
COB-Establecer Marco Normativo
COB-Evaluar y Decidir Caso
COB-Cerrar Caso
COB-Archivar Documentación
Sub-procesos Comunes opcionales (COP)
COP_Presentar Instrumento
COP_Resolver Instrumento

Sub-procesos específicos opcionales (EOP)
EOP_PDI_Tomar Medidas Preventivas

EOP_PIJ_Revisar Expediente en Despacho Judicial o Administrativo
EOP_PFP_Hacer Seguimiento
Sub-procesos específicos obligatorios (EOB)
EOB_PRE_Divulgar Información Jurídica

EOB_PRE_Recopilar Información Legal
EOB_PRE_Atender Consultas Internas
EOB_PSI_Aplicar Sanción
EOB_PSI_Registrar Evento
EOB_PSI_Verificar Cumplimiento
EOB_PSI_Controlar Calidad
EOB_PSI_Emitir Certificado Antecedentes
En el Anexo 1 de este documento se muestra la relación existente entre los procesos

optimizados (definidos en el Entregable 2 – TOMO II Procesos Optimizados) y los sistemas
de información (identificados en el Entregable 5 – Mapa de Sistemas).
4.2 Listado General de Requerimientos (Casos de Uso)

En el cuadro de las siguientes páginas se identifican los requerimientos de alto nivel
utilizando la nomenclatura de UML para los Casos de Uso. Se ha identificado el nombre del
caso de uso, una breve descripción y los actores involucrados. Este listado general de
requerimientos ha sido clasificado por los sistemas de información identificados en el
documento del Mapa de Sistemas.

SISTEMA NOMBRE DESCRIPCION ACTORES

REQUERIMIENTO
SIMIP1 Asignar competencia El presente caso de uso tiene como objetivo asignar la dependencia que se hará cargo de la solicitud. El Servidor PGN
(Dependencia) sistema automáticamente debe asignar la dependencia competente para una solicitud o petición basado
en la información registrada en el sistema en el caso de uso de SIAM – Administrar Competencias de las
Dependencias, en el que se describen los temas y normas que determinan las competencias.
Esta asignación automática se puede realizar cuando los ciudadanos o autoridades diligencien la
solicitud o petición de manera completa, en cuyo caso se cuenta con toda la información.
SIMIP2 Evaluar duplicidad El presente caso de uso tiene como objetivo evaluar la duplicidad de solicitudes ingresadas al sistema, y Servidor
advertir al servidor para que decida si definitivamente la solicitud debe ser abierta o no. Si la solicitud
llega por la Web y el sistema detecta duplicidad, la advierte al usuario, indicándole en número de
radicación de la solicitud o caso existente. El mecanismo también debe funcionar cuando la solicitud se
inicia de oficio. También debería funcionar si lo que se reporta es el inicio de una investigación
disciplinaria, para el ejercicio del poder preferente.
SIMIP3 Acumular solicitud El presente caso de uso tiene como objetivo combinar la información de una solicitud con otra ya Servidor
existente, vinculando las dos solicitudes indicando cual solicitud depende de la otra e inactivando la
solicitud dependiente.
SIMIP4 Reversar El presente caso de uso tiene como objetivo permitir reversar la acumulación efectuada sobre una Servidor PGN
acumulación solicitud o un caso.
SIMIP5 Abrir un documento El presente caso de uso tiene como objetivo permitir que una solicitud recibida en correspondencia se Servidor PGN
de correspondencia convierta en más de una solicitud en el sistema en el momento en que se considere que debe ser en división de
en varias solicitudes atendida por varias dependencias (ejemplo: tiene un componente de intervención, uno de disciplinario, registro y
etc). control
SIMIP6 Acumular caso El presente caso de uso tiene como objetivo combinar la información de varios casos en uno solo, Servidor
vinculando la información, creando una relación de dependencia, de un caso en otro existente e
inactivando el caso dependiente.
Requerimientos de Alto Nivel –Funcionales (Documento Final) Pág. 22


REQUERIMIENTO
SIMIP7 Fraccionar Caso El presente caso de uso tiene como propósito abrir un caso de uso existente, en otro nuevo heredando la Servidor PGN
información del caso original cuando así se indique. Este aplica cuando un proceso se debe abrir en dos
o mas procesos (hay ruptura de la unidad procesal y se debe abrir un nuevo caso).
SIMIP8 Relacionar casos El presente caso de uso tiene como objetivo relacionar dos o más casos con el fin de hacer seguimiento Servidor PGN
a casos relacionados. Este caso de uso es llamado desde los casos de uso de acumular y fraccionar
casos, y consiste en registrar los IUCs de los casos que se relacionaron y que tipo de relación se ejecutó
(ej: acumulación, fracción, etc).
El caso de uso también puede ser llamado directamente para relacionar dos casos con un tipo de
relación genérica que el servidor puede definir, dando la justificación para la relación.
SIMIP9 Complementar El presente caso de uso tiene como objetivo complementar la información de la solicitud, de acuerdo al Servidor de la
Información Solicitud área misional disciplinaria, de intervención (judicial, administrativa o jurídica) o de prevención. PGN como
Para solicitudes ingresadas por la web, éste requerimiento forma parte de la información recolectada operador del
cuando se hace el ingreso de la solicitud. De igual manera cuando la solicitud es ingresada por un Sistema SIMIP
servidor PGN en una dependencia como solicitud de oficio. Para solicitudes ingresadas por el sistema
SIAF, la información incorporada al SIAF en el departamento de correspondencia es la información
mínima de la solicitud, una vez el registro ha llegado a SIMIP via interfaz, la información se complementa
en SIMIP en la oficina de registro y control.
SIMIP10 Asignar El presente caso de uso tiene como objetivo asignar a una solicitud -valorada como de competencia de la Procurador
Servidor/Equipo de PGN- o a un caso, el servidor o servidores (equipo de trabajo) que se encargarán del mismo, es decir Delegado,
Trabajo a asignar el titular de la responsabilidad del trámite del caso. Regional o
Solicitud/Caso Si se asignan servidores el sistema debe brindar la posibilidad de señalar sus roles, por ejemplo, para el Territorial, Jefe
caso de las comisiones disciplinarias especiales, la presidencia y los colaboradores. o Coordinador
El sistema debe prever la posibilidad de que un servidor, de la dependencia, también se encuentre de Grupo
adscrito o se pueda adscribir, a un Comité o Comisión Institucional (dependencia virtual) creada para
atender determinados tipos de casos o problemáticas.
El tipo de asignación puede ser automática o manual.
SIMIP11 Recibir El presente caso de uso tiene como objetivo indicar qué documentación física debe haber sido recibida Dependencia


REQUERIMIENTO
Documentación en una dependencia de la PGN, y asociarla a una solicitud o caso existente en el sistema.
Física Solicitudes Esta tarea se podrá realizar con ayuda del código de barras que se le coloca a la documentación al
momento de entrar a la PGN, y que es generada por SIAF. Cuando la documentación llegue a la
dependencia, se leerá el código de barras del documento y de esta manera quedará registrado en el
sistema la dependencia que posee los documentos. Si la documentación asociada a una solicitud no
llega a su receptor después de un tiempo definido, se generará una alarma a la División de
Correspondencia.
SIMIP12 Contrastar solicitudes El presente caso de uso tiene como objetivo listar las solicitudes asignadas a una dependencia contra el Dependencia
recibidas del SIAF recibo de la documentación física correspondiente. Esto con el fin de detectar documentos que no hayan
contra llegado a la dependencia físicamente pero cuya solicitud ya se encuentra asignada a la dependencia en
documentación física. el sistema.
SIMIP13 Definir Actuación El presente caso de uso tiene como objetivo registrar la acción que corresponda seguir, una vez se ha Servidor PGN
evaluado el asunto. El sistema proporcionará al servidor de la PGN, una lista de opciones posibles entre
las que puede seleccionar la más indicada, por ejemplo: abrir caso, generar auto u oficio para remitir a
otra entidad, etc. Estas acciones corresponden a las salidas del proceso Evaluar Asunto.
SIMIP14 Asignar Prioridad, El presente caso de uso tiene como objetivo asignar prioridad a una solicitud, así como adscribir la Servidor PGN
Políticas y Proyectos solicitud/caso a una determinada política institucional y a un proyecto particular si es del caso. en la
a una Solicitud/Caso Prioridad es el grado de importancia relativa para la PGN, y está determinada por el grado de Dependencia
connotación de la solicitud o caso (alta, media, baja), para focalizar esfuerzos.
Política es una clasificación por línea de acción, las cuales se encuentran definidas en el mapa
estratégico de la entidad.
SIMIP15 Abrir Caso El presente caso de uso tiene como objetivo asignar un identificador único de caso (IUC). Este número Servidor PGN
servirá para identificar cada caso (preventivo, disciplinario, de intervención o jurídica) a lo largo de toda la Sistema
actuación de la PGN, sin importar si el caso cambia de dependencia en el nivel central, territorial o por
traslado de competencia.
SIMIP16 Vincular IÚS con IÚC El presente caso de uso tiene como objetivo relacionar una solicitud con un caso, mediante los Sistema
identificadores correspondientes.
Este caso de uso puede ser utilizado en dos oportunidades: Cuando se abre un caso o cuando se desea


REQUERIMIENTO
acumular una solicitud nueva a un caso ya existente. Si es en apertura de caso, el sistema hace la
operación automáticamente. Si es por acumulación, el servidor tiene que suministrar la información de la
solicitud y el caso que desea vincular, así como una justificación de la acción.
SIMIP17 Gestionar Actores del El presente caso de uso tiene como objetivo registrar en el sistema los actores del caso (agentes internos Servidor PGN
caso o externos) que participan en el proceso pero que no son los titulares de la responsabilidad del trámite
del caso. (Los titulares de la responsabilidad, que pueden ser un servidor o un equipo de trabajo de la
PGN, se asignan en el respectivo caso de uso).
La información registrada en este caso de uso debe facilitar el envió de oficios o de notificaciones a los
actores del proceso, el sistema podrá tomar datos registrados por cada actor y llevarlos directamente al
oficio correspondiente.
SIMIP18 Definir Ruta y Plan de Tiene como objetivo definir la ruta y el plan de acción a seguir en el desarrollo de un caso. Servidor de la
Actividades PGN
- Definir Ruta: El servidor determina el camino a seguir (Marcar ruta), con base en una ruta sugerida por
el sistema siguiendo las consideraciones lógicas y legales correspondientes. Por ejemplo, si el caso es
disciplinario, debe indicar si se va por proceso ordinario o verbal y en el primero, si se va por indagación
preliminar o por investigación. Si es intervención, debe indicar si es agente especial o agente ordinario.
Si es preventivo, la determinación de la ruta de las acciones que le permitirán comprobar los hechos. La
validación de la ruta, en cuanto validez de las actividades (precedencia, tipo de actividades por área, etc)
se hará teniendo en cuenta las etapas y actividades registradas en el sistema mediante el caso de uso de
SIAM de Administrar etapas, actividades e información asociada.
- Definir Plan de Acción: El servidor dice que es lo que va a hacer. El sistema le puede sugerir algunas
actividades, como en derechos humanos, en donde se cuenta para disciplinario con un manual de
pruebas por tipo de violación y para preventivo, con un instrumento guía. Puede ser un plan general de
acción o puede ser detallando una a una las actividades. El plan también se puede rearmar a medida que
transcurre el caso. El Plan de Acción permitirá al servidor llevar un control ordenado de las actividades a
realizar y su propósito, igualmente, el Plan le permitirá al sistema, controlar los términos, para el Caso, la
etapa o la actividad, según el caso, generando al servidor las alertas tempranas que se definan.
SIMIP19 Registrar Actividades Tiene como objetivo registrar las actividades y actuaciones (decisiones) realizadas en el caso. Servidor de la
y Actuación/Decisión PGN
realizadas Actividades: ejemplos de actividades para Disciplinario son: las declaraciones de testigos, las


REQUERIMIENTO
declaraciones de las víctimas, las visitas especiales, los peritazgos, la exposición libre de los
disciplinados, etc. Hay actividades relacionadas con el caso y otras con los actores del caso.
Actuaciones / Decisiones: Hay actuaciones que implican decisiones, por ejemplo, abrir indagación
preliminar, abrir investigación disciplinaria, suspender al servidor investigado, decretar archivo, formular
cargos y dictar fallo. Al igual que para las actividades, hay algunas decisiones relacionadas con el actor
(ejemplo: sanción, la suspensión y el archivo) y otras relacionadas con el proceso, como la nulidad.
SIMIP20 Alertar Vencimiento El presente caso de uso tiene como objetivo generar alertas sobre el próximo vencimiento de alguno de SIMIP
Casos los casos, términos o decisiones de las etapas o actividades/actuaciones definidas para un caso. Este
será un proceso automático que barre los casos y sus etapas, y genere unas alertas de los términos que
están a punto de vencerse, de acuerdo a unos parámetros de fechas y requisitos establecidos.
Se debe considerar la generación de varios tipos de alerta. Por ejemplo, unas alertas tempranas y otras
alertas de términos vencidos. Las primeras darán al servidor de la PGN tiempo suficiente para la
ejecución de la tarea, las segundas pueden ser utilizadas para el monitoreo de actividades.
SIMIP21 Registrar El presente caso de uso tiene como objetivo permitir al servidor registrar las conclusiones en el análisis Servidor PGN
Conclusiones del caso, una vez se haya emitido la decisión, concepto o informe que pone fin a la actuación de la PGN
Debe constar de una sección donde en forma resumida el servidor registra las conclusiones del caso y
debe tener la posibilidad de adjuntar información adicional como anexo.
Esta sección de conclusiones puede incluir una plantilla en la que se pueden, por ejemplo, manejar
temas y subtemas, normatividad aplicada para la solución del caso y un breve resumen de la solución del
caso y las razones o fundamentos. Registro que además, puede facilitar el trabajo de relatoría.
SIMIP22 Generar oficios, El presente caso de uso tiene como objetivo elaborar los documentos de comunicaciones (ejemplo: Servidor PGN
autos autos, actos, oficios) requeridos en el trámite de una solicitud o caso. Para ello se cuenta con plantillas
preestablecidas en SIAM, que pueden ser importadas como guía del documento. Una vez el usuario ha
completado el documento, el software debe validar que los campos requeridos han sido diligenciados y
adjuntarlo al registro – solicitud o caso.
Vale la pena aclarar, que para algunas plantillas, el sistema podrá automáticamente llenar los campos
con base en la información del caso y una vez revisado por el usuario podrá ser anexado al caso. El caso
de uso de SIAM (Administrar Etapas, Actividades, Actuaciones e Información Relacionada) describe una


REQUERIMIENTO
tabla básica del sistema que relaciona documentos (plantillas) con actividades/actuaciones, la cual
permitirá al sistema de manera automática cuando se registra una actividad o actuación en el sistema,
desplegar una lista de documentos asociados. Una vez seleccionado el documento, el sistema traerá
automáticamente la plantilla diligenciada con los datos del registro. Una vez el documento este completo
se anexará al caso.
SIMIP23 Marcar Cierre Caso El presente caso de uso tiene como objetivo cerrar el caso. Consiste en cambiar el estado del registro en Servidor PGN
el sistema, indicando que el caso esta cerrado.
En algunos casos el sistema automáticamente puede cerrar el caso, para no tener que hacerlo en forma
manual. Por ejemplo, en disciplinario, si el servidor registra en el sistema la decisión de archivar la
actuación disciplinaria y ésta cobra ejecutoria, sin importar si es en primera o segunda instancia, el
sistema puede cerrar el caso.
SIMIP24 Marcar Archivo Físico El presente caso de uso tiene como objetivo indicar que la documentación asociada al caso ya ha sido SIMIP
Caso enviada a Archivo Central. Esta acción se realiza una vez el caso ha pasado a cosa juzgada (para
disciplinario), acción preventiva concluida (para preventivo) o proceso de intervención concluido (para
intervención o jurídico) y se cumpla la fecha estipulada para establecer dicha acción (ver caso de Uso
Marcar Cierre del Caso). Este marcado se realiza mediante un proceso automático que verifica los casos
cerrados que son candidatos a pasar a Archivo Central, escogiendo los que deben pasar y haciendo la
anotación respectiva.
SIMIP25 Manejar ubicación del El presente caso de uso tiene como objetivo permitir el registro de la ubicación y seguimiento de los Servidor PGN
archivo en la expedientes en las dependencias hasta que el expediente (documento físico) pase a archivo Central.
dependencia
SIMIP26 Administrar préstamo El presente caso de uso tiene como objetivo administrar el manejo de préstamo de expedientes al interior Servidor PGN
de expedientes de la PGN.
SIMIP27 Indicar cumplimiento El presente caso de uso tiene como objetivo permitir que sobre el sistema SIMIP, se indique a un caso Servidor de la
por caso preventivo que tiene control de advertencia, si la Entidad hizo o dejó de hacer lo que normativamente le PGN
correspondía. Si la indicación tiene connotación positiva, se le debe deshabilitar el control de advertencia.
Deben quedar previamente registradas las recomendaciones contenidas en el informe final, ligándolas al
seguimiento, para que en este caso de uso se puedan registrar los avances en el cumplimiento de las
recomendaciones u observaciones formuladas por la PGN en el marco de la acción preventiva. Como la


REQUERIMIENTO
acción preventiva puede recaer simultáneamente sobre varias entidades, las recomendaciones deberían
atarse a la entidad para facilitar el seguimiento y verificación de cumplimiento, por ejemplo, chequeando
en la lista cuales se van cumpliendo, la forma de cumplimiento, la fecha y la persona responsable
SIMIP28 Registra seguimiento El presente caso de uso tiene como objetivo permitir que sobre el sistema SIMIP, se registren las Servidor de la
diferentes actividades que realiza el servidor PGN en torno a las actividades de seguimiento a la Entidad PGN
objeto del caso de prevención, que está bajo seguimiento. Por cada gestión realizada, el servidor debe
indicar las acciones realizadas, la fecha en que se desarrolló y los resultados obtenidos.
SIMIP29 Reabrir Caso El presente caso de uso tiene como objetivo permitir la reapertura de un caso. Este caso de uso debe Servidor PGn
cambiar el estado del caso que ya estaba cerrado, esta situación se presenta cuando un caso que ya ha
sido fallado debe ser revisado nuevamente por eventos como el de una tutela.
SIMIP30 Generar listado de El presente caso de uso tiene como objetivo generar un listado de alerta de los fallos que se han Servidor PGN
fallos no enviados a registrado en SIMIP pero que no han sido enviados a SIRI.
SIRI El caso de uso Transmitir sanciones SIMIP a SIRI, permite diligenciar el formato SIRI desde SIMIP para
que pueda ser enviado por el usuario al SIRI. Dado que la opción de envío de dicha información es
manual y no automática, existe la posibilidad de que el usuario no envié a SIRI un fallo determinado. El
objetivo de este caso de uso es generar un listado que permita revisar periódicamente la relación de
casos fallados en SIMIP contra SIRI.
SIMIP31 Administrar Equipos El presente caso de uso tiene como objetivo permitir sobre el sistema SIMIP, para un caso en particular: Procurador
de Trabajo Definir, consultar, actualizar e inactivar la información concerniente a los equipos de trabajo, los roles que Delegado,
los componen y los servidores PGN inscritos en dichos roles. Regional o
Un equipo de trabajo puede ser creado bajo uno de dos tipos: Equipo de trabajo titular – Responsable del Territorial, Jefe
desarrollo de un caso, Equipo de trabajo no titular – De apoyo en el desarrollo de un caso. Un Equipo de o Coordinador
trabajo lo componen roles tales como por ejemplo “Jefe de equipo” e “Investigador”. de Grupo.
SIMIP32 Manejar Agenda Tiene como objetivo permitir el manejo de la agenda de los servidores, entendiéndose como servidor un Servidor PGN
Servidores Públicos funcionario de la PGN. La agenda se maneja respecto a las actividades y tareas que debe cumplir un
servidor en el desarrollo de los casos que se le asignan.


REQUERIMIENTO
SIMIP_INT_1 SIMIP_INT_1- Recibir Este caso de uso tiene como objetivo registrar en línea, en SIMIP, las solicitudes que se ingresan en SIAF
Solicitudes SIAF y que se consideran misionales
misionales SIAF
SIMIP_INT_2 SIMIP_INT_2- El presente caso de uso tiene como objetivo la comunicación de un fallo sancionatorio en SIMIP para el Servidor PGN
Transmitir sanciones registro de la sanción en el SIRI. Se activa con la decisión sancionatoria en firme y se cumple con el
SIMIP a SIRI diligenciamiento del formulario respectivo y el envío a SIRI.
(diligenciar formato
SIRI)
SIMIP_INT_3 SIMIP_INT_3. Este caso de uso tiene como objetivo generar un archivo con documentos de salida para que se maneje SIMIP
Proveer información la correspondencia de salida en SIAF. Este caso de uso se utiliza para el manejo de comunicaciones
de documentos de enviadas por la Procuraduría.
salida al SIAF
SIMIP_INT_4 SIMIP_INT_4. Este caso de uso tiene por objetivo, que un usuario autorizado en SIMIP pueda sugerir al administrador Servidor PGN
Sugerir Caso a de SIREL, la inclusión en SIREL de un caso, como representativo, para que éste pueda ser consultado
SIREL por los usuarios de SIREL.
SIMIP_INT_5 SIMIP_INT_5 Recibir Este caso de uso tiene como objetivo registrar en línea los datos de las solicitudes y peticiones SIMP
Solicitudes/Peticiones ingresadas por el SIC, en SIMIP. Incluye lo registrado en los casos de uso de SIC: Registrar Solicitudes,
WEB SIC Registrar Peticiones e Ingresar Inicio y Actuaciones Procesos disciplinarios reportados por OCID
(Oficinas de Control Interno Disciplinario).
SIREL1 AdministrarTemas El presente caso de uso tiene como objetivos consultar, establecer (ingresar-capturar), modificar y borrar Administrador
por cada uno de los tipos de información jurídica (Legislación, jurisprudencia o doctrina) del sistema SIREL
SIREL, los diferentes temas de clasificación, búsqueda y acceso a los registros de los casos
representativos y de las informaciones jurídicas que se almacenan en dicho sistema.
Por cada tema, se debe poder establecer, consultar, modificar y borrar subtemas (restrictotes) con el
ánimo de poder realizar de forma avanzada los procesos de clasificación, búsqueda y acceso de
información almacenada en el sistema SIREL. A su vez, por cada subtema, se debe poder consultar,
establecer, modificar y eliminar el conjunto ordenado de términos o palabras (Descriptores) de mayor
relevancia, dentro del concepto manejado por el subtema. A su vez, sobre las palabras definidas se
deben poder establecer relaciones, con tal suerte de que por cada una se puedan identificar sinónimos y
antónimos (un sinónimo y un antónimo son cada uno un descriptor ya almacenado en el sistema).


REQUERIMIENTO
SIREL2 AdministrarServidore El presente caso de uso tiene como objetivo consultar/ingresar (inscribir)/modificar/eliminar los servidores Administrador
sPGNTemas PGN según los temas (con conjunto de descriptores y restrictotes asociados) definidos para la SIREL
información jurídica y los casos representativos, almacenados en el sistema SIREL. Esto con el fin de
proporcionar información relevante a los servidores PGN cuando estén trabajando casos particulares en
SIMIP, así como permitir la comunicación oportuna producto de la incorporación y/o modificación de la
información sobre el sistema SIREL.
SIREL3 ComunicarCambios a El presente caso de uso tiene como objetivo comunicar, vía e-mail, a los usuarios sobre la incorporación Sistema SIREL
ServidoresPGN de una nueva información jurídica y de la liberación de casos representativos. También comunica las
correcciones y modificaciones sobre la información ya existente (información jurídica y casos
representativos ya liberados), que se hayan registrado en el sistema SIREL.
SIREL4 Administrar Este caso de uso tiene por objetivo que el usuario pueda administrar la información jurídica (se refiere a Administrador
información jurídica la normatividad que soporta el desarrollo de los diferentes casos que lleva la PGN – Por ejemplo: SIREL.
Normas, leyes, decretos, sentencias y doctrinas), teniendo en cuenta que esta debe ser ingresada Servidor PGN.
(capturada), algunas veces simplemente consultada, y en casos de error, modificada (corregida) o
eliminada. La información jurídica que se administrará obedece a los siguientes tipos: Legislación,
jurisprudencia y doctrina. En referencia a los servidores de la PGN, en general la información que se
administra en la implementación del presente caso de uso, sólo puede ser consultada y dependiendo del
tipo de usuario no se debe admitir ninguna clase de alteración del documento, salvo que el Administrador
necesite hacer correcciones sobre el texto del mismo (Que por alguna razón se haya incorporado un
texto que no coincida con el original del documento que contiene la información jurídica).
SIREL5 Administrar links El presente caso de uso tiene como objetivo, consultar/establecer (ingresar - crear)/modificar/borrar Administrador
internos dentro de un texto de una información jurídica, un link en referencia a otro fragmento del mismo texto SIREL
(Subtexto).
SIREL6 Administrar links El presente caso de uso tiene como objetivo, consultar/establecer (ingresar - crear)/modificar/borrar Administrador
externos dentro de un texto de una información jurídica, un link en referencia a otra información jurídica. SIREL
SIREL7 ConsultarListaLinksIn El presente caso de uso tiene como objetivo, dados unos parámetros de búsqueda, mostrar de forma Administrador
formaciónJurídica resumida, una lista donde se pueda distinguir para las diferentes informaciones jurídicas seleccionadas, SIREL


REQUERIMIENTO
los links internos y externos establecidos. En el caso de los links externos se debe indicar la calidad de
los mismos, determinando si son de carácter histórico o no.
SIREL8 Buscar información El presente caso de uso tiene como objetivo permitir la búsqueda y consulta de información jurídica o de Administrador
jurídica casos sugeridos, dados algunos criterios de búsqueda. No necesariamente se debe suministrar valores a de SIREL y
todos los criterios y la búsqueda de la información puede obedecer a una combinación de los mismos. servidor PGN.
SIREL9 Generar documento El presente caso de uso tiene como objetivo permitir la generación automática de documentos con las Administrador
informaciones jurídicas y los casos representativos que se encuentren a partir de una búsqueda de SIREL
información (Ver el caso de uso “Buscar Información Jurídica”) sobre el medio de almacenamiento del
sistema. Este caso de uso debe permitir en el documento generado, la incorporación de títulos, subtítulos
e índices, además de mantener los links internos y externos a discreción del usuario.
SIREL_INT_1 SIREL_INT_1. Este caso de uso tiene como objetivo que un usuario autorizado en SIMIP pueda consultar SIMIP
Consultar Temas automáticamente de SIREL los diferentes temas (grupos de descriptores) allí creados, esto con el fin de
que el usuario pueda asociar un caso a un tema específico.
SIREL_INT_2 SIREL_INT_2. Este caso de uso tiene por objetivo tomar los casos sugeridos por usuarios SIMIP, y presentarlos al Administrador
Evaluar casos administrador de SIREL, para que él haga una evaluación de los mismos y decida si se deben o no ser SIREL.
sugeridos tenidos en cuenta en SIREL como casos representativos. Servidor PGN.
SIAM1 Mantener Banco de Tiene como objetivo la administración, generación y modificación de plantillas que utilice la Procuraduría Administrador
Plantillas para generar comunicaciones, autos, decisiones, resolución de instrumentos, etc. SIAM.
SIAM2 Administrar Recursos Tiene como objetivo permitir la asignación en préstamo de los diferentes recursos físicos. Además de la Servidor PGN
Físicos creación, consulta, eliminación y actualización de los datos de un recurso.
Un recurso físico puede ser una sala de audiencia, un proyector, o cualquier otro elemento de apoyo
administrativo. También es cualquier elemento de apoyo misional, como bienes y equipos entregados al
servidor para el cumplimiento de sus funciones misionales, además de los elementos de prueba que
integran al proceso disciplinario (manejo de la cadena de custodia). También se contempla en el presente
caso de uso el préstamo de expedientes.
Se debe tener en cuenta que los elementos de prueba deben ser asociado a un caso y siempre se debe
conocer la ubicación física de donde se encuentran.


REQUERIMIENTO
SIAM3 Administrar Servidor El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, definir y modificar la Administrador
PGN disponibilidad de un servidor PGN, además de la consulta de los datos tomados del Sistema de Nómina. SIAM.
La disponibilidad de un servidor PGN, está dada en términos de porcentajes de tiempo diario. En caso de Usuario SIMIP.
no ocupar el 100%, se debe indicar el tiempo no disponible en que actividades lo ocupará.
SIAM4 Administrar Oficios Tiene como objetivo permitir la administración de oficios, estableciendo sobre los mismos los diferentes Servidor PGN
estados por los que puede pasar. La implantación de este caso de uso debe permitir control permanente
sobre los diferentes oficios que se generen.
SIAM5 Administrar Políticas El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, administrar la información de Servidor PGN
y Proyectos las políticas y los proyectos de la institución.
SIAM6 Administrar Inventario El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, administrar la información de Procurador
de Entidades las entidades con las que se relaciona la PGN. Delegado
SIAM7 Administrar El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, administrar la información de Procurador
Competencias de las las competencias de cada Dependencia. La base para este requerimiento será la ley (decreto 262). Delegado
Dependencias En este punto se debe tener en cuenta que existen las Dependencias Organizacionales y las Virtuales.
Las primeras corresponden a las que tienen un reconocimiento organizacional formal dentro de la
estructura de la PGN (Cuentan con una oficina - una ubicación física) y las segundas son producto de la
conformación de comisiones y comités con servidores PGN que pertenecen a las Dependencia
Organizacionales.
SIAM8 Administrar Etapas, Tiene como objetivo permitir registrar las etapas, actividades y actuaciones y su información asociada Servidor PGN
Actividades, como documentos, términos y procedimientos, entre otros. (administrador
Actuaciones e Los datos que se registran en el presente caso de uso, son los que usará el usuario para la definición de sistema).
Información rutas y actividades en la implementación del caso de uso “Definir Ruta y plan de actividades” del sistema
Relacionada SIMIP.
SIAM_INT_1 SIAM_INT_1Cargar El presente caso de uso tiene como objetivo permitir sobre el sistema SIAM, el cargue de los datos de los Administrador
Datos Servidores servidores PGN inscritos en el sistema de Nómina de la Entidad. La implementación del presente caso de SIAM
PGN uso se debe ejecutar en forma periódica.
SIC1 Registrar Solicitudes El presente caso de uso tiene como objetivo permitir el ingreso de demandas de servicio. Dichas Ciudadano o
demandas de servicio corresponden a solicitudes o quejas nuevas asociadas a alguna de las áreas Servidor PGN


REQUERIMIENTO
misionales de la PGN. Puede ser utilizado por los ciudadanos que vía Web accedan al sistema o por
servidores de la PGN que de forma oficiosa ante el conocimiento de un hecho ingresan una solicitud a
SIMIP.
Vale la pena aclarar que dichas solicitudes corresponden a: Quejas disciplinarias, Solicitudes de acción
preventiva, Solicitudes de Intervención Judicial o Administrativa o Solicitudes de Ejercicio del Poder
Preferente que se registran por primera vez en el sistema. Las peticiones de los ciudadanos sobre casos
ya existentes, para conocer por ejemplo información detallada del caso, se ingresan al sistema por el
caso de uso Registrar Peticiones.
SIC2 Registrar Peticiones El presente caso de uso tiene como objetivo permitir el ingreso de peticiones vía Web (derechos de Ciudadano
petición) de los ciudadanos para solicitar información a la PGN sobre conceptos, o casos ya existentes.
Para ello se deberá registrar una petición con la información mínima necesaria para identificar el caso y/o
la solicitud, para luego remitirse a la dependencia o funcionario a cargo quien se encargará de resolver o
contestar dicha petición.
Las peticiones aquí registradas corresponden a consultas que implican análisis, fundamentación y
posición por parte de la Entidad. Las consultas que pueden sen generadas por el sistema se encuentran
descritas en el caso de uso Consultar Información.
SIC3 Consultar El presente caso de uso tiene como objetivo brindar información a los ciudadanos o autoridades sobre Ciudadano o
Información servicios de la PGN en las distintas áreas misionales. Entidad
Este caso de uso incluye los siguientes tipos de consultas:
- SIRI (Link al aplicativo): Consultas de antecedentes en línea a través de la funcionalidad del aplicativo
SIRI.
- Relatoria (Link al aplicativo): Consultas de información de relatoría a través de la funcionalidad de
SIREL. (Caso de uso SIREL-Buscar información)
- Consulta Solicitudes y/o Casos: Consultas de información sobre casos registrados en SIMIP. Dichas
consultas deben tener en cuenta las disposiciones legales sobre la reserva de las investigaciones.
- Consulta peticiones: Consultas sobre derechos de petición registrados en SIMIP.
Vale la pena aclarar que las dos últimas -consultas sobre SIMIP-, son aquellas en las que el ciudadano
puede obtener información directa del sistema, y no requieren de un análisis por parte de la dependencia.
En los casos en los que la consulta se refiera a un aspecto que implique análisis, fundamentación y
posición por parte de la Entidad, se deberá registrar una petición con la información mínima necesaria
para identificar el caso y la solicitud, para luego remitirse a la dependencia o funcionario a cargo quien


REQUERIMIENTO
dará respuesta a la solicitud. (Caso de uso Registrar Peticiones).
SIC4 Generar datos El presente caso de uso tiene como objetivo generar reportes que permitan a la PGN conocer quienes Sistema
estadísticos de son los ciudadanos que están usando los servicios de la Entidad para poder medir la demanda de
demanda y servicio y la respuesta institucional al requerimiento, y eventualmente, poder llevar a cabo encuestas para
medir la percepción de los mismos.
evaluación de
servicio Se trata entonces de dos cosas, de un lado, llevar un registro de las demandas de servicio y peticiones a
la PGN, generando estadísticas por tipo, área, dependencia, etc… Y de otro lado, emprender tareas de
medición de la respuesta institucional, tales como casos resueltos, los tiempos de respuesta, el nivel de
satisfacción del usuario, etc…
SIC5 Ingresar Inicio y El presente caso de uso tiene como objetivo que las Oficinas de Control Interno Disciplinario de las Oficinas de
Actuaciones Proceso entidades del Estado puedan ingresar información del inicio de procesos disciplinarios por la Web para Control Interno
Disciplinario poner en conocimiento de la Procuraduría la apertura de investigaciones disciplinarias y de esta manera Disciplinario
facilitar a la PGN el ejercicio del Poder Preferente. (OCID)
reportados por OCID
Para reportar inicio de procesos disciplinarios, se debe tener en cuenta el mapa estratégico de la PGN,
de tal forma, que únicamente se reporten aquellos casos que se adscriben a las prioridades
institucionales.
De igual manera podrán reportar las principales decisiones del proceso disciplinario, tales como: archivo,
apertura de investigación, cargos, fallo y suspensión del servidor investigado de tal manera que la
Procuraduría pueda ejercer el poder preferente en etapas distintas al inicio del proceso disciplinario.
SIC6 Evaluación El presente caso de uso tiene como objetivo marcar de manera automática el NO ejercicio del poder Sistema
automática del Poder preferente de la PGN sobre los inicios y actuaciones de procesos disciplinarios reportados por las oficinas
Preferente de control interno disciplinario - OCID, de acuerdo a unas políticas establecidas por la Entidad.
Una vez la OCID reporta el inicio o la actuación sobre un proceso disciplinario a la PGN, la dependencia
competente tiene 3 días hábiles para manifestar si ejerce o no el poder preferente.
SIC_INT_1 SIC_INT_1. Generar Este caso de uso tiene como objetivo generar un archivo con las solicitudes y peticiones que un SIC.
archivo de ciudadano/entidad haya reportado vía Web, en el sistema SIC. La información del archivo será cargada
solicitudes/peticiones en el SIAF (ver el caso de uso “SIAF_INT_1. Cargar solicitudes ingresadas por la Web”).
ingresadas por la
Web

ANEXO 1 – MATRIZ REQUERIMIENTOS POR

SISTEMA DE INFORMACION .VS. PROCESOS
OPTIMIZADOS
Requerimientos de Alto Nivel (Documento Final) Pág. A1-1

TABLA DE CONTENIDO
Pág.
1. Matriz Requerimientos por Sistemas de Información .vs. Procesos Optimizados........... 3

1. Matriz Requerimientos por Sistemas de Información .vs. Procesos Optimizados
La siguiente matriz relaciona los requerimientos con cada uno de los sistemas propuestos; adicionalmente relaciona el sub-proceso de la
autopista al que corresponde.
# REQUERIMIENTO SISTEMA PROCESO
SIMIP1 Asignar competencia (Dependencia) SIMIP COB- Clasificar asunto y Asignar competencia
SIMIP2 Evaluar duplicidad SIMIP COB- Evaluar Asunto
SIMIP3 Acumular solicitud SIMIP COB- Evaluar Asunto
SIMIP4 Reversar acumulación SIMIP COB- Evaluar Asunto
SIMIP5 Abrir un documento de correspondencia en varias solicitudes SIMIP N/A
SIMIP6 Acumular caso SIMIP COB- Evaluar Asunto
SIMIP7 Fraccionar Caso SIMIP COB- Evaluar Asunto
SIMIP8 Relacionar casos SIMIP COB- Evaluar Asunto
SIMIP9 Complementar Información Solicitud SIMIP COB- Valorar y Radicar Solicitud
SIMIP10 Asignar Servidor/Equipo de Trabajo a Solicitud/Caso SIMIP COB- Asignar Servidor Publico
SIMIP11 Recibir Documentación Física Solicitudes SIMIP COB- Valorar y Radicar Solicitud
SIMIP12 Contrastar solicitudes recibidas del SIAF contra documentación física. SIMIP COB- Valorar y Radicar Solicitud
SIMIP13 Definir Actuación SIMIP COB- Evaluar Asunto
SIMIP14 Asignar Prioridad, Políticas y Proyectos a una Solicitud/Caso SIMIP COB- Evaluar Asunto
SIMIP15 Abrir Caso SIMIP COB- Abrir Caso
SIMIP16 Vincular IÚS con IÚC SIMIP COB- Abrir Caso
SIMIP17 Gestionar Actores del caso SIMIP COB- Abrir Caso
SIMIP18 Definir Ruta y Plan de Actividades SIMIP COB- Abrir Caso
SIMIP19 Registrar Actividades y Actuación/Decisión realizadas SIMIP COB- Verificar hechos
COB- Evaluar y Decidir Caso
COP- Presentar Instrumento
COP- Resolver Instrumento
EOP-PDI- Tomar Medidas Preventivas

SIMIP20 Alertar Vencimiento Casos SIMIP COB- Verificar hechos

SIMIP21 Registrar Conclusiones SIMIP COB- Evaluar y Decidir Caso
SIMIP22 Generar oficios, autos SIMIP COB- Evaluar y Decidir Caso
SIMIP23 Marcar Cierre Caso SIMIP COB- Cerrar caso
SIMIP24 Marcar Archivo Físico Caso SIMIP COB- Archivar documentación
SIMIP25 Manejar ubicación del archivo en la dependencia SIMIP COB- Archivar documentación
SIMIP26 Administrar préstamo de expedientes SIMIP COB- Archivar documentación
SIMIP27 Indicar cumplimiento por caso preventivo SIMIP EOP-PFP- Hacer seguimiento
SIMIP28 Registra seguimiento SIMIP EOP-PFP- Hacer seguimiento
SIMIP29 Reabrir Caso SIMIP COB- Evaluar Asunto
SIMIP30 Generar listado de fallos no enviados a SIRI SIMIP EOB-PSI- Aplicar Sanción
SIMIP31 Administrar Equipos de Trabajo SIMIP COB- Asignar Servidor Publico
SIMIP32 Manejar Agenda Servidores Públicos SIMIP N/A
SIMIP_INT_1 SIMIP_INT_1- Recibir Solicitudes misionales SIAF INTERFAZ COB- Valorar y Radicar Solicitud
SIMIP_INT_2 SIMIP_INT_2-Transmitir sanciones SIMIP a SIRI (diligenciar formato INTERFAZ EOB-PSI- Aplicar Sanción
SIRI)
SIMIP_INT_3 SIMIP_INT_3. Proveer información de documentos de salida al SIAF INTERFAZ N/A
SIMIP_INT_4 SIMIP_INT_4. Sugerir Caso a SIREL INTERFAZ EOB_PRE_Recopilar información Jurídica
SIMIP_INT_5 SIMIP_INT_5 Recibir Solicitudes/Peticiones WEB SIC INTERFAZ COB- Valorar y Radicar Solicitud
SIREL1 AdministrarTemas SIREL EOB_PRE_Recopilar información Jurídica
SIREL2 AdministrarServidoresPGNTemas SIREL COB – Establecer Marco Normativo
SIREL3 ComunicarCambiosServidoresPGN SIREL COB – Establecer Marco Normativo
EOB_PRE_Divulgar Información Jurídica
SIREL4 Administrar información jurídica SIREL EOB_PRE_Recopilar información Jurídica
SIREL5 Administrar links internos SIREL EOB_PRE_Recopilar información Jurídica
SIREL6 Administrar links externos SIREL EOB_PRE_Recopilar información Jurídica
SIREL7 ConsultarListaLinksInformaciónJurídica SIREL EOB_PRE_Atender Consultas Internas

SIREL8 Buscar información jurídica SIREL EOB_PRE_Atender Consultas Internas

SIREL9 Generar documento SIREL EOB_PRE_Atender Consultas Internas
SIREL_INT_1 SIREL_INT_1. Consultar Temas INTERFAZ EOB_PRE_Divulgar Información Jurídica
EOB_PRE_Atender Consultas Internas
SIREL_INT_2 SIREL_INT_2. Evaluar casos sugeridos INTERFAZ EOB_PRE_Recopilar información Jurídica
SIAM1 Mantener Banco de Plantillas SIAM N/A
SIAM2 Administrar Recursos Físicos SIAM N/A
SIAM3 Administrar Servidor PGN SIAM COB- Asignar Servidor Publico
SIAM4 Administrar Oficios SIAM N/A
SIAM5 Administrar Políticas y Proyectos SIAM N/A
SIAM6 Administrar Inventario de Entidades SIAM N/A
SIAM7 Administrar Competencias de las Dependencias SIAM COB- Clasificar asunto y Asignar competencia
SIAM8 Administrar Etapas, Actividades, Actuaciones e Información Relacionada SIAM COB- Verificar hechos
COB- Evaluar y Decidir Caso
SIAM_INT_1 Cargar Datos Servidores PGN INTERFAZ COB- Asignar Servidor Publico
SIC1 Registrar Solicitudes SIC COB- Valorar y Radicar Solicitud
SIC2 Registrar Peticiones SIC COB- Valorar y Radicar Solicitud
SIC3 Consultar Información SIC N/A
SIC4 Generar datos estadísticos de demanda y evaluación de servicio SIC N/A
SIC5 Ingresar Inicio y Actuaciones Proceso Disciplinario reportados por OCID SIC COB- Valorar y Radicar Solicitud
COB- Verificar hechos
SIC6 Evaluación automática del Poder Preferente SIC COB- Evaluar Asunto
SIC_INT_1 SIC_INT_1. Generar archivo de solicitudes/peticiones ingresadas por la INTERFAZ COB- Valorar y Radicar Solicitud
Web

ANEXO 2 – DIAGRAMAS DE PAQUETES Y

CASOS DE USO

TABLA DE CONTENIDO
Pág.
1. Definiciones...................................................................................................................... 5
2. Diagrama de paquetes .................................................................................................... 8
3. Casos de uso de SIC ........................................................................................................ 9
4. Casos de uso de SIMIP ................................................................................................. 10
4.1 SIMIP.Solicitud ......................................................................................................... 10

4.2 SIMIP.Caso............................................................................................................... 11
4.2 SIMIP.Interfaz........................................................................................................... 12
5. Casos de uso de SIAM .................................................................................................. 13
6. Casos de uso de SIREL................................................................................................. 14

CONTROL DE VERSIONES DEL DOCUMENTO
Fecha Versión Revisado por Comentario

Actualización
20/May/2005 1.0 Hernán Velásquez. Versión inicial
Disney Rubiano
26/May/2005 2.0 Hernán Velásquez. Actualización: Las funcionalidades del sistema
Disney Rubiano SISEN están implícitas en otras funcionalidades
del sistema SIMIP.
9/Jun/2005 3.0 Hernán Velásquez. Actualización de los casos de uso de SIC y de
Disney Rubiano SIMIP.
02/Ago/2005 4.0 Hernán Velásquez. Versión Final – Actualización de los diagramas
Disney Rubiano de casos de uso y de paquetes con la última
versión de requerimientos.

INDICE DE ILUSTRACIONES
Ilustración 1 Componentes de un diagrama de casos de uso. .................................................. 5

Ilustración 2 Estructura gráfica de un paquete. ....................................................................... 7
Ilustración 3 Diagrama de paquetes......................................................................................... 8
Ilustración 4 Diagrama del paquete SIC. ................................................................................. 9
Ilustración 5 Diagrama del paquete SIMIP.Solicitud............................................................. 10
Ilustración 6 Diagrama de los paquetes SIMIP.Caso. .......................................................... 11
Ilustración 7 Diagrama de los paquetes SIMIP.Interfaz ....................................................... 12
Ilustración 7 Diagrama del paquete SIAM. ............................................................................ 13
Ilustración 8 Diagrama del paquete SIREL............................................................................ 14

1. Definiciones
Para entender el contenido del presente anexo, se presenta a continuación una breve
explicación sobre casos de uso, diagramas de casos de uso y de paquetes.
Caso de uso:
Un caso de uso es una descripción narrativa textual de los procesos de una empresa o sistema,
desde el punto de vista del análisis y diseño orientado a objetos, un caso de uso es la
herramienta por medio de la cual en el análisis de requerimientos funcionales, se descubre y
expresan los procesos y necesidades del negocio.
Diagrama de clases:
Un diagrama de casos de uso explica gráficamente un conjunto de casos de uso de un
sistema, los actores y la relación entre éstos y los casos de uso. Estos últimos se muestran en
óvalos y los actores son figuras estilizadas. Hay líneas de comunicaciones entre los casos de
uso y los actores; las flechas indican el flujo de la información o el estímulo (ver la
ilustración 1).
El diagrama tiene por objetivo ofrecer una clase de diagrama contextual que nos permite
rápidamente conocer los actores externos de un sistema y las formas básicas en que lo
utilizan.
Flujo de información o estímulo

Actor
Ilustración 1 Componentes de un diagrama de casos de uso.
Se debe tener en cuenta que existen relaciones entre casos de uso, estas son:
Relación <<include>>
Cuando un caso de uso se asocia con otro mediante esta relación, se debe
interpretar que el caso de uso incluido debe ejecutarse para que el que lo
incluye, se pueda desarrollar completamente. Gráficamente se representa por
una línea punteada más una flecha que va del lado del caso de uso incluido, la
línea se acompaña del texto <<include>>.
Relación <<extends>>
interpretar que el caso de uso que extiende se puede ejecutar en algún punto

desde el caso de uso que hace la extensión. Gráficamente se representa por

una línea punteada más una flecha que va del lado del caso de uso incluido, la
línea se acompaña del texto <<extends>>.
Relación de generalización
interpretar que el caso de uso que es generalizado tiene la funcionalidad
básica que es específica a uno o más casos de uso sobre los cuales se hace la
generalización. Gráficamente se representa con una línea punteada que
asocia a los casos de uso, terminada con un triángulo, el cual va del lado del
caso de uso generalizado.
Paquete:
Por otro lado, es necesario tener en cuenta que los casos de uso del presente anexo, están
agrupados por paquetes. El lenguaje UML ofrece el mecanismo paquete que permite
describir los grupos de elementos o subsistemas. Un paquete es un conjunto de cualquier tipo
de elementos de un modelo, en este caso, de casos de uso. Un sistema puede examinarse
íntegramente dentro del ámbito de un solo paquete de alto nivel, por ello la representación
elegida es la de paquetes, uno por cada uno de los sistemas que conformarán el sistema de
información de la PGN. Los sistemas representados por paquetes son:
SIC
SIMIP
SIAM
SIREL
A su vez, de acuerdo a los diferentes subprocesos definidos en el documento de optimización,

al interior de cada paquete que integra un sistema, se presentan otros paquetes (paquetes
subordinados).
Un paquete se muestra gráficamente como una carpeta con etiquetas. Los paquetes
subordinados se incluyen en su interior. El nombre del paquete se encuentra dentro de la
etiqueta si el paquete describe sus elementos; en caso contrario estará en el centro de la
misma carpeta. En la ilustración 2, se puede ver la estructura gráfica de un paquete.

Ilustración 2 Estructura gráfica de un paquete.
En el caso de la ilustración 2, el sistema SIMIP, estaría representado por un paquete de

nombre SIMP y un paquete subordinado de nombre Solicitud. Para referirse al nombre un
paquete subordinado, es necesario antecederlo del nombre del paquete que lo contiene
separado por un punto. En el caso de la ilustración 2, el nombre del paquete VALORACION,
es: SIMIP.Solicitud 1.
Sobre los paquetes existen también relaciones de dependencia que son reprensados por líneas
y flechas. Las flechas indican la dirección de la dependencia.
A continuación se presentan los diagramas de los diferentes paquetes que conformarán el

sistema de información de la PGN y los diferentes diagramas de casos de uso por cada
sistema (paquete).
1
Los paquetes se nombran con el estándar del inglés, en razón a que estos posteriormente se
convertirán en componentes de Software en un lenguaje de programación.

2. Diagrama de paquetes
SIAM SIMIP SIREL
Solicitud
ServidorPGN
Consulta
Interfaz ClasificacionAsignacion EvaluacionAsignacion
Recopilacion
ValoracionRadicacion Asignacion
AsignacionCompetencia
Divulgacion
Caso
EtapaActividad InterfazRecopilacion
Apertura Seguimiento VerificacionHechos Documentacion
Administracion
EvaluacionDecision Cierre Agenda ServidorPGN Listado
Interfaz
SIAF SIRI SIREL SIC
SIC
Valoracion Evaluacion Consulta Estadistica Interfaz

Radicacion
Ilustración 3 Diagrama de paquetes.

3. Casos de uso de SIC
Los casos de uso del SIC son:
SIC
ValoracionRadicacion
Ingresar Inicio y Actuaciones
Registrar Registrar
Ciudadano Proceso Disciplinario
Solicitudes Peticiones
Reportados por OCID
«extend» Oficionas de Control Interno
Disciplinario (OCID)
Evaluacion
Servidor PGN Evaluación Automática

del poder preferente
«extend»
Consulta
Consultar
Información
Entidad
Estadistica
Generar Datos Estadísticos

de Demanda y de
Evaluación del Servicio SIC
Interfaz
SIC_INT_1-Generar Archivo de
Solicitudes/Peticiones
Ingresadas por la WEB
Ilustración 4 Diagrama del paquete SIC.

4. Casos de uso de SIMIP
Teniendo en cuenta tres elementos relevantes dentro del SIMIP, como lo son: Solicitud, Caso
e Interfaz, a continuación se presentan los respectivos paquetes, uno por cada elemento
relevante:
4.1 SIMIP.Solicitud
SIMIP
Solicitud
ClasificacionAsignacion
Asignar
Competencia
EvaluacionAsignacion
Servidor PGN
Reabrir Caso Abrir un Documento de

Evaluar Solicitud
Correspondencia en
Varias Solicitudes Servidor PGN en División de
Registro y Control
Acumular Reversar
Solicitud Acumulacion
Evaluar
Acumular Fraccionar
Duplicidad
Caso Caso Relacionar
Casos
ValoracionRadicacion
Contrastar Solicitudes
Complementar Recibidas del SIAF
Recibir Documentación
información Contra Documentación
Física Solicitudes Procurador Regional Procurador Territorial
Física
«include»
Asignacion «include»
Administrar Asignar Servidor/Equipo

Equipos de Trabajo de Trabajo a
«include»
Solicitud/caso Procurador Delegado «include»
Servidor PGN -Operador de SIMIP
Jefe o Coordinador de Grupo
Definir Actuación
Asignar Prioridad Servidor PGN

Políticas y Proyectos
a una Solicitud/Caso
Ilustración 5 Diagrama del paquete SIMIP.Solicitud.

4.2 SIMIP.Caso
SIMIP
Caso
Apertura
Vincular IUS
Abrir Caso Gestionar Caso Definir Ruta y Plan de
con IUC
Actividades
Servidor PGN -SIMIP
Seguimiento
Indicar Cumplimiento Registrar

por Caso Preventivo Seguimiento
SIMIP
Documentación
Servidor PGN
Manejar Ubicación del
Administrar Préstamo
Archivo en la
de Expedientes
Dependencia
VerificacionHechos
Registrar Actividades y
Servidor PGN Alertar Vencimiento
Actuación/Decisión SIMIP
Casos
Realizadas
EvaluacionDecision
Registrar Generar Oficios,

Conclusiones Autos
AgendaServidorPGN
Manejar Agenda
Servidores
Cierre
Marcar Archivo Marcar Cierre Caso
Físico Caso
Servidor PGN
Listado
Generar listado de fallos

no enviados a SIRI
Ilustración 6 Diagrama de los paquetes SIMIP.Caso.

4.2 SIMIP.Interfaz
Interfaz
SIAF SIAF
SIMIP_INT_1-Recibir SIMIP_INT_3-Proveer
Solicitudes MIsionales SIAF Información de documentos
de salida a SIAF
Servidor PGN
SIRI
SIREL SIMIP
SIC
SIMIP_INT_ SIMIT_INT_4-Augerir
SIMIP_INT_5-Recibir
2-Transmitir Sanciones Caso a SIREL
Solicitudes/Peticiones
SIMIP aSIRI
WEB SIC
Ilustración 7 Diagrama de los paquetes SIMIP.Interfaz

5. Casos de uso de SIAM
Los casos de uso de SIAM son:
SIAM
ServidorPGN
Interfaz
Administrar
Servidor PGN SIAM_INT_
1-Cargar Datos
Usuario SIMIP Servidores PGN
AsignacionCompetencia
Administrar
Competencias de
las Dependencias
Procurador Delegado
Administrador SIAM
«extend»
EtapaActividad
Administrar Etapas,
Actividades,
Actuaciones e
Información Relacionada
Administracion
Mantener Administrar
Banco de Recursos
Plantillas Físicos
Administrador SIAM
Administrar
Políticas y
Proyectos
Servidor PGN
Administrar Adminstrar
Inventario Oficios
Entidades
Procurador Delegado
Ilustración 8 Diagrama del paquete SIAM.

6. Casos de uso de SIREL
Los casos de uso de SIREL son:
SIREL
Consulta
Consultar Lista Link Generar

Servidor PGN Buscar Información
Información Jurídica Documento
«include» Jurídica «extend»
Recopilacion
Administrar
Información Jurídica
Administrador SIREL «extend»
«extend»
Administrar Temas
«extend»
Adminstrar Links Administrar

Internos Links Externos
Divulgación
«include»
Comunicar Administrar
Cambios a Servidores PGN
Servidores PGN «include» Temas
SIREL
Administrador SIREL
InterfazRecopilacion
SIREL_INT_
1-Consultar SIREL_INT_
Temas 2-Evaluar Casos
SIMIP Sugeridos
Ilustración 9 Diagrama del paquete SIREL.

ANEXO 3 – DIAGRAMAS DE CLASES
Requerimientos de Alto Nivel. (Documento Final) Pág. A3-1

TABLA DE CONTENIDO
Pág.
1. Definición ......................................................................................................................... 5
1.1 Modelo conceptual .......................................................................................................... 5

1.2 Diagramas de clases ........................................................................................................ 8
2. Diagrama de clases ......................................................................................................... 10

CONTROL DE VERSIONES DEL DOCUMENTO
Fecha Versión Revisado por Comentario

Actualización
02/Ago/2005 4.0 Hernán Velásquez. Versión Final – Actualización del diagrama de
Disney Rubiano clases con la última versión de requerimientos.

INDICE DE ILUSTRACIONES
Ilustración 1 Asociaciones ........................................................................................................ 7

Ilustración 2 Valores de la multiplicidad ................................................................................. 8
Ilustración 3 Concepto y atributos............................................................................................ 8
Ilustración 4 Diagrama de Clases. ......................................................................................... 11

1. Definición
En términos generales, un diagrama de clases permite modelar la estructura de un sistema,

mostrando las clases y sus relaciones.
Para poder entender la nomenclatura aquí presentada y el diagrama que se muestra en el

presente anexo, es necesario remitirse a algunas definiciones básicas.
1.1 Modelo conceptual
El paso esencial de un análisis o investigación orientado a objetos es descomponer el

problema en conceptos u objetos individuales: Las cosas que sabemos o conocemos del
problema. Un modelo conceptual es una representación de conceptos en un dominio del
problema (MO951, Fowler962). En términos de UML corresponde aun grupo de diagramas de
estructura donde no se define ninguna operación. La designación de un modelo conceptual
ofrece la ventaja de poder profundizar en los conceptos del domino del problema y no en las
entidades del software.
Puede mostrarnos:
• Conceptos
• Asociaciones entre conceptos
• Atributos de los conceptos
Nomenclatura:
Además de descomponer el espacio del problema en unidades comprensibles (conceptos), la

creación de un modelo conceptual contribuye a esclarecer la terminología o nomenclatura del
dominio. Podemos verlo como un modelo que comunica (a los interesados, como pueden
serlo los desarrolladores) cuáles son los términos importantes y cómo se relacionan entre sí.
Conceptos:
En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal,
podemos considerarlo a partir de un símbolo, intensión y extensión (MO95):
Símbolo: palabras o imágenes que representan un concepto.

Intensión: la definición del concepto.
Extensión: el conjunto de ejemplos a que se aplica el concepto.
1
MO95, Martín J. y Odell, J. 1995. Object-Orient Methods: A Foundation, Englewood Cliffs, NJ.:
Pretince-Hall.
2
Fowler96, Fowler, M. 1996. Analysis Patterns: Reusable Object Models. Reading, MA.: Addison-
Wesly.

La idea fundamental del modelo conceptual, es la de poder contar con un punto de referencia
para avanzar a lo que es un diagrama de clases, incorporando para cada concepto, los
correspondientes atributos y asociaciones.
Definición de términos en lenguaje UML:
En UML, se emplean los términos "clase" y "tipo", en lugar de "concepto". No existe

consenso unánime respecto al significado de clase y tipo; cualquiera que sea la definición, lo
importante es su utilidad para distinguir entre la perspectiva de un analista de dominios que
observa conceptos reales, como lo son solicitud y caso, y los diseñadores de software que
especifican entidades de programas, por ejemplo la clase Solicitud.
La definición clase en UML es "una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, métodos, relaciones y semántica (BJR97). Algunos autores
limitan la definición de clase a una implementación concreta de software, digamos una clase
de java (Fowler96). Pero en UML, este vocablo tiene una aceptación más general: abarca
especificaciones que anteceden a la implementación, a una clase implementada de software
se le llama más concretamente clase de implementación.
En UML, una operación es "un servicio que puede solicitarse a un objeto para que realice un
comportamiento" (BJR973), y método es la implementación de una operación que especifica
el algoritmo o procedimiento de esta.
La definición de tipo en UML se asemeja a la de la clase: describe un conjunto de objetos

parecidos con atributos y operaciones, pero no puede incluir métodos. De ellos se deduce que
un tipo es una especificación de una entidad de software y no una implementación. Ello
significa también que un tipo UML es independiente del lenguaje.
Aunque no sea estrictamente exacto dentro del contexto del lenguaje UML, a veces se utiliza
los vocablos "concepto" y "tipo" indistintamente, porque en el uso coloquial el vocablo "tipo"
a menudo se define como sinónimo de un concepto del mundo real (MO95).
El término interfaz se define como un conjunto de operaciones visibles en el exterior. En el

UML, puede estar asociado a tipos y clases (y también a paquetes que agrupan operaciones).
Aunque los conceptos reales pueden tener una interfaz, el término suele emplearse dentro del
contexto de una interfaz para entidades de software, como la interfaz Runnable de java.
Identificación de las asociaciones:
Es necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los
requerimientos de información de los casos de uso y los que contribuyen a entender el
modelo conceptual. En este punto se examina la identificación de las asociaciones adecuadas
para luego incorporarlas al modelo conceptual.
3
BJR97, Booch, G., Jacobson, I. y Rambaugh, J. 1997. The UML specification documents. Santa
Clara, CA.: Rational Software Corp.

a. Definición de una asociación
La asociación es una relación entre dos conceptos que indica alguna conexión significativa e
interesante entre ellos. Un ejemplo de una asociación es el que se muestra en la ilustración 1.
Comision
1..*
- _UsuarioDeUnaComision
Usuario
# idUsuario : String
# nombreUsuario : String
Ilustración 1 Asociaciones
En el nombre de la asociación de la ilustración 1 es UsuarioDeUnaComisión.
b. Criterios de asociaciones útiles
Las asociaciones que vale la pena mencionar suelen incluir el conocimiento de una relación
que ha de preservarse durante algún tiempo: puede tratar de milisegundos o años según el
contexto.
c. Notación de las asociaciones
Una asociación se representa como una línea entre conceptos con el nombre de la asociación.
Ésta es intrínsecamente bidireccional. o sea es posible un nexo lógico entre los objetos de un
tipo y los del otro. Este vínculo es totalmente abstracto; no es una afirmación entre las
entidades del software. Para el caso de la ilustración 1, se destaca:
• Que en uno de los extremos aparece el valor “1..*”, esto corresponde a una una expresión
de multipilicidad que indique la relación numérica entre las instancias de los conceptos.
La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia
del tipo B en determinado momento. Por ejemplo, una instancia individual de una
Comisión puede asociarse a "muchas" instancias (una o más marcadas con *) de Usuario
(ver la ilustración 9). Algunos ejemplos de las expresiones de multiplicidad son:

Ilustración 2 Valores de la multiplicidad
• Una flecha (En algunos casos es opcional) de la dirección de la lectura, indicando la

dirección en que debe leerse el nombre de la asociación. En su ausencia, por convención
la asociación se lee de izquierda a derecha o de arriba hacia abajo.
Identificación de los atributos
Un atributo es un valor lógico de un dato de un objeto. En un modelo conceptual se incluyen

aquellos atributos que indican o conllevan la necesidad de recordar información.
a. Notación de los atributos
Los atributos se muestran en la segunda sección de la sección de conceptos, es opcional

indicar el atributo.
Servidor
- dependencia
- cargo
Ilustración 3 Concepto y atributos
En la ilustración 3, el concepto/Clase es Servidor y sus atributos identificados son

dependencia y cargo.
1.2 Diagramas de clases
Se conocen también como diagramas de estructura estática, su preparación exige crear antes
el modelo conceptual. La idea es que a partir de este el diseñador agregue detalles a la
definición de las clases. Un diagrama de clases describe gráficamente las especificaciones de
las clases de software (las de java, por ejemplo) en una aplicación. Normalmente contiene la
siguiente información:
• Clases asociaciones y atributos.

• Interfaces, con sus operaciones y constantes.
• Métodos.
• Información sobre los tipos de los atributos.
• Navegabilidad.
• Dependencias.

A diferencia del modelo conceptual, un diagrama de este tipo contiene las definiciones de las
entidades del software en vez de conceptos del mundo real.
En cuanto a las clases y atributos que se involucran en un diagrama de clases, se debe tener
en cuenta los siguientes aspectos:
a. Jerarquías de clases y herencia
Una clase es una implementación de un concepto o de un tipo en software, y en un lenguaje

de programación orientado a objetos una subclase hereda las definiciones de atributos y de
operaciones de sus superclases, gracias a la creación de jerarquías de clases. Gráficamente, la
herencia se representa con una línea que asocia a las clases, terminada con un triángulo, el
cual va del lado de la clase que hereda.
b. Tipos de atributos
Sobre los atributos existen ciertos tipos de restricciones que derivan en los siguientes tipos de
atributos:
• Privados: Se representan por el símbolo “-“, y a ellos sólo puede acceder la clase que
los contiene. No se pueden acceder, desde fuera de su clase.
• Públicos: Se representan por el símbolo “+“, y a ellos puede acceder cualquier otra
clase, además de la clase que los contiene.
• Protegidos: Se representan por el símbolo “#”, y a ellos sólo puede acceder la clase
que los contiene y las clases que heredan de la misma.
Modelo conceptual Vs. Diagrama de clases:
El modelo conceptual, no presenta una definición de software, más bien es una abstracción de
un concepto del mundo real acerca del cual se quiere afirmar algo. En cambio en los
diagramas de clases se presentan las clases como componente del software.
En el caso concreto del proyecto adelantado para la PGN, dado que se trata de un trabajo de
análisis y no de diseño, se partió del modelo conceptual para obtener una primera
aproximación de lo que es el diagrama de clases. Es deber del diseñador hacer las
correspondientes actualizaciones y complementaciones en lo que tiene que ver con la
información del diagrama que aquí se presenta.

2. Diagrama de clases

Comision 0..1
1..*
- _UsuarioDeUnaComision
- _ComisionDeCaso
Usuario 1..*
ActoresCaso
# idUsuario : String - _UsuariosDeUnCaso
# nombreUsuario : String Queja + insertarActor ( )
- entidad : String + tomarListaActoresCandidatos ( )
SolicitudParte
- funcionario : String
- _ActoresCaso 1
Servidor
- dependencia Solicitud - _Correspondencia Correspondencia
- cargo
# IUS : int 0..*
# textoAsunto : String + fechaRecepcion
# fechaIngreso : Date + resumen
1 - _CompetenciaDe
OtrasCompetencias Competencia + asignarPrioridadPoliticas ( ) - _Solicitante
+ acumularSolicitud ( )
Solicitud con que se acumula + evaluarSolicitud ( ) 0..1 0..* - _Solicitante
- _FuncionarioAsignado ...
Solicitante
AcumulacionSolicitud 1 Solicitud a acumular 1 1
# idSolicitante : int
IUS # nombreSolicitante : String
1 # telefonoSolicitante : String
ProcuraduriaDelegada 1 # direccionSolicitante : String
Relacion Vinculacion
0..1
# justificacion : String
- _AbogadoQueInterpone Abogado 0..1
0..1 - _FuncionarioAsignado IUC Quejoso SujetoProcesal
AcumulacionCaso 1 Caso a acumular - fuente : String

ProcuradorJudicial - esTemerario : boolean
1 1
Caso con que se acumula - _Expediente Expediente
Caso
1 0..* - idExpediente : String
# IUC : int - usuarioResponsable : int
Instrumento Actividad # hechos : String - tituloExpediente : String
0..*
1..* Etapa # decision : String - ubicacion : String
PoderPreferente # fechaEmision : Date # idActividad : int
- _Etapas Ruta del Caso # fechaCierre : Date
# pasivoOActivo : int # argumento : String - _Actividades de la etapa + ingresarPrestamo ( )
- entidad : String # fechaSolucion : Date # contrargumento : String + tomarEtapas ( ) # fechaApertura : Date CasoIntervencion + fijarTiempoEnDependencia ( )
0..*
+ tomarExpediente ( ) - juzgado : String
+ gestionarActores ( ) 0..1 - _PrestamosExpedientes
0..* + registrarConclusiones ( )
+ definirRuta ( ) PrestamosExpedientes
Oficio + vincularASolicitud ( ) - usuarioResponsable : String
AccionPopular Tutela AccionCumplimiento + abrirCaso ( ) - fechaPrestamo : Date
- codigo : int
+ acumularCaso ( ) - fechaDevolucion : Date
- fecha : Date
+ crearActividad ( )
- destinatario : String
+ ingresarEtapaEnRuta ( )
+ generarOficios ( ) + asignarServidorEquipo ( )
+ marcarCierreCaso ( )
+ descargarFuncionarios ( ) 0..*
0..1 - _PlantillaAsociada Conclusiones
- _Conclusiones
Plantilla CasoDisciplinario + insertarConclusion ( )
- codigo : int - instancia : int CasoPreventivo
- tipo : int
- nombre : String - entidad
1..* - _Disciplinado
Disciplinado
- idDisciplinado : int
- nombre : String
- entidad : String
Ilustración 4 Diagrama de Clases.

Licitacion112006bid Anexo4 3requerimientosdealtonivel

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Licitacion112006bid Anexo4 3requerimientosdealtonivel

Загружено:

Авторское право:

Доступные форматы

CIFI-INFORMATICA – PROCURADURIA GENERAL DE LA NACION

REQUERIMIENTOS DE ALTO NIVEL DEL

Fecha Versión Descripción Autor

Requerimientos de Alto Nivel (Documento Final) Pág. 2

CAPÍTULO 2- OBJETIVOS Y ALCANCE ...................................................................................... 7

Requerimientos de Alto Nivel (Documento Final) Pág. 3

ANEXO 1 – MATRIZ REQUERIMIENTOS .VS. PROCESOS OPTIMIZADOS … . A1-1

ANEXO 2 – DIAGRAMA DE PAQUETES Y DE CASOS DE USO ….………….... A2-1

ANEXO 3 – DIAGRAMA DE CLASES ……………………………………………… A3-1

Requerimientos de Alto Nivel (Documento Final) Pág. 4

El contrato 066 de 2004 suscrito entre la Procuraduría General de la Nación y la Universidad

Este documento de “Requerimientos de Alto Nivel del Sistema de Información Misional”,

En el capítulo 2, se presentan los objetivos y alcance del documento. En el capítulo 3, se

En el Anexo 1 del documento se incluye la matriz de REQUERIMIENTOS POR SISTEMAS

Los Anexos 2 y 3 contienen los siguientes diagramas:

ANEXO 2 – DIAGRAMAS DE PAQUETES Y DE CASOS DE USO

ANEXO 3 – DIAGRAMA DE CLASES

Adicionalmente, en el documento de la Etapa 7 “Requerimientos Detallados Sistema de

En el presente documento y en los restantes documentos del Sistema de Información

Requerimientos de Alto Nivel (Documento Final) Pág. 5

se encuentren en operación en la Procuraduría en el momento del desarrollo del SIM.

Requerimientos de Alto Nivel (Documento Final) Pág. 6

Requerimientos de Alto Nivel (Documento Final) Pág. 7

Requerimientos de Alto Nivel (Documento Final) Pág. 8

la solicitud lo amerita, con la verificación de hechos, establecimiento del marco normativo

• Unificar los criterios y las actuaciones al interior de la PGN.

• Integrar mejor los recursos/elementos disponibles para la ejecución de las funciones

• Garantizar la seguridad jurídica del proceso: El sistema debe ayudar a garantizar la

• Garantizar Transparencia: El sistema misional de la PGN debe brindar información y

• Mejorar la gestión operacional: El sistema debe disminuir la carga operativa en lo que

Requerimientos de Alto Nivel (Documento Final) Pág. 9

análisis, ampliación de cobertura y seguridad jurídica, lo cual redundará en una mejor

Requerimientos de Alto Nivel (Documento Final) Pág. 10

Requerimientos de Alto Nivel (Documento Final) Pág. 11

3.1 Alcance Funcional y Misional del Sistema

Requerimientos de Alto Nivel (Documento Final) Pág. 12

3.2 Supuestos para la Definición del Sistema

La definición del sistema se ha realizado teniendo en cuenta los siguientes criterios:

Requerimientos de Alto Nivel (Documento Final) Pág. 13

1. La PGN contará con toda la infraestructura de hardware, software de base,

2. El sistema debe ser diseñado teniendo en cuenta los macroprocesos institucionales y no

4. La arquitectura del sistema de información debe estar orientada y unificada para la

6. Con respecto a la información jurídica, manejar en el sistema lo que es exclusivo a las

3.3 Actores del Sistema

En el siguiente cuadro se encuentra el esquema de los actores involucrados en el sistema.

Requerimientos de Alto Nivel (Documento Final) Pág. 14

3.4 Requerimientos Generales

Requerimientos de Alto Nivel (Documento Final) Pág. 15

Requerimientos de Alto Nivel (Documento Final) Pág. 16

3.5 Restricciones Generales

f) El sistema debe ser diseñado considerando los requerimientos de seguridad de la

3.6 Características Generales

A continuación se enumeran una serie de características o condiciones generales que deben

a) El sistema debe definirse considerando los procesos transversalmente, sin suscribirlos a

b) La generación de estadísticas y reportes debe ser uniforme y general.

Requerimientos de Alto Nivel (Documento Final) Pág. 17

c) Debe ser un sistema homogéneo con entradas y salidas preestablecidas.

h) La información restringida debe tener los mecanismos de seguridad suficientes para

i) Por el alto nivel de criticidad de la calidad de información para el buen funcionamiento y

j) Se debe manejar con claridad la dispersión de procesos, duplicidad de procesos y las

k) El sistema debe ser autodocumentado funcionalmente, con ayudas automáticas.

l) Generar y hacer un seguimiento a flujos paralelos, atendiendo la naturaleza de los

m) El sistema de manejo de la información jurídica debe tener esquemas de ingreso de la