UNIDAD 3Req yViabilidad-2020 (1)

Vista previa del material en texto

Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 1 
UNIDAD 4 
REQUERIMIENTOS Y VIABILIDAD DEL SISTEMA 
IDENTIFICACION DE REQUISITOS 
Introducción 
 
Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir, no 
existe tarea con mayor capacidad de lesionar al sistema cuando se hace mal. Ninguna otra tarea es tan difícil 
de rectificar a posteriori (F.P. Brooks, 1987) 
 
Continuamente se publican nuevos datos acerca de la importancia de los requisitos en Ingeniería 
del Software, por ejemplo según el “Chaos Report” del Standish Group 1, resulta que: 
• El gasto anual en proyectos software en EEUU es de unos 250 billones de dólares, invertidos 
en aproximadamente unos 175000 proyectos 
• 31.1% serán cancelados 
• 52.7% costará un 190% más de lo estimado 
• Un 16.2% será finalizado a tiempo y dentro del presupuesto pero el producto final poseerá 
(aprox.) la mitad de los requisitos iniciales 
Estudios anteriores a éste reflejan: 
• El 45% de los errores tienen su origen en los requisitos y en el diseño preliminar 
• El 56% de los errores que tienen lugar en un proyecto software se deben a una mala 
especificación de requisitos 
Según el “Chaos Report” los factores principales que conducen al fracaso en los proyectos software 
son: 
• Falta de comunicación con los usuarios 
• Requisitos incompletos 
• Cambios a los requisitos 
Por otra parte la evidencia demuestra que: 
• Los requisitos contienen demasiados errores 
• Muchos de estos errores no se detectan al principio 
• Muchos de estos errores podrían ser detectados al principio 
• No detectar errores incrementa los costos (tiempo y dinero) de forma exponencial 
Y esto trae como consecuencia que: 
• El sistema resultante no satisface a los usuarios 
• Se producirán desacuerdos entre usuarios y desarrolladores 
• Puede ser imposible demostrar si el software cumple o no los requisitos 
• Se gastará tiempo y dinero en construir el sistema equivocado 
 
Ante esta situación qué se puede hacer? En primer lugar, se debe tomar conciencia del problema, 
quizá no se conozcan todas las soluciones, pero al menos se conocen los problemas. Quizá no sea posible 
elaborar los requisitos con absoluta perfección, pero se debiera intentar minimizar el impacto de los errores en 
los requisitos y se podría tratar de organizar mejor las tareas relacionadas con los requisitos. Los requisitos 
se sitúan en la frontera socio-técnica de los sistemas, y esa frontera es borrosa, e inconsistente. Según M. 
Jackson los requisitos son: “donde lo formal se encuentra con lo informal”. Los requisitos están vivos, 
emergen, interactúan, cambian, desaparecen… 
 
 
 
1 www.standishgroup.com/chaos.html 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 2 
Ingeniería de Requisitos 
Para remediar en lo posible esta situación, surge la Ingeniería de Requisitos (IR). 
La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar 
y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible. 
La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y 
especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Se crean 
modelos de los requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan 
soluciones alternativas y el modelo completo del análisis es creado. Donald Reifer describe el proceso de 
ingeniería de requisitos del software en el siguiente párrafo: 
La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y 
herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las 
necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las 
necesidades del usuario. Todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no 
se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso 
sistemático de aproximaciones contrastadas. 
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos del 
software. El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y 
comportamiento, en detalles concretos. El desarrollador actúa como un interrogador, como consultor, como 
persona que resuelve problemas y como negociador. 
 
¿Qué es? 
El papel global del software en un gran sistema es identificado durante la ingeniería del sistema. De 
cualquier manera, es necesario considerar una visión lo más profunda posible del papel del software, para 
comprender los requisitos específicos que deben ser considerados en la construcción de un software de alta 
calidad. Este es el trabajo del análisis de requisitos del software. Para realizar el trabajo adecuadamente, se 
deben seguir un conjunto de conceptos y principios fundamentales. 
¿Quién lo hace? 
Generalmente, el ingeniero del software es quién realiza el análisis de requisitos. En cualquier caso, 
para aplicaciones de negocio complejas, un «analista de sistemas» —formado en los aspectos del negocio 
del dominio de la aplicación— puede realizar esta tarea. 
¿Por qué es importante? 
Si no se analiza, es muy probable que se construya una solución software muy elegante que resuelva 
incorrectamente el problema. El resultado es tiempo y dinero perdido, frustración personal y clientes 
descontentos. 
¿Cuáles son los pasos? 
Los requisitos de datos, funciones y comportamiento son identificados por la obtención de 
información facilitada por el cliente. Los requisitos son refinados y analizados para verificar su claridad, 
completitud y consistencia. La especificación se incorpora al modelo del software y es validada tanto por el 
ingeniero del software como por los clientes/usuarios. 
¿Cuál es el producto obtenido? 
Una representación efectiva del software debe ser producida como una consecuencia del análisis de 
requisitos. Tanto los requisitos del sistema como los requisitos del software pueden ser representados 
utilizando un prototipo, una especificación o un modelo simbólico. 
¿Cómo puedo estar seguro de que lo he hecho correctamente? 
El resultado obtenido del análisis de requisitos del software debe ser revisado para conseguir: 
claridad, completitud y consistencia. 
 
 
 
 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 3 
Requisitos 
 
Se considerará que un problema sw consiste en configurar una máquina M para que ejerza unos efectos R en 
un dominio D 
 
La máquina M es la que realizará los requisitos R gracias a su conexión con D. En la fase de requisitos solo 
necesitamos describir las conexiones de M con D, es decir el comportamiento externo de M (M-ex), sin detalles 
internos (M-int). 
 
