Modelo Procedimental para la Especificación de Requisitos Funcionales en la Construcción de Software

Headnote

Resumen: El presente modelo muestra un esquema secuencial de actividades; para la obtención de requisitos funcionales; en el proceso previo a la construcción del software, lejos únicamente de la noción y clasificación de los requisitos efectuados por diversos autores, este modelo muestra como progresivamente se construyen los instrumentos que permitirán capturar la información de origen, para esta tratarla progresivamente hasta llegar a una especificación de requisitos funcionales, todo esto parte de la identificación del contexto de desarrollo, definición de stakeholders para con ello lograr la especificación de requisitos, esto último se efectúa en tres pasos; que son la educción, elicitación y por último la especificación de requisitos.

Palabras-clave: Especificación de requisitos, requisitos funcionales, modelo procedimental.

Abstract: This model shows a sequential scheme of activities; for obtaining functional requirements; In the process prior to the construction of the software, far only from the notion and classification of the requirements made by various authors, this model shows how the instruments that will capture the source information are progressively constructed, so that it can be treated progressively until reaching a specification of functional requirements, all this starts from the identification of the development context, definition of stakeholders to achieve the requirements specification, the latter is done in three steps; which are education, elicitation and finally the requirements specification.

Keywords: Specification of requirements, functional requirements, procedural model.

1. Introducción

La clasificación de los requisitos ha sido una materia de estudio bastante abordada por los autores quienes han efectuado diferentes clasificaciones, como se muestra en la figura 1(Gómez M. 2011, Drake J. 2008, Pow S.; Portillo J. 2002, IEEE-STD-830 1998-R2009, Hull E., Jackson, Ken & Dick 2005, Borja, Carlos, Cuji & Valeria 2013), los requerimientos han sido clasificados de diferente manera, cada una de ellas muestra un particular punto de vista de los autores según corresponda. Sin embargo no se tiene a disposición un modelo procedimental para el desarrollo de actividades claramente identificadas; que conduzcan inequívocamente a la determinación de los requisitos funcionales del software

Luego de una indagación sobre otras propuestas de cómo abordar el tema materia de este artículo, se han encontrado las propuestas de (Mora 2007), quien propone una composición de los requisitos en general, sin especificar una secuencia lógica de cómo conseguir los requisitos, (Monferrer 2001), presenta un acopio del estándar de IEEE, sin embargo este trabajo solamente narra los aspectos a considerar en los requisitos de software, (Cuba, 2018) hace una propuesta donde especifica los requisitos en una lista secuenciada de actividades que debería desarrollar el software a desarrollar, (De La Cruz, Castro 2015) plantean una metodología para para la adquisición de requerimientos, en su propuesta se aprecia el uso de esquemas manuales y dibujo de protocolos de usuario, además de un conjunto de pasos para el establecimiento de requisitos, sin embargo su propuesta no formaliza la documentación de una forma replicable.

2. Objeto del modelo

La IEEE-STD-830-1998, define simplemente una clasificación de requisitos en dos grandes grupos; como son los funcionales y los no funcionales, cuyo par es asumido por la Agencia Espacial Europea, quienes los dividen en requisitos de usuario y de software, haciendo la par al planteamiento de la IEEE. En el presente modelo se asume el modelo procedimental que permitirá tener una especificación de requisitos funcionales o de usuario, los que en una secuencia de instrumentos formalizados, se presentan unos formatos; tanto de trabajo como de reporte o informe sobre labores realizadas, que convergen en una ficha final que permite especificar los requisitos de un software a desarrollar

3. Estructura general de la composición del modelo

En la figura 2 se muestra la constitución básica del modelo donde se aprecia que la especificación de requisitos funcionales pasa por 3 etapas (educción, elicitación y especificación)

3.1.Definición del contexto de uso y aplicación del software

En esta etapa del modelo, se deben precisar tres aspectos básicos, los mismos que deben estar claramente entendidos:

* ¿Para qué se va a usar el software?

* ¿En qué escenarios se va a usar el software?

* ¿Quiénes van a usar el software?

