Capitulo 5 Requerimientos - Mayo - 2014

INGENIERÍA DE PROYECTOS
EN INGENIERÍA ELECTRÓNICA
Programa de Ingeniería Electrónica
Mayo 2014 ISBN XXXX-XXXX
CAPÍTULO 5
REQUERIMIENTOS
Fabio Téllez Barón

Ernesto Sabogal Gómez
Óscar Arias Ballén
Requerimientos |3
Ingeniería de Proyectos en
Ingeniería Electrónica
Universidad El Bosque
4| Requerimientos
Requerimientos |5
Ninguna parte de esta obra puede ser reproducida o

transmitida mediante ningún sistema o método, electrónico o
mecánico -incluyendo el fotocopiado o cualquier sistema de
recuperación y almacenamiento de información-, sin
consentimiento escrito del editor.
6| Requerimientos
Tabla de Contenido
1. Definiciones ........................................................................................ 11
Requerimiento.............................................................................. 11
Usuario ......................................................................................... 12
Lenguaje ....................................................................................... 12
Necesidades y características....................................................... 13
Tipos de requerimientos .............................................................. 13
1.5.1 Requerimientos funcionales................................................. 13
1.5.2 Requerimientos de calidad................................................... 14
1.5.3 Requerimientos de restricción ............................................. 14
Errores comunes .......................................................................... 14
2. Requerimientos y pruebas ............................................................... 16
2.1 Introducción ................................................................................. 16
2.2 Proceso de desarrollo................................................................... 16
2.3 Fases de desarrollo ....................................................................... 18
2.4 Modelo en V ................................................................................. 19
2.3.1 Requerimientos ........................................................................... 20
2.3.2 Pruebas ........................................................................................ 20
2.3.3 Modelo ........................................................................................ 20
3 Sistema ................................................................................................. 23
Definición ..................................................................................... 23
Características .............................................................................. 23
Ejemplo de un sistema ................................................................. 25
3.3.1 Entorno ................................................................................. 25
3.3.2 Interfaces.............................................................................. 27
Requerimientos |7
3.3.3 Requisitos ............................................................................. 28

3.3.4 Resumen ............................................................................... 29
4.Metodología propuesta ......................................................................... 31
4.1 Metodología ................................................................................. 31
4.1.1 Definición básica del sistema ............................................... 31
4.1.2 Complementar las características de la entrada y la salida . 32
4.1.2 Complementar las características del sistema ..................... 33
5.2 Resumen ............................................................................................. 35
5. Ejemplos sobre la metodología propuesta ..................................... 37
5.1 Licuadora ...................................................................................... 37
5.2 Agua potable ................................................................................ 40
6. Cómo escribir requerimientos ......................................................... 43
6.1 Introducción ................................................................................. 43
6.2 Requerimientos clave ................................................................... 43
6.3 Organización................................................................................. 44
6.4 Propiedades de los requerimientos ............................................. 44
6.5 Criterios de depuración ................................................................ 46
6.6 Estructura ..................................................................................... 46
6.6.1 Verbos utilizables ................................................................. 46
6.6.2 Uso de estructuras ............................................................... 47
6.7 Errores comunes .......................................................................... 48
7. Procedimiento .................................................................................... 51
8. Otros requerimientos ........................................................................ 55

8.1 Manuales ...................................................................................... 56
8.1.1 Manual de instalación .......................................................... 56
8.1.2 Manual de operaciones ........................................................ 57
8| Requerimientos
8.2 Documentos ................................................................................. 57

9. Comité de Proyectos y los Requerimientos ................................... 59
Requerimientos |9
Este capítulo se presenta en forma estructurada para definir y
concretar los requerimientos que debe cumplir una solución,
hardware y/o software, sin hacer diseño ni seleccionar tecnologías; se
refiere, en especial, a aquellos proyectos a los que se enfrenta un
ingeniero electrónico.
Una de las grandes dificultades que tienen los alumnos de
pregrado, y los recién egresados, es la elaboración precisa de los
requerimientos que debe cumplir una solución de ingeniería. Es
frecuente que se elaboren en forma ambigua e insuficiente, y que se
seleccionen tecnologías.
La definición incorrecta de los requerimientos lleva a que la
posible solución no sea la prevista por el usuario final. Incluso puede
ocasionar pleitos futuros, innecesarios, entre éste y el diseñador de la
solución.
Los requerimientos nacen con los aspectos a solucionar del
problema; tienen en cuenta la propuesta de solución, el producto previsto,

10 | R e q u e r i m i e n t o s
y los objetivos general y específicos. Su elaboración debe buscar una
solución funcional de los aspectos a solucionar del problema.
La estructura para elaboración y redacción de requerimientos,
propuesta en este capítulo, se basa en: definiciones, procedimientos,
tablas y formatos.
Una vez que se explica la metodología, se presentan varios
ejemplos. Estos se orientan al uso de aquella, por lo que se presentan
los pasos en detalle hasta llegar a la redacción final de los
requerimientos.
Por último y, para claridad de los estudiantes del Programa de
Ingeniería Electrónica de la Universidad El Bosque, se indican los
mínimos que debe tener el capítulo de requerimientos para que este
sea aprobado por el Comité de Proyectos e Investigación.

1. Definiciones
Para elaborar los requerimientos es fundamental hacer claridad
sobre algunos conceptos que se utilizan a lo largo de este documento.
Puede haber otras definiciones, pero en este contexto las entendemos
como están a continuación.
Requerimiento
Un requerimiento es una condición que debe satisfacer el
bien/servicio a construir para resolver un problema; puede ser una
necesidad que debe cumplirse, o una restricción que debe satisfacerse
para el cliente.
Los requerimientos conducen a un producto orientado a corregir
algunas de las causas detectadas en el problema; se espera que la
solución minimice los efectos y las manifestaciones.
Lo primero que se debe advertir es que no es necesario elaborar
todos los requerimientos simultáneamente. Así, en el Anteproyecto se
consideran sólo los requerimientos funcionales; los otros,
relacionados con los subsistemas y componentes, se tratarán en el
momento de hacer el Diseño –funcional y detallado-.

Los requerimientos deben estar relacionados directamente con el
producto a entregar. Así, pues, deben considerar:
 El tipo de proyecto o estudio
 El entregable (producto a entregar)
 Los objetivos generales y específicos
 Las necesidades de los usuarios
