• No se han encontrado resultados

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

N/A
N/A
Protected

Academic year: 2021

Share "ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE"

Copied!
24
0
0

Texto completo

(1)

MOTIONDRAWING

Andrés Felipe Mejía Varón

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE Julio 2012

V 1.0.0

(2)
(3)

Contenido

HISTORIAL DE CAMBIOS ... ¡ERROR! MARCADOR NO DEFINIDO.

CONTENIDO ... 2 LISTA DE TABLAS ... 4 LISTA DE ILUSTRACIONES ... 5 1. INTRODUCCIÓN ... 6 1.1 PROPÓSITO ... 6 1.2 ALCANCE ... 6

1.3 DEFINICIONES,ACRÓNIMOS, Y ABREVIACIONES ... 6

1.4 REFERENCIAS ... 7

1.5 APRECIACIÓN GLOBAL... 7

2. DESCRIPCIÓN GLOBAL ... 9

2.1 PERSPECTIVA DEL PRODUCTO ... 9

2.1.1 Interfaces con el sistema ... 9

2.1.2 Interfaces con el usuario ... 9

2.1.3 Interfaces con el Hardware ... 10

2.1.4 Interfaces con el Software ... 11

2.1.5 Interfaces de Comunicación ... 12

2.1.6 Restricciones de Memoria ... 12

2.2 FUNCIONES DEL PRODUCTO ... 13

2.3 CARACTERÍSTICAS DEL USUARIO ... 14

2.4 RESTRICCIONES ... 15

2.5 MODELO DEL DOMINIO ... 15

2.6 SUPOSICIONES Y DEPENDENCIAS ... 17

2.6.1. Suposiciones ... 17

2.6.2. Dependencias ... 17

3. REQUERIMIENTOS ESPECÍFICOS ... 18

3.1 REQUERIMIENTOS DE INTERFACES EXTERNAS ... 18

3.1.1 Interfaces con el Usuario ... 18

3.1.2 Interfaces con el Hardware ... 18

3.1.3 Interfaces con el Software ... 19

3.1.4 Interfaces de Comunicaciones ... 19

3.2 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE... 19

3.2.1. Funcionalidad 1: Configuración ... 20

3.2.2. Funcionalidad 2: Conexión ... 20

3.2.3. Funcionalidad 3: Detección de cuerpos ... 20

3.2.4. Funcionalidad 4: Dibujo de movimiento ... 20

3.3 REQUERIMIENTOS DE DESEMPEÑO ... 20

3.4 RESTRICCIONES DE DISEÑO ... 20

3.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES) ... 21

3.5.1 Confiabilidad ... 21

3.5.2 Disponibilidad... 21

3.5.3 Seguridad ... 21

3.5.4 Mantenibilidad ... 21

(4)
(5)

Lista de Tablas

Tabla 1: Historial de cambios ... ¡Error! Marcador no definido. Tabla 2: Acrónimos ... 7

(6)

Lista de Ilustraciones

Ilustración 5: Interfaces con el usuario ... 10 Ilustración 9: Restricciones ... ¡Error! Marcador no definido. Ilustración 18: Interfaces de Hardware ... 18 Ilustración 20: División por Funcionalidades ... 19

(7)

1. Introducción

1.1 Propósito

El presente documento presenta la especificación de requerimientos de software para el proyecto MOTIONDRAWING y busca la precisa definición del prototipo de aplicación, en su totalidad, de acuerdo con las restricciones y necesidades del cliente que se consignan como requerimientos y fijan un acuerdo sobre el alcance del proyecto mismo.

El documento está dirigido a toda la comunidad académica en general, incluyendo a los estudiantes de la facultad de Artes de la Pontificia Universidad Javeriana con el objetivo de fomentar los proyectos interdisciplinarios entre facultades y promover el fácil entendimiento entre los involucrados en los diferentes proyectos.

1.2 Alcance

El producto a desarrollar, es una aplicación prototipo para la integración del sensor de captura de movimiento de Microsoft KINECT con la plataforma gráfica VITRAL, desarrollada en el Departamento de Ingeniería de Sistemas, para la creación de presentaciones artísticas interactivas.

