INGENIERIA DE REQUERIMIENTOS

INTEGRANTES:

Jose Ahías Vargas Pacheco

Henry Vargas Ortiz

Gabriel Nuñez Juarez

Randall Madrigal Leiva

GRUPO 3

Definiciones de Requerimientos

Son descripciones de lo que el sistema debe hacer:

• el servicio que ofrece

• las restricciones en su operación

Requerimientos

Ingeniería de Requerimientos

Proceso de descubrir, analizar, documentar y verificar los serviciosofrecidos y las restricciones de operación.

Requerimientosdel usuario

Requerimientosdel sistema

Enunciados en lenguaje natural junto con diagramas, acerca de quéservicios esperan los usuarios del sistema y de las restricciones con lascuales éste debe operar.

Descripciones más detalladas de las funciones, servicios y lasrestricciones operacionales del sistema de software.

Clasificación de los Requerimientos

Requerimientosfuncionales

Requerimientosno funcionales

Enunciados acerca de servicios que el sistema debe proveer y de cómodebería reaccionar a entradas particulares y situaciones específicas.

Según Campderrich (2003), los requisites funcionales describen quédebe realizar el software para sus usuarios: aceptar, verificar y registrar datos, transformarlos, presentarlos, etc.

Limitaciones sobre servicios o funciones que ofrece el sistema.

Consisten en restricciones impuestas por el entorno y la tecnología, especificaciones sobre tiempo de respuesta o volume de informacióntratado por unidad de tiempom requisitos en cuanto a interfaces, extensibilidad, facilidad de mantenimiento, etc. (Campderrich, 2003)

Requerimientos Funcionales

Nivel de detalle

Ejemplos

Los requerimientos funcionales varían desde requerimientos generals que cubren lo que tiene que hacer el sistema, hasta requerimientosmuy específicos que reflejan maneras locales de trabajar o los sistemasexistentes de una organización.

Requerimiento 1: Un usuario podrá buscar listas de citas en todas lasclínicas de la Caja Costarricense del Seguro Social.

Requerimiento 2: El sistema elaborará a diario para cada clínica, listasde pacientes que se esperan asistan a cita ese día.

Requerimiento 3: Cada miembro del personal que usa el sistema debeidentificarse de manera individual con su número de 8 dígitos.

Requerimientos Funcionales

Especificación de requerimientos

funcionales

Inexactitud en laespecificación

Causa muchos problemas en la ingeniería de software que pueden provocaraplazamiento de la entrega del sistema y aumento de costos.

Debe ser:

• completa: deben definirse todos los servicios requeridos por el usuario.

• consistente: los requerimientos tienen que evitar definicionescontradictorias.

En sistemas complejos grandes es casi imposible lograr la consistencia y totalidad:

• por la facilidad con que se cometen errors y omisiones al escribirespecificaciones.

• por la existencia de muchos participantes con diferentes necesidades

Requerimientos No Funcionales

Requerimientos de sistemas amplios, derivados de políticas y procedimientos en la organización del cliente y del desarrollador. Ejemplos: requerimientos ambientales, operacionales y de desarrollo.

Requerimientosdel producto

Requerimientosde la empresa

Requerimientosexternos

Especifican o restringen el comportamiento del software. Ejemplos: requerimientos de eficiencia, confiabilidad, seguridad y usabilidad.

Se clasifican en:

Aquellos derivados de factores externos al sistema y su proceso de desarrollo. Ejemplos: requerimientos regulatorios, éticos y legales.

Requerimientos No Funcionales

Facilidad de uso

Transacciones/Segundo procesadas, tiempo de respuesta usuario/evento, tiempo de regeneración de pantalla.

Métricas para especificar requerimientos no funcionales:

Portabilidad

Fiabilidad

Robustez

Tamaño

Rapidez

Mbytes, número de chips ROM.

Tiempo de capacitación, número de cuadros de ayuda.

Tiempo medio para falla, probabilidad de indisponibilidad, tasa de ocurrencia de falla, disponibilidad.

Tiempo de reinicio después de falla, porcentaje de eventos que causan falla, probabilidad de corrupción de datos en falla.

Porcentaje de enunciados dependientes de objetivo, número de sistemas objetivo.

Especificación de Requerimientos

Proceso de escribir, en un documento de requerimientos los:

• requerimientos del usuario: en lenguaje natural, complementando condiagramas y tablas.

• requerimientos del sistema: también en lenguaje natural, pero se utilizan otrasnotaciones como las siguientes:

Definición

Enunciados en lenguaje natural

Lenguaje natural estructurado

Lenguaje de descripción de diseño

Anotaciones gráficas

Especificaciones matemáticas

Cada enunciado debe expresar un requerimiento.

Usa lenguajes como los de programación, pero con características más abstractas para especificar losrequerimientos al definer un modelo operacional del sistema.

Se escriben en lenguaje natural en una forma o plantilla estándar. Cada campo ofrece información de unaspecto del requerimiento.

Los modelos gráficos, complementados con anotaciones de texto sirven para definer los requerimientosfuncionales del sistema; se emplean los casos de uso del UML y los diagramas de secuencia.

La anotaciones se basan en conceptos matemáticos como máquinas o conjuntos de estado finito.

Documento de Requerimientos de Software

Según el sitio bicubic.cl, el documento de requerimientos es la declaraciónoficial de qué es lo que deben implementar los desarrolladores:

• requerimientos del usuario para el sistema

• especificación detallada de los requerimientos del sistema

Definición

Es la documentación que implementa en los software sobre susrequerimientos, pero con más detalle y el cual puede ir orientado a variosusuarios , si la documentación llega a ser muy extensa, se separa ensecciones. El document es tan necesario para el cliente como para losdesarolladores para poder orientarse a las necesidades del cliente y viceversadonde el cliente entederá sobre el nuevo sistema (la documentación siempredebe ser desarrollada en lenghuaje ordinario sin tecnicismo para su completoentendimiento para el cliente).

Clientes del sistema

Este documento se orienta al cliente, donde este podrá verificar si el software cumple con lo deseado, y así podría hacer modificaciones si hubiera la necesidad

Administra-dores

Este documento contiene información del sistema a nivel de costos y su proceso de desarrollo

Ingenieros de prueba

del sistema

Usan el documento para verificar los requerimiento que se desean y validarlos

Ingenieros de sistema

El documento los guía a desarrollar el sistema en base a los requerimientos deseados por el cliente y que los desarrolladores de software crean

Ingenieros de mantenimiento

del sistema

Se encargar de revisar el documento, e identifican como se relacionan los componentes con el sistema

Estructura del Documento de Requerimiento del Sistema

Prefacio Es un resumen de las versiones, del porque la nueva versión del sistema

Introducción Muestra todas las funciones del sistema y sus requerimiento de forma resumida, también información empresarial y estadísticas del sistema

Glosario Acá se agregan las definiciones de las palabras técnicas del documento

Definición de requerimientos del usuario

Se explica en lenguaje natural de los servicios que se le dan al cliente, también pueden usar diagramas y observaciones. También se incluyen los requerimientos no funcionales

Arquitectura del sistema

Esta sección muestra como esta formado el sistema, por medio de módulos de sistema, donde también se ven las partes que se reutilizaron del sistema

Especificación de requerimientos de sistema

Se detallan con mucho mas detalle los requerimientos funcionales y no funcionales

Modelos de sistema En este se muestra como funciona los componentes y su relación con los sistemas con gráficos.

Evolución de sistema Este es donde se registra la bases del sistema también cualquier cambio que se esperaba ya sea por alguna modificación que quisiera el cliente o por las mejoras a nivel de hardware

Apéndice En el apéndice va a ir la información detalla de la aplicación, como la información del hardware (como los requisitos mínimos o los necesarios para obtener un rendimiento optimo)y la base datos, muestra la relación del sistema y sus componentes

Índice Acá muestra un índice(lista de las secciones del documento de requerimientos) el cual puede ser alfabético, diagrama….

Especificación de Requerimientos

Es donde se explica los requerimientos de usuario y sistema, pero se deben seguir siempre ciertas reglas para desarrollar este documento.El documento se debe de desarrollar con lenguaje natural y no técnico, ya que su lectura será totalmente para el cliente, este puede que no manejo lenguaje técnico, causado que el no pueda entender lo cual hace este documento no sirva para su propósito.

• Los requerimientos de usuario es un documento el cual explica los componentes funcionales y no funcionales del sistema, normalmente se usan tablas o alguna otra forma que sea muy sencilla de explicación.

• Y los requerimientos de sistema son versiones extendidas del de usuarios, este si incluye estructura del sistema, es mas que todo el que se agrega para aceptar el contrato donde viene explicado con detalle lo que el sistema hace y necesita, que si esta de acuerdo con lo establecido.

Tipos de Lenguajes

1. Especificación en lenguaje natural: es el utilizado para detallar los requerimientos de software por su sencillez aunque ambiguo y se usan muchas palabras de entendimiento universal, resaltar con negrita o cursiva información importante, también pueden dar una razón para el requerimiento para sacar de cualquier duda al lector, evitar palabras inmisarias como (debe) y si es muy necesario usar un (debería).

2. Especificaciones estructuradas: los requerimientos de sistemas acá usan lenguaje natural pero tal vez si especifique mas con detalle y tecnicismo por esa motivo se usa una estructura la cual pueda ayudar al lector, como material de apoyo. Se a estandarizado que se uso en modo de tarjeta para los requerimientos de sistema para poder dar un toque sencillo a este y así facilitar su compresión al lector. El uso de tablas, graficos es muy importante ya que son de a gran ayuda para las explicaciones; si se llegara detallar funciones de sistemas deben incluir (descripción de funciones, entrada de sistema, salida y donde llegara, acciones que se tomaran, efecto colaterales).

Procesos de Ingeniería de Software

El procesos se basan en las decisiones que tomaron sobre los requerimientos de software, cuales se validaron y modificaron. Con esto se emplea un método por etapas el cual se ejecutara paso a paso , este método representado en forma grafica es una espiral .

En una organización, la adquisición y el análisis de requerimientos pueden involucrar a diversas clases de personas. Un participante en el sistema es quien debe tener alguna influencia directa o indirecta sobre los requerimientos del mismo. Los participantes incluyen a usuarios finales que interactuarán con el sistema, y a cualquiera en una organización que resultará afectada por él. Otros participantes del sistema pueden ser los Ingenieros que desarrollan o mantienen otros sistemas relacionados, administradores de negocios, expertos de dominio y representantes de asociaciones sindicales.

Adquisición y Análisis de Requerimientos

Actividades del Proceso

La comprensión de los requerimientos por parte del analista mejora con cada ronda del ciclo. El ciclo concluye cuando está completo el documento de requerimientos.

Descubrimiento de Requerimientos

Es el proceso de recopilar información sobre el sistema requerido y los sistemas existentes, así como de separar, a partir de esta información, los requerimientos del usuario y del sistema.Las fuentes de información durante la fase de descubrimiento de requerimientos incluyen documentación, participantes del sistema y especificaciones de sistemas similares. La interacción con los participantes es a través de entrevistas y observaciones, y pueden usarse escenarios y prototipos para ayudar a los participantes a entender cómo será el sistema.

El equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el sistema que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan de las respuestas a dichas preguntas.La información de las entrevistas se complementa con otra información del sistema de documentación que describe los procesos empresariales o los sistemas existentes, las observaciones del usuario, etcétera. En ocasiones, además de los documentos del sistema, la información de la entrevista puede ser la única fuente de datos sobre los requerimientos del sistema.

Entrevistas

• Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas preestablecidas.

• Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de ingeniería de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades.

Tipos de Entrevistas

Los escenarios son particularmente útiles para detallar un bosquejo de descripción de requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. Cada escenario abarca comúnmente una interacción o un número pequeño de interacciones posibles. Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos de información con diversos niveles de detalle acerca del sistema.Un escenario comienza con un bosquejo de la interacción. Durante el proceso de adquisición, se suman detalles a éste para crear una representación completa de dicha interacción.

Escenarios

• Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario.

• Una descripción en el escenario del flujo normal de los eventos.