Además, la solución debe ser:
 Realizable en un tiempo determinado
 Realizable desde la disciplina del conocimiento
 Viable (se tengan los recursos necesarios)
 Relevante (de interés para la Universidad, sociedad,
empresa y/o ambiente)
Usuario
Los requerimientos deben satisfacer las necesidades de los
usuarios, por completo y sin ambigüedades.
Ahora bien, se entiende por usuario a quien requiere el sistema
para solucionar un problema; además, lo valida y lo utiliza.
Lenguaje
Los requerimientos deben ser entendidos tanto por los usuarios
como por los desarrolladores; muestran a ambos qué es lo que se
requiere de un sistema (proceso). Con este fin, se utiliza el lenguaje
natural. Se debe evitar el uso de lenguaje especializado.

Requerimientos | 13
Necesidades y características
Se hace diferencia entre necesidades y características,
entendiendo que las necesidades son las exigencias que hacen los
usuarios y que las características son las respuestas que da el sistema
a esas necesidades.
Tipos de requerimientos
Los requerimientos pueden clasificarse de muchas maneras. En
forma genérica podrían dividirse entre funcionales y no funcionales.
Donde:
 Funcionales: responden a la pregunta ¿qué hace el
sistema?
 No funcionales: describen aspectos del sistema
apreciables por el usuario pero que no tienen una
relación directa con el comportamiento funcional de
aquel. Por ejemplo: tiempos de respuesta, seguridad,
precisión, solicitudes tecnológicas específicas de los
usuarios, etc.
Dentro de este documento los clasificaremos en tres tipos:
funcionales, de calidad y de restricción.
1.5.1 Requerimientos funcionales
Responden a la pregunta ¿qué hace el sistema? Son sus
funciones, lo que hace éste.

Describen la interacción entre el sistema y su entorno. Son
independientes de la tecnología, de la implementación
El entorno incluye a los usuarios y a los demás sistemas externos
que interactúen con el sistema en cuestión –ver capítulo 2-.
1.5.2 Requerimientos de calidad
Son aquellos que tienen parámetros que indican precisión y
exactitud. También, el tiempo al aire de un servicio o sistema de
telecomunicaciones.
La calidad no debe confundirse con el lujo; es el cumplimiento
de las necesidades de los usuarios.
1.5.3 Requerimientos de restricción
Son aquellos que limitan al sistema. Las restricciones pueden
estar relacionadas con:
 Normas o recomendaciones.
 Con la ética.
 Con el medio ambiente.
 O con solicitudes del cliente –usuario-.
Errores comunes
Es importante aclarar que en este nivel los requerimientos deben
ser independientes de la tecnología o productos existentes en el

R e q u e r i m ie n to s | 15
mercado. Algunos de los errores más comunes al describir los
requerimientos son:
 Indicar con qué se va a realizar la solución
 Orientar desde un principio la solución a una tecnología
particular
 Proponer soluciones irrealizables (no se tienen los
recursos, tecnología o conocimientos)
 Hacer especificaciones ambiguas

2. Requerimientos y pruebas
2.1 Introducción
Los requerimientos tienen una relación directa con el ciclo de
vida de un producto. Se desarrollan en varias fases: a) en el
Anteproyecto (requerimientos funcionales); y b) en el Diseño
(requerimientos de subsistema y requerimientos de componentes).
Los requerimientos afectan el costo-beneficio total del producto;
por lo tanto, hay que tenerlos presentes durante todas las fases de
desarrollo del producto.
El producto desarrollado debe cumplir con los requerimientos
solicitados. Su prueba se realiza cuando se va a entregar el sistema.
Este capítulo muestra la relación entre los requerimientos y sus
respectivas pruebas.
2.2 Proceso de desarrollo
Los requerimientos surgen inicialmente de los usuarios de la
empresa que tiene el problema quienes plantean sus necesidades en
lenguaje natural.
Luego son tomados por los ingenieros que tienen a cargo la
elaboración del documento de planeación (Anteproyecto), quienes los
analizan, separan, agregan y modifican su redacción para darles
consistencia, integridad y precisión, sin cambiar el sentido inicial
dado por los usuarios.
A continuación son revisados por los usuarios quienes buscan
que sus necesidades no hayan sido alteradas. Si existe un acuerdo
surge el documento de Requerimientos Técnicos que hace parte de una
licitación.
El desarrollador del producto (contratista) normalmente es otra
empresa dedicada a esta labor, que se presenta a la licitación
organizada por la empresa cliente. Cuando se define el ganador de la
licitación se firma un contrato.
Entonces el desarrollador analiza las necesidades de los usuarios,
las revisa, discute y acuerda con ellos los requerimientos definitivos.
A partir de ese momento, orientan a las demás actividades del
proyecto. (Ver figura 2.1).
Finalmente, cuando el desarrollador entrega el producto al
usuario, éste le efectúa las pruebas de aceptación con base en los
requerimientos.
EMPRESA
CLIENTE DESARROLLADORA CLIENTE
Documento de
Estudio del
Requerimientos
problema a Requerimientos
solucionar
Documento de
especificaciones
Especificaciones
Devolución
Doc. Requerimientos
Documento
de Diseño
Rechazo Diseño
Documento de
Especificaciones Documento de
Implementación
Implementación
Rechazo de
Documento de Diseño
Documento de
Pruebas Pruebas
Rechazo de Documento
de Pruebas
Pruebas de
aceptación
Doc. de Rechazo de
Pruebas de Aceptación
Rechazo Puesta en Op.
Fig. 2.1. Ciclo de vida de un producto
Si los resultados están conformes con los requerimientos, se
acepta el producto y se inicia la fase de operación.
2.3 Fases de desarrollo
Los requerimientos no se establecen totalmente en la etapa de

planeación del proyecto –Anteproyecto- pues habría que entrar a hacer
prediseño. En esta etapa sólo se levantan las necesidades de los usuarios y
se establecen los requerimientos funcionales del sistema.
Los otros requerimientos deben elaborarse en detalle cuando se haga

