James Here are some off-the-cuff observations for an ‘information model’. These come from a background of specifying requirements for fixed-time fixed-price contracts with big CMS components. I’m interpreting ‘Information Model’ as the thing that defines (most of) the requirements,
Problems 1) You want something that defines requirements, in a manner which helps a multidisciplinary ( business tech, content, creative, vendors !) team. Often, if you produce different docs for these audiences, you have a hard time keeping them in synch, but if you just produce docs for one audience, that audience drives the solution. This is why just doing a sitemap ( design- driven) or use cases (business or tech driven) doesn’t answer the problem 2) You can’t just provide a business-facing document, as CMS systems are still at an immature stage. This means that there will be trade-offs with tech and creative, so its best to have them involved early. 3) In a good CMS based system, it should be relatively possible to support a new site-map (e.g. new navigation and interaction style) from the same CMS, but as the sitemap is often the only clear requirement, the CMS is often tied to the first site-map in a brittle manner 4) As most people on this list know, content is king, content maintenance is the dominating long-term cost, but content is often considered last Answers (this is a composite based on different projects) A) – CMS based system Reqts Model – i) Write up business objectives/ business case. List brand requirements. Identify stakeholders as in Use cases ii) Segment end-user groups. Build or research quick ‘personas’ for representatives of user groups e.g. “ Doris is 67 yr old grandmother who is computer literate and uses Win 98. She wants to be re-assured about her current investments and understand a bit of the investment strategy behind them”. Expand these over time to record user needs iii) Document the core content at a high level. Include sourcing, volumes and throughput and any special workflow requirements (quick workflow picture here helps). Say who the intended audience is. If possible have real examples of the content (including exact copy, pictures etc.) iv) Document the functionality with a high-level set of use cases (e.g. View/Edit/Delete/Preview page, Post to bulletin board, Search, Integrate with System X). This should NOT refer to pages. Detail the points where you feel unsure (e.g. security, integration) v) Describe the key entities on the site ( e.g. a unit trust site might have product info, advisory info, personal portfolio, transaction pages, news) vi) Model the relationships between the key entities in a way which business users and tech architects both understand – one pager ER diagram e.g. a user has multiple accounts each which may have multiple products. Products are organised regionally … vii) Keep a laundry list of non-functional requirements (performance, XML compliance etc.) Finally - using magic (which always happens on any design) bring together ii)- vi) to build viii) A list of the core content types, including sub-fields, metadata and workflow (e.g. “product”) –Keep these numbers down ix) Pictures & description of the core display templates – Number these and all subcomponents. Describe functionality . link back to use cases, and cross reference displayed content to content types – Keep these numbers down x) A big sitemap – which shows site structure, template types, key cross- navigation, secured areas, content re-use and has rough volumes on it (e.g. # news pages). For a big big site, you probably need a meta-site map which shows the different subsites, their governance etc. ( I haven’t done this) xi) A big spreadsheet, indexed by display template, which shows display templates, where used on site/with what content/with what special functions etc. viii) – xi) + iii) gives an information model Problem is you don’t want to go in to too much detail before you have selected a CMS, but you can certainly do a little of everything above. I know the above looks heavy, but many of these documents can be created in ˝ day each with a good team, and failing to write them down courts risk. AND/OR B) – Choose a single person who owns the system design – let them document as they see fit, but keep them involved in everything from beginning to end. Support them and don’t let them burn out. This is because in my observation, success comes from having a single person who tracks the whole system design and requirements and accepts the system and oversees the tests e.g. they are at all meetings with the business and all reqts type meetings. They are usually detailed, open-minded, hard-working, have good common sense, good at communication, dogged and they genuinely care about success. They are probably not techies, but are willing to learn technology, they have some design sense and are often female (no flames, this is an empirical observation) Sorry for the length, hope this helps. Can’t give sample docs as they are all client specific, but happy to chat off-list. Jim Dallas [EMAIL PROTECTED] ---------------------------------------------------------- This message was sent using http://uk2.net NEWS - CHEAPEST DEDICATED SERVERS IN THE WORLD - 25/month FREE UK DIAL 0845 609 1370 - username uk2: - password: uk2 UK's FREE Domains, FREE Dialup, FREE Webdesign, FREE email -- http://cms-list.org/ more signal, less noise.
