Tabla de contenido

Que es un requerimiento:

Se puede decir que es una necesidad de un usuario, una condición o capacidad a la que un sistema en construcción debe conformar.

Que es la ingeniería de requerimientos:

Es un conjunto de tareas que conducen a comprender las necesidades que tiene el usuario para comunicarlas a los desarrolladores del sistema. Eso se consigue analizando el problema usando técnicas y herramientas que permitan construir un modelo que solucione el problema.

Tipos de requerimientos

Agregando mas texto a un post sobre los tipos de requerimientos.

  • Funcionales: Describen las interacciones entre el sistemas y su entorno, funcionalidades que se espera que el sistema proveerá, sus comportamientos a las diferentes entradas y situaciones. Se estudian y se representan en casos de uso.
  • No funcionales: Son características que todo software implícitamente debe proveer, son restricciones que puede tener de las funcionalidades, como restricciones de tiempo, restricciones de desarrollo, restricciones de desarrollo. Describen aspectos del sistema visibles por el usuario que no se relacionan en forma directa con el comportamiento funcional del sistema

Tipo de especificación de requerimientos funcionales

  • Requerimientos del sistema: Los servicios y las restricciones están definidos de manera estructurada y escritos de tal forma que se detalla de que manera deben estar implementados.
  • Requerimientos de usuario: Se caracterizan por estar escritos en lenguaje natural describiendo los servicios y las restricciones del sistema.

Clasificación de requerimientos no funcionales

  • Requerimientos del producto: Requerimientos que especifican que el  producto deba comportarse de una determinada manera.
  • Requerimientos Organizacionales: Requerimientos que surgen de políticas y procedimientos del organización (Creadora o Usuaria).
  • Requerimientos Externos: Requerimientos surgidos por factores externos al proyecto de desarrollo como tal.

Ejemplos 

Requerimientos del producto

  • La interfaz debe ser implementada en HTML puro (Sin applets, Javascript, o frames). 

Requerimientos organizacionales

  • El proceso de desarrollo debe estar conforme con el SIG de la corporación.

Requerimientos Externos

  • La información médica de un paciente, no debe estar al alcance del público general.

Métricas o características deseadas para los requerimientos.

Estas se pueden encontrar en un post que ya realice anteriormente sobre las caracteristicas de los requerimientos funcionales.

Modelo para la ingeniería de requerimientos 

Dorfman(1)(3) propone el siguiente modelo para comenzar con el proceso de la ingeniería de requerimientos:

  • Elicitación: Es el proceso mediante el cual el cliente y el analista de un sistema de software descubren, revisan, articulan y entienden las necesidades de clientes y usuario y las restricciones del software y de la actividad de desarrollo.
  • Análisis: Es el proceso de analizar las necesidades de los clientes y de los usuarios para llegar a la definición de los requerimientos del software. 
  • Especificación: Es el desarrollo de un documento que, de manera clara y precisa, registre cada uno de los requerimientos del software. 
  • Verificación: Es el proceso de asegurar que la especificación de requerimientos cumple con las necesidades de los clientes y usuarios, cumple con los estándares definidos en la organización y es una base adecuada para establecer la arquitectura preliminar del proyecto. 
  • Administración: Es la planeación y control de las actividades que ocurren durante el proceso de desarrollo de los requerimientos. 

 Elicitacion:

Pasos para el procesos de elicitacion:

  • Identificar el problema
  • Definir las fronteras de la solución
  • Identificar las restricciones impuestas a la solución
  • Entender las necesidades del los clientes y usuarios.

Identificación del problema

Es importante que la definición del problema sea consensada por el cliente y todos los involucrados en el proceso de desarrollo. La manera más sencilla de lograr esto es escribir el problema y modificarlo hasta que se logre un consenso.

El problema es uno solo? La respuesta es SI. Cada proyecto debe tener un solo enunciado del problema por lo tanto el enunciado debe ser el de mas alto orden encontrado.

