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
([Link]. 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).
