ingenieria de requisitos

24
INGENIERIA DE REQUISITOS Tema 2

Upload: carlos-suarez-andrade

Post on 18-Dec-2015

216 views

Category:

Documents


1 download

DESCRIPTION

Ingenieria de Requisitos Ian Sommerville

TRANSCRIPT

Diapositiva 1

INGENIERIA DE REQUISITOSTema 2Ingeniera de Requisitos (IR)Es la aplicacin de principios, mtodos, tcnicas y herramientas en pro del descubrimiento de los requisitos de un producto software; de igual manera, permite el anlisis y documentacin de los objetivos, funciones y restricciones de dicho sistema de computacinIngeniera de Requerimientos(definicin)Es el estudio de los requerimientos que se necesitan para que un sistema ofrezca un buen servicio y defina las limitaciones en su operacin. Esta fase ocupa un lugar importante en el proceso de desarrollo de software ya que si el personal comprometido no conoce con claridad los requisitos, corre el riesgo de que los resultados obtenidos no sean los esperados, presentando as los mismos problemas de hace cincuenta aos: altos costos, baja calidad de software, clientes inconformes e incumplimiento de plazos, entre otros.2.1 Tareas de la Ingeniera de requisitos

Planeacin,Levantamiento de informacin:Identificar fuentes de informacin (usuarios) relevantes para el proyecto y planificar las actividades de investigacin.Realizar las preguntas apropiadas para comprender sus necesidades.Analizar la informacin para detectar los aspectos que quedan poco claros.Determinacin de las caractersticas que debe cumplir el software:Confirmar con los usuarios lo que parece haberse comprendido de los requisitos.Sintetizar los requisitos en un documento de especificacin apropiado.

Las tcnicas de recoleccin de informacin surgen como un medio para mejorar la comunicacin entre los usuarios/clientes y los desarrolladores de software. Las tcnicas principales utilizadas para esta actividad son las siguientes:Entrevistas. Es quizs la tcnica mas empleada, aunque requiere una preparacin (y experiencia) por parte del analista. Es similar a una entrevista periodstica en la cual el desarrollador entrevista uno a uno a los futuros usuarios del software.

2.2. Tcnicas de la Ingeniera de RequisitosTcnicas, continuacinDesarrollo conjunto de aplicaciones (JAD). Se crean equipos de usuarios y analistas que se renen para trabajar conjuntamente en la determinacin de las caractersticas que debe tener el software para satisfacer las necesidades de los usuarios. Tiene una mayor probabilidad de xito, ya que involucra al usuario en el proyecto, que lo aprecia como algo propio. Una variante del JAD es el JRP (Planificacin Conjunta de Requisitos), donde se pretende un estudio estratgico de sistemas con participantes de un nivel ms alto en la jerarqua de la organizacin.Prototipado. Consiste en la construccin de un modelo o maqueta del sistema que permite a los usuarios evaluar mejor sus necesidades, analizando si el prototipo que ven tiene las caractersticas de la aplicacin que necesitan.Observacin. Consiste en analizar in situ cmo funciona la unidad o el departamento que se quiere informatizar. Aporta grandes ventajas sobre las otras tcnicas, ya que se pueden analizar mejor todos los detalles del proceso y se llega a captar el funcionamiento real de la empresa (que, a veces, no coincide con las normas oficiales), as como en el ambiente en el que se va a desarrollar el proyecto y se va instalar el futuro sistema.

Tcnicas, continuacinEstudio de documentacin. En casi todas las organizaciones existen documentos que describen el funcionamiento del negocio, desde planes estratgicos hasta manuales de operacin o de procedimientos. El analista debe estudiar esta documentacin para hacerse una idea de la normativa que rige la empresa. Tambin es conveniente que recopile muestras de impresos u otros documentos de trabajo (que deben estar necesariamente rellenados para constatar que se usan realmente y para apreciar cmo se emplean) que se utilizan ya que nos permiten conocer los datos que se manejan.Cuestionarios. Resultan tiles para recolectar informacin de un gran nmero de personas en poco tiempo, especialmente en situaciones en las que se da una gran dispersin geogrfica. Para que resulten operativos deben ser necesariamente concisos y centrados en unos pocos aspectos del sistema, breves para no cansar, con una redaccin clara y definitiva, combinando preguntas cerradas y abiertas segn lo que deseamos averiguar y con una introduccin que explique el propsito del cuestionario y que agradezca la colaboracin de quien responde.Tormenta de ideas. Algunos autores proponen la utilizacin de este tipo de tcnica como medio para identificar un primer conjunto de requisitos en aquellos casos en los que no estn muy claras todas las necesidades que hay que cubrir, normalmente por falta de tradicin informtica o de referencias de aplicaciones similares a la que se desea. Se trata de reuniones de cuatro a diez personas (usuarios o tcnicos) donde, en una primera fase, se sugieren toda clase de ideas sin juzgarse una validez, por muy disparatadas que parezcan. En una segunda fase se realiza un anlisis detallado de cada propuesta.

