El documento habla sobre los requerimientos de sistemas y el proceso de ingeniería de requerimientos. Explica que los requerimientos son características que debe tener un sistema para ser aceptado por el cliente y son obtenidos a través de herramientas como escenarios y casos de uso. También describe los tipos de requerimientos funcionales y no funcionales, y los pasos para validar y especificar requerimientos como parte del proceso de ingeniería de requerimientos.
2. El requerimiento de un sistema es aquella
característica que debe tener el sistema. Es una
restricción que debe satisfacer para que sea aceptado
por el cliente.
Este requerimiento viene desarrollado a partir de la
ingeniería de requerimientos
•Obtención: Da como resultado una
especificación del sistema que el
cliente comprende
•Análisis: Da como resultado un
modelo de análisis que los
desarrolladores pueden interpretar sin
ambigüedad
3. Son obtenidos por
Programadores:
•Experiencia en el desarrollo
de sistemas
•Muy poco conocimiento del
ambiente de los usuarios
Se obtienen
A través de
Herramientas
Escenarios
Los requerimientos
Casos de uso
Uso del sistema
mediante
interacciones
usuario-sistema
Abstracción que
describe una
clase
de escenarios
De
•Clientes
•Usuarios
•Expertos en sus
dominios
•Tienen una idea
general de lo que debe
hacer el sistema
•Muy poca experiencia
en el desarrollo del
software
4. Clientes Usuarios Programadores
Identifican
Área problema
Definen
Sistema
Requerimientos
•Funcionalidad del sistema
•Interacción usuario-sistema
•Errores que el sistema puede detectar y manejar
•Condiciones ambientales de funcionamiento
5. Tipos de requerimientos
Funcionales
Describen las interacciones entre el
sistema y su ambiente, en forma
independiente a su Implementación
Ambiente: Se refiere al usuario y cualquier
otro sistema externo con que interactúe el
sistema
No Funcionales
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.
6. La validación de requerimientos involucra la revisión de
Especificaciones:
Correcta
Si representa la visión
del cliente
No es ambigua
Si no tiene más de una
interpretación
Realista
Si el sistema puede implementarse
dentro de esas restricciones
Consistente
Si no se contradice a sí
misma
Completa
Si se describen todos los escenarios
posibles que hay en el sistema
7. Propiedades de las
Especificaciones:
Verificable
Si una vez que se construye el
sistema puede diseñarse una prueba
repetible para demostrar que el
sistema satisface los requerimientos
Rastreable
Si cada función del
sistema puede rastrearse
hasta su conjunto de
requerimientos
correspondientes
8. Categorías de la obtención de requerimientos
Ingeniería a partir de 0
No existe un sistema anterior
y los requerimientos se
extraen de los usuarios y el
cliente
Ingeniería de interfaz
Es el rediseño de la interfaz
de usuario de un sistema
existente
Reingeniería
Es el rediseño y de
implementación de un
sistema existente activado
por los coordinadores de
tecnología o por un nuevo
flujo de información
9. Producto imaginario con el cual los usuarios pueden
interactuar
Basados en papel
Software complejo
Maqueta
Animación y demostración de los requerimientos del
sistema
10. •En la mayoría de los casos los usuarios no saben decir que es lo que
quieren, pero si ven algo y lo usan, descubren que es lo que quieren
•Son muy útiles como ayuda cuando se discuten ideas con los clientes o
usuarios ideas con los clientes o usuarios
•En el proceso de desarrollo se construyen prototipos para poder
interactuar con varias versiones que permiten a los diseñadores
Estudiar la factibilidad técnica
Clarificar requerimientos borrosos o vagos
Comprobar que cierto diseño es compatible con el resto del
sistema
11. Escenario
Simulación del uso del
sistema
Demostración
Porción de código que
realizan algunas funciones
Versión 0
Aplicación liberada que puede usarse bajo
condiciones preliminares añadiendo, cambiando
o quitando funciones existentes y creándole su
documentación
12. Ventajas
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.
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.