Especificación y validación de requerimientos. IEEE-830 y plantillas SRS.

 

¿Qué es el estándar IEEE 830?

El estándar IEEE 830 se conoce como el documento de especificación de requerimientos de

software y comprende un listado de los requerimientos y del contexto de la solución, así

como una descripción general del diseño por medio de los casos de uso y los escenarios.

(Info Norma IEEE 830. Recuperado , 2023)

¿Cuál es su propósito?

El propósito principal de esta norma es ayudarnos a elaborar un documento muy útil: el ERS

(Especificación de Requerimientos de Software) y este a su vez tiene como finalidad la

documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con

la totalidad de exigencias estipuladas. (Info Norma IEEE 830. Recuperado , 2023)

Ventajas:

● Facilita la comunicación entre clientes y desarrolladores.

● Funciona como base para realizar las estimaciones del proyecto en costos, tiempo y

magnitud.

● Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos).

● Se tenga una base o referencia para validar o probar el software solicitado.

● Se facilite el traspaso del software a otros clientes/usuarios.

● Se le puedan hacer mejoras (o innovaciones) a ese software. (Info Norma IEEE 830.

Recuperado , 2023)

Especificación de requisitos de software (SRS):

Consejos y plantilla

La comunicación es la clave del éxito en el desarrollo de software. Según un estudio que

examinó por qué las empresas de desarrollo de software luchan por ofrecer a sus clientes

soluciones de software que satisfagan sus expectativas, la mala comunicación y los

requisitos poco claros son algunas de las principales razones por las que los proyectos de

software fracasan. (Especificación de requisitos de software (SRS): consejos y plantillas..

Visure Solutions; Visure Solutions, Inc., 2019)

Los requisitos claros y bien comunicados ayudan a los equipos de desarrollo a crear el

producto adecuado, lo que representa la base del desarrollo exitoso de productos. Pero

¿cómo son realmente esos requisitos y cómo deben comunicarse? La respuesta es simple:

con una especificación de requisitos de software (SRS). (Especificación de requisitos de

software (SRS): consejos y plantillas.. Visure Solutions; Visure Solutions, Inc., 2019)

PLANTILLA IEEE 830(haz click)

¿Qué es un SRS?

Un SRS es un documento cuyo propósito es proporcionar una descripción completa de un

producto de software a desarrollar, incluyendo su propósito, los principales procesos de

negocio que serán soportados, características, parámetros clave de rendimiento y

comportamiento. Como tal, esencialmente sirve como un mapa que guía el proceso de

desarrollo y mantiene a todos en el camino correcto. (Especificación de requisitos de

software (SRS): consejos y plantillas.. Visure Solutions; Visure Solutions, Inc., 2019)

Un SRS es generalmente aprobado al final de la fase de ingeniería de requisitos, la fase

más temprana en el proceso de desarrollo de software. Contiene requisitos funcionales y no

funcionales. Los requisitos funcionales describen la función de un sistema de software y sus

componentes (como la reserva previa de libros al describir un sistema de bibliotecas

universitarias), mientras que los requisitos no funcionales describen las características de

rendimiento del sistema de software y sus componentes (como la seguridad o la

disponibilidad de servicios). (Especificación de requisitos de software (SRS): consejos y

plantillas.. Visure Solutions; Visure Solutions, Inc., 2019)

La especificación IEEE (Institute of Electrical and Electronics Engineers) 830-1998 describe

los métodos y enfoques recomendados para definir un SRS, ayudando a los clientes de

software a describir con precisión lo que desean obtener y facilitando al mismo tiempo a los

proveedores la comprensión exacta de lo que el cliente desea. (Especificación de requisitos

de software (SRS): consejos y plantillas.. Visure Solutions; Visure Solutions, Inc., 2019)

Componentes de un SRS

No hay dos documentos SRS idénticos porque todos los proyectos de software son

diferentes, algunos usando el modelo de desarrollo en cascada, y otros practicando el

desarrollo ágil. Sin embargo, todavía es posible destilar los componentes principales de un

SRS y crear un esquema aproximado de cómo debería ser:

1. Introducción

1. Propósito

2. Audiencia

3. Uso previsto

4. Alcance

5. Acrónimos y definiciones

2. Descripción general

1. Necesidades del usuario

2. Dependencias y Asunciones

3. Requisitos y características del sistema

1. Requisitos funcionales

2. Requisitos de interfaz externa

3. Características del sistema

4. Requisitos no funcionales

(Especificación de requisitos de software (SRS): consejos y plantillas.. Visure Solutions;

Visure Solutions, Inc., 2019)

La primera sección describe el producto que se está desarrollando, su propósito, audiencia

objetivo, uso previsto y alcance. La segunda sección proporciona más información sobre las

necesidades de los usuarios y los factores que podrían impedir que se cumplan los

requisitos establecidos en la SRS. La última sección principal está dedicada a los requisitos

específicos, tanto funcionales como no funcionales. (Especificación de requisitos de

software (SRS): consejos y plantillas.. Visure Solutions; Visure Solutions, Inc., 2019)

¿Cómo escribir un buen SRS?

Un buen SRS debe cumplir con varias características clave. Debería ser:

● Correcto: Es importante asegurarse de que el SRS siempre refleje la funcionalidad

y las especificaciones del producto.

● Sin ambigüedades: Es mejor ser demasiado específico que ambiguo. El SRS no es

una obra maestra literaria, por lo que incluso las reglas estilísticas más básicas

pueden ser ignoradas en nombre de la claridad.

● Finalizar el proyecto: Nunca es una buena idea omitir cualquier característica

solicitada por el cliente.

● Consistente: Todos los acrónimos y definiciones deben ser utilizados de manera

consistente en todo el SRS.

● Clasificación por importancia y/o estabilidad: El tiempo es a menudo un recurso

escaso durante el proceso de desarrollo, por lo que es una buena idea clasificar los

requisitos según su importancia y estabilidad.

● Verificable: Debe haber un método de verificación para cada requisito.

● Modificable: Los cambios en los requisitos deben hacerse de manera sistemática, y

debe tenerse en cuenta su impacto en otros requisitos debe tenerse en cuenta.

● Rastreable: Todos los requisitos deben ser trazables desde su origen.

(Especificación de requisitos de software (SRS): consejos y plantillas.. Visure Solutions;

Visure Solutions, Inc., 2019)