la fase de diseño –funcional y detallado-. Estos otros requerimientos se
conocen como requerimientos de los subsistemas -entendidos como los
módulos que se proponen en la solución que se adopte- y como
requerimientos de sus componentes. Se hace así porque durante la fase de
Requerimientos | 19
diseño se puede evaluar mejor la incidencia de los requerimientos sobre el

costo-beneficio del sistema. (Ver figura 2.1).
En la fase de Planeación, sin entrar a diseñar, sí se puede establecer su

entorno, su finalidad básica, y sus entradas y salidas; es decir, los
requerimientos funcionales.
En este sentido, lo apropiado es tomar en forma abstracta al sistema

como una gran caja negra con sus funciones (¿Qué debe hacer?). Esta caja
negra tiene entradas y salidas que la conectan con el mundo externo. Esta
aproximación se muestra en la figura 2.2.
Entrada 1 Salida 1
Entrada 2 Salida 2
Entrada 3 FUNCIONES DEL SISTEMA Salida 3
Entrada n Salida m
Figura 2.2 Requerimientos funcionales, como un todo
2.4 Modelo en V
Los primeros requerimientos que se fijan son los requerimientos

funcionales. También existen requerimientos para los subsistemas y para
los componentes. Todos estos requerimientos deben ser probados por los
usuarios; cada tipo tiene sus pruebas respectivas
En la figura 2.3 se muestra el modelo en V que relaciona los niveles de

los requerimientos con los niveles en que se hacen las pruebas; estas se
realizan entre pares.
2.3.1 Requerimientos
Para establecer los requerimientos se sigue un procedimiento de

arriba-abajo, de más a menos, que incluye cuatro niveles, a saber:
 Nivel de usuario
 Nivel del sistema
 Nivel de subsistemas
 Nivel de componentes
2.3.2 Pruebas
Los requerimientos no son opcionales, hay que cumplirlos; por eso se

deben probar. Las pruebas se efectúan en sentido inverso a como se
establecieron los requerimientos; es decir, de abajo-arriba, de menos a
más:
 Pruebas de componentes
 Pruebas de integración
 Pruebas del sistema
 Pruebas de aceptación
2.3.3 Modelo
El conjunto de etapas de requerimientos y de pruebas conforman un

modelo conocido como Modelo en V, donde cada nivel de requerimientos
tiene su par correspondiente de pruebas (ver figura 2.3).
Por el lado izquierdo, de arriba-abajo, están las etapas de

requerimientos orientadas por las necesidades de los usuarios. Por el lado
Requerimientos | 21
derecho, de abajo-arriba, están los tipos de pruebas que deben llenar los
requerimientos de los usuarios.
El Modelo en V muestra que los requerimientos se inician teniendo en

cuenta las necesidades de los usuarios. A partir de estas necesidades se
establecen los requerimientos del sistema, de los subsistemas y de los
componentes en un procedimiento arriba-abajo, que cubre cuatro niveles.
REQUERIMIENTOS PRUEBAS
Requerimientos Pruebas de
de usuario aceptación
Requerimientos Pruebas del

del sistema sistema
Requerimientos de Pruebas de
subsistemas integración
Requerimientos de Pruebas de
componentes componentes
Fig. 2.3. Requerimientos versus pruebas
En forma similar, cuando se realizan las fases de implementación y

prueba se sigue un proceso inverso que se inicia a nivel de los
componentes, sigue con cada uno de los subsistemas -y su integración-,
hasta llegar al sistema completo. En ese momento se llama a los usuarios

para que efectúen las pruebas de aceptación.
En resumen, se puede observar que:
 Al nivel de usuarios primero se definen los resultados
esperados –necesidades-; después, en su etapa par, se
hacen las pruebas de validación del producto.
 A nivel del sistema se define lo que se debe hacer;
después, en su etapa par, se hacen las pruebas para
verificar que el sistema sí lo hace.
 A nivel de los subsistemas se limitan los requerimientos
para la optimización del costo-beneficio. Después se
prueba el cumplimiento de esos requerimientos.
 A nivel de los componentes se especifican los
requerimientos que valoren su calidad; después se prueba
que los componentes cumplan con la calidad solicitada.

Requerimientos | 23
3 Sistema
Definición
Por sistema se entiende el conjunto de componentes hardware y
software, y un grupo de personas que interactúan con aquellos en
forma coordinada para satisfacer unos resultados esperados
(requerimientos).
Las funciones que realiza el sistema, lo que hace, son la esencia
del mismo. Esas funciones y las interfaces externas constituyen el
sistema.
Las funciones del sistema pueden ser realizadas por diferentes
componentes básicos, en hardware y/o software.
Características
Las propiedades del sistema tienen que ser deseables, en el
sentido de que deben haberse previsto y en que el sistema, además, se
diseña para que sea útil. También se deben evitar aquellas

características que son indeseables. Es decir, los requisitos del sistema
deben señalar lo que se quiere y lo que no se quiere.
Una particularidad a tener en cuenta en un sistema es que,
normalmente, éste hace parte de un sistema más grande que lo
incluye. Así, por ejemplo, el sistema de telecomunicaciones de
Movistar Colombia incluye:
 Al subsistema que comunica a Bogotá y Barranquilla,
 A todos los demás subsistemas de Movistar en el país.
 Todo el sistema de Movistar Colombia hace parte del
sistema de comunicaciones nacionales de Colombia.
 El conjunto de sistemas de comunicaciones de todos los
operadores que prestan servicios en el territorio nacional
conforman el sistema nacional de comunicaciones de
Colombia.
 Y así sucesivamente, hasta llegar al sistema mundial de
comunicaciones.
En ese contexto, existen interfaces entre esos sistemas
particulares para que el sistema global trabaje como un todo; no se
puede evitar ese contexto. Es decir, habitualmente los sistemas no
trabajan en forma aislada.
Otra característica de un sistema es que los requerimientos se
satisfacen cuando cada uno de sus componentes cumple con sus

Requerimientos | 25
propios requisitos. Es decir, el conjunto de componentes básicos debe
actuar como un todo –sistema-.
También, hay que considerar que:
 La capacitación y los procedimientos que siguen los
operadores y/o usuarios de los diferentes componentes
básicos son tan importantes como el hardware y el
software del sistema.
 Las interfaces entre los componentes básicos y con los