En IR se denominan requisitos a los tres conjuntos M-ex, R y D, la razón es que los requisitos están 
constituidos por toda aquella información que sirva para construir un sistema que satisfaga las metas 
perseguidas. 
 
Ejemplo 
 
Este ejemplo está basado en un caso real, y demuestra que los Requisitos(metas, deseos), no son suficientes 
si no se encuentran basados en un contexto: 
Se trata de especificar un software para un sistema de avión. En estos sistemas hay un requisito que 
establece, que la marcha atrás sólo puede ser habilitada sí y solo sí el avión se encuentra en la pista. Es decir: 
 
R: marcha_atras-habilitada → avión_en_pista 
 
Para detectar si el avión se encuentra o no en pista, existen unos sensores conectados a las ruedas, que 
generan pulsos eléctricos, cuando las ruedas están girando. Para que este mecanismo funcione, se supone 
que en el dominio que rodea al software (o sea, en el mundo real) se cumple que “las ruedas rotan cuando se 
encuentran en pista y que se envían los pulsos cuando las ruedas rotan” 
 
D1: pulsos_sensor → ruedas_rotando 
D2: ruedas_rotando → avión_en_pista 
 
Las dos afirmaciones no son requisitos, sino descripciones. 
Finalmente, la descripción del comportamiento externo de la máquina M (en realidad el comportamiento 
externo del software, M-ex), establecería que 
 
M-ex: marcha_atras_habilitada →pulsos_sensor 
 
Puede comprobarse que dado el comportamiento externo de la Máquina M-ex y dadas las descripciones D, 
se cumple R. 
 
La importancia del conocimiento del dominio D, es crucial en la IR. Si se diera el caso (como sucedió en la 
realidad) que la pista estuviese mojada (aquaplaning) y por lo tanto las ruedas dejaran de rotar, deja de 
cumplirse D2, las ruedas no rotan a pesar de que el avión está en la pista. Por lo tanto, un pequeño cambio 
en el Dominio, pese a no hallarse aparentemente conectado con el software, puede conducir a una situación 
en la que R no se cumple. 
 
En IR se denominan “requisitos” a los tres conjuntos R, M-ex y D. La razón es que los requisitos están 
constituidos por toda la información necesaria para construir un sistema que satisfaga las metas perseguidas. 
 
Los requisitos no son análisis top-down, ni son la arquitectura del sistema, ni son el “qué” frente al “cómo”. 
 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 4 
Determinación e Identificación de requisitos 
 
El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero 
las apariencias engañan. Abundan las ocasiones para las malas interpretaciones o falta de información. Es 
muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse 
muy bien repitiendo la famosa frase de un cliente anónimo: «Sé que cree que entendió lo que piensa que dije, 
pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir.» 
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la 
definición del software a nivel sistema y el diseño del software 
El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales 
del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y 
establece las restricciones que debe cumplir el software. 
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: 
(1) reconocimiento del problema 
(2) evaluación y síntesis 
(3) modelado 
(4) especificación 
(5) revisión. 
 
Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto 
de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software 
que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la 
comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El 
objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el 
cliente/usuario. 
 
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en 
el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y 
contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento 
del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la 
interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para 
describir el problema de manera que se pueda sintetizar un enfoque o solución global. 
 
Por ejemplo, un mayorista de repuestos de automóviles necesita un sistema de control de inventario. 
El analista averigua que los problemas del sistema manual que se emplea actualmente son: 
(1) incapacidad de obtener rápidamente el estado de un componente 
(2) dos o tres días de media para actualizar un archivo a base de tarjetas; 
(3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a 
los vendedores con los componentes. 
Una vez que se han identificado los problemas, el analista determina qué información va a producir 
el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe 
diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica 
que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del 
inventario. 
 
 
 
 
 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 5 
 
 
Una vez evaluados los problemas actuales y la información deseada (entrada y salida), el analista 
empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de 
tratamiento y el comportamiento del sistema. 
 
Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la 
implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en 
el Plan del Software'? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está 
justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta 
que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software 
para posteriores fases de desarrollo. 
 
A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» 
y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué 
interfaces se definen y qué restricciones son aplicables? 
 
Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en 
un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento 
operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y 
como base para la creación de una especificación del software. 
 
El Proceso de los Requisitos 
 
El proceso de Ingeniería de Requisitos es un conjunto estructurado de actividades que sirven para 
derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware + software). 
 
De acuerdo con los estándares definidos por la IEEE la especificación estándar de requerimientos 
de software debe contener los siguientes elementos: 
 
• Descripción de la Funcionalidad de la Aplicación. 
• Descripción de la relación de la Aplicación con Sistemas e Interfaces Externas. 
• Descripción de las métricas deDesempeño del Sistema (Velocidad, disponibilidad, tiempos 
de respuesta y mantenibilidad). 
• Limitaciones de la implementación (Lenguaje de desarrollo, políticas de Base de Datos, 
Sistemas Operativos y otros Recursos utilizados). 
 
Las tareas que conlleva este proceso, a grandes rasgos, se representan en el siguiente gráfico: 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 6 
 
 
 
 
Los cuadros redondeados son tareas. Los cuadros son productos (inputs o outputs). La separación 
que se muestra es más conceptual que real ya que las tareas que se ejecutan durante el proceso de requisitos 
suceden en paralelo y se solapan unas con otras. Por ejemplo durante el proceso de Educción de Requisitos 
empleando prototipado, es inevitable realizar una pequeña validación de los requisitos que se van obteniendo, 
o incluso una pequeña negociación, si por ejemplo estamos tratando con varios usuarios a la vez. 
 
 
IDENTIFICACIÓN DE REQUISITOS PARA EL SOFTWARE 
 
