[Php-avanzado] Requerimientos del sistema
David Barraud
davidbarraud en gmail.com
Vie Jun 22 08:44:35 ART 2012
Hola Leo, cambié algunas cosas con respecto a las correcciones que me
pasaste.
Correcciones
*Requerimientos funcionales:*
1. El sistema debe gestionar departamentos de trabajo.
2. El sistema debe gestionar categorías de insumos.
3. El sistema debe gestionar insumos con sus categorías [2].
4. El sistema debe mostrar estados de las solicitudes de trabajo.
5. El sistema debe asentar solicitudes de trabajo con su departamento
[1] e insumos [3] utilizados.
a. El sistema debe asentar una solicitud [5] pedida y cambiar su
estado [4] a “pendiente”.
b. El sistema debe tomar solicitudes [5] pendientes [5.a] y cambiar su
estado [4] a “en proceso” si se toma la decisión de trabajar en esta
solicitud.
c. El sistema debe cambiar el estado [4] de las solicitudes [5] en
proceso [5.b] y pasarlos a “solucionado” si se ha resuelto el problema.
d. El sistema debe cambiar el estado [4] de las solicitudes [5]
“pendiente” [5.a], “en proceso”[5.b] a “no resuelto” si es que el problema
de la solicitud[5] no tiene solución.
6. El sistema debe listar la solicitudes [5] de acuerdo a su
estado[4].
*Diccionario*
*Departamentos (nombre).* Áreas de trabajo que tienen un problema y
realizan una solicitud de trabajo.
*Categorias (nombre)*. Tipos de insumos informáticos.
*Insumos(id_ categoria, nombre, cantidad, imagen).* Insumos informáticos
(teclados, mouses, monitores, fuentes, etc.).
*solicitudes (fecha_inicio, fecha_fin, problema, id_estado, solución,
id_insumos_usados).* Pedidos de trabajo que hacen los departamentos cuando
hay algún problema para resolver.
*estados( estado).* Vista actual del pedido de trabajo. El estado pueder
ser: "No resuelto", "En proceso", “pendiente”o "Solucionado".
Hay un detalle que me marcaste tambien: No veo de qué manera se dan de alta
los Insumos al sistema: tenés un
mecanismo solo para darlos de baja, que es la Solicitud de Trabajo... te
hace falta algo así como un Remito de Alta de Insumos.
En qué parte se agregaría el "remito de alta de insumos" en el diccionario?
porque en las especificaciones se da por sentado de que hay que hacer un
ABM de los insumos.
Nos vemos.
El 18 de junio de 2012 18:50, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:
> Hola David,
>
> El lun, 18-06-2012 a las 08:11 -0300, David Barraud escribió:
> > Hola Leo, como para recordar lo que venía haciendo te coloco todo el
> > proyecto para que lo revises y corrijas para pasarte la normalizacion.
> > Muchas gracias.
>
> Por nada!
>
> Necesito que le hagas unos retoques.
> Te los marco intercalados:
>
>
>
> > Requerimientos Empresariales:
> > El sistema que se pretende hacer es un control de pedidos (o
> > solicitudes) de trabajo para el área de sistemas, incluyendo el manejo
> > y control de stock de insumos.
> >
> > Cabe señalar que los el control de insumos no es un detalle importante
> > dentro de este sistema sino que los insumos pueden ser cargados sin
> > necesidad de un control estricto y no se especifica si el insumo es
> > usado o nuevo. Todo cambio de insumo es tratado como que se lo
> > descarta.
> >
> > Metodología:
> > - Un área de la empresa (departamento), realiza una solicitud de
> > trabajo.
> > - Se toma y carga la solicitud colocando el problema, la fecha de
> > inicio, el nombre del departamento y el estado en el que se encuentra
> > el pedido.
> >
> > - El estado puede ser "pendiente", "en proceso" , “ No resuelto” y
> > "Solucionado".
> >
> > - Toda nueva solicitud comienza con un estado “pendiente”.
> > - Al momento de aceptar la solicitud, el estado cambia a “en
> > proceso” .
> >
> > - Al procesar el pedido, se realiza el trabajo y si se utiliza algún
> > insumo informático, se selecciona la cantidad (si hay stock); se
> > coloca cómo se resolvió el problema y el estado cambia a
> > "Solucionado". En el caso de que no se utilice insumos informáticos,
> > se coloca cómo se resolvió el problema y se cambia el estado a
> > "Solucionado".
> >
> > - Si no hay solución del problema, el estado pasa a “no Resuelto”
> > - Para esta primera etapa del sistema, si hay cambio de stock se
> > entiende de que el stock que se remplaza está roto y no se repara.
>
> Todo el contexto y proceso que figura arriba está muy bien.
> Luego, debe tener su reflejo expresado como funcionalidad.
>
> > Requerimientos no funcionales:
> > - El sistema debe gestionar usuarios:
> > tipos de usuarios:
> > - consulta: como ser un gerente: sólo accede a la pantalla para ver
> > los pedidos de trabajo y su estado.
> > - administrador: es el superusuario del sitio y el que administra el
> > control de solicitudes de trabajo.
> >
> >
> >
> >
> >
> > Requerimientos funcionales:
> >
> > 1. El sistema debe gestionar departamentos de trabajo.
> >
> > 2. El sistema debe gestionar insumos.
> >
> > 3. El sistema debe gestionar categorías de insumos [2].
>
> Esto es al revés. Primero especificá las Categorías de Insumos,
> luego,
> especificiá los Insumos con sus Categorías de Insumos.
> En tu redacción, son dos cosas separadas, y si no entiendo mal el
> problema, los Insumos tienen una Categoría de Insumo.
>
> > 4. El sistema debe asentar solicitudes de trabajo.
> >
> > 5. El sistema debe asentar estados de las solicitudes de trabajo [4].
>
> Cambiá "asentar" por "mostrar" o algo que de la idea que a esto no
> se
> le agregan más adelante nuevos Estados.
>
> Tenés el mismo error que arriba: especificá primero los Estados, y
> luego especificá las Solicitudes de Trabajo, que tiene su Estado y
> además cero o más Insumos, un Departamento, y todo lo que usen.
>
> > 6. El sistema debe asentar la fecha de la solicitud de trabajo [4].
>
> La fecha es un atributo de la Solicitud de Trabajo: no tiene
> sentido
> especificar los atributos, salvo que sean otro RF.
>
> > 7. El sistema debe asentar departamentos [1] que realizan la solicitud
> > de trabajo [4].
>
> Los Departamentos tienen que ir antes que la Solicitud de Trabajo,
> porque esta los usa...
>
> > 8. El sistema debe asentar el problema del departamento [1] que
> > realiza la solicitud de trabajo [4].
>
> Me parece que "problema" es un atributo más de la Solicitud de
> Trabajo... de hecho lo ponés así en el diccionario.
> Es lo mismo que lo que te observo en el actual RF6.
>
> > 9. El sistema debe asentar una solicitud [4] pedida y cambiar su
> > estado [5] a “pendiente”.
>
> Esto entonces sería un subrequerimiento del RF con la Solicitud de
> Trabajo.
>
> > 10. El sistema debe tomar solicitudes [4] pendientes [9] y cambiar su
> > estado [5] a “en proceso”.
>
> Idem.
>
> > 11. El sistema debe asentar soluciones realizadas al problema [8]
> > solicitado.
>
> Esto no tiene mucho sentido. Luego de reformular el orden de la SRS
> será el subrequerimiento 1 de la especificación de la Solicitud de
> Trabajo
>
> > 12. El sistema debe cambiar el estado [5] de las solicitudes [6] en
> > proceso [10] y pasarlos “a solucionados junto con el insumo [2]
> > utilizado y la solución [11] al problema [8]”.
>
> Lo mismo que para el actual 10.
>
> > 13. El sistema debe cambiar el estado [5] de las solicitudes [4]
> > “pendiente”[9], “en proceso”[10] a “no resuelto” si es que el problema
> > [8] no tiene solución.
>
> Lo mismo que para el actual 10.
>
> > 14 El sistema debe emitir un informe de reparaciones terminadas entre
> > fechas.
>
> Esto es muy ambiguo: en qué consiste el informe? Decir cuantas
> son? Un
> listado con un resumen de las Solicitudes de Trabajo? Las no resueltas
> no aparecen?
> Lo más rápido para resolver esto es un ejemplo del informe...
>
>
>
> > Diccionario
> > Departamentos (nombre, responsable). Áreas de trabajo que tienen un
> > problema y realizan una solicitud de trabajo.
>
> Y no hace falta especificar los Responsables de Departamento?
>
> > Categorias (nombre). Tipos de insumos informáticos.
> > Insumos(id_ categoria, nombre, cantidad, imagen). Insumos informáticos
> > (teclados, mouses, monitores, fuentes, etc.).
> > solicitudes (fecha_inicio, fecha_fin, problema, id_estado, solución,
> > id_insumos_usados). Pedidos de trabajo que hacen los departamentos
> > cuando hay algún problema para resolver.
> > estados( estado). Vista actual del pedido de trabajo. El estado pueder
> > ser: "No resuelto", "En proceso", “pendiente”o "Solucionado".
> > insumosusados( id_insumos, cantidad). Tabla auxiliar entre los pedidos
> > y la tabla insumos.
>
> Tabla??? Estamos diciendo qué es lo que vas a hacer, y no como!!!
>
> No veo de qué manera se dan de alta los Insumos al sistema: tenés un
> mecanismo solo para darlos de baja, que es la Solicitud de Trabajo... te
> hace falta algo así como un Remito de Alta de Insumos.
>
> > Muchas gracias
>
> Por nada!
> Mandame ni bien puedas las correcciones así hacemos esto lo más
> rápido
> posible. Verás que por la falta de tiempo te estoy diciendo los errores
> y la solución para que casi nada más tengas que redactarlos.
>
> Dale!!
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Blog: http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20120622/82c451da/attachment.html>
Más información sobre la lista de distribución Php-avanzado