Siempre escribimos funciones o clases y su lógica es muy complicada. Si no hay especificaciones para estas estructuras, más adelante será difícil incluso para nosotros captar las ideas.¿Cómo escribir una especificación funcional?
¿Cómo se escriben las especificaciones para funciones y clases complicadas?
Por favor, dime algo sobre tu propia experiencia, pero no solo un enlace, gracias.
Creo que el mayor desafío con las especificaciones funcionales no es el formato directamente, sino mantenerlos sincronizados con las cosas que los impulsan (requisitos) y las cosas que se basan en ellos (casos de prueba, documentación).
Por esa razón, prefiero manejar este problema con un enfoque basado en modelos en lugar de uno basado en papel.
Utilizo una herramienta de modelado UML (Enterprise Architect de Sparx Systems, pero también funcionan muchas herramientas) para capturar todos los artefactos del proyecto en un solo lugar y crear la trazabilidad entre ellos. En Enterprise Architect, puedo crear la trazabilidad de un artefacto de requisito a un artefacto de diseño (por ejemplo) simplemente poniéndolos en el mismo diagrama y creando un conector de uno a otro con la función de arrastrar del mouse.
Mi "especificación funcional" es en realidad una colección de diagramas de actividad, uno por caso de uso en el sistema. Cada caso de uso se relaciona con uno o más requisitos que requieren ese caso de uso. Incluso los usuarios finales encuentran fácil seguir los diagramas de actividad y validarlos (¿qué tan fácil es que los usuarios finales lean, y mucho menos comprendan y validen, una especificación funcional tradicional basada en papel?)
En una similar De esta manera, puedo crear trazabilidad desde mis diagramas de actividad (casos de uso) hasta artefactos de diseño específicos como diagramas de clase.
QA puede modelar casos de prueba y crear trazabilidad desde sus casos de prueba a los casos de uso. De esta forma, vemos si hay casos de uso que no tienen casos de prueba (o no tienen suficientes casos de prueba).
Lo bueno de Enterprise Architect como herramienta es que todos estos artefactos se almacenan en una base de datos SQL, por lo que puedo ejecutar algunas consultas que he desarrollado con el tiempo para encontrar artefactos sin rastrearlos desde/hacia ellos .
'qué fácil es lograr que los usuarios finales lean, y mucho menos entiendan y validen, una especificación funcional tradicional en papel' Quizás no haya mucha diferencia en la práctica, pero el número de personas que admitirían no poder entender un inglés técnico claro es mucho más pequeño que el número de personas que admitirían no poder leer un diagrama en una notación técnica específica. – soru
Realmente revisamos las especificaciones/diagramas al tomar una sala de conferencias y un proyector, y recorrer cada diagrama con personas de negocios/analistas apropiados. Es increíble cuántos malentendidos y conceptos erróneos descubrimos antes de escribir una línea de código. –
Echa un vistazo Joel on Software. Y here. Y here. Incluso hay un mundo real example.
El ejemplo es correcto sobre el dinero. –
No estoy del todo seguro de que esto es lo que el OP está buscando, pero su artículo es una gran lectura y un buen ejemplo de cómo escribir especificaciones de funcionalidad del usuario y casos de uso. –
Usted debe hacer la investigación sobre los temas siguientes (no necesariamente en este orden):
Estos son los más comunes enfoques para proyectos de software especificat ion.
Veo algunas quejas anteriores sobre tener enlaces a las cosas de Joel, en lugar de texto en línea, así que aquí está mi opinión sobre lo que está diciendo.
En los niveles más altos, las especificaciones funcionales deben comunicar lo que el programa pretende hacer al consumidor o cliente. Estoy 100% al tanto de Joel sobre esto: el lenguaje inglés (¡cualquiera!) Utilizado con rigor es una herramienta muy poderosa que todos sus clientes serán expertos en digerir. Los expertos en UML no lo son.
Un documento de especificación funcional de alto nivel (FSD) puede proporcionar un marco lógico que captura los requisitos del sistema dentro de un modelo lógico que las personas puedan comprender fácilmente.
Los documentos de requisitos puros, algo que precede a un FSD, son un pez difícil de manejar. Muy pocas personas pueden diferenciar mentalmente lo que es un requisito y lo que es parte de la solución. Lo mejor es mantener los requisitos a un nivel muy alto y, como analista, centrarse en el FSD.
El FSD debe ser un modelo de nivel superior completo del sistema y un proceso de diseño posterior para completar una jerarquía de modelos con más detalle. El último nivel de detalle es código real.
El FSD debería terminar en un conjunto de simples declaraciones en inglés. Use un solo nivel de encabezado en los documentos, mantenga los parásitos con un máximo de dos oraciones y numere cada párrafo. Repase los párrafos y asegúrese de que cada uno diga algo útil. Si no, elimínelo. Corto es bueno!
Piensa mucho sobre el lenguaje en tu FSD. Tenga definiciones rigurosas de sustantivos clave en sus párrafos. Estos sustantivos se convierten en tus clases. Los verbos que usas se convierten en tus métodos de clase. ¡Es realmente así de simple!
Como dice Joel, escriba oraciones como si fuera a compilarlas. Por ejemplo, escriba "Si sucede cosas luego haga más" en lugar de "Si sucede cosas, haga más" o "haga más cuando pase algo".
Este tipo de modelos escritos se pueden beneficiar del uso de diagramas específicos, como diagramas de estados finitos, pero tenga cuidado de pensar que puede capturar un sistema usando un conjunto de diagramas UML. Estas cosas simplemente no son poderosas, flexibles o rigurosas para actuar como una descripción completa por sí mismas. Es mucho más efectivo comenzar con un bosquejo escrito en inglés riguroso y complementarlo según sea necesario.
En cuanto a los problemas de iteración, en un mundo ideal, solo debería necesitar volver a trabajar los niveles inferiores del modelo. Si tiene que cambiar los niveles altos, algo serio estaba mal. En cuanto a las herramientas UML que son más rápidas para habilitar la revisting - poppy-cock! La clave es que todas estas descripciones son CORTAS y CONCISTAS. El inglés es el camino a seguir, porque todos lo hemos practicado durante tanto tiempo.
He visto a personas pasar una tarde tratando de hacer que los "me gusta" de los diagramas de entidades se vean bonitos en términos de líneas superpuestas. Como por que? ¿Es su solución definitiva las cajas y líneas bidimensionales? ¡No! Y ese es el problema con UML: los diagramas se convierten en un fin en sí mismos para el analista, y te separan del cliente, en lugar de ayudar a la comunicación.
He editado su inglés. Estoy razonablemente seguro de que sé lo que quieres decir ... No me ofenderé si lo cambias de nuevo. :-) –
¿Está buscando consejos sobre la escritura de especificaciones para estructuras de código reales, o para la funcionalidad de usuario sin formato de un programa? En mi empresa, los documentos de especificación de la estructura del código se denominan "especificaciones de diseño" y las descripciones de la funcionalidad del usuario se denominan "especificaciones funcionales". La respuesta de Joel on Software describe las especificaciones de funcionalidad del usuario. –
Creo que necesito un "documento de especificaciones", Gracias Paul Nathan – MemoryLeak