11.1 Efectos del lenguaje natural
El uso del lenguaje natural en la redacción de requerimientos se refiere al uso de la escritura para describir los detalles de un requerimiento como mecanismo de comunicación entre el usuario final y el equipo de desarrollo.
Utilizar el lenguaje natural en muchas ocasiones provoca ambigüedad ya que un texto puede ser interpretado de diferentes formas. El ingeniero de requerimientos debe estar consciente de la posibilidad de una lectura errónea, sobre todo porque los requisitos de un software son revisados por personas diferentes, con antecedentes académicos diversos y objetivos distintos.
Un ejemplo de un mensaje ambiguo, que es frecuentemente objeto de debate, es el que encuentras al pie de las escaleras eléctricas: “Los perros deben ser cargados” que puede leerse también como “Deben llevarse perros” y sugiere la absurda idea que para utilizar las escaleras es obligatorio llevar un perro. El mensaje correcto debería ser “Si tienes un perro, debes cargarlo al utilizar las escaleras”.
Otro ejemplo puede ser el anuncio en una construcción que dice “Sedeben utilizar zapatos”, que no quiere decir “Si tienes zapatos, úsalos”, sino “Usa zapatos de seguridad”.
Sommerville (2011 ), ofrece las siguientes recomendaciones:
- Estandariza la forma de redactar los requerimientos. Esto permitirá que hagas un esfuerzo por describirlos de forma completa y no se omitan detalles importantes.
- Utiliza una redacción consistente. Los requerimientos que son obligatorios, es decir, indispensables para el sistema, redáctalos utilizando el verbo: “deberá”, mientras que los requerimientos deseables, utilizar “debería” o “podría”.
- Utiliza algún estilo de fuente (negrilla, itálica, marcador de texto) para resaltar las partes más importantes de un requerimientos.
- Nunca asumir que el lector entenderá el lenguaje técnico de ingeniería de software como “arquitectura”, “módulo” o “interfaz”, ya que pueden malinterpretarse.
Sommerville (2011) sugiere utilizar el siguiente formato para evitar la variabilidad en la descripción de los requerimientos, que es uno de los problemas al utilizar el lenguaje natural.
Elemento |
Descripción |
Identificador |
Identificador del Requerimiento/Versión del documento |
Función |
Título de la función o entidad |
Descripción |
Descripción de la función o entidad a especificar |
Entradas |
Descripción de sus entradas y de dónde provienen |
Salidas |
Descripción de sus salidas y hacia dónde van |
Destino |
Ubicación de la función en el sistema |
Acción |
Descripción del requerimiento |
Precondición |
Especificar la precondición que se debe cumplir antes de invocar la función |
Postcondición |
Especifica lo que será verdad una vez invocada dicha función |
Efectos colaterales |
Efectos o posibles resultados alternos que se podrían dar |
Nota: En caso de ser necesario, la redacción del requerimiento puede hacer referencia a otros documentos que detallen la información.
Por ejemplo, si deseas describir la función un sistema de atención a fallas (SAF)
Identificador |
REQ-01v3 / ERS-SAF-v.10 |
Función |
Ingresar un registro de falla. |
Descripción |
El usuario ingresará los datos generales para registrar una falla detectada por el cliente. |
Entradas |
Número de cliente, número de servicio. |
Salidas |
Número de reporte de falla, tiempo promedio de resolución. |
Destino |
Control Principal. |
Acción |
El sistema deberá presentar un formulario para ingresar los datos generales del reporte de falla: número de cliente, número de servicio, datos del usuario que registra la falla, severidad, descripción de la falla. |
Precondición |
El sistema debe tener registrado al cliente. El servicio del cliente debe estar registrado. Si estas condiciones no se cumplen mostrar el mensaje “No existe el registro del cliente” o “No existe el registro del servicio asignado al cliente”. |
Postcondición |
El sistema deberá calcular el tiempo promedio de resolución basándose en el tipo de falla
(Ver anexo KnowledgeDataBase_v2.4). |
Efectos colaterales |
Ninguno. |
11.2 Calidad en los requerimientos
Es necesario que el ingeniero de requisitos tenga una presentación con los siguientes atributos que permitan redactar los requisitos con calidad:
Haz clic en cada atributo para conocer la información.
Pohl y Rupp (2011) sugieren dos principios fundamentales para mejorar la legibilidad al redactar requerimientos:
Las frases y párrafos cortos: Redactar los requerimientos de la forma más corta posible ofrece aprovechar la memoria a corto plazo de las personas, se recomiendan máximo 7 oraciones.
Formular un único requisito por oración: Utilizar la voz activa y sólo un verbo de proceso. Evitar frases entrelazadas largas y complicadas.
Observa la redacción del siguiente requerimiento:
“El sistema deberá ser amigable para el usuario y generar un reporte rápido de las órdenes de clientes más recientes que pueda leerse con facilidad”.
Como puedes observar en la redacción del requerimiento anterior, las palabras “amigable”, “rápido” y “facilidad”, son términos ambiguos que podrían producir errores de interpretación. Lo que para un usuario puede considerarse una característica “amigable”, “rápida” o “fácil” para otro no lo sería.
Este mismo problema aparecería en el equipo de desarrollo, ¿Cómo asegurar el diseño de una
interfaz “amigable”?, ¿Qué significa “rápido”: 1 minuto, 30 segundos, 1 milésima de segundo?
Una posible redacción más adecuada podría ser:
REQ-01: El sistema deberá poder ser utilizado por los usuarios que hayan pasado por un curso de capacitación de 2 horas. Se espera que el usuario cometa menos de 3 errores en promedio al capturar órdenes de venta.
REQ-02: El reporte de órdenes de cliente deberá ser obtenido en menos de 2 segundos.
REQ-03. El reporte deberá mostrar las 10 órdenes más recientes del cliente.
REQ-04. Las órdenes deberán ser mostradas en orden descendente tomando como base la fecha de creación y en una hoja tabular, incluyendo los siguientes datos: número de orden, fecha de creación, producto solicitado.
Observa cómo el requerimiento se divide en 4 partes. Esto permite que pueda ser analizado con mayor detalle, incluso cada requerimiento puede ser asignado a grupos de desarrollo distintos, el primero es para el diseñador de interfaz gráfica y los requerimientos 2, 3 y 4 pueden ser para un grupo de reportes y análisis de datos.
La redacción del REQ-01 expresa la cualidad “sistema amigable” a través de una clara descripción de lo que se espera: evitar introducir errores al sistema de órdenes de compra. Mientras que el texto del REQ-02 describe las cualidades “rapidez” al expresar claramente el tiempo de espera. Los REQ-03 y REQ-04 puntualizan la “facilidad” mediante una explicación de las características del reporte.
11.3 Criterios de calidad en la documentación
Pohl y Rupp (2011) recopilan los siguientes criterios de calidad del documento de requerimientos, tomando en cuenta algunos estándares que aún siguen vigentes:
Claridad y consistencia [IEEE Std. 830-1998]
Claridad en su estructura
Modificable y extensibilidad [IEEE Std. 830-1998]
Completitud [IEEE Std. 830-1998]
Trazabilidad [IEEE Std. 830-1998]
- Claridad y consistencia: Un documento de requerimientos es claro cuando los requisitos individuales que recopila son redactados sin ambigüedades. Para tener esta certeza, es posible realizar el siguiente ejercicio: se toma al azar un grupo de requerimientos y se les pregunta a los usuarios qué entendieron. Si todos llegan a la misma conclusión, quiere decir que son claros. Si se realiza este ejercicio un par de veces más, puedes estar tranquilo que la redacción utilizada en el documento es bastante clara.
La consistencia se logra al comparar los requerimientos individuales entre sí, el objetivo es cerciorarse que no se contradicen unos con otros.
Para Pohl y Rupp (2011) otro aspecto de la claridad del documento es que sea posible identificar a cada uno de los requerimientos de forma individual y única en el mismo, entre otros documentos de requerimientos del mismo o de otro proyecto.
- Claridad en su estructura: Una buena estructura en los requerimientos facilita la comprensión del documento, ya que los stakeholders podrán ubicar las partes que más le interesan y donde requieren poner más atención, mientras que otras las podrían pasar por alto.
- Modificable y extensibilidad: Es natural que los requerimientos cambien, ya sea añadiendo, modificando o eliminando información, o incluso cancelándolos si carecen de sentido. La redacción y estructura del documento de requerimientos debe permitir estos cambios de forma ágil.
- Completitud: El documento de requerimientos debe incluir referencias (documentos, diagramas, gráficas, tablas) que complementen la descripción.
- Trazabilidad: Utilizan algún mecanismo de identificación para poder rastrear su origen y explicar su existencia. El documento de requerimientos debe estar alineado con la estrategia del negocio para que cree valor a la organización. La trazabilidad facilita el control de cambios y el análisis de impacto cuando se modifica o elimina un requerimiento.