sistemas externos son muy importantes.
Ejemplo de un sistema
3.3.1 Entorno
Para entender bien los requerimientos de un sistema hay que
comprender su entorno. Tomemos el ejemplo de una casa.
Esta es usada especialmente para las actividades y relaciones
familiares. Sirve de refugio contra la lluvia, el viento y demás agentes
meteorológicos, y protege a sus habitantes de posibles intrusos y de
los animales.
La casa es un todo; pero es evidente que tiene tres grandes
componentes que, al entenderlos, ayudan a establecer los
requerimientos del todo. Estos componentes son: a) la estructura; b)
el contenedor; y c) el conjunto de habitaciones. Pero ¿para qué sirve
cada uno?:
 La estructura para soportar el edificio y fijarlo al terreno.
También para aislarlo de la humedad del suelo.
 El contenedor sirve para encerrar y proteger el interior del
edificio, que alberga personas y las resguarda de los
elementos de la naturaleza y de los intrusos.
Aísla la casa del ruido y la temperatura externos.
Está constituido por techo, muros de cerramiento,
puertas y ventanas.
 Las habitaciones para alojar a las personas y para
otorgarles comodidad, privacidad y seguridad.
Ahora bien, la forma correcta de hacer requerimientos es poner
esas necesidades en forma de funciones que contesten la pregunta
¿qué hace la casa? Así, en primera instancia, se tiene:
 La estructura debe soportar al edificio y fijarlo al terreno.
 La estructura debe aislar al edificio de la humedad del
suelo.
 El contenedor debe resguardar a las personas y a los
enseres de los elementos de la naturaleza.
 El contenedor debe proteger a las personas de los intrusos
y de los animales.
Requerimientos | 27
 El contenedor debe aislar el interior de la casa del ruido y
de la temperatura externos.
 Las habitaciones de la casa deben otorgar comodidad,
privacidad y seguridad a las personas.
Sin embargo, en su forma final se debe involucrar ya a la casa como
un todo teniendo en cuenta a sus residentes. Entonces se tiene:
 La casa debe cumplir con la norma antisísmica vigente.
 La casa debe aislar a sus habitantes y enseres de la
humedad del suelo.
 La casa debe resguardar a las personas y a los enseres de
los elementos de la naturaleza.
 La casa debe proteger a las personas de los intrusos y de
los animales.
 La casa debe aislar a sus residentes del ruido y la
temperatura externos.
 La casa debe otorgar comodidad y privacidad a sus
residentes.
3.3.2 Interfaces
Pero la casa está llena de interfaces externas, servicios, tales
como:
 El sistema hidráulico que facilita el acceso al agua potable
ofrecida por la municipalidad;

 El sistema eléctrico que facilita el acceso a la energía para
que todos los electrodomésticos puedan funcionar;
 El sistema de comunicaciones que facilita el acceso a los
sistemas de voz, datos y video;
 El sistema de alcantarillado que facilita la recolección y
encausamiento de las aguas lluvias y aguas negras que
emanen de la casa;
 El sistema urbanístico, relacionado con el conjunto de
elementos que se instalan alrededor de la casa, como la
pavimentación exterior, el alumbrado externo, las aceras,
las alcantarillas, etc.
Además, se pueden hacer otras observaciones:
 La casa no es buena en sí misma. Depende de sus
habitantes, del acceso a los servicios básicos y del buen
uso que se haga de ella.
 La casa requiere de un mantenimiento continuo para
evitar su deterioro; tanto en su exterior como en su
interior.
3.3.3 Requisitos
Finalmente, para que una casa cumpla su propósito depende de:
 Las propiedades de cada uno de sus componentes;

Requerimientos | 29
 Las propiedades que surgen de la interacción de sus
componentes;
 Las interfaces apropiadas con los sistemas externos;
 La adaptación correcta con su entorno – zona tórrida, zona
polar, zona septentrional, etc.-, según el sitio donde se
ubique la vivienda. Cada ambiente específico plantea
requerimientos diferentes, incluyendo a sus habitantes.
En consecuencia, para elaborar los requerimientos de una casa
hay que tener en cuenta:
1. A la casa como un todo;
2. A cada uno de sus componentes básicos;
3. A las interfaces con los diferentes sistemas externos;
4. Y a las interfaces con los residentes.
3.3.4 Resumen
Todos los elementos citados anteriormente son fundamentales en
el momento de establecer los requerimientos.
Pero existen dos aspectos esenciales que siempre hay que tener
en cuenta:
 Al hacer requerimientos no hay que hacer diseño.
 Al fijar los requerimientos hay que tener en cuenta el
costo-beneficio.
Por lo tanto, al elaborar los requerimientos, los ingenieros deben
tener en cuenta la naturaleza de los sistemas. Merecen
consideraciones especiales aquellos requisitos que surgen del sistema
como un todo; las restricciones y disposiciones del entorno externo; y
las interfaces con los sistemas que lo rodean.

4.Metodología propuesta
4.1 Metodología
La metodología se puede dividir en tres grandes etapas, a saber.
4.1.1 Definición básica del sistema
La metodología propuesta debe llevar en forma rápida a señalar
qué hace el sistema. Con este fin, se deben considerar cuatro pasos
básicos fundamentales:
1. ¿Qué entrega el sistema? Es decir, ¿cuál es su producto
esencial?
2. ¿Qué insumo básico debe haber en la entrada para
obtener el producto de salida?
3. ¿Cuál es la función básica del sistema? Es decir, ¿cómo se
transforma la entrada en salida?
4. ¿Qué hace el sistema en forma fundamental? Es decir,
¿cómo puedo unir la función con la entrada para obtener
el entregable?
Veamos cómo queda el ejemplo de un asadero de pollos:

 El producto básico del sistema es un pollo asado.
 El insumo de entrada es un pollo crudo.
 La función fundamental del sistema es asar.
 Así se tiene que: El sistema debe asar un pollo crudo.
Esto es lo que hace el sistema en esencia.
Al final de estos cuatro pasos de la metodología ya se sabe qué es
lo que hace fundamentalmente el sistema. Cuál es su producto, cuál
es su entrada y qué es lo que hace en forma básica.
4.1.2 Complementar las características de la entrada y la salida
A continuación vienen otros pasos que complementan la
información básica ya obtenida.
5. ¿Cuáles son las características complementarias del
producto de salida?
6. ¿Cuáles son las características adicionales del insumo de
entrada?
7. Ahora se puede unir el insumo entrante con todas sus
características y la función para obtener el producto de
salida.
8. Finalmente se enlazan las características del insumo de
entrada con la función y con las características del
producto resultante.
Veamos cómo queda el ejemplo del asadero de pollos:

