Requerimientos no funcionales: Una clasificación

Los requerimientos no funcionales son los que especifican criterios para evaluar la operación
de un servicio de tecnología de información, en contraste con los requerimientos funcionales
que especifican los comportamientos específicos de las aplicaciones.

En la primera parte de esta serie, describíamos una definición de requerimientos no

funcionales y porque son importantes.

Los requerimientos no funcionales definen las características o cualidades generales que se

esperan de un sistema y establecen restricciones sobre el producto, el proceso de desarrollo de
software y establecen restricciones externas que el software debe lograr.

Para poder identificar estas características durante la ingeniería de requisitos que realizan los
Analistas de sistemas e Ingenieros de software en todo proyecto de desarrollo, es útil contar
con una clasificación que nos establezca un marco de los tipos de requerimientos funcionales
con que nos podemos encontrar.

PMOinformatica presenta una clasificación de los requerimientos no funcionales a continuación.

¿Que son los requerimientos no funcionales?

Si buscas más información sobre el concepto de requerimientos no funcionales, te
recomendamos la primera parte de esta serie:

> Requerimientos no funcionales: Porque son

importantes
Para ver algunos ejemplos de requerimientos no funcionales consulta el siguiente artículo:

> Requerimientos no funcionales:
Ejemplos
Clasificaciones varias de requerimientos no
funcionales
Existen diversas fuentes o marcos de referencia para clasificar los requerimientos no
funcionales, de hecho, existe un estándar de la IEEE, Std 830 – 1993 que establece 13 tipos de
requerimientos no funcionales que deberían incluirse en toda especificación de software.

Otro modelo es el propuesto por Jacobson (1999) en el cuales e propone para el Unified
Process.
Uno de los modelos más difundidos es el establecido por Somerville, que presentaremos más
adelante en el artículo.

Formación en Ingeniería de requisitos

Curso de Ingeniería de requisitos

Se ha hecho muy evidente que una especificación deficiente de los requisitos del software
puede conducir a proyectos fallidos, de allí que esta disciplina cada vez adquiera mayor
importancia.

El curso de Ingeniería de requisitos esta diseñado para enseñarte a identificar y analizar

requisitos de manera integral, con el cual garantizaras la elaboración de especificaciones
funcionales de calidad.

Conocerás técnicas de levantamiento de requisitos como la revisión de documentación,

observación y entrevistas, técnicas para el análisis como la descomposición funcional,
modelado de procesos, MoSCoW, TimeBoxing, así como actividades de gestión de requisitos
para su organización, priorización y gestión de alcance.

La clasificación de requerimientos no
funcionales de Somerville
La figura presenta la clasificación de requerimientos no funcionales definida por Somerville.
Somerville divide los requerimientos no funcionales en tres grandes tipos: Requerimientos de
producto, requerimientos organizacionales y requerimientos externos.

Requerimientos no funcionales de producto

Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual
establece límites y restricciones sobre lo que los diseñadores (arquitectos de software) e
ingenieros de software pueden hacer.

Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el desempeño y
la confiabilidad, pero otros son más difíciles como por ejemplo usabilidad y adaptabilidad.

Los requerimientos de producto pueden clasificarse en (Sommerville):

 Requerimientos de usabilidad: La usabilidad se define como el esfuerzo que necesita

hacer un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de
un software de aplicación. En tiempos recientes, la usabilidad ha adquirido mucha importancia,
en especial ante la demanda de desarrollo de software para móviles y tabletas.
 Requerimientos de eficiencia: Relacionado con desempeño en cuanto a tiempo de
respuesta, número de operaciones por segundo, entre otras mediciones, así como consumo de
recursos de memoria, procesador, espacio en disco o red.
 Requerimientos de dependibilidad: Engloba varios atributos
o Disponibilidad: Disposición del sistema para prestar servicio correctamente.
o Confiabilidad: Continuidad del servicio prestado por el sistema.
o Seguridad industrial: Ausencia de consecuencias catastróficas para el
usuario o el ambiente.
o Integridad: Ausencia de alteraciones inadecuadas al sistema.
o Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones a un
proceso sin afectar la continuidad del servicio.
 Requerimientos de seguridad: Capacidades funcionales o no funcionales que debe
tener un sistema para cumplir atributos en el área de seguridad de tecnología de información,
seguridad de datos, seguridad lógica, control de acceso a información (restricciones de
acceso), autenticidad de la información, privacidad, entre otros aspectos.

