LOGO SERVIBANCA Standard Documento Requisitos Versión X.X Estándar documentos de requisitos – versión 0.1 SERVIBANCA Estándar documentos de requisitos Este documento esta destinado a capturar los requerimientos capturados desde el cliente debido al resultado de las entrevistas, encuestas, estudios y prototipeo con él. 1.1 captura de requisitos de usuarios Aun cuando los requerimientos de los usuarios se originan a partir de sus percepciones propias acerca de sus necesidades, es necesario especificar estos requerimientos, a través de experiencias anteriores con otros softwares. Es necesario poder llegar al mejor acuerdo con el cliente a través de entrevistas y encuestas. El proceso de captura de requerimientos es un proceso iterativo, y las actividades para capturar los requerimientos deben ser repetidas varias veces antes de que el documento de requerimientos de usuario este completa. 1.2 determinación ambiente operacional Determinar el ambiente operacional debiera ser el primer paso en la definición de los requerimientos del usuario. Debe quedar claro en que contexto del mundo real el software deberá operar, esta descripción narrativa puede ser soportada por diagramas. Así también debe especificarse la interacción con sistemas externos que puedan verse involucrados en la futura operación del software. 1.3 especificación de los requerimientos de usuario Cuando el ambiente operacional ha sido establecido, los requerimientos del usuario son extraídos y organizados. 2 ________________________________________ Estándar documentos de requisitos – versión 0.1 SERVIBANCA Estándar documentos de requisitos – versión 0.1 SERVIBANCA Consideraciones acerca de implementación serán omitidas, a menos que ellas sean un requerimiento en si. 1.3.1 Clasificación de los requerimientos de usuario. Los requerimientos de usuario caben en 2 categorías: Requerimientos de capacidad Requerimientos de Restricciones Capacidades necesitadas por el Restricciones puestas por el usuario usuario para solucionar un en como el problema será resuelto o problema o alcanzar objetivos. el objetivo alcanzado. Requerimientos de capacidad describen funciones y operaciones necesitadas por el usuario. Definiciones de cantidad y precisión deberían formar parte de las descripciones de las especificaciones de de una función que se desee realice el sistema. Los requerimientos de restricción ponen límites en la manera que el software debe ser construido y operado. Por ejemplo, definiciones de comunicaciones con sistemas externos, interfases de programas que ya pueden existir, ya sea por que el software pertenece a un sistema más grande, o por que el usuario necesita que ciertos protocolos, estándars, computadores, sistemas operativos, librerías o kernels sean usados. Los requerimientos de interfases podrían variar de acuerdo al tipo de software que se esta construyendo. Para sistemas interactivos, el usuario puede querer definir ejemplos de cuadros de diálogos requeridos, incluyendo como debería ser manejado por el hardware (Ej.: Mouse, teclado, paneles, etc.) y la asistencia que debería proveer el software (Ej.: Ayuda en línea). Para sistemas batch, bastará con indicar los parámetros que se necesitan, el tipo de salida y formato de esta. Restricciones que el usuario quisiese colocar en el software incluyen la calidad de los atributos tales como adaptabilidad, disponibilidad, portabilidad y seguridad. El usuario debe describir las consecuencias que pueden generar las perdidas de disponibilidad, u hoyos de seguridad, para que el desarrollador pueda apreciar de manera precisa cuan critico es cada función que desarrolla. ________________________________________ Estándar documentos de requisitos – versión 0.1 3 SERVIBANCA Estándar documentos de requisitos – versión 0.1 SERVIBANCA 1.3.2 Atributos de requerimientos de usuario Cada requerimiento de usuario debe incluir los atributos listados abajo (a) Identificadores - cada requerimiento del usuario debe incluir un identificador, para facilitar su seguimiento en las subsecuentes etapas. (b) Necesidad – requerimientos de usuario esenciales deben ser marcados como tal. Requerimientos esenciales del usuario no son negociables; los otros pueden ser menos vitales y pueden ser objeto de negociación. (c) Prioridad – para entregas incrementales, cada usuario debe incluir una medida de prioridades para que el desarrollador pueda fijarse un orden de desarrollo. (d) Estabilidad – algunos de los requerimientos pueden saberse que serán estables durante la vida esperada del software; otros pueden depender de la respuesta de las siguientes fases de desarrollo, o pueden ser objeto a cambios durante el ciclo de vida del software. Aquellos requerimientos inestables deben ser marcados. (e) Fuente – la fuente de cada requerimiento de usuario debe ser especificada. Esto puede ser una referencia a un documento externo, (Ej.: documento de requerimientos de usuarios) o el nombre del usuario, o grupos de usuarios, que provean el requerimiento dado. (f) Claridad - un requerimiento de usuario debe ser tan claro que sólo posea una sola interpretación posible. Esto implica que no debe haber ambigüedad. Si un termino usado en un contexto particular tiene múltiples significados, el termino debe ser clasificado o reemplazado por otros mas específicos. (g) Verificabilidad – Cada requerimiento de usuario debe ser verificable. Esto significa que debe ser posible: - Chequear que el requerimiento ha sido incorporado al diseño - Probar que el Software implementará el requerimiento - Testear que el software implementa el requerimiento ________________________________________ Estándar documentos de requisitos – versión 0.1 4 SERVIBANCA