La herramienta MOTIONDRAWING surge principalmente de la necesidad de una estudiante de Artes Escénicas de la Pontificia Universidad Javeriana de evidenciar la siguiente tesis: “Los cuerpos en movimiento generan dibujos en el espacio”. Adicionalmente, se propone como un punto de partida para la generación de propuestas de trabajo interdisciplinario y para incitar la creación de proyectos en áreas relativamente nuevas como la animación y los videojuegos.

La aplicación usará los algoritmos de reconocimiento de cuerpos integrados en el sensor de captura de movimiento KINECT para realizar representaciones gráficas (dibujos) de movimientos coreográficos (baile), sobre la plataforma VITRAL respetando las necesidades de calidad de dibujo y tiempo de respuesta, indicadas por el cliente e las reuniones sostenidas durante el transcurso del desarrollo del proyecto y detalladas a profundidad en el presente documento. Además, permitirá la personalización de los dibujos generados, mediante configuraciones realizadas dentro de la aplicación por el usuario, detalles como la cantidad de puntos a dibujar o longitud de la línea podrán determinarse en la aplicación.

1.3 Definiciones, Acrónimos, y Abreviaciones

API Aplication Programming Interface

(8)

DBMS Data Base Management System

GNU Es un acrónimo recursivo que significa "GNU No es Unix"

GNU GPL General Public License o licencia pública general

JDBC Java DataBase Connectivity

JVM Java Virtual Machine

LAN Local Area Network

PHP Es un acrónimo recursivo “Hypertext Preprocessor”

RFC Request For Comments

SDD Software Design Description

SQL Structured Query Language

SRS Software Requirement Specification

WLAN Wireless Local Area Network

WPA World Poker Association

Tabla 1: Acrónimos

1.4 Referencias

1.5 Apreciación Global

El presente documento describe la aplicación en términos generales, pero realiza una vista en detalle sobre lo que debe realizar y bajo qué parámetros debe realizarlo. Para el mejor entendimiento del mismo se ha dividido el texto en tres grandes secciones:

Sección Descripción Ubicación

Introducción Permite al lector conocer

el contexto en el que se realiza la aplicación, por qué se realiza y quién es el beneficiario de la misma.

Descripción del producto Esta sección presenta una visión general de la aplicación y de sus interacciones con otros sistemas y usuarios, que definen el funcionamiento de la aplicación.

(9)

Detalle de producto Describe los procedimientos que se siguieron para levantar, verificar y validar los requerimientos para así asegurar la calidad del producto final

(10)

2. Descripción Global

2.1 Perspectiva del Producto 2.1.1 Interfaces con el sistema

MOTIONDRAWING es una aplicación totalmente nueva, desarrollada como un ejercicio

académico y como proyecto interdisciplinario por lo que no se necesita de interacción con entidades financieras o administradoras estatales. Como su objetivo general es la integración del sensor de captura de movimiento KINECT con la plataforma gráfica

VITRAL, se utilizará el API de Microsoft con sus controladores y se interactuará con los

mismos, así mismo se interactuará con la plataforma VITRAL desarrollada en el lenguaje Java y basada en la librería gráfica OpenGL.

2.1.2 Interfaces con el usuario

La interacción principal del usuario final con el aplicativo se dará por medio del sensor de captura de movimiento KINECT, pero, adicionalmente contará con interfaces gráficas de usuario (GUI) para configurar los diferentes parámetros para la presentación de los dibujos resultantes. La aplicación consiste de dos partes principales: la primera es el subsistema que se encarga de recoger la información del sensor para enviar la información a la plataforma virtual, aquí puede configurarse el puerto de comunicación con vitral y la tolerancia a movimiento.

La segunda, es sobre la plataforma vitral y se encarga de la configuración de diferentes parámetros, como duración de la línea, cantidad de puntos a graficar, etc.

La comunicación entre las partes se realiza por medio sockets* con protocolo TCP/IP por lo que la tarjeta de red será una interface indirecta con el usuario.

(11)

Ilustración 1: Interfaces con el usuario

2.1.3 Interfaces con el Hardware

Debido a que se usará el API de Microsoft para la aplicación de recopilación de datos del sensor KINECT, es necesario que la máquina en la que se ejecute este aplicativo tenga instalada la plataforma .NET para su funcionamiento. Por otra parte, la plataforma VITRAL está desarrollada en java que es prácticamente independiente de sistema operativo.