El entendimiento de cuál es el propósito por el cual se va a construir un software es algo que da a entender el norte que nos ubica en el contexto del uso en sí, y justifica de alguna forma los conceptos previos que podremos generar para abordar el problema y encaminar os esfuerzos hacia las alternativas de solución.

La definición de los escenarios de despliegue, permite identificar los lugares físicos donde los usuarios deberán tener acceso a las diversas funcionalidades y sus utilidades que tenga el software, para ello se debe presentar una simple tabla como se muestra en la tabla 1:

Por último se definen los estereotipos de los usuarios quienes harán uso del software, normalmente esto está asociado a los cargos que ocupan dichos usuarios, para ello se elabora la tabla 2 que a continuación se muestra:

Cabe mencionar que los tres aspectos mencionados y descritos anteriormente es un proceso iterativo y progresivo; el mismo ha de madurar, y cuando esto esté claramente entendido se debe formalizar todo ello en un acta de definición de objetivos, el mismo que se muestra en la figura 3

Esta acta presenta el resumen de la negociación entre el representante de la institución usuaria y el gestor del proyecto.

3.2.Definición de los stakeholders

Los grupos interesados se clasifican en dos grandes grupos, los mismos que deben identificarse claramente y deben registrarse en la tabla 3, como se muestra a continuación:

Cabe destacar que quienes son stakeholders claramente identificados de la parte usuaria son el directivo responsable de la institución y un responsable delegado quien será el nexo oficial de la parte usuaria para ver aspectos operativos del proyecto, es sumamente útil la relación de usuarios que se presentó en la tabla 2, que permitirá completar el grupo de stakeholders de la parte usuaria.

Con fines operativos se debe elaborar la relación que se presenta en la figura 4, donde se debe poner al personal de la institución usuaria que participara de las entrevistas, proporción de información u otros aspectos operativos que se estime por conveniente hasta la puesta a producción del producto software elaborado.

De manera análoga, son stakeholders claramente identificados de la parte del equipo del proyecto, el Jefe del proyecto, quien representara al equipo de desarrollo y será el facilitador de recursos técnicos y tecnológicos; en coordinación con los stakeholder de la parte usuaria u otros agentes externos que estime por conveniente de acuerdo a la necesidad.

3.3.Requisitos Funcionales del software

Esta etapa se desarrolla en una secuencia iterativa de tres pasos, los cuales se desarrollaran secuencialmente y de existir algún incomprendido, se deberá regresar tantos pasos atrás como se estime por conveniente, lo cual se muestra en la figura 5:

A Educción

De primera intención; se debe tener en cuenta que los usuarios finales a quienes se entrevistara, no son regularmente personas instruidas en temas asociados a la construcción del software, sin embargo ellos deberán tener la labor de explicar de manera pormenorizada al equipo técnico, los detalles de las necesidades del software a desarrollar. Para ello se debe efectuar tabla 4, donde se contrastan los usuarios y los escenarios en donde intervienen.

Posteriormente se debe elaborar una matriz de doble entrada, como se muestra en la tabla 5, donde se deben contrastar a los objetivos definidos y enumerados en el acta de definición de objetivos que se muestra en la figura 3, con los escenarios definidos en la tabla 1, para con ello elaborar las respectivas entrevistas con los usuarios elegidos que se definieron en la figura 4, para lo cual se debe cotejar con la tabla 4, esto asegurara que todos los objetivos serán abordados, y los usuarios comprometidos en los mismos; aportaran conocimiento respecto a los pormenores de los procesos en los que intervienen.

Se debe recomendar que para elaborar las entrevistas, es necesario desarrollar un cuestionario por cada tipo de usuario, en el orden de los objetivos y escenario en los que se desplegara el software, luego se deberá efectuar una lista de chequeo, como se muestra en la figura 6, donde se deben fijar a los usuarios elegidos en la figura 4;y el calendario en el que se les programara la entrevista, cabe destacar que esta lista de cotejos puede sufrir modificaciones por factores técnicos, operativos o de subsiguiente entrevista para ampliar detalles o corregir incomprendidos.

