Sistema de facturación e inventario – FACTINV (página 3)

Requerimiento: # 1

Tipo de requerimiento: 9

Evento/caso de uso #: 1

Descripción: El sistema debe permitir probar un modelo de interés para el usuario.

Razón: Analizar que tan seguro es el modelo probado, para determinar si debe ser o no utilizado.

Fuente: Coordinador del Proyecto

Criterio de medida:

La funcionalidad del modelo una vez aprobado y utilizado.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Los modelos a probar deben estar representados como ecuaciones algebraicas diferenciales.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso

Historia: Creado el 31 de Octubre del 2004

Requerimiento: # 1.1

Tipo de requerimiento: 9

Evento/caso de uso #: 1,2

Descripción: El sistema debe permitir que el usuario pruebe diferentes modelos.

Razón: Ahorrar costos en el desarrollo de diferentes sistemas para probar un modelo especifico.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda seleccionar el modelo que desea probar.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Los modelos a probar deben estar representados como ecuaciones algebraicas diferenciales.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso

Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 1.2

Tipo de requerimiento: 9

Evento/caso de uso #: 1,3

Descripción: El sistema debe permitir que el usuario configure el modelo que desea probar.

Razón: Permite ensayar un conjunto de casos a través del mismo modelo

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda parametrizar el modelo que desea probar.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Los modelos a probar deben estar representados como ecuaciones algebraicas diferenciales.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso

Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 1.3

Tipo de requerimiento: 9

Evento/caso de uso #: 1,4

Descripción: El sistema debe permitir solucionar el modelo a través de diferentes métodos numéricos.

Razón: Que el usuario verifique cual es la solución que representa mejor la salida real.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda seleccionar el método numérico con que desea solucionar el

Modelo.

Satisfacción del cliente: 4

Insatisfacción del cliente: 4

Dependencias: Los métodos numéricos seleccionados deben solucionar modelos representados como ecuaciones algebraicas diferenciales.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso. Sección de Fundamentos Básicos

Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 1.4

Tipo de requerimiento: 9

Evento/caso de uso #: 1,5

Descripción: La solución del modelo debe representarse gráficamente.

Razón: Es la mejor forma de observar el comportamiento del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que se pueda visualizar la solución grafica del modelo.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para la representación gráfica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.5

Tipo de requerimiento: 9

Evento/caso de uso #: 1,5

Descripción: El sistema debe construir la solución grafica en forma dinámica.

Razón: Que el usuario pueda observar detalladamente el comportamiento del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda observar como se va construyendo gráficamente la solución del

Modelo.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para la representación gráfica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.6

Tipo de requerimiento: 9

Evento/caso de uso #: 1,5,6

Descripción: El sistema debe permitir normalizar la solución grafica del modelo.

Razón: Que el usuario pueda visualizar la solución grafica en una escala adecuada.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la solución grafica se pueda mostrar completa en la pantalla.

Satisfacción del cliente: 5

Insatisfacción del cliente: 4

Dependencias: Desarrollar las rutinas necesarias para normalizar la solución del modelo antes de graficarla.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.7

Tipo de requerimiento: 9

Evento/caso de uso #: 1,7,8,9,10,11

Descripción: El sistema debe proveer las funciones necesarias para probar el modelo.

Razón: Sin estas funciones el proceso de validación no será seguro.

Fuente: Coordinador del Proyecto

Criterio de medida:

La cantidad y el tipo de funciones que ofrece el sistema para probar el modelo.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que las funciones propuestas puedan ser desarrolladas con la herramienta de desarrollo seleccionada.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.1

Tipo de requerimiento: 9

Evento/caso de uso #: 1,7

Descripción: El sistema debe tener una función que permita iniciar la simulación.

Razón: Poder controlar el proceso de simulación.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que la solución inicial se corresponda con los parámetros iniciales.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que el modelo acepte un estado inicial de partida.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.2

Tipo de requerimiento: 9

Evento/caso de uso #: 1,8

Descripción: El sistema debe tener una función que permita detener la simulación.

Razón: Poder controlar el proceso de simulación.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la solución grafica se detenga una vez que se active esta función.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que el modelo se pueda resolver parcialmente.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.3

Tipo de requerimiento: 9

Evento/caso de uso #: 1,9

