7 Técnicas de levantamiento de requerimientos software

¿Quieres dominar el análisis de requerimientos de software? El curso Recolección y análisis de requerimientos de software 📚💻 en Udemy es tu camino hacia el éxito. ¡Inscríbete hoy! 🎓🚀

  

Una etapa fundamental en proyectos de ingeniería de software, es la identificación y documentación de los requerimientos del futuro sistema al comienzo del proyecto, pues en numerosas ocasiones se ha demostrado que es cuando pueden prevenirse errores que puedan significar el fracaso del proyecto.

En la Ingeniería de requisitos, el levantamiento de requerimientos se refiere a la identificación y documentación de los requerimientos de un sistema, a partir de los usuarios, clientes o interesados (Stakeholders). A la práctica también se le conoce como Recopilación de requerimientos.

En este artículo te compartimos 7 técnicas para realizar el levantamiento de requerimientos de software, entre ellas las de Análisis de documentación, observación, entrevistas, cuestionarios, mesas de trabajo, tormentas de ideas e historias de usuario.

PMOInformatica, La oficina de proyectos de informática presenta: 7 Técnicas para obtener requerimientos en proyectos de ingeniería de software.

Requerimientos no funcionales: Ejemplos

Perfecciona el análisis de requerimientos mediante técnicas como la observación🔍, entrevistas🗣️, talleres📚, los cuestionarios📝 y el modelado💻. Inscríbete en el curso 🎓👍 Recolección y análisis de requerimientos de software en Udemy.

Los requerimientos no funcionales representan características generales y restricciones de la aplicación o sistema que se esté desarrollando. En esta tercera parte de nuestra serie sobre los requerimientos no funcionales, presentamos algunos ejemplos que puedan servir de guía en su definición.

Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición con criterios de aceptación que se puedan medir.

Entre los ejemplos de requerimientos no funcionales presentados, tenemos los referidos a atributos como la eficiencia, seguridad, dependibilidad y usabilidad del sistema. También presentamos ejemplos de requerimientos no funcionales organizacionales y externos.

PMOInformatica presenta: Ejemplos de requerimientos no funcionales.

Ejemplo de diagrama de casos de uso

El curso UML para analistas de negocios 🎓en Udemy te proporciona las herramientas necesarias para sobresalir en el análisis de negocios. Aprende a utilizar UML para modelar sistemas de negocio y prepárate para el éxito. ¡Inscríbete hoy! 🚀

  

Un diagrama de casos de uso tiene la función de representar de forma gráfica cuales son las funcionalidades de un sistema y las interacciones con los usuarios. Para ello se vale de elementos como el actor, casos de uso, relaciones actor caso de uso y las relaciones entre casos de uso.

Este artículo es la tercera entrega de nuestra serie sobre el diagrama de casos de uso. Aquí te mostraremos un ejemplo sobre como representar las interacciones en un sistema para una clínica médica, donde intervienen actores como el paciente, el médico y los empleados. Asimismo, representa funcionalidades de un sistema de clínica como podrían ser emitir una receta, marcar una consulta y realizar pagos.

Elementos del diagrama de casos de uso

La función principal del diagrama de casos de uso es representar los requerimientos de software bajo un lenguaje común entre desarrolladores de software y clientes. Para ello, utilizan los elementos del diagrama de casos de uso que son el actor, los casos de uso y las relaciones.

Otro elemento importante de los casos de uso son las relaciones que pueden darse entre actores y casos de uso. Cuando la relación es actor con caso de uso, esta define si el actor es pasivo o activo, mientras que las relaciones entre casos de uso pueden ser de generalización, inclusión o extensión.

Este artículo es la segunda parte de nuestra serie dedicada al diagrama de casos de uso, en esta nos enfocaremos en los elementos mencionados.

¡Eleva tus habilidades de programación con el curso JavaScript Moderno Guía Definitiva Construye +20 Proyectos 🌟 Aprende JavaScript, el lenguaje esencial del web, y crea más de 20 proyectos reales. ¡Incluye un proyecto MongoDB, Express, React y Node.js (MERN) Full Stack para que te conviertas en un experto! 💻 

Diagrama de casos de uso: Definición

 
Un factor clave para el éxito de proyectos de desarrollo de software, es lograr hacer una representación correcta, exacta y sin omisiones, de las funciones que debe ejecutar un sistema para satisfacer los requerimientos de clientes y usuarios. En esto, una de las técnicas de mayor difusión en el ámbito académico y empresarial es el Diagrama de casos de uso.

La principal ventaja que ofrece esta técnica es que establece un lenguaje común entre desarrolladores, expertos en arquitectura de software y lenguajes de programación, con los usuarios finales que están proporcionando el levantamiento de información.