Considerar los requerimientos de producto es vital para lograr la integración continua de

aplicaciones y el desarrollo de cambios que sean rápidos pero sostenibles en el tiempo.

Este nuevo paradigma es necesario para implementar las nuevas tecnología de información

y aplicaciones de softwarecomo la movilidad, internet de las cosas, analítica avanzada de
datos (Big Data), evolución de los sistemas a la nube y tecnología de información escalable.

Requerimientos no funcionales organizacionales

Se derivan de las políticas y procedimientos de la organización como por ejemplo estándares
de procesos o requerimientos de implementación.

Pueden incluir metodologías de desarrollo de software, estándares de programación

(codificación) y herramientas de soporte al desarrollo de software (por ej. Herramientas CASE)
que deben usarse (siguiendo las políticas de la organización), también reportes a la gerencia
que deben proveerse, entre otros.

Las herramientas para la gestión de desarrollo de software que conocemos, se definen

como requerimientos no funcionales organizacionales.

Los requerimientos organizacionales pueden clasificarse en (Sommerville):

 Requerimientos de entorno: Describen el ambiente operativo en el que se debe

desenvolver el sistema.
 Requerimientos operacionales: Procedimientos operativos que describen como será
usado el sistema dentro del contexto de la organización.
 Requerimientos de desarrollo: Lenguaje de programación a usar, estándares de
codificación, patrones (y antipatrones) de diseño y programación, herramientas para
gestionar el desarrollo de software, entorno de desarrollo de software (ambiente de desarrollo),
entorno de pruebas de software (ambiente de pruebas), entre otros aspectos.

Uno de los aspectos que se documentan como requerimientos funcionales organizacionales

son los entorno, específicamente los procedimientos de mantenimiento y administración
del ambiente de desarrollo de software.

Esta administración también incluye los procedimientos para gestionar los ambientes de

pruebas integrales.

Requerimientos no funcionales externos

Estos derivan del entorno organizacional (no entorno técnico) en el cual se desarrolla el
sistema y pueden hacerse tanto sobre el producto (el software desarrollado) o también sobre el
proceso de desarrollo de software.

Este tipo de requerimientos incluyen limitaciones de índole económica, como por ejemplo
el presupuesto del proyecto de software, interacción o necesidad del sistema de inter-operar
con otros sistemas, requerimientos regulatorios en el área de salud, seguridad industrial o
protección de datos, requerimientos legales concernientes con licencias, regulaciones o
certificaciones que necesita el producto según la industria en el que se desempeñe, entre otros.

Somerville a su vez clasifica estos requerimientos en:

 Requerimientos regulatorios: Leyes y reglamentos que establecen que debe hacer el

sistema y como debe hacerlo para cumplirlas. El foco de un sistema o nueva funcionalidad
puede ser exclusivamente para cumplir una regulación.
 Requerimientos éticos: Requerimientos que aseguran que el sistema será aceptable
para el usuario, público en general y se adapta a las costumbres de la sociedad en la que se
desenvuelve o a la que presta servicios.
 Requerimientos legislativos: Características que debe cumplir el sistema para
cumplir con la ley, por ejemplo en el área de contabilidad (normas contables y estándares
financieros), requerimientos de seguridad industrial (para sistemas críticos), entre otros
aspectos.

Importancia de clasificar los requerimientos no

funcionales
El especificar requerimientos no funcionales de forma incompleta o inexacta puede ocasionar el
fracaso de tu proyecto de ingeniería de software.

De hecho no gestionar los requerimientos no funcionales es uno de los errores clásicos en la

gestión de desarrollo de software definida por Steve McConnell.

Lograr clasificar adecuadamente cada requerimiento no funcional identificado es muy

importante para garantizar este proceso.

Errores clásicos en la gestión de desarrollo de software

Imagen obtenida de: comerecommended.com

En 1996, Steve McConnel, un influyente consultor de la industria del desarrollo del

software, público su obra “Desarrollo Rápido: Domesticando Cronogramas Salvajes de
Software” (Rapid Development: Taming Wild Software Schedules).

Una de las secciones del libro, describen los errores clásico al tratar de acelerar (o hacer
Fastrack) de los proyectos, prácticas de desarrollo de software que son seleccionadas con
tanta frecuencia y con los mismos malos resultados predecibles, que merecen ser llamadas
 “clásicos”, y que siguen estando muy vigentes a pesar que la obra se público hace 17 años.