•Interfaz usada para el ingreso de datos en campos de texto. Ejemplo de uso de teclado: Registro de usuario

Sensor de

captura de

movimiento

KINECT

•Interfaz usada para la navegabilidad entre interfaces gráficas, la selección de las diferentes opciones que da el sistema, el envio de formularios hacia la aplicación.

Ratón:

•El monitor permite al usuario, mediante una interfaz gráfica, observar las diferetnes GUI's que conforman la aplicación. Se debe especificar la resolución que debe se soportada por la pantalla, por ejemplo: "La pantalla debe soportar una resolución de 1024 * 768"

Pantalla:

•Para las interfaces GUI se debe especificar la forma de hacerlas es decir, librerias, programas y extensiones utilizadas para dicha tarea, ademas, al igual que en la interfaz "Pantalla" se debe definir la resolución que tendran las diferentes GUI's de la aplicaciión. Ejemplo: "Las interfaces gráficas de usuario tendran

una resolución de 1024 * 768, y serán implementadas en Java Swing y Java Awt."

Interfaz GUI:

•En ocasiones las aplicaciones aconsejan que para una experiencia mejor entre el usuario y el software es recomendable el uso de una tarjeta gráfica integrada de 64 MB de RAM.

Tarjeta

Gráfica:

•Si la aplicación esta destinada a funcionar bajo un entorno e red es necesario que cuente con una tarjeta de red Ethernet o Inalámbrica.

Tarjeta de

Red:

(12)

2.1.4 Interfaces con el Software

MOTIONDRAWING usa el API de Microsoft para el manejo del sensor, por lo tanto, la

máquina en la que se conecte el sensor debe tener un sistema operativo Windows 7 y el framework .NET 4 para garantizar el funcionamiento de la aplicación. En cuanto a el componente gráfico VITRAL no se tiene requisito de sistema operativo pero si se debe

tener una máquina virtual de java de 32 bits.

•La arquitectura utilizada para el proyecto será de tubos y filtros. •Mecanismo de transporte confiable y orientado a conexión, evitando

recepción de paquetes incompletos o dañados.

Protocolo de

comunicación TCP/IP

•Se recomienda como mínimo tener 1 Ghz en la máquina donde se va a instalar la aplicación.

•La aplicación está siendo desarrollada en una máquina con Intel Core i3 2.13Ghz.

•Dene tener compatibilidad con JRE, Java Virtual Machine para la plataforma VITRAL y plataforma .NET para la conexión con el KINECT.

Procesador

•La aplicación utilizará cualquier puerto TCP mayor a 1024. •Debe ser mayor a 1024 para evitar conflictos con otras aplicaciones. •Para la comunicación de una máquina dentro de una red con otras máquinas

y completar la comunicación entre éstas, se deberá tener instalada una tarjeta de red que soporte el estándar de la IEEE 802.3 (Ethernet) y/o 802.11 (Wi-Fi).

Puerto de red TCP

•Se recomienda como mínimo tener 1 GB en la máquina donde se va a instalar la aplicación.

•La aplicación está siendo desarrollada en una máquina con 2 GB

Memoria RAM

•Se recomienda como mínimo tener 20 MB de almacenamiento disponible en la máquina donde se va a instalar la aplicación.

•La aplicación está siendo desarrollada en una máquina con 220 GB de almacenamiento disponible.

Disco Duro

•Puede ser, de cable o inalámbrica, que este conectada a Internet. •Debe ser compatibles con dispositivos de red como lo son Hubs, Switches,

Routers.

•En el caso de usarse un router, este permitirá un enrutamiento adecuado dentro de la red y a su vez optimización de la conexión a través de la Internet. •El sensor KINECT usa una conexión estándar USB 2.0.

(13)

2.1.5 Interfaces de Comunicación

La aplicación MOTIONDRAWING para la comunicación de sus dos componentes principales componentes usará el protocolo TCP/IP para la comunicación a través de una red de área local (LAN).

La comunicación del sensor entre el sensor y la máquina que procesa la información del sensor se realizará a través de puertos USB estándar y su funcionamiento ya está encapsulado en el API de Microsoft.

