Term
| Subclasificación de Harker para los requisitos volátiles |
|
Definition
- Mutables / Cambiantes: por cambios en el entorno en el que opera la organización
- % de impuestos de retención en una nomina
- Emergentes: aparecen al incrementar la comprensión del cliente con el uso del sistema
- Consecuentes: como resultado de la introducción del sistema informatico
- Compatibles: la compatibilidad con otros equipos cambia al cambiar estos
- Si cambia una pasarela de pago, se deberá cambiar la parte del sistema que se comunica con ella
|
|
|
Term
| ¿Dónde se realiza el análisis de requisitos de los métodos agiles?¿Y en SCRUM? |
|
Definition
El análisis de requisitos se realiza en numerosas reuniones periódicas don participa todo el equipo de desarrollo y el experto de negocio.
- También pueden participar otros stakeholders que asesoran en el análisis
En el caso de SCRUM el análisis de requisitos se realiza en:
- El sprint planning
- El product backlog refinement
- El sprint review
|
|
|
Term
| En la gestión de requisitos, define que es una linea base e indica que implica una vez que se establece |
|
Definition
Linea base: es un conjunto de requisitos que han sido formalmente aceptados por todas las partes implicadas.
Una vez establecida, implica que los futuros cambios de los requisitos solo se pueden llevar a cabo por un proceso de gestion de cambios
- El proceso de gestion de cambios analiza el impacto de los cambios por medio de un grupo de control de cambios (GCC) formado por stakeholders clave, y se decide si se acepta o no
|
|
|
Term
|
Definition
Tipos:
- Estructuradas
- No estructuradas
Diferencias:
| No estructurada |
Estructurada |
| Interacción sistematica, sin preparación previa de la entrevista |
Su objetivo y contenido de preguntas se prepara previamente |
| Se utiliza al principio del proceso de capturar requisitos para tener una orientación general |
S eusa al avanzar en el proceso de capturar requisitos, una vez que se tiene una orientación general |
| Las preguntas deben ser generales, no deben profundizar en temas particulares |
Profundizan en temas particulares |
| Son realizadas por analistas experimentados y a ser posible, que sean conocedores del dominio |
No requiere ser un analista experimentado, pero si conocer el dominio |
|
|
|
Term
Indica para los métodos agiles cuando se realizan:
- La obtención de requisitos
- El análisis de estos
- Su validación
- Y el proceso de gestión de requisitos
También indícalo para SCRUM |
|
Definition
En los métodos agiles:
- La obtención de requisitos: es continua y usan a un experto del negocio involucrado en todo el proceso de desarrollo (proporcionado o acordado por el cliente)
- Deben tener en cuenta todas las fuentes de información
- El analisis de requisitos: se realizan numerosas reuniones periodicas donde participa todo el equipo de desarrollo y el experto del negocio
- Tambien pueden participar otros stakeholders que asesoren
- En la validación de requisitos: se realiza al final de cada iteración i.
- En la reunión se muestra la versión i obtenida del producto
- No hay un proceso formal de gestión de requisitos: el desarrollo es iterativo e incremental.
- Cualquier cambio en los requisitos se incluye para tratarlo en una iteración posterior
Para SCRUM, el analisis de requisitos esta presente en los siguientes eventos:
- Sprint planning
- Reuniones de grooming o refinamiento del product backlog
- Sprint review
|
|
|
Term
| Requisitos funcionales VS no funcionales |
|
Definition
Funcionales: describen la funcionalidad o servicios del software
- De usuario: descripciones de alto nivel del sistema o de que debe hacer este
- De sistema: describen los servicios con más detalle
No funcionales: suelen estar relacionados con las propiedades emergentes (fiabilidad, seguridad, usabilidad y otras características)
- Definen atributos globales
- Definen restricciones sobre el producto
- Definen el entorno donde opera el sistema
- Estandares, leyes o reglamentos
|
|
|
Term
| Clasificación de requisitos (Métrica V3) |
|
Definition
- Funcionales: representan funcionalidades del sistema a cubrir, usando casos de uso
- Rendimiento: definen limitaciones del software
- Establecen limites en el rendimiento
- Establecen los volumenes de información que el software trata
- De seguridad: define criterios de seguridad para garantizar la protección del sistema
- De implantación: relacionados con la formación, infraestructura e instalación para preparar y organizar los recursos necesarios para la implementación e instalación del sistema
- De disponibilidad del sistema
|
|
|
Term
| Actividades básicas del proceso de IR |
|
Definition
Obtener requisitos: los ingenieros de software trabajan con los clientes y usuarios finales del sistema para determinar que servicios debe proporcionar el sistema y sus restricciones
Análisis de requisitos
- Los agrupan por categorías y los organizan
- Se estudia cada requisito en relación al resto
- Se trasladan los requisitos de usuario a requisitos software
Negociaciones de requisitos
- Se clasifican en base a las necesidades de los clientes y se estudian los conflictos
- Se establecen prioridades
- Compromiso final sobre el conjunto de requisitos a implementar
Documentación: elaborar documento que define de forma completa, precisa y verificable los requisitos y el comportamiento del sistema
Verificación y Validación
- Verificación: cumple criterios de calidad
- Validación: se corresponde con las necesidades de los clientes y usuarios
Gestión de requisitos: comprender y controlar los cambios de requisitos |
|
|
Term
| Proceso IR: Kotonga y Sommerville |
|
Definition
[Gráfico]
1. Captura de requisitos: interacción de los stakeholders para recopilar requisitos
- Leer documentacion y normativa existente, y las especificaciones del sistema
2. Clasificación y ordenación requisitos: se cogen los requisitos recopilados no estructurados y se organizan en grupos coherentes
- Se analiza la calidad de los requisitos
3. Ordenación por prioridades y negociación requisitos
- Se organizan según prioridades
- Se resuelven conflictos a través de negociaciones
4. Refinamiento de requisitos: se realizan los modelos de analisis y prototipos relevantes |
|
|
Term
| Requisitos estables VS volátiles |
|
Definition
Estables: derivan de la actividad principal de la organización y están relacionados con el dominio del sistema
Volátiles: específicos de una instancia del sistema en un determinado entorno y para un cliente |
|
|
Term
| Clasificación fuentes de información |
|
Definition
Los stakeholders y las fuentes de información se pueden clasificar desde tres puntos de vista generales:
- De los stakeholders que interaccionan directamente con el sistema
- De stakeholders indirectos: personas o sistemas que no usaran el sistema directamente pero que influyen en los requisitos
- Fuentes del dominio: representan características y restricciones del dominio que influyen en el sistema
|
|
|
Term
| Metodologías tradicionales VS métodos agiles |
|
Definition
| Metodologías tradicionales |
Métodos agiles |
| Basadas en normas que vienen de estandares que deben ser seguidos por el equipo |
Basadas en la experiencia en el desarrollo de proyectos software |
| Impuestas externamente |
Generalmente impuestas internamente |
| Proceso mas controlado con muchas politicas y normas |
Proceso menos controlado |
| El cliente interactua con el equipo de desarrollo en reuniones |
El cliente o experto es parte del equipo de desarrollo |
| Muchos roles |
Pocos roles |
| La ingenieria del software es esencial y se realizan numerosos modelos |
Menos enfasis en la ingenieria del software |
| Cierta resistencia al cambio |
Especialmente preparado para cambios en el proyecto |
| RUP, CMMI, METRICA... |
SCRUM, XP, FDD... |
|
|
|
Term
| Utilidad del modelado con casos de uso UML desde el punto de vista de la ingenieria de requisitos |
|
Definition
Los diagramas de caso de uso documentan el comportamiento del sistema desde el punto de vista del usuario. Es decir, representan funcionalidades del sistema.
Este modelado permite al analista y a su equipo:
- Conocer mejor el funcionamiento de algunas funcionalidades
- Detectar posibles ausencias en los requisitos obtenidos
- Refinar los requisitos.
En la descripcion de los casos de uso hay que indicar que requisitos satisface para poder realizar la trazabilidad del sistema
Ventajas
- Faciles de interpretar
- Utiles en la comunicacion con el cliente
Inconvenientes:
- No validos para representar requisitos no funcionales
- Requieren conocimientos de modelado UML por parte del equipo de desarrollo software
|
|
|
Term
| ¿Cuando debe parar de obtenerse requisitos? |
|
Definition
No podemos saber cuando se han identificado todos los requisitos. De hecho, siempre pueden surgir nuevos.
En la practica se termina cuando existe cierta certeza de una definición correcta, basada en opiniones positivas del cliente/usuarios y ralentización considerable del ritmo de obtención
|
|
|
Term
|
Definition
Ambigüedad: tiene que tener una única interpretación
Correcto: dominico correcto, gramática correcta...
Completos: tienen que tener la información para ser entendidos
Verificables
Viable: si tenemos los recursos para llevarlo a cabo
Trazables: identificador único
Bien organizada
No redundante: cada requisito se expresa en un solo lugar de la ERS
Preciso: si utiliza constantes para los valores numericos
Independiente del diseño: no puede traer cosas como formulario, campo...
Conciso: cada requisito debe expresar una sola idea o funcionalidad
Consistentes: que no se contradiga con nada |
|
|
