Ingeniería de Sistemas y Telecomunicaciones<br />INGENIERÍA DEL SOFWARE II<br />Requerimientos<br />
At its most basic, a software requirement is a property<br />which must be exhibited in order to solve some problem in the...
Problemas con los requerimientos: 34.2%<br />
¿Ingeniería de Requerimientos (IR)?<br />Así, como en su momento la disciplina para crear software fue denominada Ingenier...
Objetivos de la IR<br /><ul><li>Comprender todas las actividades que permitan crear y mantener el documento y los formatos...
Facilitar la comprensión de los requerimientos  y necesidades del cliente, de tal manera que se puedan transformar en un s...
 Permitir la adecuada gestión de los requerimientos durante el proceso de desarrollo.</li></li></ul><li>Software Requireme...
Software Requirements Fundamentals, IEEE<br /><ul><li>Functional and NonfunctionalRequirements</li></ul>Functional require...
Software Requirements Fundamentals, IEEE<br /><ul><li>EmergentProperties</li></ul>Some requirements represent emergent pro...
Software Requirements Fundamentals, IEEE<br /><ul><li>QuantifiableRequirements</li></ul>Software requirements should be st...
El sistema debe permitir que muchos usuarios se conecten al mismo tiempo
Permitir que la factura de venta sea exportada
Que la base de datos soporte grandes cantidades de información</li></li></ul><li>Trabajo con requerimientos desde la IEEE<...
RequirementsElicitation
RequirementsAnalysis
RequirementsSpecification
RequirementsValidations</li></li></ul><li>Somerville <br />Existen cuatro actividades genéricas dentro del proceso de la i...
Somerville <br />El Estudio de factibilidad es una descripción resumida del sistema y de cómo se utilizará dentro de una o...
Upcoming SlideShare
Loading in...5
×

Requerimientos del Software

1,193

Published on

