Este documento describe el formato de Especificación 1.1.

Propósito
de Requisitos Software (ERS) según el estándar IEEE
Define el propósito del documento ERS y especifica a
830. Aunque no es obligatorio seguir estrictamente la
quién va dirigido.
organización y formato del estándar, se debe incluir
toda la información que este presenta. El estándar IEEE 1.2. Ámbito del Sistema
830 ha sido criticado por sus defectos y prejuicios, y
algunos cuestionan si realmente es un estándar en el  Se puede dar un nombre al futuro sistema (p.ej.
sentido tradicional de otras ingenierías. El propósito del MiSistema).
documento es educativo, mostrando cómo organizar un  Explica lo que el sistema hará y lo que no hará.
Documento de Requisitos según el estándar IEEE 830.
 Describe los beneficios, objetivos y metas
esperadas del sistema.
1. Introducción 3  Referencia documentos de nivel superior para
1.1. Propósito 3 mantener la consistencia con la especificación
de requisitos globales del sistema, si existe.
1.2. Ámbito del Sistema 3
1.3. Definiciones, Acrónimos y Abreviaturas
1.3. Definiciones, Acrónimos y Abreviaturas 3
Define todos los términos, acrónimos y abreviaturas
1.4. Referencias 3 utilizados en la ERS.
1.5. Visión General del Documento 4 1.4. Referencias
2. Descripción General 4 Proporciona una lista completa de todos los
documentos referenciados en la ERS.
2.1. Perspectiva del Producto 4
1.5. Visión General del Documento
2.2. Funciones del Producto 4
Esta subsección describe brevemente los contenidos y
2.3. Características de los Usuarios 5
la organización del resto de la ERS.
2.4. Restricciones 5
2. Descripción General
2.5. Suposiciones y Dependencias 5
Se describen los factores que afectan al producto y sus
2.6. Requisitos Futuros 6 requisitos, proporcionando el contexto necesario para
definir los requisitos en detalle en la sección 3. Incluye
3. Requisitos Específicos 6
las siguientes subsecciones:
3.1. Interfaces Externas 7
2.1. Perspectiva del Producto
3.2. Funciones 7
Relaciona el futuro sistema con otros productos,
3.3. Requisitos de Rendimiento 9 especificando si es independiente o parte de un sistema
mayor, e identificando las interfaces entre ellos. Se
3.4. Restricciones de Diseño 9 recomienda el uso de diagramas de bloques.
3.5. Atributos del Sistema 9 2.2. Funciones del Producto
3.6. Otros Requisitos 9 Proporciona un resumen general de las funciones del
4. Apéndices 9 futuro sistema, organizadas y, si es necesario,
representadas gráficamente para mostrar las relaciones
Introducción entre funciones, no el diseño del sistema.
Esta sección proporciona una introducción al Claro, aquí tienes un resumen con las ideas principales:
documento de Especificación de Requisitos Software
(ERS) y consta de varias subsecciones:
2.3. Características de los Usuarios  Identificación: Cada requisito debe ser
identificable de manera única mediante un
Describe las características generales de los usuarios del
código o sistema de numeración adecuado.
producto, incluyendo nivel educacional, experiencia y
experiencia técnica. Los requisitos deben ser:

2.4. Restricciones  Correctos: Reflejar necesidades reales.

Detalla las limitaciones impuestas sobre los  No ambiguos: Tener una sola interpretación,
desarrolladores del producto, tales como: utilizando gráficos o notaciones formales si es
necesario.
 Políticas de la empresa
 Completos: Incluir todos los requisitos
 Limitaciones del hardware
relevantes y posibles respuestas del sistema a
 Interfaces con otras aplicaciones los datos de entrada, tanto válidos como no
válidos.
 Operaciones paralelas
 Consistentes: Los requisitos no deben ser
 Funciones de auditoría y control contradictorios.
 Lenguajes de programación  Clasificados: Los requisitos se clasifican por
 Protocolos de comunicación importancia (esenciales, condicionales,
opcionales) o estabilidad.
 Requisitos de habilidad
 Verificables: Los requisitos deben ser
 Criticalidad de la aplicación verificables mediante un proceso claro y
 Consideraciones de seguridad económico.

2.5. Suposiciones y Dependencias  Modificables: La ERS debe permitir cambios

