REPUBLICA BOLIVARIANA DE VENEZUELA I.UP. “SANTIAGO MARIÑO” ESCUELA DE INGENIERIA DE SISTEMAS MATURIN ESTADO MONAGAS
Profesora:
Autor:
Germania Briceño
Alfonzo Yurianny
Maturín, Noviembre 2011
C.I.: 20.647.053
INDICE
1.
¿Qué son los requerimientos?................................................................ ............................................. 3
2.
¿Qué es la ingeniería de requisitos o requerimientos?....................................... ................................ 3
3.
¿Cuáles son las características de los requerimientos?...................................... ................................ 4
4.
Explique algunas técnicas de recolección de requerimientos ............................ 5
Entrevistas ................................................................................................ ................................ .................................................. 5 Talleres ................................................................................................ ................................ ....................................................... 5 Forma de contrato ................................................................................................ ...................................... 6 Prototipos................................................................................................ ................................ .................................................... 6 Casos de uso ................................................................................................ ................................ ................................................ 6 5.
Explique los tipos de requerimientos ................................................................ ................................. 8
6.
¿Qué es la especificación de requerimientos? .................................................... ................................ 8
Bibliografía ................................................................................................ ................................ ................................................10
2
1. ¿Qué son los requerimientos? 1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especific especificación u otro documento formal. 3) Una representación documentada de una condición o capacidad como en (1) o (2). (2) Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software.
2. ¿Qué es la ingeniería de requisitos o requerimientos? La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, H esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los
3
buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc. etc
3. ¿Cuáles son las características de los requerimientos? Características de los requerimientos Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información ación suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. interpretación El lenguaje usado en su definición, no debe causar confusiones al lector.
4
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, análisis demostración o pruebas.
4. Explique algunas técnicas de recolección de requerimientos Algunas técnicas que podemos destacar en la recolección de requerimientos son: Entrevistas Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo uevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar trabajar con los mismos para corregir sus fallos.
Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las
5
personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas.
Forma de contrato En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Prototipos Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
Casos de uso Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra,, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades enti externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales.
6
A continuación se prresenta un cuadro comparativo de las ventajjas y desventajas de las técnicas utilizadass en la ingeniería de requerimientos:
Técnica
Entrevistas y Cuestionarios
Ventajas
• • • •
Lluvia de Ideas
•
•
Prototipos
• •
Análisis Jerárquico
• • •
Casos de Uso
• • •
Desventajas
Mediante ellas se obtiene una gran • cantidad de información correcta a través del usuario. • Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten com combinarse con otras técnicas.
La información obtenida al principio puede ser redundante o incompleta. Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.
Los diferentes puntos de vista y las • confusiones confusi en cuento a terminología, son aclaradas por expertos. Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.
Es necesaria una buena compenetración del grupo participante.
Ayudan a validar y desarrollar nuevos • requerimientos. Permite comprender aquellos requerimientos que no están muy • claros y que son de alta volatilidad
El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado. A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo
Permite determinar el grado de importancia de cada requerimiento. Ayuda a identificar conflictos en los requerimientos. Muestra el orden en que deben ser implementados los requerimientos.
•
Representan Repr los requerimientos desde • el punto de vista del usuario. Permiten representar más de un rol • para cada afectado. Identifica requerimientos estancados, dentro de un conjunto de requerimientos.
Debe construirse un estándar claro de evaluación, evaluación que incluya la participación del cliente.
En sistemas grandes, toma mucho tiempo definir todos los casos de uso. El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.
7
5. Explique xplique los tipos de requerimientos Los tipos de requerim mientos pueden ser:
Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.
No funcionales: son los "recursos" para que trabaje el sistema de información (redes, redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.
6. ¿Qué es la especificación de requerimientos?
Una especificación ddee requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos requisito no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño). Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. 830 1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.
8
En el proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se enfrenta al problema de la identificación de requisitos. La definición de las necesidades del sistema es un proceso complejo, pues en él hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. Existe en cambio un conjunto de técnicas, cuyo uso proponen las diferentes tes metodologías para el desarrollo de aplicaciones web. Se debe tener en cuenta que la selección de las técnicas y el éxito de los resultados que se obtengan, depende en gran medida tanto del equipo de análisis y desarrollo, como de los propios clientes clientes o usuarios que en ella participen.
El proceso comienza con la realización de la captura de requisitos, el grupo de técnicos
toma
la
información
suministradaa por los usuarios y clientes. Esta información puede provenir de fuentes
muy
aplicaciones
diversas: existentes,
documentos, a
través
de
entrevistas, etc. En base a esta información, el equipo de desarrollo elabora el catálogo de requisitos. Finalmente con la validación de requisitos se realiza la valoración de los mismos, comprobando si existen inconsistencias, errores erro o si faltan requisitos por definir. El proceso de definición-validación validación es iterativo y en algunos proyectos complejos resulta necesario ario ejecutarlo varias veces.
9
Bibliografía
• •
IEEE Std 830 830-1998 1998 IEEE Recommended Practice for Software Requirements Specifications –Description. McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules, 1st ed., Redmond, WA: Microsoft Press. ISBN 1-55615900-5..
Direcciones electrónicas sobre este tema • • •
IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html .links.html Software Engineering Resources by Roger S. Pressman & Associates Inc. http://www.rspa.com/spi/index.html Lista de publicaciones de un grupo de Ingeniería de Software. http://www.soi.city.ac.uk/~gespan/sw_group_pub.htm http://www.soi.city.ac.uk/~gespan/sw_group_pub.html
10