Cabe aclarar que en la columna "ficha", se debe indicar que ficha de entrevista se ha de aplicar a los respectivos usuarios, puede darse en caso en el que a un usuario se le pueda aplicar más de una ficha de entrevista.

Una vez se completan las entrevistas, estas se deben resumir por aspectos o características anotadas y clasificadas, para ser resumidas en un acta de entrevista, como se ve en la figura 7, que debe ser validada por el usuario entrevistado, puede darse el caso que cuando se han completado las entrevistas, y en los pasos siguientes surjan incomprendidos, lo que motive nuevas entrevistas; por lo cual se debe controlar la versionalidad de las actas de entrevistas.

B Elicitación

Al concluir la etapa de Educción, se debe efectuar un rastreo por escenario de todas las características destacadas en las actas de entrevista, las mismas que se deben agrupar por funcionalidad, esto a futuro constituirá una aproximación a la modularidad; que en la etapa de diseño del software se deberá abordad con mayor amplitud, es una labor de análisis y reconocimiento, en el cual participa el equipo técnico en su conjunto, para que de esta manera se deban aclarar toda duda, de existir algún incomprendido, se deberá volver a efectuar tantas entrevistas como sean necesarias, una vez el panorama de cada escenario este completamente claro, se debe elaborar la ficha de caracterización de escenarios, como se muestra en la figura 8.

Cabe indicar que en el detalle se puede sub-agrupar el mismo por aspectos o temas asociados, esto con el fin de poder analizar problemas o necesidades de usuario, y poder determinar si el grado de satisfacción estimado pueda ser mínimamente aceptable en el peor de los casos, lo recomendable es entrar en una fase de negociación de características con el "responsable delegado" o con el "directivo", esto puede ocasionar que el alcance del proyecto se incremente en extensión, amplitud y/o profundidad, lo cual impactará necesariamente en los recursos asignados, y entre ellos los costos.

C Especificación

Al terminar la caracterización de los escenarios de despliegue de funcionalidades, se podrá identificar claramente los requisitos funcionales, estos deberán tener un nombre que los identifique, y para ello se deberá elaborar un catálogo de requisitos, como se muestra en la figura 9:

Se debe precisar que los requisitos al ser conjugados en el compendio de todas las fichas de caracterización de escenarios, estas se puedan mejorar o precisar de alguna manera, por ello la ficha se puede actualizar progresivamente y los requisitos funcionales sufran un incremento en su versionalidad.

Posteriormente se debe efectuar una especificación en detalle de cada requisito funcional, esto se debe formalizar en una ficha de especificación de requisitos, como se muestra en la figura 10.

4.Resultados del Modelo

Este modelo fue puesto a prueba en la Escuela Profesional de Ingeniería de Sistemas, de la Universidad Nacional San Agustín de Arequipa, con una muestra dirigida conformada por tres (03) cursos de su plan de estudios, los cursos son llevados en forma consecutiva, esto significa, que los conocimientos adquiridos en el primer curso se emplean en el siguiente, y que el grado de dificultad de sus proyectos de desarrollo; son cada vez más complejos y con particularidades específicas. El detalle de los cursos se muestra en la siguiente tabla;

Se definió una escala de calificación vigesimal (0 a 20), que se muestra en la Tabla 7

Posteriormente se aplicó la evaluación a los dieciocho grupos cuando esos desarrollaron las asignaturas en sus respectivos semestres académicos, con los cuales obtuvo los resultados que se presentan en la tabla 8.

Un detalle que se debe resaltar es que los puntajes obtenidos en la tabla 8, corresponden a la evaluación continua efectuada a los grupos de estudio, en sus respectivos cursos, donde como parte de los trabajos a realizar; es necesario contar con una especificación de requisitos, y fue en ese escenario que se tomaron las respectivas lecturas.