Antes que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a 
través de un proceso de obtención. La educción de requisitos se refiere a la captura y descubrimiento de los 
requisitos. Es una actividad más “humana” que técnica, en la que se identifica a los interesados y se 
establecen las primeras relaciones entre ellos y el equipo de desarrollo: “Un cliente tiene un problema que 
pretende sea resuelto con una solución basada en computadora. Un desarrollador responde a la solicitud de 
ayuda del cliente. La comunicación ha empezado. Pero el camino de la comunicación al entendimiento está a 
menudo lleno de baches.” 
 
Principales fuentes de requisitos 
 
 Los requisitos pueden proceder de: 
• Metas: factores críticos de éxito 
• Conocimiento del dominio de la aplicación 
• Los interesados. Los afectados por el sistema 
• El entorno físico que rodea al sistema 
• El entorno organizacional. Los procesos de negocio. 
 
Inicio del proceso 
 
La técnica de obtención de requisitos (educción) más usada, es la de llevar a cabo una reunión o 
entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) y el cliente puede 
compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están 
preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener 
expectativas radicalmente diferentes); los dos están deseando que aquello termine, pero, al mismo tiempo, 
ambos desean que la cita sea un éxito. 
 
Sin embargo, hay que empezar la comunicación. Gause y Weinberg [GAU89] sugieren que el 
analista empiece preguntando cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarán a 
un entendimiento básico del problema, qué solución busca, la naturaleza de la solución que se desea y la 
Educción de 
Requisitos 
Análisis y 
Negociación 
Documentación 
de Requisitos 
Educción de 
Requisitos 
Necesidades 
Información del Dominio 
Estándares 
Documento de 
Requisitos 
GESTION DE REQUISITOS 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 7 
efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, 
los objetivos generales y los beneficios esperados. 
 
Por ejemplo, el analista podría preguntar: 
• ¿Quién está detrás de la solicitud de este trabajo? 
• ¿Quién utilizará la solución? 
• ¿Cuál será el beneficio económico del éxito de una solución? 
• ¿Hay alguna otra alternativa para la solución que necesita? 
 
Estas preguntas ayudan a identificar todos los participantes que tienen un interés en el software a 
construir. Además, las preguntas identifican los beneficios medibles en una implementación correcta de 
posibles alternativas para un desarrollo normal del software. 
El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente 
comentar sus opiniones sobre la solución: 
• ¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena solución? 
• ¿A qué tipo de problema(s) va dirigida esta solución? 
• ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? 
• ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la 
solución? 
 
El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg las denominan 
«meta-preguntas» y proponen la siguiente lista (abreviada): 
¿Es usted la persona adecuada para responder a estas preguntas? 
¿Sus respuestas son «oficiales»? 
¿Estoy preguntando demasiado? 
¿Hay alguien más que pueda proporcionar información adicional? 
¿Hay algo más que debería preguntarle? 
 
Estas preguntas (y otras) ayudarán a «romper el hielo» e iniciar la comunicación tan esencial para el éxito del 
análisis. Pero el formato de reunión tipo «pregunta y respuesta» no es un enfoque que haya tenido mucho 
éxito. De hecho, esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro 
y sustituirse después por una modalidad que combine elementos de resolución del problema, negociación y 
especificación. En la siguiente sección se presenta un enfoque a reuniones de este tipo. 
 
Técnicas para facilitar las especificaciones de una aplicación 
 
Entre las técnicas destacadas para la educción de requisitos, hallamos: 
• Entrevistas: que es el método tradicional 
• Escenarios: los requisitos se situan en el contexto de uso del sistema 
• Prototipado: cuando la incertidumbre es total acerca del futuro del sistema. De los cuales 
hay dos tipos principales, Evolutivo y De Desecho (muchas veces desarrollados con 
diapositivas) 
Técnica TFEA 
 
Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros 
y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho 
su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, 
documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona 
muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena 
relación de trabajo. 
 
Con estos problemas en mente es por lo que algunos investigadores independientes han 
desarrollado un enfoque orientado al equipo para la reunión de requisitos que se aplica durante las primeras 
fases del análisis y especificación. Denominadas Técnicas para facilitar las especificaciones de la aplicación 
(TFEA), este enfoque es partidario de la creación de un equipo conjunto de clientes y desarrolladores que 
trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar 
un conjunto preliminar de requisitos de la solución. Hoy en día, las TFEA son empleadas de forma general por 
los sistemas de información, pero la técnica ofrece un potencial de mejora en aplicaciones de todo tipo. 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 8 
 
Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente 
diferente, pero todos aplican alguna variación en las siguientes directrices básicas: 
• La reunión se celebra en un lugar neutral y acuden tanto los clientescomo los desarrolladores. 
• se establecen normas de preparación y de participación. 
• se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero 
lo suficientemente informal como para animar el libre flujo de ideas. 
• Un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la reunión. 
• Se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o pizarras). 
• El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y 
especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar 
el objetivo. 
 
Para comprender mejor el flujo de acontecimientos tal y como ocurren en una reunión TFEA, 
presentamos un pequeño escenario que esboza la secuencia de acontecimientos que llevan a la reunión, los 
que ocurren en la reunión y los que la siguen. 
 
En las reuniones iniciales entre el desarrollador y el cliente, se dan preguntas y respuestas básicas 
que ayudan a establecer el ámbito del problema y la percepción global de una solución. Fuera de estas 
reuniones iniciales, el cliente y el desarrollador escriben una «solicitud de producto» de una o dos páginas. Se 
selecciona lugar, fecha y hora de reunión TFEA2 y se elige un coordinador. Se invita a participar a 
representantes de ambas organizaciones; la del cliente y la de desarrollo. Se distribuye la solicitud de producto 
a los asistentes antes de la fecha de reunión. 
 
