PARTE I: REQUERIMIENTO DE SOFTWARE

¿Qué es un requerimiento, establezca ejemplos?

En Ingeniería de Software el término requerimiento hace referencia a algo que se le pide o solicita a alguien, en este caso seria el programador o quien se va a encargar de diseñar el software y esta relacionado con las características que se desea que posea un sistema o un software o las tareas relacionadas con los requerimientos de un sistema. Una colección de requerimientos describe las características o atributos del sistema deseado Dentro de estos requerimientos o requisitos podemos mencionar:

Características del producto

Tareas que debe realizar

Ejemplos

No se puede aceptar devoluciones en el modulo de facturación, las devoluciones se debe ejecutar en su modulo correspondiente (devoluciones)

Todo proveedor deberá registrarse con su numero de rif, de no ser asi no se dara entrada en la base de datos de proveedores

Solo puede imprimirse 20 items por factura, si la venta excede ese número deberá imprimirse la diferencia de ítems en una nueva factura

¿Qué es la Ingeniería de requerimientos, establezca ejemplos?

En la ingeniería de sistemas y la ingeniería de software, la 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.

 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.

 Requisitos  funcionales: puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito específica algo que el sistema entregado debe ser capaz de realizar.

Ejemplos:

El sistema debe validar las disponibilidad de inventario antes de aceptar las transacciones de ventas de los clientes

El sistema debe generar un reporte de pedidos ordenado por fecha y proveedor

Requisitos no funcionales: especifican algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitarles son la disponibilidad, el mantenimiento, la facilidad de uso, entre otros.

Ejemplos

El respaldo debe ser ejecutado automáticamente entre las 11pm y la 1am todos los días

El sistema debe estar en línea con la base de datos central el 99% de su tiempo

¿Cuál es la importancia de la ingeniería de requerimientos, establezca ejemplos?

La importancia de la ingeniería de requerimientos radica en 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.

• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
• Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.
• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
• Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

¿Cuáles son las actividades (Ejemplos) de la ingeniería de requerimientos?

En el proceso de Ingeniería de Requerimientos son esenciales diversas actividades, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado.

Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la Ingeniería de Requerimientos varían tanto en número como en nombres.

A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades, podemos identificar y extraer cinco actividades principales que son:

• Análisis del Problema:
• Evaluación y Negociación
• Especificación
• Validación
• Evolución

Ejemplo de análisis del Problema:

"El cliente se queja mucho por la enorme fila que debe formar para realizar una transacción bancaria".

Perspectiva del cliente = Pérdida de tiempo

Perspectiva del banco = Posibles pérdidas de clientes

Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos,).

Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iníciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio.

¿Cuales son las técnicas y herramientas en la Ingeniería de requerimientos, ejemplos de sus usos, ventajas y desventajas?

Existen varias técnicas para la IR, sin embargo, se van a estudiar sólo algunas de ellas. Cada técnica puede aplicarse en una o más actividades de la IR; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

Alguna de estas Actividades son:

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales.

Lluvia de Ideas (Brainstorm)

Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los niveles.

Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de los principios creativos.

Principios de la lluvia de ideas

• Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como un inhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se sienta amenazado.
• Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que encontremos las soluciones y tendremos más variedad sobre la que elegir.
• La producción de ideas en grupos puede ser más efectiva que la individual.
• Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, serán asociadas de manera distinta por cada miembro, y hará que aparezcan otras por contacto.

PARTE II: ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

Requerimientos funcionales 

Los requerimientos funcionales de un sistema describen la funcionalidad o losservicios que se espera que éste provea. Estos dependen del tipo de software ydel sistema que se desarrolle y de los posibles usuarios del software. Cuandose expresan como requerimientos del usuario, habitualmente se describen deforma general mientras que los requerimientos funcionales del sistema describencon detalle la función de éste, sus entradas y salidas, excepciones, etc.Muchos de los problemas de la ingeniería de software provienen de laimprecisión en la especificación de requerimientos. Para un desarrollador desistemas es natural dar interpretaciones de un requerimiento ambiguo con el finde simplificar su implementación. Sin embargo, a menudo no es lo que el clientedesea. Se tienen que estipular nuevos requerimientos y se deben hacer cambiosal sistema, retrasando la entrega de éste e incrementando el costo.

