PROGRAMA DE RECONVERSION DE AREAS TABACALERAS –

PRAT

PROYECTO DE DESARROLLO DE UN SOFTWARE DE GESTION

MANUAL DE PROCEDIMIENTOS PARA LA APROBACION DE

REQUERIMIENTOS

Contempla un compendio de políticas generales, roles y funciones de

los participantes, los procedimientos operativos involucrados con su
diagrama de flujo.

OCTUBRE de 2018

Consultas: Página 1 de 11
 Organización: SoftING
Rubro: Manual de Procedimientos
  Ítem: Contenidos
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Minuta N°

Contenido
1 Introducció n.......................................................................................................................................3
2. Aspectos Organizacionales................................................................................................................4
2.1. Consideraciones preliminares.......................................................................................................4
2.2. Roles y Funciones...........................................................................................................................4
3. Descripció n de Requerimientos........................................................................................................7
3.1. Requerimientos Funcionales.........................................................................................................7
4. Procedimientos..................................................................................................................................9
4.1. Definició n y validació n de Requerimientos Funcionales.........................................................9
4.1.1. Consideraciones generales........................................................................................................9
4.1.2. Procedimiento...........................................................................................................................9
Anexo I – Diagrama de Flujo.................................................................................................................11

Consultas: Página 2 de 11
 Organización: SoftING
Rubro: Manual de Procedimientos
  Ítem: 1.Introducción
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

1 INTRODUCCIÓN.

Resulta de má xima importancia para el adecuado desarrollo de los proyectos tecnoló gicos, contar con un
procedimiento específico, que describa de manera certera, la metodología de validació n de los distintos
requerimientos de dicho proyecto, sean estos “Funcionales” como “No Funcionales”. En virtud de la
necesidad descripta, se exponen en los distintos acá pites de este manual las consideraciones técnicas y
organizacionales que regulen la actividad de validació n de manera segura, á gil y trazable con el objeto de
un sano desarrollo del proyecto en curso. Así en el punto siguiente se describen los distintos
requerimientos y sus atributos técnicos, en un acá pite posterior se definen los aspectos organizacionales a
través de políticas y roles de ejecució n y finalmente se exponen los detalles del procedimiento para dicha
ejecució n.

Consultas: Página 3 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

2 ASPECTOS ORGANIZACIONALES

2.1 CONSIDERACIONES PRELIMINARES.

Resulta imprescindible para el proyecto contar con un Líder de Usuarios que resuma la visión global del
proyecto y que cuente con la colaboración de los usuarios expertos para cada uno de los módulos a
desarrollar. Dichas personas serán los encargados de validar los requerimientos a construir o ya
construidos.

Con independencia de los roles descriptos en el párrafo anterior se sugiere que el proyecto cuente con
los siguientes roles:

 Coordinador Político: Con asignación en la Coordinación Nacional y con un buen nivel de

comunicación con los actores de las provincias a los efectos de facilitar la interacción con los
mismos.
 Socios Tecnológico: Con asignación en cada una de las provincias tabacaleras y el conocimiento
técnico y funcional de la plataforma de cada región, para colaborar en los relevamientos,
definiciones e implementaciones del proyecto.

2.2 ROLES Y FUNCIONES.

Con el objeto de establecer quien debe realizar cada una de las actividades de los distintos
procedimientos, se definen en este apartado los roles que deben cubrirse dentro de la organización a
los fines de dotarla de procesos efectivos con adecuados controles internos. La definición de los
distintos roles surge del organigrama sugerido y una vez establecidos los roles, se detallan las funciones
asignadas a cada uno dentro del proyecto.

Consultas: Página 4 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

Coordinador PRAT

Director PHA Director Softing

Líder de Usuarios Gerente Softing Gerente PHA

Usuarios
Arquitectos
Expertos

Analistas de
Socios Tecnicos Procesos
Analistas

Coord. PRov Desarrolladores

Consultas: Página 5 de 11
 Funciones

PRAT  Controlar la marcha de las operaciones

 Mantenerse informado de los avances
Coordinador  Resolver conflictos propios de la etapa de relevamiento
 Validar los requerimientos definidos por los usuarios
PRAT expertos.
 Definir en las decisiones que afectan los requerimientos
Líder de Usuarios de más de un departamento.
 Realizar el seguimiento de las tareas de validación
PRAT  Definir los requerimientos de cada sector.
 Validar las especificaciones funcionales y el software
Usuarios Expertos construido.
PHA  Velar por el avance del proyecto junto al Coordinador
PRAT y Director SoftING.
Director del Proyecto

PHA  Gestionar los requerimientos en tiempo y forma

atendiendo las tareas del procedimiento.
Gerente del Proyecto

PHA  Relevar funcionalmente los requerimientos de software.

 Especificar los requerimientos funcionales al equipo de
Analista de Proceso SoftING.

Softing  Velar por el correcto avance de la definición de

requerimientos
Director del Proyecto

Softing  Gestionar junto al Gerente de PHA la definición y

validación de los requerimientos.
Gerente de Proyecto  Gestionar la construcción de los documentos funcionales
del proyecto

Softing  Requerir al analista de proceso las definiciones que

surjan del trabajo técnico
Analista Funcional  Construir los documentos funcionales del proyecto.
Softing  Aportar valor a los requerimientos desde los aspectos
constructivos del aplicativo.
Desarrolladores

Softing  Velar por los aspectos tecnológicos de las definiciones

del aplicativo
Arquitectos

Consultas: Página 6 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

3 DESCRIPCIÓN DE REQUERIMIENTOS

3.1 REQUERIMIENTOS FUNCIONALES.

