INSTITUTO POLITÉCNICO NACIONAL Prof. Paula León A.

Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas Actividad 05. Requerimientos de
Fundamentos de Usuario (URS)
Ingeniería de Software

Fecha: 02 octubre 2021

_______________________________
Neyra Ortega Ericka Pamela
Nombre(s): _____________________________________________ No. Lista 25
___________ Grupo: 2NM21
___________
(Apellido paterno. Apellido materno. Nombre(s)

Objetivo: Identificar los componentes y funcionalidad del URS (Requerimientos de Usuario). Reconocer cómo se organizan los requerimientos dentro de un documento de requerimientos de
software.

 Los requerimientos para un sistema de software establecen lo que debe hacer el

sistema y definen las restricciones sobre su operación e implementación.  URS: Users Requeriments (Requerimientos de usuario)
 Los requerimientos funcionales son enunciados de los servicios que debe proporcionar  HMI: Human Machine Interface. (Interfaz Gráfica de Usuario).
el sistema, o descripciones de cómo deben realizarse algunos cálculos.  UPS: Fuente de Alimentación Ininterrumpida
 Usuarios: Personas con acceso al sistema, que según el grupo o perfil al
 Los requerimientos no funcionales restringen con frecuencia el sistema que se va a que pertenezcan disponen de una serie de privilegios en el sistema.
desarrollar y el proceso de desarrollo a usar. Éstos pueden ser requerimientos del  Privilegios: Es el conjunto de acciones a las que el usuario tiene
producto, requerimientos organizacionales o requerimientos externos. A menudo se
autorización para acceder o realizar.
relacionan con las propiedades emergentes del sistema y, por lo tanto, se aplican al
 Face plate: Cuadro de diálogo para operación manual/automático de los
sistema en su conjunto.
dispositivos/fases. (Carátulas).
 El documento de requerimientos de software es un enunciado acordado sobre los  CCM’s – Centros de Control de Motores
requerimientos del sistema. Debe organizarse de forma que puedan usarlo tanto los  FTView. Software Factory Talk View de Rockwell Automation (USA)
clientes del sistema como los desarrolladores del software.
 El proceso de ingeniería de requerimientos incluye un estudio de factibilidad,
adquisición y análisis de requerimientos, especificación de requerimientos, validación
de requerimientos y administración de requerimientos.
 La adquisición y el análisis de requerimientos es un proceso iterativo que se representa
como una espiral de actividades: descubrimiento de requerimientos, clasificación y
organización de requerimientos, negociación de requerimientos y documentación de Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer: el servicio
requerimientos.
que ofrece y las restricciones en su operación. Tales requerimientos reflejan las necesidades de
 La validación de requerimientos es el proceso de comprobar la validez, la consistencia, los clientes por un sistema que atienda cierto propósito, como sería controlar un dispositivo,
la totalidad, el realismo y la verificabilidad de los requerimientos. colocar un pedido o buscar información. Al proceso de descubrir, analizar, documentar y
 Los cambios empresariales, organizacionales y técnicos conducen a cambios en los verificar estos servicios y restricciones se le llama ingeniería de requerimientos (IR).
requerimientos para un sistema de software. La administración de requerimientos es el
proceso de gestionar y controlar dichos cambios.

1
Si una compañía desea otorgar un contrato para un gran proyecto de desarrollo de software, tiene que definir sus necesidades de tal forma que ofrezca una solución. Los
requerimientos deben redactarse de tal forma que muchos proveedores liciten para ganar el contrato, ofreciendo diferentes maneras de cubrir las necesidades del cliente.
Una vez otorgado el contrato, el proveedor tiene que escribir con más detalle una definición del sistema para el cliente para que comprenda y valide lo que hará el software.
Estos documentos suelen nombrarse documentos de requerimientos para el sistema.

Los requerimientos del usuario y los requerimientos del sistema se definen del siguiente modo:

1. Los requerimientos del usuario son enunciados, en un lenguaje natural junto con diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las
restricciones con las que debe operar.
2. Los requerimientos del sistema son descripciones más detalladas de las funciones, servicios y restricciones operacionales del sistema de software.
3. El documento de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará. Puede
formar parte del contrato entre el comprador del sistema y los desarrolladores del software.

Requerimientos del usuario y requerimientos del sistema

Los primeros por lo general no están interesados en la manera en que se implementará el sistema, y tal vez sean administradores a quienes no les atraigan las facilidades
detalladas del sistema. Mientras que los segundos necesitan conocer con más precisión qué hará el sistema, ya que están preocupados sobre cómo apoyará los procesos
de negocios o porque están inmersos en la implementación del sistema.

Para la mayoría de los sistemas grandes, todavía se presenta una fase de ingeniería de requerimientos claramente identificable, antes de comenzar la implementación del
sistema. El resultado es un documento de requerimientos que puede formar parte del contrato de desarrollo del sistema.

2
 Lectores de diferentes tipos de especificación de requerimientos

Requerimientos funcionales y no funcionales

Generalmente los requerimientos del sistema de software se clasifican como requerimientos funcionales o requerimientos no funcionales:

1. Requerimientos funcionales. Son enunciados sobre servicios que el sistema debe proveer, cómo debería reaccionar el sistema a entradas particulares y de cómo
debería comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos funcionales también explican lo que no debe hacer el sistema.
2. Requerimientos no funcionales. Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso
de desarrollo, como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a características o a
servicios individuales del sistema.

La distinción entre los diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones sencillas. Un requerimiento de un usuario interesado por la
seguridad, como el enunciado que limita el acceso a usuarios autorizados, parecería un requerimiento no funcional. Sin embargo, cuando se desarrolla con más detalle,
este requerimiento puede generar otros requerimientos que son evidentemente funcionales, como la necesidad de incluir facilidades de autenticación en el sistema.

Requerimientos funcionales

Los requerimientos funcionales para un sistema refieren lo que el sistema debe hacer. Tales requerimientos dependen del tipo de software que se esté desarrollando, de
los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requerimientos.

Requerimientos no funcionales

Los requerimientos no funcionales, son requerimientos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios. Pueden
relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden definir restricciones
sobre la implementación del sistema, como las capacidades de los dispositivos o las representaciones de datos usados en las interfaces con otros sistemas.

Los requerimientos no funcionales, como el rendimiento, la seguridad o la disponibilidad, especifican o restringen por lo general características del sistema como un todo.
Los requerimientos no funcionales, son más significativos que los requerimientos funcionales individuales. Es común que los usuarios del sistema encuentren formas para
trabajar en torno a una función del sistema que realmente no cubre sus necesidades.

3
 Tipos de requerimientos no funcionales

Los requerimientos no funcionales provienen de características requeridas del software (requerimientos del producto), la organización que desarrolla el software
(requerimientos de la organización) o de fuentes externas:

1. Requerimientos del producto. Estos requerimientos especifican o restringen el comportamiento del software. Los ejemplos incluyen requerimientos de
rendimiento sobre qué tan rápido se debe ejecutar el sistema y cuánta memoria requiere, requerimientos de fiabilidad que establecen la tasa aceptable de fallas,
requerimientos de seguridad y requerimientos de usabilidad.
2. Requerimientos de la organización. Son requerimientos de sistemas amplios, derivados de políticas y procedimientos en la organización del cliente y del
desarrollador. Los ejemplos incluyen requerimientos del proceso operacional que definen cómo se usará el sistema, requerimientos del proceso de desarrollo
que especifican el lenguaje de programación, estándares del entorno o el proceso de desarrollo a utilizar, y requerimientos ambientales que definen el entorno
de operación del sistema.
3. Requerimientos externos. Este término cubre todos los requerimientos derivados de factores externos al sistema y su proceso de desarrollo. En ellos se incluyen
requerimientos regulatorios que establecen lo que debe hacer el sistema para ser aprobado en su uso por un regulador, como sería un banco central;
requerimientos legislativos que tienen que seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos éticos que garanticen que el sistema
será aceptable para sus usuarios y el público en general.

4
 Requerimientos regulatorios

NORMA Oficial Mexicana

BEBIDAS ALCOHÓLICAS

NORMA OFICIAL MEXICANA NOM-199-

SCFI-2017, BEBIDAS ALCOHÓLICAS-
DENOMINACIÓN, ESPECIFICACIONES
FISICOQUÍMICAS, INFORMACIÓN
COMERCIAL Y MÉTODOS DE PRUEBA

Requerimientos regulatorios. Alimentos y bebidas (vinos).

5
  REQUERIMIENTO DEL PRODUCTO
El vino X se produce bajo condiciones y procesos. Extracción de jugo, fermentación, presión, filtración, conserva, embotellado hasta llegar al consumidor
final.
 REQUERIMIENTOS DE LA ORGANIZACIÓ N
Política de calidad de la empresa frente a la autoridad sanitaria (COFEPRIS,FDA en USA).
 REQUERIMIENTOS EXTERNOS
NORMA Oficial Mexicana
BEBIDAS ALCOHÓLICAS
NORMA OFICIAL MEXICANA NOM-199-SCFI-2017, BEBIDAS ALCOHÓLICAS-DENOMINACIÓN, ESPECIFICACIONES FISICOQUÍMICAS, INFORMACIÓN
COMERCIAL Y MÉTODOS DE PRUEBA

Algunas organizaciones grandes, como el Departamento de Defensa estadounidense y el Institute of Electrical and Electronic Engineers (IEEE), definieron estándares para
los documentos de requerimientos. Comúnmente son muy genéricos, pero útiles como base para desarrollar estándares organizativos más detallados. El IEEE es uno de
los proveedores de estándares mejor conocidos y desarrolló un estándar para la estructura de documentos de requerimientos. Este estándar es más adecuado para
sistemas como comando militar y sistemas de control que tienen un largo tiempo de vida y, por lo general, los diseña un grupo de organizaciones.

El documento de requerimientos de software:

El documento de requerimientos de software (llamado algunas veces especificación de requerimientos de software o SRS) es un comunicado oficial de lo que deben
implementar los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para un sistema, como una especificación detallada de los requerimientos del
sistema. En ocasiones, los requerimientos del usuario y del sistema se integran en una sola descripción. En otros casos, los requerimientos del usuario se definen en una
introducción a la especificación de requerimientos del sistema. Si hay un gran número de requerimientos, los requerimientos del sistema detallados podrían presentarse
en un documento aparte.

El documento de requerimientos tiene un conjunto variado de usuarios, desde el administrador ejecutivo de la organización que paga por el sistema, hasta los ingenieros
responsables del desarrollo del software.

6
El nivel de detalle que se incluya en un documento de requerimientos depende del tipo de sistema a diseñar y el proceso de desarrollo utilizado. Los sistemas críticos
necesitan tener requerimientos detallados porque la seguridad y la protección también deben analizarse de forma pormenorizada. Cuando el sistema lo desarrolla una
compañía independiente (por ejemplo, mediante la subcontratación), deben detallarse y precisarse las especificaciones del sistema

La información que se incluya en un documento de requerimientos depende del tipo de software que se va a desarrollar y del enfoque para el desarrollo que se use.

Especificación de requerimientos

La especificación de requerimientos es el proceso de escribir, en un documento de requerimientos, los requerimientos del usuario y del sistema. Idealmente, los
requerimientos del usuario y del sistema deben ser claros, sin ambigüedades, fácil de entender, completos y consistentes.

Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales, de forma que sean comprensibles para los usuarios del
sistema que no cuentan con un conocimiento técnico detallado. De manera ideal, deberían especificar sólo el comportamiento externo del sistema. El documento de
requerimientos no debe incluir detalles de la arquitectura o el diseño del sistema.

Formas de escribir una especificación de requerimientos del sistema

7
Procesos de ingeniería de requerimientos

Los procesos de ingeniería de requerimientos incluyen cuatro actividades de alto nivel. Éstas se enfocan en valorar si el sistema es útil para la empresa (estudio de
factibilidad), descubrir requerimientos (adquisición y análisis), convertir dichos requerimientos en alguna forma estándar (especificación) y comprobar que los
requerimientos definan realmente el sistema que quiere el cliente (validación).

Vista en espiral del proceso de ingeniería de requerimientos.

La figura anterior presenta este entrelazamiento. Las actividades están organizadas como un proceso iterativo alrededor de una espiral, y la salida es un documento de
requerimientos del sistema. La cantidad de tiempo y esfuerzo dedicados a cada actividad en cada iteración depende de la etapa del proceso global y el tipo de sistema que
está siendo desarrollado. En el inicio del proceso, se empleará más esfuerzo para comprender los requerimientos empresariales de alto nivel y los no funcionales, así como
los requerimientos del usuario para el sistema. Más adelante en el proceso, en los anillos exteriores de la espiral, se dedicará más esfuerzo a la adquisición y comprensión
de los requerimientos detallados del sistema.

Este modelo en espiral acomoda enfoques al desarrollo, donde los requerimientos se elaboraron con diferentes niveles de detalle. El número de iteraciones de la espiral
tiende a variar, de modo que la espiral terminará después de adquirir algunos o todos los requerimientos del usuario.

Prácticamente en todos los sistemas cambian los requerimientos. Las personas implicadas desarrollan una mejor comprensión de qué quieren que haga el software; la
organización que compra el sistema cambia; se hacen modificaciones al hardware, al software y al entorno organizacional del sistema.

Al proceso de administrar tales requerimientos cambiantes se le llama administración de requerimientos.

8
Para efectos de estudio de la ingeniería de software, revisaremos el desarrollo de este proceso en una planta productiva que actualmente se cuenta con un Sistema
de Monitoreo y Control de Planta denominado SC-PP-01 (marca Allen Bradley / Rockwell) para ejecutar las diferentes operaciones y recolección de datos de los
procesos en las áreas de Polivalente, Hidrogenación y PSI, el cual se encuentra instalado en un cuarto de cómputo ubicado en el edificio principal de Producción.
La plataforma actual se encuentra implementada bajo el concepto de Arquitectura Integrada, por el momento el proceso de fabricación se sigue en papel y de
manera semiautomática, es decir, a través de un documento llamado actualmente “Técnica de Fabricación”.

Los operadores de planta van lanzando las fases de agitación, temperatura, presión, carga de solventes, etc. Dichas fases se encuentran programadas en los
diferentes PLC´s de planta y se ejecutan a través de una aplicación (software) FTView de Rockwell desde los diferentes HMI’s de planta, la configuración de la
plataforma de control es Cliente-Servidor, se tiene un servidor principal donde reside la aplicación de FTView, y al cual se conectan los diferentes clientes
(HMI’s). Para el control de motores se tienen varios CCM´s (Centros de Control de Motores) en planta con red de control DeviceNet a su interior, dentro del
mismo se tiene un dispositivo Linking Device para convertir de DeviceNet a Ethernet y poder comunicarnos a los diferentes PLC’s de planta. Para el control de la
Instrumentación (válvulas, transmisores, etc), se tiene una red indepediente ControlNet para conexión hacia los mismos.

A continuación se presenta el documento Requerimientos de Usuario (User Requeriments. URS). (ANEXO. URS. PDF)

9
 INSTITUTO POLITÉCNICO NACIONAL Prof. Paula León A.
Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas Actividad 05. Requerimientos de
Fundamentos de usuario (URS)
Ingeniería de Software

Fecha: 02 octubre 2021

_______________________________
Nombre(s):
Neyra Ortega Ericka Pamela
_____________________________________________ No. Lista 25
___________ Grupo: 2NM21
___________
(Apellido paterno. Apellido materno. Nombre(s)

Parte A. Individual

1. Complete el nombre de la primera actividad de la metodología basada en planes tipo “V” o cascada combinada. (Línea punteada)

URS

1. Menciona 3 características de la industria del software a nivel mundial.

a.

10
 2. Los (escribe el nombre que recibe esta documentación) serán la base para la preparación de otra documentación del ciclo de vida del sistema, tales como la especificación
funcional, especificación de diseño y los protocolos de prueba.

Los requerimientos del usuario

3. ¿Cuál es el objetivo de los Requerimientos de Usuario?

reconocer como se organizan los requerimientos dentro de un documento de requerimientos de software

4. ¿Por qué se afirma que los Requerimientos de Usuario serán la base para la preparación de otra documentación del ciclo de vida del sistema?

Porque son genéricos y útiles como base para desarrollar estándares organizativos más detallados.

5. Complete el alcance de los URS (Para el sistema informatizado de referencia).

a Funciones de control basada en entradas / algoritmos / salidas.

b Permitir la operación manual de los dispositivos de campo y las operaciones de proceso.
c Administrar acciones de protección y seguridad lógica.
d Monitoreo y manejo de alarmas, interlocks y avisos, tanto del proceso como del sistema.
e Proveer el manejo de un HMI para la interacción entre el operador y el Sistema.
f Registro y monitoreo de variables críticas o necesarias del proceso, alarmas y eventos en tiempo real
g Contar con un Audit trail para el registro de las acciones del operador en el sistema.
h Intercambiar información con sistemas paquetes, para supervisión y control.

6. ¿Quién la realiza el URS?

El departamento de produccion

7. ¿Qué es Ingeniería de Requerimientos?

Es el proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones

11
 8. ¿Qué es Administración de Requerimientos?
Es el proceso de administrar tales requerimientos cambiantes

9. Completa las partes que conforman el URS del caso

práctico.

a. Requerimientos operacionales
b. Requerimientos de Documentación
c. Requerimientos de Infraestructura
d. Requerimientos de GMP
e. Requerimientos de Prevención y Medio Ambiente

10. ¿Qué se menciona acerca de “Audit Trail”?

Que se debe contar con uno para el registro de las acciones del operador en el sistema.

11. ¿Existe alguna norma relacionada con las Buenas Prácticas de Ingeniería? Mencione brevemente a qué normas y sección se hace referencia.


 Si  No
a. Nombre/sección/referencias: Norma oficial mexicana NOM-199-SFCI-2017 BEBIDAS ALCOHOLICAS
b. Tipo de requerimiento no funcional:  Requerimiento del producto  Requerimiento de la organización 
 Requerimiento externo

12. ¿Qué son los Requerimientos de Usuario?

Son enunciados, en un lenguaje natural junto con diagramas, acerca de quéservicios esperan los usuarios del sistema, y de las
restricciones con las que debe operar.
13. ¿Quién realiza el respaldo de datos, y cómo se debe presentar?
El integrador / compañía responsable de indicar la carpetas a respaldar de cada una de las aplicaciones de control. La información
deber ser copiada para garantizar su tiempo de archivo de acuerdo a los requerimientos por Aseguramiento de Calidad Departamento
Usuario.
14. ¿En qué sección del URS se encuentra el tema: “Evaluación de riesgos”?
En la sección de requerimientos de documentación

15. ¿Quién realiza la configuración de permisos de usuario?

La configuracion de permisos de usuario estara restringida al administrador del sistema

12
 DESCRIPCIÓN CÓDIGO UTILIDAD/ÁREA DE APLICACIÓN
1. Arquitectura  Arquitectura general Se requiere implementar una Arquitectura… Integrada conformada con las diferentes
de control redes, dispositivos y software de control, software de virtualización
 Configuración Arquitectura Se requiere que la configuración de la arquitectura sea Cliente – Servidor, es decir, contar con servidores donde
resida el software de control que dé servicio a los clientes / HMI’s distribuidos en las diferentes áreas de la
planta.
 Virtualización Requiere ser implementada bajo … el concepto de Ambiente Virtual, para ello es necesario utilizar como
plataforma standard VsPhere de VMWare. Se requiere una máquina virtual por cada aplicación de
1. Hardware  Servidores Servidores marca CISCO
 Clientes CPU’s con las siguientes características mínimas: CPU con velocidad de procesamiento de 1.6 GHz
 Switches de comunicación Para la conectividad de toda la red de control y conectividad hacia todos los HMI’s
 Pantallas HMI Pantallas Industriales HMI (Interface Hombre – Máquina)
 Equipo de control Los equipos de control (marca Allen Bradley). Controladores Programables de la familia ControlLogix
Chasis de 7 / 10 slots ControlLogix, Fuentes de Poder ControlLogix
2. Software  Servidores Sistema Operativo Windows Server 2012; VsPhere de VMware; Factory Talk View Server de Rockwell
 Clientes Sistema Operativo Windows 7; VMware; FTView Client de Rockwell; Antivirus McAfee
 HMI´s Controladores para el teclado táctil
3. Interfaces  Pantallas de operación Se requiere de pantallas de operación para el control y monitoreo de todos los equipos conectados al
sistema. resolución de 1024 x 768 pixeles.
 Elementos Dinámicos Menus listado de varias opciones; caratular o faceplate pequeños recuadros; dinamos graficos
 Parámetros Generales Se requiere de una pantalla donde se pueda ingresar un tipo de ajustes específicos
 Horario Automático La hora de verano e invierno deben ajustarse automáticamente
 Reloj y Fecha La hora y fecha del sistema deben ser inalterables para todos los usuarios
4. Funcionalidad  Variables de proceso Monitorear en tiempo real las variables de proceso en la tabla denominada “Variables de Proceso”
 Operación manual o Permitir al usuario de nivel autorizado de acuerdo a la matriz de seguridad a especificar durante la
automática fase de diseño
 Tendencias requieren tendencias en forma gráfica únicamente de las variables críticas de proceso
 Fases y Estados de Proceso Se necesita que la interfaz gráfica para cada tipo de fase esté en un formato y apariencia común.
5. Seguridad física  Seguridad de clima Se requiere instalar sistemas de clima / aires acondicionados en los Data Center y Cuartos CCM’s
 Control de acceso Se debe tener control de acceso restringido para el Data Center de Producción y Oficinas Administrativas
6. Seguridad lógica  Cuentas de Usuario de Calidad de “CMS” PNT18-19 (tamaño de contraseñas, niveles de usuario, número de intentos
Windows permitidos, caducidad de contraseña, etc)
 Longitud de Contraseña El password de usuario tendrá una longitud mayor a la longitud mínima definida
 Número de Intentos El sistema bloqueará una cuenta de usuario tras un número de intentos de acceso no autorizados
Permitido Ingreso de según el procedimiento de seguridad lógica PNT18-19 del Manual deCalidad de CMS
Contraseña
 Bloqueo de Cuenta por La sesión de trabajo de un usuario se bloqueará transcurrido el periodo de inactividad definido en el
Inactividad procedimiento de seguridad Lógica PNT18-19 del Manual de Calidad de CMS
 Configuración de Permisos de
Usuario
 Administración de Permisos
 Cuenta de Usuario Única 13
 Deshabilitar Cuentas de
Usuario
 Energía Eléctrica
Continuación…  Cuentas de Usuario de
Seguridad lógica Windows
 Longitud de Contraseña
 Número de Intentos
Permitido Ingreso de
Contraseña
 Bloqueo de Cuenta por
Inactividad
 Configuración de Permisos de
Usuario
 Administración de Permisos
 Cuenta de Usuario Única
 Deshabilitar Cuentas de
Usuario
 Energía Eléctrica
Calidad de “CMS” PNT18-19 (tamaño de contraseñas, niveles de usuario, número de
intentos permitidos, caducidad de contraseña, etc).
El password de usuario tendrá una longitud mayor a la longitud mínima definida
El sistema bloqueará una cuenta de usuario tras un número de intentos de acceso no
autorizados según el procedimiento
La sesión de trabajo de un usuario se bloqueará transcurrido el periodo de inactividad
definido en el procedimiento de seguridad Lógica PNT18-19
La configuración de los permisos de usuario estará restringida al administrador del
sistema.
El acceso a las herramientas de gestión de usuarios debe estar restringida a usuarios autorizados.
El sistema garantizará la unicidad del identificador de usuario
Las cuentas de usuario serán deshabilitadas en lugar de borradas
Se requiere para el sistema como fuente de suministro principal de energía eléctrica: Voltaje a 120 V,
+/- 10%
14