With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?
Depending on which discipline is dominant in the project approach, the next step could be to define the functional requirements (or specification) that support the use cases. Or it could be to take user-centric approach to prototyping interface elements. Or it could be developing an understanding of the domain model that will drive the behavior of the site.
Ruby on Rails (Rails, for short) makes rapid prototyping of the “under the hood” stuff appear to be very quick to develop. And Rails separates the presentation from the logic with a model-view-controller approach to code structure. From the reading I’ve done about Rails, the next step needed to get an interactive prototype is to define the representational model.
In the better object oriented programs I’ve worked on in the past, the underlying representation matches the user’s conceptual model as well as possible. This will be challenging to not confuse the two and expose the implementation to the users. I’m not sure what differences will exist between them, we’ll see when we explore this. Creating a UML static diagram of both will help.
Creating some mockups of the user interface and documenting some design elements and interaction ideas will help here. I started that process last night and have the first initial thoughts drawn on paper. I will scan those in and post them as paper prototypes.
If we were using a purely structured requirements approach, we would create an SRS at this stage. In conjunction with this prototyping approach, we will capture those same requirements. The requirements will be defined in the context of the individual use cases that we are focusing on for the first release. Don’t forget to vote on the use cases if you haven’t already.
This process will be iterative or concurrent. The goal is to get enough of an understanding of the design to create an initial prototype.