Descripción: El sistema debe tener una función que permita cambiar los parámetros del modelo durante la simulación

Razón: Poder controlar el proceso de simulación y ver como responde ante nuevas condiciones

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que la solución grafica se represente correctamente una vez introducidos los

nuevos parámetros.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que el modelo se pueda resolver correctamente a partir de los nuevos parámetros

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.4

Tipo de requerimiento: 9

Evento/caso de uso #: 1,10

Descripción: El sistema debe permitir el fotografiado periodico de la solución gráfica.

Razón: Capturar soluciones graficas previas a las que el usuario pueda retroceder y observar nuevamente, sin tener que graficar desde el inicio la solución.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar si la foto tomada se corresponde con la solución grafica presentada previamente en tiempo de ejecución

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo provea las librerías necesarias para llevar a cabo esta función.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso. Sección de Fundamentos Básicos

Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 1.7.5

Tipo de requerimiento: 9

Evento/caso de uso #: 1,10

Descripción: El sistema debe tener una función que permita retroceder a un estado anterior de la simulación.

Razón: Poder controlar el proceso de simulación y visualizar nuevamente una parte de la misma.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar si a la etapa de la simulación a donde se retrocedió, forma parte de la solución

parcial del modelo.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que se pueda realizar el fotografiado periodico.

Conflictos: Requerimiento 1.7.4

Materiales de apoyo: Diagrama de Casos de Uso. Sección de Fundamentos Básicos

Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 1.7.6

Tipo de requerimiento: 9

Evento/caso de uso #: 1,11

Descripción: El sistema debe tener una función que permita continuar la simulación

Razón: Poder controlar el proceso de simulación, y observar como se comporta el modelo después de haber sido detenida la simulación.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que la solución grafica se construya a partir de donde se detuvo la simulación.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que el modelo acepte un estado inicial de partida.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 2

Tipo de requerimiento: 9

Evento/caso de uso #: 1,12,13

Descripción: El sistema debe permitir que se obtenga un reporte impreso de los resultados de la prueba.

Razón: Facilitar el análisis posterior a la prueba del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Obtener el reporte impreso, tal cual como se edito durante la prueba.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Debe existir un archivo en donde estén almacenadas las observaciones que corresponden al reporte que se desea imprimir.

Conflictos: Requerimientos 2.2

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 5 de Noviembre del 2004

Requerimiento: # 2.1

Tipo de requerimiento: 9

Evento/caso de uso #: 1,12

Descripción: El sistema debe proveer un medio para que el usuario pueda escribir las observaciones de la prueba on-line durante la simulación.

Razón: Facilitar el análisis posterior a la prueba del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que las observaciones anotadas, se correspondan con el reporte impreso.

Satisfacción del cliente: 4

Insatisfacción del cliente: 4

Dependencias: Que se pueda detener la simulación para anotar estas observaciones.

Conflictos: Requerimiento 1.7.2

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 2.2

Tipo de requerimiento: 9

Evento/caso de uso #: 1,12

Descripción: El sistema debe permitir almacenar las observaciones en un medio de almacenamiento secundario.

Razón: Proveer el medio necesario para extraer la información contendrá el reporte impreso.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que se haya creado el archivo correspondiente.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que se pueda importar la información editada en memoria principal a memoria secundaria.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 2.3

Tipo de requerimiento: 9

Evento/caso de uso #: 1,12

Descripción: El sistema debe permitir que se puedan modificar las observaciones.

Razón: Corregir observaciones previas.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que el archivo contenga las últimas modificaciones realizadas

Satisfacción del cliente: 5

Insatisfacción del cliente: 4

Dependencias: Que se pueda importar la información editada en memoria principal a memoria secundaria.

Conflictos: Requerimiento 2.2

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 2.4

Tipo de requerimiento: 9

Evento/caso de uso #: 1,12

Descripción: El sistema debe permitir que se consulten observaciones de pruebas realizadas anteriormente.

Razón: Corroborar si las observaciones anteriores se corresponden con los criterios actuales del usuario.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que el archivo contenga las últimas modificaciones realizadas

Satisfacción del cliente: 5

Insatisfacción del cliente: 4

Dependencias: Que se pueda importar la información editada en memoria principal a memoria secundaria.

Conflictos: Requerimiento 2.2

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 3

Tipo de

requerimiento: 10a

