Un software ERP se robustece en la medida que se incorporan reales soluciones a situaciones de día a día en las operaciones de cada negocio. Estas soluciones se ofrecen por la adición, eliminación o modificación de funcionalidades en base a lo que conocemos en la industria como nuevos requerimientos.
Ciertos requerimientos se presentan por el usuario de forma muy vaga o, por el contrario, muy específica. Entonces, por ejemplo, en lugar de decir: “La aplicación debe ser lo suficientemente fácil para que la use el público en general”, un requerimiento específico debe decir cosas como “Los usuarios deben completar la tarea en cinco minutos y cancelar la tarea menos del 5% del tiempo”. Desafortunadamente, este tipo de requerimientos basados en métricas son demasiado costosos y consumen mucho tiempo. Por lo tanto, este no es el mundo real cuando hablamos de requerimientos.
Es interesante cómo Britton (2016) señaló un nuevo enfoque relacionado con “diseñar una solución de negocio” en lugar de “recolectar requerimientos”. Britton (2016) afirmó que en un enfoque de diseño se dedica poco tiempo a pedirle a los usuarios que llenen una hoja de papel en blanco y mucho tiempo a presentarles una posible solución y escuchar sus comentarios. Si se pregunta por sus necesidades, tendrán dificultades para enumerarlas todas. Sin embargo, al presentarles una o dos soluciones posibles, identificarán rápidamente necesidades, errores y problemas adicionales. Además, las diferencias de opinión entre las partes interesadas se hacen evidentes rápidamente cuando todos revisan el mismo diseño. El diseño proporciona un marco a partir del cual puede intentar encontrar un compromiso.
Chemuturi (2013) estableció la clasificación de un requerimiento bajo tres consideraciones que se enumeran a continuación.
- Funcionalidad: estos son los requerimientos que cumplen con el conjunto de procesos comerciales seleccionados y entregan los resultados a los usuarios finales.
- Construcción del producto: estos son los requerimientos que son necesarios para construir el producto de manera eficiente, así como para mantenerlo más adelante.
- Consideraciones sobre la fuente: los requisitos para el desarrollo de software provienen de diferentes fuentes. Esta clasificación se basa en las fuentes expertas que proporcionan los requerimientos.
S i el proceso de recopilación de requerimientos cae en la consideración de los clientes, el producto final podría perder alguna guía importante relacionada con la arquitectura, la mantenibilidad, las restricciones de desarrollo y las restricciones sobre los servicios o funciones que ofrece el sistema. Sin embargo, si los desarrolladores recopilan los requerimientos exclusivamente, podría haber una gran posibilidad de perder algunas funcionalidades del sistema, una entrada particular o un comportamiento esperado (Sommerville, 2016). Por lo que en este proceso, es mandatorio el involucramiento de las partes para asegurar un resultado exitoso.
En JoS & Asociados contamos con la experiencia acumulada con las ya más de 150 implementaciones exitosas del software SJ ERP. En la madurez de nuestro producto SJ ERP, incorporamos nuevas soluciones basadas en un enfoque de negocio que facilitan la gestión de las empresas brindando orden y reduciendo los potenciales errores. Permite que te acompañemos como aliado tecnológico experto en tu solución de software y juntos logremos los objetivos propuestos.
Referencias
Britton, C. (2016). Designing the requirements: Building applications that the user wants and needs. Old Tappan, New Jersey: Addison-Wesley.
Chemuturi, M. (2013). Requirements engineering and management for software development projects. New York, NY: Springer. doi:10.1007/978-1-4614-5377-2
Sommerville, I. (2016). Software engineering. Reading, Pearson.
