Requerimientosreq

Determinación de Requerimientos
Tabla de contenidos
3. Conceptos
a) Concepto.
b) Características,
c) Tipos de requerimientos.
5. Proceso de Determinación de requerimientos.

 Concepto.
 Fases.
 Características.
6. Metodología para la Determinación de requerimientos.
Ingeniería Software de Gestión.

Determinación de Requerimientos. Proceso de R.
1. Conceptos. Concepto
 Requisito/Requerimiento. Condición, Característica o Restricción que debe

tener o cumplir un sistema o componente de un sistema para satisfacer un
contrato, norma, especificación u otro documento formalmente impuesto.
 Ingeniería de Requerimientos. Disciplina de la ISW que se encarga de definir

los requerimientos del sistema. Fases:
1. Determinación de requerimientos.
3. Análisis de requerimientos.

1. Conceptos. Características.
Características que han de reunir los requisitos para ser de alta calidad.
 Correctos, sin errores.
 Consistentes.
 No ambiguos.
 Son completos:
1. Externamente completa si contiene todas las propiedades deseadas por el
cliente.
2. Internamente completa si no existen referencias no definidas.

1. Conceptos. Características.
 Son realistas. Puede el sistema hacer lo que el cliente desea.
 Los R. Describen algo necesario para el cliente.
 Verificables. Un requisito es verificable si existe algún proceso finito de coste

razonable que pueda probar que el producto software cumple con el requisito.
 Son rastreables. Trazables, el origen de cada requisito está claro y se posibilita

la referencia de cada uno de estos requisitos en desarrollos futuros o
incrementos de la documentación.

1. Conceptos. Tipos de Requerimientos.
 R. Funcionales. Una función es algo que hará el sistema. Describen una

interacción entre el sistema y su ambiente.
 R. No funcionales. Describen restricciones que limitan las opciones de

solucionar el problema. Restricciones cuantitativas o precisión.
 Seudorequerimientos. R. impuestos por el cliente que restringen la

implementación del sistema.

Especificación
1. Conceptos. Concepto Sistema
Determinación
Requerimientos
Obtención Documentación Validación
Cliente/Usuario
Desarrolladores

2. Determinación de Requerimientos. Concepto y Fases.
Proceso que tiene como objetivo capturar, documentar y condiciones o

características que debe cumplir un sistema dado: La especificación del sistema.
 Obtención de requerimientos. Captura de requerimientos con el objetivo de

definir que es el sistema.
 Documentación de requerimientos. Los requisitos han de reflejarse en un

documento como registro del proceso de captura con el objetivo de fijar una
base para clientes y desarrolladores.
 Validación. Es el proceso por el cual se determina si la especificación es consistente es

decir si los requerimientos satisfarán las necesidades del cliente.

2. Determinación de Requerimientos. Participantes en el proceso.
 Supervisores del contrato, sugieren hitos de control y cronogramas que disciplinan el

desarrollo del sistema.
 Clientes y usuarios, deben comprender y trasmitir adecuadamente los requerimientos,

para del sistema.
 Los gerentes de negocios, para calibrar el impacto de construir y utilizar el sistema.
 Los diseñadores que usarán los requerimientos como base del desarrollo.
 Los verificadores encargados de las sesiones de prueba destinadas a asegurar que el

sistema cumple los requerimientos.

2. Determinación de Requerimientos. Captura R.

1. Captura de Requerimientos.
1. Primera tarea
2. Fase critica. Colaboración de grupos heterogéneos.
Desarrollador Identifc.
Cliente/Usuario Actores
Actividades
Obtención Captura de
Requer. Requer.
Identifc.
Funcionalidad


Objetivos de la captura de requerimientos (OO):
 Identificación de actores. Entidades externas que interactúan con el sistema.

Como abstracción de papeles.
 Identificar la funcionalidad a la que tiene acceso cada actor.
 Identificación de escenarios. Descripción concreta, enfocada e informal de una sola

característica del sistema desde el punto de vista de un solo actor.
 Descripción de casos de uso.


Administración de la Captura de requerimientos:
 Fuentes:
 Documentación.
 Personas con puntos de vista necesarios.
 Técnicas
 Cuestionarios
 Entrevistas
 Talleres
 Prototipos


Fuentes.
 Análisis de Documentación.
