Centro Universitario de Ciencias Económico-

Administrativas

Gestión de Servicios y Procesos de TI

Profesor: José Luis Fernández Robles

YESSICA YAMILETH GARCIA GOMEZ
Cod-. 213090319

3.2.1 – ingeniería de requerimientos

 ¿Qué es la ingeniería de requerimientos?
 Proceso que comprende todas las actividades de requerimientos para crear y
mantener un documento de requerimientos del sistema.
 Proceso de aplicar un método estructurado, el cual analiza el sistema y
desarrolla un conjunto de modelos gráficos del mismo que actúan como una
especificación del sistema.
 El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema es llamado Ingeniería de Requerimientos.
La meta es entregar una especificación de requerimientos de software correcta y
completa
Los requerimientos se deben descubrir antes de empezar a construir un producto y
puede ser algo que el producto debe hacer o una cualidad que el producto debe tener •
Si no se tienen los requerimientos correctos, no se puede diseñar o construir el
producto correcto

--Conjunto de actividades involucradas en el descubrimiento, documentación y

mantenimiento de los requerimientos para un producto determinado – según
Ortas 1997--

¿Cuál es la diferencia entre requerimientos funcionales y no

funcionales?
El requisito funcional: Es describir el comportamiento del sistema en relación con la
funcionalidad del sistema. El requisito no funcional elabora una característica de
rendimiento del sistema.

Las actividades que el sistema debe realizar

 El negocio utiliza funciones que los usuarios realizan

 ejemplo de casos de uso si está desarrollando un sistema de nómina de
funciones requeridas
 generar transferencias electrónicas de fondos
 importes de comisiones de cálculo
 calcular impuestos de nómina
 informar la deducción de impuestos al IRS

Los requisitos no funcionales a veces se definen en términos de métricas (es decir,

algo que se puede medir sobre el sistema) para hacerlos más tangibles.

Los requisitos no funcionales también pueden describir aspectos del sistema que no
se relacionan con su ejecución, sino con su evolución a lo largo del tiempo

Los requisitos funcionales especifican una función que un sistema o componente del
sistema debe poder realizar. Se puede documentar de varias maneras. Las más
comunes son descripciones escritas en documentos y casos de uso.
 Los requisitos funcionales es lo que se supone que debe lograr un sistema. Puede
ser

 Cálculos
 Detalles técnicos
 Manipulación de datos
 Procesamiento de datos
 Otra funcionalidad específica

Un requisito funcional típico contendrá un nombre y número únicos, un breve

resumen y una justificación. Esta información se utiliza para ayudar al lector a
comprender por qué se necesita el requisito y para rastrearlo a través del desarrollo
del sistema. sensibilidad, extensibilidad, documentación, etc.).

Requerimientos no funcionales

 Los requisitos no funcionales son cualquier otro requisito que los requisitos
funcionales. Estos son los requisitos que especifican los criterios que se
pueden utilizar para juzgar el funcionamiento de un sistema, en lugar de
comportamientos específicos.
 Los requisitos no funcionales tienen la forma de "sistema debe ser" , una
propiedad general del sistema en su conjunto o de un aspecto particular y no
una función específica. Las propiedades generales del sistema suelen marcar
la diferencia entre si el proyecto de desarrollo ha tenido éxito o no.

Requisitos no funcionales: se pueden dividir en dos categorías principales:

 Cualidades de ejecución, como seguridad y usabilidad, que se pueden

observar en tiempo de ejecución.

 Cualidades de evolución, como capacidad de prueba, mantenibilidad,

extensibilidad y escalabilidad, que están incorporadas en la estructura
estática del sistema de software.

Los requisitos no funcionales imponen restricciones al producto que se está

desarrollando, al proceso de desarrollo y especifican restricciones externas que el
producto debe cumplir.

técnicas para la recopilación de requisitos

