SciELO - Scientific Electronic Library Online

 
vol.13 número2Almacén de Datos para la gestión de estudios de Peligro, Vulnerabilidad y Riesgo en CubaComponente para el cálculo de la relevancia en el buscador Orión índice de autoresíndice de assuntospesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

  • Não possue artigos citadosCitado por SciELO

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


Revista Cubana de Ciencias Informáticas

versão On-line ISSN 2227-1899

Rev cuba cienc informat vol.13 no.2 La Habana abr.-jun. 2019

 

Artículo original

Los requisitos no funcionales de software. Una estrategia para su desarrollo en el Centro de Informática Médica

The non-functional software requirements. A strategy for its development in the Medical Informatics Center

Yenisel Molina Hernández1  * 

Ailec Granda Dihigo2 

Alionuska Velázquez Cintra3 

1 Centro de Informática Médica CESIM. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370.

2 Centro de Innovación y Calidad en la Educación. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370.

3 Dirección de Calidad de Software, Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370.

RESUMEN

Los Requisitos No Funcionales (RNF) de software forman una parte significativa de la especificación de requisitos y en algunos casos estos son críticos para el éxito del producto. Con frecuencia estos requisitos son ignorados o subestimados debido a que para muchos proyectos estos implican una cantidad considerable de trabajo y esfuerzo; resultan ser más complejos y requieren un mayor nivel de conocimiento. En el desarrollo de software para la salud estos problemas se incrementan dada la complejidad del mismo. El presente artículo describe una estrategia de desarrollo de requisitos no funcionales en aplicaciones para la salud, basada en un conjunto de normas y modelos internacionales; la cual propone acciones, métodos y técnicas cuya finalidad es lograr especificaciones de RNF de mayor calidad de manera que se incremente la calidad de estos productos software.

Palabras clave: calidad; estrategia; requisitos no funcionales; software

ABSTRACT

The Non-Functional Requirements (RNF) of software form a significant part of the requirements specification and in some cases these are critical to the success of the product. Often these requirements are ignored or underestimated because for many projects these involve a considerable amount of work and effort; they turn out to be more complex and require a higher level of knowledge. In the development of software for health these problems are increased given the complexity of it. This article describes a strategy for developing non-functional requirements in applications for health, based on a set of international standards and models; which proposes actions, methods and techniques whose purpose is to achieve higher quality RNF specifications in order to increase the quality of these software products.

Keywords: non-functional requirements; quality; strategy; software

INTRODUCCIÓN

La comprensión de los requisitos y la importancia de su correcta y precisa especificación se incrementa cada día dado la complejidad que adquieren los sistemas software al tener que responder a exigencias que van más a allá de las funcionalidades tales como interoperabilidad, seguridad, eficiencia, confiabilidad entre otras (Doerr et al. 2005). El éxito o fallo de un software depende casi siempre de cómo se hayan capturado, entendido y usado los requisitos como base para el desarrollo (Hinojosa et al. 2015).

La ingeniería de requisitos constituye la piedra angular en el desarrollo de software (Sommerville 2011), ya que se enfoca en definir lo que se debe producir para cumplir con las necesidades y expectativas del cliente. El modelo CMMI para Desarrollo (CMMI-DEV, del inglés Capability Maturity Model Integration for Development) en su más reciente versión CMMI Development V2.0 (2018), define un Área de Prácticas: Desarrollo de requisitos y administración (RDM, por sus siglas en ingles), siendo las actividades más comunes que involucra el desarrollo de requisitos: Eicitación u Obtención, Análisis, Especificación, Verificación y Validación.

Un requisito, o también denominado requerimiento, es definido por el glosario de la IEEE como una condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto. (Sommerville, 2011) distingue dos niveles de requisitos: Requisitos de usuario y Requisitos del sistema/software, estos últimos son clasificados en dos grandes tipos, como Requisitos Funcionales (RF) y Requisitos No Funcionales (RNF).