Es imprescindible cuando:
 Introducción del sistema en infraestructuras existentes.
 Suplemento de funcionalidad ya disponible.
Documentación a analizar:
 Sobre las prácticas existentes de los usuarios.
 Sobre procedimientos de soporte.
 Sobre componentes técnicos.
 Sobre el modelo lógico
 Sobre los modelos de procesos y datos
 Sobre requisitos existente


Fuentes.
 Personas. Identificar personas con puntos de vista precisos para representar el conjunto
de los requerimientos:
5. Dirección general
6. Usuarios finales y dirección
7. Clientes
8. Proveedores
9. El equipo operativo
10. El equipo de mantenimiento
11. Asesoría jurídica u otros expertos.
 Importante contar con más de una persona por cada punto de vista.


Técnicas
4. Elaboración de cuestionarios.
1. Recomendable para grandes poblaciones (+30 personas).

2. Recomendable como base para posterior entrevista personal.
3. Crear un marco para el análisis de resultados. (visión clara de cómo utilizar
la información)
4. Comprobar que existe información suficiente en el personal “cuestionado”.
5. Garantizar que es comprensible (no utiliza argot técnico).
6. Probarlo antes de comenzar
7. Verificar la comprensión.


Tipos de cuestionarios:
 Para recopilar datos estructurados. 2 Modalidades:

1. Mediante Lista de cuestiones concretas y de respuesta cerrada.
 ¿Cuánto lleva operando el actual sistema de facturación (en años)?.
3. Mediante índices.
 ¿Importancia de estos factores para adquirir un OS?
Baja Alta
Velocidad 1 2 3 4 5
Usabilidad 1 2 3 4 5
Flexibilidad 1 2 3 4 5


Tipos de cuestionarios:
 Cuestionarios para recoger información abierta.
 Se formula una pregunta abierta.
 ¿Cuál son para usted los factores principales en la selección de proveedor de

servicios de Internet”
 Útiles para obtener una información inicial sobre el área.
 Importante evitar sesgos.

2. Determinación de Requerimientos. Técnicas captura.

Entrevistas
 Objetivo: Obtener toda la información posible de la visión que el entrevistado tiene de

los requisitos.
 Depende de la habilidad del entrevistador para crear un clima de confianza.
 Resulta útil planificar las entrevistas para evitar sesgos (evitar que un grupo incline a un
lado el proceso).
 Preparar un marco para la entrevista (mediante un cuestionario)
 Confirmar detalles del entrevistado
 Establecer la finalidad de la entrevista con el entrevistado
 Organizar una lugar adecuado.
 Confirmar los detalles por escrito.


Entrevistas:
 Es aconsejable 2 entrevistadores (una conduce la entrevista el otro supervisa la

interacción y toma notas):
 Mejora la gestión del tiempo.
 Beneficia la supervisión.
 Es aconsejable emplear tanto preguntas abiertas como cerradas:

 Abiertas: Suelen comenzar por “qué”, por qué” y “como” y exigen respuesta
detallada por el entrevistado.
 Cerradas: Aquellas con un Intervalo específico de respuesta.
 El entrevistador debe centrar la entrevista cuando esta se desvía.
 El entrevistador debe evitar emitir juicios de valor para no influir.


Entrevistas:
 Análisis de resultados de la entrevista:

 Si se ha utilizado como marco un cuestionario, este se utilizará como contexto e el
análisis.
 Si la entrevista no es estructurada, el resultado se detallará como informe.
Esquema de resumen de entrevista

Nombre entrevistado.
Puesto de trabajo y breve descripción.
Punto de vista que representa.
Fecha, hora y lugar de la entrevista
Resumen de puntos principales
Doc´s. de referencia
Otros contactos.


Talleres:
 Reunión de partes interesadas.
 Sesiones intensivas y estructuradas concentradas en uno o dos días.
 Es preciso una importante preparación previa:

 Definir con los participantes la finalidad del taller.
 Facilitarles información histórica.
 El taller ha de ser dirigido por un experto para:

 Garantizar que todo los participantes aportan sus puntos de vista.
 No se desvían del propósito del taller.


Talleres:
 Los requisitos capturados en el taller se registran junto con todas las cuestiones
y acciones resultantes.
 Se genera un informe para documentar los resultados y base de la

especificación de requisitos.
 Tiene la ventaja de reunir a los participantes pudiendo debatirse las cuestiones

