NORMA IEEE 830

Consideraciones para producir un buen ERS (Especificación de

Requerimientos del Software)
Esta cláusula proporciona información básica que debe tenerse en cuenta al escribir
los requerimientos del Software basándose en la norma IEEE830. Las cuales están
formadas por unas consideraciones que son:
a) Naturaleza del ERS
b) Entorno del ERS
c) Características de un buen ERS
d) Preparación conjunta del ERS
e) evolución del ERS
f) creación de prototipos
g) Diseño incrustado en el ERS
h) Incrustar los requisitos del proyecto en el ERS.
Las cuales se explicarán brevemente, de como se deben de desarrollar para
producir de manera correcta las especificaciones de los requerimientos del Software
según mencionada la norma IEEE830.

a) Naturaleza del ERS

El ERS es una especificación para un producto de software particular, programa o
conjunto de programas que realiza ciertas funciones en un entorno específico. El
ERS puede ser escrito por uno o más representantes del proveedor, uno o más
representantes del cliente o ambos.
Los problemas básicos que los escritores del SRS deben abordar son los siguientes:
a) Funcionalidad ¿Qué se supone que debe hacer el software?
b) Interfaces externas. ¿Cómo interactúa el software con las personas, el
hardware del sistema, otro hardware, y otro software?
c) Performance. ¿Cuál es la velocidad, disponibilidad, tiempo de respuesta,
tiempo de recuperación de varias funciones de software, etc.?
d) Atributos. ¿Cuáles son las consideraciones de portabilidad, corrección,
mantenimiento, seguridad, etc.?
e) Las restricciones de diseño impuestas en una implementación.
 b) Entorno del ERS
Es importante considerar la parte que desempeña el ERS en el plan de proyecto
total, que se define en IEEE 830. El software puede contener esencialmente toda la
funcionalidad del proyecto o puede ser parte de un sistema más grande. En este
último caso, normalmente habrá un SRS que establecerá las interfaces entre el
sistema y su porción de software, y colocará requisitos de desempeño y
funcionalidad externos sobre la parte del software. Por supuesto, el ERS debería
estar de acuerdo con estos requisitos del sistema y ampliarlos.
IEEE 830 describe los pasos en el ciclo de vida del software y las entradas
correspondientes para cada paso.
Dado que el ERS tiene un papel específico que desempeñar en el proceso de
desarrollo de software, el (los) escritor (es) ERS debe (n) ser cuidadosos de no ir
más allá de los límites de ese papel. Esto significa que el ERS debe:
a) Debe definir correctamente todos los requisitos del software. Un requisito de
software puede existir porque de la naturaleza de la tarea a resolver o debido
a una característica especial del proyecto.
b) No debe describir ningún diseño o detalles de implementación. Estos deben
describirse en el diseño etapa del proyecto.
c) No debería imponer restricciones adicionales al software. Estos están
especificados adecuadamente en otros documentos como un plan de
aseguramiento de la calidad del software.

c) Características de un buen ERS

Una ERS nos da ciertos puntos que debemos de tener en cuenta al realizarlo, por
lo cual un ERS debe tener estas características:
a) Correcto
b) inequívoco
c) Completar
d) Consistente
e) Clasificado por importancia y / o estabilidad
f) Verificable
g) Modificable
h) Trazable.
 d) Preparación conjunta del ERS
El proceso de desarrollo del software debe comenzar con el acuerdo del proveedor
y el cliente sobre lo que el software completado debe hacer. Este acuerdo, en forma
de ERS, debe prepararse conjuntamente. Esto es importante porque generalmente
ni el cliente ni el proveedor están capacitados para escribir un buen ERS solo.
a) Los clientes generalmente no comprenden el proceso de diseño y desarrollo del
software lo suficientemente bien como para escribir un ERS utilizable.
b) Los proveedores generalmente no entienden el problema del cliente y su esfuerzo
lo suficientemente bien como para especificar los requisitos para un sistema
satisfactorio.

F) Prototipos
Los prototipos se utilizan con frecuencia durante la parte de requisitos de un
proyecto. Existen muchas herramientas que permiten prototipo, que presenta
algunas características de un sistema, que se creará de manera rápida y sencilla.
Los prototipos son útiles por las siguientes razones:
a) Es más probable que el cliente vea el prototipo y reaccione ante él que leer el
ERS y reaccionarlo. Por lo tanto, el prototipo proporciona una respuesta rápida.
b) El prototipo muestra aspectos imprevistos del comportamiento del sistema. Por
lo tanto, produce no solo respuestas, pero también nuevas preguntas. Esto ayuda
a alcanzar el cierre en el ERS.
c) Un ERS basado en un prototipo tiende a sufrir menos cambios durante el
desarrollo, acortando así tiempo de desarrollo.
g) Diseño incrustado en el ERS
El ERS debe especificar qué funciones se van a realizar sobre qué datos producir,
qué resultados y qué ubicación para quién. El ERS debe enfocarse en los servicios
que se realizarán. El ERS no debería normalmente especificar elementos de diseño
como los siguientes:
a) Particionar el software en módulos
b) Asignación de funciones a los módulos
c) describir el flujo de información o control entre módulos
d) Elegir estructuras de datos.
Requerimientos Necesarios para Diseño
En casos especiales, algunos requisitos pueden restringir severamente el diseño.
Por ejemplo, requisitos de seguridad o seguridad puede referirse directamente al
diseño, como la necesidad de:
a) Mantenga ciertas funciones en módulos separados
b) Permitir solo comunicación limitada entre algunas áreas del programa
c) Verifique la integridad de los datos para las variables críticas.
H) Incrustar los requisitos del proyecto en el ERS
Los requisitos del proyecto representan un entendimiento entre el cliente y el
proveedor sobre el contrato, cuestiones relativas a la producción de software y, por
lo tanto, no deberían incluirse en el ERS. Estos normalmente incluyen elementos
tales como:
a) coste
b) horarios de entrega
c) procedimientos de reporte
d) métodos de desarrollo de software
e) garantía de calidad
f) Criterios de validación y verificación
g) Procedimientos de aceptación.