El documento que le da soporte a la presentación puede ser solicitado a luiseduardo.pelaez@gmail.com

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,193
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Requerimientos del Software

  1. 1. Ingeniería de Sistemas y Telecomunicaciones<br />INGENIERÍA DEL SOFWARE II<br />Requerimientos<br />
  2. 2. At its most basic, a software requirement is a property<br />which must be exhibited in order to solve some problem in the real world.<br />Requirements: concept/definition<br />–IEEE, 2004<br />
  3. 3. Problemas con los requerimientos: 34.2%<br />
  4. 4. ¿Ingeniería de Requerimientos (IR)?<br />Así, como en su momento la disciplina para crear software fue denominada Ingeniería del software, hay quienes proponen que los requerimientos son toda una disciplina ya que se enfoca en la definición de algo fundamental: lo que se desea producir.<br />De acuerdo con Rational Software Corporation(IBM) "La Ingeniería de Requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto". <br />
  5. 5. Objetivos de la IR<br /><ul><li>Comprender todas las actividades que permitan crear y mantener el documento y los formatos relacionados con los requerimientos del sistema, en el que se describa con claridad, sin ambigüedades el comportamiento del sistema.
  6. 6. Facilitar la comprensión de los requerimientos y necesidades del cliente, de tal manera que se puedan transformar en un sistema operacional o aplicativo.
  7. 7. Permitir la adecuada gestión de los requerimientos durante el proceso de desarrollo.</li></li></ul><li>Software Requirements Fundamentals, IEEE<br /><ul><li>Product and ProcessRequirements</li></ul>distinction can be drawn between product parameters and process parameters. Product parameters are requirements on software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course.”). A process parameter is essentially a constraint on the development of the software (for example, “The software shall be written in C#.”). <br />
  8. 8. Software Requirements Fundamentals, IEEE<br /><ul><li>Functional and NonfunctionalRequirements</li></ul>Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.<br />
  9. 9. Software Requirements Fundamentals, IEEE<br /><ul><li>EmergentProperties</li></ul>Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture. <br />
  10. 10. Software Requirements Fundamentals, IEEE<br /><ul><li>QuantifiableRequirements</li></ul>Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and<br />unverifiable requirements which depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularlyimportantfornonfunctionalrequirements.<br />Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10−8. The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture. <br /><ul><li>El sistema debe ser confiable
  11. 11. El sistema debe permitir que muchos usuarios se conecten al mismo tiempo
  12. 12. Permitir que la factura de venta sea exportada
  13. 13. Que la base de datos soporte grandes cantidades de información</li></li></ul><li>Trabajo con requerimientos desde la IEEE<br /><ul><li>RequirementsProcess
  14. 14. RequirementsElicitation
  15. 15. RequirementsAnalysis
  16. 16. RequirementsSpecification
  17. 17. RequirementsValidations</li></li></ul><li>Somerville <br />Existen cuatro actividades genéricas dentro del proceso de la ingeniería de requerimientos<br />(1) Estudio de factibilidad del sistema, (2) obtención y análisis de requerimientos, (3) Especificación y documentación de los requerimientos, y (4) Validación de los requerimientos.<br />
  18. 18. Somerville <br />El Estudio de factibilidad es una descripción resumida del sistema y de cómo se utilizará dentro de una organización. Este estudio recomienda si es conveniente o no llevar a cabo la IR y el desarrollo del sistema propuesto. <br />Dicho en otras palabras nos ayuda a evaluar si el sistema: <br /><ul><li>Contribuye a los objetivos de la organización.
  19. 19. Se puede implementar con la tecnología actual dentro del costo y tiempo propuestos.
  20. 20. Puede integrarse a otros sistemas existentes dentro de la organización. </li></li></ul><li>Somerville <br />La obtención y análisis de requerimientos sirve para determinar el dominio del software cuales servicios debe proporcionar el sistema, así como su desempeño requerido, las restricciones de hardware, etc. <br />Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle. Las actividades que cubren son: <br /><ul><li>Comprensión del dominio
  21. 21. Recolección de requerimientos
  22. 22. Clasificación de requerimientos
  23. 23. Resolución de conflictos
  24. 24. Priorización
  25. 25. Verificación de requerimientos </li></li></ul><li>Somerville <br />La Especificación y documentación de los requerimientos se enfoca al proceso de documentación del comportamiento deseado del sistema. Es un acuerdo -entre usuarios y el equipo encargado del desarrollo del software- y debe tener al menos las siguientes características: <br /><ul><li>Contener todos los requerimientos deseados.
  26. 26. Cada requerimiento solo tiene una interpretación posible.
  27. 27. Planificación y Modelado Proceso de la Ingeniería de Requerimientos
  28. 28. Ingeniería en Sistemas Computacionales
  29. 29. El cumplimiento de cualquier requerimiento no provoque conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente.
  30. 30. Prioridades definidas. </li></li></ul><li>Somerville <br />Por último la actividad de validación de los requerimientos tiene mucho en común con el análisis, ya que implica encontrar problemas con los requerimientos. Sin embargo, son procesos distintos puesto que la validación comprende un bosquejo completo del documento de requerimientos mientras que el análisis implica trabajar con los requerimientos incompletos. <br />Durante esta actividad se deben llevar a cabo diferentes tipos de verificación en el documento de requerimientos que incluyen verificaciones de: <br /><ul><li>Validez
  31. 31. Consistencia
  32. 32. Integridad
  33. 33. Realismo
  34. 34. Verificabilidad </li></li></ul><li>Clasificación<br /><ul><li>Requerimientos de proceso
  35. 35. Requerimientos de usuarios
  36. 36. Requerimientos para el análisis y la negociación
  37. 37. Requerimientos para la gestión
  38. 38. Requerimientos del sistema
  39. 39. Requerimientos del equipo encargado del proyecto
  40. 40. Requerimientos de la organización</li></li></ul><li>
  41. 41. Tarea<br /><ul><li>Consultar la clasificación de los requerimientos
  42. 42. Elaborar el formato de levantamiento de requerimientos
  43. 43. Estudiar la primera unidad para examen
  44. 44. Avanzar en el proyecto:
  45. 45. Introducción
  46. 46. Presentación de la organización
  47. 47. Objetivo general
  48. 48. Objetivos específicos
  49. 49. Planteamiento del problema
  50. 50. Definición del problema
  51. 51. Metodología
  52. 52. Modelo y enfoque de desarrollo</li>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×