MOTIONDRAWING usará la implementación de la clase Socket tanto de Java como de

C# por lo que se cumple el estándar descrito en el RFC correspondiente y, para evitar conflictos con otras aplicaciones, se recomendará el uso de puertos superiores al 1024 dónde se encuentran los puertos conocidos.

La aplicación no manejará persistencia por lo que no se tendrán en cuenta el manejo de archivos o conexiones con motores de bases de datos.

2.1.6 Restricciones de Memoria

Las restricciones de memoria para el correcto funcionamiento del aplicativo son:

 Máquina Virtual de Java (JVM): se recomienda tener la versión 1.6 que requiere 80 MB de espacio libre en el disco duro y 64 MB de RAM.

 Microsoft Kinect API: Las especificaciones del API recomiendan tener como mínimo 2 GB en la memoria RAM.

(14)

2.2 Funciones del Producto

MOTIONDRAWING como producto de software contará con las siguientes funciones:

• La aplicación aprovechará el API de microsoft para el reconocimiento de cuerpos y la identificación de esqueletos para el rastreo de

movimientos.

• La aplicación reconocerá un mínimo de 7 puntos principales del cuerpo humano como articulaciones principales, cabeza, etc.

Reconocimiento de movimientos

• Para la obtención de mejores resultados finales de dibujo se integrará el sensor kinect con la plataforma VITRAL

• Aunque la librería gráfica permita manipular objetos en tres

dimensiones los dibujos realizados serán plasmados como objetos en dos dimensiones, la coordenada Z se usará para determinar el grosor del trazo.

(15)

2.3 Características del Usuario

La aplicación MOTIONDRAWING está diseñada para un cliente específico con una necesidad concreta, por lo que el único usuario final para este proyecto es dicho cliente que cumple con las siguientes características:

Ilustración 2 - Caracterización del usuario

Usuario

Final

Descripción: Es todo aquel que use el producto, ya que no existen

diferentes roles dentro de la aplicación.

Privilegios: Puede realizar la configuración inicial para el desempeño

de la aplicación.

Experiencia Técnica: Conocimiento básico de manejo de aplicaciones de Windows 7. Conocimiento básico del funcionamiento de los

sensores de captura de movimiento Uso: La aplicación será usada principalmente

en dos momentos: Sustentación del trabajo de grado y muestra pública del trabajo de

grado de la estudiante de la facultad de artes

(16)

2.4 Restricciones

Ilustración 3 - Restricciones

2.5 Modelo del Dominio

Restricciones generales

•Las interfaces de la aplicación y el código con su documentación están escritas en inglés.

Restricciones de software

•La aplicación usa APIs de licenciamiento libre para desarrollo de aplicaciones sin animo de lucro. •La aplicación requiere Windows 7 y plataforma .NET 4

•La aplicación requiere JVM

Restricciones de hardware

•Se requiere de una máquina que cumpla como mínimo con los siguientes requerimientos: • procesador Dual-core a 2,66 GHz.

•Puertos USB 2.0 dedicados para el sensor. •2 GB de memoria RAM

(17)

ID 01 Nombre Usuario

Descripción Representa al usuario final de la aplicación

Función Realiza las configuraciones pertinentes según el resultado final que desee. Datos No aplica

ID 02

Nombre Configuración

Descripción Representa una configuración de cualquiera de los componentes principales de la aplicación

Función Guarda la información de la configuración deseada

Datos Estructuras de datos con valores como banderas para enviar/pintar puntos, etc.

ID 03

Nombre Sensor

Descripción Representa al sensor de captura de movimiento

Función Recopila la información de un objeto en movimiento para enviarlo al subsistema motiondrawing_sensor

Datos No aplica

ID 04

Nombre MotionDrawing_sensor

Descripción Representa al subsistema que se encarga del procesamiento de la información recogida por el kinect y la envía al subsistema motiondrawing_paint

Función Procesa la información del sensor y la envía al siguiente subsistema Datos Estructuras de datos para el procesamiento de la información del kinect

(18)

Nombre MotionDrawing_paint

Descripción Representa al subsistema que procesa la información del subsistema motiondrawing_sensor y realiza los dibujos según la configuración establecida Función Procesa la información recibida del anterior subsistema y realiza los dibujos Datos Estructuras de datos pertinentes para el procesamiento y la realización de dibujos.