Enprincipio, la especificación de requerimientos funcionales de un sistema debeestar completa y ser consistente. Completa significa que todos los serviciossolicitados por el usuario están definidos. Y la consistencia significa que losrequerimientos no tienen definiciones contradictorias. En la práctica, parasistemas grandes y complejos, es imposible cumplir los requerimientos deconsistencia y completitud. La razón de esto se debe parcialmente a lacomplejidad inherente del sistema y parcialmente a que los diferentes puntos devista tienen necesidades inconsistentes. Estas inconsistencias son obviascuando los requerimientos se especifican por primera vez. Los problemas emergendespués de un análisis profundo. Una vez que éstos se hayan descubierto en lasdiferentes revisiones o en las fases posteriores del ciclo de vida, se debencorregir en el documento de requerimientos. 

Ejemplos derequerimientos funcionales

Matriculación

• La matricula será realizada deforma interactiva. Se le preguntara al alumno cual es el plan de estudios enque desea matricularse (pueden ser varios).
• Se podrá generar una copia impresade la matricula (sin valor oficial) en el computador desde donde se realice elproceso de matriculación.
• Así mismo, se podrá generar elimpreso de pago debidamente cumplimentado.
• Para la matriculación seconsultaran los datos del expediente y se realizaran las validacionesnecesarias, descritas a continuación 

Pagode matrícula:

• La aplicación generara un impresopara que el alumno realice el pago correspondiente a la matricula en 1 o 2plazos (según las fechas establecidas).
• Si el alumno tiene matriculas dehonor de cursos anteriores o disfruta de algún tipo de beca, la aplicación deberácalcular automáticamente los descuentos correspondientes

Gestiónde docencia

• El secretario será el encargado deintroducir que profesores corresponden a cada asignatura (si no, no podránintroducir las actas los profesores).
• Los profesores de cada asignatura tendránacceso a las listas de los alumnos que estén matriculados en sus asignaturas yla aplicación les debe permitir rellenar las actas.

Estadísticas

En control de estudio se podrán obtener estadísticas que clasifiquen alos alumnos por su lugar de residencia, sexo, edad, cursos o asignaturas

Requerimientos no funcionales

 Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, y otros

Sonaquellos requerimientos que no se refieren directamente a las funcionesespecíficas que entrega el sistema, sino a las propiedades emergentes de éstecomo la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.De forma alternativa, definen las restricciones del sistema como la capacidadde los dispositivos de entrada/salida y la representación de datos que seutiliza en la interface del sistema.

Muchosrequerimientos no funcionales se refieren al sistema como un todo más que arasgos particulares del mismo. Esto significa que a menudo con más críticos quelos requerimientos funcionales particulares. Mientras que el incumplimiento deeste último degradará el sistema, una falla en un requerimiento no funcionaldel sistema lo inutiliza.

Los requerimientos no funcionales surgen de la necesidad del usuario,debido a las restricciones en el presupuesto, a las políticas de laorganización, a la necesidad de interoperabilidad con otros sistemas desoftware o hardware o a factores externos como los reglamentos de seguridad,las políticas de privacidad, etc.

Ejemplos derequerimientos NO funcionales 

Interfaces 

• Hardware: El sistema se debeimplementar sobre la infraestructura existente en las aulas de prácticas de lacátedra Ingeniería de Software
• Software: No existe posibilidad deadquirir software. La aplicación deberá funcionar sobre Oracle

Requerimientos deldominio 

 Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.

Sederivan del dominio del sistema más que de las necesidades especificas de losusuarios. Pueden ser requerimientos funcionales nuevos, restringir losexistentes o establecer cómo se deben ejecutar cálculos particulares. Losrequerimientos del dominio son importantes debido a que a menudo reflejan losfundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen,es imposible hacer que el sistema trabaje de forma satisfactoria.

Ejemploen un Sistema de Biblioteca, este deberá proveer visores para que el usuariolea documentos en el almacén de documentos 

Requerimientos delusuario 

Sondeclaraciones en lenguaje natural y en diagramas de los servicios que se esperaque el sistema provea y de las restricciones bajo las cuales debe operar.

