CAPITULO IIIAnálisis y Especificación deRequisitosIngeniería de Software IIProf. Sara Blach
¿QUÉ DEFINEN LOS REQUERIMIENTOS?Lo que el sistema debe hacer: Las funciones que debe ejecutar. Los datos que debe captur...
¿QUE DEFINEN LOS REQUERIMIENTOS?Las interacciones usuarios-sistema y sistema-sistema: La interfaz grafica usuario-sistema...
¿QUE DEFINEN LOS REQUERIMIENTOS?Las restricciones bajo las cuales el sistema debeoperar: La plataforma de operación del s...
¿QUE DEFINEN LOS REQUERIMIENTOS?Los atributos de calidad que el sistema debesatisfacer: Estándar ISO 9126 Software Quali...
¿POR QUÉ DETERMINAR REQUERIMIENTOS? El software esta integrado por muchoscomponentes. El costo de cambiar requerimientos...
PROBLEMAS AL DETERMINARREQUERIMIENTOS El usuario o cliente no siempre sabe lo que quiere delsistema: Al inicio del proye...
PROBLEMAS AL DETERMINARREQUERIMIENTOS El usuario no tiene tiempo para participar en elproyecto: Evita participar en el p...
PROBLEMAS AL DETERMINARREQUERIMIENTOS Problemas de comunicación: El cliente o usuario no entiende el lenguaje informátic...
PROBLEMAS AL DETERMINARREQUERIMIENTOS Los requerimientos pueden interpretarse dediferentes maneras: El analista entiende...
PROBLEMAS AL DETERMINARREQUERIMIENTOS Requerimientos mal definidos: No reflejan las necesidades reales de los usuarios d...
SOLUCIÓN A LOS PROBLEMAS DE LOSREQUERIMIENTOS Entender la naturaleza del software: Promueve cambios frecuentes en los re...
 Utilizar practicas conocidas (mejores practicas): Incorporar al cliente en el desarrollo del sistema(activamente). Mod...
 Emplear personal especializado: Analistas de negocios. Analistas de requerimientos.
ESPACIO PROBLEMAESPACIO SOLUCION
 Los métodos tradicionales de desarrollo desoftware subestiman la importancia del problema ysu análisis: Se centran en l...
 La separación de estos dos espacios es crucial entoda ingeniería. Las necesidades ocurren en el espacio delproblema. L...
Es relevante definir claramente el dominio.Dominio= Espacio del problema.
ESPACIO DEL PROBLEMAMODELADO DEL NEGOCIONECESIDADES Y REQUERIMIENTOS
 Los requerimientos funcionales de un sistemaexpresan necesidades de información: ¿Qué información requieren los usuario...
 Una buena practica de la IR es modelar losprocesos de negocio antes de definir susrequisitos. Se puede hacer mediante l...
 El producto del MN son los modelos de negocio. El modelo del negocio de una empresa es unarepresentación simplificada d...
 En ingeniería de requerimientos, el modelo delnegocio es usado para: Entender el proceso del negocio actual y establece...
ESPACIO DE LA SOLUCION:INGENIERIA DEREQUERIMIENTOS
INGENIERÍA DE REQUERIMIENTOSDefinición:Es una sub-disciplina de la Ingeniería deSoftware, encargada de los requerimientos ...
Se encarga de establecer:Principios, modelos, métodos, mejorespracticas, técnicas y herramientas que contribuyana mejorar ...
ELEMENTOS DE LA IREl ProductoEl ProcesoEl Equipo¿Qué se hace?¿Cómo hacerlo?¿Quiénes lo hacen?Documento deEspecificación de...
REFLEXION“La brecha entre la teoría y la práctica no es tanlarga en teoría como lo es en la práctica”.Anónimo
Upcoming SlideShare
Loading in...5
×

Analisis y especificacion de requerimientos

4,916

Published on

Analisis y especificacion de requerimientos de software

