1. Caracteristicas de una buena ERS
1.1. Correcta
1.1.1. si y sólo si todo requisito que figura en ella refleja alguna necesidad real.
1.2. no ambigua
1.2.1. si y solo si cada requisito descrito tiene una única interpretación, especificar muy bien y claro los requisitos
1.3. Completa
1.3.1. Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas)
1.3.2. Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.
1.3.3. Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado
1.4. verificable
1.4.1. 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
1.5. consistente
1.5.1. si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto
1.6. clasificada
1.6.1. Los requisitos pueden clasificarse por diversos criterios:
1.6.1.1. Importancia: Pueden ser esenciales, condicionales u opcionales.
1.6.1.2. Estabilidad: Cambios que pueden afectar al requisito.
1.7. modificable
1.7.1. si cualquier cambio puede realizarse de manera fácil, completa y consistente, no incurrir en redundancias con eso en el momento de hacer la modificacion no tendremos que buscar en mas de un sitio para hacerla.
1.8. explorable
1.8.1. si el origen de cada requerimiento es claro tanto hacia atrás
1.8.1.1. origen que puede ser un documento, una persona etc.
1.8.2. como hacia delante
1.8.2.1. componentes del sistema que realizan dicho requisito
1.8.3. Cuando el código y los documentos son modificados, es esencial poder comparar el conjunto total de requisitos que puedan verse afectados por estas modificaciones.
1.9. Utilizable en tareas de mantenimiento y uso
1.9.1. El personal que no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su mantenimiento. Así, dicha ERS actúa a modo de plano de la aplicación, permitiendo incluso modificaciones que no requieran un cambio en el diseño.
1.9.2. En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal que se encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria una correcta documentación de las funciones, ya que si no se conoce en detalle su origen, difícilmente podrán ser modificadas.
2. Introduccion
2.1. proposito
2.1.1. Se especifica a quien va dirigido el Documento
2.2. Ambito del Sistema
2.2.1. se dara nombre al futuro sistema y se especifica que hara y lo que no
2.3. definiciones, acronimos y abreviaturas
2.3.1. Se definirán aquí todos los términos, acrónimos y abreviaturas utilizadas en el desarrollos
2.4. referencas
2.4.1. Se presentará una lista completa de todos los documentos referenciados
2.5. Vision general del Documento
2.5.1. describirá brevemente los contenidos y la organización del resto de la ERS.
3. Descripcion general
3.1. prespectiva del producto
3.1.1. Indicar si es un producto independiente o parte de un sistema mayor 1. Interfaces de sistema 2. Interfaces de usuario 3.Características lógicas del interfaz 4.Cuestiones de optimización del interfaz de usuario 5. Interfaces hardware 6. Interfaces software 7. Descripción del producto software utilizado 8. Propósito del interfaz 9. Definición del interfaz: contenido y formato 10. Interfaces de comunicaciones 11. Limitaciones de memoria 12. Operaciones 13. Modos de operación de los distintos grupos de usuarios 14. Periodos de operaciones interactivas y automáticas 15. Funciones respaldo del procesamiento de datos 16. Operaciones de backup y recuperación 17. Requerimientos para adaptarse a la ubicación 18. Indicar cualquier dato o secuencia de inicialización específico de cualquier lugar, modo de operación. 19. Características que deben ser modificadas para una instalación en particular.
3.2. funsiones del Producto
3.2.1. 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
3.3. Caracteristicas de los Usuarios
3.3.1. Se indica aquí el tipo de usuario al que se dirige la aplicación, así como suexperiencia técnica, nivel de conocimientos, etc.
3.4. Restriciones
3.4.1. ualquier 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.
3.5. Supocisiones y Dependencias
3.5.1. En este apartado aparecerá cualquier factor, que si cambia puede afectar a los requerimientos. Si cambian ciertos detalles puede ser necesario revisar los requisitos.
3.6. Requisitos Futuros
3.6.1. Se indican aquí posibles mejoras del sistema en el futuro. Estas mejoras deben estudiarse y analizarse una vez concluido y puesto en marcha el sistema
4. Requisitos Especificos
4.1. Interfaces Externas
4.1.1. En esta subsección se definirán los requisitos que afecten a la interfaz de usuario e interfaz con otros sistemas (hardware y software), así como a interfaces decomunicaciones.
4.2. Funsiones
4.2.1. En este subsección de 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.
4.2.1.1. Por tipo de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organización, se especifican los requisitos funcionales que le afecten o tengan mayor relación con sus tareas.
4.2.1.2. Por objetos: Los objetos son entidades del mundo real que son reflejadas en el sistema. Por tanto, para cada objeto se detallan sus atributos y sus funciones. Los objetos se pueden agrupar en clases. A pesar de realizar el análisis con objetos no obliga a que el diseño del sistema siga el paradigma Orientado a Objetos, aunque lo facilita en gran medida.
4.2.1.3. Por objetivos: un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo requerido al sistema, se detallarán las funciones que permitan llevarlo a cabo.
4.2.1.4. Por jerarquía funcional: La funcionalidad del sistema se especifica como una jerarquía de funciones que comparten entradas, salidas o datos del propio sistema. Para cada función y subfunción del sistema se detallará la entrada, el proceso en el que interviene y la salida. Normalmente este tipo de análisis implica que el diseño siga el paradigma de diseño estructurado. Por lo general éste sistema se utiliza cuando ninguno de los anteriores se puede aplicar.
4.3. Requisitos de Rendimiento
4.3.1. n esta subsección se 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 ...)
4.4. Restricciones de Diseño
4.4.1. Se incluyen aquí 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.
4.5. Atributos del Sistema
4.5.1. Se detallarán atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos de acceso restringido (password), usuarios autorizados a realizar ciertas tareas críticas ...
4.6. Otros Requisitos
4.6.1. Aquellos requerimientos que no se hayan podido incluir en ninguna de las secciones anteriormente especificadas.