2.12.

Revise los estándares IEEE 830 y PSS-05 de la ESA y mencione 3 reglas de cada
uno para especificar requisitos correctamente.
IEEE 830:

Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos

contradictorio no es implementable.

Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos
pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad
(cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear
excesivos recursos en implementar requisitos no esenciales.

Verificables: La ERS es verificable si y s´olo si todos sus requisitos son verificables. Un requisito
es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema
cumple con el requisito.

PSS-05

 Deberá ser responsabilidad del usuario la definición de los requisitos de usuario.

 Para hacer entregas incrementales, cada requisito de usuario deberá incluir un grado de
prioridad, de tal manera que el desarrollador pueda decidir la agenda de producción.
 El DRU proporcionará una descripción general de lo que el usuario espera que haga el
software

2.13. Mencione 5 sugerencias prácticas para efectuar una buena revisión de

requerimientos.
 Utilizar checklist.
 Realizar reunión de revisión.
 Prototipado
 Validación de testeabilidad
 Validación de modelos (A través de objetos, DFD, etc.)

2.14. Investigue en la web sobre una herramienta de Gestión de Requisitos y

evalúela a la luz de lo aprendido hasta ahora
2

CaliberRM:
Elegimos esta herramienta ya que cumple perfectamente con su función de gestionar los
requerimientos.

Estas son algunas de las características tiene este software:

 Gestión de requisitos
 Visualización de los requisitos
 Seguimiento y análisis de impactos en tiempo real
 Colaboración y revisión

3.1. Evalúe si en la definición de requerimiento o en sus características existe algún elemento

nuevo que no hayamos visto hasta ahora

No, ya habíamos estudiados estas definiciones y características anteriormente para el

desarrollo de nuestros sistemas. Hay algunos detalles que hemos recordado al haber leído el
contenido, pero en general ya es un tema conocido.

3.2 -Basado en el organigrama de requerimientos no funcionales, mencione uno

correspondiente a cada tipo, investigando datos adicionales si es necesario.
3

 Eficiencia: Los datos modificados en la base de datos deben ser actualizados para
todos los usuarios que acceden en menos de 2 segundos.
 Organizacionales: El procedimiento de desarrollo de software a usar debe estar
definido explícitamente (en manuales de procedimientos) y debe cumplir con los estándares
ISO 9000.
 Externos: El sistema no revelara a sus operadores otros datos personales de los
clientes distintos a nombres y números de referencia.
 Seguridad: Los permisos de acceso al sistema podrán ser cambiados solamente por el
administrador de acceso a datos.
 Usabilidad: El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4
horas.
 Portabilidad: El sistema diseñado y sus componentes deben ser portables en
plataformas GNU/Linux y Windows.
 De entrega: El software debe ser entregado en 1 CD con un label que detalle el
contenido.
 De implementación: Se iniciara la implementación del sofware en el servidor de
prueba con sistema operativo Windows 64 bits.
 Requerimientos éticos: Se mostrara un mensaje de error si se intenta cambiar datos
de transacciones, tales como facturas, Nota de debito, etc.
 De Espacio: Se requiere un mínimo de 40 GB libres para la instalación de software.
 De estándares: El software cumplirá con el estándar IEEE 830

Individuales:
4

1.5 Defina las actividades básicas de la IR. Incluya un ejemplo de su proyecto en cada
una

1. Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el

nombre comúnmente dado a las actividades involucradas en el descubrimiento
preliminar de los requisitos de usuario.

Ejemplo:

o Calcular y IMC de los usuarios.

o Ingresar/Consultar Alimentos.
o Generar Plan de nutrición automatizado.

2. Estudio de viabilidad: En esta fase se estima si el problema del usuario se podrá

resolver con la tecnología disponible y si el sistema será rentable según el
presupuesto del que se dispone.

Ejemplo:

Si, con la tecnología disponible es posible cumplir este requerimiento.

3. Análisis: Sobre la base de la extracción realizada previamente, comienza esta

fase en la cual se interactúa con clientes o usuarios para determinar los requisitos
funcionales y no funcionales del sistema, además del dominio de la aplicación.

Ejemplo:

Requisito funcional:

Generar plan de nutrición en Base al estado físico del usuario.

Requisito No funcional:

Los alimentos solo pueden ser agregados y modificados por un usuario

administrador.

4. Especificación: En esta fase se documentan los requisitos con mayor detalle y

precisión, de manera que sirva de base para un contrato entre el desarrollador y el
cliente.

Ejemplo:

Requerimiento: Generar plan de nutrición en Base al estado físico del usuario

Se debe tomar en cuenta datos como:

 Actividad física.
 Si sufre de alguna enfermedad.
5

 Peso deseado.
 Peso Ideal.

5. Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los

requisitos, es decir, verificar todos los requisitos que aparecen en el documento
especificado para asegurarse de que son aceptados por el cliente. Esto implica
verificar que los requisitos sean consistentes, que estén completos, que sean
realistas y que puedan ser verificables.

2.4. Para el ejemplo del avión en la pista, detalle un ejemplo similar aplicable a un
proceso de su sistema.

R: Ingresar_Mant_Cliente -> Ser Profesional en Nutricion.

D1: Dar acceso -> Ser administrador

D2: Ser Administrador -> Ser Profesional en Nutricion.

M-Ex: Ingresar_Mant_Cliente -> Ser administrador

2.5. Para cada una de las áreas de esfuerzo de la IR, elabore un producto a entregar
relativo a su proyecto.

(1) reconocimiento del problema

Los alimentos no incluyen una imagen de referencia.
(2) evaluación y síntesis
Debemos permitir al usuario cargar una imagen en el mantenimiento de alimentos,
además agregar el campo correspondiente en la tabla de la base de datos. Luego
debemos realizar cambios en el Query que recibe los datos de la pantalla de consulta
que permitan visualizar los cambios realizados en la tabla de alimentos.

(3) modelado
Cambios:
6

Pantalla: Mantenimiento Alimentos

Accion: Agregar PictureBox

Nombre: PicAlimento
Accion: Agregar Button
Nombre: BtnPic

Base de datos: Nutrición

Tabla: Alimentos
Acción: Agregar Columna de Imágenes
Nombre: Pic
Tipo: Picture

Query: Traer_datos_Consulta
Acción: Agregar el campo Pic al query.

(5) revisión.
Luego de haber realizado los cambios se realizarán varias pruebas:

 Agregar productos nuevos.

 Modificar productos existentes.
 Traer los Alimentos nuevos y viejos desde la pantalla de consulta.

2.8. Para cada uno de los tipos de requisitos expuestos, especifique uno de su
proyecto, incluyendo un requisito en negativo.
Requisitos que definen efectos sobre el entorno.
Solo presentar a los operadores del sistema los datos básicos de los clientes.
Requisitos muy generales.
Mantenimiento de todos los alimentos.
Requisitos funcionales.
7

Se debe realizar el calculo del IMC del usuario.

Requisitos de implementación.
Se debe tener instalado en la PC/Laptop el siguiente software: SQL Server 2008
Requisitos de rendimiento.
El software debe durar un promedio de 10 a 30 segundos para generar el plan
Requisitos de usabilidad.
El software debe ser muy interactivo a través de gráficos.
requisito en negativo:
El software no debe permitir que el usuario introduzca una fecha irreal para lograr el
peso deseado.

2.9. Especifique un requisito donde crea necesario utilizar negociación de requisitos,

aplicable a su proyecto
En el reporte del plan de nutrición se puede presentar una situación donde un usuario
requiere los detalles de macronutrientes, mientras que otros desean que se detallen
los micronutrientes.
En este caso se puede realizar una negociación donde todos los reportes detallen los
macronutrientes, pero que tengan la opción de más detalles, para también mostrar los
micronutrientes.
8

2.11. Sobre las características de una buena ERS, elabore un ejemplo que cumpla

Historial de Revisiones

Fecha Revisión Descripción Autor

05/10/2018 1.0 “Requerimientos de Interfaz” Jeyson Diez

Documento validado por las partes en fecha: 05/10/2018

Por el cliente Por la empresa suministradora

Fdo. D./ Dña Jose Perez Fdo. D./Dña Jeyson Diez

9
10

Contenido
Contents

HISTORIAL DE REVISIONES ...................................................................................................... 8

CONTENIDO ............................................................................................................................... 10

1 INTRODUCCIÓN................................................................................................................ 11

1.1 Propósito ...................................................................................................................... 11

1.2 Alcance ......................................................................................................................... 11

1.3 Personal involucrado................................................................................................... 11

1.4 Definiciones, acrónimos y abreviaturas .................................................................... 11

1.5 Restricciones ................................................................................................................ 12

1.6 Suposiciones y dependencias .................................................................................... 12

1.7 Evolución previsible del sistema ............................................................................... 12

2 REQUISITOS ESPECÍFICOS ............................................................................................ 12

2.1 Requisitos comunes de los interfaces ...................................................................... 13

2.1.1 Interfaces de usuario ................................................................................................. 13
2.1.2 Interfaces de hardware .............................................................................................. 14
2.1.3 Interfaces de software ............................................................................................... 14
2.1.4 Interfaces de comunicación ....................................................................................... 14

2.2 Requisitos funcionales ................................................................................................ 14

5. Requisito funcional 1 Autenticación ............................................................................... 14
6. Requisito funcional 2 Toma de datos ............................................................................. 14
7. Requisito funcional 3 Generar plan nutricional .............................................................. 14

2.3 Requisitos no funcionales .......................................................................................... 15

2.3.1 Requisitos de rendimiento ......................................................................................... 15
2.3.2 Seguridad................................................................................................................... 15
2.3.3 Fiabilidad.................................................................................................................... 15
2.3.4 Disponibilidad ............................................................................................................ 15
2.3.5 Mantenibilidad ............................................................................................................ 15
2.3.6 Portabilidad ................................................................................................................ 16

2.4 Otros requisitos ........................................................................................................... 16

11

1 Introducción
En el presente documento estaremos detallando los diferentes requisitos de software, los cuales son
necesarios para el correcto funcionamiento del mismo, también hablaremos sobre el propósito,
alcance, Restricciones, entre otras cosas indispensables para nuestro software.

1.1 Propósito
 El propósito general de este documento es darle a conocer al usuario la forma correcta de
trabajar en el sistema de M&P Nutrición

1.2 Alcance
 El actual documento se utilizará en el Software de M&P Nutrición.

1.3 Personal involucrado

Nombre Jeyson Diez
Rol Director de JD Technology
Categoría profesional Ingeniero en Informatica
Responsabilidades Organizar el equipo y asignar funciones
Información de contacto 809-413-5269

Nombre Luis Pérez

Rol Analista
Categoría profesional Licenciado en Informática
Responsabilidades Desarrollar el ERS
Información de contacto 809-233-2240

1.4 Definiciones, acrónimos y abreviaturas

HW: Hardware
SW: Software
SO: sistema operativo.
PC: (del inglés personal computer), computadora personal, es una microcomputadora diseñada en
principio para ser usada por una sola persona a la vez.
SGBD: sistema gestor de bases de datos, son un tipo de software muy específico, dedicado a servir
de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.
Login: (término inglés) es el proceso mediante el cual se controla el acceso individual a un sistema
informático mediante la identificación del usuario utilizando credenciales provistas por el usuario.
12

1.5 Restricciones
 El sistema sólo podrá ser utilizado en plataformas de Microsoft versión XP o posterior.

 Sólo los usuarios registrados podrán hacer uso del sistema.

1.6 Suposiciones y dependencias

En caso de que el equipo de cómputo utilice un SO diferente a los mencionados en la sección
anterior, el sistema no podrá ejecutarse.

1.7 Evolución previsible del sistema

En caso de que el consultorio cuente, en un futuro, con una sucursal, el sistema se modificará para
convertirlo en un sistema distribuido.
En caso de que la tienda cuente con internet, las compras se podrán realizar en línea, si así lo
deseara el usuario administrador.

2 Requisitos específicos
Número de requisito R1

Nombre de requisito Requisito de

autenticación

Tipo X Requisito Restricción

Fuente del requisito Todos los usuarios

deberán introducir
en la pantalla de
“login” un usuario
y contraseña
válidos en el
sistema para poder
entrar a éste.

Prioridad del requisito X Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito R2

Nombre de requisito Requisito de

descripción

Tipo Requisito X Restricción

13

Fuente del requisito El usuario

administrador
podrá acceder a
todos los módulos
del sistema,
mientras que el
usuario empleado
sólo lo podrá
generar planes de
nutricion.

Prioridad del requisito Alta/Esencial X Media/Deseado Baja/ Opcional

Número de requisito R3

Nombre de requisito Requisito de

visibilidad

Tipo X Requisito Restricción

Fuente del requisito El usuario

empleado podrá
ver los datos
básicos de los
clientes (Nombre,
Contacto, Tipo de
Cliente)

Prioridad del requisito X Alta/Esencial Media/Deseado Baja/ Opcional

2.1 Requisitos comunes de los interfaces

La interfaz de login necesita como entrada un usuario y contraseña válidos para poder dar acceso
a la siguiente interfaz.

La interfaz del módulo de preparación de dieta necesita como entrada el IMC del cliente. Como
salida generara un reporte con el plan nutricional.

2.1.1 Interfaces de usuario

La interfaz en uso deberá mostrar a los usuarios solamente la información necesaria para
realizar cualquier operación.
14

La interfaz en uso deberá mostrarle al usuario administrador sólo la información necesaria

para realizar una modificación.

2.1.2 Interfaces de hardware

El monitor: éste deberá mostrar las interfaces, así como la información necesaria para que
el usuario pueda trabajar adecuadamente con el sistema. El monitor deberá contar con una
resolución de 1024 x 768 pixeles.

El ratón: el sistema requerirá del ratón para que el usuario pueda realizar selecciones y
oprimir botones.

El teclado: el sistema permitirá al usuario introducir datos mediante el teclado.

Impresora de tickets: el sistema arrojará el desglose de la compra a través un ticket para el
cliente.

2.1.3 Interfaces de software

El sistema interactuará con la interfaz de impresión.

2.1.4 Interfaces de comunicación

El sistema se comunica con su base de datos a través del SGBD SQLServer.

2.2 Requisitos funcionales

El sistema permitirá la entrada a los usuarios que cuenten con la autorización necesaria.

El sistema recibirá los datos de clientes y Alimentos almacenándolos en la base de datos para
futuras consultas y diversas operaciones.

Si se hubiera algún error al momento de Generar el plan nutricional, el sistema deberá permitir
retroceder, es decir, deshacer la operación.

5. Requisito funcional 1 Autenticación

El usuario deberá proporcionar un usuario y contraseña válidos para poder tener acceso al
sistema.

6. Requisito funcional 2 Toma de datos

El sistema calculará el IMC del cliente a partir de datos como Altura, Peso, Actividad física,
etc.

7. Requisito funcional 3 Generar plan nutricional

El SW Generara un plan nutricional personalizado según el estado físico del cliente.
15

2.3 Requisitos no funcionales

2.3.1 Requisitos de rendimiento

El sistema ofrecerá respuesta al usuario en tiempo real.

2.3.2 Seguridad

1. Requisito funcional-Seguridad 1: Requisito de autenticación

El sistema requerirá de un usuario y contraseña válidos para poder

permitir el acceso.

2. Requisito funcional-Seguridad 2: Requisito de división de módulos

El sistema tendrá separados los módulos a los que puede acceder un

usuario convencional de los módulos a los que puede acceder el usuario
administrador.

3. Requisito funcional-Seguridad 3: Requisito de conexión.

El sistema sólo tendrá abierta la conexión a la base de datos mientras se

requieren información.

2.3.3 Fiabilidad

El sistema cerrará las conexiones inmediatamente terminando cualquier ejecución para

evitar pérdida de datos a cualquier percance inesperado.

2.3.4 Disponibilidad

En funcionamiento normal el sistema estará disponible el 85% del tiempo.

2.3.5 Mantenibilidad

1. Requisito funcional-Mantenibilidad 1: Requisito de mantenimiento

El sistema recibirá mantenimiento una vez por semana los primeros 6

meses.

2. Requisito de depuración de respaldos de bases de datos.

Se revisarán los respaldos de la base de datos para decidir si es necesaria

una depuración.
16

3. Requisito funcional-Mantenibilidad 3: Requisito de actualización de estadísticas.

Se actualizarán las estadísticas manualmente para no perjudicar el

rendimiento con una actualización automática.

4. Requisito funcional-Mantenibilidad 4: Requisito de comprobación de integridad de

datos.

Se comprobará la integridad y asignación estructural de objetos e índices

de la base de datos.

2.3.6 Portabilidad

1. Requisito funcional-Portabilidad 1: Requisito de SW

El sistema de M&P Software será portable siempre y cuando el equipo en

que se quiera instalar cuente con un SO igual o de versión posterior al primer equipo
donde se instaló

2. Requisito funcional-Portabilidad 2: Requisito de HW

M&P Software será portable siempre y cuando el equipo en el que se

instale tenga especificaciones de HW iguales o superiores al primer equipo donde se
instaló.

2.4 Otros requisitos

Si el usuario empleado quiere realizar alguna modificación deberá ser necesario que se presente
el usuario administrador con su contraseña, salir de la sesión del usuario empleado y entrar a la
suya.