Describenlos requerimientos funcionales y no funcionales de tal forma que seancomprensibles por los usuarios del sistema que no posean un conocimientotécnico detallado. Únicamente especifican el comportamiento externo del sistemay evitan, tanto como sea posible, las características de diseño del sistema.Por consiguiente, los requerimientos del usuario no se deben definir utilizandoun modelo de implementación. Deben redactarse utilizando el lenguaje natural,representaciones y diagramas intuitivos sencillos.

Sin embargo, pueden surgir diversos problemas cuando se redactan enlenguaje natural: falta de claridad, confusión de requerimientos y conjunciónde requerimientos.

Requerimientos del sistema 

Sondescripciones más detalladas de los requerimientos del usuario. Sirven comobase para definir el contrato de la especificación del sistema y, por lo tanto,debe ser una especificación completa y consistente del sistema. Son utilizadospor los ingenieros de software como el punto de partida para el diseño delsistema.

Laespecificación de requerimientos del sistema incluye diferentes modelos delsistema como el de objetos o el de flujo de datos.

Enprincipio, los requerimientos del sistema deberán establecer lo que éste hará yno la manera en que se implementará. Sin embargo, en el nivel de detallerequerido para especificar el sistema completamente, es casi imposible excluirtoda la información de diseño.

Unaespecificación del diseño del software, es una descripción abstracta del diseñodel software, que es una base para un diseño e implementación detallados;agrega detalle a la especificación de requerimientos del sistema

Lenguaje onotación usada en la especificación de requerimientos. 

El lenguaje onotación usada para la especificación de requerimientos por excelencia es elUML (Lenguaje de modelado unificado), específicamente  los diagramas  de caso de uso, estados y actividades, estosdos últimos describen en detalles los usos del sistema establecidos.  Es así como estos diagramas se describen acontinuación.

Diagrama de casode uso. 

Los diagramas deCasos de Uso describen o especifican lo que hace un sistema desde el punto devista de un observador externo, enfatizando el qué más que el cómo. Planteanescenarios, es decir, lo que pasa cuando alguien interactúa con el sistema,proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Usodescribe como Carlos va a desayunar (este es su objetivo), para lo que seplantea el escenario de preparar su café y el pan tostado

Diagrama deEstados 

Muestran losposibles estados en que puede encontrarse un objeto y las transiciones que puedencausar un cambio de estado, en los usos establecidos para el sistema. El estadode un objeto depende de la actividad que esté llevando a cabo o de algunacondición dentro de los usos.

 Las transiciones son las líneas queunen los diferentes estados. En ellas se representa la condición que provoca elcambio, seguida de la acción oportuna separada por “/”. En un estado enque el objeto esta pendiente de algún tipo de validación que dependa de unproceso en curso, no es necesario evento externo alguno para que se produzca latransición, ya que ésta ocurrirá cuando termine el proceso, en función delresultado de éste. En estos casos es conveniente, por claridad, incluir lacondición que de la que depende la transición (entre corchetes). 

Diagrama de Actividades

Sonbásicamente diagramas de flujo adornados, que guardan mucha similitud con losdiagramas de estados. Mientras que los diagramas de estados centran su atenciónen el procesoo uso que está llevando a cabo un objeto, losdiagramas de actividades muestran como las actividades fluyen y lasdependencias entre ellas.

 Los diagramas deactividades pueden dividirse en “calles” que determinan qué objeto esresponsable de qué actividad. Las actividades vienen unidas por transiciones,que pueden separarse en ramas en función del resultado de una condiciónexpresada entre corchetes. Cada rama muestra la condición que debe sersatisfecha para que el flujo opte por ese camino. Igualmente, las transicionesse pueden bifurcarse en dos o más actividades paralelas. En lafigura 7 se muestra un diagrama de actividades del uso COMPRAR ARTICULOS conlos actores CLIENTE y TIENDA POR CATOLOGO (EMPLEADO)

Ejemplo de especificación de requerimientos usando los diagramas de casos de uso y actividad 

DIAGRAMA DE CASO DE USO

DIAGRAMA DE ACTIVIDAD

  

Notación textualde los requerimientos 

En lassecciones anteriores se ha establecido los requerimientos de manera grafica conel lenguaje de modelado UML, específicamente con los diagramas de casos de usoy actividades, pero es necesario para la comunicación efectiva con los usuariose interesados en el futuro sistema describir textualmente.

Obtener o escribirrequerimientos de alta calidad 

 En todas lastécnicas involucradas descritas en la unidad I de la ingeniería derequerimientos, las actividades y características resaltantes para obtener oescribir requerimientos de alta calidad son los siguientes.

• Identificar lasclases de usuario del producto esperado.
• Extraer lasnecesidades de los individuos que representan (STAKEHOLDER) cada clase deusuario.
• Comprender lastareas y metas del usuario y los objetivos de negocio con los que esas tareasse alinean.
• Analizar lainformación recibida de los usuarios para distinguir sus objetivos de tarea derequerimientos funcionales, requerimientos no-funcionales, reglas de negocio, yotros
• Destinar partes delos requerimientos de alto nivel a definir componentes de software en laarquitectura sistema.
• Comprender laimportancia de los atributos de calidad.
• Negociar lasprioridades de implementación.
• Traducir lasnecesidades de usuario escritas dentro de las especificaciones y modelos derequerimientos
• Examinar losrequerimientos documentados para asegurar el conocimiento común de losrequerimientos presentados por los usuarios y corregir cualquier problema antesde que el grupo de desarrolladores los acepte.
• Definir el punto departida de los requerimientos.
• Revisar y evaluarel impacto de cada requerimiento cambiado antes de aprobarlo.
• Seguir cadarequerimiento en su diseño, código fuente y pruebas.
• Agrupar losrequerimientos según rendimiento y actividad de cambio durante todo elproyecto.
• La iteración es unaclave para el éxito del desarrollo de los requerimientos.

Estándares de ladocumentación de los requerimientos

Eldocumento de los requerimientos de software es la declaración oficial de qué eslo que requieren los desarrolladores del sistema. Incluye tanto losrequerimientos del usuario para el sistema como una especificación detallada delos requerimientos del sistema. En algunos casos, los dos tipos de requerimientosse integran en una única descripción. En otros, los del usuario se definen enuna introducción de la especificación de los del sistema. Si existe un grannúmero de requerimientos, los detalles de los requerimientos del sistema sepueden presentar como documentos separados.

Eldocumento de requerimientos tiene un conjunto diverso de usuarios que va desdelos administradores principales de la organización, quienes pagan por elsistema, hasta los ingenieros responsables del software. Una gran variedad deorganizaciones han definido estándares para los documentos de requerimientos. Porejemplo la IEEE sugiere la siguiente estructura para los documentos derequerimientos.

•  Introducción • propósito del documento de requerimientos • Alcance del producto• Definiciones, acrónimos y abreviaturas • Referencias • Resumen del resto deldocumento
•  Descripción general •Perspectiva del producto • Funciones del producto • características del usuario• Restricciones generales • Suposiciones y dependencias
•  Requerimientos específicos. Cubren los requerimientos funcionales, nofuncionales y de interfaz. Obviamente, ésta es la parte más sustancial deldocumento, pero debido a la amplia variabilidad en la práctica organizacional,no es apropiado definir una estructura estándar para esta sección. Losrequerimientos pueden documentar las interfaces externas, describir lafuncionalidad y el desempeño del sistema, especificar los requerimientoslógicos de la base de datos, las restricciones de diseño, las propiedadesemergentes del sistema y las características de calidad. 

CASO DE USO BIBLIOTECA

CASO DE USO

1.- La biblioteca “ESTUDIAR ES UN BENEFICIO”desea informatizar su operatoria básica en lo referente a: préstamos deejemplares de libros a sus socios, las respectivas devoluciones de estos, yconsultas acerca de la disponibilidad de los ejemplares.Los socios de labiblioteca pueden ser de 3 tipos: docente, no docente y estudiante. Cada tipode socio tiene diferentes condiciones de préstamo en cuanto a la duración y alnúmero de ejemplares que puede retirar en préstamo. El número de días desuspensión, ante una devolución tardía de un ejemplar, también es diferentepara cada tipo de socio. Cada libro tiene un isbn (Identificación) y un título,está escrito por uno o más autores, y es publicado por un editorial en unafecha de edición. Cada ejemplar de libro tiene un código único que loidentifica, y se conoce si está o no en mantenimiento por un eventualdeterioro.