¿No sabes por dónde empezar? Ayúdanos normalizando artículos.
¿Tienes experiencia? Crea alguno de estos artículos de actualidad.
Diferencia entre revisiones de «Modelo de Durán»
(Página creada con '<div align="justify"> {{Definición |nombre= Dr. Amador Durán Toro |imagen= Dr._Amador_Durán_Toro.jpg |tamaño= 180 × 213 píxeles |concepto= }} '''Modelo de Durán''': Model...') (Etiqueta: no tiene enlaces internos) |
|||
Línea 6: | Línea 6: | ||
|concepto= | |concepto= | ||
}} | }} | ||
− | '''Modelo de Durán''': Modelo realizado por el Dr. Amador Durán Toro en su tesis doctoral “Un entorno metodológico deingeniería de requisitos para sistemas de información” que recoge una serie detécnicas, tareas y plantillas a utilizar durante las actividades de elicitacióno negociación, análisis y validación de los requerimientos. | + | '''Modelo de Durán''': Modelo realizado por el Dr. Amador Durán Toro en su [[tesis]] doctoral “Un entorno metodológico deingeniería de requisitos para sistemas de información” que recoge una serie detécnicas, tareas y plantillas a utilizar durante las actividades de elicitacióno negociación, análisis y validación de los requerimientos. |
== Descripción == | == Descripción == | ||
El modelo de Durán describe un entorno metodológico para la ingeniería de requisitos para | El modelo de Durán describe un entorno metodológico para la ingeniería de requisitos para | ||
Línea 21: | Línea 21: | ||
* Identificar los actores del sistema, identificar los requisitos funcionales (Casos de Uso) que debe cumplir el sistema software a desarrollar y revisar, en el caso de que haya conflictos, los requisitos funcionales previamente identificados. | * Identificar los actores del sistema, identificar los requisitos funcionales (Casos de Uso) que debe cumplir el sistema software a desarrollar y revisar, en el caso de que haya conflictos, los requisitos funcionales previamente identificados. | ||
− | * Identificar/revisar los requisitos no funcionales del sistema software a desarrollar. | + | * Identificar/revisar los requisitos no funcionales del sistema [[software]] a desarrollar. |
* Priorizar objetivos y requisitos. | * Priorizar objetivos y requisitos. |
Revisión del 09:34 4 jun 2012
|
Modelo de Durán: Modelo realizado por el Dr. Amador Durán Toro en su tesis doctoral “Un entorno metodológico deingeniería de requisitos para sistemas de información” que recoge una serie detécnicas, tareas y plantillas a utilizar durante las actividades de elicitacióno negociación, análisis y validación de los requerimientos.
Descripción
El modelo de Durán describe un entorno metodológico para la ingeniería de requisitos para sistemas de información compuesto por:
- Un modelo de procesos iterativo en el que se identifican tres actividades fundamentales: elicitación, análisis y validación.
- Una metodología para la elicitación de requisitos de sistemas de información, incluyendo las tareas a realizar, los productos a obtener y las técnicas a emplear, principalmente plantillas y patrones de requisitos, así como la posibilidad de introducir la reutilización en el proceso.
- Una metodología para el análisis de requisitos de sistema de información, incluyendo las tareas a realizar, los productos a obtener y las técnicas a emplear, principalmente plantillas y patrones de requisitos, así como la posibilidad de introducir la reutilización en el proceso.
- Una metodología para el análisis de sistemas de información, incluyendo las tareas a realizar, los productos a obtener y las técnicas a emplear, basadas en el estándar UML y con relaciones de rastreabilidad hacia los productos de la actividad anterior que facilita la reutilización de elementos complejos.
Tareas a realizar y técnicas a emplear durante las actividades de elicitación, análisis y validación de requisitos:
- Obtener información sobre el dominio del problema y el sistema actual con el objetivo de conocer el dominio del problema y la situación actual.
- Preparar y realizar las reuniones de elicitación/negociación con el objetivo de conocer las necesidades de clientes y usuarios, y resolver posibles conflictos.
- Identificar los objetivos del sistema que se esperan alcanzar mediante el sistema software a desarrollar y revisar, en el caso de que haya conflictos, los objetivos previamente identificados.
- Identificar los actores del sistema, identificar los requisitos funcionales (Casos de Uso) que debe cumplir el sistema software a desarrollar y revisar, en el caso de que haya conflictos, los requisitos funcionales previamente identificados.
- Identificar/revisar los requisitos no funcionales del sistema software a desarrollar.
- Priorizar objetivos y requisitos.
Fuentes
- Amador Durán Toro. Un entorno metodológico de ingeniería de requisitos para sistemas de
información. 2000 disponible en: http://fondosdigitales.us.es/tesis/tesis/30/un-entorno-metodologico-de-ingenieria-de-requisitos-para-sistemas-de-informacion/