Knoppia

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Especificación de requisitos ======
Los documentos de requisitos son diferentes en función a si son para clientes técnicos o clientes no conocedores.
El documento de requisitos tiene los siguientes requisitos:
  * Comunicación entre clientes, usuario y desarrolladores
  * Permitir iniciar la actividad de diseño
  * Soportar las actividades de pruebas del sistema
  * Controlar la evolución del sistema

===== Contenido =====

  * Propiedades y comportamientos de nuestro sistema
  * Restricciones de diseño y de producto
  * Propiedades emergentes del sistema

que No debe incluir
  * Información referente al proyecto
  * Diseño
  * Planes de garantía del producto
  * Costes

===== Como se deben escribir los requisitos =====


Se usan frases como Mi sistema tiene que, "El sistema debe", "El sistema Hará", "el sistema Habilitará"
Debe utilizarse lenguaje natural, este se puede complementar de diagramas y notaciones formales.
El cliente debe participar en el documento

Los requisitos se deben poner en positivo, salvo excepciones, como sistemas críticos en donde indicaremos que NO hará el sistema

===== Formato de las especificaciones =====

  * Solo texto
  * Texto y técnicas
    * Lo más usado
  * Solo técnicas
    * No recomendables

El documento de requisitos es la forma que tenemos de formar y guardar los requisitos.

===== Documentación Requisitos Usuario (DRU) =====

Plasmamos el problema que tiene el usuario. Definimos el problema en un proceso iterativo donde el usuario es el máximo responsable
  * **Objetivo**: Obtener definiciones de lo que el usuario espera del sistema
  * **Entradas**: Resultados de entrevistas, encuestas, estudios, ejercicios de prototipado
  * **Salidas**: Documento de requerimientos de usuario DRU, donde se describen todos los requerimientos con claridad y consistencia

Actividades
  * Especificar los requisitos del usuario
  * Describir los requisitos en términos de sus atributos
  * Organizar los requisitos en base a la categoría que pertenezcan
  * Revisar y comprobar las salidas de la fase

Atributros de los requisitos de usuario
  * Identificador: número necesidad: Como de necesario es 
  * prioridad:Que prioridad tiene, alta, media o baja 
  * estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes 
  * fuente: Quien ha dicho el requisito 
  * claridad: Como de claro está 
  * verificabilidad: Todos los requisitos deben poder realizarse


===== Documento de requisitos del software (ERS) =====
Fase de análisis del problema donde se adopta un método

Actividades
  * Especificar los requisitos del software
  * Describir los requisitos eb tñernminos de sus atributos, asegurando la completitud y consistencia
  * Organizar los requisitos en base a la categoría a la qu pertenezcan
  * Revisar y comprobar salidas de la fase

Atributos del documento de requisitos del software (ERS):
  * Identificador: número necesidad: Como de necesario es 
  * prioridad:Que prioridad tiene, alta, media o baja 
  * estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes 
  * fuente: Quien ha dicho el requisito 
  * claridad: Como de claro está 
  * verificabilidad: Todos los requisitos deben poder realizarse


Lectores/usuarios de la ERS
  * Clientes: para comprobar que satisface sus necesidades y para hacer cambios en los requisitos
  * gestores: Para preparar una oferta por el sistema y planificar el proceso de desarrollo
  * ingenieros de desarrollo: Para comprender el sistema a desarrollar
  * ingenieros de pruebas: Para elaborar pruebas de validación
  * ingenieros de mantenimiento: Para facilitar la comprensión del sistema y las relaciones entre sus partes

===== Diferencia entre ERS y DRU =====

El DRU esta en lenguaje más natural e incluye tal cual el problema a resolver, el ERS contiene los requisitos y como se va a solucionar el problema.
La diferencia entre ERS y DRU es que uno está más detallado de otro

La diferencia entre ambos es el nivel de detalle (EXAMEN), uno está más detallado que otro.