Entrevista
La entrevista es una técnica para obtener información mediante una conversación
dirigida por los analistas a clientes y usuarios, con el objetivo de entender el dominio del
problema y sus necesidades. Se basa en un formato de preguntas y respuestas. El
desarrollador buscará obtenerlas opiniones de los clientes o usuarios entrevistados, sus
opiniones del sistema, sus metas personales, de la organización y de los
procedimientos informales.

Existen cinco puntos que deben tomarse en cuenta para preparar una entrevista [10]

• Lectura de antecedentes. Se debe hacer un previo estudio de antecedentes de los

entrevistados y su ambiente de trabajo, con ello se logrará conocer el lenguaje
empleado dentro de la empresa.

• Establecer objetivos de la entrevista. Se establecen los objetivos de la entrevista en

base a los antecedentes y la experiencia personal.

• Selección de los entrevistados. Se entrevista a gente clave de todos los niveles del
sistema.

• Preparación del entrevistado. Se debe de contactar a la persona que se entrevistará

con tiempo para que pueda reflexionar acerca de la entrevista.

• Selección del tipo y la estructura de las preguntas. Escribir las preguntas que cubran
los aspectos fundamentales del objetivo de la entrevista, eligiendo el tipo y la estructura
adecuada de las preguntas de la entrevista.

Las preguntas tienen ciertas estructuras básicas que se deben conocer. Los dos tipos
básicos de

preguntas son abiertas y cerradas.

• Las preguntas abiertas permiten al entrevistado expresar de manera flexible y en

consideración de su experiencia responder a lo que se le pregunta.

• Las preguntas cerradas limitan las respuestas disponibles de los entrevistados

mediante una lista de opciones o alternativas de respuestas.

La entrevista puede estructurarse de las siguientes maneras:

• Estructura de pirámide. En este caso, el entrevistador inicia con preguntas detalladas,

del tipo de preguntas cerradas, y luego realiza preguntas abiertas, de respuestas más
generalizadas.

• Estructura de embudo. El entrevistador comienza haciendo preguntas abiertas de

carácter general y más adelante va utilizando preguntas cerradas.

• Estructura de diamante. Combina las estructuras anteriores, el entrevistador comienza

de una manera muy específica, luego examina aspectos muy generales y finalmente
llega a una conclusión muy específica.
Las entrevistas deben registrarse ya sea por un cuaderno de notas o utilizando una
grabación. Es importante que al final de la entrevista se escriba un informe con el fin de
asegurar la calidad de los datos de la entrevista.

Reuniones de trabajo

Efectiva
El objetivo de las reuniones varía dependiendo el tipo de reunión convocada.

 Horario
Establecer reglas para las reuniones:

 Puntualidad
 Métodos para decidir
 Interrupciones permitidas
 Confidencialidad

Se cuida el tiempo asignado para la presentación de cada tema que se cumpla.

Una persona puede auxiliar a quien dirige la reunión para dar la palabra.

Es un encuentro entre personas que pretenden alcanzar metas comunes a través de

una discusión.

Una reunión efectiva es una reunión que se realiza en un ambiente adecuado y se

alcanzan las metas propuestas.

 Planificar

Concepto y características de las reuniones de trabajo EFECTIVAS

Evitar factores negativos que afecten a la reunión

 Objetivo de la reunión
 Investigar todo el tema de la reunión
 Lista de las personas que estarán presentes
 Planificar con ayuda de otros

Minuta de acuerdos
 Participantes
 Agenda
Los compromisos de la reunión deben quedar asignados e incluidos en un plan de
acción, en donde se establezca mínimo el responsable y la fecha estimada de termino.
Las cifras pequeñas potencian la interacción y permiten llegar con más rapidez a un
clima de trabajo en grupo.

Debe contener:

 Fecha y hora de la reunión

 Lugar y duración de la reunión
 Información que deben llevar
 Lista de participantes

Observación
En la mayoría de las organizaciones se realiza algún trabajo en el cual se involucran
distintos grupos de personas que cooperan para llevar a cabo distintas tareas. La
naturaleza de esta cooperación es a menudo compleja y varía dependiendo de las
usuarias involucradas, del ambiente físico y de la organización en donde se realiza el
trabajo. Los usuarios con frecuencia encuentran dificultades para expresar la forma en
como realizan sus tareas en la organización y la forma en como cooperan con otras
personas, por lo cual son necesarias técnicas y herramientas para describir las
actividades de los usuarios en la organización.