Mientras se revisa la solicitud días antes de la reunión, se pide a todos los asistentes que hagan una 
lista de objetos que formen parte del entorno del sistema, otros objetos que debe producir el sistema y objetos 
que usa el sistema para desarrollar sus funciones. Además, se pide a todos los asistentes que hagan otra lista 
de servicios (procesos o funciones) que manipulan o interactúan con los objetos. 
Finalmente, se desarrollan también listas de restricciones (por ejemplo, costes, tamaño, peso) y criterios de 
rendimiento (por ejemplo, velocidad, precisión). Se informa a los asistentes que no se espera que las listas 
sean exhaustivas, pero que sí que reflejen su punto de vista del sistema. 
 
Por ejemplo, imagínese que a un equipo de trabajo TFEA de una compañía de productos para el 
consumidor se le ha dado la siguiente descripción del producto: 
“Nuestras investigaciones indican que el mercado de sistemas de seguridad para el hogar está creciendo a un 
ritmo del 40 por 100 anual. Nos gustaría entrar en este mercado construyendo un sistema de seguridad para el 
hogar basado en un microprocesador que proteja y/o reconozca varias situaciones indeseables tales como 
irrupciones ilegales, fuego, inundaciones y otras. El producto, provisionalmente llamado Hogar Seguro, utilizará los 
sensores adecuados para detectar cada situación, puede programarse por el propietario del hogar y llamará 
automáticamente a una agencia de vigilancia cuando se detecte alguna de estas situaciones.” 
 
En realidad, se proporcionaría considerablemente más información en esta fase. 
Pero incluso con información adicional, habría ambigüedades presentes, existirán omisiones 
probablemente y podrían ocurrir errores. Por ahora, la «descripción de producto» anterior bastará. 
 
El equipo TFEA está compuesto por representantes de marketing, ingeniería del software y del 
hardware, y de la fabricación también participará un coordinador externo. 
 
Todos los componentes del equipo TFEA desarrollan las listas descritas anteriormente. Los objetos 
descritos para HogarSeguro podrían incluir detectores de humo, sensores de ventanas y puertas, detectores 
de movimientos, una alarma, un acontecimiento (se ha activado un sensor), un panel de control, una pantalla, 
números de teléfono, una llamada de teléfono, etc. La lista de servicios podría incluir la instalación de la alarma, 
vigilancia de los sensores, marcado de teléfono, programación del panel de control y lectura de la pantalla 
(fíjese que los servicios actúan sobre los objetos). De igual manera, todos los asistentes TFEA desarrollarán 
una lista de restricciones (por ejemplo, el sistema debe tener un coste de fabricación de menos de $10.000, 
 
2 Dos de los enfoques más populares de TFEA son Desarrollo Conjunto de Aplicaciones/UAD), desarrollado por IBM, y The METHOD, 
desarrollado por Performance Resources, Irte, Falls Church, VA. 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 9 
debe tener una «interfaz amigable» con el usuario y debe conectar directamente con una línea telefónica 
estándar) y de criterios de rendimiento (por ejemplo, un acontecimiento detectado por un sensor debe 
reconocerse en un segundo; se debería implementar un esquema de prioridad de acontecimientos). 
 
Cuando empieza la reunión TFEA, el primer tema de estudio es la necesidad y justificación del nuevo 
producto, pues todo el mundo debería estar de acuerdo en que el desarrollo (o adquisición) del producto está 
justificada. Una vez que se ha conseguido el acuerdo, cada participante presenta sus listas para su estudio. 
Las listas pueden exponerse en las paredes de la habitación usando largas hojas de papel, pinchadas o 
pegadas, o escritas en una pizarra. Idealmente debería poderse manejar separadamente cada entrada de las 
listas para poder combinarlas, borrarlas o añadir otras. En esta fase, está estrictamente prohibido, el debate o 
las críticas. 
 
Una vez que se han presentado las listas individuales sobre un tema, el grupo crea una lista 
combinada. La lista combinada elimina las entradas redundantes y añade las ideas nuevas que se les ocurran 
durante la presentación, pero no se elimina nada más. Cuando se han creado las listas combinadas de todos 
los temas, sigue el estudio —moderado por el coordinador—. La lista combinada es ordenada, ampliada o 
redactada de nuevo para reflejar apropiadamente el producto o sistema que se va a desarrollar. El objetivo es 
desarrollar una lista de consenso por cada tema (objetos, servicios, restricciones y rendimiento). Después 
estas listas se ponen aparte para utilizarlas posteriormente. 
 
Una vez que se han completado las listas de consenso, el equipo se divide en subequipos; cada uno 
trabaja para desarrollar una mini-especificación de una o más entradas de cada lista. La mini-especificación 
es una elaboración de la palabra o frase contenida en una lista. Por ejemplo, la mini-especificación del objeto 
panel de control de HogarSeguro podría ser: montado en la pared; tamaño aproximado 23 * 13 centímetros; 
contiene el teclado estándar de 12 teclas y teclas especiales; contiene una pantalla LCD de la forma mostrada 
en el bosquejo (no presentado aquí); toda la interacción del cliente se hace a través de las teclas usadas para 
activar o desactivar el sistema; software para proporcionar una directriz de empleo, recordatorios, etc., 
conectado a todos los sensores. 
 
Cada subequipo presenta entonces sus mini-especificaciones a todos los asistentesTFEA para 
estudiarlas. Se realizan nuevos añadidos, eliminaciones y se sigue elaborando. En algunos casos, el desarrollo 
de algunas mini-especificaciones descubrirá nuevos objetos, servicios, restricciones o requisitos de 
rendimiento que se añadirán a las listas originales. Durante todos los estudios, el equipo sacará a relucir 
aspectos que no podrán resolverse durante la reunión. Se hará una lista de estas ideas para tratarlas más 
adelante. 
 
Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una lista 
de criterios de validación del producto/sistema y presenta su lista al equipo. Se crea así una lista de consenso 
de criterios de validación.Finalmente, uno o más participantes (o algún tercero) es asignado para escribir el 
borrador entero de especificación con todo lo expuesto en la reunión TFEA. 
 