Published in: Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,916
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
132
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Analisis y especificacion de requerimientos

  1. 1. CAPITULO IIIAnálisis y Especificación deRequisitosIngeniería de Software IIProf. Sara Blach
  2. 2. ¿QUÉ DEFINEN LOS REQUERIMIENTOS?Lo que el sistema debe hacer: Las funciones que debe ejecutar. Los datos que debe capturar y almacenar. La información que debe producir
  3. 3. ¿QUE DEFINEN LOS REQUERIMIENTOS?Las interacciones usuarios-sistema y sistema-sistema: La interfaz grafica usuario-sistema. La interfaz de la aplicación con otros sistemas.
  4. 4. ¿QUE DEFINEN LOS REQUERIMIENTOS?Las restricciones bajo las cuales el sistema debeoperar: La plataforma de operación del sistema. La tecnología de información que debe utilizar elsistema.
  5. 5. ¿QUE DEFINEN LOS REQUERIMIENTOS?Los atributos de calidad que el sistema debesatisfacer: Estándar ISO 9126 Software Quality Model
  6. 6. ¿POR QUÉ DETERMINAR REQUERIMIENTOS? El software esta integrado por muchoscomponentes. El costo de cambiar requerimientos crece a medidaque avanza el proyecto. (Durante la fase dediseño, durante la fase del diseñodetallado, durante la codificación, durante la pruebade unidades, durante la validación, después que elsistema ha sido implantado).
  7. 7. PROBLEMAS AL DETERMINARREQUERIMIENTOS El usuario o cliente no siempre sabe lo que quiere delsistema: Al inicio del proyecto, no sabe que esperar del sistema. Los requerimientos suelen surgir a medida que el usuario sefamiliariza con el sistema.
  8. 8. PROBLEMAS AL DETERMINARREQUERIMIENTOS El usuario no tiene tiempo para participar en elproyecto: Evita participar en el proyecto. No esta consiente de la importancia de su participación. No ve el sistema como algo que le pertenece.
  9. 9. PROBLEMAS AL DETERMINARREQUERIMIENTOS Problemas de comunicación: El cliente o usuario no entiende el lenguaje informáticode los analistas. Los analistas no entienden el lenguaje del dominio de laaplicación.
  10. 10. PROBLEMAS AL DETERMINARREQUERIMIENTOS Los requerimientos pueden interpretarse dediferentes maneras: El analista entiende y especifica de manera diferentelos requerimientos del cliente. El diseñador interpreta de otra manera los requisitosespecificados por el analista.
  11. 11. PROBLEMAS AL DETERMINARREQUERIMIENTOS Requerimientos mal definidos: No reflejan las necesidades reales de los usuarios delsistema. Son inconsistentes. Son incompletos. No son factibles.
  12. 12. SOLUCIÓN A LOS PROBLEMAS DE LOSREQUERIMIENTOS Entender la naturaleza del software: Promueve cambios frecuentes en los requerimientos. Entender el espacio del problema: Modelar el negocio antes de identificar y especificarrequerimientos. Utilizar un proceso de desarrollo bien definido yprobado.
  13. 13.  Utilizar practicas conocidas (mejores practicas): Incorporar al cliente en el desarrollo del sistema(activamente). Modelar los requerimientos usando notaciones graficasestandarizadas. Gestionar los requisitos.
  14. 14.  Emplear personal especializado: Analistas de negocios. Analistas de requerimientos.
  15. 15. ESPACIO PROBLEMAESPACIO SOLUCION
  16. 16.  Los métodos tradicionales de desarrollo desoftware subestiman la importancia del problema ysu análisis: Se centran en la solución y sus requisitos. No alinean la solución al negocio.
  17. 17.  La separación de estos dos espacios es crucial entoda ingeniería. Las necesidades ocurren en el espacio delproblema. Los requerimientos tienen lugar en el espacio de lasolución.
  18. 18. Es relevante definir claramente el dominio.Dominio= Espacio del problema.
  19. 19. ESPACIO DEL PROBLEMAMODELADO DEL NEGOCIONECESIDADES Y REQUERIMIENTOS
  20. 20.  Los requerimientos funcionales de un sistemaexpresan necesidades de información: ¿Qué información requieren los usuarios para ejecutarsus procesos de negocio? Que actividades de un proceso de negocio requierenser automatizados? Los requerimientos de una aplicación dependen delos procesos de negocio que la aplicación soporta(como y por que lo hace) Si los procesos de negocio no se conocen, laidentificación de necesidades y la especificación derequerimientos no tienen fundamentación.
  21. 21.  Una buena practica de la IR es modelar losprocesos de negocio antes de definir susrequisitos. Se puede hacer mediante la elaboración de un pequeñomodelo. El modelado del negocio (MN), es un proceso através del cual se representa el dominio de unaaplicación. El MN identifica y representa aspectos delsistema, tales como: Objetivos de la organización. Procesos del negocio y sus actividades. Reglas del negocio. Objetos del negocio. Actores y sus organización.
  22. 22.  El producto del MN son los modelos de negocio. El modelo del negocio de una empresa es unarepresentación simplificada de la lógica de negocioque describe lo que un negocio ofrece a susclientes, como llega a ellos, y como se relacionacon ellos. El modelo de negocio es un documento compuestopor un conjunto de submodelos. Cada submodelo describe uno o mas elementosorganizacionales.
  23. 23.  En ingeniería de requerimientos, el modelo delnegocio es usado para: Entender el proceso del negocio actual y establecer susproblemas de información. Descubrir las necesidades que los usuarios tienen. Facilitar la definición y especificación de requerimientosfuncionales. Caracterizar el nuevo proceso de negocio.
  24. 24. ESPACIO DE LA SOLUCION:INGENIERIA DEREQUERIMIENTOS
  25. 25. INGENIERÍA DE REQUERIMIENTOSDefinición:Es una sub-disciplina de la Ingeniería deSoftware, encargada de los requerimientos paraautomatizar sistemas.Estudia:• Los problemas de los requerimientos.• Las soluciones que pueden contribuir a resolver estosproblemas.
  26. 26. Se encarga de establecer:Principios, modelos, métodos, mejorespracticas, técnicas y herramientas que contribuyana mejorar la definición y especificación de losrequerimientos.Conduce a:• Encontrar y definir las necesidades que tienen losinteresados de la aplicación.• Transformar la definición de necesidades en unadescripción completa y precisa derequerimientos, denominada Especificación deRequerimientos de Software (ERS).
  27. 27. ELEMENTOS DE LA IREl ProductoEl ProcesoEl Equipo¿Qué se hace?¿Cómo hacerlo?¿Quiénes lo hacen?Documento deEspecificación deRequerimientos (DER)Llenado del Documentode Especificación deRequerimientos (DER)Conjunto de interesadoso actores debidamenteorganizados
  28. 28. REFLEXION“La brecha entre la teoría y la práctica no es tanlarga en teoría como lo es en la práctica”.Anónimo
  1. ¿Le ha llamado la atención una diapositiva en particular?

    Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

×