Análisis y Diseño Orientado a Objetos

2.1 Análisis de requerimientos: Marco conceptual

Prof. Ulises Vélez Saldaña

26 de septiembre de 2019

Índice
1. Introducción 1
1.1. Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Saberes previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Objetivos de la lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Análisis 2
2.1. Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. ¿Para que analizar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Documento de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Stakeholders 4
3.1. Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Ejemplo 1: Stakeholders en un “software a la medida” . . . . . . . . . 5
3.3. Ejemplo 2: Stakeholders en un “software de licenciamiento” . . . . . . 5
3.4. Ejemplo 3: Stakeholders en un “software propio” . . . . . . . . . . . . 6

4. Actividades 7
4.1. Tipos de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Toma de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Especificación de requerimientos . . . . . . . . . . . . . . . . . . . . . 9

5. Requerimientos 10
5.1. ¿Que son los requerimientos? . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Tipos de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Requerimientos del Usuario VS del Sistema . . . . . . . . . . . 12

1
 5.2.2. Requerimientos Funcionales VS No Funcionales . . . . . . . . . 12
5.3. Tipos de Requerimientos No Funcionales . . . . . . . . . . . . . . . . 13
5.4. Propiedades de Software . . . . . . . . . . . . . . . . . . . . . . . . . 14

6. Resumen 15

1. Introducción
1.1. Contenido
En este capı́tulo damos un marco conceptual del análisis de requerimientos con
énfasis en adoptar un lenguaje formal que permita comprender todos los conceptos y
procesos que lo rodean. Al final presentamos un resumen de los conceptos presentados
y consideraciones importantes para esta etapa del desarrollo.

1.2. Saberes previos

Es importante que el lector conozca previamente:

• Ciclo de vida del software.

• Objetivos de la Ingenierı́a de software.

• Nociones básicas de programación.

• Estructuras de datos.

• Programación basada en eventos.

1.3. Objetivos de la lectura

• Identifique claramente las actividades que comprende la etapa de Análisis de Re-
querimientos.

• Comprenda la diferencia entre Identificación de requerimientos, Toma de Requeri-

mientos, Análisis de requerimientos, Especificación de requerimientos, Validación
e requerimientos y Administración e requerimientos.

• Conozca claramente las diferencias entre: Requerimientos del Usuario, Requeri-

mientos del Sistema, Requerimientos Funcionales, Requerimientos no funcionales,
Propiedades de software y Requerimientos del Negocio.

2
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 • Comprenda la importancia del Análisis del problema como parte del Análisis de
requerimientos.

• Recuerde la importancia y distintos usos que tiene el documento de análisis.

• Identifique las principales fuentes de requerimientos.

2. ¿Que es el análisis de requerimientos?

Para iniciar, necesitamos una definición del “Análisis de Requerimientos” que nos
permita delimitar nuestro campo de estudio,no por que no sea importante lo demás sino
por su complejidad.

2.1. Análisis de requerimientos

Dentro del Ciclo de vida del software se menciona una etapa de análisis, la cual está
presente aunque sea de manera iterativa en todas las metodologı́as de desarrollo, inclu-
yendo las metodologı́as ágiles. Aun que puede ser una “etapa” o varias las actividades
que se realizan son las siguientes:
Análisis de requerimientos
Se refiere a aquellas tareas orientadas a determinar las necesidades o condiciones a
cumplirse por un producto nuevo o a ser modificado, tomando en cuenta la posibilidad
de conflictos entre requerimientos que provienen de varios stakeholders.
Esta tarea, no es propia del desarrollo de software e involucra identificar, especificar,
gestionar y validar dichos requerimientos, los cuales son en esencia el alcance de todo
proyecto.
El análisis de requerimientos es complejo debido a que involucra hacer estudios,
descubrimientos, elaborar modelos, llegar a acuerdos, documentarlos y comunicarlos en
todo momento durante el proyecto, todo lo anterior sin olvidar que los requerimientos
suelen cambiar a lo largo de todo el proyecto.