TFEA no es la panacea para los problemas que se encuentran en las primeras reuniones de 
requisitos, pero el enfoque de equipo proporciona las ventajas de muchos puntos de vista, estudio y 
refinamiento instantáneo y un paso adelante hacia el desarrollo de una especificación. 
 
Problemas con la educción 
 
Entre los principales problemas que pueden entorpecer la tarea de la educción de requisitos se 
cuentan los siguientes: 
• Los usuarios no pueden /saben describir sus tareas 
• Mucha información importante no llega a verbalizarse 
• La educción se afronta como un proceso pasivo, cuando debería ser un proceso cooperativo. 
 
 
 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 10 
¿Cómo escribir requisitos? 
 
Y se ha mencionado que los requisitos constituyen la base de la comunicación entre todas las partes 
interesadas en el desarrollo del sistema: usuarios, clientes, desarrolladores y el equipo encargado de realizar 
las pruebas. Todas estas personas forman un conjunto heterogéneo, lo cual provoca que “la mejor forma” de 
escribir requisitos no exista. Lo que para unos puede ser un lenguaje muy preciso, para otros puede ser un 
lenguaje incomprensible. 
Debido a esto en la práctica, lo más utilizado es el lenguaje natural a pesar de su inherente 
ambigüedad. Se acostumbra a especificar cada requisito como una frase corta (“el sistema hará X…”, “se 
facilitará X…”, etc.). También se utiliza el lenguaje natural complementado con diagramas y/o notaciones 
formales. La notación utilizada depende de quien leerá o quien escribirá los requisitos. 
 
Ejemplos: 
1. El sistema mantendrá la temperatura de la caldera entre 70 y 80 grados 
2. El sistema mantendrá un registro de todos los materiales de la biblioteca, incluyendo libros, 
periódicos, revistas, videos y CDRoms. 
3. El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN. 
4. La interface de usuario se implementará sobre un navegador Web. 
5. El sistema deberá soportar al menos 20 transacciones por segundo 
6. El sistema permitirá que los nuevos usuarios se familiaricen con su uso en menos de 15 minutos 
 
Aquí puede verse que los requisitos son de muy distintos tipos: 
• Requisitos que definen efectos sobre el entorno (1) 
• Requisitos muy generales 
• Requisitos funcionales (3) 
• Requisitos de implementación (4) 
• Requisitos de rendimiento (5) 
• Requisitos de usabilidad (6) 
 
Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma estándar 
de escribirlos. Tampoco es posible decir cuál es la “mejor forma” de especificarlos. Todo depende de quien 
los escribe, quién los va a leer, el dominio de la aplicación, etc. 
 
Requisitos en negativo 
 
Tan importante como decir lo que el sistema debe hacer, es decir lo que el sistema NO debe hacer. 
Estos requisitos “en negativo” limitan el ámbito del sistema. Las razones son varias: 
• En primer lugar, dicen donde NO se deben emplear recursos 
• Por otro lado, especificar lo que el sistema no hará es fundamental para sistemas críticos 
(es decir, sistemas en los que un fallo puede provocar un accidente). Se trata de especificar 
cómo el sistema evitará la aparición de situaciones potencialmente peligrosas. 
 
Requisitos Funcionales y No Funcionales 
 
Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema. Por 
ejemplo: “El sistema aceptará pagos con VISA” 
Los requisitos funcionales son restricciones sobre los requisitos funcionales. Por ejemplo:”El 
Sistema aceptará pagos con VISA de forma segura y con tiempo de respuesta menor a 5 segundos.” 
Pero el siguiente, muchas veces resulta arbitrario: “”El Sistema aceptará pagos con VISA a través 
del protocolo SET”. En este caso, lo que aparentemente es un requisito funcional, está determinado, en el 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 11 
fondo por una serie de características no funcionales (características que hacen que el protocolo SET sea el 
más adecuado para los objetivos perseguidos). 
 
Modelización de requisitos 
 
Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, 
de interacción, de objetos, etc. La meta es entender mejor el problema, más que iniciar el diseño de la solución 
(idealmente). El tipo de modelo elegido depende de: 
• La naturaleza del problema 
• La experiencia del modelizador 
• La disponibilidad de herramientas 
• La imposición del cliente de una notación determinada. 
 
Negociación de Requisitos 
 
En todo proceso de IR intervienen distintos individuos con distintos, y a veces enfrentados intereses. 
Estos conflictos entre requisitos se descubren durante el análisis. Todo conflicto descubierto debería disparar 
un proceso de (re)negociación, es decir, los conflictos nunca se deben resolver “por decreto”. 
Desde este punto de vista, los conflictos son positivos, pues son fuente de NUEVOS REQUISITOS. 
Los acuerdos alcanzados deben ser convenientemente anotados, favoreciéndose asi la trazabilidad de los 
requisitos a sus orígenes (“el requisito 987 surge como resultado de la reunión entre X y Z el día tal…”) 
 
Documento de Requisitos 
 
El llamado “Documento de Requisitos” es el modo habitual de guardar y comunicar los requisitos. 
Debe tenerse en cuenta que al decir “documento”, nos referimos a cualquier medio electrónico de 
almacenamiento y distribución de información como por ejemplo: 
• Procesador de textos 
• Bases de datos 
• Herramientas de Gestión de Requisitos 
 
En general, es buena práctica utilizar, al menos dos documentos, a distinto nivel de detalle: 
1. DRU: Documento de Requisitos de Usuario 
2. ERS: Especificacion de Requisitos de Software 
 
