Especificación de requisitos - Approach

<p style="text-align:left;">Es conocido que, en ciertos casos, los desarrolladores debemos cumplir también con el rol de analista. Es conocido, además, que para la construcción y el análisis de software, existen varios caminos. Uno de ellos, es la conocida <span style="font-weight:bold;">codificación y corrección </span>iterativa, bastante utilizada en los inicios de la transición como desarrolladores a analistas funcionales. En constraste, otro de los caminos es la realización de una especificación de requisitos (o <span style="font-weight:bold;">ERS</span>), tema del cual se dará un <span style="font-style:italic;">approach </span>en este, mi primer, artículo. Al ser una aproximación, no se hablará de herramientas CASE (por ejemplo, Enterprise Architect), ni tampoco se hará hincapié en UML u otras técnicas de modelado.</p><p class="MsoNormal" style="text-align:left;"><span><br /></span></p><h3 style="text-align:left;">Requisitos y ERS</h3><p class="MsoNormal" style="text-align:left;">Un <span style="font-weight:bold;">requisito </span>o <span style="font-weight:bold;">requerimiento</span>, es una condición o capacidad que un sistema "debe" poseer. Algunos autores y personas, suelen hacer diferencia entre requisitos y requerimientos, tomando los primeros como algo “obligatorio” y los segundos como algo, en ciertos casos, "deseable". En este artículo no se harán tales diferencias (al menos explícitamente). Yendo al grano, es posible destacar los siguientes <span style="font-weight:bold;">tipos </span>requerimientos:</p><p></p><p class="MsoListParagraphCxSpFirst"></p><ul><li style="text-align:left;"><b>1. Funcionales</b>: Servicios que el sistema <span style="font-weight:bold;">debe otorgar </span>como tal. Ejemplo: Es indispensable en un sistema de ventas, el proceso de venta de un producto.<br /></li><li style="text-align:left;"><b>2. No funcionales</b>: Son <span style="font-weight:bold;">restricciones </span>del sistema, normalmente causadas por agentes externos. Por ejemplo, en ciertos casos, para la lectura de documentos exportados del sistema se necesitará un lector de PDF.<br /></li><li style="text-align:left;"><b>3. De usuario</b>: Son las operaciones del sistema esperadas por los <span style="font-weight:bold;">usuarios </span>finales, en lenguaje natural. Estos requerimientos deben, obligatoriamente, verificarse con el usuario.<br /></li><li style="text-align:left;"><b>4. De sistema</b>: <span style="font-weight:bold;">Derivan de los requerimientos de usuario</span>, siendo, normalmente, el detalle de estos. Es deseable, también, la verificación de estos con el cliente. Debido a la presencia de tecnicismos, no siempre es posible.<br /></li></ul><p></p><p></p><p></p><p></p><p></p><p class="MsoNormal"></p><p></p><ul><li style="text-align:left;">Por consiguiente, una <span style="font-weight:bold;"><span style="font-weight:normal;">especificación de requisitos (de ahora en más </span>ERS</span>) es la de descripción del <span style="font-style:italic;">“futuro”</span> software en todos sus aspectos, en base a un <b>relevamiento inicial</b>, el cual posteriormente puede ser retroalimentado por esta especificación en una suerte de proceso iterativo. Es importante aclarar que <span style="font-weight:bold;">el usuario es inherente </span>a la construcción de este documento: Una buena ERS, verificada con el cliente, puede ser tomada como contrato formal.<br /></li><li style="text-align:left;"><span><br /></span></li></ul><p></p><h4 style="text-align:left;">Más notas...</h4><p class="MsoNormal" style="text-align:left;"><span style="font-weight:bold;">1. </span>Es importante la <span style="font-weight:bold;">numeración de los requisitos</span> y la descripción de los mismos en tiempo “<span style="font-weight:bold;">futuro</span>” (el software relevado, se supone, aún no existe).</p><p class="MsoNormal" style="text-align:left;"><span style="font-weight:bold;">2. </span>Es posible nombrar ciertos requisitos bajo la categoría de <span style="font-weight:bold;">opcionales</span>, también denominados “<span style="font-weight:bold;">deseables</span>”. Su desarrollo añade un "plus" al sistema, pueden ser implementados o no, pero pueden pasar a ser requisitos obligatorios en futuras reversiones.</p><p></p><p class="MsoNormal"></p><p style="text-align:left;"> </p><h4 style="text-align:left;">Un ejemplo para entender mejor...</h4><p class="MsoNormal" style="text-align:left;"><span></span></p><p class="MsoNormal">Documento "Análisis de sistema <span style="font-style:italic;">'xxxx.doc'.</span>"</p><table class="table table-bordered"><tbody><tr><td><p class="MsoNormal"><span style="font-weight:bold;">Requisitos funcionales</span></p><p class="MsoNormal">Nota: En el primer nivel de la lista, se encuentran definidos los requisitos de <span style="font-weight:bold;">usuario</span>, mientras que en los sub-niveles, los de <span style="font-weight:bold;">sistema</span>.</p><p></p><p class="MsoListParagraphCxSpFirst">1. El usuario administrador podrá agregar, eliminar, modificar y listar de personas.</p><p></p><p class="MsoListParagraphCxSpMiddle"><span style="font-style:italic;">      1.1. El sistema no permitirá  dos personas con un mismo DNI.</span></p><p></p><p class="MsoListParagraphCxSpMiddle"><span style="font-style:italic;">      1.2. El sistema no permitirá realizar baja física, esta deberá ser lógica.</span></p><p></p><p class="MsoListParagraphCxSpLast"><span style="font-style:italic;">      1.3. El sistema no permitirá la modificación del DNI de una persona.</span></p><p></p><p class="MsoNormal">2. El usuario deberá establecer un nombre y un apellido para una persona.</p><p></p><p class="MsoNormal"><span style="font-style:italic;">      2.1. El sistema no permitirá la carga de una persona sin nombre ni apellido.</span></p><p></p><p class="MsoNormal"></p><p> </p><p class="MsoNormal"><span style="font-weight:bold;">Requisitos no funcionales</span></p><p></p><p class="MsoListParagraph">1. Para la visualización de archivos exportados, será necesario un software lector de PDF. </p></td></tr></tbody></table><p style="text-align:left;"><br /></p><h3 style="text-align:left;">Conmensurando la ERS y la codificación de software</h3><p class="MsoNormal" style="text-align:left;">En el ejemplo mencionado, los requisitos 1.1, 1.3 y 2.1, pueden, claramente, transformarse en piezas de código, más precisamente en sentencias de condición "if", por lo que la ERS no es algo <span style="font-weight:bold;">"lejano" </span>a la construcción de software. Por otra parte, la repetición de ciertos conceptos, data acerca de la construcción del <span style="font-weight:bold;">modelo de datos </span>y los <span style="font-weight:bold;">módulos</span> presentes en el sistema. Por ejemplo, la repetición de la palabra persona, indica la presencia de esta entidad como una futura <span style="font-weight:bold;">tabla </span>y <span style="font-weight:bold;">clase</span>. En este caso, sus propiedades o columnas serán el <span style="font-style:italic;">DNI</span>, el <span style="font-style:italic;">nombre </span>y el a<span style="font-style:italic;">pellido</span>. Además, a partir de los requerimientos es posible la derivación de los diagramas de casos de uso (UML): En el ejemplo dado, el<span style="font-style:italic;"> “usuario administrativo” </span>es un actor, y la acción, en consecuencia, el <span style="font-style:italic;">“Gestionar usuarios”</span>.</p><p>

</p><p class="MsoNormal" style="text-align:left;">Para finalizar, puede que se considere que la construcción de una ERS conlleve a una pérdida de tiempo en el desarrollo, ya que al principio, implementar técnicas de análisis, puede ser un poco tedioso por el tiempo empleado en la definición de los requisitos o requerimientos. Sin embargo, luego de lograr una adaptación es denotable como el desarrollo de código se vuelve más eficiente y el software final, más maduro, siendo este <span style="font-weight:bold;">verificable </span>contra la ERS.</p><p></p>

sistemas ers analisis software requisitos