Software Guru Conference & Expo 2014

¿Que son los Requerimientos?

La definición formal nos dice:

  1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo
  2. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal
  3. Una representación documentada de una condición o capacidad como en (1) o (2)

Los encontramos en formas variadas como lista de pedido, casos de uso, historias, escenarios de negocio, reglas de negocio, condiciones de sistema entre otras.

Pero lo que es muy cierto es que los requerimientos deberán de ser claros, descritos o bosquejados de manera atómica además de saber cómo serán probados, por dichas razones hay que documentarlos y colocarles un identificador único (el documentado del requerimiento puede ser: escritos, dibujados o modelados) tal que podamos transmitirlos, implementarlos, verificarlos y obtener la aprobaciones correspondiente.

División básica de los requerimientos

Los requerimientos se dividen en Funcionales.- Que servicios necesita que haga el sistema, que operaciones o funcionalidades son esperadas por los stakeholders.

Para los Requerimientos No funcionales.- Cuales son las cualidades del servicio (usabilidad, tiempos de respuesta, flexibilidad, confiabilidad, estabilidad, recuperación de fallas entre otros).

Estos últimos muy habitualmente no son considerados por los líderes o bien por que ya existe el sistema y se están haciendo mejoras o porque definitivamente no saben que existen.

Como programadores nos corresponde detectar ciertos requerimientos que no son solicitados de manera explícita, pero sin embargo deben de estar en el sistema, estos son establecidos a través de los requerimientos no funcionales, donde vamos creando requerimientos complementarios con el fin de cubrir la necesidad del cliente o stakeholdres. Esto lo encontramos en las pruebas de concepto, propuesta de usabilidad, desarrollo de componentes de infraestructura, utilización de un u otro framework entre otras actividades, normalmente estos últimos no se documentan de manera formal, pero es muy conveniente que se documente en el código (best practice) y difundirlo al equipo, esto puede ayudar a que se evite la programación redundante.

Lo importante de los requerimientos al transmitirlos es que sean claros, únicos (no redundante o que se tengan conflictos con otros), que sean concretos y que ante todo se alineen al objetivo o visión inicial.

Cada metodología tiene formas diferentes para expresarlos, lo común de todas ellas es que coinciden en la importancia del requerimiento, siendo fundamental para las demás actividades del equipo de trabajo, los requerimientos deben de ayudar a establecer el plan de trabajo (esfuerzos, tiempos y costo) incluyendo la manera en que se va a probar y validar

Una mecánica que es sugerida por los Ágilistas es crear una pila de requerimientos(backlog), donde en base a su priorización se tengan un orden de ejecución, de esta pila como parte de un ciclo(Iteración, Sprint) de desarrollo se tome una porción de los requerimientos que se encuentren estables (línea base) y se lleve a su desarrollo. (Un grupo de requerimientos que puedan ser desarrollado en máximo de 2 a 4 semanas, según la complejidad del sistema)

Esta estrategia permite introducir cambios en la pila sin problema alguno, ya que solamente la porción que se tomo se ha congelado y teniendo en mente que el tiempo de desarrollo es corto, cualquier cambio a dicha linea base puede programarse para la siguiente ciclo.

http://www.agilemodeling.com/essays/changeManagement.htm

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Uno de los requerimientos....

Uno de los requerimientos más importantes (y que muchas veces se nos olvida)es el personal con el que se cuenta para llevar a cabo el proyecto.

Buen post

Imagen de Israel-69

Uno de los requerimientos....

Muy cierto tú comentario y es un hecho que sería muy complejo saber cuales son las habilidades que el equipo de trabajo si no se tiene claro los requerimientos del sistema y en particular los requerimientos no funcionales, de estos últimos son los que determinan cual es expertice deseado.
del equipo.

Igual que cualquier otro trabajo, si deseamos eficiencia, calidad y excelencia en producto, necesitamos de calidad y excelentes equipos de trabajo.