Requerimientos | 33
 Pollo crujiente por fuera pero húmedo por dentro, la
carne no debe tener zonas rojas o rosas que indiquen baja
cocción, la piel debe saber a carbón pero no a quemado.
 Pollo crudo entero, desplumado, lavado, sin vísceras con
un peso entre 500 g y 2 kg
 El sistema deberá asar un pollo crudo entero,
desplumado, lavado, sin vísceras, con un peso entre 500 g
y 2 kg.
 El sistema deberá asar un pollo crudo entero,
desplumado, lavado, sin vísceras, con un peso entre 500 g
y 2 kg, de tal manera que pollo asado sea crujiente por
fuera pero húmedo por dentro, la carne no debe tener
zonas rojas o rosas que indiquen baja cocción, la piel debe
saber a carbón pero no a quemado.
Mediante estos pasos adicionales se han definido las
características del producto saliente y del insumo entrante. Ya se tiene
más información del producto y del insumo.
4.1.2 Complementar las características del sistema
Ahora se definen la producción del sistema en el tiempo, sus
cualidades y las desviaciones permitidas.
9. Cuantificar la salida en el tiempo.
10. Cuantificar el margen de error o desviación que se
permite a la salida.
11. Concretar las cualidades del producto.
12. Cuantificar la desviación de las cualidades del producto
Veamos cómo queda el ejemplo del asadero de pollos.
 Se cuantifica la salida
Fig. 4.1 Cuantificación de la salida
Entrada Salida Función Cuantificación de

la salida
Pollo crudo entero, Pollo asado crujiente por Asar 200 pollos asados
desplumado, lavado, sin fuera pero húmedo por por hora
vísceras, con un peso dentro, la carne no debe
entre 500 g y 2 kg tener zonas rojas o rosas
que indiquen baja
cocción, la piel debe
saber a carbón pero no a
quemado
 Se cuantifica la desviación permitida a la salida
Fig. 4.2 Desviación de la producción
Cuantificación de la salida Desviación (cantidad) Desviación %

200 pollos asados por hora -2 pollos por hora 1%
 Se hace un listado de las cualidades del producto
Fig. 4.3 Cualidades del producto
Producto Cualidad
Pollo  Piel  Crujiente al morder
 Humedad interna  Superior al 20%
 Color carne  Blanco
 Sabor piel  Carbón
Requerimientos | 35
 Se cuantifica la desviación de las cualidades del producto

Fig. 4.4 Desviación de las cualidades
Cualidad
 Piel  Crujiente al morder  2% pollos no crujientes
 Humedad interna  Superior al 20%  Inferior 20% para 1%

de los pollos
 Color carne  Blanco  Puntos rojos o rosados
7% pollos
 Sabor piel  Carbón  Sabor a quemado
menor a 4% pollos
5.2 Resumen
En forma fundamental se ha seguido una metodología, de menos
a más, que establece rápidamente qué hace el sistema. Posteriormente
se complementaron sus características de entrada y salida.
Finalmente, se establecieron su producción y sus desviaciones.
Así, en esa forma rápida, cualquier lector entenderá qué es lo
que hará el sistema.
Falta seguir otras etapas para llegar a obtener requerimientos de
calidad; es decir, a mejorar el resultado que ya se ha obtenido. Esto se
verá en los próximos capítulos.

5. Ejemplos sobre la metodología
propuesta
A continuación se muestran dos ejemplos que utilizan la
metodología vista en el capítulo anterior. El primero trata sobre una
licuadora y el segundo sobre agua potable.
5.1 Licuadora
1. Iniciar por la salida del sistema; o por lo que debe dar o
entregar el sistema.
Jugo de fruta
2. Identificar qué necesita ingresar al sistema para obtener la
salida o resultado.
Fruta
3. Se debe enlazar, con una función, cómo es la transformación de
la entrada a la salida.
Licuar
4. Teniendo lo anterior, se une de tal manera que se expresa el
producto entrante y la función que lo convertirá en el producto
saliente.
El sistema deberá licuar fruta.
5. Ahora se debe preguntar sobre las características del producto
resultante.
El jugo debe ser lo más líquido posible, puede
mantener algo de fibra pero las partes sólidas no
deberán superar un tamaño de 0.1 mm.
6. Se repite lo mismo para el producto entrante.
Fruta de tamaño no superior a 8 cm3
7. Teniendo lo anterior, se une de tal manera que se expresa el
producto entrante y la función que lo convertirá en el producto
saliente.
El sistema deberá licuar fruta de tamaño no superior a
8 cm3.
8. Adicionar las condiciones del producto resultante
El sistema deberá licuar fruta de tamaño no superior a
8 cm3; el jugo debe ser lo más líquido posible, puede
mantener algo de fibra pero las partes sólidas no
deberán superar un tamaño de 0.1 mm.

9. Identificar la entrada, la salida y la función y cuantificar la
salida en el tiempo

la salida
Fruta de tamaño no El jugo debe ser lo más Licuar 100 litros/hora
superior a 8 cm3 líquido posible, puede jugo
mantener algo de fibra
pero las partes sólidas no
deberán superar un
tamaño de 0.1 mm
10. Desviación de la cuantificación de la salida, se indica qué
margen de error o desviación se permite a la salida
Fig. 5.2 Desviación de la cuantificación

100 litros/hora jugo -5 litros por hora 5%
11. Hacer un listado de las cualidades del producto
Producto Cualidad
100 litros/hora jugo  Tamaño partes  Menor a 0.1 mm

sólidas
12. Desviación de las cualidades del producto
Fig. 5.4 Desviación de las cualidades
Cualidad
 Fibra  Tamaño partes sólidas  5% de litros de jugo

con partes sólidas

mayor a 0.1 mm
5.2 Agua potable
1. ¿Qué debe entregar el sistema?
Agua potable
2. ¿Qué se debe ingresar al sistema para obtener el resultado?
Agua
3. ¿Con qué función (verbo) se obtiene la transformación de la
entrada a la salida?
Potabilizar
4. ¿Qué hace el sistema?
El sistema deberá potabilizar agua.
5. ¿Qué características adicionales debe tener el producto
resultante?
El agua debe ser inodora, sin turbiedades, cumplir con
la norma Resolución 2115 de 2007 del Invima.
6. ¿Qué características adicionales debe tener el insumo de
entrada?
Agua sin concentración de metales pesados, barros
inferiores a 1000 ppm, cualquier nivel de protozoos y
bacterias
7. Así, se tiene que:
El sistema deberá potabilizar agua sin concentración
de metales pesados, barros inferiores a 1000 ppm y con
cualquier nivel de protozoos y bacterias.
8. Adicionando las condiciones del producto resultante se
tiene:
El sistema deberá potabilizar agua sin concentración
de metales pesados, barros inferiores a 1000 ppm y con
cualquier nivel de protozoos y bacterias; el agua
resultante debe ser inodora, sin turbiedades, cumplir
con la norma Resolución 2115 de 2007 del Invima.
9. Identificar la entrada, la salida y la función y cuantificar la
salida en el tiempo

la salida
Agua sin concentración Agua resultante debe ser Potabilizar 1 metro cúbico
de metales pesados, inodora, sin turbiedades, hora
barros inferiores a 1000 cumplir con la norma
ppm y con cualquier nivel Resolución 2115 de 2007
de protozoos y bacterias del Invima del Invima
10. Desviación de la cuantificación de la salida, se indica qué
margen de error o desviación se permite a la salida
Fig. 5.6 Desviación

1 metro cúbico hora -200 litros por hora 20%
11. Hacer un listado de las cualidades del producto
Producto Cualidad
1 metro cúbico hora  Olor  Inodora
 Color  Sin turbiedades
 Norma nacional  Resolución 2115 de 2007
del Invima
6. Cómo escribir requerimientos
6.1 Introducción
A partir del resultado obtenido de la metodología de requerimientos

se hace necesario fragmentar esos párrafos para obtener requerimientos
individuales comprensibles, de calidad que puedan ser comprobados
mediante un plan de pruebas.
Con este fin, se propone seguir unos pasos que incluyen:
 Requerimientos clave
 Organización de los requerimientos
 Propiedades de los requerimientos
 Criterios de depuración de los requerimientos
 Estructuras de los requerimientos
 Errores comunes
6.2 Requerimientos clave
Los aspectos clave del negocio deben estar incluidos; no deben

omitirse. Un requerimiento clave debe ser de obligatorio cumplimiento.
En consecuencia se deben descartar aquellas exigencias que pueden

ser deseables u opcionales, pero no de forzoso cumplimiento.
Para detectar si un requerimiento es o no obligatorio, se deben

responder las siguientes preguntas:
 Usuario
¿Si la solución no me provee esta capacidad, aún la compraría?
 Sistema
¿Si el sistema no realizara esta función, aún sería útil?
 Requerimiento
¿Es negociable?
Si, en cualquier caso, la respuesta es afirmativa entonces el

requerimiento no es obligatorio.
6.3 Organización
Para obtener un documento organizado se recomienda seguir los
siguientes pasos:
 Minimizar el número de requerimientos
 Detectar y agrupar requerimientos relacionados
 Detectar omisiones y/o duplicaciones
 Eliminar conflictos entre requerimientos
 Rechazar requerimientos deficientes
 Evaluar (probar) los requerimientos
6.4 Propiedades de los requerimientos
Para elaborar requerimientos concretos y precisos, éstos tienen
que poseer las siguientes propiedades:

Requerimientos | 45
 Obligatorio: su omisión hace que el sistema sea
deficiente en cualquier dimensión (funcionalidad,
calidad, capacidad, otros).
 Conciso: debe ser fácil de leer y entender. No debe
generar ambigüedades por su lectura. No debe contener
palabras innecesarias.
 Completo: autocontenido; tener en sí mismo toda la
información necesaria. No debe requerir adiciones o
explicaciones extras.
 Consistente: no debe ser contradictorio con otro y debe

ser determinado en el tiempo.
Los conflictos pueden ser directos o indirectos:
o Directos, cuando ante una misma situación, cabe

esperar comportamientos diferentes.
o Indirectos, cuando no es posible cumplir con dos
requisitos al mismo tiempo, aunque describan
funcionalidades distintas.
 No ambiguo: debe ser claro, preciso y tener una única
interpretación posible.
 Verificable: debe poderse verificar (por algún tipo de
prueba) si satisface las necesidades del cliente o no:
cumple o no cumple.
 Viable: tiene que ser realista; posible de ser alcanzado
con los recursos disponibles.

6.5 Criterios de depuración
Además, los requerimientos deben estar depurados. Con este fin,
se aplican los siguientes criterios.
 Indivisible: cada proposición debe presentar un único

elemento al que se le pueda realizar el seguimiento.
 Único
 Legal/ético
 Claro
 Preciso
 Abstracto: no se debe indicar cómo hacerlo. No se incluye el
diseño.
 No redundante: solo se presenta una vez.
 Estructurado: se presenta bajo una de las estructuras
validadas.
 Modular: requerimientos similares van juntos
6.6 Estructura
6.6.1 Verbos utilizables
Dado que los requerimientos son obligatorios, el uso de verbos o
palabras clave unificadas en el texto emplea los verbos deber y poder,
en sus diferentes acepciones:
 Debe
 Debería
 Puede
Requerimientos | 47
 Podrá
6.6.2 Uso de estructuras
Es deseable utilizar plantillas que contengan estructuras que ayuden a

que los requerimientos cumplan con las características obligatorias. Una
forma general de la estructura puede ser la siguiente: El <sistema> deberá
<función> <objeto>. Ese objeto varía específicamente como se puede ver a
continuación.
Entre los tipos de estructuras más utilizadas se hallan las siguientes:
a) El <sistema> deberá <función> <objeto> cada <desempeño>

<unidad>.
Ejemplo:
 Sistema: SAN
 Función: almacenar.
 Objeto: un registro.
 Desempeño: 1.
 Unidad: ms.
La SAN deberá almacenar un registro cada 1 ms.
b) El <sistema> deberá <función> <objeto> durante por lo menos

