INGENIERIA DE REQUERIMIENTOS

““La parte más difícil al construir un

sistema de software es decidir qué
construir. Ninguna parte del trabajo
invalida tanto al sistema resultante si
ésta se hace mal. Nada es más difícil de
Corregir después.”
Brad J. Cox

INGENIERÍA DE REQUERIMIENTOS 1
 Introducción
• Los requerimientos para un sistema son descripciones de lo que el
sistema debe hacer: el servicio que ofrece y las restricciones en su
operación. Tales requerimientos reflejan las necesidades de los
clientes por un sistema que atienda cierto propósito.
• Al proceso de descubrir, analizar, documentar y verificar estos
servicios y restricciones se le llama ingeniería de requerimientos (IR).
• En algunos casos, un requerimiento es simplemente un enunciado
abstracto de alto nivel en un servicio que debe proporcionar un
sistema, o bien, una restricción sobre un sistema. En el otro extremo,
consiste en una definición detallada y formal de una función del
sistema.

INGENIERÍA DE REQUERIMIENTOS 2
 Requerimientos del usuario y requerimientos
del sistema
1. Los requerimientos del usuario son enunciados, en un lenguaje
natural junto con diagramas, acerca de qué servicios esperan los
usuarios del sistema, y de las restricciones con las cuales éste debe
operar.
2. Los requerimientos del sistema son descripciones más detalladas
de las funciones, los servicios y las restricciones operacionales del
sistema de software. El documento de requerimientos del sistema
(llamado en ocasiones especificación funcional) tiene que definir
con exactitud lo que se implementará. Puede formar parte del
contrato entre el comprador del sistema y los desarrolladores del
software.

INGENIERÍA DE REQUERIMIENTOS 3
 Un ejemplo de un sistema de administración de pacientes para
apoyar la atención a la salud mental (MHC-PMS)

INGENIERÍA DE REQUERIMIENTOS 4
 Requerimientos funcionales y no funcionales
1. Requerimientos funcionales: Son enunciados acerca de servicios
que el sistema debe proveer, de cómo debería reaccionar el sistema
a entradas particulares y de cómo debería comportarse el sistema
en situaciones específicas. En algunos casos, los requerimientos
funcionales también explican lo que no debe hacer el sistema.
2. Requerimientos no funcionales: Son limitaciones sobre servicios o
funciones que ofrece el sistema. Incluyen restricciones tanto de
temporización y del proceso de desarrollo, como impuestas por los
estándares. Los requerimientos no funcionales se suelen aplicar al
sistema como un todo, más que a características o a servicios
individuales del sistema.

INGENIERÍA DE REQUERIMIENTOS 5
 Requerimientos funcionales
• Los requerimientos funcionales del sistema varían desde
requerimientos generales que cubren lo que tiene que hacer el
sistema, hasta requerimientos muy específicos que reflejan maneras
locales de trabajar o los sistemas existentes de una organización.
• En principio, la especificación de los requerimientos funcionales de un
sistema debe ser completa y consistente. Completa significa que
deben definirse todos los servicios requeridos por el usuario.
Consistencia quiere decir que los requerimientos tienen que evitar
definiciones contradictorias.

INGENIERÍA DE REQUERIMIENTOS 6
 Requerimientos no funcionales
• Son requerimientos que no se relacionan directamente con los
servicios específicos que el sistema entrega a sus usuarios. Pueden
relacionarse con propiedades emergentes del sistema, como
fiabilidad, tiempo de respuesta y uso de almacenamiento.
• Los requerimientos no funcionales surgen a través de necesidades del
usuario, debido a restricciones presupuestales, políticas de la
organización, necesidad de interoperabilidad con otro software o
sistemas de hardware, o factores externos como regulaciones de
seguridad o legislación sobre privacidad.

INGENIERÍA DE REQUERIMIENTOS 7
 Tipos de requerimientos no funcionales

INGENIERÍA DE REQUERIMIENTOS 8
 Tipos de requerimientos no funcionales (II)