Los requerimientos funcionales de un sistema, son aquellos que describen cualquier actividad que este
deba realizar, en otras palabras, el comportamiento o función particular de un sistema o software
cuando se cumplen ciertas condiciones.

Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas, descripciones de
los flujos de trabajo a ser desempeñados por el sistema y otros requerimientos de negocio,
cumplimiento, seguridad u otra índole.

Los requisitos funcionales de un software se suelen registran en la matriz de trazabilidad de

requerimientos y en la especificación de requerimientos de software, este último, documenta las
operaciones y actividades que el sistema debe poder desempeñar.

Entre los posibles requerimientos funcionales de un sistema, se incluyen: 

 Descripciones de los datos a ser ingresados en el sistema.

 Descripciones de las operaciones a ser realizadas por cada pantalla.
 Descripción de los flujos de trabajo realizados por el sistema.
 Descripción de los reportes del sistema y otras salidas.
 Definición de quien puede ingresar datos en el sistema.
 Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean
aplicables.

3.2. REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales son los que especifican criterios para evaluar la operación de un
servicio de tecnología de información, en contraste con los requerimientos funcionales que especifican
los comportamientos específicos de las aplicaciones.

En la primera parte de esta serie, describíamos una definición de requerimientos no funcionales y

porque son importantes. Los requerimientos no funcionales definen las características o cualidades
generales que se esperan de un sistema y establecen restricciones sobre el producto, el proceso de
desarrollo de software y establecen restricciones externas que el software debe lograr.

Consultas: Página 7 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

Para poder identificar estas características durante la ingeniería de requisitos que realizan los Analistas
de sistemas e Ingenieros de software en todo proyecto de desarrollo, es útil contar con una clasificación
que nos establezca un marco de los tipos de requerimientos funcionales con que nos podemos
encontrar.

La figura presenta la clasificación de requerimientos no funcionales definida por Somerville.

Consultas: Página 8 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

4 PROCEDIMIENTOS

4.1 DEFINICIÓN Y VALIDACIÓN DE REQUERIMIENTOS FUNCIONALES.

4.1.1. Consideraciones generales.

A los efectos de estandarizar el proceso de definició n y validació n de requerimientos,

estableceremos algunas políticas generales que ayudan a dar marco al proceso bajo estudio.
a.) En la reunió n de kick off se establecerá n las responsabilidades en cuanto a la definició n y
validació n para los distintos mó dulos funcionales y cada uno de los aspectos no funcionales
que surjan del relevamiento.

b.) Con el objeto de posibilitar un avance adecuado del proyecto se entiende que los procesos
de revisió n de los entregables no deben superar los 5 días há biles, momento a partir del
cual se pone en riesgo el cumplimiento de fechas establecidas.

c.) En virtud que la planificació n del proyecto se realizó a partir de los documentos funcionales
puestos a disposició n en la etapa de cotizació n, se parte del supuesto que dichos
documentos reflejan de manera efectiva la realidad actual de los procesos y que, si bien
pueden surgir modificaciones en los momentos de relevamiento inicial, las mismas no será n
de gran impacto.

d.) El análisis de procesos será realizado por PHA quien entregará a Softing el proceso validado
con el usuario experto de cada mó dulo y/o el Líder de Usuarios. Cabe destacar que Softing
participará de las actividades de finales de validació n del proceso.

4.1.2. Procedimiento.

a.) PHA hará entrega de cada uno de los distintos procesos analizados y validados con los usuarios
como input para el análisis funcional.

b.) Softing tomando como base la documentación funcional desarrollada en el documento

tecnológico N° 4 especificará un requerimiento funcional que se ajuste al diseño del proceso
entregado por PHA.

c.) Softing validará el documento funcional con PHA y juntos realizaran las reuniones de
presentación a los usuarios expertos / Líder de Usuarios para su aceptación definitiva.

Consultas: Página 9 de 11
 Organización: SoftING
Procedimiento de validación de
Rubro: requerimientos
  Ítem: 2. Aspectos Organizacionales
Vigencia Original: 23/10/2018 Última Actualización: 23/10/2018
Versión: 00 Aprobado por Acta: N°

d.) Una vez presentado el documento funcional, el Líder de Usuarios contará con 5 días hábiles para
solicitar pedidos de ajuste o su aprobación definitiva. Los pedidos de ajustes que existan
deberán ser explicitados por medio de un correo electrónico a Softing y PHA. Pasados los 5 días
hábiles el documento se dará por aprobado.

e.) En caso de ajustes Softing realizará las modificaciones pertinentes y las remitirá por correo
electrónico a PHA y al Líder de Usuarios o si lo considera necesario ejecutará nuevamente las
actividades de presentación, reunión y validación para su aprobación definitiva.

f.) Cada documento validado contará con una bitácora en donde se detalle la trazabilidad del
procedimiento de validación y una vez aprobado el documento, se procederá a dar de alta en la
biblioteca de documentos de alcance del proyecto.

g.) En el Anexo I se presenta el diagrama de flujo del proceso.

Consultas: Página 10 de 11
 Anexo I – Diagrama de Flujo

Inicio

PHA entrega documento

con procesos validados

Softing, construye
documento funcional

Softing valida documento

Si funcional con PHA

Softing y PHA presentan

documento con Usuarios

Requiere todo el Softing remite ajustes a Usuario valida el

proceso?
No usuarioos documento

Ajusta documento y lo
valida con PHA

Usuario remite correo a

Softing y PHA con No Funcionalidad OK?
modificaciones

Si

Usuario remite correo a

Softing y PHA aprobando

Documento se incorpora
a la biblioteca de alcance

Inicio

Consultas: Página 11 de 11