I.E.S.T.P.

Lurín Docente: Juan Carlos Hernández Saona

HOJA DE INFORMACIÓN N°03
Profesor: Juan Carlos Hernandez Saona Fecha: del 17 al 21/04/2023
Semestre: III Turno: Diurno - Nocturno
Unidad Didáctica: Análisis y Diseño de Sistemas

1. Introducción
En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la
Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad,
tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos
relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número crecientede
herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software
efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto
ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.
Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos
proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad?
¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias
dependen de la calidad del sistema?
Tal vez suene ilógico, pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de
producción informales, parciales y en algunos casos no confiables.
La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que
enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la
generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistentey
compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionadosal
desarrollo de sistemas.
La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no
llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto
común la compra de sistemas extranjeros, para luego “personalizarlos” supuestamente a la medida de las
empresas.
Tal “personalización”, la mayoría de las veces termina retrasando el proyecto en meses, o incluso en años. La
problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas
existentes; cambios que, desde mi punto de vista, no fueron bien planificados.
El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las
modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a
desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se
omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los
requerimientos.
Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio
previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el
cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.
Con este trabajo se pretende alcanzar los siguientes objetivos:
Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo.Dar
a conocer las diferentes alternativas que existen para identificar requerimientos.
Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la IR.Minimizar
las dudas que se tiene sobre los casos de uso.
Mostrar la utilización de herramientas CASE dentro de la administración de requisitos.

Unidad Didáctica: Análisis y Diseño de Sistemas 1⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

2. La ingeniería de requerimientos y sus

principales actividades
¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que
existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE1.
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición
o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato,
estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o
capacidad como en (1) o (2).
Los requerimientos 2 puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los
requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para producir salidas. Los
requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar elsistema,
como, por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez delsistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en
estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A
continuación, se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y
además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras
capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para
aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se
proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su
definición no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de
los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
Dificultades para definir los requerimientos
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del
proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
Ingeniería de Requerimientos vs. Administración de Requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de
Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de
software correcta y completa.

1 IEEE Std. 610.12-1990

2 En el documento se usa la palabra requisito como sinónimo de requerimiento.
Unidad Didáctica: Análisis y Diseño de Sistemas 2⚫
 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

A continuación, se darán algunas definiciones para ingeniería de requerimientos.

“Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no
ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se
describen las funciones que realizará el sistema” Boehm 1979.
“Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los
clientes 3, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del
comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones”. STARTS Guide 1987.
“Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el
sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo productoes
un modelo del cual se genera un documento de requerimientos” Leite 1987.
“Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los
requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de
requerimientos, entre los clientes y el equipo del proyecto” Rational Software

Importancia de la Ingeniería de Requerimientos

Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:
• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste en
una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un
punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de
costos, tiempo y recursos necesarios.
• Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por
un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones
tomadas durante la RE.
• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de
requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
• Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de
consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus
requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra
durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniería de Requerimientos

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es
importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de
la planificación del proyecto; el conocimiento de cada papel desempeñado asegura que se involucren a las
personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.

No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores,
que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden
clasificarse como sigue:
• Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la
usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos
que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las
interfaces y los manuales de usuario.
• Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en
donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y
requerimientos de las interfaces del sistema.

3 El“cliente” puede ser interpretado como un usuario de contabilidad, el grupo de mercadeo, otra organización
interna o un cliente externo.

Unidad Didáctica: Análisis y Diseño de Sistemas 3⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

• Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son
las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su
trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.
• Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan
directamente con el cliente.
• Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las
condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos
satisfacen las necesidades del cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser:
administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.

Puntos para considerar durante la Ingeniería de Requerimientos

Aunque la lista no está completa, se enumeran los puntos más importantes.
Objetivos del negocio y ambiente de trabajo
Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para
descomponer el trabajo en tareas específicas. En ciertas situaciones IR se enfoca en la descripción de las tareas
y en el análisis de sistemas similares. Esta información proporciona la base para especificar el sistemaque será
construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de trabajo
planificado.
El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales sobre
la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en
producción; también ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo
equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque
existen diversas razones que dificultan el mantenimiento del software, la falta de atención a la IR es la principal.
Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación y
el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen
sistemas inadecuados.
Punto de vista de los clientes
Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y,
diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces
tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten
procesos que causan conflictos con los solicitados por el usuario.

Diferentes puntos de vistas también pueden tener consecuencias negativas, tales como datos redundantes,
inconsistentes y ambiguos.
El tamaño y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo
aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos.
• Barreras de comunicación
La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de
requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la
comunicación.
Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas
barreras y así ganar experiencia dentro del marco del sistema propuesto.
• Evolución e integración del sistema
Pocos sistemas son construidos desde cero. En la práctica, los proyectos se derivan de sistemas ya
existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo
general son una integración de componentes de varios proveedores.
Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre
los requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código.
• Documentación de requerimientos