La observación es una técnica en donde el analista se sumerge en el ambiente de

trabajo de los usuarios, para observar el trabajo diario que éstos realizan anotando los
aspectos importantes y observando factores sociales y organizacionales que afecten el
sistema.

Análisis de protocolos
El análisis de protocolos es una técnica aplicada a un grupo de usuarios
representativos, a quienes se les pide que describan en voz alta sus actividades dentro
del sistema. Así el desarrollador podrá identificar las metas y submetas del negocio
apreciadas por los usuarios.

Análisis de escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le
presentan eventos específicos. Cada evento de interacción distinto, o la selección de un
servicio del sistema, se documentan como un escenario de eventos distinto. Los
escenarios de eventos incluyen una descripción del flujo de datos y las acciones del
sistema, y documenta las excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los escenarios de eventos son:

1. Los datos proporcionados desde un punto de vista o proporcionados a éste se

representan como elipses.
2. Las entradas y salidas de la información de control se ubican en la parte superior
de cada recuadro.
 3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no están
encerradas, significa que pertenecen al sistema.
4. Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, éstas se encierran en un recuadro.
5. El nombre del siguiente evento esperado después de completar el escenario se
muestra en un recuadro sombreado.

Los Casos de Uso son una técnica que se basa en escenarios para la obtención de
requerimientos. Actualmente se han convertido en una técnica fundamental que se
utiliza para analizar y describir modelos de sistemas orientados a objetos. En su forma
más simple, un caso de uso identifica a los actores involucrados en una interacción y
nombra al tipo de ésta.

Prototipos
Consiste en elaborar una versión preliminar tangible del producto final para obtener una
retroalimentación temprana sobre los requisitos del proyecto. El proceso para seguir
sería el siguiente:

1. Se desarrolla un modelo preliminar y tangible del producto final basado en

la necesidad de los interesados.
2. Se solicita a las partes interesadas que den su opinión sobre este modelo.
3. Los comentarios negativos se capturan para identificar otros requisitos.
Las retroalimentaciones positivas se conservan tal como son.
4. Una vez obtenidos los requisitos completos a partir del prototipo, podemos
pasar a la fase de diseño o construcción.

Seguimientos (Shadowing)
Actividad de observación en el trabajo o profesional o Shadowing es una técnica muy
utilizada en los procesos de incorporación de los nuevos trabajadores en las empresas.
Este proceso consiste en pasar un espacio de tiempo observando a un trabajador que
ya realiza las mismas funciones que tú harás en un futuro cercano. Así, el trabajador
podrá aprender de forma precisa como realizar las funciones necesarias en su nuevo
puesto como también las habilidades sociales necesarias.

Ventajas del Shadowing:

 Verificación del trabajador ante la duda de si cambiar de puesto de trabajo,

promocionarse o irse a otra empresa.
 Al observar todos los comportamientos de manera directa aumenta la
comunicación por lo que hace que el ambiente organización mejore.
  Se crean relaciones interpersonales creando un networking positivo para todos
los trabajadores y en algunos casos, favoreciendo también a los clientes.
 Se da pie a conocer el coste temporal de aprendizaje real de las funciones a
realizar.
 Aparte de funciones teóricas que solo se pueden aprender de manera presencial
o de manera online, se aprenden las habilidades sociales, cada vez más
importantes en las empresas.

Referencias:
Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and Techniques”. John
Wiley and Sons, 2002.
Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with viewpoints”. BCS/IEE
Software Engineering J.
Rumbaugh, J.; Jacobson, I. y Booch, G.; “El Lenguaje Unificado de Modelado”.
JACOBSON, Ivar; RUMBAUGH, James; BOOCH, Grady, “El proceso unificado de
desarrollo”.2000.