INGENIERIA DE REQUERIMIENTOS
INTEGRANTES:
Jose Ahías Vargas Pacheco
Henry Vargas Ortiz
Gabriel Nuñez Juarez
Randall Madrig...
Definiciones de Requerimientos
Son descripciones de lo que el sistema debe hacer:
• el servicio que ofrece
• las restricci...
Clasificación de los Requerimientos
Requerimientos
funcionales
Requerimientos
no funcionales
Enunciados acerca de servicio...
Requerimientos Funcionales
Nivel de detalle
Ejemplos
Los requerimientos funcionales varían desde requerimientos generals
q...
Requerimientos Funcionales
Especificación de
requerimientos
funcionales
Inexactitud en la
especificación
Causa muchos prob...
Requerimientos No Funcionales
Requerimientos de sistemas amplios, derivados de políticas y
procedimientos en la organizaci...
Requerimientos No Funcionales
Facilidad de uso
Transacciones/Segundo procesadas, tiempo de respuesta usuario/evento, tiemp...
Especificación de Requerimientos
Proceso de escribir, en un documento de requerimientos los:
• requerimientos del usuario:...
Documento de Requerimientos de Software
Según el sitio bicubic.cl, el documento de requerimientos es la declaración
oficia...
Clientes del
sistema
Este documento se orienta al cliente, donde este podrá verificar si el
software cumple con lo deseado...
Estructura del Documento de Requerimiento del Sistema
Prefacio Es un resumen de las versiones, del porque la nueva versión...
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 requis...
Especificación de Requerimientos
Es donde se explica los requerimientos de usuario y sistema, pero se deben seguir siempre...
Tipos de Lenguajes
1. Especificación en lenguaje natural: es el utilizado para detallar los requerimientos de
software por...
Procesos de Ingeniería de Software
El procesos se basan en las decisiones que tomaron sobre los requerimientos de
software...
En una organización, la adquisición y el análisis de requerimientos pueden involucrar a
diversas clases de personas. Un pa...
Actividades del Proceso
La comprensión de los requerimientos por parte del analista mejora con cada ronda del
ciclo. El ci...
Descubrimiento de Requerimientos
Es el proceso de recopilar información sobre el sistema requerido y los sistemas
existent...
El equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el
sistema que actualmente usan y el...
• Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas
preestablecidas.
• Entrevistas abiert...
Los escenarios son particularmente útiles para detallar un bosquejo de descripción de
requerimientos. Se trata de ejemplos...
• Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario.
• Una descripción en el escenario d...
Un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de
interacción. Entonces, esto se ...
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 apo...
La Etnografía Puede Combinarse con la Creación de
Prototipos
La etnografía informa del desarrollo del prototipo, de modo q...
Validación de Requerimientos
• Definición: es el proceso de verificar que los requerimientos definan realmente el
sistema ...
Tipos de Comprobaciones de Requerimientos
• Comprobaciones de Validez: se debe identificar y analizar las funciones adicio...
Tipos de Comprobaciones de Requerimientos
• Revisiones de requerimientos: los requerimientos se analizan sistemáticamente
...
Administración de Requerimientos
Los requerimientos para los grandes sistemas de software siempre cambian, ya que los
requ...
Planeación de Administración de Requerimientos
En esta etapa se establece el nivel de detalle que se requiere en la admini...
Administración de Cambios de Requerimientos
Identificación del
Problema
Análisis del
problema y cambio
de especificación
A...
Bibliografía
Bicubic, Documento de requerimientos. (nd) extraído el 8 de marzo del 2014 desde
http://www.bicubic.cl/portal...
Próxima SlideShare
Cargando en…5
×

Presentación grupo 3

