ANÁLISIS DE REQUERIMIENTOS

ESPECIFICACIÓN DE REQUISITOS SEGÚN EL

ESTÁNDAR DE IEEE 830

1. Introducción
Que es IEEE 830?
1.1. Propósito

En esta subsección se definirá el propósito del

documento ERS y se especificara a quien va
dirigido el documento.
1.2. Ámbito del Sistema
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
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.
1.4. Referencias

En esta subsección se mostrará una lista

completa de todos los documentos
referenciados en la ERS.
1.5. Visi´on General del Documento

Esta subsección describe brevemente los

contenidos y la organización del resto de
la ERS.
2. Descripción General

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.
2.2. Funciones del Producto
2.3. Características de los Usuarios

Esta subsección describirá las

características generales de los usuarios
del producto, incluyendo nivel
educacional, experiencia y experiencia
técnica.
2.4. Restricciones

Esta subsección describirá aquellas

limitaciones que se imponen sobre los
desarrolladores del producto
2.5. Suposiciones y Dependencias

Esta subsección de la ERS describirá

aquellos factores que, si cambian, pueden
afectar a los requisitos.
2.6. Requisitos Futuros

Esta subsección esbozará futuras mejoras

al sistema, que podrán analizarse e
implementarse en un futuro.
3. Requisitos Específicos
El documento debería ser perfectamente
legible por personas de muy distintas
formaciones e intereses.

Lo ideal, aunque en la práctica no

siempre realizable, es que los requisitos
posean las siguientes características:
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.
3.2. Funciones

Esta subsección (quizá la más larga del

documento) deberá especificar todas
aquellas acciones (funciones) que deberá
llevar a cabo el software.
3.3. Requisitos de Rendimiento

Se detallarán los requisitos relacionados

con la carga que se espera tenga que
soportar el sistema.
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 (las

“ilities”) del sistema: Fiabilidad,
mantenibilidad, portabilidad, y, muy
importante, la seguridad.
3.6. Otros Requisitos

Cualquier otro requisito que no encaje en

otra sección
4. Apéndices
Pueden contener todo tipo de información
relevante para la ERS pero que,
propiamente, no forme parte de la ERS.
Por ejemplo:
ANÁLISIS DE REQUERIMIENTOS

IEEE -> Es una organización sin ánimo de lucro, la

mayor asociación del mundo para el desarrollo
tecnológico.
PUNTOS DE VISTA IEE.

1. Primero define un requerimiento como una

condición o capacidad que un usuario necesita para
resolver un problema o lograr un objetivo.
PUNTOS DE VISTA IEE.

1. Segundo una condición o capacidad que debe tener

un sistema o un componente de un sistema para
satisfacer un contrato, una norma, una
especificación u otro documento formal
PUNTOS DE VISTA IEE.

1. Tercero una representación en forma de

documento de una condición o capacidad como las
expresadas en la primera o la segunda.
CLASES DE REQUERIMIENTOS

1. Los requerimientos funcionales (RF). Son aquellos

servicios que el usuario espera del sistema. En
principio, los requisitos funcionales de un sistema
deben ser completos y consistentes.
CLASES DE RF POR AREAS.

1.- De proceso o área de negocio. (Ejemplo). El

sistema enviará un correo electrónico cuando se registre
alguna de las siguientes transacciones: pedido de venta
de cliente, despacho de mercancía al cliente, emisión de
factura a cliente y registro de pago de cliente.

1.
CLASES DE RF POR AREAS.

2.- De interfaz gráfica. (Ejemplo). El campo de

monto acepta únicamente valores numéricos con dos
decimales.

1.
CLASES DE RF POR AREAS.

3.- Requerimientos de seguridad.(Ejemplo).

Los libros de venta y de compras serán emitidos en el
formato establecido por las autoridades tributarias de
dicha materia.
CLASES DE RF POR AREAS.

4.- De requerimientos de interfaces externas

(Hardware y software). Ejemplo. El software
podrá ser utilizado en los sistemas operativos
Windows, Linux y OSX.
ACERCA DE LOS REQUERIMIENTOS F.

Los requerimientos funcionales deben redactarse de tal

forma que el lector pueda entender el funcionamiento
del sistema sin tener conocimientos técnicos
particulares de su funcionamiento.
ACERCA DE LOS REQUERIMIENTOS F.

Asimismo, los requerimientos funcionales no

necesariamente tienen que definirse en forma de
narrativas escritas, sino que también pueden utilizarse
diagramas o flujos de procesos, casos de uso, los cuales
se incluyen en la especificación funcional del software
o sistema a desarrollar.
ACERCA DE LOS REQUERIMIENTOS F.

Asimismo, Para identificar y documentar los

requerimientos funcionales de software, se siguen dos
pasos, en primer lugar se aplican técnicas de
levantamiento de requisitos, tales como la observación,
entrevistas, observación, entre otras.
ACERCA DE LOS REQUERIMIENTOS F.

Asimismo, Luego del levantamiento, se

aplican técnicas de análisis de requerimientos para
revisar la información obtenida en el levantamiento y
elaborar la especificación funcional, algunas de estas
técnicas son la descomposición funcional, modelado de
procesos, los casos de uso y otras más.
 
IDENTIFICACION DE REQUERIMETNOS
FUNCIONALES.

Los requerimientos funcionales son declaraciones de

los servicios que proveerá el sistema, de la manera en
que éste reaccionará a entradas particulares. En
algunos casos, los requerimientos funcionales de los
sistemas también declaran explícitamente lo que el
sistema no debe hacer.

 
IDENTIFICACION DE REQUERIMETNOS
FUNCIONALES.

Muchos de los problemas de la ingeniería de software

provienen de la imprecisión en la especificación de
requerimientos. Para un desarrollador de sistemas es
natural dar interpretaciones de un requerimiento
ambiguo con el fin de simplificar su implementación.
 
IDENTIFICACION DE REQUERIMETNOS
FUNCIONALES.

Sin embargo, a menudo no es lo que el cliente desea. Se

tienen que estipular nuevos requerimientos y se deben
hacer cambios al sistema, retrasando la entrega de éste
e incrementando el costo.
 
IDENTIFICACION DE REQUERIMETNOS
FUNCIONALES.

En principio, la especificación de requerimientos

funcionales de un sistema debe estar completa y ser
consistente. La compleción significa que todos los
servicios solicitados por el usuario están definidos. La
consistencia significa que los requerimientos no tienen
definiciones contradictorias.
IDENTIFICACION DE REQUERIMETNOS NO
FUNCIONALES.

REQUERIMIENTOS NO FUNCIONALES
CLASES DE REQUERIMIENTOS

1. Los RNF, son los requisitos no funcionales de un

sistema, son restricciones u obligaciones impuestas
al servicio de éste.
CLASES DE REQUERIMIENTOS

1. Los requerimientos funcionales (RF).

2. Los requerimientos no funcionales (RNF).