2.6

Suposiciones y Dependencias 2.6.1. Suposiciones

El usuario tiene conocimiento básico de computadores con sistema operativo Windows 7.

El tiempo de respuesta no es una prioridad para realizar el diseño de la aplicación. El usuario final cuenta con un sensor de captura de movimiento KINECT.

El API de manejo del sensor y la librería gráfica son de libre elección para el desarrollador.

Los requerimientos funcionales no podrán ser modificados.

Los requerimientos no funcionales podrán discutirse en reuniones para su modificación.

2.6.2. Dependencias

La aplicación debe estar en una red con buen tiempo de respuesta para asegurar su correcto funcionamiento.

Para la aprobación de un prototipo se debe contar con el visto bueno del cliente y el asesor.

(19)

3. Requerimientos Específicos

3.1 Requerimientos de Interfaces Externas 3.1.1 Interfaces con el Usuario

La aplicación interactuará de dos formas con el usuario de dos formas: a través de la interfaz gráfica de usuario, cuya interacción se realizará por medio del mouse. En dicha interacción solo se realizarán las configuraciones para el proceso a ejecutar.

La segunda forma en la que se interactuará con el sistema será por medio del sensor de captura de movimiento cuyas restricciones de captura son estar en el rango de visión del sensor y ser utilizado en ambientes cerrados ya que la luz solar impide el correcto funcionamiento del mismo.

La resolución de pantalla no es una restricción de la aplicación debido a que la librería gráfica se encarga de adaptar los resultados a la pantalla de la máquina en la que se ejecute la aplicación.

El protocolo de comunicación entre los subsistemas es el TCP/IP por lo que se requiere de una tarjeta de red (LAN o WLAN) para el completo funcionamiento del aplicativo.

3.1.2 Interfaces con el Hardware

Ilustración 4: Interfaces de Hardware

•La comunicación entre los dos componentes principales se realizará usando el protocolo TCP/IP, orientado a la conexión para garantizar que no se pierdan paquetes.

Protocolos de comunicación

•Aunque la aplicación no es distribuida, se pueden ejecutar varias instancias del progama por lo que se recomienda que se configuren puertos superiores al 1024. Puertos usados para la comunicación

•La aplicación funciona en cualquier LAN o WLAN que use el protocolo TCP/IP, en caso de no tener una infraestructura de red disponible, el uso de un enrutador o un punto de acceso es suficiente para el funcionamiento de la aplicación.

(20)

3.1.3 Interfaces con el Software

Para el manejo del sensor de captura de movimiento se usa el API de Microsoft de KINECT, cuyos requerimientos de software son:

 Sistema operativo Windows 7.  Framework .NET 4.

En cuanto al procesamiento de imágenes, la aplicación está desarrollada sobre la plataforma VITRAL, desarrollada en Java por lo que se debe contar con:

 Máquina Virtual de Java. Se recomienda la versión 6 actualización 27.  Controladores y librerías de la plataforma vitral.

3.1.4 Interfaces de Comunicaciones

Para la comunicación entre el sensor y el equipo se necesitan puertos USB 2.0 dedicados para el sensor y para la comunicación entre los componentes se requiere únicamente de una tarjeta de red que permita el uso del protocolo TCP/IP, ya sea de forma cableada o inalámbrica.

3.2 Características del Producto de Software

En esta sección se realizará una descripción general de las funcionalidades de la aplicación, y más adelante se especificarán los requerimientos con su respectivo mapeo hacia las funcionalidades y subsistemas.

Ilustración 5: División por Funcionalidades

Funcionalidad 1: Configuración

Funcionalidad 2: Conexión

Funcionalidad 3: Detección de cuerpos

Funcionalidad 4: Dibujo de movimiento

(21)

3.2.1. Funcionalidad 1: Configuración

Para lograr diferentes resultados, ambos subsistemas (sensor y painting), requieren que se establezcan parámetros iniciales, como por ejemplo, se debe especificar una tolerancia al movimiento; esto es, indicar la mínima cantidad de desplazamiento para que sea procesada por la aplicación. Además, debe determinarse el puerto por el que el subsistema painting debe escuchar.

3.2.2. Funcionalidad 2: Conexión