Los usuarios finales, en la gran mayoría de los casos, no son expertos en software o arquitectura técnica, pero sí lo son en sus dominios de negocio que el nuevo sistema o software debe apoyar. Por tanto es fundamental la comunicación entre ambos grupos.

Este es el primero de una serie de artículos donde explicaremos que son los casos de uso, en qué consisten los diagramas de casos de uso y cómo se elaboran.

¿Cómo hacer el diagrama de casos de uso?

Los casos de uso se elaboran a partir de las descripciones del funcionamiento del futuro sistema, proporcionado por sus usuarios o clientes. Estas descripciones suelen estar en minutas de reunión, definiciones de alcance o matrices de trazabilidad de requerimiento elaboradas en la fase de levantamiento de información del proyecto o iteración.

Esta es la cuarta entrega de nuestra serie sobre el diagrama de casos de uso. En esta, te mostraremos un procedimiento sencillo que puedes aplicar para elaborarlos a partir de la documentación de requerimientos o las minutas de las reuniones con clientes y usuarios. Asimismo, describiremos que es la especificación de casos de uso y como complementa está a los diagramas.

8 Técnicas de análisis de requerimientos de software

Designed by Freepik

En la Ingeniería de requisitos, el análisis de los requerimientos del software es la etapa que sigue después que estos han sido levantados y documentados en un registro o matriz de trazabilidad.

La especificación de requerimientos, es una actividad que cada vez toma mayor preponderancia en la gerencia de proyectos, dado que se ha demostrado que una causa recurrente en su fracaso se origina de una inadecuada especificación de requisitos.

Con este artículo, continuamos nuestra serie de Ingeniería de requisitos, continuando con los conceptos desarrollados en el artículo anterior de 7 Técnicas para el levantamiento de requerimientos de software.

Perfecciona el análisis de requerimientos mediante técnicas como la observación🔍, entrevistas🗣️, talleres📚, los cuestionarios📝 y el modelado💻. Inscríbete en el curso 🎓👍 Recolección y análisis de requerimientos de software en Udemy.

El análisis de requerimientos consiste en aplicar una serie de técnicas para desglosar y analizar los requisitos y sus partes, algunas de estas técnicas son: Modelado de procesos, Modelado de dominio, casos de uso, inspecciones, listas de chequeo y prototipos.

PMOInformatica presenta: 8 Técnicas para analizar requerimientos de software

Pruebas de aceptación de software según el ISTQB

Designed by Freepik

En la Ingeniería del software, las pruebas de aceptación se realizan para establecer el grado de confianza en un sistema, partes del mismo o en sus características no funcionales.

La confianza en el sistema estará determinada por su grado de adherencia a las necesidades, requerimientos y procesos de negocio solicitados por el usuario o cliente. Es en función a estos que el usuario debe decidir si acepta o no el sistema que le está siendo entregado.

Por lo tanto, las pruebas de aceptación suelen ser responsabilidad de los clientes o usuarios del sistema. Otros interesados del proyecto pueden involucrarse también.

En este artículo te presentamos los diversos aspectos que definen que son las pruebas de aceptación de software, incluyendo a partir de que se define, sobre qué aspectos se realizan y cuáles son las clases de pruebas de aceptación.

Requerimientos funcionales: Los niveles de granularidad

Este artículo es una contribución de Carlos Eduardo Vazquez y Guilherme Siqueira Simões y Gustavo Siqueira Simões de FATTO, empresa de Consultoría y Sistemas referente en la medición, estimación y requisitos de software. Este contenido forma parte de su Curso Online de Ingeniería de requisitos.

Imagen de: iStockPhoto / Brillianata

En la Ingeniería de requerimientos y en el desarrollo de software, el nivel de granularidad es la mayor o menor amplitud de la descripción del comportamiento esperado para el software en una especificación funcional.

En esencia, la granularidad define que tan detallada o tan general es la descripción de una funcionalidad de software.

Las distintas etapas de un proyecto de desarrollo de software requieren distintos niveles de granularidad en la descripción de los requisitos funcionales: En etapas tempranas del proyecto, se requiere una visión amplia del alcance, mientras que en etapas avanzadas se necesita tener un nivel de granularidad mayor, es decir, una visión profunda del software.

En este artículo presentamos los distintos niveles de granularidad que se pueden definir para requisitos funcionales (RF), según su objetivo sea de usuario, agregado o de subfunción.

Presentamos a continuación el artículo Los niveles de granularidad en los requerimientos funcionales.

Requerimientos no funcionales: Una clasificación

Los requerimientos no funcionales son los que especifican criterios para evaluar la operación de un servicio de tecnología de información, en contraste con los requerimientos funcionales que especifican los comportamientos específicos de las aplicaciones.

En la primera parte de esta serie, describíamos una definición de requerimientos no funcionales y porque son importantes.

Los requerimientos no funcionales definen las características o cualidades generales que se esperan de un sistema y establecen restricciones sobre el producto, el proceso de desarrollo de software y establecen restricciones externas que el software debe lograr.

