P. 1
Plantilla_Requerimientos

Plantilla_Requerimientos

|Views: 76|Likes:
Publicado porSofi Legalb

More info:

Published by: Sofi Legalb on Oct 23, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

10/23/2011

pdf

text

original

ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I

DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS

4 Reglas y Funciones de Negocio 3.3 Requerimientos No Funcionales 3.1.Observaciones 8.1 Actores 3.2 Requerimientos Funcionales 3.3.1 Propósito del Sistema 1.Requerimientos de Interfaz 5.Descripción Detallada de Requerimientos 3.Historia de Cambios .2.2 Restricciones y Supuestos 2.Requerimientos de Licencia 7.2 Listado de Casos de Uso 3.2 Alcance 1.3 Detalles de Casos de Uso 3.2.2 Contexto del Producto 2.1.1 Del Producto 3.Descripción General 2.1 Objetivo 1.Restricciones de Diseño 6.1 Listado de la Funcionalidad del Sistema 2.2 Del Ambiente 4.2.3.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I CONTENIDO 1.1.1 Diagramas de Casos de Uso 3.2.4 Prototipo de Interfaz de Usuario 3.3 Perspectivas futuras del producto 2.Presentación del Producto 1.3 El Sistema no contempla 1.

Listado de la Funcionalidad del Sistema <Esta sección proporciona un sumario de las principales funciones que debe realizar el producto. 1. 2.: 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. . En ocasiones la información de esta sección puede tomarse de un documento de especificación del sistema (ej. que puede afectar al cumplimiento de los requerimientos y que viene dado desde el ambiente del negocio o acordado con anterioridad.1. Objetivo: <Este campo deberá indicar de manera general lo que se pretende lograr con el desarrollo del sistema.3. Propósito del Sistema 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. No se debe incluir puntos referentes al proyecto. Restricciones y Supuestos: <El objetivo de este apartado es indicar cualquier aspecto que debe ser considerado para el desarrollo.1. El objetivo de esta sección es dejar expresadas cuestiones que el producto no cubrirá. 1.1.1. No se debe incluir puntos referentes al proyecto. 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.2. 1. Presentación del Producto 1.2. Descripción General 2. sin entrar en demasiado detalle.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I 1. sino especificar el objetivo del producto a desarrollarse.>. Alcance: <Se deben indicar en términos generales las funciones que el sistema deberá realizar o los módulos que contendrá.1. al menos hasta el momento>. sino especificar el alcance del producto a desarrollarse >.

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

prioridad del cliente. con sus atributos obligatorios.> 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).ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I de errores). o Parámetros. prioridad final. incluyendo:  Secuencias de entradas y salidas. 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 . o Relaciones entre entradas y salidas. complejidad.> 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. <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. nivel de riesgo de arquitectura. Esta información puede proveerse directamente o por referencia a otro documento.

3. con resolución de pantalla de 800 x 600 RN-3. RN-4. Redactar teniendo en cuenta que el RNF pueda ser probado >. Las interfaces específicas de los casos de uso se pueden detallar en cada descripción de caso de uso. alternativamente. 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).3. . 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. Estos incluyen: RN 1: Especificar el tiempo de capacitación requerido para usuarios normales y expertos para convertirse en productivos en operaciones particulares. con lo cual deben ser accedidas mediante Internet Explorer X. RN-2.1. tales como estándares de GUI>. Los requerimientos identificados en esta parte del documento son aplicables al producto en general.X o superior. El sistema está preparado para ser operado a través de mouse y teclado. Las pantallas serán desarrolladas para ambiente Windows 98 ó posterior. 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.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I documento. requerimientos de usabilidad básica del nuevo sistema sobre otros sistemas que los usuarios conocen y les agradan.3. Las pantallas de <Nombre_ de_Producto> son en ambiente Web. RN 3: Especificar requerimientos para conformidad con los estándares comunes de usabilidad. Texto sugerido: RN-1.> 3. Del Producto Usabilidad: <se debería incluir todos aquellos requerimientos que afectan la usabilidad.

28 hs. 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. siguiente y anterior). pero también puede especificarse en días. etc. horas de uso. RN-7. RN-6. Todas las búsquedas o consultas deben estar paginadas (botones primero. comunes o mejoras>. El sistema deberá estar disponible en un 97% de su tiempo online. etc. último. RN 7: Certeza: Precisión Especifica (resolución) y certeza (sobre un estándar) que es requerida para las salidas del sistema. meses y años. Disponibilidad: 97%. Performance: <incluye tiempos de respuesta específicos: . Los campos obligatorios deberán estar marcados con * (asterisco). 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 9: Errores o índices de defectos: usualmente expresados en términos de errores invalidantes. (de 24hs al menos 23. leves. Texto sugerido: RN-8.ESPECIFICACIÓN DE REQUERIMIENTOS Ingeniería de Software I RN-5. RN 5: Tiempo mínimo entre fallas: Especificado usualmente en horas.) RN-9. graves. acceso de mantenimiento. 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?.

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

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

Restricciones de Diseño <Esta sección debería indicar cualquier restricción de diseño en el sistema. Observaciones <Esta sección permite incorporar cualquier información que se considera de importancia. que no haya sido especificada con anterioridad>. cualquier licencia aplicable o restricción de uso > 7. 6.x Descripción <Detalle> Autor <Nombre> . Historia de Cambios Fecha <dd/mm/yyyy> Versión x. 5.3. Estas restricciones representan decisiones de diseño a las que hay que adherirse. Describe todos los componentes comprados a ser usados por el sistema. tales como redes de área local o dispositivos seriales remotos>.  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. 8.  seguridad  rendimiento. Interfaces de Comunicación <Describe las interfaces de comunicación u otros requerimientos de restricción o dispositivos. Ejemplos de esto son:  lenguajes de software.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>. 4.  uso prescripto de las herramientas de desarrollo.  requerimientos del proceso de software.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->