Sin embargo tristemente la parte económica y continuamente nuestros grandiosos Project Manager no consideran dichos factores :´(

Requerimientos...

Efectivamente voy con las dos opiniones, a menudo sucede que quien encabeza los proyectos, no toma en cuenta las habilidades del equipo desarrollador, entonces es cuando la agilidad al llevar a cabo la construcción comienza a flaquear, y si es muy cierto que se les hace complejo a los grandiosos Project Manager seleccionar excelentes equipos de trabajo.

Imagen de greeneyed

Requerimientos de la aplicación

El personal que tenemos para llevar a cabo el proyecto no es ningún requerimiento de la aplicación. Es un requerimiento de la organización que hace la aplicación pero no con el producto final, no es una característica requerida. Estais confundiendo el termino formal "requerimiento" de metodología de desarrollo con el coloquial de lo que necesitas para hacer algo. Son dos cosas diferentes.
No es que no sea importante, pero no tiene que ver con el tema del post.

Imagen de WinDoctor

En efecto

Da gusto leer a Greeneyed en este foro, generalmente lo leo en JavaHispano o Forosdelweb, es lo bueno de crear buena fama!


no toma en cuenta las habilidades del equipo desarrollador, entonces es cuando la agilidad al llevar a cabo la construcción comienza a flaquear

A diferencia de los que practican métodos formales, la agilidad se distingue por apostar a que el equipo sea Auto Gestionable y que el equipo de desarrollo sea quien tome las desiciones en cuanto al tiempo. Una de los requisitos para practicar la agilidad es contar con un buen "equipo", si no se tiene, la agilidad seguramente fallará!

Pero bueno, como dice GreenEyed, el equipo de desarrollo no es ningún "Requerimiento" dentro del contexto del "Análisis de Requerimientos" según el hilo original!

Imagen de Israel-69

Requerimientos de la aplicación

Hasta donde yo conozco no existe una clasificación de "Requerimientos de metodología y Requerimientos coloquiales", tal ves no he leído lo suficiente :)

Sin embargo en mí opinión los requerimientos, independientemente de que tipo sea el trato que se les deberá dar es el mismo. la Ingeniería de Requerimientos puede aplicarse a cualquier ámbito, (no solo al desarrollo de software) la manera de implementarse(metodología) podrá ser diferente por equipo o lugar de trabajo; mientras el método es muy similar (Recopilar, Analizar documentar y validar mas Administrarlos)

Ahora bien en cuanto a los recursos, es cierto que son contratados por una compañía, pero normalmente para saber que tipo de recurso necesitas, las áreas de recursos humanos necesitas conocer las habilidades esperadas y eso es proporcionado en base a que tipo de aplicación están por desarrollar; cual es la diferencia entre un sistema cliente servidor y una aplicación empresarial (EE), aún que funcionalmente hagan lo mismo??

Por consiguiente las Necesidades de los Clientes derivarán en Requerimientos de sistema, recursos, económicos, infraestructura entre otros mas y que cualquiera de ellos tendrá que analizarse, documentarse y validarse.

Imagen de greeneyed

No, lo necesario en cuanto a

No, lo necesario en cuanto a recursos económicos, humanos, temporales etc. para construir la aplicación no forman parte de los requerimientos de la aplicación en ninguna metodología. Son dos cosas separadas y no reciben el mismo trato, por que unos incumben al resultado, que es la aplicación, y otros al proceso para llegar a ese resultado. Los requerimientos de la aplicación son independientes y los tienes que cumplir uses la metodología que uses, con 2 o con n personas, con x presupuesto o con y.
Son tan independientes como lo puedan ser los requerimientos de aplicación y el diseño de la BDD, y por eso se han de tratar por separado. Tratarlos juntos es un error.

Imagen de Israel-69

Re - No, lo necesario en cuanto a..

Que tal greeneyed es muy respetable tus observaciones, solo que en ningún lado se comenta que los Requerimientos deban de "tratarse juntos" o que sin son "parte de una Metodología u otra".

De hecho la idea que se pretende transmitir es que cualquier Requerimiento tiene que ser Recopilado, Analizado, especificado y validado (cualquiera que tenga un nivel de formalidad económica) así como posteriormente administrado.

En el último punto si estoy totalmente confundido cuando comentas
>>"Son tan independientes como lo puedan ser los requerimientos de aplicación y el diseño de la BDD"

Desde mi punto de vista no seria muy sugerido, dado que la BD deberá de obedecer a las necesidades del cliente (tanto Funcionales como No Funcionales), no veo como puedes hacer un diseño de la BD si tener los requerimientos de la aplicación; Tampoco estoy diciendo que son solo los requerimientos ya tienes para crear la BD, hay toda un proceso para llegar a crear los esquemas de datos, pero sin embargo lo primero que debe de haber son los requerimientos.