<cantidad> <unidad> mientras <condición operacional>.
Ejemplo:
 Sistema: sistema de suministro de agua para

riego y bebederos.
 Función: suministrar
 Objeto: energía eléctrica alterna.

 Cantidad: 6.
 Unidad: horas.
 Condición de operación: falla el suministro de

energía pública.
El sistema de suministro de agua para riego y bebederos

deberá suministrar energía eléctrica alterna durante por lo
menos 6 horas mientras falle el suministro de energía
pública.
c) El <sistema> deberá <función> con por lo menos <cantidad>

<objeto> mientras <condición operacional>
Ejemplo:
 Sistema: SAN
 Función: mantener la comunicación con la

BD.
 Cantidad: 100.
 Objeto: usuarios.
 Condición operacional: falla un dispositivo de I/O.
La SAN deberá mantener la comunicación con la BD con por

lo menos 100 usuarios mientras falla un dispositivo de I/O.
6.7 Errores comunes
Al elaborar los requerimientos se cometen muchos errores. Veamos

algunos muy comunes:
 Se presentan en párrafos largos, donde es difícil de comprender lo

que se quiere.
Es preferible un listado de mercado que una novela.
 Muchas ideas mezcladas en un párrafo.
Presentar sólo un requerimiento por párrafo.
 No especulativo
 Uso de palabras vagas: general, normal, típico, óptimo.
Hay que ser concretos; dar cifras, datos.
 No uso de adjetivos vagos: todos, flexible, amigable, bonito, útil.
Que sean mensurables.
 Se redactan con los deseos: 100% seguro, 100% confiable, portable

a todas las plataformas.
Hay que ser realistas; tener en cuenta los recursos.

7. Procedimiento
El procedimiento general para elaborar los requerimientos de un
sistema sigue los siguientes pasos:
1) Adaptación al entorno.
El sistema tiene que tener una adaptación correcta con su entorno.
Cada ambiente específico plantea requerimientos diferentes.
2) Definir la función básica del sistema para que éste sea útil.
3) Abstraer los componentes básicos del sistema.
4) Seguir la metodología propuesta (capítulo V).
5) Establecer las interfaces externas del sistema (sin hacer diseño).
6) Estipular las interfaces con los usuarios (sin hacer diseño).
7) Comprobar que todos los objetivos específicos tienen requerimientos

relacionados que coadyuvan al cumplimiento de aquellos.
8) Definir los requerimientos clave del negocio.

52 | M a n i f e s t a c i ó n
Los requerimiento clave son de obligatorio cumplimiento. En

consecuencia se deben descartar aquellas exigencias que pueden ser
deseables u opcionales, pero no de forzoso cumplimiento.
9) Organización de los requerimientos.
 Minimizar el número de requerimientos
 Detectar y agrupar requerimientos relacionados
 Detectar omisiones y/o duplicaciones
 Eliminar conflictos entre requerimientos
 Rechazar requerimientos deficientes
 Evaluar (probar) los requerimientos
10) Controlar el cumplimiento de las propiedades de cada uno de los
requerimientos.
 Obligatorio.
 Conciso.
 Completo.
 Consistente.
 No ambiguo.
 Verificable.
 Viable.
11) Definir plantillas cuyas estructuras ayuden a precisar las
características obligatorias de los requerimientos.
12) Aplicar los criterios a los requerimientos.

M a n i f e s t ac i ó n | 53
 Indivisible
 Único
 Legal/ético
 Claro
 Preciso
 Abstracto
 No redundante
 Estructurado
 Modular
8. Otros requerimientos
Los requerimientos del sistema están bien definidos como se indicó en

los capítulos anteriores. Ahora bien, si se quiere realizar alguna función
específica en hardware o en software, ésta será una decisión que se tomará
en el momento en que se haga diseño –funcional y detallado-.
Así que, en la etapa de diseño se complementarán los requerimientos

a nivel de subsistemas y de los componentes de ellos. Estas decisiones
inciden directamente sobre el costo-beneficio del sistema En ese momento,
se justificará por qué se toma una decisión u otra.
Las decisiones que afectan el costo-beneficio están relacionadas con

los requerimientos no funcionales. Estos requerimientos, como se
mencionó anteriormente, son aquellos que describen aspectos del
sistema perceptibles por el usuario pero que no tienen una relación
directa con el comportamiento funcional del mismo. Por ejemplo,
tiempos de respuesta, seguridad, precisión, solicitudes tecnológicas
de los usuarios, etc.
Quizá, si vale la pena mencionar los requerimientos relacionados con

los documentos. No basta, por ejemplo, con decir que se entregará un
56 | C o n t e x t o
manual de operaciones, pues esto no dice nada ni sobre el contenido ni

sobre su calidad.
8.1 Manuales
Un sistema/equipo, normalmente, tiene los siguientes tipos de

manuales:
 Instalación.
 Operación.
 Mantenimiento.
 Funcional.
Una característica común a todos ellos es que se hacen paso a paso,

sin dar lugar a ambigüedades y para personas no muy inteligentes. Además,
utilizan muchas gráficas aclaratorias.
A continuación, se explicarán los manuales de instalación y operación,

que son los más empleados.
8.1.1 Manual de instalación
 Debe contener un listado de los componentes del sistema.

 Una gráfica que relacione a cada componente con su forma y
tamaño.
 Un listado de armado, paso a paso, con figuras de apoyo.
 Las condiciones para conectarlo a la red eléctrica, ayudada de
una gráfica.
 Las pruebas de funcionamiento básicas, con sus resultados y
gráficas de apoyo.
Este es el contenido mínimo de este manual.

Manifestación | 57
Además, algunas veces se indica la forma de desinstalarlo y empacarlo

para su transporte, si es necesario.
8.1.2 Manual de operaciones
Este manual se organiza por servicios y por roles. Es decir, se toma el

primer servicio y se hace el manual para cada uno de los roles del sistema.
Luego el segundo. Y así, sucesivamente, hasta terminar con el último
servicio y el último rol.
Cada servicio y rol, se explica paso a paso. También se utilizan gráficas

explicativas.
8.2 Documentos
Hay objetivos específicos cuyos entregables son documentos o

incluyen documentos. ¿Cómo se especifica su contenido?
 En primer lugar, se explica el objetivo del documento. Esto va