Para poder identificar estas características durante la ingeniería de requisitos que realizan los Analistas de sistemas e Ingenieros de software en todo proyecto de desarrollo, es útil contar con una clasificación que nos establezca un marco de los tipos de requerimientos no funcionales con que nos podemos encontrar.

PMOinformatica presenta una clasificación de los requerimientos no funcionales a continuación.

Plantilla de casos de uso

Imagen de: PMOInformatica.com

En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.

En el ámbito académico y profesional, es una de las técnicas de mayor difusión para especificar el comportamiento del Sistema. Para su documentación a menudo es útil contar con una Plantilla de Casos de Uso, en la cual esta preestablecido la metodología que vamos a utilizar para documentarlos.

La Plantilla de Casos de Uso, se documentan durante la fase de Levantamiento de Información y Análisis de Requerimientos en el Desarrollo de un Software. Al elaborar esta especificación, debería definirse el Modelo de Casos de Uso (el Diagrama), la especificación de cada uno de los actores del caso de uso y finalmente una especificación detallada de cada uno de los casos de uso.

Para una mayor organización estructurar de los requerimientos, estos se pueden organizar en grupos de funcionalidades o por módulos.

¡Eleva tus habilidades de programación con el curso JavaScript Moderno Guía Definitiva Construye +20 Proyectos 🌟 Aprende JavaScript, el lenguaje esencial del web, y crea más de 20 proyectos reales. ¡Incluye un proyecto MongoDB, Express, React y Node.js (MERN) Full Stack para que te conviertas en un experto! 💻 

PMOInformatica.com, La Oficina de Proyectos de Informática, presenta a continuación una Plantilla de Casos de Uso, la cual está libre de derechos de autor, y te invitamos a descargarla y usarla en tus proyectos académicos y profesionales.

Requerimientos No Funcionales: Porque son importantes

Todos los Servicios de Tecnología de Información (TI) en algún punto de su ciclo de vida, necesitan considerar los requerimientos no funcionales y las pruebas asociadas a los mismos.

Para algunos proyectos, estos requerimientos implican una cantidad considerable de trabajo y esfuerzos, mientras que para otros no.

Con frecuencia, los requerimientos no funcionales son ignorados o subestimados en la fase de análisis de requerimientos. El error, termina identificándose en la fase de implementación cuando remediarlos implica más trabajo y costo, pudiendo ocasionar que no sean adoptados por los usuarios y clientes.

En este artículo se presenta una definición de que son los requerimientos no funcionales de un servicio de tecnología de información o un sistema, se describen las categorías en las que pueden clasificarse, las posibles consecuencias de no definirlos en la fase de Diseño y algunos ejemplos de requerimientos no funcionales.

La gestión de requerimientos de software es fundamental para mantener los proyectos en alcance, tiempo y presupuesto. También para superar las expectativas del cliente. Inscríbete en el Curso Online de Ingeniería de requisitos

Errores comunes de programación: Segunda Parte

Imagen de: Picasa Web Albums

Anterior a este artículo publicamos “5 errores comunes de programación”, original del blog “Software Engineer de Techrepublic.com, el cual se describían algunas prácticas de programación erróneas. Luego de los comentarios recibidos de la comunidad, hemos decidido publicar una segunda parte, tomando en consideración las sugerencias de algunos usuarios y otras fuentes de información consultadas.

En este artículo se exploran cinco prácticas de programación que pueden ser problemáticas, abarcando la codificación sin un análisis previo, estructura inadecuada de módulos, codificación directa de variables (“Hard Coding”), omitir el manejo de excepciones y no documentar los comentarios en el código.

Presentamos a continuación, la segunda parte de la serie sobre “Errores de programación comunes”.

5 errores comunes de programación

Imagen de: Picasa Web Albums

El siguiente es un extracto del artículo “Five common programming mistakes”, publicado en el blog “Software Engineer” de Techrepublic.com, de fecha 12 de Septiembre de 2012. En este post, su autor (Justin James) describe algunas metidas de pata comunes en programación y explica porque estas pueden ser problemáticas.

Estos errores de programación son independientes del lenguaje de programación que se esté utilizando, y se han presentado con frecuencia al autor (Justin James) de manera que este considera que merecen especial atención.

Presentamos a continuación 5 errores de programación comunes.

El enfoque tradicional de desarrollo de sistemas

El enfoque tradicional de desarrollo de sistemas es estudiado ampliamente en medios académicos de la Ingeniería de software y es el denominado ciclo de vida de desarrollo de sistemas.

Bajo este enfoque:

• Se realiza el Análisis de requerimientos, Diseño, Desarrollo e Implantación secuencialmente. 
• La fase siguiente no comienza hasta completar la anterior. 

La siguiente imagen presenta un diagrama de este enfoque: