UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO

Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática

ISI – INGENIERÍA DE SOFTWARE II 2022-II

SEMANA 1: INGENIERÍA DE REQUERIMIENTOS

Entender los requerimientos de un problema es una de las tareas más difíciles que enfrenta
el ingeniero de software. Cuando se piensa por primera vez, no parece tan difícil desarrollar
un entendimiento claro de los requerimientos. Después de todo, ¿acaso no sabe el cliente lo
que se necesita? ¿No deberían tener los usuarios finales una buena comprensión de las
características y funciones que le darán un beneficio? Sorprendentemente, en muchas
instancias la respuesta a estas preguntas es “no”. E incluso si los clientes y los usuarios finales
explican sus necesidades, éstas cambiarán mientras se desarrolla el proyecto.
En el prólogo a un libro escrito por Ralph Young sobre las prácticas eficaces respecto de los
requerimientos, escribe lo siguiente: Es la peor de las pesadillas. Un cliente entra a la oficina,
toma asiento, lo mira a uno fijamente a los ojos y dice: “Sé que cree que entiende lo que digo,
pero lo que usted no entiende es que lo que digo no es lo que quiero decir.” Invariablemente,
esto pasa cuando ya está avanzado el proyecto, después de que se han hecho compromisos
con los plazos de entrega, que hay reputaciones en juego y mucho dinero invertido.

I. INGENIERÍA DE REQUERIMIENTOS

El diseño y construcción de software de computadora es difícil, creativo y

sencillamente divertido. En realidad, elaborar software es tan atractivo que muchos
desarrolladores de software quieren ir directo a él antes de haber tenido el
entendimiento claro de lo que se necesita. Argumentan que las cosas se aclararán a
medida que lo elaboren, que los participantes en el proyecto podrán comprender sus
necesidades sólo después de estudiar las primeras iteraciones del software, que las
cosas cambian tan rápido que cualquier intento de entender los requerimientos en
detalle es una pérdida de tiempo, que las utilidades salen de la producción de un
programa que funcione y que todo lo demás es secundario. Lo que hace que estos
argumentos sean tan seductores es que tienen algunos elementos de verdad. Pero todos
son erróneos y pueden llevar un proyecto de software al fracaso.

El espectro amplio de tareas y técnicas que llevan a entender los requerimientos

se denomina ingeniería de requerimientos. Desde la perspectiva del proceso del
software, la ingeniería de requerimientos es una de las acciones importantes de la
ingeniería de software que comienza durante la actividad de comunicación y continúa
en la de modelado. Debe adaptarse a las necesidades del proceso, del proyecto, del
producto y de las personas que hacen el trabajo.

La ingeniería de requerimientos tiende un puente para el diseño y la construcción. Pero,

¿dónde se origina el puente? Podría argumentarse que principia en los pies de los
participantes en el proyecto (por ejemplo, gerentes, clientes y usuarios), donde se
definen las necesidades del negocio, se describen los escenarios de uso, se delinean las

MSc. Ing. Walter J. Medina L. 1

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

funciones y características y se identifican las restricciones del proyecto. Otros tal vez
sugieran que empieza con una definición más amplia del sistema, donde el software no
es más que un componente del dominio del sistema mayor. Pero sin importar el punto
de arranque, el recorrido por el puente lo lleva a uno muy alto sobre el proyecto, lo que
le permite examinar el contexto del trabajo de software que debe realizarse; las
necesidades específicas que deben abordar el diseño y la construcción; las prioridades
que guían el orden en el que se efectúa el trabajo, y la información, las funciones y los
comportamientos que tendrán un profundo efecto en el diseño resultante.

La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo

que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una
solución razonable, especificar la solución sin ambigüedades, validar la especificación
y administrar los requerimientos a medida que se transforman en un sistema funcional.
Incluye siete tareas diferentes: concepción, indagación, elaboración, negociación,
especificación, validación y administración. Es importante notar que algunas de estas
tareas ocurren en paralelo y que todas se adaptan a las necesidades del proyecto.

II. DETERMINACIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS

Es la etapa que tenemos que cumplir para la construcción de un software. Consiste en

definir o tener bien en claro cuáles son los requerimientos/necesidades/problemas que
se encuentran en los diferentes escenarios que los usuarios identifican en los diversos
procesos que se desarrollan en una área u organización en general. Es la etapa de vital
importancia hacia la implementación de un software de manera eficiente, en ella los
desarrolladores y usuarios deben reunirse las veces que sea necesario a fin de poder
realizar una buena captura de las necesidades de información que tienen estos
últimos, se suelen utilizar diferentes técnicas de recolección de datos, como las
encuestas, los cuestionarios, las entrevistas y la revisión de documentos y en algunos
casos el desarrollador se involucra en los procesos que se llevan a cabo dentro de la
organización.

La captura de requerimientos es de vital importancia debido a que:

- Permite gestionar las necesidades del proyecto en forma estructurada, debido
a que cada actividad tendrá los pasos a seguir.
- Mejora la capacidad de predecir cronogramas de proyecto proporcionando en
punto de partida para controlar actividades específicas.
- Mejora la calidad del software, pues si se cumple con todos los requisitos el
software poseerá lo que el cliente desea por lo tanto tendrá buena calidad.
- Evita rechazo de usuarios finales debido a que obliga a los usuarios a
considerar sus requerimientos cuidadosamente.

MSc. Ing. Walter J. Medina L. 2

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

Usuarios. - Personas o grupos de interés que tienen la necesidad o necesidades de

información; es decir aquellos que necesitan el software a construir.

Desarrolladores. - Son las personas con conocimientos profesionales en software,

informática y sistemas o afines, que serán los encargados de la construcción e
implementación del software en cuestión.

Técnicas de recolección de datos.

En la etapa de determinación y especificación de requerimientos, los usuarios y
desarrolladores deben estar en constante interacción para poder entender con claridad
cuáles son las necesidades que se tienen respecto a los procesos a optimizar que debe
poseer el software que pretendemos implementar. Es en este escenario entonces donde
se hace de vital importancia contar con una forma o mecanismo que ayude a realizar
con éxito esta interacción, para lo cual tenemos que utilizar técnicas de recolección de
datos y cumplir esta etapa con existo, entre las técnicas de las que disponemos para
esto destacan ampliamente las entrevistas.

Entrevista. Es una conversación dirigida entre dos o más personas, donde una de ellas
hace las veces de entrevistador y otro u otros cumplen el rol de entrevistados, se dice
que es dirigida porque la entrevista por lo general tiene que ser planificada es decir se
define por anticipado a quien se tienen que entrevistar, en qué fecha y hora, cuáles son
los objetivos de la entrevista y formular por anticipado las preguntas que constituyen
la base de la entrevista. La entrevista hace posible acercarse a la intimidad de la
conducta social del sujeto.

Modos o formas de estructurar las preguntas en una entrevista:

En lo relacionado a la forma de estructurar las preguntas de una entrevista los expertos
indican que se tiene hasta tres formas de hacerlo: tipo embudo, tipo pirámide y tipo
diamante.
- Estructura embudo. - En esta forma de estructurar la entrevista se debe iniciar
haciendo preguntas abiertas y finalizar la entrevista realizando o formulando
preguntas cerradas.
- Estructura pirámide. - En esta forma la entrevista se debe iniciar haciendo
preguntas cerradas y se finaliza haciendo preguntas abiertas.
- Estructura diamante. - En esta forma la entrevista se tiene que iniciar con
preguntas abiertas, posteriormente cerca de la mitad de la entrevista se deben
realizar preguntas cerradas y luego ir abriendo hasta finalizar con preguntas
abiertas. Según los expertos en este tipo de actividades, esta forma de estructurar
las entrevistas es la más eficiente y aceptada de todas por lo tanto la más
recomendada.

MSc. Ing. Walter J. Medina L. 3

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

III. IDENTIFICACIÓN Y ANÁLISIS DE REQUERIMIENTOS DEL SOFTWARE

La identificación de requerimientos y análisis del software implica las siguientes

actividades:
- Determinación y especificación de requerimientos de los usuarios del software.
- La técnica de recolección de datos, el más usado y recomendado la
ENTREVISTA, en sus diferentes estructuras, detalladas en lìneas anteriores.
- Especificación de los requerimientos del software.

Para desarrollar estas actividades haremos uso de las siguientes tablas:

Análisis de los requerimientos obtenidos por usuario

Entrevistado: Gerente General: Juan ……

Pregunta: Respuesta: Conclusión:

Pregunta 1 Respuesta 1 Conclusión 1

Identificación de procesos – Software (SI)

Proceso: Venta de productos ……

Descripci Actividad Actor Regla Problem

ón es es s de as
negoc
io
Proceso de - Act 1 - Actor 1 -…. -…..
…. - Act 2 … - Act ….. -…. -…...

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.

MSc. Ing. Walter J. Medina L. 4

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

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 ser consistente. 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 cuando los
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.

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, entre otros.

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.

MSc. Ing. Walter J. Medina L. 5

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

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 métricas que se puedan utilizar; el costo
de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy
alto.

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?

MSc. Ing. Walter J. Medina L. 6

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

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 etapa, 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?

Tablas para la clasificación de los requerimientos funcionales, no funcionales y

externos:
Documento de especificación de requerimientos funcionales
Proceso Requerimientos
Gestión del carné único de - Registrar el número de Boucher de pago por
lector. concepto de carné de biblioteca.

MSc. Ing. Walter J. Medina L. 7

 UNIVERSIDAD NACIONAL SANTIAGO ANTÚNEZ DE MAYOLO
Facultad de Ciencias – Escuela Profesional de Ingeniería de Sistemas e Informática
ISI – INGENIERÍA DE SOFTWARE II 2022-II

- Mostrar los requisitos para la adquisición de carné de

biblioteca.
- Registrar los requisitos que presento el lector
solicitante.
- Registrar la ficha de datos del lector.

Documento de especificación de requerimientos no funcionales

Req. Específicos
Req. Generales
Requerimiento Regla de negocio
- Fácil de aprender a - No debe permitir que - El monto por carné es
utilizar. se registren pagos por S/. 5.00.
- Su primer concepto de carné,
mantenimiento se diferente a S/. 5.00.
requiriera después del -Mostrar a los
medio año como trabajadores de la - El lector externo debe
mínimo. universidad. ser avalado por algún
- Para acceder al - El lector externo se trabajador de la
sistema se tengan 3 debe registrar con su universidad.
oportunidades. respectivo aval.
- Que las búsquedas no
demoren más de 30
segundos.

Documento de especificación de requerimientos externos

Definición del Requerimiento
Interoperabilidad
Ético
Seguridad de información
Privacidad de información
Detalles del requerimiento
Comunicación con otros equipos, usuarios, etc
Seguridad de usuarios
Seguridad de los datos almacenados
Acceso restringido a usuarios externos…

IV. ACTIVIDADES
1. Desarrollar la identificación y análisis de requerimientos para los proyectos
grupales.

MSc. Ing. Walter J. Medina L. 8