Existen diversos criterios y definiciones de RNF, en la bibliografía consultada se utilizan indistintamente los términos: restricciones, propiedades, características, atributos y cualidades que el producto o sistema debe tener. Las autoras de la presenten investigación asumen la definición dada por Cysneiros y Yu (2004) en la que se plantea que los RNF son “requerimientos de calidad, que representan restricciones o las cualidades que el sistema debe tener tales como: precisión, usabilidad, seguridad, rendimiento, confiabilidad, performance entre otras. Estos requisitos poseen una naturaleza abstracta e intangible en comparación con los RF y esto hace que sean más difíciles de especificar o documentar formalmente (Hadad, Doorn y Kaplan 2009). No alteran la funcionalidad del sistema, pero pueden añadir nuevos RF. Sommerville (2011) clasifica los RNF en: Requisitos de producto (por ejemplo, usabilidad, seguridad, eficiencia) Requisitos organizacionales y Requisitos externos.

Las actividades enfocadas en los RNF involucran especialistas con diferentes competencias, perfiles y visiones acerca del sistema que debe construirse. De no especificarse correctamente, es decir si la especificación de estos requisitos no es completa y no se define en términos cuantificables o medibles resulta difícil establecer criterios para la ejecución de pruebas que permitan verificar su cumplimiento una vez que el software es desarrollado.

En Cuba, a partir de la voluntad política del país por acercar cada vez más las nuevas tecnologías a la población, refrendado en los Lineamientos de la Política Económica y Social del Partido y la Revolución se definen entre las políticas de informatización potenciar el uso masivo de las Nuevas Tecnologías de la Información y las Comunicaciones (NTIC) a favor del desarrollo de la economía nacional, la sociedad y el servicio al ciudadano. La Universidad de las Ciencias Informáticas (UCI), con el objetivo de impulsar el desarrollo de software en el país, ha definido como estrategia la creación de Centros de desarrollo de software dedicados fundamentalmente a fortalecer la labor productiva de la misma entre los cuales se encuentra el Centro de Informática Médica (CESIM); dedicado al desarrollo de productos, sistemas, servicios y soluciones integrales para la salud, cuya misión es la de convertirse en un Centro de excelencia en el desarrollo de estos productos con creatividad e innovación pero además lograr la calidad requerida para alcanzar un prestigio en el mercado internacional.

De acuerdo con la Organización Panamericana de la Salud (OPS) la implementación de sistemas y tecnología de información para atención de salud se ha vuelto crucial para prestar una asistencia de buena calidad. Según IMDRF SaMD Working Group (2015) “el objetivo es diseñar un sistema que: a) mantenga la seguridad del paciente y la confidencialidad, disponibilidad e integridad de las funciones y datos críticos; b) es resistente contra amenazas intencionales e involuntarias; y c) es tolerante a fallas y recuperable a un estado seguro en presencia de un ataque”.

El desarrollo para la salud es complejo. Estos sistemas además de lograr integrar las complejas operaciones clínicas requieren un flujo continuo de información, incluso entre diferentes sistemas, garantizando la disponibilidad y seguridad de la misma, así como el acceso inmediato a esta de modo que contribuya a mejorar la eficiencia de estos procesos, facilitando el trabajo cotidiano y logrando la satisfacción de los usuarios. Los RNF son especialmente importantes en este tipo de sistemas cuyos fallos causan un daño significativo que puede llegar a repercutir en la salud de las personas.

Con frecuencia estos requisitos son ignorados o subestimados, para muchos proyectos estos implican una cantidad considerable de trabajo y esfuerzos. Generalmente se confiere mayor atención a la definición y uso de métodos, técnicas y notaciones para definir RF y no se especifican detalles acerca de cómo tratar los RNF, los cuales resultan ser más complejos y requieren un mayor nivel de conocimiento, así como métodos específicos. Este ambiente motiva la búsqueda de estrategias para garantizar que estos requisitos sean descubiertos con precisión y que además sean expresados de una forma correcta, sin ambigüedad y especificados cuantitativamente, siempre que sea posible, de manera que se puedan establecer criterios para la ejecución de pruebas que permitan verificar su cumplimiento una vez el software es desarrollado y de esta manera garantizar la calidad del producto final.