Evento/caso de uso #: 1,5

Descripción: La interfaz gráfica en la que se muestra la solución del modelo, debe presentarse por defecto en colores agradables a la vista del usuario, donde exista un claro contraste entre el fondo de la pantalla y la solución grafica.

Razón: Evitar producir cansancio en la vista del usuario, ya que esto podría dificultar la observación adecuada de la prueba del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Consultar al usuario con respecto al cansancio de su vista, tras varias sesiones de

prueba.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para modificar los colores de la representación gráfica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 3.1

Tipo de requerimiento: 10a,11b

Evento/caso de uso #: 1,5

Descripción: El usuario puede modificar los colores por defecto de la solución grafica.

Razón: Que el usuario pueda adecuar el ambiente de graficación de la prueba de acuerdo a sus preferencias, lo que lo hará sentir más a gusto al momento de realizar las pruebas del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda utilizar los colores de su preferencia.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para modificar los colores de la representación gráfica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 4

Tipo de requerimiento: 10a,11b

Evento/caso de uso #: 1,5

Descripción: El usuario puede modificar la escala en que se representa la solución grafica del modelo.

Razón: Que el usuario pueda adecuar el ambiente de graficación de la prueba de acuerdo a sus preferencias, y que de acuerdo pueda observar mejor el comportamiento del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que el usuario pueda realizar los cambios deseados.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para modificar loa escala de la representación gráfica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 5

Tipo de requerimiento: 12a

Evento/caso de uso #: 1,5

Descripción: El tiempo en que se grafica la solución del modelo no representa una limitante del sistema.

Razón: La simulación no esta orientada a representar un sistema de tiempo real, sino a estudiar el detalladamente el comportamientos del modelo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que la salida del modelo sea graficada correctamente sin importar el tiempo en

que sea graficada.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo cuente con librerías adecuadas para representar la solución gráfica del modelo correctamente.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 6

Tipo de requerimiento: 11b

Evento/caso de uso #: 1,5,10

Descripción: Los intervalos de tiempo en que se realiza el fotografiado periodico se pueden configurar.

Razón: Aumentar el grado de precisión de la prueba.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la cantidad de estados capturados se corresponda con el intervalo de tiempo

Seleccionado y el tiempo de la prueba.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: El mínimo intervalo de tiempo seleccionado, debe ser mayor al tiempo en que se genera y muestra la solución grafica.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 7

Tipo de requerimiento:

14d

Evento/caso de uso #: 1,10

Descripción: Las fotos deben ser guardadas en archivos tipo jpg o gif.

Razón: La portabilidad que ofrece este tipo de formatos

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que los archivos creados puedan ser abiertos con herramientas orientadas a

procesar este tipo de archivos.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo provea los mecanismos necesarios para la creación de archivos de este tipo.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 5 de Noviembre del 2004

Requerimiento: # 8

Tipo de requerimiento: 14d, 12f

Evento/caso de uso #:

Descripción: El sistema debe ser desarrollado en un lenguaje de alto nivel y no en una herramienta como SIMULINK.

Razón: Que el sistema pueda solucionar modelos complejos, que no pueden ser resueltos con herramientas como SIMULINK.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que el sistema resuelva correctamente modelos complejos

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo permita desarrollar rutinas eficientes para la aplicación de los métodos numéricos seleccionados.

Conflictos: No existen conflictos

Materiales de apoyo:

Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 9

Tipo de requerimiento: 10a

Evento/caso de uso #: 12

Descripción: El sistema debe permitir que se active una ventana de texto usuario puede escribir las observaciones correspondientes a la prueba que esta realizando en ese momento.

Razón: Proveer un mecanismo práctico para que el usuario lleve a cabo esta operación.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que la ventana se pueda activar durante la prueba del modelo.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 9.1

Tipo de requerimiento: 12g

Evento/caso de uso #: 12

Descripción: La ventana de edición debe permitir el scroll-back.

Razón: Procesar el volumen del texto escrito por el usuario sin importar su tamaño.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que el texto escrito se desplace correctamente a medida que se va llenando la

ventana.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso. Sección de Fundamentos Básicos.

Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 9.2

Tipo de requerimiento:

10a, 11a

Evento/caso de uso #: 12

Descripción: El sistema debe permitir que el usuario active y desactive la ventana de edición.

Razón: Hacer mas sencillo al usuario la utilización de esta herramienta.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la ventana aparezca y desaparezca cuando se activen los mecanismos adecuados (click del ratón)

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 9.3

Tipo de requerimiento:

10a, 11a

Evento/caso de uso #: 12

Descripción: El sistema debe permitir que el usuario mueva la ventana de edición.

Razón: Hacer mas sencillo al usuario la utilización de esta herramienta.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la ventana se mueva cuando se activen los mecanismos adecuados (arrastre a través del ratón)

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 9.4

Tipo de requerimiento:

10a, 11a, 11b

Evento/caso de uso #: 12

Descripción: El sistema debe permitir que el usuario configure el tamaño de la ventana de edición.

Razón: Hacer mas sencillo al usuario la utilización de esta herramienta.

Fuente: Coordinador del Proyecto

Criterio de medida:

Que la ventana cambie de tamaño va cuando se activen los mecanismos adecuados

( a través del ratón)

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 9 de Noviembre del 2004

Requerimiento: # 10

Tipo de requerimiento:

12a, 14d

Evento/caso de uso #: 12,13

Descripción: Las anotaciones de la ventana deben ser almacenadas en un archivo de texto.

Razón: La portabilidad que ofrece este tipo de formatos, y por la rapidez con que se pueden imprimir.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que los archivos creados puedan ser abiertos con herramientas orientadas a

procesar este tipo de archivos.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo provea los mecanismos necesarios para la creación de archivos de texto.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 10 de Noviembre del 2004

Requerimiento: # 10.1

Tipo de requerimiento:

11a

Evento/caso de uso #: 12,13

Descripción: Las archivos de texto almacenados deben guardar por defecto la fecha de creación y un número que identifique el modelo que se esta probando en ese momento.

Razón: Facilidad para que el usuario pueda relacionar la información contenida en el archivo con el modelo que desea analizar.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que los archivos creados guarden esta información.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Desarrollar la rutinas de programación que anexen automáticamente esta información al archivo de texto.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 10 de Noviembre del 2004

Requerimiento: # 10.2

Tipo de requerimiento:

11a

Evento/caso de uso #: 12,13

Descripción: El nombre con que se guarda el archivo de texto, se creara por defecto con el número que identifica el modelo que se esta probando, concatenado con la fecha de creación.

Razón: Facilidad para ubicar el archivo e imprimirlo.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que los archivos creados se guardan con estos parámetros.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Desarrollar la rutinas de programación que permitan crear los archivos de esta forma .

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 11 de Noviembre del 2004

Requerimiento: # 11

Tipo de requerimiento:

12c

Evento/caso de uso #: 1,5

Descripción: El sistema debe proveer una buena precisión en la graficación de la solución

Razón: El éxito o fracaso de la prueba depende de la observación del comportamiento de la prueba, por lo tanto los resultados de la solución del modelo deben graficarse con la mayor precisión posible.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar la graficación de la solución de modelos característicos, donde ya se conoce su salida.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo provea las funciones adecuadas para calcular y graficar con precisión las soluciones del modelo.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso.

Historia: Creado el 12 de Noviembre del 2004

Requerimiento: # 12

Tipo de requerimiento:

11a

Evento/caso de uso #:

Descripción: El sistema debe permitir que el usuario etiquete las entradas de las variables del modelo.

Razón: Facilidad para que el usuario pueda utilizar el sistema, ya que las etiquetas de las variables permiten relacionar mejor el modelo con el sistema real que se pretende simular.

Fuente: Coordinador del Proyecto

Criterio de medida:

Ninguno

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo:

Historia: Creado el 13 de Noviembre del 2004

Requerimiento: # 13

Tipo de requerimiento:

11a

Evento/caso de uso #:

Descripción: El sistema debe proveer una ventana de ayuda al usuario, por cada uno de los módulos presentados.

Razón: Facilidad para que el usuario pueda utilizar el sistema.

Fuente: Coordinador del Proyecto

Criterio de medida:

Verificar que los la información contenida en cada ventana, se relaciones con el uso del modulo en donde fueron activadas.

Satisfacción del cliente: 5

Insatisfacción del cliente: 5

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual.

Conflictos: No existen conflictos

Materiales de apoyo:

Historia: Creado el 13 de Noviembre del 2004