más controvertidas y resolver así requisitos aparentemente divergentes
satisfaciendo a las partes.


Modelado de proceso:
 Método de análisis vertical (up-dow) para establecer la composición funcional del area
para la cual se propone el sistema.
Proceso
Funciones Funciones Actividades
Actividades
Funciones Actividades
Actividades
Actividades

Modelado de proceso:
 Se descompone el sistema en procesos “atómicos” que no admitan mas

divisiones.
 La derivación de procesos se realizará mediante técnicas de captura de

requisitos.
 Los usuarios revisarán el modelo en cada desagregación.

 Permite correcciones antes de seguir con una mayor elaboración
 Permite identificar procesos de bajo nivel duplicados, permitiendo una
simplificación del modelo.


Prototipado:
 Un prototipo es un modelo de sistema eventual que se puede utilizar para demostrar las
características de lo que el sistema puede ofrecer. 2 métodos: P. desechable, P.
evolutivo.
 Los prototipos pueden usarse para:
 Demostrar la viabilidad del sistema. Se implanta parte del sistema para:

 Comprobar el comportamiento funcional.
 Análisis de rendimiento.
 Aclarar los requisitos del usuario.

2. Determinación de Requerimientos. Documentación.
 Los requisitos han de reflejarse en un documento como registro del proceso de captura.
 El objetivo de la documentación es servir de base para la futura operativa del proyecto

tanto para clientes como para desarrolladores.
 Por ello han de escribirse de modo que sean significativos para ambos.
 Así se generan dos documentos:
 Doc. De requisistos del usuario/Definición de requerimientos

 Doc. De requisitos del sistema/Especificación de requerimientos.


Doc. De Requisitos del Usuario/determinación de requerimientos.
 Listado completo de las cosas que el cliente espera que haga el sistema propuesto para
todas las categorías de usuarios (incluido el soporte operativo).
 Redactado de forma que el cliente pueda entenderlo. (con claridad, conciso y

congruente)
 Es generado entre cliente y desarrollador como documento de compromiso.
 Si el Documento recoge requisitos no funcionales se documentarán en términos

mensurables.


Elementos de la documentación:
 Se perfila el propósito general del sistema con referencias a otros sistemas relacionados
y un diccionario de términos y abreviaturas que puedan ser útiles.
 Descripción de antecedentes y objetivos del desarrollo.
 Si el cliente tiene un nuevo enfoque para describir el problema se recoge el enfoque y

sus restricciones o suposiciones si las hay.
 Se detallan se definen las características del sistema: Limites del sistema, interfaces,
lista clases y características, funciones y procesos con sus entradas y salidas y
finalmente requerimientos específicos de rendimiento.
 Requerimientos sobre soporte, seguridad y privacidad y cualquier restricción.


E. Requisitos del Usuario

Introducción
2. Alcance. Área de aplicación de los requisitos.
3. Definiciones.
4. Historial.
5. Descripción de alto nivel. Esquema del problema.
6. RF (Forma atómica y con identificador)
7. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
8. Restricciones específicas


Doc. De Requisitos del Sistema/especificación de requerimientos.
 Se desarrolla a partir del documento de requisitos del usuario.
 Cubre el mismo área que el documento de requisitos del usuario pero en los términos
técnicos adecuados para diseñar el sistema,
 Suele estar redactado por analistas de requerimientos.
 Se fundamenta en:
 El modelado del sistema, para esclarecer la funcionalidad del sistema.
 Restricciones sobre infraestructura.
 Requisitos Funcionales y no funcionales.


Doc. De Requisitos del Sistema/especificación de requerimientos.
E. Requisitos del Sistema

Introducción
2. Alcance. Relación con otros sistemas
3. Definiciones.
4. Historial. Infraestructura existente
5. Descripción de alto nivel. Esquema del problema.
6. RF (Forma atómica y con identificador)
7. RNF (Forma atómica y con identificador y
vinculados a los funcionales que soportan)
8. Restricciones específicas

2. Determinación de Requerimientos. Validación.
 La determinación de requerimientos tiene 2 propósitos:
 El acuerdo entre clientes y desarrolladores sobre qué debe ser el sistema.

 Proporcionar a los diseñadores pautas para el desarrollo.
 La validación de requerimientos es el proceso por el cual se determina si la

