Identificación de Requerimientos no funcionales

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que
entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en
el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del
sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que
se utiliza en la interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones
en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros
sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las
políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los

requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se
requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de
portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la

organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de programación o el método de diseño a
utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su
documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de

desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el
sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben
seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos
últimos son impuestos al sistema para asegurar que será aceptado por el usuario.

En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es

posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de
mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva
los requerimientos no funcionales cuantitativos es muy alto.

En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de

requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de forma
separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con
los requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e
identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance
apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que
claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace
colocándolos en una sección aparte o diferenciándolos, de alguna 

Algunos ejemplos de requerimientos no funcionales son:

 Comprobabilidad: Grado en que un sistema, software o servicio de TI permite y facilita

que sea probado en un determinado contexto.
 Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado en un
período determinado. También puede definirse el grado en que un sistema está en un estado
operable definido cada vez que se necesite.
 Extensibilidad: Grado en que la implementación del sistema toma en consideración y
facilita su crecimiento en el futuro.
 Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una creciente carga
de trabajo, por ejemplo mayor número de conexiones o usuarios. No debe confundirse con
extensibilidad, que mide la capacidad del sistema de crecer en funcionalidades.
 Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al producto (en este
caso al software o servicio de TI), con la finalidad de: Desarrollar nuevos requerimientos, Aislar los
defectos y sus causas, corregir estos defectos y atender las demandas del entorno cambiante. 
 Seguridad: Grado de protección de los datos, software y plataforma de tecnología de
posibles pérdidas, actividades no permitidas o uso para propósitos no establecidos previamente.
 Usabilidad: Definido como la facilidad de uso y aprendizaje de un Sistema, Software o
Servicio de Tecnología de Información.

Necesidad de definir los requerimientos no

funcionales en términos precisos y que puedan
medirse
Para todo proyecto de TI, es crítico que los requerimientos no funcionales sean definidos con los
usuarios, clientes y otros interesados en términos precisos y medibles en la etapa de análisis del
proyecto. No hacerlo puede poner en riesgo el éxito de un proyecto.

Por ejemplo, tomando el caso de los tiempos de respuesta de un sistema, lo cual podría
clasificarse en disponibilidad, ¿que sucedería si no se definiera el tiempo de respuesta deseado en
la fase de análisis de requerimientos?, o si se definiera en términos imprecisos, como por
ejemplo indicado, "Se necesita un tiempo de respuesta aceptable".

Al llegar a la fase de implementación, quizás en sistema tendría un tiempo de respuesta, digamos

de 15 segundos(debido a muchas plataformas remotas y bases de datos involucradas), pero el
usuario lo necesitaba en menos de 5 segundos, para por ejemplo, evitar que se forme una fila muy
larga para atender a clientes.

Errores como esto pudieran ocasionar inclusive que el usuario final decidiera no usar el nuevo
sistema, haciendo fracasar el proyecto.

Por ende, es importante definir los requerimientos con métricas que puedan establecer sin lugar a
duda que el sistema o servicio de TI desarrollado cumple los parámetros no funcionales solicitados.

En el caso particular de tiempos de respuesta (desempeño de un sistema) una herramienta útil

para comprobarla es SoapUI, que permite hacer pruebas de carga o estrés sobre webservices.
Aquí te compartimos artículos sobre el tema: Otros requerimientos no funcionales pueden ser:
Accesibilidad, Capacidad, Cumplimiento, Documentación, Requerimientos de despliegue,
Efectividad, Eficiencia, Tolerancia a fallos, Modificabilidad, Operabilidad, Portabilidad,
Confiabilidad, entre otros.

Hoy en día, muchas empresas se han extendido a la adquisición de herramientas CASE

