Guía para la especificación de requerimientos de software
Esta guía tiene como propósito estandarizar la documentación de requisitos funcionales y no funcionales en proyectos de software, asegurando que sean claros, verificables y rastreables. Su alcance abarca la creación de documentos de requerimientos siguiendo buenas prácticas, aplicable a cualquier proyecto dentro de la organización, y establece las bases para un desarrollo exitoso.
Requisito funcional
Los requisitos funcionales describen el funcionamiento del software, pero existen dos tipos de requisitos funcionales (RF):
-
RF de usuario, son oraciones que pueden llegar a ser muy generales, como: “El sistema debe permitir al usuario eliminar sus comentarios en la plataforma”. Los RF de usuario son identificables respondiendo la pregunta: ¿Qué servicio debe prestar el sistema?
-
RF de sistema, que deben describir los servicios con mucho detalle, como: “El sistema debe generar reportes con los campos: Tiempo, consumo eléctrico y costo monetario en pesos mexicanos“. Los RF de sistema son identificables por el detalle del mismo requisito.
Estandarización para la especificación de requisitos de software
Según la IEEE/ANSI 830-1998:
Se debe crear un documento de requerimientos en el que se detalle:
-
Propósito del documento.
-
El alcance del proyecto.
-
La perspectiva del producto.
-
Funciones del producto.
-
Características de los usuarios.
-
Limitaciones.
-
Suposiciones y dependencias
-
Requisitos funcionales y no funcionales.
-
Apéndices e Índice.
Asimismo, el documento debe tener las siguientes características:
-
Correcto: Describe el producto de software a entregar.
-
Rastreable: Cada requisito se puede seguir desde su origen hasta su implementación.
-
Completos: Todos los requisitos necesarios deben estar incluidos.
-
Modificable: Sus requisitos deben tener la capacidad de ser modificados con facilidad.
-
Consistente: No debe haber requisitos contradictorios.
-
Verificable: Todos los requisitos deben poder ser probados.
-
No es ambigüo: Cada requisito debe tener una sola interpretación.
-
Priorizable: Los requisitos deben ser priorizados de acuerdo a su relevancia dentro del proyecto.
¿Cómo es que aporta valor?
El estándar está centrado en proporcionar claridad tanto al documento como a cada tema que contiene. El estándar ofrece una estructura que incluye la información esencial, además de implementar buenas prácticas en la documentación de requisitos.
Referencias
-
C.Robinson. 4.0 My Introduction to requirements. (s.f.). Google Docs. https://docs.google.com/presentation/d/16Tuxvln_nG6cld5UQ2s_7mVBUNBOYC-t9RzfXkbYJK8/edit#slide=id.g11958c48d67_1_5
-
C.Robinson. 4.0_REQ.pptx. (s.f.). Google Docs. https://docs.google.com/presentation/d/1uVHB2n_HSG597TdDv5CO3j9NHtgl-XH0/edit#slide=id.p20
Historial de cambios
| Tipo de versión | Descripción | Fecha | Colaborador |
|---|---|---|---|
| 1.0 | Guía de SRS. | 06/03/2025 | Juan Pablo Chávez, Daniel Queijeiro |
| 1.1 | Gestión de configuración. | 24/04/2025 | Diego Fuentes |
| 1.2 | Introducción, propósito y alcance. | 25/04/2025 | Hiram Mendoza |