El documento SRS es revisado por la persona que realiza la prueba o un grupo de personas mediante el uso de cualquier método de verificación (como revisiones por pares, recorridos, inspecciones, etc.). Podemos utilizar inspecciones debido a su eficacia y capacidad para producir buenos resultados. Podemos realizar revisiones dos veces o incluso más a menudo. Cada revisión mejorará la calidad del documento, pero puede consumir recursos y aumentar el costo del desarrollo del software . Una lista de verificación es una herramienta de verificación popular que consiste en una lista de contenido de información crítica que debe contener un entregable. Una lista de verificación también puede buscar información duplicada, información faltante, información poco clara, información incorrecta, etc. Las listas de verificación se utilizan durante la revisión y pueden hacer que las revisiones sean más estructuradas y efectivas.
Una lista de verificación de documentos SRS debe abordar los siguientes problemas:
- Corrección:
en el documento SRS, cada requisito establecido en el documento debe representar correctamente una expectativa del software propuesto. Se deben identificar todos los requisitos de seguridad y protección aplicables. Además, todas las entradas y salidas de cada requerimiento son requeridas y suficientes para el procesamiento especificado. Por ejemplo, si hay un requisito del cliente para que el software responda a todos los botones presionados dentro de los 2 segundos, pero el SRS establece que «el software responderá a todos los botones presionados dentro de los 20 segundos», entonces eso se considerará incorrecto en el documentación.
- Ambigüedad:
el documento SRS puede contener cierta ambigüedad en los requisitos del software. Por ejemplo , si un requisito transmite más de un significado de una cosa, entonces será un problema grave, por lo que, para evitar esta ambigüedad, cada requisito debe tener un solo significado. Por lo tanto, la declaración de requisitos de software debe ser breve, correcta, precisa y clara. La lista de verificación del documento SRS debe centrarse en palabras ambiguas para evitar la ambigüedad.
- Integridad:
el documento SRS debe estar completo en todos los aspectos, ya que debe tener todos los requisitos funcionales importantes (como fallas de hardware, errores de E/S, errores de cómputo, sobrecarga de procesamiento, desbordamiento de búfer, eventos que no ocurren, etc.) y no funcionales. Los requisitos necesarios para el software y esta integridad del documento SRS deben verificarse minuciosamente a través de una lista de verificación.
- Consistencia:
en el documento SRS, la consistencia del documento se puede mantener si todos los requisitos establecidos no varían de los otros requisitos establecidos. Se hace referencia a cada objeto con un nombre único y se define por un conjunto de características que no están en conflicto entre sí. Además, si las ecuaciones matemáticas, los acrónimos y las abreviaturas se definen y utilizan de forma coherente, el documento será coherente. La lista de verificación debe resaltar los problemas relacionados con la inconsistencia y debe estar diseñada para encontrar inconsistencias.
- Verificabilidad:
en el documento SRS, se dice que es verificable, si y solo si, todos los requisitos establecidos en el documento son verificables. Los requisitos no verificables incluyen declaraciones como ‘buenas interfaces’, ‘excelente tiempo de respuesta’, ‘generalmente’, ‘bien’, etc., que no deben usarse. Se debe utilizar la terminología de los requisitos como «deberá», «hará», «podrá», etc. En el documento, solo debemos usar términos medibles y debemos evitar todos los términos indefinidos.
- Trazabilidad:
el documento SRS puede rastrearse si la fuente de todos y cada uno de los requisitos se define correctamente, ya que puede ayudar en el desarrollo futuro. La trazabilidad puede ayudar a estructurar el documento y debe encontrar un lugar en el diseño de la lista de verificación.
- Viabilidad:
en el documento SRS, algunos de los requisitos pueden no ser factibles de implementar debido a razones técnicas o falta de recursos, por lo que dichos requisitos deben identificarse y, en consecuencia, eliminarse del documento SRS. Una lista de verificación de documentos también puede ayudarnos a encontrar otros requisitos no factibles en el software. Como por ejemplo, los datos esperados de fuentes externas deben existir en las fuentes definidas, o los datos enviados a destinos externos se esperan en esos destinos, de lo contrario, los requisitos pueden no ser factibles de implementar.
Publicación traducida automáticamente
Artículo escrito por tarunsinghwap7 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA