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.