2.2. ¿Para que analizar?

El análisis es inevitable, pues no podemos hacer sistemas de la nada y sin saber para
que serán utilizados o cual es el problema que deben resolver. Sin embargo, las razones
por las que no lo podemos tomar a la ligera son las siguientes:

• Con fines contractuales en relación a alcance, tiempo y costo de un proyecto.

• Para validar el producto terminado. ¿Es lo que se pidió?

3
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 • Priorizar necesidades y tomar desiciones a lo largo del proyecto.

• Dar mantenimiento posterior al desarrollo.

• Resolución de conflictos y malos entendidos entre el equipo de desarrollo y el

cliente.

• Evaluar el diseño del sistema sin la necesidad de desarrollarlo.

• Historia para mejora continua.

Aunque en muchas ocasiones se ha criticado esta etapa por ser muy demandante y
poco útil, los resultados de un buen análisis se ven reflejados en la ausencia de conflictos
durante el desarrollo y pruebas del sistema.

2.3. Documento de análisis

En todo proyecto el análisis debe estar documentado en alguna parte, de otra forma
no podremos utilizar la información generada.
Documento de análisis
Documento que contiene toda la descripción del sistema a desarrollar, incluye:

• Objetivos del sistema

• Información del negocio

• Usuarios y responsabilidades

• Glosario de términos

• Requerimientos funcionales

• Alcance del proyecto

• Requerimientos no funcioanels

• etc.

Este documento puede ser muy extenso o muy simple, dependiendo del proyecto y la
forma de trabajar.
Lo que no debemos olvidar es que no necesariamente debe ser un solo documento,
que no tiene un formato especı́fico y que en lugar de ser una carga para el proyecto debe
ser una ayuda.

4
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Antes de seguir avanzando en el análisis de requerimientos, es importante darle su
importancia al término Stakeholder. Aunque se ha hecho un intento por no utilizar
términos ajenos a nuestro idioma en esta lectura, ésta palabra es muy usada en proyectos
y sobretodo en sistemas, se maneja en su forma original por no tener equivalente en
español.

3. ¿Que es el Stakeholder?
En el contexto de la administración ed proyectos el Stakeholder tiene una connotación
mas clara que en los libros de Ingenierı́a de software. Cuando se está hablando de análisis
de requerimientos el término se refiere a un grupo mas especı́fico como se explica a
continuación.

3.1. Stakeholder

Stakeholder
En el ámbito de proyectos, se refiere a cualquier persona involucrada o afectada direc-
tamente o indirectamente por el proyecto.

Stakeholder/Cliente
En el ámbito del análisis de software, se refiere a cualquier persona involucrada o afectada
directamente o indirectamente por las condiciones que cumpla o no el sistema a ser
desarrollado o mejorado. En este caso se deben contemplar al menos tres figuras:
Clientes: Principales interesados en que el sistema sea desarrollado.

Usuario: Quienes usaran directamente el sistema.

Patrocinador: Quien decide cuanto esfuerzo o recursos se pueden asignar a la solución.

A esto hay que aclarar que los Stakeholders pueden ser una sola persona o un gru-
po muy diverso. a continuación lo explicaremos presentando tres casos hipotéticos de
proyectos a desarrollar.

3.2. Ejemplo 1: Stakeholders en un “software a la medida”

Piense en un Sistema que se pretende desarrollar como un Software a la medida de
las necesidades de una empresa. En este caso los stakeholders pueden ser:

El usuario: Serán todos los empleados que usarán el sistema, pueden ser: Directivos,
cajeros, asistentes, supervisores, etc.

5
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
El cliente: Será el director responsable del proyecto o el directivo cuya cabeza depende
de que el proyecto tenga éxito. También es quien se verá afectado directamente
de su éxito y muy probablemente no sea usuario final del sistema. En este grupo
entrarı́a también la empresa pues habrán ganancias derivadas del desempeño del
sistema.

