- Especificación Requerimientos Software -

Documento principal

1.1 Información General

Ubicación Electrónica /conversion/tmp/scratch/376753738.odt

1.2 Revisiones

Fecha de Sección
No. Responsable Descripción de la revisión
Emisión: Número
YYYY-MM-DD 1 Nombre Apellido Todas Creación del documento

1.3 Registro de los responsables de Elaboración, Control y Aprobación

Elaboró: Controló: Aprobó:

Firma: Firma: Firma:

Fecha: YYYY-MM-DD Fecha: Fecha

1.4 Propósito y alcance

En esta sección se deben establecer los lineamientos y alcances que tendrá el nuevo producto software desde la
perspectiva de la implementación en la organización y los objetivos que el mismo debe alcanzar para cubrir las
necesidades de ésta.

1.5 Documentación de Referencia

 Norma ISO 9000:2003

 Norma ISO 9001:2003


1.6 Áreas o Funciones Afectadas

Se detallan las diferentes áreas de la organización que se verán afectadas por la implementación de este
sistema, ya sea por la utilización directa del mismo, o porqua la utilización de éste en otra área impacte en el
desarrollo de ésta.


1.7 Ámbito del Sistema

En esta subsección:
Se podrá dar un nombre al futuro sistema (p.ej. MiSistema)
Se explicará lo que el sistema hará y lo que no hará.
Se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema.

Página 1 de 6
 - Especificación Requerimientos Software -
Documento principal

2 Descripción General
En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen
los requisitos, sino su contexto. Esto permitirá definir con detalle los requisitos en la sección 3, haciendo que sean
más fáciles de entender.
Normalmente, esta sección consta de las siguientes subsecciones: Perspectiva del producto, funciones del
producto, características de los usuarios, restricciones, factores que se asumen y futuros requisitos.

2.1 Perspectiva del producto

Esta subsección debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es
totalmente independiente de otros productos, también debe especificarse aquí. Si la ERS define un producto que
es parte de un sistema mayor, esta subsección relacionará los requisitos del sistema mayor con la funcionalidad
del producto descrito en la ERS, y se identificarán las interfaces entre el producto mayor y el producto aquí
descrito. Se recomienda utilizar diagramas de bloques.
2.2 Funciones del Producto
En esta subsección de la ERS se mostrará un resumen, a grandes rasgos, de las funciones del futuro sistema. Por
ejemplo, en una ERS para un programa de contabilidad, esta subsección mostrará que el sistema soportará el
mantenimiento de cuentas, mostrar ́ el estado de las cuentas y facilitará la facturación, sin mencionar el enorme
detalle que cada una de estas funciones requiere.
Las funciones deberán mostrarse de forma organizada, y pueden utilizarse gráficos, siempre y cuando dichos
gráficos reflejen las relaciones entre funciones y no el diseño del sistema
2.3 Características de los Usuarios
Esta subsección describe las características generales de los usuarios del producto, incluyendo nivel educacional,
experiencia y experiencia técnica.

2.4 Restricciones
Esta subsección describe aquellas limitaciones que se imponen sobre los desarrolladores del producto
◦ Políticas de la empresa
◦ Limitaciones del hardware
◦ Interfaces con otras aplicaciones
◦ Operaciones paralelas
◦ Funciones de auditoría
◦ Funciones de control
◦ Lenguaje(s) de programación
◦ Protocolos de comunicación
◦ Requisitos de habilidad
◦ Criticidad de la aplicación
◦ Consideraciones acerca de la seguridad

Página 2 de 6
 - Especificación Requerimientos Software -
Documento principal

2.5 Suposiciones y dependencias

Esta subsección de la ERS describe aquellos factores que, si cambian, pueden afectar a los requisitos. Por
ejemplo, los requisitos pueden presuponer una cierta organización de ciertas unidades de la empresa, o pueden
presuponer que el sistema correrá sobre cierto sistema operativo. Si cambian dichos detalles en la organización de
la empresa, o si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario revisar y
cambiar los requisitos.

2.6 Requisitos Futuros

