APR: Mixing It Up With Design And Requirements

prototyping flow
With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?

Prototyping.

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.

Functional Prototyping

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.

UI Prototyping

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.

Documenting Requirements

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.

Iteration

Concurrency

This process will be iterative or concurrent. The goal is to get enough of an understanding of the design to create an initial prototype.

4 Comments

James Taylor

Posted April 26, 2007 at 1:05 pm

Me, I would be thinking about the rules too. I might even be creating rule templates that would allow business users to add their own rules to the repository.
JT

Reply to this comment
Scott Sehlhorst

Posted April 26, 2007 at 2:34 pm

Hey James – great catch that rules are conspicuously absent. Can you throw out a couple examples of the kinds of rules that users might apply in this project?

The only one I had come up with so far was contact settings for communication between users. I’ve represented this as an enumeration in my domain model (UML Static Diagram), and I expect to describe it as a requirement – “user can specify contact level (see list of choices).”

Thanks for starting this thread!

Reply to this comment
Rolf

Posted April 27, 2007 at 3:01 am

my .05 are thinking about the “how well” and “how much”: Performance,
Quality, Resource Saving, Workload Capacity. I believe in the theory that nonfunctional requirements are more numerous in specs the higher level the spec is (not necessarily in fact but in good practice :-)

For example, for me it is very important that all the small interactions with the site, like rating, suggesting, searching, show their results extremely fast. I can wait a little longer for an article to be loaded.
Another example would be reliability: I’d like to see my comments right away.
Or, the sheer amount of articles should not cause the site to slow down. I’d like to see the pages using bandwidth economically, as I will sometimes use my mobile phone.

Reply to this comment
Scott Sehlhorst

Posted April 27, 2007 at 9:11 am

Excellent suggestions, Rolf!

I put “how well” and “how much” in the “more is better” bucket, so I will definitely tackle these immediately after the “must be” stuff. But I agree that there is some level of performance that “must be” – will manage that as we go.

My plan, since we’re learning Rails as part of this project is to

1)set up deployment infrastructure (instantRails, svn, etc)
2)create a VERY rough prototype and deploy it
3)work out the change management process (iterate the prototype and deploy the update)
4)start tackling performance stats, etc. If there are performance issues with a handful of users, that speaks to really bad design on my part – will open up to maybe 10 people to “bang on” the first iterations, and grow the user base as the site gets more functional. I suspect there are great perf-tracking products/gems for rails, I just don’t know what they are yet.

Your suggestions on specific things to look at for response times are great ones – will definitely include them.

Reply to this comment