Your SlideShare is downloading. ×
0
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Requerimientos de Información
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Requerimientos de Información

11,026

Published on

Captura de requerimientos

Captura de requerimientos

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
11,026
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
104
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Proyecto de Sistemas de Información Ing. Julio César Álvarez Reyes [email_address] http://juliozet.blogspot.com www.twitter.com/juliozet
  • 2. Sesión Nro. 3 Contenido. <ul><li>Análisis de Requerimientos. </li></ul>
  • 3. IEEE-Estándar 830: Introducción <ul><li>Definiciones </li></ul><ul><li>Contrato: Incluye lo requisitos técnicos y requerimientos de la organización, costo y tiempo para un producto. </li></ul><ul><li>Cliente: La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos. </li></ul><ul><li>Proveedor: La persona (s) que producen un producto para un cliente. </li></ul><ul><li>Usuario: La persona (s) que operan o actúan recíprocamente directamente con el producto. El usuario (s) y el cliente (s) no es (son) a menudo la (s) misma (s) persona (s). </li></ul><ul><li>¿Qué es un Requisito de software? </li></ul><ul><li>Un requisito de software es una especificación de lo que se debería implementar. Existen básicamente dos tipos de requisitos (funcionales y no funcionales). Son una declaración de lo que debería hacer un sistema y no como lo debería hacer. </li></ul><ul><li>Es un conjunto de condiciones o capacidades que pueden ser esenciales, necesarias o deseadas y que es satisfecha por un sistema de software o componente con la finalidad de satisfacer un contrato u otro documento formal . </li></ul><ul><li>Los requisitos deben ser INEQUIVOCOS, CONSISTENTES Y COMPROBABLES </li></ul>
  • 4. IEEE-Estándar 830: Introducción <ul><li>Problemas de la especificación de requisitos de software (SRS) </li></ul><ul><li>Los problemas de la SRS son: </li></ul><ul><li>Funcionalidad: se encuentran incompletos, erróneos o ambiguos. </li></ul><ul><li>Interfaces externas: no han identificados completamente involucrados (personas), hardware del sistemas, hardware de otros sistemas y otros software. </li></ul><ul><li>Atributos de calidad: estos se encuentran incompletos y/o sin criterios de aceptación por ejemplo tenemos rendimiento, portabilidad y otros. </li></ul><ul><li>Restricciones de diseño: como estándares, procedimientos, normas, idiomas, etc. </li></ul><ul><li>No administrados: problemas con el control de cambios y falta de capacidad de trazabilidad. </li></ul>
  • 5. IEEE-Estándar 830: Introducción <ul><li>Estos problemas impactan en el presupuesto, calidad, plazos y en necesidades insatisfechas. </li></ul>
  • 6. IEEE-Estándar 830: Introducción <ul><li>a) Consideraciones para producir un buen SRS. Naturaleza del SRS: SRS son especificaciones para un producto de software </li></ul><ul><li>b) Ambiente del SRS: Es importante considerar la parte que el SRS representa en el diseño del proyecto total y es parte del ciclo de vida del software. </li></ul><ul><li>c) Características de un buen SRS: </li></ul><ul><li>Correcto </li></ul><ul><li>Inequívoco </li></ul><ul><li>Completo </li></ul><ul><li>Consistente </li></ul><ul><li>Establecer su importancia </li></ul><ul><li>Comprobable </li></ul><ul><li>Modificable </li></ul><ul><li>Identificable. </li></ul>
  • 7. IEEE-Estándar 830: Introducción d) Preparación conjunta del SRS: El proceso de desarrollo de software debe empezar con el acuerdo entre el proveedor y cliente acerca de lo que el software deberá hacer. Este acuerdo, en la forma de un SRS, debe prepararse conjuntamente. Esto es importante porque ni el cliente ni el proveedor son calificables para escribir exclusivamente un buen SRS. e) Evolución de SRS: Gestión de cambios a los requisitos del software. f) Prototipos: Un prototipo debe usarse como una manera de sacar los requisitos del software. Pueden extraerse algunas características de pantallas y/o reportes.
  • 8. IEEE-Estándar 830: Introducción <ul><li>Partes de un SRS </li></ul><ul><li>Las partes del SRS se muestran en el cuadro. </li></ul><ul><li>Un SRS no tiene porque usar los nombres mostrados en el siguiente cuadro, pero si un buen SRS debe incluir toda la información que se menciona aquí. </li></ul>

×