La pregunta que surge es: En que se diferencian los requisitos de usuario de los requisitos de 
software? A grandes rasgos se puede afirmar que: 
• El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los 
requisitos de usuario, contenidos en el DRU, no poseen demasiado nivel de detalle. Se 
incluye la descripción del problema actual (razones por las que el sistema de trabajo actual 
es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema. 
• La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software 
contenidos en la ERS son más detallados. Contiene la respuesta a la pregunta ¿Qué 
características debe poseer un sistema que nos permita alcanzar los objetivos y evitar los 
problemas expuestos en la DRU? 
Estándares 
 
Los documentos estándares más conocidos de especificación de requisitos son: 
• IEEE 830 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 12 
• PSS-05 de la Agencia Espacial Europea (ESA). Las herramientas de gestión de requisitos 
permiten generar documentación en los anteriores formatos, a partir de una base de datos 
de requisitos 
 
Características deseables de una ERS 
 
Una ERS de calidad debería presentar, dentro de lo posible, las siguientes características: 
• No ambigua: la ERS es noambigua si todo requisito posee una sola interpretación. 
• Completa: Una ERS es completa si todo lo que se supone que el software debe hacer está 
incluido en la ERS. Por completitud, deberían describirse todas las posibles respuestas a 
todas las posibles entradas y en todas las situaciones posibles. Además, la ERS no 
contendrá secciones de tipo “por determinar…” 
• Correcta: todo requisito de la ERS contribuye a satisfacer una necesidad real 
• Comprensible: todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de pruebas, 
gestores, etc) entienden la ERS 
• Verificable: si para cada requisito expresado en la ERS existe un procedimiento de prueba 
finito y no costoso para demostrar que el futuro sistema lo satisface 
• Internamente Consistente: no existen subconjuntos de requisitos contradictorios 
• Externamente Consistente: ninguno de los requisitos está en contradicción con lo expresado 
en documentos de nivel superior. Por ejemplo los requisitos del software no pueden 
contradecir los requisitos del sistema. 
• Realizable: si dados los actuales recursos la ERS es implementable 
• Concisa: la ERS debe ser lo más breve posible, sin que esto afecte al resto de atributos de 
calidad 
• Independiente del Diseño: existen más de un diseño e implementación que realizan la ERS. 
Para ello la ERS debiera limitarse a describir el comportamiento externo del sistema. 
• Trazable: cada requisito se puede referenciar de forma unívoca. Es fundamental para 
precisar qué requisitos son implementados por que componente del diseño, lo cual es 
imprescindible a la hora de realizar las pruebas de dicho componente. 
• Modificable: los cambios son fáciles de introducir 
• Electrónicamente almacenada: se encuentra en un archivo de texto, en una base de datos 
o, mejor aún, ha sido creada con una herramienta de Gestión de Requisitos (RequisitePro, 
Doors, etc) 
• Ejecutable/Interpretable/Prototipable/Animable: si existe una herramienta software que, 
recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan 
solo a ciertas notaciones como las notaciones formales o los diagramas de transición de 
estados. 
• Anotada por importancia relativa: si los requisitos se clasifican según su importancia. Como 
mínimo un requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sire para no asignar 
demasiados recursos a la implementación de requisitos no esenciales. 
• Anotada por estabilidad relativa: los requisitos son, en general, inestables y volátiles. A cada 
requisito se le asigna una probabilidad de cambio (Alta, Media o Baja). 
• Anotada por versión: si un lector de la ERS puede determinar qué requisitos serán 
satisfechos por qué versión del producto. 
• No redundante: cada requisito se expresa en un solo lugar de la ERS. La redundancia de 
todas formas, no es del todo mala si aumenta la legibilidad 
• Nivel de Abstracción: al nivel adecuado, ni demasiado detallada ni demasiado vaga 
• Precisa: una ERS es precisa si hace uso de valores numéricos para precisar características 
del sistema. La precisión es aplicable, ante todo, a los requisitos no funcionales. Por 
ejemplo, no es útil decir: ¡“el tiempo de respuesta será más bien rápido!, sino “El tiempo de 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 13 
respuesta será menor a dos segundos” (esto es fuertemente dependiente de la tecnología 
disponible, que no siempre se conoce al principio del proyecto). 
• Reutilizable: si ciertas secciones de la ERS se pueden reutilizar 
• Trazada: sin está claro el origen de cada requisito (quien o que pide) 
• Con referencias cruzadas: si se utilizan referencias entre requisitos relacionados o entre 
otras secciones 
 
Para lograr los objetivos y resultados anteriormente descritos, será necesario el seguimiento de un 
proceso estructurado que finalizará con la elaboración y verificación de los artefactos de salida descritos a 
continuación: 
• Documento de definición de Actores del Sistema 
• Documento de Casos de Uso del Sistema 
• Documento de Especificación Detallada de Casos de Uso 
• Documento de definición de Requerimientos No Funcionales. 
 
1. Criterios de inicio o criterios de entrada 
Este proceso se inicia luego de la aprobación del Acta de Inicio del proyecto para el desarrollo del Sistema 
para el seguimiento de la gestión de proyectos de Software. 
Adicionalmente se cuenta con el enunciado general de requerimientos del proyecto, a partir del cual se 
desarrollará el proceso de especificación. 
También se realiza la definición de las diferentes plantillas para los documentos de actores, casos de uso y 
especificación detallada, y se definen los ítems incluidos en el documento de requerimientos no funcionales. 
 
2. Objetivo del proceso 
El objetivo principal del proceso de especificación es lograr definir de forma clara y precisa cada uno de los 
requerimientos del Sistema para el seguimiento de la gestión de proyectos de desarrollo de Software. 
El seguimiento adecuado del proceso además nos permitirá: 
• Disminuir el número de defectos encontrados en la fase de implementación del producto de software. 
• Realizar la fase de implementación de forma ágil y con la seguridad de estar desarrollando 
exactamente las necesidades del cliente. 
• Lograr un dimensionamiento adecuado del tamaño del sistema. 
 