El presente artículo describe una estrategia de desarrollo de RNF de software en aplicaciones para la salud, la cual permite guiar estas actividades al proponer acciones, métodos y técnicas cuya finalidad es lograr especificaciones de RNF de mayor calidad de manera que se incremente la calidad de los sistemas software desarrollados en el CESIM.

MATERIALES Y MÉTODOS

Para el desarrollo de la estrategia se tomaron como base los requisitos definidos por la norma NC ISO/IEC 25030: 2017 SQuaRE - Requisitos de calidad y el modelo de calidad del producto definido en la norma NC ISO/IEC 25010 SQuaRE - Modelos de la Calidad de software. Además, se tiene en cuenta la norma ISO/IEC 25023 - Medidas de calidad del producto para la identificación de las métricas a utilizar durante la especificación de estos requisitos, así como las buenas prácticas para el desarrollo de requisitos definidas en el modelo de procesos CMMI para Desarrollo y los procesos definidos en la UCI con vistas a certificar el nivel 3 de este modelo.

También se consideran y se proponen emplear algunas técnicas que permitan la gestión del conocimiento como son: la realización de auditorías del conocimiento que permita identificar el conocimiento existente o ausente (Guitián, Pérez, & Porra, 2015), la utilización de mapas de conocimiento como un instrumento de visualización del conocimiento existente (García & Dante, 2014) y el uso de listas de chequeo como una técnica de asistencia para la elicitación de estos requisitos que permite transferir el conocimiento de expertos a una gran cantidad de miembros de la organización (Simbaña Saransig & Simbaña Quinsasamín, 2015) (Silva et al., 2016).

Para el desarrollo de la estrategia, se toman en cuenta los aspectos definidos en (Ramírez y Lima 2011): Diagnóstico, Planteamiento del objetivo general, Planeación estratégica, Instrumentación y Evaluación. Con el objetivo de caracterizar el estado actual del proceso de desarrollo de los RNF en el CESIM se realizó un diagnóstico, a partir del cual se determinaron las potencialidades que proporcionarían a la institución las condiciones para llegar a un nivel superior y las deficiencias o aspectos negativos que caracterizan la misma, a partir de lo cual se identifica el objetivo general de la estrategia propuesta, se realiza la planeación estratégica y posteriormente se describe la instrumentación donde se explica cómo se aplicará, bajo qué condiciones, durante qué tiempo y los responsables; por último se describe la forma de evaluación donde se realiza una valoración de la aproximación lograda al estado deseado.

RESULTADOS Y DISCUSIÓN

La estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud tiene como objetivo: contribuir a elevar la calidad de la especificación de requisitos de software de las aplicaciones para la salud desarrolladas en el CESIM a partir del desarrollo de los requisitos no funcionales de estos productos. La propuesta se concibe teniendo en cuenta las condiciones actuales identificadas mediante un diagnóstico realizado, las recomendaciones y sugerencias realizadas por los expertos durante el proceso de validación.

Planeación estratégica

Como parte de la planeación estratégica, se definen objetivos a corto y mediano plazos que permiten la transformación del objeto desde su estado real hasta el estado deseado y la planificación por etapas de las acciones, métodos y técnicas que corresponden a estos objetivos. Se definen 4 etapas relacionadas con objetivos definidos y planificación de acciones de orientación, ejecución y control. Estas se complementan entre sí, de manera similar a un proceso, por lo no pueden ser concebidas de forma independiente una de la otra tal como se representa en la Figura 1.

Fig. 1 Representación gráfica de la estrategia de desarrollo de requisitos no funcionales de software en aplicaciones para la salud. Fuente: elaboración propia 

Preparación del entorno: esta etapa tiene como principal objetivo preparar los elementos necesarios que permitan la ejecución exitosa del resto de las etapas definidas. Para lograr este objetivo se ejecutan las siguientes acciones:

