1.1.

1 NORMA IEEE 830

NORMA IEEE 830
El estándar 830-1998 fue generado por un
equipo de trabajo del IEEE(Institute of Electrical
and Electronics Engineers), su finalidad es la
integración de los requerimientos del sistema
desde la perspectiva del usuario, cliente y
desarrollador.
La 830 se encarga de poner las pautas para
identificar y esquematizar las requerimientos de
software. Como parte integral del desarrollo de
software, sino también como base fundamental
de este, todo esto con el fin de no caer en
cambios, errores o situaciones que pongan en
peligro la creación de una solución, producto o
software; incurriendo en gastos o cambios
producto de una mal análisis de requerimientos
 Objetivo
La especificación de los requerimiento o requisitos de software el
cuál tiene como producto final la documentación de los acuerdos
entre el cliente y el grupo de desarrollo para así cumplir con la
totalidad de exigencias estipuladas.

Proceso
NORMA IEEE 1. Definir con los interesados en el proyecto los límites y
requerimientos del mismo, y toda la información necesaria.
830 2. Realizar el documento con toda la información recolectada.
3. Si se generan dudas, es necesario realizar otra reunión con los
interesados del proyecto.
Documentos
▪Cuestionario de entrevista (preguntas y respuestas).
▪Requerimientos
ESPECIFICACIÓN DE
REQUISITOS SEGÚN EL
ESTÁNDAR
DE IEEE 830
 Aquí debemos escribir la
introducción al documento de
especificación de requisitos
del software.
Las subsecciones de las que
esta conformada son:
▪Propósito
▪Ámbito del Sistema.
▪Definiciones.
▪Referencias.
▪Visión General del
1. INTRODUCCION documento.
1.1 PROPOSITO
En esta subsección se definirá el
propósito del documento ERS y
se especificará a quién va
dirigido el documento.
1.2 Á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.
•Se referenciarán todos aquellos documentos de
nivel superior (p.e. en Ingeniería de Sistemas, que
incluyen Hardware y Software, debería
mantenerse la consistencia con el documento de
especificación de requisitos globales del sistema,
si existe).
 1.3 DEFINICIONES,
ACRÓNIMOS Y
ABREVIATURAS
En esta subsección se definirán todos
los términos, acrónimos y abreviaturas
utilizadas en la ERS.
 En esta subsección se
mostrará una lista completa
de todos los documentos
referenciados en la ERS.

1.4 REFERENCIAS
1.5 VISION GENERAL
DEL DOCUMENTO
Esta subsección describe brevemente
los contenidos y la organización del
resto de la ERS.
 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.
Esta sección consta de las siguientes
subsecciones:
•Perspectiva del producto
•Funciones del producto
•Características de los usuarios
•Restricciones
2. DESCRIPCIÓN GENERAL •Factores que se asumen
•Futuros requisitos.
 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
2.1 PERSPECTIVA DEL PRODUCTO utilizar diagramas de bloques.
2.2 FUNCIONES DEL
PRODUCTO
En esta subsección se mostrara un resumen, a
grandes rasgos de las funciones del sistema.
Ejemplo:
Si el sistema es un sistema de contabilidad aquí se
hace el resumen de cuales son las funcionalidades
que el sistema soportara, por ejemplo el
mantenimiento de cuentas, consultar el estado de
cuentas del usuario, facilitar la facturación.
Cada una de las funciones que aquí describiremos se
deben de mostrar de forma organizada, de esta
manera será mas claro el entendimiento sobre estas
para el usuario, se pueden usar gráficos siempre y
cuando ayuden a que se tenga una idea mas clara
de su uso y de las relaciones entre las funciones.
2.3 CARACTERISTICAS
DE LOS USUARIOS
En esta subsección debemos
agregar cuales serán las
características de los usuarios
que usaran el sistema,
incluyendo el nivel educacional,
experiencia laboral y
experiencia técnica.
2.4 RESTRICCIONES
Aquí colocaremos las limitaciones
que se imponen sobre los
desarrolladores del producto. Por
ejemplo:
•Políticas de la empresa
•Hardware
•Interfaces con otras aplicaciones
•Operaciones paralelas
•Funciones de auditoria
•Funciones de control
•Lenguajes de programación
 Esta subsección de la ERS describirá 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
2.5 cambian ciertos detalles técnicos, como el sistema operativo,
puede ser necesario revisar y cambiar los requisitos.
SUPOSICIONES Y
DEPENDENCIAS
2.6 REQUISITOS
FUTUROS
Aquí debemos tener en
cuenta las implementaciones
de futuras mejoras al sistema,
o futuras implementaciones
de módulos o cualquier plan
a futuro que se tenga para el
sistema a desarrollar y que
se planeen implementar.
 3. REQUISITOS ESPECÍFICOS