1. Requerimientos del producto: Estos requerimientos especifican o restringen el
comportamiento del software. Los ejemplos incluyen requerimientos de rendimiento sobre
qué tan rápido se debe ejecutar el sistema y cuánta memoria requiere, requerimientos de
fiabilidad que establecen la tasa aceptable de fallas, requerimientos de seguridad y
requerimientos de usabilidad.
2. Requerimientos de la organización: Son requerimientos de sistemas amplios, derivados de
políticas y procedimientos en la organización del cliente y del desarrollador. Los ejemplos
incluyen requerimientos del proceso operacional que definen cómo se usará el sistema,
requerimientos del proceso de desarrollo que especifican el lenguaje de programación,
estándares del entorno o el proceso de desarrollo a utilizar, y requerimientos ambientales que
definen el entorno de operación del sistema.
3. Requerimientos externos: Este término cubre todos los requerimientos derivados de factores
externos al sistema y su proceso de desarrollo. En ellos se incluyen requerimientos regulatorios
que establecen lo que debe hacer el sistema para ser aprobado en su uso por un regulador,
como sería un banco central; requerimientos legislativos que tienen que seguirse para
garantizar que el sistema opere conforme a la ley, y requerimientos éticos que garanticen que
el sistema será aceptable para sus usuarios y el público en general.

INGENIERÍA DE REQUERIMIENTOS 9
 Ejemplo de requerimientos no funcionales (MHC-PMS)

INGENIERÍA DE REQUERIMIENTOS 10
 Redacción de los requerimientos no funcionales
• Como meta general:
“Para el personal médico debe ser fácil usar el sistema, y este último debe
organizarse de tal forma que minimice los errores del usuario”

• Como requerimiento “comprobable”:

“Después de cuatro horas de capacitación, el personal médico usará todas las
funciones del sistema. Después de esta capacitación, los usuarios
experimentados no deberán superar el promedio de dos errores cometidos por
hora de uso del sistema”

INGENIERÍA DE REQUERIMIENTOS 11
 Redacción de los requerimientos no funcionales (II)
• Siempre que sea posible, se
deberán escribir de manera
cuantitativa los
requerimientos no
funcionales, de manera que
puedan ponerse
objetivamente a prueba.
• Se puede medir dichas
características cuando el
sistema se pone a prueba
para comprobar si éste
cumple o no cumple con sus
requerimientos no
funcionales.
• ¿Cómo medir la
mantenibilidad?

INGENIERÍA DE REQUERIMIENTOS 12
 El documento de requerimientos de sw.
• El documento de requerimientos de software (llamado algunas veces
especificación de requerimientos de software o SRS) es un
comunicado oficial de lo que deben implementar los desarrolladores
del sistema. Incluye tanto los requerimientos del usuario para un
sistema, como una especificación detallada de los requerimientos del
sistema.
• En ocasiones, los requerimientos del usuario y del sistema se integran
en una sola descripción. En otros casos, los requerimientos del
usuario se definen en una introducción a la especificación de
requerimientos del sistema. Si hay un gran número de
requerimientos, los requerimientos del sistema detallados podrían
presentarse en un documento aparte.
INGENIERÍA DE REQUERIMIENTOS 13
 Usuarios de un documento de requerimientos

INGENIERÍA DE REQUERIMIENTOS 14
 Estructura de un documento de requerimientos

INGENIERÍA DE REQUERIMIENTOS 15
 Estructura de un documento de requerimientos (II)

INGENIERÍA DE REQUERIMIENTOS 16
 Fuente: Ing. del
Software, Roger
Pressman

INGENIERÍA DE REQUERIMIENTOS 17
 Especificación de requerimientos
• La especificación de requerimientos es el proceso de escribir, en un
documento de requerimientos, los requerimientos del usuario y del
sistema.
• De manera ideal, los requerimientos del usuario y del sistema deben
ser claros, sin ambigüedades, fáciles de entender, completos y
consistentes. Esto en la práctica es difícil de lograr, pues los
participantes interpretan los requerimientos de formas diferentes y
con frecuencia en los requerimientos hay conflictos e inconsistencias
inherentes.

INGENIERÍA DE REQUERIMIENTOS 18
 Formas de escribir las especificaciones

INGENIERÍA DE REQUERIMIENTOS 19
 a. Especificación en lenguaje natural
1. Elaborar un formato estándar y asegurarse de que todas las definiciones
de requerimientos se adhieran a dicho formato.
2. Utilizar el lenguaje de manera clara para distinguir entre requerimientos
obligatorios y deseables.
3. Usar texto resaltado (negrilla, cursiva o color) para seleccionar partes
clave del requerimiento.
4. No suponer que los lectores entienden el lenguaje técnico de la
ingeniería de software. Evitar el uso de jerga, abreviaturas y acrónimos.
5. Siempre que sea posible, asociar una razón con cada requerimiento de
usuario. La razón debe explicar por qué se incluyó el requerimiento.

INGENIERÍA DE REQUERIMIENTOS 20
 Especificación estructurada de un requerimiento para una bomba de insulina

INGENIERÍA DE REQUERIMIENTOS 21
 b. Especificaciones estructuradas
Cuando se use una forma estándar para especificar requerimientos
funcionales, se debe incluir la siguiente información:
1. Una descripción de la función o entidad a especificar.
2. Una descripción de sus entradas y sus procedencias.
3. Una descripción de sus salidas y a dónde se dirigen.
4. Información sobre los datos requeridos para el cálculo u otras entidades en el
sistema que se utilizan (la parte “requiere”).
5. Una descripción de la acción que se va a tomar.
6. Si se usa un enfoque funcional, una precondición establece lo que debe ser
verdadero antes de llamar a la función, y una postcondición especifica lo que es
verdadero después de llamar a la función.
7. Una descripción de los efectos colaterales (si acaso hay alguno) de la operación.

INGENIERÍA DE REQUERIMIENTOS 22
 Especificación tabular del cálculo para una bomba de insulina

INGENIERÍA DE REQUERIMIENTOS 23
 Procesos de ingeniería de requerimientos
• Los procesos de ingeniería de requerimientos incluyen cuatro
actividades de alto nivel:
1. Valorar si el sistema es útil para la empresa (estudio de factibilidad).
2. Descubrir requerimientos (adquisición y análisis).
3. Convertir dichos requerimientos en alguna forma estándar (especificación).
4. Comprobar que los requerimientos definan realmente el sistema que quiere
el cliente (validación).
• En la práctica, la ingeniería de requerimientos es un proceso iterativo
donde las actividades están entrelazadas.

INGENIERÍA DE REQUERIMIENTOS 24
 Vista en espiral del proceso de ingeniería de requerimientos:
• Las actividades están organizadas como un
proceso iterativo alrededor de una espiral, y la
salida es un documento de requerimientos del
sistema. La cantidad de tiempo y esfuerzo
dedicados a cada actividad en cada iteración
depende de la etapa del proceso global y el
tipo de sistema que está siendo desarrollado.
• En el inicio del proceso, se empleará más
esfuerzo para comprender los requerimientos
empresariales de alto nivel y los no
funcionales, así como los requerimientos del
usuario para el sistema. Más adelante en el
proceso, en los anillos exteriores de la espiral,
se dedicará más esfuerzo a la adquisición y
comprensión de los requerimientos
detallados del sistema.
INGENIERÍA DE REQUERIMIENTOS 25
 a. Adquisición y análisis de requerimientos
Después de un estudio de
factibilidad inicial, la siguiente etapa
del proceso de ingeniería de
requerimientos es la adquisición y el
análisis de requerimientos. En esta
actividad, los ingenieros de software
trabajan con clientes y usuarios
finales del sistema para descubrir el
dominio de aplicación, qué servicios
debe proporcionar el sistema, el
desempeño requerido de éste, las
restricciones de hardware, etcétera.

INGENIERÍA DE REQUERIMIENTOS 26
 Dificultades del proceso de adquisición y análisis de
requerimientos
1. Los participantes con frecuencia no saben lo que quieren de un sistema
de cómputo, excepto en términos muy generales.
2. Los participantes en un sistema expresan naturalmente los
requerimientos con sus términos y conocimientos implícitos de su
trabajo.
3. Diferentes participantes tienen distintos requerimientos y pueden
expresarlos en variadas formas.
4. Factores políticos llegan a influir en los requerimientos de un sistema.
5. El ambiente económico y empresarial donde ocurre el análisis es
dinámico. Inevitablemente cambia durante el proceso de análisis.

INGENIERÍA DE REQUERIMIENTOS 27
 Descubrimiento de requerimientos
• Es el proceso de recopilar información sobre el sistema requerido y
los sistemas existentes, así como de separar, a partir de esta
información, los requerimientos del usuario y del sistema.
• Las fuentes de información durante la fase de descubrimiento de
requerimientos incluyen documentación, participantes del sistema y
especificaciones de sistemas similares.
• La interacción con los participantes es a través de entrevistas y
observaciones, y pueden usarse escenarios y prototipos para ayudar a
los participantes a entender cómo será el sistema.

INGENIERÍA DE REQUERIMIENTOS 28
 Entrevistas
