ANALISIS DE REQURIMIENTOS

Concepto de Requerimiento.

En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingenieria de sistemas o la ingenieria del software.

Requerimientos funcionales: 

Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.

Como se define en la ingenieria de requisitos, los requisitos funcionales establecen los comportamientos del sistema.

Requerimientos no funcionales:

Un requisito no funcional es, en la ingenieria de sistemas y la ingenieria de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

lo mas sobresaliente a mi criterio es la gestion de requerimientos y la forma como esta distribuida:

Reglas generales de la gestión de requerimientos

En la gestión de requerimientos como en el resto de las tareas en un proceso de ingeniería de software, que generalmente es más complejo de lo que uno quisiera, aplican una serie de reglas son útiles a la hora de tomar una decisión de qué hacer y que no hacer.

1. ORO: Mientras más simple mejor. Esta es como una moneda de oro, que tiene dos caras: por una cara manejar los requerimientos de la manera más sencilla posible hará más fácil la administración de los requerimientos. Por la otra cara, si no se recoge toda la información necesaria para la administración, la información que en las manos del responsable del proyecto es útil, pierde su aplicación al estar incompleta. Es decir, simple no es incompleta.
2. PLATA: La redundancia de información es siempre un problema. Un análisis no cuidadoso puede caer fácilmente en redundancia de información, colocando requerimientos del sistema o características de la solución como necesidades de la organización, o bien repitiendo información para rellenar los niveles de información comprometidos. El análisis de sistemas es, de por sí, un adelanto de la programación del sistema, en el que cada componente tiene una misión, y los componentes no está para construirlos una y otra vez, por el contrario se construyen una vez, se colocan en el lugar adecuado y se utilizan las veces que sean necesaria, esto es, los requerimientos se escriben una vez y se escriben de manera simple, se les da la clasificación adecuada, y se trazan las veces necesarias.
3. BRONCE: Los requerimientos no desaparecen porque no se tengan en cuenta. En física, la ley de la conservación de la materia enuncia: "la materia no se crea ni se destruye, se transforma", en ingeniería de software el equivalente sería la ley de la gestión de los requerimientos: "los requerimientos no se acomodan o se desaparecen, se descubren". Una solución informática a un problema de negocio tienen una cantidad de requerimientos intrínsecos que provienen del negocio. El no tomarlos en cuenta no significa que el sistema no los necesite, sino que no han sido tomados en cuenta y que a la larga, los mismos han de ser desarrollados. La diferencia está en el momento en que son descubiertos y el estado de ánimo con el que terminará la parte que deba pagar la diferencia (bien sea el proveedor o el cliente). No tomar en cuenta los requerimientos desde un inicio, está más que probado, que es más costoso que hacer un buen análisis que los contemple. El no encontrarlos supone, en el mejor de los casos, inexperiencia de la parte que hace el análisis, y en el peor, mala intención en el descubrimiento de los mismos. Para la parte que hace el análisis, en realidad, ninguno de los dos escenarios son buenos.