3.3 Actividades de apropiación del conocimiento (Conceptualización y Teorización)
Es la disciplina que se basa en las necesidades y condiciones del cliente a satisfacer en un software.
El fin de la ingeniería de requerimientos es generar especificaciones correctas (claras, precisas, concisas y sin ambigüedades), para esto se debe tener en cuenta que cada requerimiento tiene unos requisitos que también deben ser tomados en cuenta.
Se dividen en tres:
Estos requerimiento son propiedades emergentes como por ejemplo ; la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.
Estos requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.
SRS / ERS Estándar IEEE 830-1998
Conjunto de recomendaciones para la especificación de los requerimientos o requisitos de software el cuál tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas.
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 preveén que los usuarios tendrán con el software. También contiene requisitos 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 de software están descritas por el estándar IEEE 830 -1998. Este estándar describe las estructuras posibles, contenido deseable y calidades de una especificación de requisitos del software.
De esta manera se documenta todo lo relacionado con el desarrollo del proyecto para evitar en errores en su proceso.
Sin Los requerimientos no se evalúa correctamente lo que desea el cliente, o se concibe en la mente ideas distintas a las requeridas en una primera instancia.
Un sistema debe contener esta condición para poder satisfacer un contrato, estándar, especificación u otra documentación formalmente establecida.
Se obtienen problemas en el desarrollo de un proyecto al no realizar un estudio previo de los requisitos del usuario, no hacer una definición completa del alcance del proyecto. No realizar el modelado del negocio antes de desarrollar el software, esto significa que el analista no se involucra en el problema, cuando esto sucede se corre el riesgo de que los requisitos identificados no correspondan a las necesidades para lo que se debe crear.
No involucrar al usuario activamente en el desarrollo del producto “UNA BUENA PRACTICA SERIA MODELAR JUNTO AL CLIENTE”.
No se realizan estimaciones realistas.
Los requerimientos son importantes debido a que son el hilo conductor de todo desarrollo de software.
Obtener requerimientos de calidad demuestra que el trabajo realizado culminará con éxito, esto se debe a dos factores:
1. La utilización adecuada de las técnicas de captura de requerimientos con los clientes.
2.Las experiencias de los analistas del proyecto.
http://kuainasi.ciens.ucv.ve/red_educativa/blogs/20
Pieza clave para una exitosa gestión del alcance.
“Si no logramos saber o bien, no logramos expresar los requerimientos que deben tener un producto, servicio o resultado, estaremos navegando sin saber con certeza cuál es el puerto al cual debemos llegar, quien nos espera y que es lo que espera que llevemos en nuestra embarcación.”
https://bsgrupo.com/bs-campus/blog/La-Importancia-de-los-Requerimientos-en-un-Proyecto-17
Es una serie de ideas o de especificaciones de los requerimientos las cuales tiene como fin el listado de las actividades que desea el cliente para cumplir con todas las expectativas las ideas solicitadas.
Es un documento que describe exactamente qué es lo que se debe construir además incluye solamente los requerimientos del producto.
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.
Los requerimientos no funcionales, atributos de calidad o cualidades del software suelen ser la principal causa de grandes, complejos y costosos cambios a los sistemas de software. Usualmente no se los tiene en cuenta y cuando se lo hacen, las descripciones de estos requerimientos suelen ser confusas y ambiguas.
Requerimientos no funcionales: describen una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. Restringen los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Los requerimientos no funcionales ponen límites y restricciones al sistema.
Prototipos desechables
Ahora, ¿por qué prototipos desechables y no prototipos evolutivos? La razón es muy sencilla: el objetivo de los prototipos evolutivos es entregar un sistema en funcionamiento al cliente, en tanto que el objetivo de los prototipos desechables es obtener y/o validar los requerimientos.
Una descripción general de la metodología:
1ra reunión Negocio detrás del sistema Requerimientos en general
Listar los interesados.
Desarrollar el 1er prototipo.
Siguiente reunión Validar los requerimientos contra el prototipo Tal vez modificar el prototipo Obtener otros requerimientos
Más requerimientos obtener Errores en el prototipo
Desarrollar un nuevo prototipo
Todo listo
Fin Pasar los requerimientos a los diseñadores
La capacidad de comunicar nuestras necesidades y deseos es una de las actividades más básicas de la vida. La comunicación implica un intercambio de información entre un emisor y un receptor. Es una calle con dos direcciones -tanto el emisor como el receptor son necesarios para que se produzca el contacto. Para que sea efectiva ambos necesitan entender el mensaje que se transmite y el método que se usa para eso.
Los medios de comunicación son el vinculo, forma o procedimiento por el cual se transmiten las ideas y los conceptos dentro de la dinámica del proceso y para la consecución de los fines de éste.
Es el lazo por el cual se exteriorizan peticiones, informaciones, ordenes de acatamiento obligatorio dentro del desenvolvimiento del proceso y para la culminación del mismo.
Un claro ejemplo de modelado de objetos es UML ya que este integra el modelo de objetos, dinámico y funcional del desarrollo de un programa informático.
El modelo objetos: que es la parte que describe la estructura estética del diagrama y nos permite leer con mayor comodidad y entendimiento cualquier proceso (en otras palabras nos explica sobre que entidades sucede los procesos que se llevan o se llevaran a cabo).
El modelo dinámico: Con la que se describe las relaciones temporales entre objetos para saber cuál es el comportamiento que tiene el sistema a lo largo del tiempo (en otras palabras nos especifica cuando sucede lo que se lleva a cabo).
El modelo funcional: Que es el que describe las relaciones funcionales entre valores (en otras palabras nos indica que es lo que sucede al llevarse a cabo).
Ingenieria de requerimientos 