• Las entrevistas formales o informales con participantes del sistema
son una parte de la mayoría de los procesos de ingeniería de
requerimientos. En estas entrevistas, el equipo de ingeniería de
requerimientos formula preguntas a los participantes sobre el
sistema que actualmente usan y el sistema que se va a desarrollar.
• Las entrevistas son de dos tipos:
1. Entrevistas cerradas, donde los participantes responden a un conjunto de
preguntas preestablecidas.
2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo
de ingeniería de requerimientos explora un rango de conflictos con los
participantes del sistema y, como resultado, desarrolla una mejor
comprensión de sus necesidades.

INGENIERÍA DE REQUERIMIENTOS 29
 Escenarios
• Por lo general, las personas encuentran más sencillo vincularse con
ejemplos reales que con descripciones abstractas. Pueden comprender y
criticar un escenario sobre cómo interactuar con un sistema de software.
Los ingenieros de requerimientos usan la información obtenida de esta
discusión para formular los verdaderos requerimientos del sistema.
• En su forma más general, un escenario puede incluir:
1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el
escenario.
2. Una descripción en el escenario del flujo normal de los eventos.
3. Una descripción de qué puede salir mal y cómo se manejaría.
4. Información de otras actividades que estén en marcha al mismo tiempo.
5. Una descripción del estado del sistema cuando termina el escenario.

INGENIERÍA DE REQUERIMIENTOS 30
 Escenario para recabar historia médica en MHC-PMS

INGENIERÍA DE REQUERIMIENTOS 31
INGENIERÍA DE REQUERIMIENTOS 32
 Casos de uso
• Los casos de uso son una técnica de descubrimiento de
requerimientos que se introdujo por primera vez en el método
Objectory (Jacobson et al., 1993). Ahora se ha convertido en una
característica fundamental del modelado de lenguaje unificado.
• En su forma más sencilla, un caso de uso identifica a los actores
implicados en una interacción, y nombra el tipo de interacción.
Entonces, esto se complementa con información adicional que
describe la interacción con el sistema. La información adicional puede
ser una descripción textual, o bien, uno o más modelos gráficos como
una secuencia UML o un gráfico de estado.

INGENIERÍA DE REQUERIMIENTOS 33
 Casos de uso para el MHC-PMS

INGENIERÍA DE REQUERIMIENTOS 34
 Etnografía
• Los sistemas de software no existen aislados. Se usan en un contexto social
y organizacional, y dicho escenario podría derivar o restringir los
requerimientos del sistema de software. Una razón por la que muchos
sistemas de software se entregan, y nunca se utilizan, es que sus
requerimientos no consideran de manera adecuada cómo afectaría el
contexto social y organizacional la operación práctica del sistema.
• La etnografía es una técnica de observación que se usa para entender los
procesos operacionales y ayudar a derivar requerimientos de apoyo para
dichos procesos. Un analista se adentra en el ambiente laboral donde se
usará el sistema. Observa el trabajo diario y toma notas acerca de las
tareas existentes en que intervienen los participantes. El valor de la
etnografía es que ayuda a descubrir requerimientos implícitos del sistema
que reflejan las formas actuales en que trabaja la gente, en vez de los
procesos formales definidos por la organización.

INGENIERÍA DE REQUERIMIENTOS 35
 Etnografía y creación de prototipos para análisis de requerimientos
La etnografía puede combinarse con la creación de prototipos. La etnografía informa del desarrollo del
prototipo, de modo que se requieren menos ciclos de refinamiento del prototipo. Más aún, la creación
de prototipos se enfoca en la etnografía al identificar problemas y preguntas que entonces pueden
discutirse con el etnógrafo. Siendo así, éste debe buscar las respuestas a dichas preguntas durante la
siguiente fase de estudio del sistema

INGENIERÍA DE REQUERIMIENTOS 36
 Validación de requerimientos
• La validación de requerimientos es el proceso de verificar que los
requerimientos definan realmente el sistema que en verdad quiere el
cliente.
• La validación de requerimientos es importante porque los errores en
un documento de requerimientos pueden conducir a grandes costos
por tener que rehacer, cuando dichos problemas se descubren
durante el desarrollo del sistema o después de que éste se halla en
servicio. La razón de estos grandes costos es que un cambio a los
requerimientos significa generalmente que también deben cambiar el
diseño y la implementación del sistema.

INGENIERÍA DE REQUERIMIENTOS 37
 Comprobaciones en los requerimientos