Ahora bien no dudo que hayan personas que se aventuren a realizar la BD sin tener claro los Requerimientos, pero creo que ya todos sabemos los resultados de esas aventuras.

Saludos

Imagen de WinDoctor

¿Mismo trato?


Sin embargo en mí opinión los requerimientos, independientemente de que tipo sea el trato que se les deberá dar es el mismo

De hecho, por ejemplo MoProSoft, lidereado por la Dra. Hanna Oktaba de la UNAM, contempla areas separadas, una de ellas es la categoría de Gestión que proporciona directrices para la Gestión del personal de desarrollo. Otra categoría es la de Operación que a su vez incluye la subdivisión de DMS (Desarrollo y Mantenimiento de Software) que ya es donde entra netamente el "Análisis de Requerimientos", y es básicamente lo que se comenta, que no se da el mismo trato a los requerimientos de negocio que a los requerimientos para lograr el objetivo.

De cualquier forma, la polémica sobre si se puede tratar de forma igual o diferente me parece innecesaria, el tema central del hilo debe ser "Análisis de requerimientos" por lo cual propongo que discutamos sobre el ¿como debe ser la toma de requerimientos? ¿que herramientas utilizar para analizar la información? ¿Como gestionar los requerimientos cambiantes?, etc etc

Imagen de WinDoctor

¿Como Gestionar el cambio de Requerimientos?

Plantearía las siguientes preguntas,

- ¿Como se debe Gestionar el cambio de Requerimientos?
- ¿Que herramientas o técnicas utilizar para la toma de requerimientos y su análisis?

Imagen de Israel-69

Técnicas para la obtención de los Requerimientos

En este punto hay diversas técnicas y dependerá del tipo de problema que se este tratando de resolver, hay desde estar observando el proceso hasta leer los manuales de procedimientos de negocio, lo más recomendable es que se tenga claro quienes son las personas que se les deba de preguntar y entonces utilizar una de las siguientes técnicas Ténicas de recopilación de Requerimientos , claro que no son las únicas, pero sí las más frecuentes.

Otra recomendación es utilizar la regla del 80/20 o con un diagrama de "Pareto", este te permitirá conocer cuales son las prioridades y determinar la relevancia de los problemas, la idea es que con el 20% de de los requerimientos de Negocio se este cubriendo el 80% de los problemas principales.

Respecto a los controles de cambio, para este tema lo voy a desarrollar como una entrada posteriormente en el blog,

Por último, sobre herramientas hay un sin numero de ellas, pero ninguna tendrá valor si no se tiene un proceso y una disciplina de análisis de requerimientos, es como cuando desarrollas con Java tienes una gama de IDE's y Servidores de Aplicaciones, pero lo mas importante esta en conocer las bases, una ves que ya tienes los fundamentos utilizar una u otra no implica mayor problema.

Imagen de WinDoctor

El Diagrama de Pareto es

El Diagrama de Pareto es más útil para la corrección de problemas, priorizarlos y así mejorar la calidad del proyecto.

El dueño de negocio es quien debe priorizar la lista de requerimientos en cada iteración y la prioridad debe llevar un número único, nada de prioridad "alta", "media" o "baja", ningún requerimiento puede tener la misma prioridad que otro. El dueño de negocio es quien debe priorizar mediante un número sus requerimientos de negocio y en ese orden se irán desarrollando.

