Requisitos de software de análisis

Posted by admin on January 6, 2013

Cuando un producto de software tiene que ser desarrollado, una de las primeras tareas en el libro de la agenda del Director del Proyecto es el Análisis de Requerimientos.

¿Qué es el Análisis de Requerimientos?

En pocas palabras, el proceso de Análisis de Requisitos tiene como objetivo identificar y documentar los requerimientos del cliente para el sistema propuesto.
Un practicante de software capacitado conocido el analista de Requerimientos (AR) se comunica con el usuario bien informado (s) para entender cuáles son los requisitos. La mayoría de las veces, el cliente tendrá una breve idea de lo que necesitan en el sistema propuesto.

El trabajo del analista es que la carne, añadir requisitos implícitos y los requisitos obligatorios o reglamentarias que el cliente no puede tener en cuenta y crear un documento llamado la Especificación de Requisitos Software o SRS.

Al final del proceso, el SRS resulta ser la impresión azul del producto. Un punto de referencia para el cliente, el director del proyecto, el probador y el diseñador. El SRS ideal es que se limita a especificar “qué” el producto se debe hacer en lugar de “cómo” hacerlo. No se incluyen los detalles de implementación tales como la estructura de base de datos, la arquitectura y así sucesivamente.

¿Qué la especificación de requisitos del software se incluyen?

Idealmente, un SRS debe incluir como mínimo la siguiente información.

Requisitos funcionales

Los requisitos funcionales son las “características” de un software que tenga. Requisitos de ejemplo para un carro de compras Shop son Personas, vista detallada del producto, la caja, cesta Ver, Mi cuenta.

El analista también debe identificar las necesidades que el cliente ha perdido o las que son necesarias para apoyar las principales características. Estos requisitos son llamados requisitos implícitos. Por ejemplo, si el cliente ha pedido un sitio de compras, el analista incluye requisitos para la Cesta de la compra como la cesta Ver, Checkout y Eliminar de la cesta.

Requisitos no funcionales

¿Qué tan eficiente es el producto de software? ¿Es de alto rendimiento, es fiable, lo rápido que es, no lo consumen una gran cantidad de recursos del sistema. Estos son aspectos tratados en los requisitos no funcionales. Los usuarios sin experiencia por lo general no tienen en cuenta estos requisitos. Estos requisitos afectan directamente a la calidad del producto.

Los requisitos reglamentarios

En muchas industrias, es posible que las regulaciones en el que el producto de software debe cumplir. Por ejemplo, las leyes fiscales del país en el que un producto de contabilidad tiene que ser desplegado. Preferencias de idioma, las leyes de cifrado de contraseñas, las normas de URL, correo electrónico normas. Estos son algunos de los requisitos reglamentarios que el cliente no puede tener en cuenta. El analista tiene que incluir estos requisitos en su caso a la industria o el país en el que el producto de software se va a implementar.

Requisitos de interfaz externa

¿Este producto interactuar con otro software o hardware de? El analista debe enumerar los requisitos mínimos de estas interfaces.

Los criterios de aceptación

Por último, los criterios de aceptación tiene que ser indicado. ¿Qué criterios se confirme que el software está funcionando de acuerdo con las especificaciones del cliente. Por lo general, las especificaciones de prueba serán los requisitos funcionales y no funcionales establecidos en el SRS.

Es importante que todos los requisitos deben incluir el número de función. Esto mejora la trazabilidad de cada función en todo el ciclo de vida del proyecto. En el diseño, construcción y en las fases de pruebas, los miembros del proyecto saben que son el diseño, la codificación o prueba de característica N º FE-2 o FE-45.

Dar prioridad a los requisitos

El SRS debe incluir las prioridades de cada función. Los clientes pueden pedir algunas de las características que deben concluirse a principios de. Un documento sobre las necesidades priorizadas cuidado conduce a un desarrollo más rápido de las características más importantes.

¿No es la Especificación de Requisitos del Software (SRS) una pérdida de tiempo. ¿Quién se beneficia?

Eso es una falacia. El SRS es útil para todo aquel que tenga algo que ver con el proyecto. El director del proyecto sepa qué planificar. Los diseñadores saben lo que al diseño. Los probadores de saber cómo el producto se espera que funcione. Todo ello con el SRS.

