Requisitos del usuario, especificación de requisitos del usuario (URS), Hoja de especificaciones. ¿Qué es? ¿Cómo se crean estos documentos? ¿Es todo lo mismo? ¿O es algo completamente diferente?
Tal vez, cuando leas estas preguntas, te preguntes por un momento si son realmente todos iguales. Y algunos expertos de repente ya no están seguros tampoco. Pero no te mantendremos en suspenso por más tiempo.
En resumen: todas las expresiones describen los requisitos de un producto, por ejemplo, software, desde el punto de vista del usuario.
Por lo general, se crean cuando se compra un nuevo sistema o se modifica un sistema existente y tienen el siguiente contenido:
¿Qué debe ser capaz de hacer este software?
¿Qué espero de él?
¿Qué interfaces hay que tener en cuenta?
¿Quién escribe la URS?
En este artículo nos limitamos a los controladores lógicos programables, los llamados PLC.
Las cuatro preguntas guía mencionadas anteriormente deben ser formuladas y respondidas por todos al crear un requisito de usuario o incluso una especificación.
URS
Una URS es escrita por el grupo de personas que usarán el software o sistema informático.
Se describen los requisitos y no la solución terminada. Los diferentes requisitos no deben contradecirse entre sí. Los requisitos del usuario se pueden describir en forma de tabla o en texto continuo.
La ventaja del formato tabular es la claridad y la asignación de un número a cada requisito del usuario. De este modo, se da la trazabilidad a los mismos. La desventaja de la forma tabular es la breve descripción de los requisitos del usuario.
Ejemplo: me gustaría un instrumento de escritura a mano con tinta a prueba de documentos. La tinta debe ser azul y el implemento de escritura a mano no debe pesar más de 100 gramos, tener una longitud total máxima de 20 centímetros y tener un grosor aproximado de 15 milímetros de diámetro.
No: quiero un bolígrafo de la marca XYZI que escriba azul. Esa ya sería la solución.
El portal alemán de conocimiento y aprendizaje para la calificación de equipos, GMP: KnowHow Anlagenqualifizierung, utiliza un ejemplo para mostrar lo que podría ser un requisito de usuario para un PLC. Sobre la base de preguntas orientadoras, se explica el desarrollo de la URS para un PLC.
En este artículo, les damos una idea de la estructura y aportamos extractos de las más de 50 preguntas orientadoras.
Las siguientes áreas y temas forman la estructura de una URS:
Descripción del proyecto
Primero comienzas con una breve descripción del proyecto. La URS normalmente se envía a uno o más proveedores potenciales. De esta manera saben de qué se trata y pueden proponer una solución.
Las posibles preguntas orientadoras para la descripción del proyecto podrían ser:
¿Qué quiero decirle a mi proveedor potencial?
¿De qué se trata realmente el proyecto?
¿Dónde es el lugar donde se utiliza el software?
Requisitos regulatorios
Las posibles preguntas orientadoras son:
¿Qué directrices, leyes y reglamentos deben observarse?
¿Qué versión es vinculante?
¿Qué documentos nacionales, supranacionales e internacionales deberían incluirse?
Requisitos de la interfaz hombre-máquina
Los requisitos de interfaz hombre-máquina (Human Machine Interface – HMI) son la facilidad de uso de un sistema/software informático.
Las posibles preguntas orientadoras son:
¿Cómo se regula el funcionamiento del software/sistema informático?
¿La operación es intuitiva o el usuario tiene que ser entrenado durante varios días?
¿Son inmediatamente perceptibles los datos relevantes para el proceso y la calidad, es decir, claramente presentados?
Requisitos de performance/funciones
Las posibles preguntas orientadoras son:
¿Existe un rastro de auditoría?
¿Están definidos y disponibles los diferentes roles de usuario? ¿Qué procesadores están instalados en el sistema y qué rendimiento tienen?
¿Qué potencia de procesador se requiere para al menos 5 años de uso del sistema?
¿Cómo se instala el sistema? (¿A través de CD o descarga de Internet?)
¿Con qué frecuencia se utiliza el sistema? (24h/7d?)
Requisitos para la documentación de validación
Las posibles preguntas orientadoras y documentos que se producirán son:
¿Qué documentos se requieren de acuerdo con el plan maestro de validación?
¿Qué documentos creo yo mismo como usuario y cuáles compro al proveedor?
¿Qué pruebas se requieren y qué pruebas realiza el proveedor? (Por ejemplo:
White Box Test = Prueba de caja blanca = El desarrollador prueba el software; Black Box Test = Prueba de caja negra = El operador prueba el software con la interfaz de usuario).
Requisitos de análisis de riesgos del software
Matriz de trazabilidad
Functional Specification (FS) – Especificación funcional
Hardware Design Specification (HDS) – Especificación de diseño de hardware
Software Design Specification (SDS) – Especificación de diseño del software
HMI Design Specification – Especificación de diseño
Plan maestro de validación de software/plan de validación del sistema informático
Design Qualification (DQ) – Cualificación del diseño – Plan – Ejecución – Informe
Installation Qualification (IQ) – Calificación de la instalación – Plan – Ejecución – Informe
Capacitación
Las posibles preguntas orientadoras son:
¿Quién debe ser entrenado?
¿Cuándo deben realizarse los entrenamientos?
¿Quién lleva a cabo las capacitaciones?
Seguridad Ocupacional
Las posibles preguntas orientadoras son:
¿La nueva adquisición o conversión supone un riesgo para las personas, las máquinas o el medio ambiente?
¿El proceso se está volviendo más seguro o menos seguro?
¿El proceso se realiza en un entorno ATEX?
Conclusión
Sobre la base de estas preguntas orientadoras, se pueden crear requisitos detallados del usuario, que facilitan significativamente la creación de documentos adicionales como el plan de calidad del software, la especificación funcional, el plan de pruebas y el informe para el PLC.