¿Algunas de estas prácticas erróneas le son familiares?, por ejemplo, ¿Qué hacemos si un
proyecto está retrasado?, ¿incorporamos más gente?, ¿que hacemos si algún integrante está
dañando la productividad del equipo?, ¿esperamos hasta el final del proyecto para despedirle?,
o ¿que haría si le han asignado un proyecto agresivo en fecha?, ¿reclutar a todos
desarrolladores disponibles (inclusive si son novatos) e iniciar lo antes posible sin
planificación?.

A continuación dejamos la lista, si conoces algún error clásico que no esté incluido, te invitamos
a dejar un comentario.

Los Desarrolladores, Gerentes y Clientes usualmente tienen buenas razones para tomar las
decisiones que toman, pero estos errores clásicos se han cometido con tanta frecuencia que
hoy en día sus consecuencias son fáciles de predecir, y la experiencia ha demostrado que lejos
de mejorar la situación, tienden a agravarla.

A continuación los errores clásicos en proyectos de desarrollo de software de Steve McConnel

Gestión de Personal Procesos Producto Tecnología

1.     No dar importancia a la 14.  Permitir cronogramas 28.  Incluir al principio 33.  Síndrome de la bala de

motivación. optimistas. requerimientos no plata. (Asumir que la
necesarios misma solución
2.     Aceptar personal con 15.  No gestionar  los realmente (Gold funciona para todo).
debilidades. riesgos o gestionarlos Plating).
de forma insuficiente. 34.  Sobrestimar los
3.     No controlar a empleados 29.  Permitir constantes ahorros que se
problemáticos. 16.  Usar contratitas y no cambios en los pueden obtener al
gestionarlos. requerimientos, sin implementar nuevos
4.     Privilegiar el “Heroismo”
en lugar de el buen 17.  Planificar de forma aplicar controles.   métodos o
desempeño continuo. insuficiente. (Feature Creep). herramientas.

5.     Incorporar personal a un 18.  Abandonar la 30.  Incluir requerimientos35.  Cambiar herramientas

proyecto retrasado. planificación al estar técnicos no en el medio del
bajo presión. necesarios proyecto.
6.     Permitir oficinas ruidosas, (Developer Scrope
con muchas personas. 19.  No aprovechar el Creep). 36.  Carecer de
tiempo mientras el automatización de
7.     Permitir la fricción entre proyecto es aprobado. 31.   Modificar el control de código
desarrolladores y el cronograma para fuente.
cliente (los usuarios). 20.  Ir directo a la corregirlo, pero luego
programación sin agregar más
8.     Comprometer hacer análisis y esfuerzo y tareas.
expectativas no realistas. diseño.
32.  Desarrollo orientado
9.     Carecer de patrocinio 21.  Diseñar de forma a la investigación
efectivo. inadecuada. (Hacer investigación
10.  Carecer de apoyo de de Software en lugar
22.  Omitir revisiones,
interesados de desarrollo de
inspecciones de
(stakeholders). software).
código y pruebas, al
11.  No involucrar a los
 usuarios finales. estar bajo presión.

12.  Privilegiar la politiquería 23.  Insuficiente control por

sobre los resultados. parte de la Gerencia.

13.  Exceso de optimismo. 24.  Integración prematura

o muy frecuente del
producto.

25.  Omitir tareas
esenciales en las
estimaciones.

26.  Planificar para
recuperar el retraso
después.

27.  Programación alocada
(Code Like Hell).

Defina que es Estrategia de requerimientos.

Como sabemos, un área de conocimiento de gran importancia en el desarrollo de software,

es la ingeniería de requerimientos. Esta comprende las actividades de obtención (captura,
descubrimiento y adquisición), análisis (y negociación), especificación, y validación de
requisitos. Además, establece una actividad de gestión de requerimientos para manejar los
cambios, mantenimiento y rastreabilidad de los requerimientos.

El proceso de obtención de requisitos, cuya finalidad es llevar a la luz los requisitos, no

solo es un proceso técnico, sino también un proceso social que envuelve a diferentes
personas, lo que conlleva dificultades añadidas a su realización.

Existe un gran número de técnicas para obtener requerimientos.

Entrevistas: es de gran utilidad para obtener información cualitativa como opiniones, o