===== Características de una buena ERS (IEE-830) =====


  * No puede haber ambigüedad
    * Un requisito ambigüo se presta a distintas interpretaciones
  * Completa
    * No puede haber secciones To Be Determined (TBD)
    * Se describen todas las posibles respuestas a todas las posibles entradas
    * Páginas numeradas, figuras y tablas con referencias. El documento debe tener formato estandarizado
  * Correcto
    * Todos los requisitos deben satisfacer lo que el cliente quiere
  * Verificable
    * Se tiene que comprobar que el requisito se pueda hacer
  * Consistencia
    * Los requisitos no pueden entrar en conflicto con otros.
  * Realizables
    * Que se puedan implementar
  * Concisos
    * Deben ser breves
  * Independiente del diseño
  * Trazable
    * Se deben poder referenciar por numeración
  * Modificable
  * Electrónicamente almacenado
  * Ejecutable/interpretable/Prototipable
  * Anotada por importancia relativa
  * Anotada por estabilidad relativa
  * Anotada por versión
  * No redundante
  * A un nivel de detalle adecuado
  * Precisa
  * Reutilizable
  * Trazada
  * Organizada
  * Con referencias Cruzadas
===== Estructura del Documento de Requisitos =====

  - Introducción
    - Proposición
    - Ámbito
    - Definiciones, Acrónimos, Abreviaturas
    - Referencias
    - Visión general del resto del documento
  - Descripción General
    - Perspectiva del producto
    - Funciones del producto
    - Características del usuario
    - Restricciones generales
    - Asunciones y Dependencias
  - Requisitos específicos: Todos los requisitos que tenemos clasificados con identificador único, referencia, entrada y salida.
    - Interfaces externas
      - Descripción detallada de entradas y salidas
      - Complementa descripciones de interfaz
    - Funciones
    - Requisitos de rendimiento/ejecución
    - Restricciones de diseño
    - Atributos de calidad del software
    - Otros Requisitos



===== Problemas que podemos tener en el documento de requisitos =====

  * Puede haber demasiados requisitos, de forma que los cambios se vuelven demasiado difíciles
  * Hay herramientas llamadas CARE que nos permiten gestionar una gran cantidad de requisitos
  * No consideración de requisitos obvios
  * Nivel de detalle: Tiene que haber un nivel de detalle adecuado para el cliente
  * Ubicación de los requisitos: Poner los requisitos donde corresponden


===== Etapas de la revisión =====
  - preparamos plan de revisión
  - Distribuimos los documentos a revisar
  - Preparación de la reunión
  - Realizar la reunión de revisión
  - Identificar defectos y acciones a realizar
  - Realizar correcciones que sean precisas

===== Herramientas para Revisiones =====

  * Checklist de validación: cada organización tiene uno diferente.
  * Pre-Revisiones: antes de la revisión se realizan reuniones pequeñas para ver que errores hay.
  * Prototipado
    * Usado en diversas disciplinas
    * Se usa para ver y comprobar que los requisitos que tenemos son correctos
    * Tipos de prototipos:
      * Mock-Ups: Pantallas dibujadas a mano que representa un aspecto en concreto del sistema. Suele ser dibujado en papel
      * StoryBoard: Evolución del MockUp, suelen estar hechos a ordenador, muestra la secuencia de acciones o escenarios que se deben realizar con el programa.
      * Maquetas: versiones simplificadas de nuestra aplicación. Simula realizar las acciones del programa.
    * Prototipos comunes en Ingeniería de Requisitos:
      * Seleccionamos quien evaluara el prototipo
      * Desarrollar escenarios de validacón
      * Ejecutar Escenarios
      * Documentar problemas

===== técnicas de validación =====

  * Generación de casos de prueba: Un caso de prueba describe una acción que el cliente quiere que realice el software.
  * Manuales de usuario
  * Animación y validación de modelos o especificaciones formales
Knoppia

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