La aplicación debe realizar la conexión de forma exitosa y mantenerse ya que se requiere de un protocolo orientado a la conexión.

3.2.3. Funcionalidad 3: Detección de cuerpos

La aplicación recibirá la información del sensor de captura de movimiento en su subsistema sensor para procesarla y aplicarle un formato de fácil reconocimiento para el siguiente subsistema. Además se especifica que es necesario reconocer por lo menos 7 puntos sobre un jugador.

3.2.4. Funcionalidad 4: Dibujo de movimiento

El subsistema painting debe recibir la información del subsistema sensor y dibujarla teniendo en cuenta la configuración establecida previamente.

3.3 Requerimientos de Desempeño

Teniendo en cuenta las restricciones y necesidades del cliente se determinaron los requerimientos no funcionales detallados más adelante, donde las principales características a tener en cuenta son:

 La calidad de la línea como elemento visual, esto es, simular el trazo de un lápiz o un carboncillo.

 Cambios de grosor de trazo determinado por la distancia existente entre el sensor de captura de movimiento y la persona que realiza en movimiento.

 Aunque no se requiere respuesta inmediata entre la realización del movimiento y la aparición del dibujo, se requiere que no exista una diferencia mayor a 10 segundos entre una y otra.

3.4 Restricciones De Diseño

Teniendo en cuenta las necesidades del cliente y una previa investigación acerca de posibles APIs y librerías a utilizar, los lenguajes a utilizar serán C# (C Sharp) para el

(22)

manejo del sensor de captura de movimiento y Java para el procesamiento de imágenes. El paradigma usado será la programación Orientada a Objetos, por experiencia del desarrollador y familiaridad con el mismo.

3.5 Atributos del Sistema de Software (No funcionales) 3.5.1 Confiabilidad

La aplicación no guardará ningún tipo de información, tanto de personas como de lo que se llegue a procesar con la aplicación por lo que la confiabilidad no es una prioridad en el desarrollo de la aplicación.

3.5.2 Disponibilidad

La aplicación es un Stand Alone de un solo uso, es decir, se hará uso del aplicativo según el usuario final lo necesite, y él contará con los instaladores y deberá cumplir con los requisitos para realizarlo. Teniendo en cuenta lo anterior, la aplicación no debe centrarse en la disponibilidad.

3.5.3 Seguridad

MOTIONDRAWING no usará información sensible o privada de los usuarios, por lo que

protocolos de seguridad no serán necesarios dentro de la aplicación y por lo tanto no se tendrán en cuenta criterios de seguridad en el desarrollo del proyecto.

3.5.4 Mantenibilidad

Como se trata de un prototipo, todo el código de la aplicación debe estar debidamente comentado y se debe generar la documentación sobre cada una las características que se desarrollen, cuando sea posible.

3.5.5 Portabilidad

Al usar el API de Microsoft para el manejo del sensor de captura de movimiento, este subsistema no será portable, ya que requiere sistema operativo Windows 7. Para el procesamiento de imágenes, el subsistema painting será portable a plataformas que cuenten con una máquina virtual de java.

(23)
(24)

REFERENCIAS

[1] Wiegers, Karl. , Software Requirements Specification. Process Goodies 2002, Disponible en http://www.processimpact.com/goodies.shtml

[2] IronWorks, Plantilla SPMP, Segundo Semestre 2007, Pontificia Universidad Javeriana.

[3] Construx Software, Software Requirements Specification CXOne Standard, Construx Software Builder, Inc, Noviembre 2002.

[4] IEEE (Institute of Electrical and Electronics Engineers), IEEE Recommended Practice for Software Requirements Specificacitions, IEEE-SA Standards Board, Junio 1998.

[5] Introduction to TCP/IP [homepage de Internet]. Copyright 1995 PCLT. Disponible en: http://www.yale.edu/pclt/COMM/TCPIP.HTM

[6] Página principal de Windows [homepage de Internet]. ©2007 Microsoft Corporation. [citado 2007 Mar 25]. Disponible en: http://www.microsoft.com/spain/ windows/default.mspx

Referencias

Documento similar

You may wish to take a note of your Organisation ID, which, in addition to the organisation name, can be used to search for an organisation you will need to affiliate with when you

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)