FUNDAMENTOS EN

INGENIERIA EN TECNOLÓGICO
SOFTWARE NACIONAL
DE MÉXICO
UNIDAD 3
INGENIERÍA DE REQUERIMIENTOS

INSTITUTO
TECNOLÓGICO
ASESOR DE TAPACHULA
De León Morga Marilin

ALUMNOS
 Carrillo Pérez Juan Javier
 Reyes Sánchez Emanuel
 Vázquez Ramírez Alexis
 Venegas García Ernesto Enrique

CARRERA
Ing. En Sistemas Computacionales

SEMESTRE Y GRUPO
5to. Semestre, Grupo “D”

LUGAR Y FECHA
Tapachula, Chiapas. Jueves 09 de Noviembre del 2017
 INGENIERÍA DE REQUERIMIENTOS

¿QUÉ ES UN REQUISITO?

 Una condición o necesidad de un usuario para resolver un problema o

alcanzar un objetivo.

 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.

INGENIERÍA DE REQUERIMIENTOS O REQUESITOS

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario

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.
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de
requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas
con la determinación de las necesidades o de las condiciones a satisfacer para un
software nuevo o modificado, tomando en cuenta los diversos requisitos de los
inversores, que pueden entrar en conflicto entre ellos.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un
estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los
buenos requisitos deben ser medibles, comprobables, sin ambigüedades o
contradicciones, etc.
La parte más difícil de construir un sistema es precisamente saber qué construir.
Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos
técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros
sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal.
Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más importante
que el ingeniero de software hace para el cliente es la extracción iterativa y el
refinamiento de los requerimientos del producto.
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 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.

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

• 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?
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?

CARACTERÍSTICAS DE UN REQUERIMIENTO
Es importante no perder de vista que un requerimiento debe ser:

 Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

 Posible de probar o verificar: Si un requerimiento no se puede comprobar,

entonces ¿cómo se sabe si se cumplió con él o no?

 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.

TAREAS DE LA INGENIERÍA DE REQUISITOS

 Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es

el nombre comúnmente dado a las actividades involucradas en el
descubrimiento de los requisitos del sistema.

 Análisis: Sobre la base de la extracción realizada previamente, comienza

esta fase en la cual se enfoca en descubrir problemas con los requisitos del
sistema identificados hasta el momento.

 Especificación: En esta fase se documentan los requisitos acordados con

el cliente, en un nivel apropiado de detalle.

 Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar

los requisitos, es decir, verificar todos los requisitos que aparecen en el
documento especificado para asegurarse que representan una descripción,
por lo menos, aceptable del sistema que se debe implementar. Esto implica
verificar que los requisitos sean consistentes y que estén completos.

TÉCNICAS DE LA INGENIERÍA DE REQUISTOS

Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de
personas o de grupos.
Durante la entrevista, la analista conversa con el encuestado; el cuestionario
consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios
en potencia del sistema propuesto. En algunos casos, son gerentes o empleados
que proporcionan datos para el sistema propuesto o que serán afectados por él. El
éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación
para la misma.
Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén
relacionados con el sistema a ser construido. Por un lado, podemos analizar las
interfaces de usuario, observando el tipo de información que se maneja y cómo es
manejada, por otro lado también es útil analizar las distintas salidas que los sistemas
producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas
sobre la base de estas.

Lluvia de ideas
Este es un modelo que se usa para generar ideas. La intención en su aplicación es
la de generar la máxima cantidad posible de requerimientos para el sistema. No hay
que detenerse en pensar si la idea eso no del todo utilizable. La intención de este
ejercicio es generar, en una primera instancia, muchas ideas.

Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos
requerimientos no estén demasiado claros o que no se esté muy seguro de haber
entendido correctamente los requerimientos
Obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del
sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos.
Los prototipos son:
Simulaciones del posible producto, que luego son utilizados por el usuario final,
permitiéndonos conseguir una importante retroalimentación en cuanto a si el
sistema diseñado con base a los requerimientos recolectados le permite al usuario
realizar su trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requerimientos:
Desarrolladores y clientes se reúnen y definen los objetivos globales del software,
identifican todos los requerimientos que son conocidos, y señalan áreas en las que
será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un
“diseño rápido”. El diseño rápido se centra en una representación de aquellos
aspectos del software que serán visibles al usuario (por ejemplo, entradas y
formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.
Casos de uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema.
“Un caso de uso es una secuencia de transacciones que son desarrolladas por un
Sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los
diagramas de casos de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interacción con los usuarios y/o otros
sistemas”
Los casos de uso permiten entonces describir la posible secuencia de interacciones
entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente
de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos
comenzado con un evento inicial desde un actor hacia el sistema.
 BIBLIOGRAFÍA

 Ingeniería de Requisitos. http://ithjuanah.blogspot.mx/.

 Técnicas para Identificar Requisitos Funcionales y No

Funcionales.
https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-
para-identificar-requisitos-funcionales-y-no-funcionales.

 Requerimientos del software. http://requerimientos.galeon.com/.

 Modelado de Negocios Modelado de Negocios. Jonás A.

Montilva C., Ph.D. PDF.