Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los lideres de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces debemos de definir que características deben de poseer los requerimientos adecuadamente formulados
No quiero sonar atrevido pero es muy difícil hallar cuestionarios genéricos, puesto que las necesidades, requisitos, ideas, y objetivos pueden variar de empresa a empresa por lo que en principio todo proyecto es diferente.
Los cuestionarios y formularios por lo general se usan como un carácter más formal y cuando ya se ha hecho una entrevista previa. Por tanto los formularios y cuestionarios se elaboran teniendo en cuenta lo ya analizado del problema.
No hay receta mágica. Lo más común y fácil de hacer es dejar que las preguntas vengan al aire. Dejar que las inquietudes surjan a medida que se desarrolla la entrevista.
Algunas preguntas puedes tenerlas ya pre-programadas, pero para ello se necesita de haber dimensionado al menos alguna idea o noción básica de lo que puede estar necesitando el cliente.
A lo que voy es que cada negocio es único y se necesita en última instancia es desarrollar las preguntas a la medida para que el mismo cliente termine describiendo requisitos, restricciones, necesidades, objetivos, su visión, la infraestructura existente, la cultura informática, etc.
Como puedes comprobar, se trata del algo bastante subjetivo. Necesariamente en algún momento las preguntas se van a particularizar para hallar tus dudas. Muy posiblemente el cliente tenga una visión de lo que concibe y/o como concibe al sistema. Es ya la responsabilidad del analista conducirlo a las preguntas específicas a fin de mitigar dudas.
Esto se desarrolla con el tiempo, con la práctica.
Hay preguntas típicas, si es muy cierto porque son en lo general. Luego se particularizan. Como idea, puedo dejarte unos puntos que deberías tener en cuenta. Cómo, y cuando se los puede preguntar, eso es mejor analizarlo durante la entrevista:
1. Infraestructura existente
2. Cultura informática
3. Condicionantes de tiempo, espacio, presupuesto, técnico, operativo, y/o legales. Básicamente determinar que puede afectar o condicionar al proyecto y/o al sistema como para imponer que y/o como hacer (o no hacer).
4. Cantidad de personal. Se necesita saber cuantos puestos de trabajo se necesita, como están distribuídos, como se asignan responsabilidades y actividades. Dependiendo del negocio o ambiente, esto puede afectar el desarrollo.
5. El proceso actual. Averiguar que, como, cuando, y/o donde se llevan a cabo las actividades que hacen, dependen, y/o afectan al sistema. De aquí pueden surgir alguno que otro requisito o funcionalidad.
6. Visión personal y grupal de como ve cada miembro del personal ve al sistema.
7. Determinar los objetivos, visión y misión de la empresa o negocio a mediano y largo plazo.
Bueno, esos son los puntos que por ahora, en lo general, se me ocurren. Como ves, es algo bastante "casero" y es así porque las conversaciones son dinámicas.
Recomiendo la lectura del libro Ingeniería de Software: un enfoque práctico de Robert Pressman. Este libro te va a ayudar a formar el aspecto del análisis.
Yo también te aconsejo que recuerdes que todo proceso se fundamenta en Entradas, Proceso y Salidas, asi que pregunta eso, como lo hacen actualmente, con que recursos cuentan (Dinero, Equipos, Personas,...)
Ojala esto complemente el formulario que necesitas sacar. Yo llevo mucho tiempo trabajando con requerimientos y nunca hay un formulario que tenga la verdad absoluta, siempre hay que modificarlo deacuerdo al caso.
Answers & Comments
Verified answer
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los lideres de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces debemos de definir que características deben de poseer los requerimientos adecuadamente formulados
http://www.geocities.com/txmetsb/req-mgm-1.htm
Aqui les dejo listado de requerimiento funcional y no funcional para software
http://adf.ly/pxptw
http://adf.ly/pxqUt
Espero les ayude :)
Hola "linda",
No quiero sonar atrevido pero es muy difícil hallar cuestionarios genéricos, puesto que las necesidades, requisitos, ideas, y objetivos pueden variar de empresa a empresa por lo que en principio todo proyecto es diferente.
Los cuestionarios y formularios por lo general se usan como un carácter más formal y cuando ya se ha hecho una entrevista previa. Por tanto los formularios y cuestionarios se elaboran teniendo en cuenta lo ya analizado del problema.
No hay receta mágica. Lo más común y fácil de hacer es dejar que las preguntas vengan al aire. Dejar que las inquietudes surjan a medida que se desarrolla la entrevista.
Algunas preguntas puedes tenerlas ya pre-programadas, pero para ello se necesita de haber dimensionado al menos alguna idea o noción básica de lo que puede estar necesitando el cliente.
A lo que voy es que cada negocio es único y se necesita en última instancia es desarrollar las preguntas a la medida para que el mismo cliente termine describiendo requisitos, restricciones, necesidades, objetivos, su visión, la infraestructura existente, la cultura informática, etc.
Como puedes comprobar, se trata del algo bastante subjetivo. Necesariamente en algún momento las preguntas se van a particularizar para hallar tus dudas. Muy posiblemente el cliente tenga una visión de lo que concibe y/o como concibe al sistema. Es ya la responsabilidad del analista conducirlo a las preguntas específicas a fin de mitigar dudas.
Esto se desarrolla con el tiempo, con la práctica.
Hay preguntas típicas, si es muy cierto porque son en lo general. Luego se particularizan. Como idea, puedo dejarte unos puntos que deberías tener en cuenta. Cómo, y cuando se los puede preguntar, eso es mejor analizarlo durante la entrevista:
1. Infraestructura existente
2. Cultura informática
3. Condicionantes de tiempo, espacio, presupuesto, técnico, operativo, y/o legales. Básicamente determinar que puede afectar o condicionar al proyecto y/o al sistema como para imponer que y/o como hacer (o no hacer).
4. Cantidad de personal. Se necesita saber cuantos puestos de trabajo se necesita, como están distribuídos, como se asignan responsabilidades y actividades. Dependiendo del negocio o ambiente, esto puede afectar el desarrollo.
5. El proceso actual. Averiguar que, como, cuando, y/o donde se llevan a cabo las actividades que hacen, dependen, y/o afectan al sistema. De aquí pueden surgir alguno que otro requisito o funcionalidad.
6. Visión personal y grupal de como ve cada miembro del personal ve al sistema.
7. Determinar los objetivos, visión y misión de la empresa o negocio a mediano y largo plazo.
Bueno, esos son los puntos que por ahora, en lo general, se me ocurren. Como ves, es algo bastante "casero" y es así porque las conversaciones son dinámicas.
Recomiendo la lectura del libro Ingeniería de Software: un enfoque práctico de Robert Pressman. Este libro te va a ayudar a formar el aspecto del análisis.
Éxitos en el proyecto.
Saludos,
Lo que dice "Miguel Angel M" es muy valido.
Yo también te aconsejo que recuerdes que todo proceso se fundamenta en Entradas, Proceso y Salidas, asi que pregunta eso, como lo hacen actualmente, con que recursos cuentan (Dinero, Equipos, Personas,...)
Ojala esto complemente el formulario que necesitas sacar. Yo llevo mucho tiempo trabajando con requerimientos y nunca hay un formulario que tenga la verdad absoluta, siempre hay que modificarlo deacuerdo al caso.