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