Ing de requerimiento

UNIVERSIDAD TECNICA ESTATAL DE QUEVEDO UNIDAD DE ESTUDIOS A DISTANCIA CARRERA: INGENIERÍA EN SISTEMAS

TEMA: Ingeniería DE REQUERIMIENTO INTEGRANTE: DANILO FERNANDO PULSARA BRAVO

TUTOR: RICARDO AGUIRRE

QUEVEDO - LOS RIOS - ECUADOR 2014

Ingeniería de requerimientos La Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Fases en ingeniería de requisitos La definición de las necesidades del sistema juega un papel fundamental en el proceso de desarrollo del software (SPD) . Esta definición es un proceso complejo puesto que en él hay que identificar los requisitos que el Patrón de clasificación de tipos de requisitos que el sistema debe cumplir para satisfacer las necesidades. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado.

La delimitación de ingeniería de requisitos no es del todo clara puesto que incluso, hay autores que, dentro de la ingeniería de requisitos, generan modelos estáticos de clases que son entendidos por otros autores como tareas de una fase posterior.

Dentro de las posibles estructuras que se pueden definir en la fase de ingeniería de requisitos, la propuesta con mayor seguimiento es la establecida por Lowe y Hall [Lowe y Hall 99].

En ella, el proceso de tratamiento de requisitos está compuesto por tres actividades: -Captura de requisitos.

-Definición de requisitos.

-Validación de requisitos.

Se puede representar este proceso de ingeniería de requisitos como un diagrama de actividades en UML, tal como se muestra en la ilustración 1

Captura de requisitos La captura de requisitos es la actividad en la que un grupo especializado extrae, de cualquier fuente de información disponible (documentos, aplicaciones existentes, entrevistas, etc.), las necesidades de cubrir dicho sistema. El proceso de captura de requisitos puede resultar complejo, debido a esto existen un conjunto de técnicas que permiten hacer este proceso de una forma más eficiente y precisa, obteniéndose necesidades Y modelos del sistema.

Definición de requisitos Para la definición de los requisitos son usados lenguajes naturales que, a pesar de poder ser ambiguos y/o extensos, su coste reducido hace que sean la alternativa común a los lenguajes formales.

Es necesario elaborar el documento de requisitos, en el cual, se definen los objetivos y necesidades del sistema. Existe un conjunto de técnicas propuestas para esta actividad: - Lenguajes naturales y formales. Los lenguajes naturales es una técnica muy ambigua en contraposición a los lenguajes formales.

- Ontologías. Donde se definen los conceptos que intervienen en la definición del sistema así como las relaciones que existen entre ellos.

- Patrones. Define los requisitos mediante el lenguaje natural pero de una manera estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida.

Validación de requisitos Por último, se procede a la validación de requisitos, llevándose a cabo la valoración de los mismos, comprobando la veracidad, consistencia y completitud de requisitos. Las técnicas existentes para desarrollar esta actividad son: - Revisiones de verificabilidad. Consiste en la lectura y corrección de la documentación o modelado de la definición de requisitos.

- Auditorías. Consiste en un chequeo de los resultados.

- Matrices de trazabilidad. Consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo que objetivos cubre cada requisito para detectar inconsistencias u objetivos no cubiertos.

- Prototipos. Permite que el usuario se haga una idea del sistema.

Los requisitos han de ser gestionados mediante el llamado plan de gestión de requisitos que establece las medidas, el método, soporte y técnicas para almacenar los requisitos, gestionar el cambio de éstos (debido a que pueden ser volátiles) y gestionar su trazabilidad.

Requerimientos funcionales.

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares.

En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. Los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera. Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitaria, denominada LIBSYS, utilizada por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3). El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículos publicados en revistas. Periódicos y publicaciones científicas. Una descripción más detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Koton ya sobre ingeniería de requerimientos (Kontonya y Sommerville, 1998). La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del software.

Requisito no funcional Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar.

Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema. Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.

De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

Algunos ejemplos de requisitos no funcionales típicos son los siguientes:



rendimiento



disponibilidad



seguridad



accesibilidad



usabilidad



estabilidad



portabilidad



costo



operatividad



interoperabilidad



escalabilidad



concurrencia



mantenibilidad



