Documentos IEEE SRS: ¿versión liviana cuando se trabaja con contratistas externos?

7

Normalmente, seguimos un proceso de desarrollo Agile que tiende a no poner énfasis en los requisitos de escritura y los documentos técnicos que nadie leerá. Tenemos la tendencia de centrar nuestra limitada mano de obra en actividades de desarrollo y pruebas con diseño colaborativo y pizarras blancas como un enfoque clave.

Hay un componente web en su mayoría autónomo que tardará unas semanas en desarrollarse, pero este trabajo puede ser paralelo a otros trabajos de proyectos en curso. Para intentar recuperar el tiempo, me dieron un presupuesto para contratar a un desarrollador en oDesk para completar este trabajo.

Si bien mi equipo no está acostumbrado a trabajar en un documento SRS firme, me doy cuenta de que con el desarrollo subcontratado es una buena idea ser lo más firme y específico posible, por lo que me doy cuenta de que necesito proporcionar los requisitos detallados. y el documento de especificaciones técnicas para que este trabajo se realice correctamente.

Cuando escribo un documento de Requisitos, normalmente utilizo la plantilla de documento estándar de IEEE SRS, pero creo que esto es demasiado detallado y probablemente exagerar lo que necesito para comunicarme con un desarrollador. ¿Existe otro documento de requisitos que sea más liviano y que también sea aceptado por una organización de estándares importante como el IEEE?

Además, como lo que se desarrollará como un módulo de software que interactuará con otros módulos de software, mis necesidades realmente necesitan profundizar en las especificaciones técnicas para que las cosas funcionen correctamente. En este escenario, tiene sentido combinar las especificaciones técnicas y los requisitos en un solo documento, y si no, ¿cuál es una alternativa viable?

    
pregunta maple_shaft 12.12.2012 - 19:56

2 respuestas

5

La mejor opción es probablemente tomar una plantilla existente o two (para la compra, también se encuentra en los apéndices de Requisitos del software ) o three y personalícelas. Elimine las secciones que sean irrelevantes para sus necesidades o agregue nuevas secciones que le gusten de una plantilla al resto de otra plantilla. Combina secciones juntas si eso tiene sentido. Cuando se combinan, es probable que cubran todos los tipos posibles de preguntas que se pueden hacer, solo es cuestión de completar los detalles donde se necesitan.

La personalización haría que no coincidiera con las plantillas de las principales organizaciones de estándares, pero la personalización es un componente clave de los programas de mejora de procesos e implementación. No creo que nadie tenga un problema con una plantilla personalizada, en la mayoría de los casos. Para mí, la eliminación explícita de secciones lo convierte en un documento más agradable y más fácil de leer que el texto que dice "no se aplica".

En cuanto a proporcionar especificaciones, dudaría de lo que se proporciona. Si va a proporcionar entradas en un formato específico, proporcione ese formato. Si otro sistema consumirá salidas, proporcione el formato de salida esperado. Estos podrían ser diagramas de ferrocarriles, esquemas XML, mapas de diseño de bytes y cualquier entrada / salida de muestra (desinfectada, si es necesario). Si está especificando algo que necesita ser un reemplazo directo para otro sistema, también puede ser necesario especificar la interfaz pública. Sin embargo, recomendaría dejar al alcalde tanto margen de maniobra como sea posible para diseñar y construir un sistema alrededor de sus requisitos.

En mi experiencia, a menudo hay una separación de los requisitos del sistema y una descripción detallada de las interfaces entre los componentes. Aunque no creo que esto sea siempre necesario. La conformidad con una interfaz especificada es, técnicamente, un requisito de comunicación o entorno ("el sistema proporcionará resultados en XML que se ajusten al esquema definido en el archivo de esquema"). Separar los dos es probablemente más apropiado cuando se describe un sistema de componentes relacionados en lugar de un solo componente, donde diría que es mejor tener un recurso único e integral para lo que se espera que produzca.

Recomiendo que se acerque a esto para definir solo lo que necesita de este sistema, dejando todo lo posible para el desarrollador. Si pasa demasiado tiempo haciendo la especificación de modo que solo hay una o dos soluciones, entonces ha hecho la mayor parte del trabajo intensivo de tiempo (en mi experiencia). Como desarrollador, usted probablemente sepa qué preguntas puede hacer si le presentan el alcance general del sistema que desea, responda a estas de la manera más clara y específica posible y espere que el desarrollador le haga cualquier otra pregunta que no haya pensado. .

    
respondido por el Thomas Owens 12.12.2012 - 20:30
2

Resumen

Si es Agile, hay un par de cuestiones a considerar. En primer lugar, SRS no se usa en Agile, y en segundo lugar, el IEEE no lo respaldará con ningún estándar, ya que no se aplica aquí.

Historias de usuario, no SRS

La mejor opción sería reconsiderar la metodología a algo como RUP , o practicar Agile correctamente y beneficiarse de su Las soluciones nativas a los problemas, es decir, en ágil, los requisitos se especifican como Historias de usuarios .

Metodologías ágiles

Considere Scrum , por ejemplo. Todas las historias se apilan por primera vez en Product Backlog. Luego, el Propietario del producto (usted) selecciona las historias que deben implementarse en el próximo sprint colocándolos en Sprint Backlog. Finalmente, la iteración comienza y puedes ver el gráfico de Burndown para ver cómo se están implementando las historias.

Otra metodología ágil recomendada es TDD o BDD donde se refina. El desarrollador primero escribe las pruebas basándose en las historias de los usuarios y luego codifica las partes internas reales del software para pasar las pruebas.

Del mismo modo, hay Programación Extrema , Crystal , DSDM y otras metodologías ágiles a considerar.

Proceso de software

Al practicar Agile, o cualquier otra metodología, es imperativo que la metodología en particular se elija bien y se siga con cierto rigor. De lo contrario, "estamos usando Agile" se convierte en "estamos usando un proceso que no se reconoce formalmente y en realidad ni siquiera estamos seguros del resultado, no sabemos lo que estamos haciendo, pero ya comencemos a piratear"

    
respondido por el user42242 31.12.2012 - 17:45

Lea otras preguntas en las etiquetas