Ir al contenido principal

Proceso de Ingeniería de Requisitos

La ingeniería de requisitos se puede definir como
El proceso sistemático de desarrollar requisitos mediante un proceso iterativo y cooperativo de analizar el problema, documentar las observaciones resultantes en varios formatos de presentación y comprobar la precisión del conocimiento obtenido. (Durán, 2000).


Como lo menciona Durán, la ingeniería de requisitos implica un proceso en el cual se obtendrán los requisitos de un proyecto a desarrollar, donde se da la participación de usuario, clientes, desarrolladores entre otros, los resultados serán presentados en un documento donde se intentará describir de la mejor manera el producto a desarrollar. 
El proceso normalmente tiene distintas etapas que lo conforman, las cuales se presentan a continuación.
Obtención o Extracción de Requisitos: Esta es la etapa inicial y de mayor importancia, aquí es donde los usuarios o los clientes hablan directamente con el equipo de desarrollo para indicarles cuales son los servicios, características, rendimientos o necesidades que el producto o sistema tiene que cubrir. Se utilizan diversas técnicas para la recopilación de los requisitos como son las entrevistas, reuniones o conversaciones con los usuarios finales que no necesariamente son los que financian el proyecto.

Análisis de Requisitos: Se analiza lo obtenido en la etapa anterior con el fin de buscar posibles errores, incongruencias o inconsistencias que presenten los requisitos. En esta parte se crean modelos y prototipos, de esta manera se va formando un diseño del producto. Dicho diseño le permite al equipo y desarrolladores tener una idea de lo que el cliente desea y determinar cuál es el alcance del proyecto.

Verificar los Requisitos: Esta es una fase de control de calidad, se encarga de verificar que estén presentes todos los requisitos necesarios para poder desarrollar el sistema, incluyendo los de hardware y plataforma (software) donde funcionara u otras restricciones que pueda tener. Otra labor es la búsqueda de posibles errores de los análisis anteriores, para garantizar la correcta implementación de los requisitos.

Validar los Requisitos: Finalizada la verificación, los requisitos pasan a validarse para comprobar que describen y satisfacen las necesidades que el cliente indicó en las etapas previas.

Gestión de Requisitos: En esta etapa se evalúan los cambios de requisitos solicitados, para determinar su influencia en el resto de los requisitos y de esta manera determinar el impacto que causara este cambio en el proyecto. Así se puede tener un control y protección de los requisitos, esto permite no generar un cambio que pueda llegar a causar graves problemas en otras etapas del desarrollo.

Las etapas anteriores nos describen el proceso de la ingeniería de requisitos; nos muestran las pautas que se siguen para extraer, analizar, formular y gestionar los requisitos que necesita un proyecto para su correcto desarrollo, de esta manera lograr cumplir con las necesidades y expectativas que el cliente espera y disminuir los problemas en el desarrollo causados por la falta de información o entendimiento del proyecto.

Comentarios

Entradas populares de este blog

Diagrama de Secuencia del Sistema (DSS)

Existen diferentes formas de explicar un sistema de software que se esté desarrollando, por ejemplo, los casos de uso, estos nos muestran una función específica que realiza el sistema, pero estos pueden ser explicados de una forma diferente por medio de los diagramas de secuencia del sistema. Los DSS es un modelo que muestra al sistema como una caja negra para un caso de uso específico, donde se muestran los actores externos que participan en él, también el orden de los eventos que suceden durante la ejecución del caso de uso. Se dice que debería haber un DSS para cada caso de uso de un proyecto de software, esto debido a que cada DSS se deriva directamente de un caso de uso. Se puede decir que los DSS explican los casos de uso de una forma diferente mostrando las secuencias de eventos que suceden en los casos de uso, estas secuencias comúnmente inician con un verbo, ya que describen una acción que sucede. En los diagramas como tal, el tiempo avanza hacia abajo respetando el

Requerimientos Volátiles y Estables

Los requerimientos de un proyecto de software se pueden clasificar de formas distintas por ejemplo cuando identificamos los requisitos funcionales, no funcionales y los de información, pero también es posible clasificarlos de una forma distinta, más específicamente en volátiles y estables. Requerimientos Volátiles: Estos requisitos volátiles (Cambiantes) tienen una alta probabilidad de sufrir cambios durante el proceso de desarrollo del software, pero también pueden cambiar fuera de dicho proceso cuando el software está terminado o incluso cuando ya está en uso por parte del usuario. Estos requisitos tienen subclasificaciones ya que son muy diversos, los cuales son los siguientes. ·          Mutables: Reciben este nombre los requisitos que se ven afectados por cambios que puedan presentarse en el ambiente con el que opera la organización. ·          Emergentes: Estos aparecen cuando el proceso de diseño de los requerimientos, facilitan el entendimiento del sistema y le perm

StakeHolders

La palabra stakeholders se utiliza para definir a las personas, grupo de personas o empresas que están interesados en un proyecto especifico, en nuestro caso un proyecto de software. El termino stakeholders se puede traducir como “interesados”, estos interesados son empresas o personas que tienen relación de alguna forma con el proyecto y no necesariamente trabajan en el. Algunos ejemplos son los siguientes: Empresas y Organizaciones: En algunos casos los proyectos necesitan de la aprobación de otras empresas u organizaciones para poder desarrollarlo, como financiamientos, seguros, aprobación de licencias etc. Usuarios: Son las personas a las cual va dirigido el proyecto, son los usuarios del programa informático en un proyecto de software, estas personas pueden estar de acuerdo o en desacuerdo con el proyecto. Afectados: Son personas u organizaciones que están indirectamente involucrados en el proyecto, y tampoco son el objetivo de los resultados del proyecto, p