El patrocinador: Todos aquellos dentro de la empresa que pueden influir en los recursos
(principalmente tiempo y dinero) con los que cuenta el proyecto.

En este ejemplo, el usuario es importante por que el sistema debe resolver sus proble-
mas en la operación: registrar, consultar, comprar, facturar, etc. Por otro lado, el cliente
debe resolver los problemas propios del negocio o actividad que realiza en la empresa
de manera mas general: reducir gastos, evitar pérdidas, controlar el almacén, facilitar
el control o monitoreo, etc. Por último, el patrocinador debe contemplarse por que el
debe garantizar que la solución sea factible y viable: Que se cuenten con los recursos
(tiempo y costo) propicios para el proyecto y que la solución sea mejor que inversión a
corto o mediano plazo. Como podemos ver no es posible dejar fuera a ninguno de estos
tres personajes.

3.3. Ejemplo 2: Stakeholders en un “software de licenciamiento”

Pensemos en un segundo ejemplo, suponga que el Sistema que se pretende desarrollar
es un producto que se va a vender a un grupo de terceros bajo un esquema de licencias.
En este caso los stakeholders pueden ser:

El usuario: Serán todos los posibles usuarios y que componen un segmento de mercado.
Pueden ser personas fı́sicas que adquieran el software para uso personal o que
grandes empresas las adquirirán para su uso dentro de su compañı́a.

El cliente: Será tanto la persona o empresa interesada en adquirir las licencias

El patrocinador: Todos aquellos dentro de la empresa que pueden influir en los recursos
(principalmente tiempo y dinero) con los que cuenta el proyecto.

La competencia*: Aquellos otros proveedores que venden productos similares al que

se desarrollará.

En este ejemplo, la razón por la cual se deben tomar en cuenta a las tres figuras
principales parece diferente: El usuario es por la misma razón, necesito saber de que
forma resolver sus problemas en la realización de su trabajo, pero en este caso con
la caracterı́stica de que no lo tengo a la mano como en el caso anterior. Si se desea
acceder a el será necesario buscarlo, contactarlo y encuestarlo. El cliente de la misma

6
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
forma definirá el éxito del proyecto, pues decidirı́a si comprarlo o no, solo que el no
tendrá conocimiento del producto hasta que se encuentre plenamente desarrollado, si el
sistema no “parece” resolver sus problemas de negocio no se interesará en adquirirlo.
El patrocinador decidirá en función de lo que el vendedor y el cliente le cuenten del
producto y su juicio para suponer que se puede realizar el gasto de adquisición, que sea
propicio para la empresa y que no haya una mejor oferta. En este ejemplo agregamos a
un jugador “externo” que desde el punto de vista de la administración de proyectos es
un stakeholder muy importante, y es la competencia, pues ellos tienen productos, con
caracterı́sticas y precios que competirán con nuestro sistema.
Aunque no lo hayamos mencionado todo lo anterior aplica también cuando se trata
de una sola persona comprando un antivirus, paquete de oficina, de diseño gráfico, etc.

3.4. Ejemplo 3: Stakeholders en un “software propio”

Para cerrar este estudio de los stakeholders, presentamos un último caso, y es cuando
el sistema a desarrollar es un producto interno de la organización a la que depende el
equipo de desarrollo.

El usuario: Serán todos los posibles usuarios y podrı́an ser incluso miembros del equipo
de analistas o programadores.

El cliente: Puede ser el principal director de la empresa, puede ser otro director o puede
ser el mismo lı́der del proyecto. En muchos casos ni siquiera es claro.

El patrocinador: Aunque se esperarı́a que sea el área de recursos humanos, materiales

o compras, no siempre es ası́, pues el proyecto se realiza con recursos de la empre-
sa, y personal de la misma. en este caso dependes de que se te asignen espacios,
personal, material, etc y que los recursos sean compartidos con las demás activi-
dades de la empresa. Generalmente esta figura tampoco es una y muchas veces
no está claramente definida.