Considerando que la evaluación se efectuó en una escala vigesimal (de o a 20), y la escala de valoración presentada en la tabla 7, a los grupos de estudiantes que se presentan en la tabla 8, se puede observar claramente que los estudiantes que no tenían experiencia en el desarrollo de un proyecto de software, estos pudieron hacerlo en la fase de análisis del sistema, y de manera puntual en las actividades de especificación de requisitos, de una forma que se valoró como "Muy Bueno". Todo ello permite demostrar que el contar con método procedimental para la especificación de requisitos, no solo guía y ordena las actividades a desarrollar para obtener una correcta obtención de la especificación de requisitos, sino también que garantiza un entrenamiento adecuado al equipo de desarrollo para la comprensión y entendimiento del problema y lograr entender y representar lo que el cliente (usuario) quiere del sistema para suplir sus necesidades.

Otro aspecto a resaltar es que el rango entre el valor máximo y mínimo son tan solo de tres puntos, lo que invita a deducir que los progresos y resultados son muy uniformes, además que ningún grupo perdió el horizonte de trabajo y completaron sus actividades con una evaluación final de entre "Bueno" y "Muy Bueno".

5.Conclusiones

El modelo procedimental gracias a la secuencia de actividades, apoyados por el conjunto de formatos definidos, permitió que los diversos grupos pudieran guiarse de forma progresiva para lograr una especificación de los requisitos funcionales.

Los formatos presentados en el artículo ayudaron a capturar la información original, organizar la misma para extraer las características comunes y particulares, y de una forma sistematizada, establecer los requisitos que permitieron efectuar acciones subsiguientes. No se restringió o direcciono a los estudiantes a emplear software específico que permitiera controlar la documentación generada, lo cual ocasiono que los estudiantes implementaran los documentos siguiendo el modelo; sin que ello signifique aprender algún software, y de esta manera se enfocaran en el propósito y no instrumentos utilitarios.

Luego de evaluar otros trabajos similares o que buscan la obtención de requisitos funcionales, podemos decir que la mayoría no presentan un modelo que permita obtener los requisitos funcionales de una forma secuenciada, además que los instrumentos o formas de documentar el proceso no están claras a diferencia de la propuesta del presente artículo.

Como un trabajo a futuro, se viene desarrollando un software para llevar a cabo la secuencia de forma modular, de tal manera que no se ciña exclusivamente a una metodología de desarrollo, sino que esta cumpla con todos los pasos del modelo para la obtención de los requisitos funcionales.

References

Referencias

Alfaro Salas, Maricruz (2014), Tesis porfesional de Ingeniero de Sistemas: "Captura de requerimien-tos funcionales de software a partir del modelo de negocio rediseñado de gestión de relaciones con el cliente para mejorar el servicio de atención al cliente en la Caja Trujillo", Facultad de Ingeniería de Sistemas, Universidad Nacional del Centro del Peru, Huancayo, Perú

Borja Buestán, Carlos Daniel; Cuji Torres, Valeria Al-exandra (2013), Tesis de Ingeniero de Sistemas: "Metodología para la especificación de requeri-mientos de software basado en el estándar IEEE 830-1998", Universidad Politécnica Salesiana Sede Cuenca, Ecuador

Callejas-Cuervo, Mauro ; Alarcón-Aldana, Andrea Catherine; Álvarez-Carreño, Ana María (2017), "Modelos de calidad del software, un estado del arte", En: Entramado. Enero - Junio, 2017. vol. 13, no. 1, p. 236-250, disponible en: http:// dx.doi.org/10.18041/entramado.2017v13n1.25125

Cuba Cumpa, Romina (2018), Tesis de Maestria: "Análisis de los Procesos y Diseño de los Requerimientos Funcionales para el Desarrollo de un Sistema de Información para la Gestión de Reclamos en las Plataformas de Atención al Usuario en Salud", Universidad Peruana Cayetano Heredia, Lima, Perú.

De La Cruz Londoño, Cristian Andres; Castro Guevara, Gustavo Andres, (2015), Tesis de Maestria: "Metodología para la adquisición y gestión de requerimientos en el desarrollo de software para pequeñas y medianas empresas (pymes) del departamento de risaralda.", Universidad Tecnológica de Pereira, Colombia

