View
243
Download
0
Category
Preview:
DESCRIPTION
Es documento es importante para Ingenieria de Software Aqui les dejo un pequeño aporte quisas les interese .
Citation preview
NOVIEMBRE-2014
MAESTRÍA EN INGENIERIA DE SISTEMAS E INFORMÁTICA
Mg. Raúl Chiquillán Salcedo
Participación del usuario
Estudio de factibilidad
Obtención y análisis Especificación Validación
Requerimientos del usuario
Retroalimentación del usuario
Especificación de requerimientos
Modelos a validar por el usuario
Modelo de requerimientos Conocimiento
Necesidad de más conocimiento
Resultado de validación
} Es el proceso de elaboración, refinamiento y organización de requerimientos dentro de un documento.
} La especificación de requerimientos es responsabilidad primaria del analista, pero puede involucrar a los usuarios quienes verifican la documentación de requerimientos y a los proveedores quienes utilizan esta documentación para producir el software.
Documentar los
requerimientos de usuario
Verificar las necesidades del usuario
Documentar los
requerimientos de software
Verificar los requerimientos
de software
Especificaciones de requerimientos
1. Documentar los requerimientos de usuario ◦ Documentar los requerimientos desde el punto de
vista del usuario en el documento de requerimientos.
◦ Describir las características y comportamiento del sistema propuesto desde el punto de vista del usuario
◦ Esta descripción actuará como puente entre las necesidades del usuario y la especificación de requerimientos de software.
2. Verificar las necesidades del usuario ◦ Chequear que los requerimientos de usuario
describan que es lo que las necesidades del usuario hacen con el sistema.
◦ Asegurar que los requerimientos se derivan de los requerimientos del negocio (ej. visión del producto, metas y objetivos del proyecto).
◦ Los stakeholders deben chequear que los requerimientos sean completos, consistentes y de alta calidad.
◦ Revisar la documentación cuantas veces sea necesario.
3. Documentar los requerimientos ◦ Guardar los requerimientos en un programa
(RequisitePro) de administración de requerimientos
◦ Escribir el documento de especificación de manera que sirva al equipo de desarrollo (proveedores del software).
◦ Describe los requerimientos funcionales, atributos de calidad, interfaces de sistemas, y limitaciones de diseño e implementación (constraints).
4. Verificar los requerimientos ◦ Asegúrese de que la documentación describe
correctamente las capacidades y características del sistema.
◦ Chequear que los requerimientos de software han sido precisamente derivados desde los requerimientos de usuario, requerimientos del sistema y otras fuentes.
◦ Asegúrese de que la documentación y especificación de requerimientos proveen las bases adecuadas para proceder con el diseño, construcción y pruebas.
1. Introducción a. Propósito b. Convenciones del documento c. Alcance d. Referencias
2. Descripción General a. Perspectivas del producto b. Interesados del producto y usuarios c. Carácterísticas del producto
d. Documentación del usuario e. Restricciones de diseño e implementación f. Asunciones y Dependencias
3. Requerimientos funcionales a. Característica 1 b. Característica 2 c. Característica 1 d. …. e. …. f. Característica n
4. Requerimientos de interfaz externa a. Interfaz de usuario b. Interfaz de hardware c. Interfaz de software
5. Atributos de Calidad 6. Anexos
a. Glosario b. Modelos de análisis c. Matriz de trazabilidad
} Completa: describe todas las necesidades relevantes para los stakeholders
} Consistente: carece de conflictos entre requisitos } Correcta: todo es pertinente y no contiene errores } Modificable: facilidad para efectuar cambios de forma
sencilla, completa y consistente } Verificable: existencia de un proceso acotado que determine
si el sistema final satisface el requisito } Trazable: el origen del requisito está marcado de forma clara;
y se puede seguir el impacto del requisito a lo largo del SDLC } Clara y no ambigua: una única interpretación
} Tamaño del requisito: ◦ El justo, ni muy breve ni muy largo ◦ Tamaño medido en caracteres, palabras, párrafos
} Legibilidad: ◦ La máxima posible ◦ Procesadores como MS Word miden la legibilidad de los textos
} Tiempo verbal: ◦ Imperativo en lugar de condicional
} Modo verbal: ◦ Activa en lugar de pasiva
} Sentencias opcionales y especulativas: ◦ Evitar sentencias del estilo “quizá…” , “posiblemente…”, “usualmente…”, “casi
siempre…” } Expresiones ambiguas: ◦ Evitar expresiones del estilo: “rápido”, “amigable”…
} Sentencias subjetivas: ◦ Evitar sentencias del tipo: “yo creo…”, “en mi opinión…”
} Conectores: ◦ El abuso de conectores puede indicar que se está incluyendo más de una necesidad
en el mismo requisito ◦ También puede indicar un exceso de detalle
} Negaciones: ◦ Más de una palabra negativa en la misma frase podría hacerla difícil de entender
} Sentencias incompletas: ◦ Evitar sentencias del tipo “etcétera…”, “…entre otros…”, “…”
} Términos propios de diseño o de flujo: ◦ Evitar términos que denotan diseño como por ejemplo “clave ajena”, “tabla hash”…
} Número de términos del dominio: ◦ Un exceso de términos del dominio puede indicar que se están mezclando diferentes
necesidades en el mismo requisito ◦ También puede indicar que se está dando un excesivo detalle
} Número de verbos principales (del dominio): ◦ Un exceso de verbos del dominio puede indicar que se están mezclando diferentes
necesidades en el mismo requisito ◦ También puede indicar que se está dando un excesivo detalle
} Acrónimos y abreviaturas: ◦ Sólo permitidos si están definidos en alguna sección del documento de requisitos
} La información sobre los metadatos de los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios
} La información sobre los metadatos de los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios ◦ Evite el tiempo condicional ◦ Sustitúyalo por el imperativo
} La información sobre los metadatos de los usuarios deberá almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios
} La información sobre los metadatos de los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios
} La información sobre los metadatos de los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios ◦ Los requisitos de usuario debería evitar detalles propios de
diseño } La información sobre los metadatos de los usuarios
deberá almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios en el sistema
} El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente
} El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente ◦ La opcionalidad debe expresarse mediante un atributo, y nunca
como texto dentro del requisito ◦ Deberá usar un requisito individual para cada necesidad. Muchos
verbos concentrados en un requisito pueden implicar la mezcla de diferentes necesidades
} El Administrador deberá ser capaz de añadir usuarios } El Administrador deberá ser capaz de borrar usuarios } El Administrador deberá ser capaz de mostrar usuarios } El Administrador deberá ser capaz de actualizar usuarios } El Administrador podrá generar un informe para enviarlo por e-mail
al cliente
} El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser amigable y rápido para el usuario
} El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser amigable y rápido para el usuario ◦ Términos como ‘amigable’ y ‘rápido’ son difíciles de medir
y, por lo tanto, imposible de probar de forma correcta ◦ Utilice unidades físicas para medir cómo de rápido debe
rendir un requisito
} El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser amigable y rápido para el usuario ◦ Términos como ‘amigable’ y ‘rápido’ son difíciles de medir
y, por lo tanto, imposible de probar de forma correcta ◦ Utilice unidades físicas para medir cómo de rápido debe
rendir un requisito ◦ Utilice acrónimos sólo cuando estén comúnmente
aceptados por todos los interesados
} Los clientes podrán remitir órdenes por Internet. Estas órdenes deben incluir fecha de envío y cantidad de artículos. Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente. Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768
} Los clientes podrán remitir órdenes por Internet. Estas órdenes deben incluir fecha de envío y cantidad de artículos. Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente. Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768
} El sistema debe ser capaz de terminar el proceso de rastreo sin sobrecargar excesivamente el servidor
} El sistema debe ser capaz de terminar el proceso de rastreo sin sobrecargar excesivamente el servidor
} El sistema debe ser capaz de terminar el proceso de rastreo en un tiempo inferior a 2 segundos y sin que el proceso sobrepase los 250 MB de memoria
NOVIEMBRE-2014
MAESTRÍA EN INGENIERIA DE SISTEMAS E INFORMÁTICA
Mg. Raúl Chiquillán Salcedo
} Consiste en actividades de detectar y corregir cualquier requisito innecesario e incorrecto
} “Proceso de comprobación de que estos requisitos fueron especificados de acuerdo a las necesidades de los clientes”
} Evita el riesgo de realizar una mala implementación
documentar los requerimientos
del usuario
Verificar las necesidades del
usuario
Documentar los requerimientos de
software
Verificar los requerimientos de
software
actividades de desarrollo de
requerimientos
1. Seleccionar e integrar las técnicas de validación de requerimientos ◦ Identifique la técnica de validación mas
apropiada ◦ Escoger una combinación de técnicas,
diferentes técnicas para diferentes representaciones y partes de los requerimientos ◦ Validar los requerimientos de alto riesgo a
inicio del proceso, para reducir los riesgos generales ◦ Integrar las actividades de validación a
través del desarrollo de requisitos
2. Asegurar la participación del usuario ◦ Verificar que los requerimientos del
usuario describan la forma en que interactúan con los usuarios ◦ Los interesados comprueban que los
requisitos estén completos, consistentes y sean de alta calidad (Revisar la documentación) ◦ Asegúrese que los requerimientos
funcionales provienen de los requerimientos del negocio.
3. Valide los requerimientos ◦ Implica comprobar que un
subconjunto de los requisitos estén bien definidos, esto se lo debe realizar a principios del desarrollo de los requisitos y no cuando se tenga el detalle de los modelos de análisis.
4. Revisar la documentación de requerimientos ◦ Revisar la documentación basados
en la retroalimentación de la etapa anterior ◦ Realizar el análisis de los
requisitos para saber cómo los cambios afectan al proyecto ◦ Priorizar algún requerimiento que
cambie, a causa de las actividades de validación ◦ Repetir el ciclo a medida que
avanza el proceso de desarrollo de requerimientos
Recommended