En este caso la gestión del proyecto se complica mucho, pues los recursos, personal
tiempos y demás son compartidos, no hay una toma clara de desiciones y si bien todos
los jugadores están disponibles y muy juntos la organización es mucho mas difı́cil.

4. Actividades del análisis de requerimientos

Regresando a las actividades del Análisis de requerimientos, estas se dividida en varios
grupos de los cuales no existe un consenso claro, pero los conceptos que a continuación
presentamos son ampliamente aceptados en la academia y la industria.

7
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
4.1. Tipos de actividades
Toma de requerimientos: Actividades relacionadas con la obtención de requerimientos
en todas sus fases.

Análisis de requerimientos: Actividades relacionadas con identificar, relacionar, des-

componer e integrar requerimientos desde una perspectiva de problemas y necesi-
dades hacia soluciones alternativas o integrales.

Especificación de requerimientos: Actividades relacionadas con escribir o representar

modelos que capturen el alcance del sistema.

Validación de requerimientos: Actividades relacionadas a validarque la solución des-

crita o modelada resuelve dicho problema.

Administración de requerimientos: Actividades relacionadas con gestionar la informa-

ción de requerimientos para toma de desiciones.

Aunque cada uno de estos grupos de actividades es de suma importancia, esta lectura
y la mayorı́a de los libros de Ingenierı́a de Software se enfocan en las tres primeras.
Invitamos al lector a investigar al respecto. La Validación de requerimientos está siempre
mejor explicada cuando se habla de calidad de software, y es parte de la siguiente lectura.
Mientras que la Administración de requerimientos se considera mas bien un tema de
Administración de proyectos.
A continuación describimos a grandes rasgos la naturaleza de los tipos de actividades
del Análisis de Requerimientos.

4.2. Toma de requerimientos

Se refiere a obtener, constatar la importancia y validez de cada requerimiento y sobre
todo acordar de manera formal con los stakeholders cada requerimiento.
Sus principales herramientas son:

• Entrevistas con los stakeholders.

• Elaboración de prototipos.

• Investigación documental.

• Estudios de mercado.

• Observación de la operación.

• Team Kawakita Jiro.

8
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Dependiendo de la forma en que se toman requerimientos se pueden usar las diferen-
tes herramientas que se listan. Las entrevistas permiten obtener información de primera
mano, se recomienda mantener grupos pequeños o usar Team Kawakita Jiro. Un pro-
totipo ayuda a dirigir las ideas y discutir una solución propuesta sobre todo cuando las
ideas no son claras. Manuales, procedimientos, formatos, facturas, reportes, etc. son la
historia de la empresa y permite conocer muchos datos importantes para el sistema. La
observación de la operación permite validar argumentos y observar las cosas que no se
dicen en una entrevista.

4.3. Análisis de requerimientos

Se refiere a la actividad de analizar los problemas, objetivos y necesidades operacio-
nales, de negocio o corporativas de los stakeholders en relación al sistema a desarrollar
y construir un modelo o propuesta de solución viable.
Sus principales herramientas son:

• Modelado del negocio, Clasificación de información.

• Análisis FODA.

• Análisis de información.

• Análisis de problemática.

• Modelado estático y dinámico del sistema.

• Modelo arquitectónico del sistema.

• Pruebas de concepto.

El análisis es un trabajo generalmente de oficina que requiere de mucho cuidado

para tener buenos resultados. La experiencia nos dice que el análisis es un trabajo arduo,
laborioso, riguroso, minucioso y concienzudo; por lo que hay que cuidar que no sea
escaso, modesto, sobrado, impreciso o agobiante.

4.4. Especificación de requerimientos

Especificación de requerimientos
Se refiere a la actividad de modelar, capturar y comunicar efectivamente el sistema
propuesto a detalle antes de iniciar su desarrollo.
Sus principales herramientas son:

9
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Figura 1: El análisis es un trabajo arduo y concienzudo