Esta subsección esbozará futuras mejoras al sistema, que podrían analizarse e implementarse en un futuro.

3 Requisitos Específicos
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores, diseñar
un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que
demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí especificado describirá
comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta
es la sección más larga e importante de la ERS.
A lo largo de esta sección, cada requisito declarado debe ser externamente perceptible por los usuarios,
operadores u otros sistemas externos. Estos requisitos deben incluir como mínimo una descripción de cada
entrada (estímulo) en el sistema, cada salida (respuesta) del sistema y todas las funciones realizadas por el
sistema en respuesta a una entrada o en apoyo de una salida. Como esto es a menudo la parte más grande y más
importante del ERS, se debe considerar que todos los requisitos deben estar identificados en forma única y que se
debe prestar especial atención a su organización para maximizar su legibilidad.
Deberán aplicarse los siguientes principios: Correctos, no ambiguos, completos, consistentes, testeables,
modificables, trazables.
3.1 Interfaces Externas
Se describirán los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software)
e interfaces de comunicaciones.
Si existe la posibilidad de intercambiar información con otros sistemas por medio de archivos, en esta sección se
deberán definir las nomenclaturas de los archivos, la direccion de la información (entrada o salida), el formato de
los mismos y cuáles serán las funcionalidades encargadas de procesarlos.
En caso de interfaces de comunicaciones (protocolos, web services, etc) se deberán definir en esta sección, con el
mayor detalle posible, incluyendo mensajes, parámetros, etc.

3.2 Funciones (Requisitos Funcionales)

Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el software, en la
aceptación, procesamiento de los insumos y la generación de salidas. Estos generalmente aparecen como
declaraciones "deberá" que comienzan con "El sistema deberá ...".
Estos incluyen:

Página 3 de 6
 - Especificación Requerimientos Software -
Documento principal

a) Validez de los controles de los insumos

b) La secuencia exacta de las operaciones
c) Las respuestas a las situaciones anormales, incluyendo
1) Overflow
2) Servicios de comunicación
3) Tratamiento de errores y recuperación
d) El efecto de parámetros.
e) Relación de las salidas a las entradas, incluyendo
1) Secuencias de Entrada/salida
2) Las fórmulas para la entrada a la conversión de salida.
Puede ser apropiado dividir los requisitos funcionales en sub-funciones o subprocesos, lo cual no implica que el
diseño de software también se dividirá así.
Para cada requisito debe indicar:
• Resumen del objetivo de la funcionalidad.
• Datos de Entrada: Establece los valores que tomará de entrada la funcionalidad. En algunos casos podría
no haber datos de entrada.
• Procesos: Describir con el mayor de los detalles posibles y con la secuencia correcta; las acciones,
validaciones, mensajes, datos, etc, que deben estar involucrados en este requisito.
• Datos de Salida: Describe los datos o procesos que se obtienen como resultado de la ejecución de este
requisito.
3.3 Requisitos de Rendimiento
Se detallan los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el
número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones
por segundo que deberá soportar el sistema, etc.
También, si es necesario, se especificarán lo requisitos de datos, es decir, aquellos requisitos que afecten a la
información que se guardará en la base de datos. Por ejemplo, la frecuencia de uso, las capacidades de acceso y
la cantidad de registros que se espera almacenar (decenas, cientos, miles o millones).
Se debe especificar tanto los requisitos numéricos dinámicos y estáticos, localizados en el software o en la
interacción humana con el software en su conjunto. Los requisitos numéricos estáticos pueden incluir los
siguientes:
a) El número de terminales a ser soportadas.
b) El número de usuarios simultáneos a ser soportados.
c) La cantidad y tipo de información a ser manejada.
Los requisitos numéricos estáticos se identifican a veces en una sección separada titulada Capacidad. Los
requisitos numéricos dinámicos pueden incluir, por ejemplo, el número de transacciones, tareas y cantidad de datos
que se procesan dentro de ciertos plazos para condiciones normales y pico de carga de trabajo. Todos estos
requisitos deben expresarse en términos mensurables.
Por ejemplo, El 95% de las transacciones deben ser procesadas en menos de 1 seg.
En lugar de, El operador no tiene que esperar a que la transacción sea completada.

Página 4 de 6
 - Especificación Requerimientos Software -
Documento principal

3.4 Requisitos lógicos de Bases de Datos

Se debe especificar los requisitos lógicos para cualquier información que se va a colocar en una base de datos.
Esto puede incluir la siguiente:
a) Tipos de información usada por las diversas funciones;
b) La frecuencia de uso;
c) Capacidades de acceso;
d) Las entidades de datos y sus relaciones;
e) Las restricciones de integridad;
f) Los requisitos de retención de datos.

3.5 Restricciones de Diseño

Todo aquello que restrinja las decisiones relativas al diseño de la aplicación: Restricciones de otros estándares,
limitaciones del hardware, etc.

3.6 Restricciones de Normas

Esta subdivisión debe especificar los requisitos derivados de las normas o reglamentos vigentes.
Se pueden incluir los siguientes:
a) Formato del informe;
b) Los datos de nombres;
c) Los procedimientos de contabilidad;
d) el seguimiento de auditoría.
Por ejemplo, esto podría especificar el requisito de software para auditar la actividad de procesamiento. Dichos
datos de auditoría son necesarios en algunas aplicaciones para satisfacer las normas reglamentarias o financieras
mínimas. Un requisito de rastro de auditoría puede ser, por ejemplo, que todos los cambios en una base de datos
de la nómina deban registrarse en un archivo de seguimiento con valores anteriores y posteriores.
3.7 Atributos del sistema
Se detallarán los atributos de calidad (las “ilities”) del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy
importante, la seguridad. Deberá especificarse qué tipos de usuario están autorizados, o no, a realizar ciertas
tareas, y cómo se implementarán los mecanismos de seguridad (por ejemplo, por medio de un login y una
password ).
3.7.1 Confiabilidad
Se debe especificar los elementos necesarios para establecer la confiabilidad requerida del sistema de software en
el momento de la entrega.
3.7.2 Disponibilidad
Se debe especificar los factores necesarios para garantizar un nivel de disponibilidad definida para todo el sistema,
tales como punto de control, la recuperación, y reiniciar.

Página 5 de 6
 - Especificación Requerimientos Software -
Documento principal

3.7.3 Seguridad
Esto debe especificar los factores que protegen el software del acceso accidental o intencional, uso, modificación,
destrucción o divulgación. Los requisitos específicos en esta área podrían incluir la necesidad de:
a) Utilizar algunas técnicas criptográficas;
b) Mantener registro específico o conjuntos de datos de historia;
c) Asignar determinadas funciones a los diferentes módulos;
d) restringir las comunicaciones entre algunas áreas del programa;
e) Comprobar la integridad de los datos de las variables críticas.
3.7.4 Mantenibilidad
Se deben especificar atributos de software relacionados con su facilidad de mantenimiento. Puede haber alguna
necesidad de cierta modularidad, las interfaces, la complejidad, etc. Los requisitos no deben ser colocados aquí
sólo porque se piensa que son buenas prácticas de diseño.
3.7.5 Portabilidad
Esto debe especificar atributos de software que relaciona a la facilidad de portar el software a otras máquinas de
acogida y/o sistemas operativos. Esto puede incluir la siguiente:
a) Porcentaje de los componentes con el código de host-dependiente;
b) Porcentaje de código que depende de acogida;
c) El uso de un lenguaje portable probada;
d) El uso de un compilador en particular o subconjunto de idiomas;
e) El uso de un sistema operativo en particular.
3.8 Otros Requisitos
Cualquier otro requisito que no encaje en otra sección.

4 Documentación
4.1 Documentación Relacionada
 Formularios de Eventos
 Procedimiento instalación de equipo nuevo.
 Etc

4.2 Anexos
N/A
4.3 Definiciones y Siglas
4.3.1 Definiciones
N/A
4.3.2 Siglas

Página 6 de 6