Del Valle Rojo, Silvana (2013), Tesis de maestría en Ingeniería de Software "Elicitación y Especificación de Requerimientos No Funcionales En Apli-caciones Web", Facultad de Informática - Univer-sidad Nacional de La Plata, Argentina

Drake, José M. (2008), "Análisis de requisitos y es-pecificación de una aplicación", Santander.

Durán Toro, Amador; Bernárdez Jiménez, Beatriz (2001), "Metodología para el Análisis de Requisi-tos de Sistemas Software", Escuela Técnica Supe-rior de Ingeniería Informática, Universidad de Se-villa, España

Gil, Gustavo Daniel (2002), Tesis: "Herramienta Para Implementar LEL Y Escenarios (TILS)", Maestría en Ingeniería de Software, Facultad de Informática, Universidad Nacional de La Plata, Argentina

Gómez Fuentes, María del Carmen (2011), "Notas Del Curso: Análisis De Requerimientos", Departa-mento de Matemáticas Aplicadas y Sistema, División de Ciencias Naturales e Ingeniería, Universi-dad Autónoma Metropolitana, Unidad Cuajimalpa, México

Hull, Elizabeth; Jackson, Ken; Dick, Jeremy (2005), "Requirements Engineering", Second Edition, Springer Science + Business Media

IEEE-STD-830 (1998), "Recommended Practice for Software Requirements Specifications", IEEE Computer Society, Disponible en: http://www.cse.msu. edu/~cse870/IEEEXplore-SRS-template.pdf , ultimo acceso 2018-05-08

Monferrer Agut, Raúl (2001), "Especificación de Requisitos Software según el estándar de IEEE 830", Universitat Jaume, ultimo acceso: 05/11/2019, disponible en: http:// zeus.inf.ucv.cl/~bcrawford/AULA ICI 3242/ERS IEEE830.pdf

Mora, Tania; Moreno, Dorance; Romo, Luis (2007), "Especificación de requisitos de software", Universidad del Valle, ultimo acceso: 05/11/2019, disponible en: http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:pis:ejemplo_de_ especificacion_de_requerimientos_-_para_sesion_9.pdf

Moreno Martín, Miguel Ángel (2015), "La Ingeniería del Software", Universidad de Sevilla, España

Pow Sang Portillo, Jose Antonio (2002), "La Especificación de Requisitos con Casos de Uso: Buenas y Malas Prácticas", Pontificia Universidad Católica del Perú, Perú

Pressman, Roger S. (2010), "Ingeniería del Software: Un enfoque práctico", Séptima edición, México DF, Editorial McGraw Hill.

Ramírez Fernández, Adelaida (2012), "Clasificaciones de tipos de requisitos para la mejora del pro-ceso de desarrollo del sofware",Universidad Car-los III de Madrid. Departamento de Informática, Recuperado el 6 de Junio del 2017 en: https://earchivo.uc3m.es/handle/10016/14998

Rodriguez Tello, Eduardo (2012), "RequirementsEn-gineering", Cinvestav, Tamaulipas, Mexico

Romero Galindo, Raúl Miguel (2012), Tesis: "Análisis, diseño e implementación de un sistema de información aplicado a la gestión educativa en centros de educación especial", Ingeniería In-formática, Pontificia Universidad Católica del Perú

Sarabia Dorlemont, Karinthia Lilianit (2011), tesis: "Ingeniería de requisitos para proceso de ejecución de estrategias de mercadeo (impulso y fachadas), coordinación de desarrollo en el punto de venta Cervecería Polar C.A. territorio comer-cial oriente sur", Ingeniero de Sistemas, Univer-sidad De Oriente, Núcleo de Monagas, Maturín, Mongas, Venezuela

Silva Vázquez, D. Andres (2000), Tesis Doctoral en Informática: "Método de Ingeniería de Requisitos Para Manejo de Discrepancias", Universidad Poli-técnica de Madrid, España.

Sommerville Ian, (2005), "Ingeniería del Software", Séptima edición, México DF, Editorial Pearson