descripciones subjetivas de actividades. Desarrollo Conjunto de Aplicaciones ( JAD ): se
utiliza para promover la cooperación y el trabajo en equipo entre usuarios y
analistas.  Desarrollo de Prototipos: suelen consistir en versiones reducidas, demos o
conjuntos de pantallas (que no son totalmente operativos) de la aplicación pedida.  

Observación: Por medio de esta técnica el analista obtiene información de primera mano

sobre la forma en que se efectúan las actividades. Estudio de documentación: Varios tipos
de documentación, como manuales y reportes, pueden proporcionar al analista
información valiosa con respecto a las organizaciones y a sus operaciones.   

Cuestionarios: El uso de cuestionarios permite a los analistas reunir información

proveniente de un grupo grande de personas.   

Tormenta de ideas ( Brainstorming ): Consiste en reuniones con cuatro a diez personas

donde como primer paso sugieren toda clase de ideas sin juzgar su validez –por muy
disparatadas que parezcan–, y después de recopilar todas las ideas se realiza un análisis
detallado de cada propuesta.   
ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos de vista
Humano y Técnico ): Constituye un método bastante evolucionado para fomentar la
participación de los usuarios en los proyectos. Puntos de Vista: Cualquier sistema de
software no trivial debe satisfacer las necesidades de un grupo diverso de interesados
(stakeholders).  

Escenarios: Estos se utilizan para documentar el comportamiento del sistema cuando se le

presentan eventos específicos. Etnografía: Los sistemas de software no existen de forma
aislada; se utilizan en un contexto social y organizacional, y los requerimientos de sistemas
de software se derivan y se restringen acorde a ese contexto.  

Describa que permite y que evita las siguientes actividades: Hacer -

Planear – Corregir –Revisar.

Planear 
Consiste en: 

 Definir propósito y participantes

 Definir forma de trabajo
 Preparar información
 Capacitar a los participantes

Permite:

 Conocer el propósito de la Reunión

 Conocer los temas a tratar
 Conocer los participantes de la reunión
 Preparar la documentación

Evita:

 Reuniones sin un claro propósito

 Ausencias por falta de comunicación
 Falta de documentación

 
Hacer 
Consiste en:

 Preparar el Lugar
 Comenzar la reunión
 Conducir la reunión
  Cerrar la reunión

Permite:

 Desarrollar la reunión de la manera planeada

Evita:

 No contar con sala para el desarrollo de la reunión

 Demoras
Revisar 
Consiste en:

 Revisar
 Asignar tareas
 Publicar documentación

Permite:

 Ordenar los resultados

 Organizar el trabajo

Evita:

 Falta de acuerdos

Corregir 
Consiste en:

 Planear próximos pasos

 Medir Valor Agregado
 Ajustar el proceso

Permite:

 Mejorar la forma de trabajo

 Hacer los ajustes necesarios

Evita:

 Repetir Errores

Cite 2 beneficios de aplicar estas actividades en el levantamiento de requerimientos

Este modelo propone planificar, hacer, verificar y actuar. Es común para proyectos
medianos y pequeños. 

1. Uno de sus mayores  beneficios es evitar el levantamiento de requerimientos y su

análisis sin la planificación. Para esto, se establecen reuniones con los usuarios, y
conversar sobre sus requerimientos.
2. Adicionalmente, su mayor fortaleza consiste en organizar el trabajo de una forma
que la participación de todos los involucrados es indispensable.

Bibliografia

César Arturo Guerra, 17 (Septiembre - Octubre 2007). Obtención de

Requerimientos. Técnicas y Estrategia. Extraído el 18 de Abril del 2015 desde: 
http://sg.com.mx/revista/17/obtencion-requerimientos-tecnicas-y-estrategia#.VTLxMubF-3g

Daniel Cabanzo, 16 de octubre de 2014. Estrategias y tácticas en el trabajo con

requerimientos 11. Extraído el 18 de Abril del 2015 desde:  
http://es.slideshare.net/danielcabanzo/estrategias-y-tcticas-en-el-trabajo-con-
requerimientos-11

 Laura K Botia R, 22 October 2014. Estrategia Y Tácticas En El Trabajo Con

Requerimientos. Extraído el 18 de Abril del 2015 desde:
https://prezi.com/6f0aou-jfxhx/estrategia-y-tacticas-en-el-trabajo-con-requerimientos/