ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I

DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS

1 Actores 3.4 Reglas y Funciones de Negocio 3.2 Contexto del Producto 2.2 Restricciones y Supuestos 2.2 Alcance 1.1 Objetivo 1.3 Requerimientos No Funcionales 3.2.3.Presentación del Producto 1.2 Listado de Casos de Uso 3.1.1.1 Propósito del Sistema 1.2 Requerimientos Funcionales 3.2.Requerimientos de Licencia 7.Descripción Detallada de Requerimientos 3.Historia de Cambios .Descripción General 2.2 Del Ambiente 4.3.3 El Sistema no contempla 1.2.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I CONTENIDO 1.4 Prototipo de Interfaz de Usuario 3.Restricciones de Diseño 6.3 Perspectivas futuras del producto 2.1.Observaciones 8.1 Listado de la Funcionalidad del Sistema 2.2.1 Diagramas de Casos de Uso 3.3 Detalles de Casos de Uso 3.Requerimientos de Interfaz 5.1 Del Producto 3.

1. No se debe incluir puntos referentes al proyecto.1.3.>.1. Fundamentalmente se debe destacar cuestiones políticas o legales del entorno de la organización que pueden afectar el éxito del proyecto si no se les brinda un adecuado tratamiento>.1.2. Listado de la Funcionalidad del Sistema <Esta sección proporciona un sumario de las principales funciones que debe realizar el producto. sin entrar en demasiado detalle.: descripción del sistema)  Las funciones deben organizarse de forma que resulten entendibles para el cliente o cualquier persona que deba leer el documento  Pueden emplearse medios gráficos para mostrar las funciones y sus relaciones. 1. 1. Objetivo: <Este campo deberá indicar de manera general lo que se pretende lograr con el desarrollo del sistema. Alcance: <Se deben indicar en términos generales las funciones que el sistema deberá realizar o los módulos que contendrá. que puede afectar al cumplimiento de los requerimientos y que viene dado desde el ambiente del negocio o acordado con anterioridad.1. sino especificar el objetivo del producto a desarrollarse.1. El objetivo de esta sección es dejar expresadas cuestiones que el producto no cubrirá. 1. . El Sistema no contempla: <Este campo sirve para indicar algunos aspectos funcionales o no funcionales y/o módulos que no estarán incluidos en el producto. Propósito del Sistema 1. Restricciones y Supuestos: <El objetivo de este apartado es indicar cualquier aspecto que debe ser considerado para el desarrollo. Presentación del Producto 1.2. No se debe incluir puntos referentes al proyecto. 2.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I 1. al menos hasta el momento>. sino especificar el alcance del producto a desarrollarse >. En ocasiones la información de esta sección puede tomarse de un documento de especificación del sistema (ej. Descripción General 2.

entidades. 2. recuperación . Actores <Se describen los roles. dispositivos y cualquier otro “Actor” con el que el sistema en desarrollo debería interactuar. Si esta especificación de requerimientos define un producto que es un componente de un sistema más grande. procesarla y producir resultados. Descripción Detallada de Requerimientos 3..”.2. Requerimientos Funcionales <Se describen los requerimientos funcionales del sistema utilizando Casos de Uso o bien Listados de Funcionalidades. Normalmente se listan en afirmaciones del tipo “el sistema debe. En ellas se incluye: o Comprobación de la validez de las entradas. Esta información puede proveerse directamente o por referencia a otro documento>. <Los requerimientos funcionales definen las acciones fundamentales que realiza el software al recibir información.1.3. Si el producto es independiente y totalmente autocontenido. Detalle del Menú de funcionalidades>. Reglas y Funciones de Negocio <Se indica la lógica de funcionamiento del negocio. comunicaciones.4. Perspectivas futuras del producto <Esta sección identifica requerimientos que pueden demorarse hasta versiones futuras del sistema>. 2. otros sistemas. entonces deberían relacionarse los requerimientos de ese sistema mayor con la funcionalidad de este software y deberían identificarse las interfaces de comunicación entre el sistema y el software>. Contexto del Producto <Esta sección debería poner al producto en perspectiva con otros productos relacionados. o Respuesta a situaciones anormales (desbordamientos. Se puede hacer referencia al punto “Definición de Actores” del documento “Diagramas de Casos de Uso” >.. 3. 2.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I  Pueden definirse casos de uso en trazo grueso>.2. debería ser especificado aquí. o Secuencia exacta de las operaciones. Listados de Pantallas. 3.

o Parámetros.> Texto sugerido: Ver archivo <Diagrama de Casos de Uso> < Nombre del Proyecto> Listado de Casos de Uso <Se deberá hacer referencia al estándar STD-LUC (Listado de Casos de Uso). en éste último caso se sugiere el estándar Diagramas de UC. El listado de Casos de Uso contiene el número y nombre de cada caso de uso. Esta información puede proveerse directamente o por referencia a otro documento. incluyendo:  Secuencias de entradas y salidas. prioridad del cliente. prioridad final.> Texto sugerido: Ver archivo <Listado de Casos de Uso> <Nombre del Proyecto> Detalle de Casos de Uso <Detalle de todos los casos de uso a través de la plantilla que se encuentra en el estándar de “Descripción de UC”> Texto sugerido: Ver archivo <Descripción de Casos de Uso> <Nombre del Proyecto> Prototipo de Interfaz de Usuario <En esta sección se incluirán las descripciones de interfaz general de la aplicación.  Fórmulas para la conversión de información. complejidad. o Relaciones entre entradas y salidas.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I de errores). <Si se utilizan Casos de Uso deben incluirse: Diagrama/s de Caso de Uso <se debe incluir aquí el diagrama o diagramas de casos de uso que muestran de manera gráfica los alcances funcionales del producto. Esta información puede proveerse directamente o por referencia a otro . con sus atributos obligatorios. nivel de riesgo de arquitectura.

con lo cual deben ser accedidas mediante Internet Explorer X. Las pantallas serán desarrolladas para ambiente Windows 98 ó posterior.3. RN-4. Requerimientos No Funcionales <La mayoría de los requerimientos no funcionales son registrados comúnmente en lenguaje natural en esta sección de especificación. Todas las pantallas deben tener un modo de cancelar la operación en curso. RN 2: Especificar tiempos de tareas mensurables para tareas típicas. tales como estándares de GUI>. Estos incluyen: RN 1: Especificar el tiempo de capacitación requerido para usuarios normales y expertos para convertirse en productivos en operaciones particulares. Del Producto Usabilidad: <se debería incluir todos aquellos requerimientos que afectan la usabilidad.3.X o superior. Para el caso de los requerimientos no funcionales aplicables a un caso de uso en particular se debe aclarar a qué caso de uso se refiere (utilizar la Matriz de Rastreabilidad). requerimientos de usabilidad básica del nuevo sistema sobre otros sistemas que los usuarios conocen y les agradan. 3.1. Las pantallas de <Nombre_ de_Producto> son en ambiente Web. Texto sugerido: RN-1. . Los requerimientos identificados en esta parte del documento son aplicables al producto en general. con resolución de pantalla de 800 x 600 RN-3.> 3. Las interfaces específicas de los casos de uso se pueden detallar en cada descripción de caso de uso. Redactar teniendo en cuenta que el RNF pueda ser probado >. RN-2. El sistema está preparado para ser operado a través de mouse y teclado.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I documento. alternativamente. RN 3: Especificar requerimientos para conformidad con los estándares comunes de usabilidad.

Performance: <incluye tiempos de respuesta específicos: . Los campos obligatorios deberán estar marcados con * (asterisco). (de 24hs al menos 23. RN 6: Tiempo mínimo de reparación: ¿Cuánto tiempo esta permitido que el sistema este fuera de operación después de una falla?. último. etc.) RN-9.28 hs. RN 9: Errores o índices de defectos: usualmente expresados en términos de errores invalidantes. acceso de mantenimiento. siguiente y anterior). Disponibilidad: 97%. Todas las búsquedas o consultas deben estar paginadas (botones primero.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I RN-5. horas de uso. RN 8: Errores Máximos o ratios de defectos: usualmente expresados en términos de ERRORES/KLOC (miles de líneas de código) o errores por puntos de función. pero también puede especificarse en días. RN 5: Tiempo mínimo entre fallas: Especificado usualmente en horas. El sistema deberá estar disponible en un 97% de su tiempo online. meses y años. etc. Verificar/validar límites de campos y tipos de datos de las pantallas en relación al modelo de datos Confiabilidad: <la confiabilidad podría expresarse en término de alguno de estos aspectos: RN 4: Disponibilidad: Especificar el porcentaje de disponibilidad de tiempo. RN-7. RN 7: Certeza: Precisión Especifica (resolución) y certeza (sobre un estándar) que es requerida para las salidas del sistema. RN-6. leves. Texto sugerido: RN-8. graves. comunes o mejoras>.

RN 13: Modos de Degradación (modo aceptable de operación cuando el sistema ha sido degradado).. El sistema deberá liberar a todos los recursos de memoria al momento de cerrar una ventana y finalizar una funcionalidad. máximo)... Se deberá usar codificación… (referenciar el estándar) Documentación: <describe los requerimientos. para documentación el Estándar de documento que . RN 11: Transacciones por segundo. RN 14: Utilización de Recursos (memoria.>. convenciones de nombres. RN-11.. Se espera que el tiempo de respuesta en el momento de presionar un botón para continuar con el flujo de la información que no supere los 5 segundos.> Texto sugerido: RN-10. Se espera mantener la escalabilidad del sistema en relación a la concurrencia de usuarios. de principio al fin. El sistema deberá capturar las excepciones producidas debido a la finalización de la session en el aplication Server debido al timeout de la misma y mostrar un mensaje comunicando lo ocurrido. Soportabilidad: <se indica cualquier requerimiento que mejorará la soportabilidad o mantenibilidad del sistema que se está construyendo. librerías de clases. RN 12: Capacidad (el numero de clientes o transacciones que el sistema puede acomodar). comunicaciones).ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I RN 10: Tiempo de respuesta para una transacción (promedio. Texto sugerido: RN-14. disco. si hay. incluyendo códigos estándar. acceso de mantenimiento y utilidades de mantenimiento RN 15:. RN-13. (cantidad de usuarios entre 5 y 8 concurrentes) RN-12.

. 4. protocolos. pantallas. internacionales. Del Ambiente Ético: <si existen requerimientos que deben considerarse en el contexto del producto que si bien no están legislados. incluyendo estructura lógica..3... impresos. RN-16. 4.>.2. direcciones lógicas.. etc RN . puertos. provinciales.1. tal que el software pueda ser desarrollado y verificado contra los estándares de requerimientos>. manuales Correcta redacción y ortografía en las La documentación requerida se detalla a continuación… 3. Legales: <identificar si existen legislaciones nacionales. deberán especificarse o referenciarse aquí RN . responde a factores morales o pautas de conducta. componentes reusados de otra aplicación. direcciones físicas y comportamiento esperado>. Estos pueden ser componentes comprados.... Debería contener adecuada especificidad.>.2.. Interfaces de Software <Describe las interfaces del software con otros componentes del sistema de software. etc aplicables y vigentes. Texto sugerido: RN-15.. o componentes que . El sistema debe garantizar la confidencialidad de la información. Interfaces de Hardware <Define cualquier interfaz de hardware que deberá ser soportada por el software. que el software deba considerar RN . El sistema debe mostrar los datos confidenciales de un cliente sólo a ese cliente.>. 4.. ayudas del sistema.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I en línea del usuario. etc. Requerimientos de Interfaz <Deben definirse las interfaces que soportará la aplicación.

3.  requerimientos del proceso de software. Interfaces de Comunicación <Describe las interfaces de comunicación u otros requerimientos de restricción o dispositivos.  uso prescripto de las herramientas de desarrollo. 6. cualquier licencia aplicable o restricción de uso > 7. 8.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I están siendo desarrollados por subsistemas fuera del alcance del esta Especificación de Requerimientos de Software pero con los cuales esta aplicación de software debe interactuar>. Restricciones de Diseño <Esta sección debería indicar cualquier restricción de diseño en el sistema. Ejemplos de esto son:  lenguajes de software. Describe todos los componentes comprados a ser usados por el sistema.x Descripción <Detalle> Autor <Nombre> . que no haya sido especificada con anterioridad>. Observaciones <Esta sección permite incorporar cualquier información que se considera de importancia. 4. Historia de Cambios Fecha <dd/mm/yyyy> Versión x. tales como redes de área local o dispositivos seriales remotos>. 5.  restricciones arquitectónicas y de diseño. Requerimientos de Licencia < Esta parte del documento debería especificar la necesidad de licencias asociada a la implementación de este producto. Estas restricciones representan decisiones de diseño a las que hay que adherirse.  seguridad  rendimiento.

Sign up to vote on this title
UsefulNot useful