interfaz

Documentación requerimientos de software Diagrama de la tarea Documentar los requisitos del sistema software a desarrollar

Éste es el proceso de interactuar con los participantes del sistema para descubrir sus requerimientos. También los requerimientos de

dominio de los participantes y la documentación se descubren durante esta actividad Es el proceso de recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario del sistema de esta información fuente: las fuentes de información durante la fase del descubrimiento de requerimientos incluyen la documentación

  

Entrevistas Etnografía Escenario

Especificación De Requisitos De Software La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

Tipos de requisitos Existen varios tipos de requisitos como lo son: 1. Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente 2. Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas 3. Requisitos Funcionales: Servicios que el sistema debe proporcionar 4. Requisitos no funcionales: Restricciones que afectan al sistema

Proceso de la Ingeniería de Requisitos Es muy importante definir cuál es el proceso de ingeniería de requisitos ya que esto nos va a servir para la obtención correcta de los requerimientos. Se han definido diversos modelos a nivel de toda la Ingeniería de Software, así tenemos para el desarrollo de aplicaciones web, de escritorio, o sencillamente se ha definido un estándar, pero en general, la mayor parte de estos procesos tienen un símil y lo único que buscan es recopilar la mayor cantidad de requerimientos correctos para así conformar una buena estructura que servirá de base para el desarrollo de un proyecto.

En la figura, se muestra un esquema del proceso de la ingeniería de requisitos basado en la Ingeniería de Software de Gestión. El proceso se cumple en cinco fases: viabilidad, captura y análisis, especificación, validación y gestión de requisitos.

Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena desarrollarlo. Es de vital importancia para la satisfacción de los objetivos del negocio.

Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados.

Especificación: Aquí se debe obtener un documento de especificación de requisitos, en cual se llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware).

Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron ya en la especificación.

Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos, sean estos requisitos estables (corresponden al estado del sistema) o volátiles (representan eventos que hacen que el sistema realice una función dada).

VALIDACION DE REQUERIMIENTOS La validación de requerimientos trata de mostrar que estos realmente definen el sistema que el cliente desea.

Coincide principalmente con el análisis ya que este implica encontrar problemas con los requerimientos. La validación de requerimientos es importante debido a errores en el documento de requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso.

La razón de esto es que un cambio en los requerimientos normalmente significa que el diseño y la implementación del sistema también deben cambiar y que este debe probarse nuevamente.

Durante el proceso de validación de requerimientos, se deben llevar acabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden: 1.

Verificaciones de validez: Un usuario puede pensar que se necesitan un sistema para llevar acabo ciertas funciones. sin embargo el razonamiento y el análisis pueden identificar que se requieren funciones adicionales o diferentes.

2.

Verificaciones de consistencia: Los requerimientos en el documento no deben contradecirse. Esto es, no deben haber restricciones propuestas por el usuario del sistema.

3.

Verificaciones de completitud: El documento de requerimientos debe incluir requerimientos que definan todas las funciones y restricciones propuestas por el usuario del sistema.

4.

Verificación del realismo: Utilizando el conocimiento de la tecnología existente, los requerimientos deben verificarse para asegurar que se pueden implementar. Estas verificaciones también deben tener en cuenta el presupuesto y la confección de agendas para el desarrollo del sistema.

5.

Verificabilidad: Para reducir la posibilidad de discusiones entre el cliente y el contratista, los requerimientos del sistema siempre deben redactarse de tal forma que seas verificables. Esto significa que debe poder escribir un conjunto de pruebas que demuestren que el sistema a entregar cumple cada uno de los requerimientos especificados.

LINCOGRAFIA

http://e-archivo.uc3m.es/bitstream/handle/10016/14998/PFCAdelaida_Ramirez_Fernandez.pdf?sequence=1 http://es.wikipedia.org/wiki/Requisito_funcional http://es.wikipedia.org/wiki/Requisito_no_funcional http://elvex.ugr.es/idbis/db/docs/design/2-requirements.pdf http://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software http://danielvn7.wordpress.com/2008/03/27/proceso-de-la-ingenieria-de-requisitos/ http://laurita-cecy.blogspot.com/2011/04/validacion-de-requerimientos.html http://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales