Que Es Un Requerimiento

Capítulo 1

Que es un requerimiento?

Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede

representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le

sea útil a los clientes o a los usuarios finales.

A nivel general los requerimientos pueden clasificarse como requerimientos indicados o reales. Los

requerimientos indicados son los entregados por el usuario al comienzo del proyecto, en tanto que

los requerimientos reales son aquellos que reflejan la satisfacción de las necesidades del usuario

en un sistema en particular. El proceso para convertir los requerimientos indicados en

requerimientos reales consisten en un proceso de filtrado según el significado y otros aspectos

según se considere.

Sobre la ingeniería de requerimientos

La Ingeniería de Requerimientos se define, según Ortas [Ortas 1997], como un "conjunto de

actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye

con la especificación de una solución (a veces más de una)."

Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las actividades

involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un

producto determinado. El uso del término "ingeniería" implica que se deben utilizar técnicas

sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean

consistentes y relevantes.

Porqué planificar

Es muy común usar diferentes tipso de planes en un proyecto: Plan de proyecto, plan de calidad,

proyecto de desarrolo de software etc.. Sin embargo el plan de requerimientos facilita el

entendimiento y el refuerzo de las actividades, en especial en momentos de implementar un

procesos efectivos en una forma de desarrollo en particular.

El ciclo de vida de los requerimientos

Los requerimientos en un proyecto no solo comprenden las tareas de captura y manejo de los

cambios a lo largo de todo el proyecto, también comprenden estas otras tareas:

1. Identificar los skateholders:

Se describe una lista de toda la persona interesada en el desarrollo del sistema.

2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y sus

expectativas

3. Indentificar los requerimientos

Inicialmente los requerimientos provienen de los objetivos que plantea el negocio,

En esta actividad los requerimientos se indican por medio de sentencias. En un escenario de

negocio se usa para entender los requerimientos del negocio

4. Aclarecer y refinar los requerimientos

Esta actividad se ejectua cuando se tiene plena seguridad plena certeza de que los

requerimientos indican las necesidades reales del cliente y que estos pueden ser usados por

el resto de equipos en el proyecto.

5. Analizar los requerimientos

Se realiza cuando los requerimientos se encuentran bien definidos y cumplen con el criterio

de un buen requerimiento.

6. Definir los requerimientos de forma estándard para los skateholders

Debido a que cada skateholder tiene una perspectiva diferente del sistema y sus

requerimientos, es importante esforzar un poco de tiempo en la descripción de los

requerimientos usando un vocabulario adecuado.

7. Especificar los requerimientos

Cada requerimiento debe expresarse en forma detallada de tal manera que pueda ser incluído

en otros documentos de especificación o en otros proyectos

8. Priorizar los requerimientos

Todos los requerimientos tienen niveles diferentes de importancia para los clientes y

usuarios. Unos tienen prioridad críticas, otros no tanta y otros de bajo nivel de prioridad.

La priorización de los requerimientos es una actividad que nos va a permitir desarrollar

nuevas versiones de nuestro proyecto de forma continua sin verse retrasadas por tiempo en

sus salidas.

9. Derivar los requerimientos:

Esta actividad nos permite detallar requerimientos no visibles para nuestros cliente o

usuarios que no se han logrado identificar, pero que son importantes para el funcionamiento

adecuado del requerimiento en detalle.

10. Particionar los requerimientos

Se clasifician los requerimientos en diferentes criterios: Hardware, software y

entrenamiento.

11. Asignar los requerimientos

Esta actividad asigna los requerimientos a diferentes subsistemas y componentes internos,

12. Hacer seguimiento a los requerimientos

Se desarrolla la capacidad de permitir que un requerimiento satisfecho pueda ser

referenciado dentro del sistema

13. Manejar los requerimientos

Se desarrolla un sistema de contro de los requerimientos, necesario para adicionar, modificar

y borrar requerimientos, al igual que la implantación de un repositorio para estos.

14. Probar y verificar los requerimientos

En esta actividad se validan los requerimientos, diseños, código etc... para asegurarse que

los requerimientos están bien

15. Validar los requerimientos

Finalmente se confirman los requerimientos reales que han sido implementados para el

sistema.

El plan de requerimientos

El propósito de un plan de requerimientos es para determinar y documentar de que forman se

involucran en el proyecto los requerimientos reales y como se referencian las actividades de

requerimientos relativos en el ciclo de vida

Debe ser desarrollado por el analista de sistemas

1. Propósito

El propósito debe ser similar la descrito en la definición

2. Sumario del proyecto

Comprende un sumario de alto nivel con los objetivos del software a desarrollar.

3. Fondo

Esta sección describe las desiciones que incidieron en el desarrollo del proyecto. También se

identifican los grupos de skateholders más importantes

4. Evolución de los requerimientos

Un mecanismo debe ser acojido entre los clientes y el equipo de desarrollo de tal manera

que se facilite la revisión de los requerimientos inidcados y lso reales. Se recomienda como

mecanismo a adoptar la creación de grupos compuestos de reperesentantes entre ambas

partes

5. Roles y responsabilidades del personal involucrado en actividades de los requerimientos

El desarrollo de un documento para este propósito permite clarificar los roles de las

personas que participen en la actividad, como por ejm: Personas que necesitan

entrenamiento, personas encargadas del uso de las herramientas etc...

6. Definiciones los requerimientos a usar en el proceso

Un documento de los procesos de los requerimientos es escencial. Se pueden usar

organigramas acompañados de narrativo que describa el nombre del proceso, los cientes,

entradas y salidas del proceso, tareas etc...

7. Mecanismos, métodos, técnicas y herramientas a utilizar

Es recomendable que el uso de las herramientas, métodos y técnicas a utilizar dispongan de

una documentación apropiada para que el equipo desarrollador se familiarize fácilmente con

estas

8. Integración de prácticas probadas y efectivas en los requerimientos

El uso de prácticas puestas en prueba y que han demostrado ser eficicientes puede producir

un gran avance para el proyecto proyecto. Por ejemplo prácticas como invertir en el tiempo

y en tratar de definir de la mejor manera las necesidades del usuario son prácticas muy

recomendadas

9. Referencias

Comprende un conjuto de de documuentos y referencias importantes para el proceso de

requerimientos.

10. Estrategias recomendadas

Algunas estrategias recomendadas a usar son:

· Proceso UpFront: Usado para entender las necesidades reales de los clientes y del entorno,

entender la visión del proyecto , definir interfaces externas , componentes de sistema

· Determinar que factores modifican los requerimientos : Como estandards, políticas externas,

costos etc...

· Entrenamiento concernientes al manejo de requerimientos

· etc...

11. Apéndices

Sirven para referenciar :

· Proceso de requerimientos

· Borradores para políticas de los requerimientos del proyecto

· Planes de acción

Capítulo 2: Roles del analista de sistemas

El analista de sistemas dispone una posición estratégica en el proyecto pues facilita en

mejoramiento de prácticas y de la organización, el rol de un analista puede vincularse a los

objetivos del proyecto, como mejoras para el producto final, en la planificación detallada, calidad

de los artefactos, control de la configuración y utilización de los. A continuación se describen los

posibles desempeños de un analista en las diferentes áreas:

Los roles sugeridos para un analista de sistemas

1. Trabajar en forma conjunta con los clientes, usuarios, equipo de arquitectura del proyecto

y equipo de diseño del proyecto par identificar los requerimientos reales.

Identificar los requerimientos reales no es tarea facil en un proyecto, por ello es

recomendable tener en cuenta algunas consideraciones:

· Entender los

...