Un error frecuente es que los analistas confunden el verdadero problema con los efectos finales o los síntomas que el problema produce, en estos casos es útil preguntar ¿por qué sucede esto?, hasta llegar a lo que se puede considerar la raíz del problema o el problema detrás del problema. 

Tecnicas:

Para descubrir el problema detrás del problema se puede usar

  • Diagramas de cola de pescado
  • Diagramas de pareto.

Formato

Un formato que puede ayudarnos a identificar el problema es el siguiente (1):


El problema de: (Descripción del problema) 

Afecta a: (Identificar a los usuarios y clientes afectados por el problema)

En qué: (Describir el impacto del problema en los afectados y en las actividades del negocio)

Una solución exitosa es: (Indicar la solución propuesta y listar los principales beneficios)

Por ejemplo:

En un hospital se tiene problemas con el tiempo para generar la factura de los pacientes dados de alta. El departamento de quejas recibe muchas protestas de clientes sobre el tiempo en el que se tardan en entregarles su factura y el departamento de mercadotecnia ha detectado que se registra una fuerte pérdida de clientes por esta causa.

El director del hospital llegó a la conclusión de que es necesario comprar un nuevo sistema de facturación para evitar seguir perdiendo clientes. Una investigación en el mercado de ERP para hospitales da como resultado que el presupuesto y el tiempo de implementación de esta solución, la dejan fuera de las necesidades actuales del hospital.

El director entonces, invita a una empresa de consultoría y desarrollo para que lo ayude a encontrar una solución. La empresa comienza el proceso de elicitación y descubre que las causas del problema de facturación son las siguientes:

El sistema actual no permite dividir una cuenta en varias facturas. Cuando un paciente quiere reclamar los cargos de su cuenta que cubre su seguro a su compañía aseguradora, el cajero tiene que cancelar la cuenta del paciente y posteriormente crear dos cuentas separadas para facturar.

En ocasiones los médicos avisan del alta al paciente antes que a la enfermera encargada, por lo que la enfermera no envía el alta del paciente a la caja y la factura se demora.

El área de Laboratorio no está conectada al sistema del hospital por lo que los cargos a la cuenta del paciente se hacen a través del área de farmacia. Debido que estos cargos no se hacen en línea el cajero tiene que hablar a farmacia para saber si el paciente no tiene cargos pendientes.

El sistema no permite cambios una vez que se cierra la factura. En ocasiones algún área del hospital informa de algún cargo pendiente después de que el cajero cerró la factura, o el cliente nota que su nombre o su dirección están incorrectas. Esto provoca que la factura tenga que ser cancelada y creada nuevamente. 

Con esta información, la empresa consultora genera estadísticas de una muestra representativa de facturas y descubre lo siguiente: Ya que el 80% de los pacientes entran por medio de una compañía aseguradora, el principal problema de facturación del hospital es la imposibilidad de dividir una cuenta en varias facturas. En la estadística también aparece el segundo problema en importancia es la imposibilidad de hacer cambios a una factura cerrada. En este punto, la empresa consultora, decide reformular el problema de esta manera:

El problema de: Generar cambios en las cuentas y en las facturas de los clientes.

Afecta a: Los clientes en general, la gerencia del hospital.

En qué: Los clientes tienen que esperar hasta una hora para recibir su factura, lo que provoca que no recomienden al hospital y que elijan otro hospital para atenderse.

Una solución exitosa es: Modificar el sistema actual para que permita:

Generar varias facturas a partir de la misma cuenta.

Realizar cambios a una factura cerrada.

Bibliografia

  • Richard H. Thayer, Merlin Dorfman. Software Requirements Engineering, IEEE 1997.
  • The Standish Group, Chaos Report, http://standishgroup.com/visitor/chaos.htm.
  • Alan M. Davis. Private comunications, 1996
  • Dean Leffingwell, Don Widring. Managing Software Requirements (A Unifiend Approach). Addison Wesley 2000. 
1/5 - (1 voto)