Como resultado final del proceso de especificación deben quedar elaborados, validados y verificados los 
siguientes entregables: 
• Documento de definición de Actores del Sistema 
• Documento de Casos de Uso del Sistema 
• Documento de Especificación Detallada de Casos de Uso 
• Documento de definición de Requerimientos No Funcionales 
 
3. Responsables del Proceso 
El proceso de especificación será desarrollado conjuntamente por todo el equipo de trabajo, realizando una 
distribución equitativa de cargas de trabajo. El proceso estará dirigido por el líder del proyecto y el 
aseguramiento de la calidad estará a cargo del Líder de Calidad. 
 
4. Entradas 
Las siguientes son las actividades que se deben ejecutar durante el proceso de Especificación de 
Requerimientos 
• Enunciado del trabajo del Proyecto: 
El enunciado del trabajo es la entrada que describe la oportunidad o necesidad de negocio que la 
organización ha identificado y por la cual se dio origen al proyecto. Adicionalmente, indica el alcance 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 14 
y los requisitos del producto los cuales servirán de apoyo para los procesos posteriores principalmente 
al proceso de planeación. 
• Acta de constitución: 
El acta de constitución, contiene información de los objetivos, alcance, restricciones y demás, que se 
deben tener en cuenta para la planeación del proyecto. 
• Formatos establecidos para la especificación: 
Son las plantillas definidas para construir los documentos involucrados en este proceso. Las plantillas 
son: 
o Plantilla de Actores del Sistema: En esta plantilla se realizará la descripción de los actores que 
interactúan con el sistema. Para esto se utilizará el formato 
ESPECIFICACION_ACTORES_SISTEMA.doc 
o Plantilla de especificación de requerimientos funcionales: En esta plantilla se especifica de forma 
detallada el formato de cada uno de los casos de uso que componen el sistema. Para esto se propone 
el formato ESPECIFICACION_DETALLADA_CASO_USO.doc 
o Documento de especificación de requerimientos no funcionales: En este documento se 
especificaránlos requerimientos no funcionales del sistema Este documento contará con las 
siguientes secciones: 
 
REQUERIMIENTOS NO FUNCIONALES MANIFIESTOS. 
Desempeño 
Disponibilidad 
Usabilidad 
 
REQUERIMIENTOS NO FUNCIONALES OPERACIONALES 
Robustez 
Escalabilidad 
Seguridad 
Interoperabilidad 
 
 REQUERIMIENTOS NO FUNCIONALES DE DESARROLLO 
Base De Datos 
Servidor Web De Aplicaciones 
Navegador Web 
Máquina Virtual De Java 
 
5. Actividades 
Las siguientes son las actividades que se deben ejecutar durante el proceso de Especificación de 
Requerimientos. 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 15 
6.Identificación de los 
Requerimientos No 
Funcionales del Sistema
Enunciado del 
proyecto 
Formatos 
Establecidos 
para 
Especificación
Documento de 
Especificación de 
Requerimientos 
No Funcionales
 Acta de 
Constitrución
3.Identificación de 
módulos del sistema y / 
o Procesos de Negocio
1.Análisis inicial del 
mundo del Sistema.
Documento de 
Especificación de 
Módulos del 
Sistema
4.Identificación de todos 
los Actores que 
componen el Sistema
5.Identificación detallada 
de Casos de Uso del 
Sistema
Documento de 
Casos de Uso 
del Sistema
6.Especificación 
detallada de 
Requerimientos
Documento de 
Actores del 
Sistema
Documento de 
Especificación 
detallada de 
Casos de Uso
Acta de 
Aprobación de la 
Especificación
2.Identificación general 
de los Requerimientos 
Funcionales del Sistema
Administración de 
Requerimientos 
(Controles de Cambios)
 
 
Figura. 1 Diagrama Actividades Proceso de Especificación de Requerimientos 
 
 
 
 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 16 
• Análisis del mundo del sistema 
a. Descripción: Realizar un análisis preliminar del mundo del sistema.. 
b. Resultado: Descripción del mundo del sistema. 
c. Responsable: Líder del Proyecto 
d. Participantes: Líder de Soporte. 
 
• Identificación de Módulos del Sistema y/o Procesos de Negocio 
a. Descripción: Identificar los módulos que conforman el sistema y elaborar el documento que los 
describe. 
b. Resultado: Documento de Módulos del Sistema 
c. Responsable: Líder del Proyecto 
d. Participantes: Líder de Soporte. 
 
• Identificación de todos los actores que componen el Sistema 
a. Descripción: Identificar los actores que intervienen en el sistema y elaborar el correspondiente 
Documento de Actores del Sistema 
b. Resultado: Documento de Actores del Sistema 
c. Responsable: Líder del Proyecto 
d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto. 
 
• Identificación de Casos de Uso del Sistema 
a. Descripción: Identificar los casos de Uso que componen el Sistema y elaborar el respectivo 
documento. 
b. Resultado: Elaboración del documento de Casos de Uso del Sistema. 
c. Responsable: Líder del Proyecto 
d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto 
 
• Especificación detallada de Requerimientos Funcionales 
a. Descripción: Elaboración de los documentos de especificación detallada de Casos de Uso. 
b. Resultado: Documento de Especificación detallada de Casos de Uso. 
c. Responsable: Líder del Proyecto 
d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto 
 
• Especificación de Requerimientos No Funcionales 
a. Descripción: Elaboración del Documento de Especificación de Requerimientos No Funcionales del 
Sistema. 
b. Resultado: Documento de Especificación de Documentos No Funcionales del Sistema 
c. Responsable: Líder de Desarrollo 
 