(Ingeniería Asistida por Computadora), con el fin de automatizar los aspectos clave de todo
el proceso de desarrollo de un sistema, desde el principio hasta el final e incrementar su
posición en el mercado competitivo, pero obteniendo algunas veces elevados costos en la
adquisición de la herramienta y costos de entrenamiento de personal así como la falta de
adaptación de la herramienta a la arquitectura de la información y a las metodologías de
desarrollo utilizadas por la organización. Por otra parte, algunas herramientas CASE no ofrecen
o evalúan soluciones potenciales para los problemas relacionados con sistemas o virtualmente
no llevan a cabo ningún análisis de los requerimientos de la aplicación.
Sin embargo, CASE proporciona un conjunto de herramientas semiautomatizadas y
automatizadas que están desarrollando una cultura de ingeniería nueva para muchas empresas.
Uno de los objetivos más importante del CASE (a largo plazo) es conseguir la generación
automática de programas desde una especificación a nivel de diseño.
Ahora bien, con la aparición de las redes de ordenadores en empresas y universidades ha
surgido en el mundo de la informática la tecnología cliente /servidor. Son muchas de
las organizaciones que ya cuentan con un número considerable de aplicaciones cliente /
servidor en operación: Servidores deBases de Datos y Manejadores de Objetos Distribuidos.
Cliente / servidor es una tecnología de bajo costo que proporciona recursos compartidos,
escalabilidad, integridad, encapsulamiento de servicios, etc. Pero al igual que toda tecnología,
el desarrollo de aplicaciones cliente / servidor requiere que la persona tenga conocimientos,
experiencia y habilidades en procesamiento de transacciones, diseño de base de datos, redes de
ordenadores y diseño gráfica de interfase.
El objeto de estudio está centrado en determinar ¿cuáles son las influencias de las
herramientas CASE en las empresas desarrolladoras de sistemas de información cliente /
servidor? Y ¿cuáles son las tendencias actuales de las empresas fabricantes de sistemas cliente /
servidor?.
A continuación, en el siguiente artículo ahondaremos más en el propósito general de
las Herramientas CASE y el impacto que puede ocasionar el uso de las mismas en una empresa.
2. Herramientas Case
De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la
aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias
de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de
CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las
aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-
Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más
eficiente y efectivo posible. Una herramienta CASE suele incluir:
 Un diccionario de datos para almacenar información sobre los datos de la aplicación de
bases de datos.
 Herramientas de diseño para dar apoyo al análisis de datos.
 Herramientas que permitan desarrollar el modelo de datos corporativo, así como los
esquemas conceptual y lógico.
 Herramientas para desarrollar los prototipos de las aplicaciones.

El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de

una aplicación de bases de datos.
4. Tecnología Case
La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a
mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean
los siguientes objetivos:
 Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser
realizadas con una herramienta se consigue agilizar el trabajo.
 Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
 Simplificar el mantenimiento de los programas.
 Mejorar y estandarizar la documentación.
 Aumentar la portabilidad de las aplicaciones.
 Facilitar la reutilización de componentes software.
 Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilización de gráficos.

Automatizar:
Ø El desarrollo del software
Ø La documentación
Ø La generación del código
Ø El chequeo de errores
Ø La gestión del proyecto
Permitir:
Ø La reutilización del software
Ø La portabilidad del software
Ø La estandarización de la documentación
5. Componentes de una herramienta case
De una forma esquemática podemos decir que una herramienta CASE se compone de los
siguientes elementos:
 Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la
herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base
de Datos (SGBD) o de un sistema de gestión de ficheros.
 Meta modelo (no siempre visible), que constituye el marco para la definición de las
técnicas y metodologías soportadas por la herramienta.
 Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la
herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la
propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez,
alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con
otras herramientas.
 Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la
exactitud, integridad y consistencia de los esquemas generados por la herramienta.
 Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico
que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la
ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas
metodologías.

6. Estructura general de una herramienta case

La estructura CASE se basa en la siguiente terminología:
 CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases
finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de
sistemas, el análisis de sistemas y el diseño de sistemas.
 CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases
finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de
sistemas y el soporte de sistemas.
 CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades
que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión
de proyectos y la estimación.

7. Estado Actual
En las últimas décadas se ha trabajado en el área de desarrollo de sistemas para encontrar
técnicas que permitan incrementar la productividad y elcontrol de calidad en cualquier proceso
de elaboración de software, y hoy en día la tecnología CASE (Computer Aided Software
Engineering) reemplaza al papel y al lápiz por el ordenador para transformar la actividad de
desarrollar software en un proceso automatizado.
La tecnología CASE supone la –informatización de la informática—es decir –la automatización
del desarrollo del software--, contribuyendo así a elevar la productividad y la calidad de en el
desarrollo de los sistemas de información de forma análoga a lo que suponen las técnicas
CAD/CAM en el área de fabricación.
En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la
productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:
<<> Permitir la aplicación práctica de metodologías, lo que resulta muy difícil sin emplear
herramientas.
<<> Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
<<> Simplificar el mantenimiento del software.
 Mejorar y estandarizar la documentación.
 Aumentar la portabilidad de las aplicaciones.
 Facilitar la reutilización de componentes de software
 Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la
utilización de controles gráficos (piezas de código reutilizables).

8. Integración de las herramientas case en el futuro