Tcnicas, continuacinETHICS (Implementacin efectiva de sistemas informticos desde los puntos de vista humanos y tcnicos). Aunque poco utilizado, este mtodo por representativo de los enfoques de informatizacin que contemplan tambin el anlisis del trabajo de la organizacin, sus proyectos y los recursos humanos y materiales como la base de sus decisiones. Fue creado en 1979 y constituye un mtodo bastante evolucionado para fomentar la participacin de los usuarios en los proyectos, ya que coordina la perspectiva social de los sistemas con su implementacin tcnica: un sistema no tiene xito si no se ajusta a los factores sociales y organizativos que rigen la empresa. Se busca la satisfaccin de los empleados en el trabajo a travs de estudios integrales. Los requisitos tcnicos de sistema sern necesarios para mejorar la situacin de los empleados (y, por tanto, su productividad) en funcin de dichos anlisis.En la prctica es habitual utilizar combinaciones de diversas tcnicas para recoger informacin de los usuarios. Los cuestionarios, la observacin y el estudio de documentacin son tcnicas que, por s solas, no suelen bastar para obtener la informacin necesaria para el anlisis. Por eso se deben usar en coordinacin con las entrevistas y el JAD. El prototipado constituye una tcnica bastante especial, ya que implica una forma distinta de concebir el desarrollo de software. No obstante, para crear un primer prototipo debe recurrirse a las otras tcnicas para tener un mnimo conocimiento de las necesidades del usuario.Estudio de los requerimientos(tipos)Requerimientos del UsuarioSon requerimientos abstractos de alto nivel, se definen como enunciados en un lenguaje natural junto con diagramas, acerca de que servicios esperan los usuarios del sistema y las restricciones con las cuales ste debe de operar.Requerimiento del SistemaSon descripciones ms detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software.Requerimientos del sistema(continuacin)Conocido tambin como documento de especificacin funcionalDebe de definir con exactitud lo que se implementarForma parte del contrato entre el cliente y el equipo de trabajo (representado por el ingeniero de software)Requerimientos funcionales y No funcionalesRequerimientos funcionales:Son enunciados acerca de los servicios que el sistema debe de proveer, de como debera reaccionar el sistema a entradas particulares y de como debera comportarse el sistema en situaciones especficas. Tambin explican lo que no debe hacer el sistema. Detallan las funciones del sistema, sus entradas y salidas, sus excepciones y limitaciones.Requerimientos No funcionalesSon requerimientos que no se relacionan directamente con los servicios especficos que el sistema entrega a sus usuarios. Pueden relacionarse con propiedades emergentes del sistema como fiabilidad, tiempo de respuesta y uso de almacenamiento. A menudo son ms significativos que los requerimientos funcionales indivuduales.Ejemplo: El rendimiento, la fiabilidad, la seguridad, la disponibilidad, entre otros.Requerimientos NO funcionalesPueden identificarse como:Requerimientos del productoRendimiento, velocidad de ejecucin, capacidad de la memoria, fiabilidad, seguridad, fallas, facilidad de usoRequerimientos de la organizacinEntorno del sistema, lenguajes y utileras utilizados en su desarrollo, metodologa empleadasRequerimientos externos ticos, legislativos, polticas de operacinMtricas para especificar requerimientos no funcionales

Documento de Requerimientos de SoftwareEs un comunicado oficial de lo que deben implementar los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para un sistema, como una especificacin detallada de los requerimientos de sistema.

Este documento es esencial cuando un contratista externo a la empresa desarrolla l producto de software.

Usuarios de un documento de requerimientos

Estructura de un Documentode Requerimientos

Diagramas de Casos de UsoSon una tcnica de descubrimiento de requerimientos.Documentan el comportamiento de un sistema desde el punto de vista del usuario. Determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente tiles en la comunicacin con el cliente.

Diagramas de casos de uso, elementos que lo componenActor: Un actor representa quien o que inicia una accin dentro del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama de Caso de uso es representado por una figura en forma de persona Caso de uso: Es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema. Comunicacin: representa la relacin que existe entre un Caso de uso y un Actor, dicho elemento es representado simplemente por una linea recta que se extiende de la figura del actor hacia el ovalo del caso de uso

Diagramas de casos de uso, elementos que lo componen (continuacin)Limite de Sistema Empleado para marcar los limites del sistema, y representado por un rectngulo con color de fondo distintivo Inclusin : Es utilizada para indicar que un caso de uso depende de otro caso, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una linea punteada con flecha y comentario que se extiende del caso de uso base hacia el caso de uso de inclusin Extensin : representa una variacin de un caso de uso a otro, representa una dependencia especifica. Este elemento es representado por una linea punteada con flecha y comentario que se origina del caso de uso base hacia el uso caso de extensin.

IRQA 43Herramienta CASE de Ingeniera de Requisitos, diseada para soportar las actividades realizadas en el proceso de especificacin de sistemas. sta facilita y formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo.Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptable a cada cliente.RETOEsta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; bsicamente, mediante tres tcnicas complementarias entre s: la definicin de la Misin del Sistema, la construccin del rbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.Adems, se introduce un Proceso de Anlisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representacin de la informacin en el segundo prototipo.OSRMT (Open SourceRequirements Management Tool)4Herramienta libre para la gestin de requisitos, cuyas principales caractersticas son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3 trae un mdulo para manejar la trazabilidad y lo introduce para el control de cambios; as mismo, genera la documentacin de los requisitos tratados.