Finalmente, el SRS ayuda al cliente más. El cliente sabe lo que obtendrá al final. En general, el desarrollo se inicia sólo después de que el cliente lee y aprueba el SRS. Por ejemplo, si el cliente quiere que el sistema de sitio de compras que incluya una lista de favoritos, se puede explorar rápidamente el SRS y pedir la lista de deseos que se añadirán, si no está ya allí. El aumento de la entrada del cliente tan pronto en el proyecto, ayuda a todo el mundo sabe lo que se va a desarrollar y lo que es necesario desarrollar en primer lugar.

Revisar los requisitos de software

Obtención de los requerimientos de la derecha en los costos del primer lugar de 50 a 200 veces menos que el código de corrección. Es importante revisar el SRS antes de pasar a la siguiente etapa.

Por lo general, una sesión de revisión incluirá al menos los expertos de 3-4 y se llevará a cabo durante un máximo de 2 horas por sesión. Los asistentes a leer el documento antes de asistir a la reunión. Una revisión de la buena voluntad descubrir aproximadamente el 60-90% de los defectos en el producto.

Algunas compañías de desarrollo de software ignorar esta reunión crucial que lleva a consecuencias desastrosas. Una revisión de los requisitos simples resultará en un ahorro neto de la Lista 10-30%. Y sí, estas inspecciones son cerca de 20 veces más efectivo que probar el producto. No es de extrañar que cada hora pasada en la revisión evita un promedio de 33 horas de mantenimiento.

La gestión del cambio requisitos

Ningún proyecto es estática. Los requisitos pueden cambiar y un buen líder de proyecto debe aprender a anticipar eso. Sin embargo, cada cambio en los requerimientos cuesta tiempo y dinero, especialmente si los cambios cruciales llegar durante la codificación o prueba y peor aún si se trata de después del desarrollo.

El Analista “tiene” para tratar de minimizar los cambios de finales de la medida de lo posible. La mejor manera de hacerlo es mostrar al cliente lo que él va a conseguir con pequeños prototipos y el SRS. Los clientes pueden ver lo que van a conseguir y pedir cambios mucho antes de que el desarrollo ha comenzado. De esta manera el analista logra reducir el coste para el cliente.

En caso de que los cambios se producen, durante o después de la codificación, el líder del proyecto tiene que asegurarse de que estos cambios son controlados. Todos los cambios en la especificación debe ser aprobado por el cliente y debe ser revisado por los miembros del equipo. Todos los miembros del equipo deben obtener copias de la última especificación.

La mayoría de los proyectos en general, experimentan un cambio del 25% de las necesidades. Methodlogies requisitos de Buenas reducirá el número de cambios y el costo por el cambio. Por ejemplo, si la RA podría reducir el número de cambios a 10% y el coste del cambio por un factor de 5 o 10, el efecto combinado sería realmente enorme.

No puede usted, sin el código de análisis de requisitos.

Puede codificar sin ningún tipo de pruebas de análisis, diseño o incluso. Esto es lo que la mayoría de programadores.

Los clientes, jefes de proyecto y programadores en general, subestiman el valor del análisis de los requisitos de una buena y le dan el visto, porque por un producto de software “puede” ser desarrollado sin la debida requisitos, el diseño o las pruebas.

Pero los problemas empiezan a surgir en varios incidentes aislados.

Por ejemplo, probador afirman que han completado las pruebas y presentar el proyecto para el cliente. El cliente dice: “Oye esto no es lo que yo quería. Yo quería que el carrito de compras para ser almacenados en caso de que el comprador decide completar el proceso de pedido después de 2 días?” El probador puede incluso no haber tenido conocimiento de este requisito, el codificador no hubiera sabido, el líder del proyecto no habría sabido. Finalmente todo el mundo trabaja horas extras para desarrollar esta nueva función. El codificador dirán que es imposible desarrollar esta función con el diseño existente. A continuación, el diseñador tiene que torcer el diseño para incluir de alguna manera la nueva característica. ¿Será un diseño óptimo? Bueno, ¿quién sabe? Nadie tiene tiempo para averiguarlo. Finalmente, después de todo esa confusión, el cliente recibe la nueva característica que está mal diseñado y ejecutado.

Es importante el análisis de requisitos en proyectos más pequeños.

En proyectos más pequeños, la misma persona podría analizar, diseño y código. A medida que aumenta el tamaño del proyecto, todo lo que sucede es que los roles sean tomados por diferentes personas. ¿Qué es el proyecto de pequeña? Cualquier proyecto de más de 2 semanas de duración, debe incluir necesariamente el proceso de análisis de requisitos.

Categories: Software

Comments are closed.