INGENIERÍA DE REQUERIMIENTOS

Ingeniería de Requerimientos

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 las partes interesadas, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

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.

Implicaciones

La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

• La educción (a veces llamada "elicitación", debido a una mala traducción de "elicitation") de los requisitos de usuario.
• El análisis y negociación de requisitos para derivar requisitos adicionales.
• La documentación de los requisitos como especificación.
• La validación de los requisitos documentados contra las necesidades de usuario.
• Así como los procesos que apoyan estas actividades.

Fases de implementación

Desde un punto de vista conceptual, las actividades son de cinco clases.

• Obtener requisitos: a través de entrevistas o comunicación con clientes o futuros usuarios, para saber cuáles son sus expectativas.
• Analizar requisitos: detectar y corregir las carencias o falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.
• Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
• Verificar los requisitos: consiste en comprobar la implementación de los requerimientos.
• Validar los requisitos: comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construyó el producto.

Técnicas principales

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual ó coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.

Durante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.

En el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todas los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos y Casos de uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

• A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
• Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
• Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
• Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Los requisitos se dividen en tres:

• Funcionales: son los que el usuario necesita que efectúe el software. Normalmente se identifican como los requisitos que responden a la pregunta ¿qué hace? e.g. El sistema debe emitir un comprobante al asentar la entrega de mercadería.
• No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL. Normalmente se identifican como los requisitos que responden a la pregunta ¿cómo lo hace? e.g. rápido, fácil etc.
• Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.

Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. Entre las personas implicadas hay que considerar:

• Organizaciones que integran la organización del analista que está diseñando el sistema
• Organizaciones o sistemas de respaldo
• Dirección
• Usuarios.

PROYECTO APP-PERFECT BODY GYM

REQUERIMIENTOS

ID	NOMBRE	DESCRIPCION
RF1	Registrar clientes	Permite al administrador  registrar un cliente nuevo, obteniendo carnet de cliente con código único
RF2	Actualizar los datos del cliente	permitirá al administrador actualizar los datos del cliente en cualquier momento
RF3	Historial del cliente	Permite  al administrador  tener un historial de medidas del cliente a través del tiempo
RF4	Caducidad del contrato del cliente	Permite al administrador  saber cuándo vence el pago del cliente (mensualidad)
RF5	Registrar instructores	Permite al administrador registrar un nuevo instructor, obteniendo carnet de empleado con código único
RF6	Actualizar los datos del instructor	Permite al administrador actualizar los datos del instructor en cualquier momento
RF7	Establecer los horarios de turnos de instructor	Permite al administrador asignar el horario de turno de trabajo del instructor
RF8	Caducidad del contrato de los instructores	Permite al administrador saber cuándo vence el contrato de los empleado
RF9	Manejo de clientes, instructores y productos	permite al administrador manipular la información de clientes, instructores y productos y al instructor consultar la información de clientes e instructores
RF10	Consultar asistencia de los clientes	permite  al administrador consultar si el cliente asiste en sus días vigentes de pago
RF11	Consultar asistencia de los instructores	Permite administrador la asistencia de los instructores a sus horarios de trabajo
RF12	Registro de venta diario	Permite al administrador y al empleado vender productos que se ofrecen en el gimnasio
RF13	Contacto vía e-mail por el administrador	Permite al administrador el envió de correos a sus clientes e instructores y recibirlos de los mismos
RF15	Registrar productos	Permite al administrador registrar un nuevo producto, obteniendo un código único
RF16	Actualizar datos de los productos	Permite al administrador actualizar los datos del producto en cualquier momento
RF17	Pago de nomina	El sistema calcula el pago de nómina a sus instructores
FR18	Cifra de venta diaria	El sistema calcula de forma efectiva los ingresos de dinero
RF19	Realizar consultas	El sistema Permitirá al cliente consultar horario del gimnasio, al instructor consultar sus horarios de turno y al administrador consultar todos los datos del sistema
RF20	Administrar rutinas de ejercicios	Permite a los clientes observar sus rutinas establecidas por sus instructores.
RF21	Ingresar rutina de ejercicio	El sistema debe permitir ingresar una rutina de ejercicio por parte del instructor hacia el usuario
RF22	Validar estado de un cliente	El sistema debe permitir validar el estado de un cliente con un carnet que contiene un código de barras y se pasa por un lector, de esta manera cuando un cliente llega al gimnasio pasa el carnet por el lector y deberá mostrar en pantalla si se le debe permitir el ingreso a ese cliente o no
RF23	El sistema deberá permitir un apartado de los productos	Permitirá realizar un apartado de los diferentes productos que ofrecen en el gimnasio
RF24	Consultar información financiera	El sistema permitirá administrar la información financiera y bancaria del gimnasio.
RF25	Reconocer tarjeta de acceso	El sistema permitirá verificar la tarjeta del usuario para el debido ingreso al establecimiento.

MODELO DEL NEGOCIO

Introducción al modelado de negocios