El RCA no me parece una técnica para la toma de requerimientos de negocio que se implementarán a nivel sistema, me parece que la palabra que mencionas en tu art{ículo de google docs, "encontrar la causa de un verdadero problema" no es equivalente a " requerimientos de negocio" y que esta técnica es para " eventos" existentes, los requerimientos no son eventos.

En este punto, noto que la mayoría de técnicas han nacido en otros ámbitos y aplicarlas al desarrollo de sw es un error habiendo otras técnicas diseñadas especificamente para este propósito.

Saludos!

Imagen de greeneyed

Solo para aclarar la

Solo para aclarar la confusión generada por mi comentario respecto a las BDD, decir que a lo que me refería es que son dos aspectos necesarios para el éxito del proyecto pero que se realizan de forma independiente. Es decir, en los requerimientos de la aplicación no aparecen detalles del esquema SQL de la BDD, por ejemplo, y son tareas que no tienen por que realizarse a la vez. Primero los requerimientos de la aplicación y de ahí derivando derivando sacaremos un esquema de BDD que nos permita satisfacer esos requerimientos.
Pero vamos, que en la lista de requerimientos no se me ocurriría poner. "La aplicación necesita una tabla X con un varchar de 255 para el nombre y un índice por FK...."

En cuanto a recopilarlos y mantenerlos, yo estoy a favor de herramientas que permitan un mantenimiento rápido y eficaz, y relacionar los requerimientos con herramientas de gestión de incidencias/tareas, de forma que las incidencias/tareas estén siempre relacionadas, directa o indirectamente, con ayudar a cumplir un requerimiento. Si usas herramientas demasiado rígidas, lo que ocurre es que el proyecto avanza más rápido que ellas y las modificaciones de los requerimientos no reflejan por que "es demasiado trabajo"... y al final si no la tienes actualizada, la lista no sirve para nada o peor aun, para crear confusión.
Eso sí, sencillo no es :).
Y como WinDoctor, creo que es dificil aplicar tecnicas de otras areas en el nuestro, donde es más habitual que te cambien los requerimientos mientras avanza el proyecto, por ejemplo, y donde el proyecto en realidad nunca acaba.
Excepto en proyectos muy controlados, la realidad es que en la mayoría de proyectos la teoría es muy dificil de aplicar debido en gran parte a la inmadurez de nuestro campo.

Imagen de jiturbide

Requerimientos de Negocio

Falta mencionar el grupo de Requerimientos de Negocio, que son mas importantes que los Funcionales y No Funcionales y que desde el punto de vista del desarrollador no siempre son evidentes.

¿Que es lo que motiva a crear un sistema de software?
R: Generar ganancias o reducir gastos, no hay mas.

Una empresa invierte en el desarrollo de un sistema para que le ayude a cumplir sus objetivos de negocio ya sea soportando la operacion del proceso actual, automatizando tareas que reducen costos, o creando/usando software que le de una ventaja competitiva respecto a la competencia.

Un requerimiento de negocio podria ser el siguiente:
"Se requiere reducir los tiempos de autorizacion de credito para Pymes de 30 a 4 dias para incrementar el volumen de clientes en un 20%. Se ha detectado que los clientes optan por solicitar creditos con tiempos de respuesta cortos, se ha detectado que muchos tramites de clientes potenciales no se continuan por la tardanza, etc."

En un requerimiento de Negocio se expresa una necesidad que esta alineada a los objetivos de la empresa y en él generalmente no se menciona como se va a resolver tecnologicamente si es que tiene solucion x software.

La propuesta del Consultor de Negocio seria, despues de un analisis, que la autorizacion en lugar de hacerse mediante envio de documentos fisicos, se haga online mediante digitalizacion hacia las otras instituciones que necesitan ser consultadas para autorizar el credito.

Entonces es aqui cuando se detecta la necesidad de un sistema y entonces aparecen los Requerimientos Funcionales, que siempre estan sujetos a cumplir los objetivos de negocio:
Se requiere crear un modulo de validacion de credito que realice lo siguiente (Ejemplos):
RF01 Digitalizar y almacenar el Documento
RF02 Extraer la informacion de solicitud de documento digitalizado
RF03 Enviar de informacion al Buro de Credito para la investigacion del solicitante
RF04 Validar en SHCP la situacion de pago de impuestos del solicitante...
RF05 Generar una notificacion de autorizacion o rechazo de la solicitud...
etc...
(Una regla de negocio para este ejemplo es que el solicitante debe proporcionar a 'producto de gallina' su RFC, si no ¿Como lo validas en los otros sistemas?)

y algunos ejemplos como Requerimientos No Funcionales
RNF01 La informacion del solicitante a cualquiera de las entidades debera viajar encriptada
RNF02 La disponibilidad del sistema debe contemplar una ventana de servicio de 8am a 10pm, etc.
RNF03 El metodo de integracion debera ser por WS y los mensajes deberán cumplir el estandar de intercambio de XML entre instituciones de credito...

Aqui entran en juego restricciones institucionales, tecnologicos, regulatorios, de presupuesto, que son tema de otro thread.

En los casos donde el cliente no sabe lo que quiere por que no tiene claro los objetivos de negocio, ni hablar.

Saludos

Imagen de Israel-69

Muy cierto!

Gracias por tu comentario, muy acertado

Como bien dices Los de Negocio = las necesidades Reales, son los primero que deberíamos de entender con toda claridad, para después crear los requerimientos funcionales y no funcionales, teniendo siempre claro de donde provienen y hacia donde se va (trazabilidad)