Re: Modelling and communicating dynamic Web functionality

"Alan Litchfield" <[email protected]> Thu, 20 Aug 2009 10:08:12 +1200 (NZST)
Newsgroups gmane.comp.infodesign.general
Message-ID <[email protected]>
Hi Conrad,

I have had these kinds of projects often in the past, and still do from time
to time.

Seems to me that there are number of issues that need clarification.
1. Are you writing a brief or preparing an RFP? A brief is just that, brief.
It leaves wide scope for discussion and response from prospective partners. An
RFP on the other hand needs to be sufficiently well specified so as to remove
ambiguity from proposals when they are received.

2. I am not assured that a relational database concept will help achieve what
you are seeking to do. That is, using relational concepts to think about what
you want to achieve will only serve to limit what you get. While many/most CMS
system use relational databases of various kinds you should not limit yourself
thinking in that way. Instead, consider what the real relationships between
objects ought to be, then leave the execution up to the RFP responders to
deliver the required solutions.

3. It is true there are many modelling languages and approaches. These days
UML seems to be the flavour of the month and while it is strongly biased
towards java developments it is very useful for achieving the goal of defining
object relationships and interactions. However, have you thought of using Soft
Systems Methods and drawing a "rich picture" to get a clearer overview first?

4. I think some of the confusion you mention has to do with coming at the
problem with top-down and bottom-up thinking, at the same time. If you are
coming from the top down, then ignore all temptation to engage in thinking
about what kind of software will deliver what you want. Leave that to the
specialists who run their preferred flavour, but also make certain that what
they propose fits with your over-arching concept.

5. Talking about screens is great for defining what the systems are required
to deliver, but try to avoid getting into detailed discussion about what
content goes onto which screen. Build classes of screens and call them
objects, that contain other objects, then you can build a hierarchy of screens
and a logical structure. And you can begin to see where objects are shared
across classes. Whiteboards and post-it notes are great for this.

HIH
Alan

-- 
Alan Litchfield MBus (Hons), MNZCS
AlphaByte
PO Box 1941, Auckland
http://www.alphabyte.co.nz

___________________________________________________________________

Use the following address to post a message to all subscribers: 
 [email protected]

To subscribe, unsubscribe or change your options, visit:
 http://list.InformationDesign.org/mailman/listinfo/infodesign-cafe

For all Information Design matters:
 http://InformationDesign.org

Problems? Write to:
 [email protected]
___________________________________________________________________