• Acta de Aprobación 
a. Descripción: En este documento se aprueba por parte del Cliente (Profesor y Monitor) y por parte 
del Equipo de Trabajo el proceso de especificación de requerimientos del Sistema. 
b. Resultado: Acta de Aprobación de la Especificación del Sistema, firmada por el Cliente y por el 
equipo de trabajo. 
c. Responsable: Líder del Proyecto. 
d. Participantes: Líder del Proyecto, Profesor, Monitor 
 
• Administración de Requerimientos 
a. Descripción: En este documento se hace el seguimiento sobre el control de cambios realizado 
sobre la especificación de requerimientos. 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 17 
e. Resultado: Documento de Administración de Requerimientos.. 
f. Responsable: Líder del Proyecto. 
g. Participantes: Líder del Proyecto, Líder de Calidad 
 
6. Salidas 
Las siguientes son las salidas del proceso de Especificación de Requerimientos. 
• Documento de Especificación de Módulos del Sistema: 
En este documento se identifican los módulos que componen el Sistema de Información y se da una 
descripción de cada uno de ellos, indicando sus características y principales responsabilidades. 
• Documento de Especificación de Requerimientos Funcionales: 
En este documento se especifica de forma detallada cada uno de los casos de uso que componen el 
sistema. 
• Documento de Requerimientos No Funcionales del Sistema: 
En este documento se especificarán los requerimientos no funcionales del sistema. 
 
7. Criterios de terminación del proceso 
El proceso finaliza una vez se hayan ejecutado todas las actividades definidas y como resultado de la 
revisión del mismo, se firmará la correspondiente Acta de Aprobación de la Especificación del Sistema. 
 
Validación de Requisitos 
 
El objetivo de la validación de requisitos es descubrir problemas en el Documento de Requisitos 
antes de comprometer recursos a su implementación. El documento debe revisarse para: 
• Descubrir omisiones o falta de requisitos 
• Conflictos 
• Ambiguedades 
• Comprobar la calidad del documento y su grado de adhesión a estándares 
 
Revisiones 
Las revisiones del documento de requisitos constituyen la fórmula más empleada en validación. En 
estas revisiones, un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos. 
Tiene tres fases: 
• Busqueda de problemas 
• Reunión 
• Establecimiento de acuerdos 
Como guía para identificar problemas habituales, se pueden utilizar listas de comprobación, 
“checklists”. 
Otros tipos de validación son: 
• Prototipado: permite descubrir con rapidez si el usuario se encuentra satisfecho o no con los 
requisitos 
• Validación de modelos: cuando los requisitos se expresan por medio de modelos (de objetos, 
DFD, etc) 
• Validacion de la “testeabilidad”. El equipo de pruebas debe revisar los requisitos. 
 
Un ejemplo de cuestiones que debieran figurar en una lista de comprobación podría ser: 
• ¿Están todos los requisitos convenientemente numerados? 
• ¿El mismo servicio es solicitado en distintos requisitos? Existen contradicciones entre ellos? 
• ¿Los requisitos relacionados se encuentran agrupados en el documento? 
• ¿Los requisitos son fácilmente comprensibles? Por todo tipo de lectores? 
 
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 18 
Gestión de Requisitos (Requirements Management, RM) 
 
Consiste básicamente, en gestionar los cambios a los requisitos. Asegurala consistencia entre los 
requisitos y el sistema construido (o en construcción). Esta tarea consume grandes cantidades de tiempo y 
esfuerzo y abarca todo el ciclo de vida del producto. 
Es necesario realizar una adecuada gestión de requisitos por una serie de razones, como: 
• Los requisitos son volátiles 
• El entorno físico del sistema cambia 
• Trasladar un sistema de un entrono a otro requiere modificaciones 
• El entorno organizacional cambia 
• Las políticas cambian 
• Cambios en las reglas y en los procesos del negocio provocan cambios en el sistema 
• La propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios 
 
La Gestión de Requisitos implica: 
• Definir procedimientos de cambios: definen los pasos y los análisis que se realizarán antes de aceptar 
los cambios propuestos. 
• Cambiar los atributos de los requisitos afectados 
• Mantener la trazabilidad hacia atrás, hacia adelante y entre requisitos 
• Control de versiones del documento de requisitos 
 
Existen herramientas que han sido desarrolladas específicamente para utilizarlas en las técnicas de gestión 
de requisitos y dominar cualquier tarea asociada con los requisitos. 
 
El uso de este tipo de herramientas permite mejorar la calidad del desarrollo de un proyecto, automatizar 
procesos de la Ingeniería de Requisitos, proporcionar un mayor control en el mantenimiento de los requisitos 
y añadir un beneficio significativo reduciendo posibles errores durante el desarrollo de un proyecto, lo que 
implica en una reducción de costes. 
 
Para facilitarnos la difícil tarea de seleccionar una herramienta de gestión de requisitos adecuada, podemos 
hacer uso de la norma ISO 24766 (Information Technology – Guide for requirements tool capabilites), la cual 
proporciona una orientación sobre las capacidades deseables que debería aportar una herramienta de 
Ingeniería de Requisitos. 
 
 
 
Herramientas Software para la Gestion de Requisitos, consultar: https://www.appvizer.es/organizacion-
planificacion/gestion-requerimientos 
 
 
 
 
 
 
 
 
 
 
 
 
 
http://www.overti.es/tecnologia/283-normas-y-estandares-para-gestion-de-requisitos
https://www.appvizer.es/organizacion-planificacion/gestion-requerimientos
https://www.appvizer.es/organizacion-planificacion/gestion-requerimientos
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I 
 
Prof. Lic. Analía N. Herrera Cognetta 19 
 
 
 
Bibliografía 
 
ROGER PRESSMAN “Ingeniería del software” 5ª edición. 
 
ANDRES SILVA, “Documentación Master en Ingenieria del Software”. UPM, 2000 
 
KOVITZ B. L., “Practical Software Requirements. A Manual 01 Content and Style”. Manning 1999