Las herramientas CASE evolucionan hacia tres tipos de integración:
1. La integración de datos permite disponer de herramientas CASE con
diferentes estructuras de diccionarios locales para el intercambio de datos.
2.
3. La integración de presentación confiere a todas las herramientas CASE el mismo
aspecto.
4. La integración de herramientas permite disponer de herramientas CASE capaces de
invocar a otras CASE de forma automática.

Definició n de las normas ISO

Las normas ISO son un conjunto de normas orientadas a ordenar la gestión de una empresa en sus
distintos ámbitos. La alta competencia internacional acentuada por los procesos globalizadores de la
economía y el mercado y el poder e importancia que ha ido tomando la figura y la opinión de los
consumidores, ha propiciado que dichas normas, pese a su carácter voluntario, hayan ido ganando un
gran reconocimiento y aceptación internacional.

Las normas ISO son establecidas por el Organismo Internacional de Estandarización (ISO), y se

componen de estándares y guías relacionados con sistemas y herramientas específicas de gestión
aplicables en cualquier tipo de organización.
 Finalidades y ventajas de las normas ISO

Las normas ISO se crearon con la finalidad de ofrecer orientación, coordinación, simplificación y

unificación de criterios a las empresas y organizaciones con el objeto de reducir costes y aumentar la
efectividad, así como estandarizar las normas de productos y servicios para las organizaciones
internacionales.

Las normas ISO se han desarrollado y adoptado por multitud de empresas de muchos países por una
necesidad y voluntad de homogeneizar las características y los parámetros de calidad y seguridad de
los productos y servicios.

Ventajas de las normas ISO para las empresas

En base a esta finalidad y objetivo inicial y debido al gran prestigio y enorme seguimiento alcanzado, las
normas ISO suponen importantes beneficios para las empresas, compañías y organizaciones en
general:

 Proporcionan elementos para que una organización puede alcanzar y mantener

mayores niveles de calidad en el producto o servicio.

 Ayudan a satisfacer las necesidades de un cliente cada vez más exigente.

 Permite a las empresas reducir costos, conseguir más rentabilidad y aumentar los
niveles de productividad.

 Constituye uno de los medios más eficaces para conseguir ventaja competitiva.

 Reducir rechazos o incidencias en la producción o en la prestación de servicios.

 Implementar procesos de mejora continua.

 C ALIDAD DE SOFTWARE

 El término calidad de software se refiere al grado de desempeño de las

principales características con las que debe cumplir un sistema
computacional durante su ciclo de vida, dichas características de cierta
manera garantizan que el cliente cuente con un sistema confiable, lo cual
aumenta su satisfacción frente a la funcionalidad y eficiencia del sistema
construido.

 El concepto de calidad de software, según Pressman (2010) se asocia a la

"concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos con los estándares de desarrollo plenamente
 documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente", con base en los requisitos
funcionales y no funcionales identificados en la etapa de análisis del
sistema, insumo principal para implementar dichos requisitos con los
atributos mínimos de calidad, fomentando la aplicación de procesos
estandarizados y criterios necesarios en cada una de sus etapas, así se
fomenta que el avance en el ciclo de vida del software minimice el riesgo
de fracaso del proyecto. Por su parte, el Instituto de Ingenieros Eléctricos y
Electrónicos (IEEE, 1990) define calidad de software como "el grado con
el que un sistema, componente o proceso cumple los requerimientos
especificados y las necesidades o expectativas del cliente o usuario",
denotando que el énfasis radica en los requisitos específicos del sistema y
en la búsqueda de la satisfacción del cliente.

 Para garantizar la calidad de software es importante implementar algún

modelo o estándar de calidad que permita la gestión de atributos en el
proceso de construcción de software, teniendo en cuenta que la
concordancia de los requisitos y su construcción son la base de las
medidas de calidad establecidas.

 2. Modelos de calidad de software

 Aunque modelo y metodología distan en su definición, se rescata la cita

dada por Moszkowitz (2010) en la que presenta una metodología que
permite a cualquier organización realizar una autoevaluación o
autodiagnóstico, por medio de una revisión sistemática de sus estrategias y
prácticas de gestión.

 En el caso de la calidad de software el modelo debe ir enfocado a hacer

seguimiento y evaluación a cada etapa de construcción del producto
software. Por otro lado se menciona (Scalone, 2006) que

 los modelos de calidad son aquellos documentos que integran la

mayor parte de las mejores prácticas, proponen temas de
administración en los que cada organización debe hacer énfasis,
integran diferentes prácticas dirigidas a los procesos clave y permiten
medir los avances en calidad.