2. UNIVERSIDAD FERMIN TORO
DECANATO DE INGENIERÍA
ESCUELA DE INGENIERÍA EN COMPUTACIÓN
CABUDARE VENEZUELA
Alumno:
• Moises Piñate
Tutor:
• Edecio Freitez
Diseño de software.
SAIA A.
Requerimientos de sistemas y desarrollo de prototipos
3. Requerimientos:
Los requerimientos, representan las características que un sistema a diseñar debe de poseer y a su
vez son puntos o características que el cliente indica de acuerdo a parámetros que el cree
necesarios para el sistema.
En la ingeniería de software los requerimientos son de suma importancia para el
diseño y desarrollo del sistema.
Obtención Análisis
Da como resultado una
especificación del sistema
que el cliente comprende
Da como resultado un
modelo de análisis que los
desarrolladores pueden
interpretar sin ambigüedad
4. ¿Cómo se obtienen los requerimientos?
Clientes
Usuarios
Herramientas
ProgramadoresSon las personas u
organizaciones
que negociaran
con el equipo de
desarrollo el
software a diseñar.
Son las personas
que conocen o
tendrán la labor de
interactuar
directamente con
el software
Son utilidades que
nos permiten
recolectar los
datos necesarios
en determinadas
situaciones
Personas
experimentadas
en el diseño del
software. Conocen
poco sobre el
entorno en donde
funcionara el
software
Casos de uso
Escenarios
A través de
A través de A través de
A través de
5. Los requerimientos
Provienen de
Clientes UsuariosProgramadores Herramientas
Identifican y definen
AREAS DE
PROBLEMAS
Especificación del
sistema
Características que tendrá el
sistema.
Esta definida por el contrato
entre el cliente y el equipo de
desarrollo
Los requerimientos nos proporcionan datos sobre las
limitaciones que poseerá nuestro sistema. Estas limitaciones
nos permitirán desarrollar diferentes etapas del sistema y
comprobar si cumplen las especificaciones solicitadas por el
cliente
Una vez los requerimientos se encuentren definidos
entre ambas partes (cliente-programador). Se procede
con el desarrollo de las etapas:
• Funcionalidad del sistema
• Interacción usuario-
sistema
• Errores que el sistema
puede detectar y manejar
• Condiciones ambientales
de funcionamiento
6. Requerimientos
Tipos de Requerimientos
Funcionales No funcionales
Describen las interacciones
entre el sistema y su
ambiente, en forma
independiente a su
implementación
Describe aspectos del
sistema visibles por el
usuario que no se
relacionan en forma directa
con el comportamiento
funcional del sistema.
Incluyen restricciones
cuantitativas como tiempo
de respuesta o precisión.
Ambiente: Se refiere al usuario y
cualquier otro sistema externo con
que interactúe el sistema
Validación de
Requerimientos
Especificaciones
Correcta
Completa
Consistente
No ambigua
Realista
Si representa la visión del cliente
Si se describen todos los escenarios
posibles que hay en el sistema
Si no se contradice así misma
Si no tiene más de una interpretación
Si el sistema puede implementarse dentro
de esas restricciones
7. Prototipo
Producto imaginario con el cual los usuarios pueden interactuar. Estos
pueden estar construidos en papel, un software complejo del sistema o
simplemente mediante una maqueta del sistema.
¿Porque se debe utilizar un prototipo?
Visualización de
errores
Retroalimentación Factibilidad
Vistas previas al
cliente
Al someter el prototipo a
condiciones similares a
su ambiente de trabajo.
Se pueden observar los
posibles errores del
funcionamiento del
sistema.
Al observar el
comportamiento del
prototipo, se logra una
retroalimentación del
equipo de trabajo y se
toman acciones para el
siguiente modelo
de sistema
Nos proporcionan
datos relevantes
sobre la factibilidad
técnica y operativa
del sistema en
desarrollo
Los prototipos nos
proporcionan ayuda el
momento de presentar
ideas al cliente. Y al
momento de discutirlas
para efectuar cambios
durante el
desarrollo
8. Ventajas y Desventajas del prototipo
• Son reales y tangibles
• Permite al cliente aclarar lo que quiere que
haga el sistema.
• Siente que es oído y tenido en cuenta para el
diseño.
• Asegura que el trabajo se está haciendo bien y
cumpliendo los requerimientos del cliente.
Ventajas Desventajas
• El cliente puede creer que el sistema ya está
listo y pedir su entrega rápida.
• Crea expectativas más allá de lo que realmente
puede hacer.
• Se dificulta la dirección y control del proceso
de desarrollo más que en el método clásico.
• La presión por entregar rápido el producto
compromete la calidad.
• Se dificulta mantener el entusiasmo del cliente
después de aprobado el prototipo porque
creerá que se desperdicia el tiempo en detalles
insignificantes.