Ingeniería De Requisitos

*
* Email
* Favorite
* Favorited ×
* Download
* More
*
We have emailed the verification/download link to "kassa23@univision.com".
Login to your email and click the link to download the file directly.
To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.
Check your bulk/spam folders if you can't find our mail.
*
*
Favorited! Want to add tags? Have an opinion? Make a quick comment as well
. Cancel
*
Edit your favorites Cancel
*
Send to your Group / Event
Add your message Cancel
* Twitter
* Facebook
* Buzz
* WordPress
* Blogger
* more »
*
*
Embed for WordPress.com without related content
1 comment
Comments 1 - 1 of 1 comment previous next Post a comment
* + esdwinforero esdwinforero 4 weeks ago spam
buen trabajo
Post a comment
Embed Video Subscribe to comments Unsubscribe from comments
Edit your comment Cancel
Notes on slide 1
no notes for slide #1
no notes for slide #1
3 Favorites
* DianaCRR DianaCRR 5 months ago
* miguelrodriguezs Miguel Rodriguez, Software/Web Developer at Internet, 2
years ago
* ajaraujo Adolfo José Araujo Jaimes ajaraujo, Engineer at UTEC, 2 years ago
Tags ingeniería de reqhisitos desarrollo
more
Ingeniería De Requisitos - Presentation Transcript
1.
2.
* Ayuda a los ingenieros de software a entender mejor el problema en c
uya solución trabajarán.
* ¿Por qué es importante? Se debe entender lo que el cliente quiere antes
de comenzar a diseñar y construir un sistema.
* Toma en cuenta errores, coste y tiempo.
* La IR trata de los principios, métodos, técnicas y herramientas que perm
iten descubrir, documentar y mantener los requisitos, de forma sistemática y repet
ible.
Ingeniería de requisitos
3.
* El objetivo del proceso de la ingeniería de requisitos es darle a toda
s las partes una explicación escrita del problema.
* Es esencial que se haga un esfuerzo real por entender los requisitos
de un problema antes de intentar resolverlo.
Ingeniería de requisitos
4.
* Funcionales
o Describen los servicios que se esperan del sistema.
* No funcionales
o Restricciones sobre los requisitos funcionales
o Existen dos tipos:
Ingeniería de requisitos ORIENTADOS AL USUARIO ORIENTADOS AL DESARROLLADOR F
iabilidad Disponibilidad Seguridad Portabilidad Usabilidad Adaptabilidad Robuste
z Testabilidad Rendimiento, etc Comprensibilidad
5.
* Proporciona el mecanismo adecuado para entender lo que el cliente qu
iere.
* Fases de la IR:
Ingeniería de requisitos
6.
* Se inicia muchas veces por:
o Identifica nueva necesidad de negocios.
o Se descubre un nuevo mercado.
o Se descubre un nuevo servicio.
Ingeniería de requisitos
7.
* La obtención de información no es tan fácil como parece. Los ingenieros de
ben realizar en forma organizada la actividad de recopilación de requisitos.
Ingeniería de requisitos DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD Limite del sist
ema mal definido El cliente no está seguro 100% de que es lo que necesita Los prob
lemas cambian con el tiempo. Detalles técnicos innecesarios, etc. Tienen dificulta
des para comunicar sus necesidades, etc.
8.
* Objetivo: Desarrollar modelo técnico refinado de las funciones, caract
erísticas y restricciones del software.
* Se conduce mediante la creación y refinamiento de escenarios.
* El resultado final es un modelo de análisis que define:
o El dominio de la información.
o Funciones.
o Comportamiento del problema.
Ingeniería de requisitos
9.
* Clientes, usuarios y otros interesados deben ordenar sus requisitos
y luego discutir los conflictos relacionados con la prioridad.
 * Hacer estimaciones preliminares del esfuerzo requerido para su desar
