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.
====== Puntos Importantes del primer parcial de Ingeniería de Requisitos ======
===== Requisitos No Funcionales de Sommerville =====
<WRAP group left>
Mientras que los requisitos funcionales indican QUE hace el sistema, los funcionales indica COMO debe funcionar (OJO: NO como lo hace)
{{drawio>ingenieria_de_requisitos:RequisitosNoFuncionalesSommerville.png}}
</WRAP>
===== Casos de Uso =====
Los casos de uso describen un conjunto de secuencias de acciones, incluyendo variantes que ejecuta el sistema para producir un resultado observable de valor para un actor. Se utiliza durante la captura de requisitos y el análisis de requisitos para visualizar, especificar, construir y documentar el comportamiento esperado del sistema. OJO: Describe que hace el sistema, pero no como lo hace
<WRAP group left>
{{drawio>ingenieria_de_requisitos:AsociacionesCasosDeUso.png}}
</WRAP>



<WRAP>


</WRAP>



<WRAP group left>
Hay varias formas de asociar entre sí los casos de uso:
  * **Extends**: Condicional, no siempre se va usar dicho caso de uso, la hacia el caso de uso que extiende.
  * **Include**: Siempre se va a realizar, sale desde el caso de uso al que hace include (La flecha va al revés que en el extends)
  * **Generalización**: Refleja Herencia, el caso del que sale la flecha actua de forma similar a una interface y los casos de uso a los que van son implementaciones de dicha interface aplicadas a ciertos casos.
</WRAP>
==== Ejemplo de asociaciones de casos de uso ====
<WRAP left>
{{drawio>ingenieria_de_requisitos:diagramaejemplocasosuso.png}}
</WRAP>

===== Requisitos según la IEEE-830 =====
==== Definición de requisito según la IEEE-830 ====
Es una condición o capacidad que un sistema debe poseer o cumplir para satisfacer un estándar, especificación u otros documentos. También pueden ser descritos como una representación documentada de capacidades o condiciones que debe cumplir el sistema.
  * Ingeniería de requisitos: Comprende las actividades de desarrollo de software de gestión y definición de requisitos para un sistema.
  * Especificación de Requisitos del Software (ERS): Documento formal de los requisitos del sistema

==== Objetivos de los requisitos ====
  * Ser correctos
  * Ser consistentes
  * Estar completos
  * Ser realistas
  * Ser verificables
  * Ser rastreables

Se deben evitar requisitos que no reflejen las necesidades reales del cliente, así como los que no sean consistentes o sean ambiguos. También se debe evitar realizar cambios a estos una vez han sido acordados.

===== CheckList =====

Es un conjunto de preguntas que el analista debe considerar para cada requisito individual. Estas preguntas están relacionadas con atributos de calidad. El problema de los checklist es que es imposible detectar defectos en los requisitos con estas.

===== Prototipado =====
Se utilizan como herramienta para clarificar requisitos poco claros o para validarlos. Hay varios tipos de prototipado:
==== Prototipado rápido o desechable ====
Comienza con partes del sistema que no se comprende del todo con el objetivo de obtener requisitos más precisos. Una vez se ha terminado con el prototipo, este se desecha.

==== Prototipado evolutivo ====
Es útil cuando los requisitos están bien establecidos. A diferencia del prototipado rápido, aquí no se desecha el prototipo al final, se reutiliza ya sea modificándolo o como producto final. Es bastante útil en sistemas Orientados a objetos ya que permite el reúso de un paso al siguiente o de un proyecto a otro. Este tipo de prototipado es fácil de cambiar durante el desarrollo, haciendo que sea más probable alcanzar el sistema que los usuarios desean.

==== Prototipado Operacional ====
Se trata de una combinación del prototipado rápido y el operacional. Solo se implementan los requisitos que están claros usando técnicas de desarrollo de prototipado evolutivo a partir de los requisitos iniciales. Un técnico que actúa de prototipador visita los puestos de los usuarios y crea prototipos rápidos con las características que el usuario desea. Si alguno de estos prototipos rápidos no sirve se desecha, pero en caso de que sea correcto, se desinstala del puesto y se notifica al departamento de desarrollo la inclusión de los requisitos implementados en dicho prototipo.


===== Triage =====
También conocido como selección de requisitos, el triage consiste en seleccionar los requisitos cuidadosamente con el objetivo de maximizar los beneficios antes de decidir que requisitos se implementarán. Se suele tener en cuenta:
  * La influencia de los requisitos en el producto final
  * Gastos e ingresos
  * Aspectos técnico-sociales

==== Influencia de los requisitos en el triage ====
  * Escalabilidad: evalúa la resistencia de los requisitos al cambio
    * Estables: Son aquellos relacionados con la esencia del sistema y el dominio
    * Volátiles: depende de las modas o necesidades:
      * Mutables: Cambios en el entorno del sistema
      * Emergentes: Aparecen con el uso del sistema
      * Consecuentes: Producidos por suposiciones erróneas
      * Compatibles: La compatibilidad del sistema cambia con los requisitos
  * Propiedades a considerar:
    * Importancia: Evalúa el impacto que los requisitos ejercen en el entorno de inversión
      * Objetiva o subjetiva
      * No pueden obtenerse de los usuarios, es necesario algún tipo de acción específica para su anotación
    * Adecuadas referencias cruzadas
      * Permiten identificar los requisitos que deben implementarse conjuntamente
      * Si dos requisitos están relacionados la implementación de uno afecta al otro

==== Evaluación del beneficio ====
La selección de requisitos implica cuantificar todas las variables, se suelen utilizar valores monetarios para ayudar al cliente a ser consciente del coste, aunque se puede también cuantificar en tiempo.
  * evaluación de gastos
  * Evaluación de ingresos
    * Contrato fijo, desarrollo interno o ingresos intangibles
    * Debe ser el analista el que idee un método de cuantificación que permita la comparación de productos alternativos

===== Trazabilidad =====

Es el proceso que permite relacionar los requisitos con otros productos del proceso de desarrollo, así como los requisitos entre sí. La especificación de estos debe ser:
  * Trazada: cada requisito debe estar relacionado con su origen
    * Trazabilidad hacia atrás: Anotar cada requisito con su origen (Documento o cliente)
  * Trazable: Cada requisito debe estar relacionado con los productos subsiguientes
    * Trazabilidad hacia delante: Compleja ya que puede dar lugar a múltiples productos
  * Con referencias cruzadas: Cada requisito debe poder relacionarse con otros requisitos
    * Trazabilidad interna: Anotación de cada requisito donde se indicaría los requisitos relacionados (Herramientas CASE)

En la trazabilidad también se pueden utilizar matrices de estabilidad como buena práctica para llevar a cabo la actividad de forma eficiente. Es importante conocer los aspectos de los requisitos como su origen, necesidad, relación con otros requisitos y relación con otros elementos.
Knoppia

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