• Una descripción de qué puede salir mal y cómo se manejaría.

• Información de otras actividades que estén en marcha al mismo tiempo.

• Una descripción del estado del sistema cuando termina el escenario.

Un Escenario Puede Incluir

Un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de interacción. Entonces, esto se complementa con información adicional que describe la interacción con el sistema. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado.Los casos de uso se documentan con el empleo de un diagrama de caso de uso de alto nivel. El conjunto de casos de uso representa todas las interacciones posibles que se describirán en los requerimientos del sistema.

Casos de Uso

Ejemplo Diagrama de Caso de Uso

Es una técnica de observación que se usa para entender los procesos operacionales y ayudar a derivar requerimientos de apoyo para dichos procesos. Un analista se adentra en el ambiente laboral donde se usará el sistema. Observa el trabajo diario y toma notas acerca de las tareas existentes en que intervienen los participantes. El valor de la etnografía es que ayuda a descubrir requerimientos implícitos del sistema que reflejan las formas actuales en que trabaja la gente, en vez de los procesos formales definidos por la organización.

Etnografía

La Etnografía Puede Combinarse con la Creación de Prototipos

La etnografía informa del desarrollo del prototipo, de modo que se requieren menos ciclos de refinamiento del prototipo.

Validación de Requerimientos

• Definición: es el proceso de verificar que los requerimientos definan realmente elsistema que en verdad desea el cliente .

• Importancia: ayuda a reducir los errores durante y después del desarrollo de un sistemay de esta forma evita grandes costos por tener que rehacer el proyecto.

Tipos de Comprobaciones de Requerimientos

• Comprobaciones de Validez: se debe identificar y analizar las funciones adicionales odiferentes que se requieran en el sistema.

• Comprobaciones de Consistencia: los requerimientos en el documento no deben estaren conflicto.

• Comprobaciones de Totalidad: el documento debe incluir requerimientos que definantodas las funciones y restricciones para el sistema.

• Comprobaciones de Realismo: se debe comprobar los requerimientos para garantizarque la implementación del sistema este dentro del presupuesto.

• Verificabilidad: Los requerimientos del sistema deben escribirse de manera verificablepara reducir disputas entre cliente y contratista

Tipos de Comprobaciones de Requerimientos

• Revisiones de requerimientos: los requerimientos se analizan sistemáticamentepara verificar errores e inconsistencias.

• Creación de prototipos: se muestra un modelo ejecutable del sistema en cuestióna los usuarios finales y a los clientes.

• Generación de casos de prueba: los requerimientos deben ser comprobables y laprueba de diseño debe ser fácil para que los requerimientos sean fáciles deimplementar.

Administración de Requerimientos

Los requerimientos para los grandes sistemas de software siempre cambian, ya que losrequerimientos para muchos sistemas por lo general se encuentran incompletos lo queobliga a estar en un constante cambio de requerimientos para corregir los problemas quese presenten.

Algunas razones de porque es inevitable los cambios son:

1. Por las modificaciones de las instalaciones del ambiente empresarial.

2. Por las diferencias entre el individuo que paga un sistema y los usuarios de dichosistema.

3. Los sistemas grandes están compuesto por comunidades de usuarios que a menudotienen diferentes requerimientos y prioridades.

Planeación de Administración de Requerimientos

En esta etapa se establece el nivel de detalle que se requiere en la administración de requerimientos y hay que decidir sobre:

Identificación de requerimientos.

Un proceso de administración del cambio.

Políticas de seguimiento.

Herramientas de apoyo.

Administración de Cambios de Requerimientos

Identificación delProblema

Análisis del problema y cambio

de especificación

Análisis del cambio y estimación del

costo

Implementación del cambio

Revisión de requerimientos

Bibliografía

Bicubic, Documento de requerimientos. (nd) extraído el 8 de marzo del 2014 desdehttp://www.bicubic.cl/portal/es/tecnicos/documento-de-requerimientos.html

Campderrich, B. (2003). Ingeniería del software. Barcelona: Editorial UOC.

Sommerville, I. (2011). Ingeniería del software (9a. ed.). México: Pearson Educación.