10729616
Beschreibung
Karteikarten von Eduardo Luis Martelo Polo, aktualisiert more than 1 year ago
|
Erstellt von Eduardo Luis Martelo Polo
vor etwa 7 Jahre
|
|
| Frage | Antworten |
| INTRODUCCIÓN | La especificación de requerimientos es quien definen los servicios que un sistema debe proveer y establece los limites y restricciones en las operaciones del mismo. En la actualidad, el conjunto de procesos y métodos que tienen por objetivo capturar y formalizar estos requerimientos se ha venido a denominar ingeniería de requerimientos. |
| ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (ERS) | Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad. Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo. |
| REQUERIMIENTOS | Los requerimientos para un sistema son La descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos. Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre estos diferentes niveles de descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario y requerimientos del sistema |
| LAS CARACTERÍSTICAS DE UNA BUENA ERS SON DEFINIDAS POR EL ESTÁNDAR IEEE 830-1998. UNA BUENA ERS DEBEN SER |
Image:
Iiieee (binary/octet-stream)
|
| CONCEPTOS DE LAS CARACTERÍSTICAS ERS | *No ambigua: Una ERS es no ambigua si y solo si cada requisito tiene una única interpretación. *Completa: Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas. *Consistente: Debe ser coherente con los propios requerimientos y también con otros documentos de especificación. *Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar. *Correcta: El software debe cumplir con los requisitos de la especificación. *Trazable: Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada. * Priorizable: Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales. *Modificable: Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable. *Verificable: Debe existir un método finito sin costo para poder probarlo. |
| TIPOS DE REQUISITOS | |
| REQUISITOS FUNCIONALES | Los requisitos funcionales de un sistema describen lo que el sistema debe hacer. Estos requisitos dependen del tipo de software que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo, los requerimientos funcionales del sistema describen con detalle la función de éste. |
| REQUISITOS NO FUNCIONALES | Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc. Los requisitos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente se aplican a características o servicios individuales del sistema |
| CLASIFICACIÓN DE LOS REQUERIMIENTOS NO FUNCIONALES | Requerimiento del producto: Estos requerimientos especifican el comportamiento del producto. Requerimientos Organizacionales: Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Requerimientos externos: Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. |
| REQUISITOS DEL SISTEMA | Establecen con detalle las funciones. Servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificación funcional) debe ser preciso. Debe definir exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el comprador del sistema y los desarrolladores del software. Son los componentes que el sistema debe tener para realizar determinadas tareas. |
| REQUISITOS DEL USUARIO | Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar. Necesidades que los usuarios expresan verbalmente. |
| REQUISITO FUNCIONAL IEE830 | Definición de acciones fundamentales que debe realizar el software al recibir información, procesarla y producir resultados. En ellas se incluye: ♣ Comprobación de validez de las entradas ♣ Secuencia exacta de operaciones ♣ Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperación de errores) ♣ Parámetros ♣ Generación de salidas ♣ Relaciones entre entradas y salidas (secuencias de entradas y salidas, fórmulas para la conversión de información) ♣ Especificación de los requisitos lógicos para la información que será almacenada en base de datos (tipo de información, requerido) |
| REQUISITO NO FUNCIONAL IEE830 | Rendimiento, Seguridad, Fiabilidad, Disponibilidad, Mantenibilidad, Portabilidad, Otros. |
| TÉCNICAS PRINCIPALES APLICADAS EN LA INGENIERÍA DE REQUISITOS |
Image:
Iiieee (binary/octet-stream)
|
| EJEMPLO DE REQUERIMIENTOS FUNCIONALES | Ejemplos de requerimientos funcionales de proceso o área de negocio El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente. Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos. Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema. El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de proyecto. El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto. |
| EJEMPLO DE REQUERIMIENTOS NO FUNCIONALES |
Image:
Iiieee (binary/octet-stream)
|
| EJEMPLO DE ESTRUCTURA DE (ERS) IEEE STD 830 (Y I) |
Image:
Iiieee (binary/octet-stream)
|
| EJEMPLO DE ESTRUCTURA DE (ERS) IEEE STD 830 (Y II) |
Image:
Iiieee (binary/octet-stream)
|
| CONCLUSIONES | Se debe recordar que la ingeniería de requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administración de proyectos, entre otros, el proceso de ingeniería de requerimientos no depende solamente de la forma como se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados. Es importante que el analista se tome el tiempo necesario para conocer a los clientes y usuarios, así como su ambiente de trabajo, ya que esto ayudara a establecer una buena relación de trabajo. |
| BIBLIOGRAFÍA | Ingeniería de Software. 5ta. Edición Sommerville, Ian Prentice-Hall, 2002 ISBN 970-26-0206-8 IEEE Recommended Practice for Software Requirements Specifications Software Engineering Standards Committee of the IEEE Computer Society ISBN 0-7381-0332-2 |
Möchten Sie mit GoConqr kostenlos Ihre eigenen Karteikarten erstellen? Mehr erfahren.