364 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
364
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
8
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Presentación grupo 3

  1. 1. INGENIERIA DE REQUERIMIENTOS INTEGRANTES: Jose Ahías Vargas Pacheco Henry Vargas Ortiz Gabriel Nuñez Juarez Randall Madrigal Leiva GRUPO 3
  2. 2. 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 servicios ofrecidos y las restricciones de operación. Requerimientos del usuario Requerimientos del sistema Enunciados en lenguaje natural junto con diagramas, acerca de qué servicios esperan los usuarios del sistema y de las restricciones con las cuales éste debe operar. Descripciones más detalladas de las funciones, servicios y las restricciones operacionales del sistema de software.
  3. 3. Clasificación de los Requerimientos Requerimientos funcionales Requerimientos no funcionales Enunciados acerca de servicios que el sistema debe proveer y de cómo deberí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ón tratado por unidad de tiempom requisitos en cuanto a interfaces, extensibilidad, facilidad de mantenimiento, etc. (Campderrich, 2003)
  4. 4. Requerimientos Funcionales Nivel de detalle Ejemplos Los requerimientos funcionales varían desde requerimientos generals que cubren lo que tiene que hacer el sistema, hasta requerimientos muy específicos que reflejan maneras locales de trabajar o los sistemas existentes de una organización. Requerimiento 1: Un usuario podrá buscar listas de citas en todas las clínicas de la Caja Costarricense del Seguro Social. Requerimiento 2: El sistema elaborará a diario para cada clínica, listas de pacientes que se esperan asistan a cita ese día. Requerimiento 3: Cada miembro del personal que usa el sistema debe identificarse de manera individual con su número de 8 dígitos.
  5. 5. Requerimientos Funcionales Especificación de requerimientos funcionales Inexactitud en la especificación Causa muchos problemas en la ingeniería de software que pueden provocar aplazamiento 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 definiciones contradictorias. En sistemas complejos grandes es casi imposible lograr la consistencia y totalidad: • por la facilidad con que se cometen errors y omisiones al escribir especificaciones. • por la existencia de muchos participantes con diferentes necesidades
  6. 6. 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. Requerimientos del producto Requerimientos de la empresa Requerimientos externos 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.
  7. 7. 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.
  8. 8. Especificación de Requerimientos Proceso de escribir, en un documento de requerimientos los: • requerimientos del usuario: en lenguaje natural, complementando con diagramas y tablas. • requerimientos del sistema: también en lenguaje natural, pero se utilizan otras notaciones 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 los requerimientos 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 un aspecto del requerimiento. Los modelos gráficos, complementados con anotaciones de texto sirven para definer los requerimientos funcionales 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.
  9. 9. Documento de Requerimientos de Software Según el sitio bicubic.cl, el documento de requerimientos es la declaración oficial 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 sus requerimientos, pero con más detalle y el cual puede ir orientado a varios usuarios , si la documentación llega a ser muy extensa, se separa en secciones. El document es tan necesario para el cliente como para los desarolladores para poder orientarse a las necesidades del cliente y viceversa donde el cliente entederá sobre el nuevo sistema (la documentación siempre debe ser desarrollada en lenghuaje ordinario sin tecnicismo para su completo entendimiento para el cliente).
  10. 10. 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
  11. 11. 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
  12. 12. 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….
  13. 13. 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.
  14. 14. 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).
  15. 15. 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 .
  16. 16. 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
  17. 17. 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.
  18. 18. 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.
  19. 19. 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
  20. 20. • 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
  21. 21. 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
  22. 22. • 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
  23. 23. 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
  24. 24. Ejemplo Diagrama de Caso de Uso
  25. 25. 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
  26. 26. 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.
  27. 27. Validación de Requerimientos • Definición: es el proceso de verificar que los requerimientos definan realmente el sistema que en verdad desea el cliente . • Importancia: ayuda a reducir los errores durante y después del desarrollo de un sistema y de esta forma evita grandes costos por tener que rehacer el proyecto.
  28. 28. Tipos de Comprobaciones de Requerimientos • Comprobaciones de Validez: se debe identificar y analizar las funciones adicionales o diferentes que se requieran en el sistema. • Comprobaciones de Consistencia: los requerimientos en el documento no deben estar en conflicto. • Comprobaciones de Totalidad: el documento debe incluir requerimientos que definan todas las funciones y restricciones para el sistema. • Comprobaciones de Realismo: se debe comprobar los requerimientos para garantizar que la implementación del sistema este dentro del presupuesto. • Verificabilidad: Los requerimientos del sistema deben escribirse de manera verificable para reducir disputas entre cliente y contratista
  29. 29. Tipos de Comprobaciones de Requerimientos • Revisiones de requerimientos: los requerimientos se analizan sistemáticamente para verificar errores e inconsistencias. • Creación de prototipos: se muestra un modelo ejecutable del sistema en cuestión a los usuarios finales y a los clientes. • Generación de casos de prueba: los requerimientos deben ser comprobables y la prueba de diseño debe ser fácil para que los requerimientos sean fáciles de implementar.
  30. 30. Administración de Requerimientos Los requerimientos para los grandes sistemas de software siempre cambian, ya que los requerimientos para muchos sistemas por lo general se encuentran incompletos lo que obliga a estar en un constante cambio de requerimientos para corregir los problemas que se 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 dicho sistema. 3. Los sistemas grandes están compuesto por comunidades de usuarios que a menudo tienen diferentes requerimientos y prioridades.
  31. 31. 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.
  32. 32. Administración de Cambios de Requerimientos Identificación del Problema 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
  33. 33. Bibliografía Bicubic, Documento de requerimientos. (nd) extraído el 8 de marzo del 2014 desde http://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.

×