fáciles y consistentes en los requisitos.
Describe los factores que, si cambian, pueden afectar a
los requisitos, como la organización de la empresa o el  Trazables: Se debe conocer el origen de cada
sistema operativo utilizado. Si estos detalles cambian, requisito y su referencia en el diseño e
puede ser necesario revisar y modificar los requisitos. implementación del sistema.

2.6. Requisitos Futuros 3.1. Interfaces Externas

Esboza futuras mejoras al sistema que podrán Describe los requisitos que afectan a la interfaz de
analizarse e implementarse en el futuro. usuario, la interfaz con otros sistemas (hardware y
software) y las interfaces de comunicaciones.
3. Requisitos Específicos
3.2. Funciones
Contiene los requisitos detallados para que los
diseñadores puedan crear un sistema que los satisfaga y Esta subsección debe especificar todas las acciones que
el equipo de pruebas pueda planificar y realizar las el software debe realizar, generalmente expresadas
pruebas necesarias. Los requisitos deben describir como “el sistema deberá…”. Se pueden utilizar gráficos
comportamientos externos del sistema y cumplir con los y tablas para complementar el texto, pero el lenguaje
siguientes principios: natural debe ser la base.

 Legibilidad: El documento debe ser El estándar IEEE 830 ha evolucionado desde 1983,
comprensible para personas con diferentes cuando establecía que las funciones debían expresarse
formaciones e intereses. como una jerarquía funcional, en paralelo con los
Diagramas de Flujo de Datos (DFDs) del análisis
 Referencias: Deben incluirse documentos estructurado. Las versiones más recientes permiten
relevantes que influyan en los requisitos. organizar esta subsección de múltiples formas,
incluyendo:
  Por tipos de usuario: Diferentes usuarios tienen restricciones de otros estándares y limitaciones de
diferentes requisitos. Para cada tipo de usuario, hardware.
se especifican los requisitos funcionales
3.5. Atributos del Sistema
relevantes.
Se detallan los atributos de calidad del sistema, como
 Por objetos: Los objetos son entidades del
fiabilidad, mantenibilidad, portabilidad y seguridad. Se
mundo real reflejadas en el sistema. Para cada
especifican los tipos de usuarios autorizados y los
objeto, se detallan sus atributos y funciones.
mecanismos de seguridad, como el uso de login y
Los objetos pueden agruparse en clases, y esta
contraseña.
organización no implica necesariamente que el
diseño del sistema siga el paradigma de 3.6. Otros Requisitos
Orientación a Objetos.
Incluye cualquier otro requisito que no encaje en las
 Por objetivos: Un objetivo es un servicio que el secciones anteriores.
sistema debe ofrecer y que requiere una
determinada entrada para obtener su 4. Apéndices
resultado. Para cada objetivo o subobjetivo, se Contienen información relevante para la ERS pero que
detallan las funciones necesarias para no forma parte de ella, como:9
alcanzarlo.
 Formatos de entrada/salida de datos.
 Por estímulos: Se especifican los posibles
estímulos que recibe el sistema y las funciones  Resultados de análisis de costes.
relacionadas con dichos estímulos.  Restricciones sobre el lenguaje de
 Por jerarquía funcional: Si ninguna de las programación.
anteriores alternativas resulta adecuada, se
puede organizar como una jerarquía de Clases:
funciones que comparten entradas, salidas o 16/9/2024
datos internos. Esto no implica que el diseño del
sistema deba seguir el paradigma de Diseño Confiabilidad: Es la característica de algo que no varía
Estructurado. con el tiempo ni con las circunstancias, manteniéndose
constante.
Es importante justificar la elección de la organización
utilizada para asegurar claridad y coherencia en la Verificable: Es algo fidedigno en lo que se puede confiar
especificación de requisitos. y que puede ser comprobado en cualquier lugar.

3.3. Requisitos de Rendimiento Verificación: Es el conjunto de métodos y

procedimientos planificados que permiten comprobar si
Esta sección detalla los requisitos relacionados con la un software cumple con las especificaciones del cliente.
carga que se espera que el sistema deba soportar, como
el número de terminales, usuarios simultáneos y Validación: Es el proceso que proporciona evidencia
transacciones por segundo. También, si es necesario, objetiva de que se han cumplido los requisitos y
especifican los requisitos de datos, es decir, aquellos necesidades de los usuarios finales.
requisitos que afecten a la información que se guardara
20/9/2024
en la base de datos, como la frecuencia de uso,
capacidades de acceso y cantidad de registros Los pasos estandarizados se convierten en métodos.
esperados. Todo tiene un inicio y una serie de pasos para llegar al
objetivo. Una serie de pasos que se convierten en un
3.4. Restricciones de Diseño
método y luego en un estándar.
Aquí se describen las limitaciones que afectan las
IEEE 830 es un método que se volvió estándar porque
decisiones de diseño de la aplicación, incluyendo
ilustra los pasos para realizar un producto informático.
Es un producto no obligatorio que se recomienda para
el desarrollo de productos informáticos. Es de carácter 1.4 Bibliografía
pedagógico, está hecho para la ingeniería en sistemas y
Cuando es electrónica se coloca:
tiene varias versiones.
Apellido, inicial del nombre. (año de la investigación),
Especificaciones de Requisitos de Software (ERS): es un título de lo investigado, (si es trabajo de grado) trabajo
estándar de la IEEE 830, originario de 1998. La versión de grado sin mención o con mención honorífica,
que se maneja es del 22 de octubre de 2008. (disponible en: link día, mes y año que investigaste). Se
coloca la fecha que investigaste por primera vez.
¿Qué es IEEE 830?
Beneficios
Es un estándar de carácter pedagógico recomendado
para la elaboración de productos informáticos. No es  Beneficios directos
obligatorio, tiene errores, pero se va mejorando, y tiene
 Beneficios indirectos
una estructura definida.
Introducción
1.2 Ámbito del sistema
Debe enamorar al lector para que le guste lo que estás
¿Qué es un ámbito?
haciendo. El lector puede ser o no profesional. La
El área del conocimiento donde se desarrollará el
introducción debe ser comprensible para cualquiera y
software.
debe dramatizar al comienzo para luego ofrecer la
Cómo seleccionar el nombre de un proyecto: solución.

 Nombre de lo que van a hacer y a quién va

dirigido.
23/9/2024
 No debe pasar de 15 palabras.
Título: Desarrollo e implementación de un software de
 Describir qué vas a hacer y hasta dónde llegará contabilidad para conjunto residencial Los Medanos
ese desarrollo e implementación.
Título: Diseño de un software de automatización y
 Nunca usar abreviaturas. control en máquinas de producción de yogur dirigido a
empresas polar
 Es más fácil decir qué hará el proyecto que lo
que no hará.  El título deberá estar formado por el área de
saber, lo que harás y a quien va dirigido, y no
Titulo: Desarrollo de un sistema de gestión de
tener más de 15 palabras.
inventario para emprendedores
 El verbo que se utilice en el título más adelante
Límites:
se usará en infinitivo en otra parte
Es cuando haces la conclusión de un trabajo y dejas
recomendaciones. Los límites son las recomendaciones  El objetivo general debe guardar relación con el
a futuro: hasta dónde llegaste y qué recomiendas en tu título del trabajo, luego el propósito y 4 objetivo
conclusión. específicos

Se referencian todos los productos para evitar el plagio. La palabra implementación no se debería usar ya que se
tendría que dejar en funcionamiento el sistema, en su
1.3 Glosario
lugar es podrían usar las palabras desarrollo o diseño.
En el glosario se colocará el título de lo que es, la
La palabra Fabricación hace referencia a fabricar piezas
explicación y la abreviatura. La primera vez que se
físicas.
mencione la palabra se debe colocar la explicación
completa y entre paréntesis (abreviatura). Más El método de cascada es finito tiene un inicio y un fin,
adelante, si se vuelve a citar, solo se coloca la aparte de ser secuencial
abreviatura entre paréntesis.
2. Descripción General 2.4 Restricciones

Secciones Son las condiciones establecidas por la empresa, el clien

te o la persona para quien se diseña el producto.
Factores que pueden afectar el producto:
2.5 Suposiciones y Dependencias
 Hardware: El producto solo puede utilizarse con
hardware específico que tenga una RAM deter Lo que se va a desarrollar solo funciona en sitios específi
minada. Es compatible con hardware libre y se p cos.
uede utilizar en Windows o Linux.
 Migraciones homogéneas: Los mismos equipos
Nota: En la sección 3, se describirán todos aquellos aspe que salen son los mismos que entran.
ctos técnicos que afectan el desarrollo. Aquí solo se me
 Migraciones heterogéneas: Es importante cuida
ncionan.
r que no se pierda un dato, ya que es un proces
3. Requisitos Específicos o delicado.

Esta sección detalla documentos, documentación, refer Coerción y acoplamiento:

encias, requisitos unívocamente definidos, característica
 Fuertemente acoplado: Algo depende de otro d
