<?xml version="1.0" encoding="UTF-8" ?><!-- generator=Zoho Sites --><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><atom:link href="https://www.allsoft.com.mx/blogs/tag/Requerimientos/feed" rel="self" type="application/rss+xml"/><title>ALLSOFT - Blog Allsoft #Requerimientos</title><description>ALLSOFT - Blog Allsoft #Requerimientos</description><link>https://www.allsoft.com.mx/blogs/tag/Requerimientos</link><lastBuildDate>Tue, 12 May 2026 09:36:20 -0700</lastBuildDate><generator>http://zoho.com/sites/</generator><item><title><![CDATA[Un cambio que quita requerimientos]]></title><link>https://www.allsoft.com.mx/blogs/post/un-cambio-que-quita-requerimientos</link><description><![CDATA[Un cambio que quita requerimientos puede ser igual de complicado que uno que añade un requerimiento si estamos en una etapa avanzada. Entre las cosas ]]></description><content:encoded><![CDATA[<div class="zpcontent-container blogpost-container "><div data-element-id="elm_4abh7Dy2RUqhGM1qYtzPmQ" data-element-type="section" class="zpsection "><style type="text/css"></style><div class="zpcontainer-fluid zpcontainer"><div data-element-id="elm_1Qmp6rHMQTKNi-8bJlAHpA" data-element-type="row" class="zprow zprow-container zpalign-items- zpjustify-content- " data-equal-column=""><style type="text/css"></style><div data-element-id="elm_ipDsVtamSY-C628wP3GXeg" data-element-type="column" class="zpelem-col zpcol-12 zpcol-md-12 zpcol-sm-12 zpalign-self- "><style type="text/css"></style><div data-element-id="elm_abjOmTHKSKmWeVqO-OwY1A" data-element-type="text" class="zpelement zpelem-text "><style></style><div class="zptext zptext-align-center " data-editor="true"><div>Un cambio que quita requerimientos puede ser igual de complicado que uno que añade un requerimiento si estamos en una etapa avanzada. Entre las cosas que hay que observar en el impacto es la modificación a los requerimientos, los planes, las pruebas, los diseños, etc para dejar el producto congruente con la documentación y su diseño. El impacto que resulte de dicho cambio lo debe de autorizar el comité de cambios así como el usuario. Este tipo de cambio no quiere decir que vamos a dejar de hacer actividades relacionadas con lo que se quitó, debemos de dejar los productos acorde con las nuevas circunstancias y comunicarlos.</div></div>
</div></div></div></div></div></div> ]]></content:encoded><pubDate>Fri, 07 Nov 2008 23:55:00 -0600</pubDate></item><item><title><![CDATA[Bases para el Desarrollo]]></title><link>https://www.allsoft.com.mx/blogs/post/bases-para-el-desarrollo</link><description><![CDATA[Es muy frecuente que no se documenten correctamente los requerimientos y que estos sean acordados formalmente. Sucede porque no tenemos tiempo de docu ]]></description><content:encoded><![CDATA[<div class="zpcontent-container blogpost-container "><div data-element-id="elm_gZUYj454SXOui4PSkurXUw" data-element-type="section" class="zpsection "><style type="text/css"></style><div class="zpcontainer-fluid zpcontainer"><div data-element-id="elm_-Cn2dyXTSgaw__lsjILI_w" data-element-type="row" class="zprow zprow-container zpalign-items- zpjustify-content- " data-equal-column=""><style type="text/css"></style><div data-element-id="elm_Z6nCTtYkSw-Y8XjrBWG92A" data-element-type="column" class="zpelem-col zpcol-12 zpcol-md-12 zpcol-sm-12 zpalign-self- "><style type="text/css"></style><div data-element-id="elm_vMeatj8sR9O8WqOlTO760Q" data-element-type="text" class="zpelement zpelem-text "><style></style><div class="zptext zptext-align-center " data-editor="true"><div>Es muy frecuente que no se documenten correctamente los requerimientos y que estos sean acordados formalmente. Sucede porque no tenemos tiempo de documentar lo que el usuario quiere y brincamos directamente a diseñar o a programar con las consecuentes fallas. Al ser esta la primera etapa del proceso de desarrollo esta también es la primera oportunidad de incluir errores por lo que debemos de tomar las medidas necesarias para realizarla correctamente. Para hacer bien esta tarea debemos de tener los elementos para ello, como las personas adecuadas para la obtención de los requerimientos, capacitadas en los métodos, el proceso y los artefactos a desarrollar. Debemos no solo de dejar documentados los requerimientos sino tratar de identificar todo aquello que esta entre líneas y que el usuario no nos transmite, que al considerarlos completos alguien los revise para ver si se pueden implementar, si están completos, claros y consistentes. Con un conjunto de requerimientos documentados, completos y revisados, podemos establecer un compromiso con el cliente y con el equipo, lo que nos permite tener una base para el trabajo posterior. Aquí encontramos otro problema, no todos queremos asumir este compromiso. Si se nos olvida algo, ¿Cómo puedo cambiarlo?. El obtener un compromiso sobre los requerimientos no significa que estos ya no se puedan cambiar, es imposible conocer con anticipación todo lo que pudiera hacer el nuevo producto o los cambios en el mercado. Lo que debemos hacer después de este compromiso es realizar los cambios de manera formal y controlada, es decir, cada requerimiento de cambio deberá ser analizado en su impacto en el proyecto y como estos pueden ser incorporados sin que el proyecto salga de control. Con un buen proceso de obtención de requerimientos y una buena administración de los mismos podemos establecer las bases hacia una planificación, estimación y desarrollo del producto más estable y con mayores probabilidades de éxito.</div></div>
</div></div></div></div></div></div> ]]></content:encoded><pubDate>Sat, 23 Sep 2006 16:05:00 -0500</pubDate></item></channel></rss>