Se identifican los interesados relevantes, es decir todos los que de una forma u otra esperan algo o intervienen en el proceso de desarrollo y deben involucrarse en las actividades de desarrollo de RNF (arquitecto, analista, desarrollador, probador, jefe de proyecto, clientes). Posteriormente se identifican las fuentes de conocimientos, para lo cual se propone la realización de una auditoria del conocimiento cuyos resultados deberán ser representados en un mapa de conocimiento de esta manera es posible identificar, las competencias y conocimiento existente, así como quien puede transferir o mejorar su nivel de apropiación de un conocimiento determinado, de esta manera se podrán definir acciones que refuercen el conocimiento disponible.

Se crea el Grupo de ingeniería de RNF (GiRNF), el cual será el encargado de definir los RNF del proyecto en cuestión y se constituye teniendo en cuenta los interesados relevantes y haciendo uso del mapa de conocimientos elaborado; debe estar constituido por especialistas con diferentes competencias, perfiles y visiones acerca del sistema que debe construirse por lo que se propone formen parte del mismo los roles: analista, arquitecto, desarrollador, probador, especialista en ciberseguridad y jefe de proyecto. Las principales competencias requeridas son: capacidad de abstracción, creatividad, liderazgo, comunicación oral y escrita, interpretación de normativas, capacidades lógicas, analíticas y de investigación, capacidad de trabajo en equipo. Conocimientos en: diseño de base de datos, técnicas de programación, arquitectura de software, ingeniería de software; metodología, estándares y normas a aplicar en la construcción de software, prácticas de testing, criptografía, análisis y detección de amenazas de seguridad y desarrollo de técnicas de prevención.

Se realizan actividades de capacitación, en las cuales se debe abarcar temas relacionados con las acciones a ejecutar como parte de la estrategia y el modelo de calidad definido en la ISO 25010, estas actividades deben ser recogidas en un plan de capacitación. A continuación, se obtiene información sobre el dominio del problema, se identifican fuentes de información que pueden ser consultadas o utilizadas como soporte a la identificación de los RNF como pueden ser: sistemas existentes, estándares, regulaciones o normas, entre otras.

Se revisa la lista de chequeo propuesta para la asistencia durante la identificación de los RNF. De ser necesario se incluyen nuevos aspectos, lo cual contribuirá a enriquecer los elementos contenidos en la misma. Como parte de la investigación se definió una lista de chequeo, la cual se estructura atendiendo al modelo de calidad de producto definido en la NC ISO/IEC 25010, teniendo en cuenta todas las características y subcaracterísticas definidas en el mismo. A estas características de asocia un conjunto de preguntas/afirmaciones determinadas a partir de las fuentes de información identificadas entre las que se citan (López, Barreras y Orozco 2014), (Henarejos et al. 2014), (IMDRF SaMD Working Group 2015), (Organización Panamericana de la Salud 2016), (CALISOFT 2017). Cada uno de estos elementos conduce a la identificación del RNF correspondiente. En la Tabla 1 se muestra un ejemplo correspondiente a la característica de calidad: eficiencia.

Tabla 1 Lista de Chequeo para la asistencia durante la elicitación. Eficiencia. Fuente: elaboración propia 

Identificación y análisis de RNF: esta etapa tiene como objetivo fundamental identificar los requisitos no funcionales aplicando métodos y técnicas que facilitan estas actividades. Para lo cual se ejecutan las siguientes acciones: en primer lugar, se deberán identificar requisitos de calidad de los clientes para lo cual se propone realizar entrevistas a los proveedores de requisitos, a partir de una guía de preguntas preconcebidas que indaguen en los requisitos de calidad, cuyos resultados deben quedar reflejados en el producto de trabajo Necesidades del cliente. Se deberá establecer un peso o importancia (Alto, Medio, Bajo, No Aplica) relativa de las características de la calidad, teniendo en cuenta las características del sistema a desarrollar, propósito, y uso previsto.

Se identifican los RNF del producto para lo cual se propone la realización de talleres (Durand 2017), donde participan los expertos designados que forman el GiRNF. En el mismo se analizan las necesidades del cliente identificadas y haciendo uso de la lista de chequeo elaborada para la asistencia durante la identificación de RNF se podrá garantizar la cobertura de todos los aspectos de calidad y se elabora el listado preliminar de RNF. Se deben identificar conflictos entre requisitos para lo cual se propone la utilización de matrices de interacción que permitirán el análisis e identificación de las relaciones que causan conflictos. Se define la prioridad de los RNF, basado en la importancia y urgencia (Wiegers y Beatty 2013). Se evalúa el impacto de los requisitos de los atributos de calidad significativos para la arquitectura y en los costes. Además, se realiza una evaluación de riesgos sobre estos requisitos.

Especificación de RNF: esta etapa tiene como propósito documentar los RNF identificados, para lo cual se ejecutan las siguientes acciones: se describen los RNF identificados especificando la característica de calidad y teniendo en cuenta un conjunto de recomendaciones para su redacción (IREB e.V. 2015), se identifica la métrica de calidad para cuantificar el RNF siempre que sea posible haciendo uso de una lista de métricas, la cual se elaboró tomando como referencia la norma ISO/IEC 25023:2016 - Medidas de calidad del producto software, la Tabla 2 muestra un ejemplo de las métricas asociadas a la característica Eficiencia. Deberá especificarse, además, la relación entre el requisito descrito con el o los requisitos adicionales necesarios para su cumplimiento.

Tabla 2 Métricas propuestas para cuantificar los RNF. Eficiencia. Fuente: elaboración propia 

Verificación y validación de RNF: esta etapa tiene como objetivo garantizar el cumplimiento de los atributos de calidad de la especificación de RNF así como su correspondencia con las necesidades de los interesados. Se ejecutan las actividades de verificación y validación según se define en el Proceso para las actividades de calidad, específicamente los procesos: Ejecutar Revisión Técnica Formal de Requisitos y Ejecutar validación, definidos en la UCI. Los expertos ejecutan las Revisiones técnicas formales de Requisitos a partir de una lista de chequeo, donde se comprueban mediante un grupo de indicadores, los atributos de calidad de las especificaciones. Con el propósito de garantizar una revisión más exhaustiva de los RNF, se adiciona a la lista de chequeo (definida como parte del proceso, en la UCI) elementos de comprobación asociados a la completitud, no ambigüedad, verificabilidad, modificabilidad y clasificación de requisitos, debido a que no se enfatizaba en algunas particularidades de los requisitos no funcionales. Los requisitos no funcionales serán validados y aprobados para lo cual se ejecuta el proceso Ejecutar validación. Deberá documentarse quién ha validado y aprobado los requisitos no funcionales.

Formas de implementación

La estrategia propuesta se aplica durante la fase de Ejecución del ciclo de vida de desarrollo. Las acciones descritas se ejecutan durante las disciplinas correspondientes al Modelado de negocio, Requisitos y Análisis y diseño (en esta última se refinan y puede surgir nuevos RNF). Puede ser ejecutada durante un nuevo desarrollo, mejora o modificación del sistema existente. Se debe incluir, en el cronograma de ejecución del proyecto, las actividades que forman parte de esta estrategia con el objetivo de que su ejecución no afecte los tiempos pactados y se ejecuten de manera natural como parte del proceso de desarrollo. La Tabla 3 muestra la relación entre las acciones que se describen anteriormente y los responsables de su ejecución.

Tabla 3 Relación entre las acciones y los roles responsables de su ejecución. Fuente: elaboración propia 

Formas de evaluación

Se propone realizar una evaluación o valoración de la aproximación lograda al estado deseado, con el propósito de identificar los cambios cualitativos una vez implementada la estrategia a partir de sus resultados. Esta evaluación se realiza por medio de la aplicación de encuestas al personal de la institución y la revisión documental a la Especificación de requisitos (teniendo en cuenta los resultados de la etapa Verificación y validación de RNF). Se analizan los criterios emitidos por los especialistas, así como el comportamiento de indicadores de calidad de las especificaciones; identificados a partir de los atributos definidos en la ISO/IEC/IEEE 29148:2011 Systems and software engineering - Life cycle processes - Requirements engineering (ver Tabla 4). Se registran los resultados alcanzados, lecciones aprendidas y se dejan sentadas las bases para un replanteamiento de las acciones para acometer la implementación del cambio que se propone.

Tabla 4 Indicadores de calidad de las especificaciones. Fuente: elaboración propia 

Análisis de la satisfacción de usuarios

Para analizar el grado de satisfacción de los usuarios con la propuesta descrita se realizó una encuesta a 14 especialistas del CESIM con la finalidad de determinar el índice de satisfacción personal y grupal a partir de la aplicación de la Técnica de Iadov. El análisis de las respuestas se realizó mediante el "Cuadro lógico de Iadov", el cual expresa una relación de las posibles respuestas a las tres preguntas cerradas.

De esta forma, para cada especialista se puede determinar en qué lugar de la siguiente escala se encuentra:

  • Clara satisfacción

  • Más satisfecho que insatisfecho

  • No definida

  • Más insatisfecho que satisfecho

  • Clara insatisfacción

  • Contradictoria

Luego de aplicado el instrumento, se determinó el nivel de satisfacción individual de los usuarios con la estrategia; el 57% de los especialistas encuestados mostraron clara satisfacción, el 28% manifestaron que se encontraban más satisfechos que insatisfechos y en el 14% de los casos no se encuentra definida.

Para obtener el índice de satisfacción grupal (ISG) se trabaja con los diferentes niveles de satisfacción que se expresan en la siguiente escala numérica:

(+1) Máximo de satisfacción.

(+0,5) Más satisfecho que insatisfecho.

(0) No definido y contradictorio.

(-0,5) Más insatisfecho que satisfecho.

(-1) Máxima insatisfacción.

Este índice de satisfacción grupal se calculó según la fórmula:

ISG=

Donde A, B, C, D y E son el número de especialistas con las categorías 1; 2; 3 ó 6; 4 y 5 de satisfacción personal, y N la cantidad total de especialistas encuestados. El cálculo del ISG arrojó como resultado 0.71 el cual evidencia que los especialistas del CESIM están satisfechos con la estrategia propuesta.

CONCLUSIONES

Los resultados obtenidos durante el desarrollo de la investigación permiten arribar a las siguientes conclusiones:

  • La estrategia diseñada permite guiar el desarrollo de los RNF, al proponer métodos y técnicas a utilizar durante estas actividades; lo cual tendrá una repercusión positiva en la calidad de estas especificaciones y por consiguiente del producto final.

  • La aplicación de la técnica de Iadov evidenció la satisfacción de los usuarios con la estrategia diseñada demostrando las posibilidades de su implantación en el CESIM.

REFERENCIAS

CALISOFT, 2017. Norma Ramal (NR) 2-1, Requisitos de la Calidad para Sistemas Informáticos y Productos de Software [en línea]. S.l.: Sub Comité 7 Ingeniería de software y Sistemas. Disponible en: https://subcomite7.cubava.cu/2017/02/10/norma-ramal-requisitos-de-la-calidad-para-sistemas-informaticos-y-productos-de-software/. [ Links ]

CMMI INSTITUTE, 2018. Introducing CMMI Development v2.0 to PAN-INDIA SPIN. [en línea]. S.l.: Disponible en: https://cmmiinstitute.com/getattachment/5b16e5f1-acd2-4b86-aa4c-c9bc353a669f/attachment.aspx.Links ]

CYSNEIROS, L.M. y YU, E., 2004. Non-functional requirements elicitation. S.l.: Springer, Boston, MA. ISBN 978-1-4615-0465-8. [ Links ]

DOERR, J., KERKOW, D., KOENIG, T. y SUZUKI, T., 2005. Nonfunctional requirements in Industry-Three case studies adopting an experience-based NFR method. 13th IEEE International Conference on Requirements Engineering (RE’05). S.l.: s.n., pp. 373-382. ISBN 0-7695-2425-7. [ Links ]

DURAND, S.W., 2017. Análisis y requerimientos de software: manual autoformativo interactivo [en línea]. 1ra. Huancayo-Perú: Huancayo: Universidad Continental. ISBN 978-612-4196. Disponible en: http://repositorio.continental.edu.pe /. Links ]

GARCÍA, G.S. y DANTE, G.P., 2014. Auditoría del conocimiento orientada a procesos principales en un área biomédica. Revista Cubana de Información en Ciencias de la Salud, vol. 25. ISSN 2307-2113. [ Links ]

GUITIÁN, M.V.G., PÉREZ, M.R. de Z. y PORRA, J.L., 2015. Auditoría de información y auditoría de conocimiento: acercamiento a su visualización como dominios científicos. Revista Cubana de Información en Ciencias de la Salud, vol. 26, no. 1, pp. 48-52. [ Links ]

HADAD, G.D., DOORN, J.I. y KAPLAN, G.N., 2009. Explicitar Requisitos del Software usando Escenarios. Workshop em Engenharia de Requisitos (WER), [ Links ]

HENAREJOS, A.S., ALEMÁN, J.L.F., TOVAL, A., HERNÁNDEZ, I.H., GARCÍA, A.B.S. y de GEA, J.M.C. , 2014. Guía de buenas prácticas de seguridad informática en el tratamiento de datos de salud para el personal sanitario en atención primaria. Atención Primaria, vol. 46, no. 4, pp. 214-222. [ Links ]

HINOJOSA, C., RAURA, G., FONSECA, E.R. y DIESTE, O., 2015. La Gestión del Conocimiento Aplicada en la Ingenierıa de Requisitos: Un Caso de Estudio en Ecuador. S.l.: WER. [ Links ]

IMDRF SAMD WORKING GROUP, 2015. Software as a Medical Device (SaMD): Application of Quality Management System. S.l.: s.n. [ Links ]

IREB E.V., 2015. Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB- Nivel Básico - Versión 2.2,. 2015. S.l.: s.n. [ Links ]

LÓPEZ, D.G., BARRERAS, L.M.Á. y OROZCO, A.F., 2014. Implementación de estándares DICOM SR y HL7 CDA para la creación y edición de informes de estudios imagenológicos. Revista Cubana de Informática Médica, vol. 6, no. 1, pp. 71-86. [ Links ]

ORGANIZACIÓN PANAMERICANA DE LA SALUD, 2016. Revisión de estándares de interoperabilidad para la eSalud en Latinoamerica y el Caribe. S.l.: s.n. ISBN 978-92-75-31881-2. [ Links ]

RAMÍREZ, N. de A. y LIMA, A.V., 2011. Resultados científicos en la investigación educativa. S.l.: Editorial Pueblo y Educación. ISBN 978-959-13-2124-4. [ Links ]

SILVA, A., PINHEIRO, P., ALBUQUERQUE, A. y BARROSO, J., 2016. A Process for Creating the Elicitation Guide of Non-functional Requirements. Springer International Publishing. [ Links ]

SIMBAÑA SARANSIG, W.J. y SIMBAÑA QUINSASAMÍN, J.G., 2015. Investigación de las prácticas de la ingeniería de requisitos en las empresas de desarrollo de software de la ciudad de Quito y generación de una propuesta metodológica para la mejora de dichas prácticas. Tesis de Grado: 2015 Carrera de Ingeniería en Sistemas e Informática. Sangolquí: Universidad de las Fuerzas Armadas ESPE. [ Links ]

SOMMERVILLE, I., 2011. Software engineering. 9. S.l.: s.n. ISBN 13: 978-0-13-703515-1 [ Links ]

WIEGERS, K. y BEATTY, J., 2013. Software Requirements Third Edition. 3. S.l.: Microsoft Press. ISBN 78-0-7356-7966-5. [ Links ]

Recibido: 21 de Enero de 2019; Aprobado: 23 de Abril de 2019

* Autor para correspondencia: ymolinah@uci.cu

Creative Commons License Este es un artículo publicado en acceso abierto bajo una licencia Creative Commons