1. El documento de especificación de requisitos debe ser legible por el cliente, con lo que se evita el malentendido de determinadas situaciones, ya que el cliente participa activamente en la extracción de dichos requisitos
1.1. Estructurada: basada en la representación de las funciones que debe realizar el sistema y los datos que fluyen entre ellas (diagramas de flujo de datos).
1.2. Metodología orientada a objetos: utiliza el UML, mediante el cual podemos representar diagramas (casos de uso) que permiten definir el sistema desde el punto de vista del usuario estableciendo las relaciones entre el futuro sistema y su entorno.
2. CARACTERÍSTICAS DE LA ERS
2.1. Correcta: La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real, esto implica que el sistema implementado será el sistema deseado
2.2. No ambigua: Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación.
2.3. Cada característica del producto final debe ser descrita utilizando un término único y, en caso de que se utilicen términos similares en distintos contextos, se deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado específicamente.
2.4. 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.
2.5. Verificable: Un requisito 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
2.6. Consistente: Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto.
2.7. Clasificación: No todos los requisitos son igual de importantes; los requisitos pueden clasificarse por diversos criterios:
2.8. Modificable: Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente
3. FASES DEL SRS
3.1. Introducción: En esta sección se proporcionará una introducción a todo el documento de Especificación de Requisitos Software. Consta de varias subsecciones
3.2. Propósito: Se definirá el propósito del documento ERS y se especificará a quién va dirigido el documento
3.3. Definiciones, Acrónimos y Abreviaturas: Se definirán todos los términos, acrónimos y abreviaturas utilizadas en el desarrollo de la ERS.
3.4. Referencias: Se presentará una lista completa de todos los documentos referenciados en la ERS.
3.5. Visión General del Producto: Esta subsección describirá brevemente los contenidos y la organización del resto de la ERS
3.6. Descripción General: En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos.
3.7. Perspectiva del Producto: Esta subsección debe relacionar el futuro sistema con otros productos.
4. Fases de análisis de requisito
4.1. Se deben identificar claramente estas necesidades y documentarlas para producir un documento de especificación de requisitos en el que se describa lo que el futuro sistema debe hacer; por tanto, no se trata simplemente de una actividad de análisis, sino también de síntesis.
4.2. 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
4.3. al requisito como una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado
4.4. determinación de los requisitos no sólo deben actuar los analistas, es muy importante la participación de los propios usuarios, porque son éstos los que mejor conocen el sistema que se va a automatizar
5. El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo de software, puesto que en ella se determinan los “planos” de la nueva aplicación
6. OBJETIVOS DE LA ERS
6.1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software:
6.2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente:
6.3. Servir de base para desarrollos de estándares de ERS particulares para cada organización:
6.4. Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto, debe definir correctamente todos los requerimientos, pero no más de los necesarios