s y principios.
e por vida, no puede funcionar de otra manera.
2.1 Perspectiva del Producto
 Fuertemente cohesionado: Puede funcionar ind
 UML: Se utiliza diagrama de bloques para explic ependientemente de otro componente.
ar.
2.6 Requisitos Futuros
 Producto de un sistema mayor: Algo desarrolla
Al concluir tu trabajo, la recomendación y conclusión se
do para ser utilizado en un determinado ambien
rán leídas por quien decida mejorar el trabajo realizado.
te.

 Desarrollo en función de la mayoría.

29/9/2024
Marco legal:
Corrección:
 Constitución de la República
 No se deben incluir funcionalidades que el
 Dirección Ciencia y Tecnología
sistema no realice ni requerimientos no
 IEEE 830 solicitados. Solo se deben especificar las
necesidades que se van a satisfacer.
2.2 Funciones del Producto
No ambiguos:
Cada usuario tiene características y funcionalidades par
ticulares. Las especificaciones según los usuarios son:  No utilizar definiciones con doble sentido ni
términos vagos.
 Usuarios internos: Programadores.
 Un término es ambiguo si su referencia cambia
 Usuarios externos: Los que van a usar el progra
con el tiempo, lo que lo hace no confiable. Si no
ma.
está claramente definido, no es confiable.
Se detallan los pasos a seguir que condicionan el uso del
 Algo es confiable cuando siempre tiene la
producto.
misma respuesta y no varía.
2.3 Características de Usuario
Completos:
El desarrollo de un producto debe tener especificacione
 No dejar nada al azar. Proporcionar la respuesta
s dependiendo del cargo del usuario. No se desarrolla ig
completa y la definición en el momento.
ual para todos.
  Definir inmediatamente lo que se va a definir, Trazables:
sin dejarlo para después.
 Es rastrear las modificaciones realizadas y tener
 Retrasos implican pérdida de tiempo, dinero y un control de versiones.
calidad.

Método de cascada:
30/9/2024
 Es finito y secuencial. Finito porque tiene un
3.2 Especificación de Acciones del Software
comienzo y un fin; secuencial porque sus partes
se retroalimentan. Las acciones que realiza el software pueden
especificarse de diversas formas, como tablas, gráficos o
Consistente:
muestras. Anteriormente, se organizaban
 No es contradictorio cuando no es ambiguo. Es jerárquicamente, pero ahora pueden representarse de
contradictorio cuando es ambiguo. La diferentes maneras:
consistencia se logra evitando la ambigüedad.
 Por tipos de usuarios:
Clasificados:
o Por objetos:
 Los requerimientos se clasifican normalmente
 Atributos: Características físicas
en esenciales, condicionales, funcionales o por
o descriptivas, como “pelo
estabilidad.
marrón” o “blanquito”.
 Los condicionales son obligatorios.
 Funciones: Capacidades o
Verificable: comportamientos, como
“inteligente”, “rápido” o
 Un requerimiento es verificable si es testeable.
“expresivo”.
Estudio de viabilidad:
o Por objetivos:
 Puede ser financiero, conceptual o de acceso
 Crear variables que satisfagan
(general o tecnológico).
necesidades específicas y
o Financiero: cuando no se sabe si se describir qué hace cada una. Si
tiene el dinero para realizar el trabajo. se declaran muchas cosas que
no funcionan, deben
o Accesibilidad: cuando se necesita desecharse.
acceder a algo en particular.
o Por estímulos:
o Conceptual: si se tiene o no el
conocimiento necesario.  Un estímulo que activa un
dispositivo y permite su
Modificables: detección.
 Deben incluir seguimiento económico, laboral y o Por jerarquía:
solución de problemas, y estar documentados
en el ERS.  Un proceso con entrada y salida
es un sistema lineal. No evalúa
 Se puede modificar la estructura del ERS si está bien o mal, pero al
siempre que sea consistente y no altere la retroalimentar la salida con la
estructura del software. entrada, si hay una diferencia,
se puede calcular un porcentaje
de error.
3.3 Requisitos de Rendimiento

 Conectividad: Capacidad del software para

conectarse con otros sistemas.

 Congruencia: Coherencia en el funcionamiento

y resultados del software.

 Auditoría: Posibilidad de realizar auditorías para

verificar el correcto funcionamiento.

 Limitaciones: Restricciones del software en

términos de capacidad y rendimiento.

 Soporte: Capacidad del software para manejar

la carga y las demandas del usuario.