2. RECEPCION DE REQUISITOS
A fin de facilitar la interacción con el cliente y sus necesidades, se empleara una
herramienta colaborativa llamada Assembla, para ello
se tomaran en cuenta los siguientes lineamientos.
El o los representantes del cliente capaces de formular nuevos requerimientos para el
desarrollo deberán disponer obligatoriamente de cuentas de usuario en Assembla.
Cuando los representantes deseen aumentar un nuevo requerimiento, este será
introducido mediante la herramienta “Tickets” de Assembla, de modo que un nuevo
requerimiento tendrá que ser creado como un ticket de estado “Nuevo”, asignado al
consultor de negocios y cuyo hito será la sección de Requerimientos del Sistema,
Adicionalmente en caso de contar con archivos acorde a la solicitud como escaneados de
documentos, etc. Tendrán que ser adjuntados como archivos. A continuación se
observara la forma de adicionar un requerimiento por el cliente.
6. REVISION DE REQUISITOS
Para la definición, descripción y detalle de los requisitos identificados, se
elaborara el documento de Especificación de Requisitos del Software (ERS),
este se elaborara en base al estándar IEEE-830. Mediante la ERS se
asegurara que los requisitos fueron comprendidos en su totalidad por parte
del equipo de desarrollo, y una vez concluido será añadido como archivo en
Assembla para posibles consultas de los representantes del cliente. La ERS
se encontrara disponible en la sección de Archivos en Assembla.
7.
8. GESTION DE CAMBIOS DE
REQUISITOS
En caso de que el cliente desee realizar una modificación a un requisito
una vez aprobada su realización, podrá utilizar las herramientas de
Assembla para comunicar los cambios a través de subtareas. Para ello
se efectuaran los siguientes pasos.
El o los representantes del cliente tendrán que ingresar a la pestaña del ticket
del requisito al cual deseen realizar una modificación.
Se ingresara a la sección Ticket relacionados y se añadirá una nueva subtarea,
brindando un nombre corto sobre el cambio a introducir y una descripción
detallada del mismo. De la siguiente forma.
9.
10.
Una vez introducida la subtarea con el cambio a realizar, se procederá a cambiar el estado del
requisito inicial de Aprobado a Nuevo.
Cada vez que se introduzcan nuevos cambios sobre los requisitos identificados, se procederá a evaluar
la factibilidad de la realización del cambio y se presentara al cliente de forma manual, el documento
“Solicitud de Modificación”, en el cual se especifican los detalles del cambio en términos de costos y
plazos.
11. Cuando el documento “Solicitud de Modificación” es aprobado por el usuario, el gestor
del proyecto cambia el estado del requisito a Aprobado y se procede a la implementación
del mismo acorde a los plazos establecidos en la solicitud.
Una vez aprobado el cambio se procede a documentar dicho cambio en esta matriz.
12. GESTION DE LA TRAZABILIDAD DE
LOS REQUISITOS
Para definir la trazabilidad de los requisitos se evaluara el
desarrollo de los diversos componentes correspondientes a
cada uno de los requisitos. Esto puede ser reflejado desde los
siguientes documentos.
17. MANTENIMIENTO DE LA
CONSISTENCIA DE LOS REQUISITOS
A fin de validar la correcta elaboración de los requisitos del cliente, se
realizara la evaluación a los casos de uso al terminar cada iteración del
ciclo de vida. Para esto se empleara el documento “Checklist de validación
de Requisitos”, en el cual se determinara el cumplimiento de los
siguientes criterios:
Valides. Si las funciones implementadas son acorde a los requisitos solicitados.
Consistencia. Si no existen conflictos entre los requisitos.
Completitud. Si los requisitos evaluados se encuentran implementados en su totalidad.
Realismo. Si los requisitos pueden ser utilizados bajo sus condiciones normales de
trabajo.
Verificable. Si los requisitos pueden ser verificables.