1. Comprobaciones de validez: Un usuario quizá crea que necesita un sistema para realizar ciertas
funciones. Sin embargo, con mayor consideración y análisis se logra identificar las funciones adicionales o
diferentes que se requieran. Los sistemas tienen diversos participantes con diferentes necesidades, y
cualquier conjunto de requerimientos es inevitablemente un compromiso a través de la comunidad de
participantes.
2. Comprobaciones de consistencia: Los requerimientos en el documento no deben estar en conflicto. Esto
es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del
sistema.
3. Comprobaciones de totalidad: El documento de requerimientos debe incluir requerimientos que definan
todas las funciones y las restricciones pretendidas por el usuario del sistema.
4. Comprobaciones de realismo: Al usar el conocimiento de la tecnología existente, los requerimientos
deben comprobarse para garantizar que en realidad pueden implementarse. Dichas comprobaciones
también tienen que considerar el presupuesto y la fecha para el desarrollo del sistema.
5. Verificabilidad: Para reducir el potencial de disputas entre cliente y contratista, los requerimientos del
sistema deben escribirse siempre de manera que sean verificables. Esto significa que se debe ser capaz
de escribir un conjunto de pruebas que demuestren que el sistema entregado cumpla cada
requerimiento especificado.

INGENIERÍA DE REQUERIMIENTOS 38
 Técnicas de validación de requerimientos
1. Revisiones de requerimientos: Los requerimientos se analizan
sistemáticamente usando un equipo de revisores que verifican errores e
inconsistencias.
2. Creación de prototipos: En esta aproximación a la validación, se muestra un
modelo ejecutable del sistema en cuestión a los usuarios finales y clientes. Así,
ellos podrán experimentar con este modelo para constatar si cubre sus
necesidades reales.
3. Generación de casos de prueba: Los requerimientos deben ser comprobables.
Si las pruebas para los requerimientos se diseñan como parte del proceso de
validación, esto revela con frecuencia problemas en los requerimientos. Si una
prueba es difícil o imposible de diseñar, esto generalmente significa que los
requerimientos serán difíciles de implementar, por lo que deberían
reconsiderarse. El desarrollo de pruebas a partir de los requerimientos del
usuario antes de escribir cualquier código es una pieza integral de la
programación extrema.

INGENIERÍA DE REQUERIMIENTOS 39
 Administración de requerimientos
• Los requerimientos para los grandes sistemas de software siempre
cambian. Como el problema no se logra definir por completo, los
requerimientos del software están condenados también a estar
incompletos.
• Durante el proceso de software, la comprensión que los participantes
tienen de los problemas cambia constantemente. Entonces, los
requerimientos del sistema también deben evolucionar para reflejar
esa visión cambiante del problema.
• Una vez que los usuarios finales experimentan el sistema, descubrirán
nuevas necesidades y prioridades.

INGENIERÍA DE REQUERIMIENTOS 40
 Planeación en la administración de requerimientos
Durante la etapa de administración de requerimientos, se tiene que
decidir sobre:
1. Identificación de requerimientos: Cada requerimiento debe identificarse de
manera exclusiva, de forma que pueda tener referencia cruzada con otros
requerimientos y usarse en las evaluaciones de seguimiento.
2. Un proceso de administración del cambio: Éste es el conjunto de actividades que
valoran el efecto y costo de los cambios.
3. Políticas de seguimiento: Dichas políticas definen las relaciones entre cada
requerimiento, así como entre los requerimientos y el diseño del sistema que debe
registrarse. La política de seguimiento también tiene que definir cómo mantener
dichos registros.
4. Herramientas de apoyo: La administración de requerimientos incluye el
procesamiento de grandes cantidades de información acerca de los
requerimientos. Las herramientas disponibles varían desde sistemas especializados
de administración de requerimientos, hasta hojas de cálculo y sistemas de bases
de datos simples.

INGENIERÍA DE REQUERIMIENTOS 41
 Administración del cambio en los requerimientos
• La administración del cambio es esencial porque es necesario
determinar si los beneficios de implementar nuevos requerimientos
están justificados por los costos de la implementación.
• Existen tres etapas principales de un proceso de administración del
cambio:

INGENIERÍA DE REQUERIMIENTOS 42
 Bibliografía
1. Ingeniería del Software – Ian Sommerville
9na Edición – Cap. 4
2. Ingeniería del Software – Roger Pressman
7ma edición - Cap. 5 y 6

INGENIERÍA DE REQUERIMIENTOS 43