1.1 Revision de Especificacion de Requisitos

UNIDAD 1: ANÁLISIS
1.1 REVISIÓN DE ESPECIFICACIÓN DE REQUISITOS.

CONTENIDO
 ITNRODUCCION
 ESPECIFICACIÓN DE REQUISITOS SOFTWARE
 CARACTERÍSTICAS DE UNA BUENA ESPECIFICACIÓN
DE REQUISITOS DE SOFTWARE
 1.1.1 NORMA IEEE830
 1.1.2 TRAZABILIDAD DE REQUISITOS
 CONCLUSION
 BIBLIOGRAFÍA
INTRODUCCION
 El análisis y la Especificación de Requisitos de Software (ERS) es una

de las fases más importante del proceso de desarrollo de software y
es en esta fase donde
se obtiene la descripción completa del comportamiento del futuro sof
tware o producto que se va a desarrollar.
ESPECIFICACIÓN DE
REQUISITOS SOFTWARE
 Se define como un documento en él que debe escribirse qué tiene
que hacer el programa que se va a desarrollar.
 Incluye un conjunto de casos de uso que describen todas las
interacciones que se prevén que los usuarios tendrán con el
software.
CARACTERÍSTICAS DE UNA BUENA
ESPECIFICACIÓN DE REQUISITOS
DE SOFTWARE
 Correcta: La ERS es correcta si y sólo si todo requisito que figura en
ella refleja alguna necesidad real.
 No ambigua: Un documento es no ambiguo si y solo si cada requisito
descrito tiene una única interpretación.
 Completa:
• Incluye todos los requisitos significativos del software.
• Cumple con el estándar utilizado.
• Aparecen etiquetadas todas las figuras, tablas, diagramas, etc., así como
definidos todos los términos y unidades de medida empleados
 Verificable: Se dice que es verificable si existe algún proceso no
excesivamente costoso por el cual una persona o una máquina pueda
chequear que el software satisface dicho requerimiento.
 Consistente: Una ERS es consistente si y sólo si ningún conjunto de
requisitos descritos en ella son contradictorios o entran en conflicto.
 Clasificada: Los requisitos pueden clasificarse por diversos criterios:
• Importancia: Pueden ser esenciales, condicionales u opcionales.
• Estabilidad: Cambios que pueden afectar al requisito
 Modificable: Una ERS es modificable si cualquier cambio puede
realizarse de manera fácil, completa y consistente.
 Explorable: Una ERS es explorable si el origen de cada
requerimiento es claro tanto hacia atrás (origen que puede ser
un documento, una persona etc.)
 Utilizable durante las tareas de mantenimiento y uso: En

la ERS también se deben tener en cuenta las necesidades de
mantenimiento. El personal que no ha intervenido directamente
en el desarrollo debe ser capaz de encargarse de su
mantenimiento.
1.1.1 NORMA IEEE830
 El análisis de requisitos se puede definir como el proceso del
estudio de las necesidades de los usuarios para llegar a una
definición de los requisitos del sistema, hardware o software
1. INTRODUCCIÓN
 1.1 Propósito
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 pondrá nombre al futuro sistema, 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
Se definirán aquí todos los términos, acrónimos y abreviaturas utilizadas
en el desarrollo de la ERS.
 1.4 Referencias
Se presentará una lista completa de todos los documentos
referenciados en la ERS.
 1.5 Visión General del Producto
Esta subsección describirá brevemente los contenidos y la
organización del resto de la ERS.
2. DESCRIPCIÓN GENERAL
 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í
 2.2 Funciones del Producto
Se debe proporcionar un resumen de las funciones principales que el
software debe llevar a cabo. Las funciones deben estar organizadas de
manera que el cliente o cualquier otra persona lo entienda
perfectamente.
 2.3 Características de los usuarios
Se indica aquí el tipo de usuario al que se dirige la aplicación, así como su
experiencia técnica, nivel de conocimientos, etc.
 2.4 Restricciones
Se debe indicar aquí cualquier tipo de limitación como pueden ser políticas de la
empresa, limitaciones hardware, seguridad, protocolos de comunicación,
interfaces con otras aplicaciones, estándares de la empresa en cuanto a
interfaces, etc.
 2.5 Suposiciones y Dependencias
En este apartado aparecerá cualquier factor, que si cambia puede afectar a los
requerimientos.
 2.6 Requisitos Futuros
Se indican aquí posibles mejoras del sistema en el futuro.
3. REQUISITOS ESPECÍFICOS
 3.1 Interfaces Externas

Se definirán los requisitos que afecten a la interfaz de usuario e
interfaz con otros sistemas (hardware y software), así como a
interfaces de comunicaciones.
 3.2 Funciones
Se deben especificar todas aquellas acciones o funciones que
deberá llevar a cabo el sistema a desarrollar. Las acciones que se
indican como “el sistema deberá ...” son las que deben incluirse en
este apartado.
 3.3 Requisitos de Rendimiento
Incluyen los requisitos relacionados con la carga que se espera que tenga que
soportar el sistema (número de usuarios simultáneos, número de terminales ...).
 3.4 Restricciones de Diseño
Se incluyen todas las restricciones que afecten al diseño de la aplicación, como
pueden ser estándares internos de la organización, limitaciones hardware, etc.
 3.5 Atributos del Sistema
Se detallan atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos
de acceso restringido, usuarios autorizados.
 3.6 Otros requisitos
Aquellos requerimientos que no se hayan podido incluir en ninguna de las
secciones anteriormente especificadas.
4. APÉNDICES
 Se incluirá aquí cualquier tipo de información relacionada con la

ERS, pero que no forme parte de la misma. Por ejemplo, se
incluirían los resultados del análisis de costes, restricciones
especiales acerca del lenguaje de programación, etc.
5. ÍNDICE
 Se proporciona un índice para poder tener un acceso rápido a la

documentación presentada en la ERS.
1.1.2 Trazabilidad de requisitos
 Según el estándar IEEE 830-1998, la trazabilidad es la habilidad

para seguir la vida de un requerimiento en ambos sentidos, hacia
sus orígenes o hacia su implementación a través de las
especificaciones generadas durante el proceso de desarrollo. Es
un factor de calidad.
BIBLIOGRAFÍA
 http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:pis:eje
mplo_de_especificacion_de_requerimientos_-_para_sesion_9.pdf
 http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI_3242/ERS_IEEE830.pdf
 http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/
407

1.1 Revision de Especificacion de Requisitos

Cargado por

Copyright:

Formatos disponibles

1.1 Revision de Especificacion de Requisitos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1.1 Revision de Especificacion de Requisitos

Cargado por

Copyright:

Formatos disponibles

UNIDAD 1: ANÁLISIS

1.1 REVISIÓN DE ESPECIFICACIÓN DE REQUISITOS.

 El análisis y la Especificación de Requisitos de Software (ERS) es una

 Utilizable durante las tareas de mantenimiento y uso: En

 2.1 Perspectiva del Producto

 3.1 Interfaces Externas

 Se incluirá aquí cualquier tipo de información relacionada con la

 Se proporciona un índice para poder tener un acceso rápido a la

 Según el estándar IEEE 830-1998, la trazabilidad es la habilidad

También podría gustarte