especificación del sistema es consistente, es decir si los requerimientos satisfarán las
necesidades del cliente. 2 pasos (trazabilidad):
 Se asegura que cada especificación del sistema pueda ser rastreada hasta su
requerimiento en el documento de definición.
 Se chequea la definición comprobando que cada requerimiento es rastreable hasta la
especificación.

 La técnica más utilizada y simple son las reuniones de revisión.
 Se examinan los requerimientos por parte de:
 Representantes del cliente:

 Operadores del sistema.
 Operadores que preparan las entradas
 Operadores los que utilizan las salidas
 Gerentes de estos empleados.
 Representantes del desarrollador:
 Equipo de diseño
 Equipo de pruebas, y gestión de configuración


 La reuniones comprenden las siguientes actividades:
 Se revisan las metas declaradas y los objetivos del sistema.
 Se comparan las metas con los requerimientos para verificar que todos estos son
necesarios.
 Se describe el ambiente en el que debe operar el sistema.
 Se evalúa y documenta el riesgo y se plantean alternativas.
 Se determinan las pruebas según avance el sistema.
 Cuando se detecta un problema se documenta y se establece la acción para

subsanarlo antes del comienzo del proceso de diseño.

 La trazabilidad de requisitos se documenta mediante la MTR (Matriz de trazabilidad de

Requisitos).
Matriz de Trazabilidad de Requisitos
Resumen de Requisito del Requisito del

requisitos del Usuario Sistema
Usuario
Identificador Identificador

Requerimientosreq

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Requerimientosreq

Enviado por

Direitos autorais:

Formatos disponíveis

Determinación de Requerimientos

5. Proceso de Determinación de requerimientos.

6. Metodología para la Determinación de requerimientos.

Ingeniería Software de Gestión.

 Requisito/Requerimiento. Condición, Característica o Restricción que debe

 Ingeniería de Requerimientos. Disciplina de la ISW que se encarga de definir

Ingeniería Software de Gestión.

 Correctos, sin errores.

Ingeniería Software de Gestión.

 Son realistas. Puede el sistema hacer lo que el cliente desea.

 Los R. Describen algo necesario para el cliente.

 Verificables. Un requisito es verificable si existe algún proceso finito de coste

 Son rastreables. Trazables, el origen de cada requisito está claro y se posibilita

Ingeniería Software de Gestión.

1. Conceptos. Tipos de Requerimientos.

 R. Funcionales. Una función es algo que hará el sistema. Describen una

 R. No funcionales. Describen restricciones que limitan las opciones de

 Seudorequerimientos. R. impuestos por el cliente que restringen la

Ingeniería Software de Gestión.

Obtención Documentación Validación

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Concepto y Fases.

Proceso que tiene como objetivo capturar, documentar y condiciones o

 Obtención de requerimientos. Captura de requerimientos con el objetivo de

 Documentación de requerimientos. Los requisitos han de reflejarse en un

 Validación. Es el proceso por el cual se determina si la especificación es consistente es

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Participantes en el proceso.

 Supervisores del contrato, sugieren hitos de control y cronogramas que disciplinan el

 Clientes y usuarios, deben comprender y trasmitir adecuadamente los requerimientos,

 Los gerentes de negocios, para calibrar el impacto de construir y utilizar el sistema.

 Los verificadores encargados de las sesiones de prueba destinadas a asegurar que el

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

 Identificación de actores. Entidades externas que interactúan con el sistema.

 Identificar la funcionalidad a la que tiene acceso cada actor.

 Identificación de escenarios. Descripción concreta, enfocada e informal de una sola

 Descripción de casos de uso.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

1. Recomendable para grandes poblaciones (+30 personas).

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

 Para recopilar datos estructurados. 2 Modalidades:

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Captura R.

 Cuestionarios para recoger información abierta.

 Se formula una pregunta abierta.

 ¿Cuál son para usted los factores principales en la selección de proveedor de

 Útiles para obtener una información inicial sobre el área.

 Importante evitar sesgos.

Ingeniería Software de Gestión.

2. Determinación de Requerimientos. Técnicas captura.

 Objetivo: Obtener toda la información posible de la visión que el entrevistado tiene de

 Depende de la habilidad del entrevistador para crear un clima de confianza.

Ingeniería Software de Gestión.