ligado a la profundidad con que se tratan los contenidos. Por
ejemplo, no es lo mismo un documento que describe el diseño
de una antena, que otro documento que muestra las
características y usos posibles de esa antena.
 En segundo lugar, se hace una tabla de contenido que incluya
todos los temas a tratar.
 Tercero, se amplía cada tema de la tabla anterior, mínimo,
hasta un segundo nivel.
9. Comité de Proyectos y los
Requerimientos
El sistema de evaluación de los requerimientos por el Comité de
Proyectos se resume en el diagrama de flujo que se presenta en la
figura 10.1. Debe notarse que el Comité no solamente vela porque los
requerimientos estén correctamente planteados, sino porque el costo
beneficio del proyecto se ajuste a la realidad: que el alumno cuente
con los recursos para solucionarlo en el término estipulado.
Por lo anterior se recomienda que cada grupo siga el diagrama
de flujo para evaluar si su proyecto cumple o no.
El Comité reconoce que el ingeniero no tiene todos los elementos
de juicio para calcular y justificar el costo beneficio del mismo, en esta
etapa del proyecto. Sí dispondrá de todos los elementos de juicio
cuando realice el diseño funcional y detallado.
El Comité de Proyectos ve el proyecto de grado como un
mecanismo para evidenciar si el alumno ya es capaz de realizar todas
las tareas que de él se esperan (conceptualización, diseño,
implementación y operación).
60 | C o m i t é d e P r o y e c t o s y e l p r o b l e m a
Inicio
NO SE APRUEBAN LOS
REQUERIMIENTOS PARA
SUSTENTACIÓN
¿El sistema está adaptado

al entorno?
No
Sí
¿El sistema tiene definida

su función básica?
No
Sí
¿Han abstraído los

componentes básicos del
No sistema?
Sí
No
¿Se siguió la metodología?
Sí
Sí
Sí
¿Se definieron las ¿Se definió la interfaz con
interfaces externas? el usuario?
No No
No
C o m i t é de P r o y e ct o s y e l p ro b l em a | 61
No
Sí
No
¿Hay Req. de objetivos
específicos?
Sí
No
¿Están los objetivos clave
del sistema?
Sí
No
¿Están organizados los
requerimientos?
Sí
No
¿Requerimientos cumplen
con sus propiedades?
Sí
No
¿Se usaron plantillas

estructuradas?
Sí
REQUERIMIENTOS APROBADOS
62 | C o m i t é d e P r o y e c t o s y e l p r o b l e m a
Fig.10.1 Diagrama de flujo de los requerimientos

INGENIERÍA DE PROYECTOS
EN INGENIERÍA ELECTRÓNICA
Junio 2013 Capítulo 5 Requerimientos
53

Capitulo 5 Requerimientos - Mayo - 2014

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capitulo 5 Requerimientos - Mayo - 2014

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DE PROYECTOS

Mayo 2014 ISBN XXXX-XXXX

Fabio Téllez Barón

Ninguna parte de esta obra puede ser reproducida o

3.3.3 Requisitos ............................................................................. 28

8. Otros requerimientos ........................................................................ 55

8.2 Documentos ................................................................................. 57

Este capítulo se presenta en forma estructurada para definir y

concretar los requerimientos que debe cumplir una solución,

hardware y/o software, sin hacer diseño ni seleccionar tecnologías; se

refiere, en especial, a aquellos proyectos a los que se enfrenta un

Una de las grandes dificultades que tienen los alumnos de

pregrado, y los recién egresados, es la elaboración precisa de los

requerimientos que debe cumplir una solución de ingeniería. Es

frecuente que se elaboren en forma ambigua e insuficiente, y que se

La definición incorrecta de los requerimientos lleva a que la

posible solución no sea la prevista por el usuario final. Incluso puede

ocasionar pleitos futuros, innecesarios, entre éste y el diseñador de la

Los requerimientos nacen con los aspectos a solucionar del

problema; tienen en cuenta la propuesta de solución, el producto previsto,

y los objetivos general y específicos. Su elaboración debe buscar una

solución funcional de los aspectos a solucionar del problema.

La estructura para elaboración y redacción de requerimientos,

propuesta en este capítulo, se basa en: definiciones, procedimientos,

Una vez que se explica la metodología, se presentan varios

ejemplos. Estos se orientan al uso de aquella, por lo que se presentan

los pasos en detalle hasta llegar a la redacción final de los

Por último y, para claridad de los estudiantes del Programa de

Ingeniería Electrónica de la Universidad El Bosque, se indican los

mínimos que debe tener el capítulo de requerimientos para que este

sea aprobado por el Comité de Proyectos e Investigación.

Para elaborar los requerimientos es fundamental hacer claridad

sobre algunos conceptos que se utilizan a lo largo de este documento.

Puede haber otras definiciones, pero en este contexto las entendemos

como están a continuación.

Un requerimiento es una condición que debe satisfacer el

bien/servicio a construir para resolver un problema; puede ser una

necesidad que debe cumplirse, o una restricción que debe satisfacerse

Los requerimientos conducen a un producto orientado a corregir

algunas de las causas detectadas en el problema; se espera que la

solución minimice los efectos y las manifestaciones.

Lo primero que se debe advertir es que no es necesario elaborar

todos los requerimientos simultáneamente. Así, en el Anteproyecto se

consideran sólo los requerimientos funcionales; los otros,

relacionados con los subsistemas y componentes, se tratarán en el

momento de hacer el Diseño –funcional y detallado-.

Los requerimientos deben estar relacionados directamente con el

producto a entregar. Así, pues, deben considerar:

 El tipo de proyecto o estudio

 El entregable (producto a entregar)

 Los objetivos generales y específicos

 Las necesidades de los usuarios

Además, la solución debe ser:

 Realizable en un tiempo determinado

 Realizable desde la disciplina del conocimiento

 Viable (se tengan los recursos necesarios)

 Relevante (de interés para la Universidad, sociedad,

empresa y/o ambiente)

Los requerimientos deben satisfacer las necesidades de los

usuarios, por completo y sin ambigüedades.

Ahora bien, se entiende por usuario a quien requiere el sistema

para solucionar un problema; además, lo valida y lo utiliza.

Los requerimientos deben ser entendidos tanto por los usuarios