rollo.
* Mediante un enfoque iterativo los requisitos se elimina, combinan o
modifican.
Ingeniería de requisitos
10.
* Puede ser:
o Se recomienda que:
o La especificación es el trabajo final que genera la IR.
Ingeniería de requisitos SISTEMAS GRANDES SISTEMAS PEQUEÑOS Documentos escrito
s Escenarios de uso Documento escrito Conjunto de modelos gráficos Modelo matemático
formal Escenarios de uso Prototipo Una combinación de estos.
11.
* Examina la especificación para asegurar que los requisitos de software
se han establecido de manera precisa.
Ingeniería de requisitos ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR ¿La fuent
e del requisito está identificado? ¿Cuáles otros requisitos están relacionados con éste? ¿E
requisito viola alguna restricción del dominio del sistema? ¿El requisito se puede
probar? ¿Se pueden especificar las pruebas?, etc.
12.
* Es el conjunto de actividades que ayuda al equipo del proyecto a ide
ntificar, controlar, rastrear los requisitos como también los cambios a éstos en el
desarrollo del proyecto.
* Para esto se desarrollan las siguientes tablas:
o La gestión formal se inicia solo para proyectos grandes
Ingeniería de requisitos TABLAS De rastreabilidad de las características. De r
astreabilidad de la fuente. De rastreabilidad del subsistema. De rastreabilidad
de la interfaz.
13.
* Identificación de los interesados.
o Todos aquellos que se benefician en una forma directa o indire
cta del sistema.
* Reconocimiento de múltiples puntos de vista.
o Categorizar la información de los interesados de manera que perm
ita elegir un conjunto de requisitos para el sistema que sean consistentes de ma
nera interna.
* Trabajo con respecto a la colaboración.
o Identificar áreas en común y áreas inconsistentes.
* Formulación de las primeras preguntas
o Las preguntas deben ser libres de contexto .
+ ¿Quién usará la solución?
+ ¿Cuál será el beneficio económico de una solución exitosa?
Ingeniería de requisitos
14.
* Recopilación conjunta de requisitos
o La meta es identificar el problema, proponer elementos de solu
ción, negociar diferentes enfoques y especificar un conjunto de requisitos prelimi
nares.
Ingeniería de requisitos
15.
* Es una técnica que traduce las necesidades del cliente en requisitos téc
nicos para el software.
* QFD define los requisitos para maximizar la satisfacción del cliente.
* QFD identifica 3 tipos de requisitos.
Ingeniería de requisitos NORMALES ESPERADOS ESTIMULANTES Objetivos y metas e
stablecidos para un sistema durante las reuniones con el cliente. Están implícitos e
n el producto o sistema. Características que van más allá de las expectativas del clie
nte.
16.
* Se aplica para determinar el valor de cada función que se requiere par
a el sistema.
* El despliegue de la información identifica los datos de los objetos y
eventos que debe consumir y producir el sistema.
* El despliegue de tareas examina el comportamiento del sistema o prod
ucto dentro del contexto de su entorno.
Ingeniería de requisitos
17.
* Escenarios del usuario.
o Proporcionan una descripción de cómo se usará el sistema.
* Productos de trabajo de obtención.
o Los productos producidos como consecuencia de la obtención de re
quisitos variará de acuerdo con el tamaño del sistema a construir.
Ingeniería de requisitos
18.
* Un caso de uso muestra el software o sistema desde el punto de vista
del usuario final.
* Los actores son las diferentes personas que utilizan el sistema dent
ro del contexto de la función y el comportamiento que se describirá.
* Un actor es algún elemento que se comunica con el sistema y que es ext
erno al sistema.
Ingeniería de requisitos PRIMARIOS SECUNDARIOS Interactúan para lograr la func
ión requerida del sistema Dan soporte al sistema.
19. Ingeniería de requisitos
20.
* El objetivo del modelo de análisis radica en describir requeridos de i
nformación, funcionamiento y comportamiento para un sistema basado en computadoras
.
* Es una representación de los requisitos en un momento determinado.
* Los elementos del modelo los determina el método de modelado que se ut
ilice.
Ingeniería de requisitos
21.
* Elementos basados en escenarios
o Sirven como una entrada para la creación de otros elementos de m
odelado.
* Elementos basados en clases.
o Conjuntos de objetos que se manipula mientras un actor interac
túa con el sistema.
Ingeniería de requisitos
22.
* Elementos de comportamiento.
o El comportamiento de un sistema puede tener efecto sobre el di
seño que se elija.
o Un estado es cualquier forma de comportamiento observable.
o Las variables de estado indican la manera en que el estado se
manifiesta.
Ingeniería de requisitos
23.
* Elementos orientados al flujo.
o La información se transforma mientras fluye a través de un sistema
.
o Es posible crear un modelo de flujo para un sistema sin que im
porte su complejidad.
Ingeniería de requisitos
24.
* Representan algo dentro del dominio de aplicación que puede reutilizar
se al modelar muchas aplicaciones.
* Se pueden encontrar en casi cualquier actividad de la vida diaria.
Ingeniería de requisitos PLANTILLA Nombre del patrón Intención Motivación Fuerzas
y contexto Solución Consecuencias Diseño Usos conocidos Patrones relacionados
 25.
* El objetivo es desarrollar un plan proyecto que satisfaga las necesi
dades del cliente.
Ingeniería de requisitos DIRECTRICES A CONSIDERAR Reconocer que no es una co
mpetencia Decidir que es lo que se desearía lograr No se debe pensar en formular u
na respuesta mientras la otra parte está hablando Enfocarse en los intereses de la
otra parte No dejar que se vuelva personal Ser creativo Estar listo para pactar
. ACTIVIDADES A CONSIDERAR Identificación de los interesados clave en el sistema o
subsistema. Determinación de las condiciones 'ganadoras' de los interresados. Neg
ociación de las condiciones ganadoras para unirlas en un conjunto de condiciones d
el tipo ganar - ganar para todos los involucrados.
26.
* Los modelos de análisis se examinan para conocer que consistencia, omi
siones o ambigüedades portan.
* Cada requisito y modelo de análisis se validan como un todo contrastándo
los con las necesidades del cliente para asegurar que se construirá el sistema cor
recto.
Ingeniería de requisitos ASPÉCTOS DE LA VALIDACIÓN Válidez Consistencia Completitu
d Realismo
27.
* Ingeniería de software: un enfoque práctico Roger Pressman, VI edición, McG
rawHill.
* www.gris.det.uvigo.es/~jose/doctorado/re/
* www.lsi.us.es/docs/informes/LSI-2002-4.pdf
Ingeniería de requisitos
28. Ingeniería de requisitos
29. Ingeniería de requisitos