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] ___________________________________________________________________