{"id":3345,"date":"2017-01-24T09:22:29","date_gmt":"2017-01-24T14:22:29","guid":{"rendered":"http:\/\/itsoftware.com.co\/content\/?p=3345"},"modified":"2022-12-05T10:49:51","modified_gmt":"2022-12-05T15:49:51","slug":"toma-de-requisitos-desarrollo-software","status":"publish","type":"post","link":"https:\/\/itsoftware.com.co\/content\/toma-de-requisitos-desarrollo-software\/","title":{"rendered":"La gran importancia de la toma de requisitos en el desarrollo de software"},"content":{"rendered":"
\"Toma<\/a>
Toma de requisitos de Software<\/figcaption><\/figure>\n

El \u00e9xito o fracaso del desarrollo de aplicaciones, radica en gran medida en comprender lo que el cliente quiere, en traducir sus deseos en un sistema inform\u00e1tico, mediante una toma de requisitos adecuada.<\/p>\n

Sin embargo, al tratarse de un deseo humano, aterrizar una idea que puede ser abstracta o hasta absurda; es un asunto delicado, que debe ser llevado con mucha rigurosidad, con el prop\u00f3sito de cuantificar, y hacer factible una idea con las herramientas digitales actuales.<\/p>\n

Entrevista Inicial con el cliente<\/h2>\n

Es por eso que una toma de requisitos, debe iniciar con una entrevista informal, donde el cliente narre todo su proceso, visto desde el punto de vista de su negocio, con el fin de captar el prop\u00f3sito final de su deseo de automatizaci\u00f3n.<\/p>\n

Es importante, si es posible, grabar esa conversaci\u00f3n, recolectar los esquemas u otros documentos que el cliente use para explicar sus deseos.<\/p>\n

Hay que recordar que la percepci\u00f3n de una idea depende del receptor, de su formaci\u00f3n, \u00a0ideas preconcebidas o prejuicios. E incluso, con el paso del tiempo, podemos cambiar nuestro entendimiento, si no tenemos un registro fiable de una conversaci\u00f3n.<\/p>\n

Esta entrevista debe ser complementada con algunas preguntas ya enfocadas al deseo de crear un programa inform\u00e1tico, como por ejemplo, averiguando el tipo y formato de datos de entrada, la interacci\u00f3n con otros sistemas existentes, o de otras personas con el sistema, etc.<\/p>\n

Historias de Usuario o Casos de Uso<\/h2>\n

Toda esta informaci\u00f3n ser\u00e1 modelada para aproximar el entendimiento del proceso del cliente, a un sistema inform\u00e1tico que puede estar satisfaciendo total o parcialmente sus deseos, ya sea en forma de historias de usuario o casos de uso.<\/p>\n

Esta primera aproximaci\u00f3n debe recibir \u00a0realimentaci\u00f3n directa \u00a0del cliente, para validar que efectivamente se entendieron sus deseos, d\u00e1ndole un alcance delimitado, donde dejan de aparecer t\u00e9rminos subjetivos como \u00abquiero que sea muy lindo\u00bb, \u00abdebe ser un sistema inteligente\u00bb.<\/p>\n

Este entendimiento en la toma de requisitos debe ser medible, sin dar lugar a controversias posteriores con respecto a percepciones humanas que cambian de un sujeto a otro.<\/p>\n

Prototipo funcional<\/h2>\n

Incluso una buena pr\u00e1ctica para llegar a un entendimiento m\u00e1s concreto de un requerimiento, es la creaci\u00f3n de un prototipo funcional que permite mostrarle al cliente como funcionar\u00eda el sistema, desde el punto de vista de los diferentes roles que intervienen con \u00e9l.<\/p>\n

Una juiciosa toma de requisitos, donde el cliente interviene en todo el proceso, hasta aceptar la interpretaci\u00f3n de sus deseos en t\u00e9rminos inform\u00e1ticos, es en gran parte el \u00e9xito que puede lograr un proyecto de software; evitando malos entendidos, alcances confusos o no incluidos, o hasta cambios radicales de un sistema mal especificado desde el principio.<\/p>\n

\n
\n
\n