En la actualidad la incorporación de las tecnologías de la información para la automatización de procesos y control de información dentro de las empresas ha tenido una gran penetración además de una enorme aceptación, pues las empresas buscan contar con sistemas computacionales hechos a medida, que sean capaces de solucionar todas sus necesidades de control de información. Partiendo de esta premisa, debemos tener en cuenta que si una empresa requiere la creación de un sistema computacional que se adapte a su compañía, el primer paso es lograr comprender la organización y estructura empresarial. De este punto nace la necesidad de modelar los negocios, que es el tema central de esta asignatura.

Definición del modelado de negocios

Para comenzar con el análisis de esta asignatura primero debemos comprender qué es el modelado de negocios. Dividamos los términos; según la Real Academia de la Lengua Española (RAE, s/f), modelar es:

·         Formar de cera, barro u otra materia blanda una figura o adorno.

·         Configurar o conformar algo no material.

·         Presentar con exactitud el relieve de las figuras.

Por lo tanto el modelado es la acción de conformar la representación de algo.

Por su parte, la definición de negocio es (RAE, s/f):

·         Ocupación, quehacer o trabajo.

·         Dependencia, pretensión, tratado o agencia.

·         Aquello que es objeto o materia de una ocupación lucrativa o de interés.

·         Acción y efecto de negociar.

·         Utilidad o interés que se logra en lo que se trata, comercia o pretende.

·         Local en que se negocia o comercia.

Sobre la base de estas definiciones entendemos entonces que: el modelado de negocios es la conformación de la representación de los quehaceres de un comercio (empresa).

Esto nos orienta hacia el hecho de que el modelado de negocios debe crear una representación gráfica de una empresa, donde se puedan apreciar todo los elementos que lo componen, su interacción, recursos, metas, procesos la comunicación y relaciones que existen.

Visión General

El modelado de negocios es de gran ayuda en la etapa de análisis de desarrollo de software, ya que tener un buen modelo permite lograr comprender el ámbito de la información además de identificar las actividades y procesos que se realizan dentro de la organización para lograr una correcta operación y así lograr una buena comprensión del negocio para automatizar procesos al crear sistemas computacionales que se ajusten a la medida de una organización.

De esta manera, si los requerimientos son tomados con base en el modelado del negocio, las probabilidades de que el sistema que se realice se adapte a las operaciones a realizarse dentro de la organización, son muy altas.

Existen varias ventajas para basar los sistemas de información en un mismo modelo básico de negocio (León y Asato, 2009):

·         Los sistemas de información se vuelven una parte integral del negocio global, soportando las operaciones, fortaleciendo el trabajo y la obtención de resultados.

·         Los sistemas se integran fácilmente unos con otros y pueden compartir o intercambiar información.

Un modelo de proceso de negocio típicamente define los siguientes elementos (León y  Asato, 2009):

·         El Objetivo o motivo del proceso.

·         Las Entradas específicas

·         Las Salidas específicas.

·         Los Recursos consumidos.

·         La secuencia de las Actividades.

·         Los Eventos que dirigen el proceso.

Estos elementos se irán analizando a lo largo de esta asignatura, para comprender su funcionamiento dentro de la organización, así como su modelado.

Características Principales

Dentro de las principales características del modelado de negocios se tienen las siguientes (León y Asato, 2009):

·         Permiten comprender mejor los mecanismos clave de un negocio existente.

 Se debe proveer una imagen clara de sus roles y tareas en la organización global, los modelos pueden ser usados para entrenar a las personas. Pueden ser usados tanto en una organización jerárquica como en una organización orientada a procesos.

·         Actúan como base para crear sistemas de información.

Las descripciones de negocio son usadas para identificar el apoyo de sistemas de información a los principales procesos de la organización. Los modelos también son usados como una base para especificar los requerimientos clave de esos sistemas.

·     Facilitan la identificación de ideas para mejorar la estructura actual del negocio y su operación.

 Los modelos permiten identificar situaciones susceptibles de ser mejoradas, la construcción de un modelo implica un proceso reflexivo del porqué se hacen las cosas como se hacen, de manera que pueden visualizarse cambios en el negocio actual que son necesarios para implementar el modelo mejorado.

·         Para experimentar con un nuevo concepto de negocio.

 Un modelo es una entidad conceptual de bajo costo sobre la cual pueden hacerse ciertas pruebas para validar su operación, lo que los hace ser un medio para la adopción de mejores prácticas inspiradas por otros modelos de negocios exitosos. También permite tomar ventaja mediante la adopción de nuevas tecnologías, tales como las relacionadas con Internet.

·         Para identificar oportunidades de Outsourcing.

 Los elementos del negocio no considerados como parte central, son delegados a proveedores externos. Los modelos son usados como especificación para los proveedores.

·         Para mostrar la estructura de un negocio innovado.

 Los modelos sirven para presentar ante la gerencia la nueva propuesta de trabajo, de manera tangible y concreta. A partir de este punto es posible definir nuevas acciones, entonces los modelos se vuelven la base para los planes de acción que apoyarán la transformación del negocio.