¿Cómo escribo una especificación funcional de forma rápida y eficiente?

Así que acabo de leer algunos artículos fabulosos de Joel sobre especificaciones aquí . (¡Fue escrito en 2000!) Leí las 4 partes, pero estoy buscando algunos enfoques metódicos para escribir mis especificaciones.

Soy el único desarrollador solitario que trabaja en esta aplicación bastante complicada (o familia de aplicaciones) para una compañía financiera muy conocida.

Nunca he hecho algo tan serio, comencé a escribir algo así como una mala especificación, una descripción general de algunos tipos, y ha desperdiciado MUCHO mi tiempo.

También hice 3 maquetas para mi cliente, así que entiendo bien lo que quieren. También lancé una vista previa (una aplicación de trabajo desechable con el flujo de trabajo más básico), y solo he escrito y probado algunos de los sistemas básicos / básicos.

Creo que el error que he estado cometiendo hasta ahora no es escribir una especificación detallada, así que lo estoy haciendo ahora.

Entonces todo se compone de

• Un sitio web MVC (para administradores y visualización de datos)
• 2 módulos Silverlight (para 2 tareas específicas)
• 1 aplicación de escritorio

Tengo muy poco tiempo, recursos y necesito hacer esto rápido, también, necesito asegurarme de que estos chicos lo lean igualmente rápido y sin dolor.

• Entonces, ¿ cómo lo hago ? Estoy buscando algún consejo, cualquier cosa del mundo real, ¿cómo suelen hacerlo?
• ¿Se burlan de cada cuadro de diálogo / formulario / página?

Estoy pensando en hacer un proyecto ficticio de formularios web ASP.NET, luego completar archivos HTML en carpetas y hacer que se vea como mi estructura de URL MVC.

Luego, tener una sección en la especificación del sitio web y escribir una página para cada URL que tengo con un screenie.

Para mi aplicación Win Forms, hice una especie de proyecto Win Form de demostración, ¿ pondría en un cuadro de diálogo o estructuraría todo como lo haría en la aplicación real y luego la captura de pantalla?

Para algunos antecedentes sobre esta pregunta. Siempre he sido un tipo loco de saltar al código, que ha funcionado bien, pero para la aplicación en la que estoy trabajando, no solo es complejo, es para una empresa muy reputada y grande y tengo que conseguirlo ¡Derecha!

(¡Y hasta ahora ha ido bien, hoy di una demostración de la versión preliminar que a mucha gente le gustó! = D)

Si obtengo el diseño inicial correcto, también tendré un gran negocio con esta compañía, ya hay muchos pensando en nuevas características "increíbles" por las que están listos para pagar.

¿Leíste la parte 2 del artículo o su especificación de muestra ? Representan un par de principios importantes al escribir una especificación.

• No sobre diseño. El propósito de escribir la especificación es obligarlo a pensar en cosas importantes como lo que sucede cuando hay un error y cómo espera que el usuario interactúe con el sistema. No tiene que entrar en detalles desordenados para obtener algo con lo que pueda trabajar. Sin embargo, necesitas detalles.
• Se trata de la comunicación. El propósito de la especificación es llegar a un acuerdo común sobre lo que hay que hacer. No es un documento blindado que requiere la fuerza de la ley. Es una herramienta para ayudarlo a comprender mejor a su cliente y a su cliente para comprender mejor lo que quiere hacer por ellos.

El mejor consejo es escribir lo suficiente para que tenga claro lo que debe hacer. Si tiene preguntas abiertas, documente en la especificación y obtenga respuestas de su cliente. Una vez que comprenda adecuadamente lo que necesita, deténgase .

Si no tiene cuidado, el documento cobrará vida propia. Debe tener un propósito, no agregue nada al documento que no se ajuste a ese propósito. Debería ser fácil de mantener. Si tiene todos sus diagramas de clase detallados allí junto con otros detalles que realmente pertenecen a una prueba unitaria, abandonará el documento porque el mantenimiento es demasiado, o nunca completará el proyecto.

Sobre escribir

Escribir para la gente es difícil . De hecho, las dos cosas más difíciles de escribir es saber cómo comenzar y cuándo parar . Al principio solo tienes que hacer algo. Mi consejo para lidiar con estos dos aspectos más difíciles es:

• Conoce a tu audiencia. ¿Quién se supone que debe leer las especificaciones? Si solo son usted y el cliente, entonces es a quien le está escribiendo. Si tiene a alguien responsable de las pruebas, también tendrá algunas notas para ellos.
• Comience con lo más prioritario. Si bien la autenticación es importante, la pantalla de inicio de sesión es probablemente la pieza mejor entendida que la mayoría de la gente tiene que escribir. En su lugar, enfóquese en la función que más necesitan sus usuarios. Ya sabes, esa parte que les hace dinero y es la razón por la que necesitan el software.
• Complete los detalles a medida que surjan las preguntas y obtenga respuestas. Mantenga las cosas realmente simples con dibujos de servilletas si es necesario hasta que el cliente esté satisfecho con el arreglo. Es importante saber qué información está involucrada y cómo la usarán.
• Deténgase cuando agregar más no agregue valor. Hay algunos detalles que simplemente no desea en una especificación. Necesita saber cuándo tiene lo correcto. No necesita saber que hay una variable dentro de un método llamado "albaquerque". Eso es código fuente, no material de especificación.