• Especificación del modelo de negocios.

• Especificación del modelo de información.

• Casos de uso.

• CRC’s.

• Modelado dinámico y estático con UML.

Este trabajo se refiere a integrar y organizar una descripción del sistema a desarrollar.
Este trabajo incluye una gran variedad de herramientas, de las cuales la mayorı́a están
basadas en diagramas. Especı́ficamente los CRC’s y Casos de uso, son herramientas
textuales. La precisión y economı́a de lenguaje es muy importante en esta etapa, ya que
el documento resultante es utilizado por casi todo el equipo de trabajo.

5. Tipos de requerimientos
Para finalizar, daremos una definición y clasificación para los requerimientos de un
sistema. Los requerimientos son simples declaraciones pero clasificarlos nos ayudan a
comprender: como escribirlos, dónde utilizarlos, su importancia, su origen y su impor-
tancia dentro de un proyecto.

5.1. ¿Que son los requerimientos?

Requerimiento
Expresan las necesidades a cubrir por un producto o proceso. Generalmente describen
las caracterı́sticas que el diseño debe cumplir.

10
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 La IEEE lo define como “una condición o capacidad requerida por un usuario para
resolver un problema o alcanzar un objetivo”.
Estas expresiones pueden ser de muchos tipos y represadas de muchas formas. Para
aclarar un poco pongamos unos ejemplos:

• Conocer la ubicación de un vehı́culo en todo momento.

• Llevar el registro de las ventas del mes.

• Un botón en la pantalla de “venta al mostrador” para la generación de factura

electrónica.

• Agregar sensores de proximidad al vehı́culo para evitar colisiones.

• Actualizar la imagen corporativa de todas las pantallas del sistema.

• Agregar comunicación con el servidor a la app de reportes.

• Una pantalla de consultas que permita saber si el asegurado tiene al corriente los
pagos de su póliza y los servicios que cubre la misma.

• Migrar los 5TB de información de la base de datos actual a la nueva base de datos.

• Verificar en la pantalla de “Registro de cliente” que el cliente que se esté regis-

trando sea mayor de edad.

• El sistema debe tener una alta usabilida.

Si nos apegamos a la definición de la IEEE todos ellos caen dentro de la definición

de requerimiento pero algo les falta. Por un lado describen parte de un producto, alguna
capacidad o condición del sistema, aunque algunos de ellos son muy precisos y otros son
muy generales o complicados de realizar. Por el otro, los aceptamos como requerimientos
por que parece haber detrás de cada uno una necesidad u objetivo de algún usuario, sin
embargo esta no está expresada. De esta forma, siendo estrictos a la definición estos
requerimientos estarı́an incompletos.

• Conocer la ubicación de los vehı́culos en todo momento, con la finalidad de asignar

adecuadamente los traslados de mercancı́a.

• Llevar el registro de las ventas del mes para llevar el control de inventarios.

• Un botón en la pantalla de “venta al mostrador” para la generación de factura

electrónica. con la finalidad de agilizar la generación de facturas.

• Agregar sensores de proximidad al vehı́culo para evitar colisiones.

11
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 • Actualizar la imagen corporativa de todas las pantallas del sistema. Para mejorar
la imagen corporativa.

• Agregar comunicación con el servidor a la app de reportes. Para que los reportes
generados tengan información de último minuto y los vendedores en sitio puedan
tomar mejores desiciones.

• Una pantalla de consultas que permita saber si el asegurado tiene al corriente los
pagos de su póliza y los servicios que cubre la misma. Para agilizar el la atención
de siniestros via telefónica.

• Migrar los 5TB de información de la base de datos actual a la nueva base de datos.
Para que el nuevos sistema pueda operar.

• Verificar en la pantalla de “Registro de cliente” que el cliente que se esté regis-

trando sea mayor de edad. Para evitar problemas legales de dar servicios a menores
de edad.

• El sistema debe tener una alta usabilida. Para que los usuarios usen la aplicación
de manera voluntaria.