Unidad Didáctica: Análisis y Diseño de Sistemas 4⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos
o miles de páginas; cada página contiene muchos detalles que pueden tener efectos profundos en el
resto del sistema.
Normalmente, las personas se encuentran con dificultades para comprender documentos de este
tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación
de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto
causa problemas y errores que no son detectados hasta después de haberse construido el sistema.

Actividades de la Ingeniería de Requerimientos

En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas
secuencialmente, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son
aplicadas de manera continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo,
las actividades de la IR varían tanto en número como en nombres. La tabla #1 muestra algunos ejemplos de las
actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades
mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:
• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software

MODELO Oliver and EIA / IS-632 IEEE Std CMM nivel RUP
Steiner 1996 1220- 1994 Repetitivo (2)

Evaluar la Análisis de Análisis de Identificación Análisis del

información requerimientos Requerimiento de Problema
disponible s requerimientos
Definir Análisis Estudio de los Identificación Comprender
métricas funcional requerimientos de las
efectivas restricciones necesidades
del sistema a de los
desarrollar involucrados
Crear un Síntesis Validación de Análisis de los Definir el
modelo del requerimientos requerimientos sistema
comportamient
Actividades o del sistema
Crear un Análisis y Análisis Representació Analizar el
modelo de los control del funcional n de los alcance del
objetos sistema requerimientos proyecto
Ejecutar el Evaluación y Comunicación Modificar la
análisis estudio de de los definición del
funciones requerimientos sistema
Crear un plan Verificación de Validación de Administrar los
secuencial de funciones requerimientos cambios de
construcción y requerimientos
pruebas
Síntesis

Unidad Didáctica: Análisis y Diseño de Sistemas 5⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

Estudio y
evaluación del
diseño
Verificación
física
Control

A continuación, se explicará cada una de ellas, presentándolas en el orden en que deben ser aplicadas para un
nuevo proyecto.
Análisis del Problema
El objetivo de esta actividad es entender las verdaderas necesidades del negocio.
Antes de describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término
“Problema”.
“Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se
desean” 4. Aquí vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y
clientes; de esta comunicación con el cliente depende que entendamos sus necesidades.

A través de la definición de problema, podemos ver entonces que la actividad de “Análisis del Problema”5 tiene
por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iniciales de todos los
involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo.
Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los
involucrados, basados en los problemas reales del negocio.
Estos pasos son los siguientes
Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente,
considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes
puntos de vista. Veamos la siguiente necesidad: “El cliente se queja mucho por la enorme fila que debe formar
para realizar una transacción bancaria”.

Perspectiva del cliente = Pérdida de tiempo Perspectiva

del banco = Posibles pérdidas de clientes
Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica
contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado),
realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc).
Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la
más factible. Las soluciones iniciales, deben ser definidas tomando en cuenta tanto la perspectiva técnica como
la del negocio.

Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los términos que
tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras
pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción
de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida.
La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio,
ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser
reutilizable en otros proyectos.

Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida
que avanza el proyecto. Las necesidades de cada afectado son discutidas y sometidas a debate durante de

4Gause & Weinberg. Turn your lights on, 1989

5A esta actividad también se le conoce como “Identificación de Requerimientos”, “Elaboración de necesidades
y objetivos”, “Elicitation Requirements”, entre otras, pero en todas se realizan los mismos pasos.

Unidad Didáctica: Análisis y Diseño de Sistemas 6⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información
necesaria para especificar un sistema adecuado.
Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán
afectadas por el sistema, debemos realizar algunas preguntas.
• ¿Quién usará el sistema que se va a construir?
• ¿Quién desarrollará el sistema?
• ¿Quién probará el sistema?
• ¿Quién documentará el sistema?
• ¿Quién dará soporte al sistema?
• ¿Quién dará mantenimiento al sistema?
• ¿Quién mercadeará, venderá, y/o distribuirá el sistema?
• ¿Quién se beneficiará por el retorno de inversión del sistema?
Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema,ya
sea directa o indirectamente.
Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está
construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo
plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que
limite el sistema que se va a construir.

Evaluación y negociación de los requerimientos

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los
mismos antes de definir si son adecuados para el cliente. El término “adecuado” significa que ha sido percibido a
un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan
resultados completos, correctos y sin ambigüedades.
En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los
niveles de abstracción y descomposición de cada problema presentado.

Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura que todas las características descritas en el punto
1.1 estén presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos
ambiguos, incompletos, inconsistentes, etc.
Clasificar los requerimientos:
En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A
esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán
las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las
necesidades que tenga el negocio.
En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios.Un
requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera
incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un
requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como
innecesario.
Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los
mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un
requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo,si
un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo
deseable.

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los
requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar
el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

Unidad Didáctica: Análisis y Diseño de Sistemas 7⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los

afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de
consideraciones que deben tenerse en cuenta; entre las principales tenemos:
• Documentar todos los requerimientos a un nivel de detalle apropiado.
• Mostrar todos los requerimientos a los involucrados en el sistema.
• Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.
• Establecer las relaciones entre requerimientos que indiquen dependencias.
• Negociar con flexibilidad para que exista un beneficio mutuo.
• Enfocarse en intereses y no en posiciones.

Especificación de Requisitos de Software (SRS)

La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo
nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será
desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los
requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y
cualquier otra información que sirva de soporte y guía para fases posteriores.

Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y
evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación
entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la
implementación del sistema.

Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades
de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El
personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el
administrador del proyecto sirve como referencia y control de la evolución del sistema.

La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua,
factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada,
cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada
requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento
debe ser modificable y así sucesivamente. Las características de la SRS son verificadas en la actividad de
Validación, descrita en el punto 3.4.

La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de
la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los
tópicos importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. Enel
anexo #1 se muestra una plantilla completa para la especificación de requisitos.

Validación de Requisitos
La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema sonlos
que realmente quiere el cliente; además
revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza
que todos los requerimientos presentes en el documento de especificación sigan los estándares decalidad.

Unidad Didáctica: Análisis y Diseño de Sistemas 8⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La

evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de
las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se
desean revisar. A continuación, se presentan varios ejemplos:
• ¿Están incluidas todas las funciones requeridas por el cliente? (completa)
• ¿Existen conflictos en los requerimientos? (consistencia)
• ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
• ¿Está cada requerimiento claramente representado? (entendible)
• ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible)
• ¿Está la SRS escrita en un lenguaje apropiado? (clara)
• ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
• ¿Está claramente definido el origen de cada requisito? (rastreable)
• ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

La validación de requerimientos es importante pues de ella depende que no existan elevados costos de
mantenimiento para el software desarrollado.

Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y
cómo los objetivos de la organización pueden cambiar, por lo tanto,
es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La
actividad de evolución es un proceso externo
que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones. Las más frecuentes son:
• Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.
• Porque cambió el problema que se estaba resolviendo.
• Porque los usuarios cambiaron su forma de pensar o sus percepciones.
• Porque cambió el ambiente de negocios.
• Porque cambió el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en
particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administraciónde
cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar
dependencias entre ellos y mantener un control de versiones.

Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener
requerimientos emparchados 6 en un proyecto

Entre algunos de los beneficios que proporciona el control de versiones están:

• Prevenir cambios no autorizados.
• Guardar revisiones de los documentos de requerimientos.
• Recuperar versiones previas de los documentos.
• Administrar una estrategia de “releases”.
• Prevenir la modificación simultánea a los requisitos.

6 Se le llama requerimiento emparchado a aquél que ha sufrido cambios excesivos en la semántica.

Unidad Didáctica: Análisis y Diseño de Sistemas 9⚫

 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un
solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

Técnicas para Identificar Requisitos

Funcionales y No Funcionales
Ya que los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, se deben tener
en cuenta las siguientes técnicas para la identificación correcta.
Identificación de Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que
éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas
también declaran explícitamente lo que el sistema no debe hacer.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de
requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo
con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e
incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y serconsistente.
La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa
que los requerimientos no tienen definiciones contradictorias.
En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y
compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que
los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuandolos
requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una
vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se
deben corregir en el documento de requerimientos.
Identificación de Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema,
sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos
de entrada/salida y la representación de datos que se utiliza en la interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el
presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software
o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, entreotros.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de
desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la
tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización
del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de
implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de
entrega que especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo.
Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los
otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema
opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que
será aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir
sus metas en requerimientos cuantitativos; para algunas de éstas, como las de mantenimiento, no existen
Unidad Didáctica: Análisis y Diseño de Sistemas 10 ⚫
 I.E.S.T.P. Lurín Docente: Juan Carlos Hernández Saona
métricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales
cuantitativos es muy alto.

Unidad Didáctica: Análisis y Diseño de Sistemas 11 ⚫

 I.E.S.T.P. LURIN Docente: Juan Carlos Hernández Saona
En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la
práctica, esto es difícil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces
es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil separar las condiciones
funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un
balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se
refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una sección aparte
o diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales

Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:

• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?
Siempre se debe comenzar con lo básico. Cuando se hacen preguntas y se reciben respuestas, se proporcionan
antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo.
Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:

• ¿Cuál es la finalidad de la actividad dentro de la empresa?

• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?

Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:

• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos
• Bases de datos
• Datos de las bases de datos

Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el sistema; o sea,cuántos
tienen relación directa con el proyecto
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño documentados oficial o no
oficialmente? Si los hay, ¿Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, ¿se respetan dichos
procedimientos?
• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
• ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?

Unidad Didáctica: Análisis y Diseño de Sistemas 1⚫