Guía para la Especificación de Requerimientos de Software(ERS)

DEFINICION
1. Se basa sobre el problema de descubrimiento y comunicación de las necesidades de clientes y usuarios
2. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Tipos de requerimientos
1. Requerimientos funcionales
  1. Provee el sistema, describen todas las entradas , salidas y sus relaciones
2. NO requerimientos funcionales
  1. Definen los atributos que le indican al sistema cómo realizar su trabajo (eficiencia, hardware, software,)
    4. Clasificación de Requerimientos no funcionales
3. Énfasis de la información
  1. El énfasis es una forma de prevenir que el lector pierda atención de enunciados que son importantes para entender el resto de la información.
  2. TIPS(TECNICAS PARA LOGRARLO)
    1. Cualquier clase de contraste enfatiza el elemento contrastado.
    2. Lo que aparezca primero es enfatizado.
    3. Un gráfico enfatiza su contenido
Involucrados en la creación de la ERS
1. Usuarios: Los usuarios que conocen muy bien el problema.
2. Clientes: Son las personas que tienen los recursos para hacer la compra
3. Desarrolladores: grupo de personas en la organizacion satisfacen los requerimientos de los usuarios y los clientes
Problemas al definir requerimientos
1. Falta de estandarización
2. Estructura inconsistente
3. Falta de organización
4. Dificultades para definir los requerimientos
  1. Existen muchos tipos de requerimientos y diferentes niveles de detalle.
  2. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
  3. Son difíciles de expresar en palabras (el lenguaje es ambiguo).
  4. Nivel de especificad y alcances del documento de requerimientos (REGLAS )
    1. PASOS A SEGUIR(TIPS)
      1. Si es para que varios proveedores participen con propuestas, podrá tener menos grado de detalle con el fin de fomentar la competencia.
      2. El nivel de detalle dependerá de varios factores:
        Prácticas normales de la organización.
        El tipo de sistema por desarrollar.
      3. En primera instancia se debe definir cuál es el objetivo de éste, para determinar qué debe incluirse.
Agrupación de requerimientos
1. TIPS DE CONFORMACION
  1. La información RELACIONADA con otra información debe estar localizada de la misma forma físicamente
  2. Agrupar los mismos por funcionalidad que se deba suplir
  3. Al redactar un documento, especialmente de requerimientos, es fácil encontrarse con referencias cruzadas, es decir, que no se pueda establecer una dependencia unidireccional entre los enunciados.
Atributos de calidad que debe cumplir la ERS
1. Fallos de lenguaje natural
  1. Los requerimientos son a menudo escritos en el lenguaje natural , se debe hacer una revisión independiente para identificar el uso ambiguo del idioma de modo que se puede corregir.
2. Correcto
  1. Una especificación de requisitos es correcta si y sólo si todo requisito contenido en ella representa alguna propiedad requerida por el sistema a desarrollar. En otras palabras, ningún requisito debe ser innecesario.
3. Herramientas de representación
  1. El enfoque basado en proceso organiza los requerimientos dentro de jerarquías de funciones que se comunican entre sí vía de flujos de datos
  2. El enfoque de comportamientos describe comportamiento externo del sistema utilizando para ellos algunos conceptos con cierto nivel de abstracción
  3. El enfoque de objetos organiza los requerimientos en términos de objetos del mundo real, sus atributos, y los servicios ejecutados por esos objetos.
4. Completo
  1. Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
5. Clasificado por su importancia y/o estabilidad
  1. Un documento de requerimiento se encuentra clasificado por importancia y/o estabilidad,
  2. Clasificación
    1. Grado de estabilidad
      1. Esencial: Imprescindible. Implica que el software no será aceptado a menos que estos requerimientos sean suministrados de la manera acordada.
      2. Condicional: Pueden darse condiciones para que dicho requerimiento este o no presente. Implica que éstos son requerimientos que mejorarían el producto de software
      3. Opcional: Implica una clase de requerimientos que pueden o no existir
    2. Grado de importancia
      1. se refiere a qué cuán volátil es el requerimiento para guiar a la organización desarrolladora en los puntos donde debe ofrecer más flexibilidad.
6. Consistente
  1. Un requerimiento es consistente si no es contradictorio con otro requerimiento.
    1. Si ningún requerimiento declarado está en conflicto con otros documentos de más alto nivel.
7. Modificable
  1. Un documento de requerimientos es modificable si, y solo si, su estructura y estilo son tales que cualquier cambio a los requerimientos puede hacerse de forma fácil, completa y consistente
    1. REQUERIMIENTOS
      1. Tener una organización coherente y fácil de leer con una tabla de contenidos, índice y referencias cruzadas explícitas.
        No ser redundante, esto es que el requerimiento se encuentre repetido en el documento.
        Expresar cada requerimiento separadamente, en vez de entremezclarlos.
8. Rastreable o trazable
  1. Un documento de requerimientos es rastreable si y sólo si para cada requerimiento contenido en ella se conoce su origen y puede referenciarse como origen en posteriores documentos durante el desarrollo
    1. TIPOS
      1. Rastreo retrospectivo Esto es donde el requerimiento referencia explícitamente su origen en documentos predecesores
      2. Rastreo propectivo Esto significa que cada requerimiento debe tener un identificador único
9. Lenguajes de especificación de requerimientos
  1. Una vía para evitar la ambigüedad inherente en el lenguaje natural es escribir la especificación de requerimientos del software en un idioma particular de lenguaje de especificación.
10. No ambiguo
  1. Si cada requerimiento declarado tiene una sola interpretación. ES NO AMBIGUO
11. Verificable
  1. Un documento de requerimientos es verificable si, y solo si, cada requerimiento declarado es verificable.
12. Recomendaciones para redactar de requerimientos sin ambigüedad
  1. Orden más gramatical que técnico, pero que resulta de gran utilidad para que no ocurran confusiones a la hora interpretar los requerimientos, es decir, que no haya ambigüedad en la especificación:
13. Compresible por el cliente y los usuarios
  1. Pareciera que este atributo es redundante al establecer la propiedad de noambigüedad al documento de requerimientos, sin embargo
14. Independiente del diseño
  1. Un documento de requerimientos es independiente del diseño si y sólo si no especifica una determinada descomposición del sistema (arquitectura) ni ningún aspecto de su posible implementación (algoritmo).
15. Conciso
  1. El documento más corto es mejor.
16. Organizado
  1. Un documento de requerimientos se encuentra organizado si los requerimientos son fáciles de localizar.

Nächster

Guía para la Especificación de Requerimientos de Software(ERS)

Beschreibung

Zusammenfassung der Ressource

Medienanhänge

ähnlicher Inhalt

	Erstellt von MATTHEWS RUSSELL OBREGON vor mehr als 7 Jahre