Podemos sacar algunas conclusiones. Por un lado la motivación del usuario en oca-
siones es obvia y parece no ser importante redactarla. Por otro lado, algunas de ellas,
si no se especificaban podrı́a llegarse a una solución errónea o inadecuada (en el caso
del monitoreo de vehı́culos por ejemplo, agregar la motivación ayuda comprender la im-
portancia de que el sistema contemple la capacidad de los vehı́culos y que tan vacı́os
están). A continuación daremos nombre a estas dos partes del requerimeinto.

5.2. Tipos de requerimientos

Existen muchas clasificaciones para los requerimientos, por lo que tomaremos solo
los conceptos necesarios para darnos a entender. En la sección anterior se mostró el
problema de describir la necesidad del usuario contra escribir la caracterı́stica del sistema
o ambas en una sola sentencia, esas dos partes del requerimiento tienen nombre y se
refieren solo a la forma en que se escriben.

5.2.1. Requerimientos del Usuario VS del Sistema

Requerimientos del Usuario

Sentencia que captura la necesidad u objetivo a alcanzar por un staskeholder.

Requerimientos del Sistema

12
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
Sentencia que describe una caracterı́stica o capacidad del sistema.
Ası́, un Requerimiento de Usuario debe verse reflejado en los Requerimientos del
Sistema y cada Requerimiento del Sistema proviene de una necesidad o Requerimiento de
Usuario. Llevar el control de la relación existente entre Requerimientos del usuario y del
sistema hasta los artefactos de programación se llama Trazabilidad de requerimientos.
Cuales requerimientos se deben escribir y como deben organizarse en un documento
es una cuestión de estilo que depende: de las capacidades del equipo de desarrollo, las
caracterı́sticas del proyecto, la madurez del negocio, el tiempo que se pueda invertir en
ello y la metodologı́a de desarrollo. Sin embargo, la Trazabilidad de los requerimientos
es un asunto de vital importancia para la gestión de proyectos grandes y es un tema de
la siguiente lectura. Describir los requerimientos del usuario junto con los del sistema
puede ser un trabajo muy arduo, pero omitirlos puede llevar a graves equivocaciones la
final del proyecto, como siempre es la experiencia y madurez del equipo de trabajo los
que duran cual es la mejor opción.
La segunda clasificación de requerimientos que veremos tiene que ver con la natura-
leza de los requerimientos del sistema.

5.2.2. Requerimientos Funcionales VS No Funcionales

Requerimientos funcionales
Son los que describen una función del sistema. Generalmente se refieren a cálculos,
detalles técnicos, manipulación o procesamientos especı́ficos.
Requerimientos no funcionales
Describen formas especı́ficas en que los requerimientos funcionales deben realizarse.
Generalmente se convierten en criterios para evaluar la forma en que los requerimientos
funcionales deben operar.
Esta clasificación es importante para la etapa de análisis, ya que dependiendo del tipo
de requerimiento el proceso de análisis es distinto. Los requerimientos no funcionales
son tratados con especial cuidado en el análisis.

5.3. Tipos de Requerimientos No Funcionales

Los Requerimientos No Funcionales tienen muchas clasificaciones. Algunos los clasi-
fican de acuerdo a si describen el producto, su plataforma, sus propiedades, su calidad,
etc. Lo que sı́ es un hecho es que en los últimos años el análisis y modelado del nego-
cio ha tomado un papel muy importante en todas las organizaciones y permite alinear
las TIC’s con las estrategias y metas organizacionales. En esta lectura presentamos
una clasificación que nos permite agrupar los requerimientos no funcionales en grupos
fácilmente manejables durante el análisis.

13
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
Del Negocio: Todos los requerimientos que provienen del comportamiento propio de la
organización, del negocio o de la operación del usuario.

De Interacción con el usuario: Todo lo relacionado con la forma en que el sistema

interactúa con los usuarios.

De plataforma: Todo lo relacionado con Hardware, Software, Servicios y otros sistemas

con los que interactuar el sistema.

De información: Todos los elementos de información que debe manejar el sistema.

De propiedades No funcionales de software: Propiedades de software.

Esta clasificación nos sirve pues podemos modelar un sistema aplicando diferentes
técnicas. Por ejemplo, para capturar, analizar o modelar todos los requerimientos del
negocio s pueden usar técnicas de arquitectura de negocios, Las de interacción con el
usuario técnicas de modelado de interfaces y dispositivos de entradas y salidas. Los de
plataforma mediante el diseño arquitectónico del sistema. El de información median-
te esquemas de modelado de información y las propiedades de software generalmente
se modelan mediante la definición y aplicación de técnicas avanzadas y métricas de
software.
Por último, no se debe olvidar que cada Requerimiento No Funcional puede afecta
a todos los demás, esta parte del análisis es la mas compleja y no se deben tomar a la
ligera.

5.4. Propiedades de Software

Las propiedades de software se refieren a las caracterı́sticas del software como pro-
ducto. Existen mas de 50 nombres para los requerimientos no funcionales relacionados
con propiedades de software, de los cuales podemos enunciar algunos.

Propiedades no funcionales de software

• Accessibilidad

• Disponibilidad

• Capacidad, actual y taza de crecimiento

• Certificación

• Despliegabilidad

14
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 • Eficiencia

• Efectividad

• Explotabilidad

• Robustez

• Tolerancia a fallos

• Estabilidad

• Extensibilidad

• Mantenibilidad

• Operabilidad

• Desempeño

• Precio

• Privacidad

• Portabilidad

• Calidad

• Recuperabilidad

• Confiabilidad

• Reusabilidad

• Seguridad

La forma de lidiar con cada una de ellas es muy particular y requiere de la aplicación
de distintas ramas de la computación. Ası́, mismo recordamos que cada una de estas
propiedades afectan directamente a la mayorı́a de los requerimientos funcionales por lo
que no pueden tratares por separado ni al final del desarrollo.

15
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Figura 2: Clasificación de requerimientos.

6. Resumen de la lectura
El análisis de requerimientos es un trabajo difı́cil que puede involucrar muchas ac-
tividades dependiendo de la naturaleza de cada proyecto. Presentamos cinco de los
principales grupos de actividades en el análisis como se puede ver en la figura ??
Los requerimientos son sentencias sobre las caracterı́sticas del sistema y se subdivi-
den en requerimientos de usuario y del sistema, y estos ñultimos en Funcionales y no
funcionales como se puede ver en las figuras 25 y 26.
Los requerimientos no funcionales representan un conjunto mas grande que solo las
propiedades no funcionales de software.
Varios autores presentan diferentes clasificaciones para los requerimientos no fun-
cionales. Sommerville en particular presenta una clasificación orientada al origen de los
requerimientos, sin embargo todos los requerimientos mencionados en esa y otras clasi-
ficaciones pueden caber aquı́.

Referencias
[1] Ian Sommerville. “Ingenierı́a de software”. México. Pearson education.

16
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Figura 3: Clasificación de requerimientos.

[2] Roger Pressman. “Ingenierı́a de software, Un enfoque práctico”. México. Pearson educa-
tion.

[3] Shari Lawrence Pfleeger. “Ingenierı́a de software”. México. Pearson education, 2a Ed.

[4] Frank Tsui. “Ingenierı́a de software”. México. Pearson education, 2a Ed.

[5] Frank Tsui. “Software Project Management”. México. Pearson education, 2a Ed.

[6] Grady Booch. “El Lenguaje Unificado de Modelado”. México. Pearson education.

17
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com
 Figura 4: Relaciones entre los requerimientos.

18
Av. Juan de Dios Bátiz esq. Miguel Othón de Mendizabal S/N Col. Lindavista, GAM, D. F.T 57296000 Ext. 52032 B ulises.velez@gmail.com