Part 2, The Specification

Technology Requirements

For architectedfutures.net I’ve identified a range of technology requirements that I will use in my DrupalWordPress evaluation. These are based on the objectives and strategy that I’ve defined above, and they are based on a the research that I’ve conducted and desires about how I would like the community of practice to operate. Not all requirements are needed in the first stage. I’ll have to get further into the evaluation before I know if I might need to consider a stage-by-stage evaluation process.

At this point my requirements are divided into the following general groups:

  • Functional Requirements – per my description in the Part 1post. I have broken these into the following major sub-categories:
    • Content – defines requirements around the content management and content delivery aspects of the web facility.
    • Community – defines requirements around the community features of the facility, independent of the content.
    • Administration – defines requirements around the administration of the web facility and the community. This area will probably vary significantly between the three stages, growing in demand, complexity and sophistication stage-by-stage.
  • Non-functional Requirements – per my description in the Part 1 post. My tendency is to try to use the ISO 9126 organization here. What I will concentrate on in this section are the special items of concern to me which I will then fit into the ISO 9126 outline in my decision matrix.
  • Use Case Models – At this stage the use case requirements are very high level and closer to user stories. The purpose of the use case models is to describe general tasks that are to be accomplished with the system. What is consequential is the task. The tasks relate to the functional requirements. The alternative systems will then be evaluated in terms of how well the task is accomplished in that system. This provides a method to think about the requirements and the alternative systems in an operational context.

These requirements are expected to evolve somewhat as the evaluation process proceeds. Not all requirements need to be fulfilled by the basic infrastructure platform. The platform must provide the foundation services for fulfillment. Requirements may be fulfilled by the platform, by add-on modules or through custom development. Higher scores may be provided for systems where features are provided by “native” facilities.

Functional Requirements

Content

  1. Must provide support for “static” pages
    • Should be able to organize pages according to categories or tags
  2. Must provide support for blogs, articles, news, announcements and other temporal content
    • Temporal content should be able to have automatic scheduled publication dates
    • Temporal content should be able to have automatic expiration dates
    • Should be able to support multiple blogs – myself plus designated others
    • Should be able to support internal (private) and external (public) temporal content
    • Should be able to organize temporal content according to categories or tags
  3. Must be able to support topical group discussions (forums)
    • Should be able to associate forums with topics and/or groups (or not)
    • Should be able to arrange discussions in a hierarchical fashion
    • Should be able to organize discussions according to categories or tags
  4. Must provide support for publication of technical documentation as web pages – this should support both encyclopedic documentation, as well as narrative specifications
    • Should provide support for automated glossary annotation
    • Should provide support for footnotes management
    • Should provide support for table-of-contents generation
    • Should provide mechanisms for bibliography management and citation links
    • Should provide navigation assistance for lengthy documents (e.g., paging, chapter navigation, etc.)
    • Should be able to organize documents according to categories or tags
  5. Must support upload and download of files (images, PDFs, presentations, documents, etc.)
  6. Must support creation of custom content types that can be incorporated into standard categorization and tagging facilities
    • Should provide support for the extension of core content types by the addition of custom fields to enhance core types or to create new content types
    • Should provide support for consistent editing of similar content types
  7. Should provide a mechanism to maintain and manage selected content in the form of a wiki
  8. Must provide a documented open API for the incorporation of customized extensions to the core web processing framework
  9. Must provide a mechanism for incorporation of the Entity Architecture Tool Suite™ (EATS™) content repository as an integrated part of the web site
  10. Must support Tag Cloud generation
  11. Must be able to support internal links between static pages, blogs, articles, forums and documents
  12. Should be able to support reuse of content between static pages, blogs, articles, forums and documents
  13. Must support web bookmarks (links) and associated local content including descriptions, ratings, comments, etc.
    • Should be able to organize links according to categories or tags
  14. Must provide RSS Feeds
    • Should be able to organize feeds and feed subscriptions according to categories or tags
  15. Should provide RSS aggregator service
  16. Should provide support for calendar and event scheduling
  17. Must provide version control over published content
    • Should provide facilities to compare versions and highlight changes
    • Should provide facilities for authorized individuals to roll back content to a prior version
  18. Should support “newsletter” generation
  19. Should support group email for newsletters
  20. Must provide facilities to generate a site index
    • Must provide automated maintenance of a robots.txt file to manage web spider crawling
  21. Should provide workflow support for peer-reviewed content
  22. Must provide a facility for optional comments on all forms of content
    • Must provide a facility to disallow comments on any individual content item
    • Should provide a facility to disallow comments based on content type, category or tag
    • Should provided for hierarchical (threaded) comments to identify and clarify conversations involving comments on comments
  23. Should provide a mechanism for ratings on all content including comments
  24. Must provide mechanisms to create and manage polls and surveys
    • Must provide facilities to enforce one-person-one-vote policies
    • Should provide mechanisms to associate multiple poll elements as a collection
    • Should provide a mechanism to associate poll answers within a collection for purposes of statistical correlation (e.g., people who answered “x” to question 1 answered “y” to question 18)
    • Should provide a mechanism to automatically generate tabular and graphical feedback for polls and surveys.
  25. Must support WYSIWYG editing
    • For content development / editing
    • For comments (to eliminate the need/desire for HTML in formatted text, e.g., bold, italic, etc.)
  26. Should provide some mechanism to facilitate interaction and dialog among members who may not speak the same language without requiring all visitors to speak English. Internationalization – but not just static text translation of content for non-English speakers to be able to read. That is a first step – but it should also provide some ability for non-English speakers to post and comment and English speakers to be able to understand and read non-English comments. (Is there a translation app that could be used to translate a post in any language to any other language?)
  27. Should provide support for geo-tagging and geo-mapping of content
  28. Should provide support/aids for microformats to enable/assist in automated processing of content
  29. Should provide support for generation of RDF encoded content to support semantic web crawlers and semantic interlinking of online communities (SIOC)
    • FOAF – friend of a friend and DOAC – Description of a Career – for profile data
    • DOAP – description of a project
    • OPO – Online Presence Ontology – for publication of activity
    • SKOS – Simple Knowledge Organization System – for content mapping
  30. Should provide facilities (through an API structure?) to manage the integration of external web tools that might be employed to extend the content of the web site or otherwise support the activities of the community (for example, through user access authentication)

One thought on “Part 2, The Specification

  1. Pingback: Part 4, Decision Time | Building Architected Futures™

Share your thoughts ...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s