En esta sección se describirán los requisitos a detalle para -Corrección: La ERS es correcta si y sólo si todo requisito
que los diseñadores hagan un diseño que logre resolver las que figura aquí refleja alguna necesidad real.
necesidades del sistema y que se permita planificar de
manera correcta el plan de trabajo, además en necesario -No ambiguos: Cada requisito tiene una sola interpretación
que a partir de esto se puedan realizar pruebas que
demuestren si el sistema esta cumpliendo con los requisitos y -Completos: Todos los requisitos relevantes han sido
resolviendo el problema que se había presentado para la incluidos en la ERS.
empresa, es una de las secciones mas largas del ERS.
-Consistentes: Los requisitos no pueden ser
Puntos importantes a considerar: contradictorios.

• El documento debe ser entendible para todos los usuarios -Clasificados: Normalmente, no todos los requisitos son
sin importar su formación o áreas de interés. igual de importantes.

• Debe hacerse referencia a los documentos relevantes que -Verificables: La ERS es verificable si y sólo si todos sus
requisitos son verificables.
influyen sobre el desarrollo del sistema.
-Modificables: La ERS es modificable si y sólo si se
• Todos los requisitos deben ser identificables mediante un encuentra estructurada de forma que los cambios a los
código o sistema de numeración. requisitos pueden realizarse de forma fácil, completa y
consistente.
• Lo ideal, aunque en la práctica no siempre realizable, es -Trazables: La ERS es trazable si se conoce el origen de
que los requisitos posean las siguientes características: cada requisito y se facilita la referencia de cada requisito a los
componentes del diseño y de la implementación
3.1 INTERFACES
EXTERNAS
Aquí debemos describir los requisitos
que afectan la interfaz de usuario,
interfaz con otros sistemas e
interfaces de comunicación.
Algunos requisitos se pueden ver
afectados por los navegadores, el
tamaño de la pantalla, el servidor,
los protocolos de comunicación y
seguridad.
 Esta es una de las subsecciones mas largas, aquí debemos especificar todas las acciones que
debe realizar el software, Podemos hacer uso de tablas, imágenes, y cualquier ayuda
grafica. La ultima versión de IEEE 830 permite organizar estas acciones de diferentes
formas, entre otras se sugieren las siguientes:
• Por tipos de usuarios: Se debe especificar los requisitos funcionales que afecten a cada
usuario, o con los que las tareas a realizar este mayormente relacionados.
• Por objetos: Para cada objeto se detallara los atributos y funciones que tiene.
• Por objetivos: Un objetivo es un servicio que debe ofrecer el Sistema y que requiere de una
determinada entrada para que se pueda dar el resultado deseado. Ej. El correo electrónico.

3.2 FUNCIONES • Por estimulos: Se especifican los estimulos que recibe el Sistema y ccuales son las funciones
que se deben realizer de acuerdo a este estimulo, en algunos casos se mencionan como
disparadores de eventos.
• Por jerarquia funcional.: Si no funciona alguna de las alternativas anteriores, se puede
definer por jerarqui funcional, es decir cuales requerimientos son mas importantes para que
el Sistema funcione de manera adecuada, También Podemos definirlo si comparten entradas,
salidas, datos internos, etc. Aquí se deben detallar las funciones(entrada, salida, proceso) y
subfunciones del Sistema.
 Se detallarán 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

3.3 REQUISITOS 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
DE almacenar (decenas, cientos, miles o millones).

RENDIMIENTO
3.4 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.5 ATRIBUTOS
DEL SISTEMA
Se detallarán los atributos de
calidad 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).
4. APÉNDICES

Contienen todo tipo de información

que es relevante para la ERS aunque
estos pueden no estar relacionados
directamente con la misma. Ejemplo:
•Formatos de entrada y salida.
•Resultados del análisis de costos.
•Restricciones sobre el lenguaje de
programación.
BIBLIOGRAFÍA
https://wikis.fdi.ucm.es/ELP/Especificaci%C3%B3n_de_Requisitos_Softw
are_seg%C3%BAn_el_est%C3%A1ndar_IEEE_830
http://www.icesi.edu.co/departamentos/tecnologias_informacion_com
unicaciones/proyectos/lisa/home/analisis/srs/srs
https://sites.google.com/site/adsicae/definicion-de-
requerimientos/ieee830
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
http://ingsoftudb.blogspot.com/
EXPOSICIÓN
QUE ES EL LENGUAJE UNIFICADO UML
TIPOS DE DIAGRAMAS UML
 1.CASOS DE USO
 2. SECUENCIAS
 3. CLASES
 4. COMPONENTES
 5. ACTIVIDADES
 6. PAQUETES
 7. DESPLIEGUE

 NOTACION SIMBOLICA
 EXPLICACION DEL DESARROLLO
 SOFTWARE
 EJEMPLO

 ¿Cómo lo aplicarías al proceso de tu proyecto?

Buscar ejemplos