Cuando diseño programas, primero diseño la interfaz de usuario usando prototipos de papel. Pruebo el prototipo de UI de que los usuarios pueden alcanzar sus objetivos con él. Tener algo concreto/visible para mostrar a los usuarios y clientes hace que sea más fácil explorar los requisitos y descubrir lo que realmente necesitan los usuarios.
En la fase de diseño de la interfaz de usuario (análisis de requisitos), siempre intento diseñar la solución ideal. No tomo en consideración lo difícil que sería implementar alguna característica. Luego, cuando el diseño se haya estabilizado lo suficiente como para implementarse (por lo general, toma una semana o dos), discutimos con los clientes y programadores sobre cuánto se necesitaría para implementar las cosas y qué cosas son las más importantes.
Porque primero diseñamos la solución ideal, podemos ver la imagen completa de lo que se necesita, y podemos comenzar a ajustar el alcance del proyecto, de modo que primero solo se implementen las características más importantes. Además, si algunos de los diseños de interfaz de usuario ideales serían demasiado costosos de implementar, podemos hacer un diseño comprometido que tenga una usabilidad ligeramente menor, pero que sea mucho más económico de implementar. El diseñador de la interfaz de usuario es siempre la persona que diseña el compromiso (es decir, no los programadores), por lo que cumple todos los requisitos y su capacidad de uso será lo suficientemente buena.
"Ingeniería inversa" significa algo completamente diferente, FYI. Se refiere al uso de un artefacto existente como una guía para construir su propia implementación del mismo. – chaos
Voy a editar la pregunta para reflejar eso; edite mis ediciones si tiene problemas. – chaos
De acuerdo con aprender más al respecto, consulte esta pregunta: http://stackoverflow.com/questions/130933/design-coding-top-to-bottom-or-bottom-to-top – chaos