ITSTB

Fundamentos de ing. Del software

Ingeniera de requisitos

FUNDAMENTOS DE INGENIERIA DEL SOFTWARE

TAREAS DE LA INGENIERIA DE REQUISITOS DEL SOFTWARE

ADQUISICIN DE REQUISITOS
Los usuarios descubren, revelan, articulan y comprenden los requisitos que desean. La primera tarea de la Ingeniera de Requisitos es averiguar y enumerar las necesidades del usuario, tratando de evitar (segn Christel y Kang) los siguientes tres tipo de problemas: Problemas de alcance (p.ej. no entender las restricciones del sistema). Problemas de comprensin (p.ej. no entender el dominio del problema). Problemas de volatilidad (por cambios de opinin del usuario).

 Puede calificarse cmo proceso social Se utilizan tcnicas diversas: entrevistas, reuniones, grupos de trabajo, equipos de discusin, prototipos, etc. Se basa en comprender cuatro dimensiones: Dominio de aplicacin Problema a resolver Necesidades y restricciones de los stakeholders (usuario en sentido amplio: todos los agentes implicados en el sistema a construir) Contexto organizativo El resultado es un documento que contiene esencialmente una lista (y que se suele denominar SRS: Software Requirements Specification, es decir, documento de especificacin).

ANLISIS Y NEGOCIACIN DE REQUISITOS

Anlisis: En general, hay que comprobar que cada requisito sea:
1.- CONSISTENTE 2.- NO AMBIGUO 3.- VIABLE 4.- ABSTRACTO 5.- RASTREABLE 6.- VERIFICABLE 7.- NECESARIO 8.- COMPATIBLE

(Las propiedades 1, 2, 4, 5 y 8 son exigidas por el estndar IEEE std. 830-1984: Guide to Software Requirements Specifications). Negociacin: Despus definir requisitos hay que aplicar un procedimiento iterativo de negociacin ANALISTA-USUARIO para: - Eliminar requisitos - Modificar requisitos - Combinar requisitos

ESPECIFICACIN O DOCUMENTACIN DE REQUISITOS

Se considera esta actividad cmo la responsable de obtener una lista depurada de requisitos, una vez obtenida la lista en bruto y una vez analizada y resueltos los conflictos. Existen guas para este documento, cmo la de IEEE Std 1233. Una vez definidos los requisitos hay que documentarlos textual y/o grficamente (mediante modelos, UML por ej.). Se pueden utilizar plantillas para ello.
IDENTIFICADOR

Ej. RQ-001 Ej. 1.0 (05/11/2001) Ej. Juan Garca Nombre del usuario que lo proporcion Funcional, de seguridad, tcnico, de datos, de interfaz, ... Texto o redaccin del requisito Muy alta, alta, media, baja, ... .......

VERSIN AUTOR FUENTE TIPO DESCRIPCIN PRIORIDAD COMENTARIOS

VALIDACIN DE REQUISITOS
Confirmacin, por parte del usuario, de la validez de los requisitos. Se trata de examinar las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigedades, sin inconsistencias, sin omisiones; que los errores detectados han sido corregidos y que la especificacin se ajusta a los estndares establecidos.

Se puede utilizar la misma lista de comprobacin que durante el anlisis de requisitos.

MODELIZACIN O ESPECIFICACIN DE REQUISITOS

Consiste en construir un modelo (o varios) del sistema a construir, desde el punto de vista de su uso (interaccin usuario-sistema) que recoja todos y cada uno de los requisitos de la lista. Adems del documento, se parte del dominio que se modela, el Universo del Discurso (UoD) Aspectos a tener en cuenta: Modelizacin conceptual. Modelizacin de empresas. Modelizacin de requisitos funcionales. Modelizacin de requisitos no funcionales.

Ingeniera de requisitos

Tcnicas de la Ingeniera de Requisitos

Entrevista
Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que propone el analista. La estructura de las entrevistas vara. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una seccin de preguntas y respuestas libres. ABIERTAS: Las entrevistas abiertas, en las cuales no se preparan preguntas concretas, y, por el contrario, se discute con el entrevistado las expectativas que este tiene del sistema CERRADAS: Donde el entrevistador (ingeniero de requerimientos) prepara un conjunto de preguntas antes del encuentro con el entrevistado, y se buscan respuestas para las preguntas formuladas.

Encuesta.
Proporcionan una alternativa muy til para la entrevista; si embargo, existen ciertas caractersticas que pueden ser apropiada en algunas situaciones e inapropiadas en otra. Mediante ellas se obtiene una gran cantidad de informacin adecuada a travs del usuario. Existen preguntas abiertas y cerradas.

Observacin
Consiste en observar a las personas cuando efectan su trabajo. Permite al analista determinar que se est haciendo, como se est haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dnde se hace y por que se hace. Maneras de llevar a cabo una observacin: Directamente Indirectamente

JAD
Es una tcnica de definicin de requisitos y de diseo de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunin los temas a tratar se centran ms en el negocio que en el asunto tcnico. Lgicamente est ms orientado a proyectos de cliente (o bien sistemas a medida, como tambin se les conoce), y permite recolectar requisitos eficientemente. Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa realidad en cuanto al progreso del proyecto o la productividad.

Casos de uso y/o escenarios.

Los casos de uso describen interacciones entre los usuarios y el sistema, enfatizando en lo que el usuario necesita del sistema. Un caso de uso describe la posible secuencia de interacciones que se dan entre el sistema y uno o ms actores como respuesta a un estmulo inicial por parte de alguno de los actores De igual manera, debe ser incluida dentro de esta interaccin, la descripcin de las variantes y extensiones que el sistema debe soportar. Los casos de uso representan los requerimientos funcionales del software y pueden ser utilizados dentro de las primeras etapas del proceso de desarrollo.

Prototipos
Un prototipo es programa de computador que implementa algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar con la definicin de los requerimientos, o para facilitar la evaluacin de alternativas de implementacin de un sistema. Existen dos grandes tipos de prototipos. NO FUNCIONALES o DESECHABLES (Throw away), que sirven para entender la dificultad y aclarar los requerimientos. FUNCIONALES o EVOLUTIVOS (Evolutionary) que permiten construir una aproximacin del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo.

Lluvia de ideas.
Es una tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas en un ambiente libre de crticas o juicios. Las sesiones suelen estar formadas por un nmero de cuatro a diez participantes, uno de los cuales es el jefe de la sesin, encargado ms de comenzar la sesin que de controlarla. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas

FODA
(Fortalezas, Oportunidades, Debilidades y Amenazas)
Permite conformar un cuadro de la situacin actual de la empresa u organizacin, permitiendo de esta manera obtener un diagnstico preciso que permita en funcin de ello tomar decisiones acordes con los objetivos y polticas formulados. FODA nos va a ayudar a analizar nuestra empresa siempre y cuando podamos responder tres preguntas: Lo que estoy analizando, es relevante? Est fuera o dentro de la empresa? Es bueno o malo para mi empresa?

Modelado de requisitos

Los requisitos funcionales que tiene la aplicacin, mostrndose tambin los diferentes subsistemas de la aplicacin mediante el diagrama de paquetes