Research & Planning

This section contains documentation relating to the research and planning phase of our project. It includes some general documentation giving guidelines on HOW to write requirements and use cases most efficiently.

Good Language Practices

Good Practices

  1. Use simple direct sentences.

    Every requirement should be a single active sentence, as short as possible, but no shorter. Long rambling sentences quickly lead to confusion and error, not to mention boredom for the reader.

    The user must login to the system by entering a password and a username which will be verified by the system against the usernames and password that they have stored in the user information repository in order to ensure that the user is a valid user who has the right to user the solution.
    The user will login by way of entering a valid username and password combination.

  2. Make requirements atomic.

    Requirements must be atomic in order to ensure that compliance with the requirement is measured by the single goal of the requirement being achieved. If you can think of a small number of related tests to verify a requirement’s implementation, it’s probably written at the right level of detail. If you envision many different kinds of tests, perhaps several requirements have been lumped together and should be separated.

    The user will be able to create, edit, delete, suspend, open, and replace all files which they have the necessary access to.
    The user will be able to create a new file, as long as they have the Add File user right.

  3. Avoid ambiguity

    This is one of the most subtle and difficult issues in writing requirements due to its subjective nature. In order to achieve this goal the requirement must be clear and explicit, but care must be taken not to take this too far as the text can become unreadable and boring and this will defeat the core objective of requirements – in other words they are meant to be read by others.

    In order to delete a task the user must enter some details.
    In order to be able to delete a task the user must enter a further password which grants them the rights to delete a task.

  4. Use definable and non-vague terms

    Many words used informally to indicate desired qualities are too vague for use in requirements. Vague terms include “user-friendly”, “versatile”, “flexible”, “Configurable”, “Approximately”, “as possible”, “efficient”, “high performance”, “quickly”, “modern”, “well designed”.

    The searching functions must be as efficient as possible.
    The searching functions must return their results in no more than 10 seconds regardless of the size of the results.

  5. A Requirement must not be too high level

    A good Requirement is at a high enough level to be understandable and precise enough to be complete.

    The solution will have security.
    In order to protect the data the system shall be subject to security by way of all users being required to enter a valid username and password combination in order to perform any function.

  6. A specification should not contain contradictions

    Care must be taken that requirements do not contradict themselves in their descriptions, nor contradict other requirements

    The system will be a 24x7 solution although it will normally be unavailable on weekends.
    The system will be available 5 days per week through out the year.

  7. Requirements must be technically and legally possible

    There is no use in specifying requirements which are technically impossible or beyond the law as they will never be implemented.

    The system will read the mind of the user and determine which colour is their favourite.
    The system will establish the favourite colour of the user by asking them pre-defined questions, in order to establish their favourite colour by process of elimination.

  8. Requirements must be necessary

    A good requirement should be a business necessity and not a wishful thought by an individual.

    It would be good for the solution to enable a user to add more than one property to an application, although only one property can be linked to an application.
    A user can add only one property to an application.

  9. Focus on stating results

    Every requirement should specify clearly a single desired and achievable result.

    The printout will contain some text, although it is uncertain what this text will contain.
    The printout will contain a list of users and their address details.

  10. Define verifiable criteria

    Every requirement must be verifiable. Often it is possible to indicate the method of verification by adding a simple phrase to qualify a basic need. This enables the requirements to be a good base for the acceptance criteria of the solution to be delivered.

    The solution must be designed in order to guarantee that all of “very famos company” staff will enjoy the experience of using the application.
    The solution must be designed in accordance with the user interface guidelines specified by standards.

  11. Do not design the system

    Requirements specify the design envelope, and if too much detail is supplied the design of the system will begin prematurely. Sometimes this is unavoidable if a requirement is to design the solution in a certain way, which in effect locks the designers in to designing the system according to the requirement stating the design constraint. Specifying the design rather than the actual need often increases the cost of systems by placing needless constraints on design and development.

    The user entity will be made up of three tables. The user table will be joined to the role table via the user_role table allowing for a user to have multiple roles.
    The data model will enable a user to have one or more roles.

  12. Looking at a requirement from developer’s point of view can assist in measuring its quality

    To see if a requirement statement is sufficiently well-defined, read it from the developer’s perspective. Mentally add the phrase, “call me when you’re done” to the end of the requirement and see if that makes you nervous. In other words, would you need additional clarification from the System Requirements Specifications author to understand the requirement well enough to design and implement it? If so, elaborate on that requirement before you proceed.


  13. Do not build in let-out clauses

    Requirements which contain let-out clauses significantly increase the risk of the requirement not being fully realised. They look as though they are asking for something definite but at the last moment they back down and allow for other options. Problems arise when the requirements are to be tested and someone has to decide what, if anything could prove the requirement was not met. Dangerous let-out word include “if”, “when”, “except”, “unless”, “although”.

    The login process will never take no longer than 3 seconds unless the system is busy.
    The login process must not take longer than 5 seconds to complete at all times.

  14. Avoid wishful thinking

    Engineering is a real-world activity. No system or components is perfect. Wishful thinking means asking for the impossible. Developers will rightly query or reject wishful requirements. Wishful terms include “100% reliable”, “Hand all unexpected failures”, “Satisfy all users needs”, “Run on all platforms”, “Never fail”, “Perfect”, “Upgradeable to all future situations”, “future proof”.

    All web browsers will be supported including any future browsers without the necessity to change any of the code.
    Internet Explorer 5 and above, Firefox 2 and above will be supported only on a Microsoft Windows operating system.

  15. Do not mix requirements and plans

    Plans are essential, but they do not belong in the requirements of a solution. Usually they are updated throughout the project life-cycle, where as the requirements should stabilize. Mixing requirements with plans tends to increase the requirements workload through extra revision and review meetings. Danger signs are references to dates, deadlines, project phases and development activities.

    The solution will begin as a desktop application but will be converted into a web application at some time in the near future.
    The solution should be written so that a web version can utilise the core code without the necessity to re-write the core code.

  16. Do not speculate

    Requirements are part of a contract between customer and developer, with users as interested third parties. There is no room for “wish lists” – general terms about things that somebody probably wants. Danger signs include use of generalisation words such as “usually”, “generally”, “often”, “normally”, “Typically”.

    The solution will most likely be deployed on five servers.
    The solution will be deployed on five servers.

  17. Do not express possibilities

    Possibilities are indicated with terms such as “may”, “might”, “ought”, “could”, “perhaps”, “probably”. If developers do what they have to, they will always ignore things that user might possibly require.

    At some point in the future the solution may need to be able to run on UNIX servers.
    The solution must be able to run on servers with both Microsoft Windows and UNIX operating systems installed.

  18. Take care when using the word “Or”

    The word “Or” can often cloud or severely confuse a requirement and render it as un-verifiable due to the conditional nature of the requirement. Where “Or” is used, often this indicates that there are two requirements being joined into one.

    The user can download customer documents to their local machine or they can print the files.
    The user can download customer documents to their local machine

  19. Avoid stating requirements redundantly

    While including the same requirement in multiple places may make the document easier to read, it also makes it more difficult to maintain. This results in the necessity to update multiple instances of the requirement at the same time to avoid inconsistency.


  20. Avoid jargon, abbreviations and colloquialisms

    Where possible avoid jargon, abbreviations and colloquialisms. Where jargon or abbreviations are used, they must be listed with their meanings in the project glossary.

    If a user enters their SAD, they will in effect be considered as top dogs of the system.
    If a user enters their special authentication details, they will be considered as super users, which entitle the users to perform all functions.


The scope this section is to present all functional requirements for “IofC Drupal Project”.

Requirements defenition All requirements are grouped into the following top level packages:

Functional Requirements Functional requirements depict the operations that the IofC desires the solution to be able to perform.This is the most important type of requirements as it answers the question “What does the solution have to do?”

Non-Functional Requirements Non-functional requirement are mostly constraints which we have to work with in order to make the solution do, what the functional requirement state it must do.


Each top level package will have a two letter prefix which identifies the type of requirements which will be within the package or within sub-packages under the package. The high level outline of structure is illustrated below:

  • FR – Functional Requirements
  • NF – Non-Functional Requirements
    • BR – Business Requirements
    • UR – User Interface Requirements
    • HR – Hardware Requirements
    • SR – Software Requirements
    • PR – Performance Requirements
    • XR – Security Requirements

A package represents a group of requirements that have a common theme or are linked to the same area in the solution. All requirements packages under the top level packages and requirements will have a unique prefix which is constructed in the following manner: "AAnn_nn - Package Name/Requirement Short Description" AA refers to the two letter prefix identifying the type of requirement, and nn being a numeric which will be unique under each top level package (i.e. Requirement Type). The underscores (_) represent how many levels under the top level packages the requirement/sub-package resides.

FR - Functional Requirements

This is an early draft.

Functional requirements for IofC Drupal project. Version 2.2

Notes Open issues (19) Phase Priority Difficulty Version
FR01 Multiple Domains/Sites This package relates to the functionality required for providing multiple websites within one integrated system.

FR01_01 The solution must deliver an integrated system for running many domains/websites initially 20-25, but growing.
1 High High 1
FR01_02 Each domain/website must be able to define a look for its user interface using site specific theme using theme, menu and administration.

1 High High 1

Each domain/website must be able to build its own content.

FR01_03 Nodes, images and users/contact records must be shareable across all domains.

1 High High 1
FR01_04 Solution must use single Drupal's codebase for all websites Having one codebase we can simplify process of installation of security patches and upgrades of Drupal core. There are a lot of tricks how to achieve that. WE should choose one which suites the best for our needs. 1 High High 1
FR01_05 A User must be able to login from any site provided by solution . Users are shared across all sites, so that any authenticated user has access to the ‘private’ part of any website, and is able to move seamlessly between these ‘private’ websites without being required to log in again. How to share user's accounts ? Think about global Directory using OpenLDAP. Dupal modules: ldapauth, ldapgroups, ldapdata. Seems to be promising for that. 1 High High 1
FR01_06 Each website (an international one, and 20-50 national and programme-oriented ones) needs to have both: A ‘public’ part (for anonymous users) and A ‘private’, community part (for authenticated users)
Notions “public” and “private” site-part are misleading here. It sounds like 2 separate places. Do you agree ? Each Drupal basic building block (node) must have access attribute, that will differentiate a node like public ( for anonymous users) or private ( for authenticated users)

FR02 Groups This package relates to the group system to be implemented.

FR02_01 Solution must provide dynamic “Group creation” functionality The process of creating a Group must be easy and intuitive and minimise the need for intervention by sitewide administrators. 4 group roles should be created automatically for a group when that group is created: * Member – defines who is part of the Group * Administrator – can administer all parts of the Group's membership except editing of contact records. * Webmasters – administers pages and content for the Group, including for a public website belonging to the Group. * Data Controller – responsible for those contact records assigned to the Group's data controllership (if any). One group may have a website, but another may not. If a group does not requires a dedicated website, then why does it require a Group-webmaster role in place ? 1 High Unknown 1
FR02_02 Solution must provide dynamic “Subgroup creation” functionality A group must be able to contain another group, so that the members of the subgroup are also members of the containing group.
1 High Unknown 1
FR02_03 Group creation operations must be tied to a role. Any Advanced User may create a Group.
1 High Unknown 1
FR02_04 Group administrator must be able to define additional group specific roles Any group member may have as many roles as required.
1 High Unknown 1
FR02_05 Group must be able to create ant type of Content A site may have many groups associated with it -- when a user creates a new site at least one group must be specified -- that group's content (team homepage etc.) will automatically be linked to the new site.
1 High Unknown 1
FR02_06 Each group must have its own calendar Events will be shown in group-calendar. Group administrator can hide events from their group calendar.
1 High Unknown 1
FR02_07 Access to some content on each private website must be able to be limited to a group. Groups need to be able to have their own Group pages/menus, etc within any domain/site.

FR02 Internationalisation This package specifies the multilingual functionality required.


Each website must be deliverable in two or more languages. where needed
1 High Unknown 1

Solution must provide a possibility to install additional languages. English will be default language for the system. Other languages installed initially will be: French, German, Swedish, Norwegian, Finnish, Dutch, Spanish, Portuguese, Russian, Chinese, Japanese.
1 High Unknown 1

There must be provision for RTL languages. Drupal core provides RTL
1 Low Unknown 1

On a multilingual website, the visitor must be able to choose from available languages. Chosen language must be used for user interface. The user interface must be in the chosen language, where translated strings are available. Strings must be multilingual
1 High Unknown 1

1 High Unknown 1

Content/nodes must allow a translation workflow.

1 Medium Unknown 1

The translation workflow should have an automated notification systems for translators.

1 Low Unknown 1

FR03 Theming This package describes issues related to the look and feel of the website.

FR030_01 Themes for national and programme websites must be easily cloned and adapted from default template. The default theme must be based on the current template at
1 Low Low 1
FR030_02 Solution must provide UI template support Visually unrelated themes must also be available for some websites.
1 High Low 1

FR04 Content This package details the main types of content to be used.

FR04_01 Support for following content types must be provided: Page, Article,(Story), Event, Blog, Book, Forum, Project and Project issues, Images, Feedback, Comments A node must be editable only by its creator and by users of the group which 'owns' it.
1 High High 1
FR04_02 Each content type may have its own required fields, in addition to the default set.
What is the purpose of that “required field” ? 1 Unknown Unknown 1
FR04_03 Each content type must be configurable to allow revisions, comparison of revisions, and reversion.( Except Comments)

1 Low Low 1
FR04_04 Nodes must be shareable across domains and groups unless specified below. Thus a node published on Site X would generate the following possible options: * It could be published by Webmaster X only on Private Site X and/or on Public Site X * It could be shared with the Network (all sites) but not actually published anywhere else by default * Webmaster Y could then decide to publish this node only on Private Site Y and/or on Public Site Y * Only the creator of the node (Webmaster X in this example) is allowed to edit/delete the node * Webmaster X needs to be able to publish the node only to Group Z (a group exclusive to Site X), in which case it would be visible only to members of Group Z on Private Site X and not anywhere else on Site X or in the Network. Webmasters of Sites Y and Z obviously need a method to view all nodes which have been ‘shared’ by other Sites, and decide whether to publish them to their site. The only amendment to the general rules above might be that a node published in Site X (but not restricted to a Group) might automatically also be published to Private Site A (the private/community section of the parent/hub/international site).
1 High Very high 1
FR04_05 Vocabulary of types must be used for content classification.

1 High Low 1

FR05 Page


FR05_01 It must be possible to create Pages. Pages may only be added and edited by Webmasters
1 Low Low 1

FR06 Article (Story)


FR06_01 Articles must be of at least one type defined by an articles vocabulary Articles may be added by any user, but their audience depends on user permissions
1 High Low 1
FR06_02 Articles must be able to be aggregated into 'issues' of a publication, and each issue of a publication must be able to carry identifiers such as volume/issue number and dateline.

1 Unknown Unknown 1
FR06_03 Articles must be able to be linked to an 'author' (not necessarily its creator) and this author must be linked to a contact record.
What does it mean “linked” ? 1 Medium Unknown 1

FR07 Calendar and Event



Events must be of at least one type defined by an events vocabulary Events may be added by any user, but their audience depends on user permissions
1 High Low 1

Events should automatically be added to the calendar of the group in which the event was created.


Events should by default automatically appear on the system wide calendar for the Extranet.
All events ? What about private events ? 1

Group administrator can hide events from their group calendar.
Why is this required ? 1

The event content type needs to be linked to an online system for managing participation in events.
Managing participation of events ... ??? Sounds like a complete set of functionality what none a word was mentioned here about it ! 1

Configurable online registrations forms will be needed for events.
Requires more details 1

Online registration needs to be intergrated with online payment systems.
Requires more details 1

Event administrators will need lists and other tools for managing participants.
Requires more details 1

FR08 Blog


FR08_01 Any user may have a personal blog, but its audience depends on user permissions

1 Medium Low
FR08_02 User must be able to define visibility scope of each blog

1 Medium High 1

FR09 Book


FR09_01 Book pages may only be added and edited by users with appropriate permissions

FR10 Forum


FR10_01 Access to Forums must be able to be restricted by group membership Forums will not be shared across domains or groups

FR10_02 Any user who can access a Forum must be able to subscribe to receive notification of new postings to that Forum

FR11 Projects and Project Issues


FR11_01 Projects will be accessible to appropriate groups, including one 'IofC web project' for all users to submit bug reports, track issues, and suggest functionality. Projects and Project Issue will not be shared across domains or groups. The Project functionality will build on Drupal's Project module, with comment and notification services, etc., but the functionality provided must offer, in a simple format:
1 Low Low 1
FR11_02 A work management system must be provided enabling allocation of specific tasks to team members, and tracking of these tasks through stages.

1 Low Low 1
FR11_03 To-do/task lists must be provided for groups and individuals.

1 Low Low 1

FR12 Feedback


FR12_01 Any visitor or user can contribute feedback on what they experience while visiting any site Feedback will not be shared across domains or groups
1 Low Medium 1
FR12_02 The handling of Feedback will be managed through a workflow Complaints are a type of feedback and will have their own workflow
1 Low Medium 1

FR13 Product
What about product ?

FR14 Image Requirements relating to images is partly dependent on the image system we decide to implement, and therefore the following requirements may not all be met.

FR14_01 Images may be inserted into any other content.

1 High Medium 1
FR14_02 Users must be able to upload images to an image database via a web interface. The maximum image size allowed for upload by ordinary users will be 5MB. Administrators have no limitation. Uploaded images will be stored in three sizes: the size of the original
1 High High 1
FR14_03 Users must be able to upload images to an image database via an offline upload client. Images of only certain formats will be allowed to be uploaded.
2 Low High 1
FR14_04 Each uploaded image requires some data to be saved with it, including photographer name (for photos), a title and description, and the date of taking (if a photo).

1 High Medium 1
FR14_05 A captions system is required for images, allowing one image to have multiple captions in multiple languages.

1 Medium Medium 1
FR14_06 Images must be able to be organized into albums.

1 High High 1
FR14_07 Images must be categorized using keywords, organised into hierarchies.

1 High High 1
FR14_08 Users must be able to search for images by keyword, photographer, creation date, format, description/caption words, and other criteria.

1 High High 1

FR15 Comment (nb: not a node)


FR15_01 Each content type may be configured to allow comments to be added Comments will not be shared across domains or groups

FR16 Help


FR16_01 Help text and pages may be provided anywhere on the site. If help exists in a particular context it will appear in one of two ways. As a hyperlink from the word/phrase for which there is a help text. As a question mark in a consistent position which when clicked opens a box with the help text.
1 Low Low 1
FR16_02 Help content will be organized into a knowledgebase which resembles a book – a hierarchy of pages with sections and subsections.

1 Low Low 1
FR16_03 The help text administrators must be automatically notified of any site changes which may require a review of help texts.

1 Low Low 1
FR16_04 Users should be able to contribute to the help system.

1 Low Low 1

FR17 Menus


FR17_01 Each domain/website/group will have its own menu(s).

1 High Medium 1
FR17_02 Dynamic menu items must be allowed for. For example, a user may need to see a menu item 'My groups' which has sub items listing the names of Groups to which that user belongs, each menu item being a link to the homepage of the Group.
1 High Medium 1
FR17_03 Menus can only be administered by the webmaster role.

1 High Medium 1
FR17_04 Menus must be able to customised according to their position and environment. For example, some websites might have menus expanded, others not

1 High Medium 1
FR17_05 Theming of menus must allow for flyout menus.
Why flyout ? 1 Unknown Medium 1

FR18 Blocks


FR18_01 Blocks may only be administered by the webmaster role.

FR18_02 Blocks should be shareable across domains/sites




FR19_01 URLs should be stored in a table and be able to be inserted into content via appropriate syntax/statement.
I don't understand a reason for that. Drupal already has URLs in a simple forms

FR19_02 URLs may also be inserted into content by typing the full url.

FR19_03 Clean URLs' should be available for Pages and other content.

FR19_04 URL redirection is required, allowing aliasing of URLs.


FR20 File Management This package defines file uploads and storage.

FR20_01 Only certain file types will be allowed for upload.

FR20_02 All files must be scanned for viruses at the time of being uploaded. If a virus is found, the file must be rejected with a notification to the uploader and to an administrator.

FR20_03 Uploaded files must be able to be designated as 'Public' (accessible directly) or 'Private' (accessible only from the server).

FR20_04 Access to files must be able to be restricted by group membership.

FR20_05 Nodes and comments may have a files attached to them depending on the node type and preferences of the content owner and admins – but only the owner of a node may attach a file.

FR20_06 A proper document management system must be implemented to allow easy administration and presentation of uploaded files.
Define all requirements for “document management system” . What should it be able to perform ?

FR20_07 When a file is uploaded and attached to content that is related to a group, then an email notification will be sent to that group admin as well.


FR21 Search engine This package provides search functionality throughout the site.

FR21_01 For each domain/site, the search engine must search all (and only) content for which the visitor/user has access rights.

FR21_02 A search must look for the search term(s) within title, summary (teaser/intro), body, author name – and other fields to be determined.

FR21_03 Advanced searching is available only to authenticated users.

FR21_04 Search results must be presented in a format easily configurable by administrators, and sorted according to criteria to be determined.


FR22 Notification services This package defines the configuration of all notification services within the site.

FR22_01 It must be possible for email notification messages to be triggered by various actions on the sites.
Define these actions ?

FR22_02 Notification messages must be able to include a link to the page related to the notice.

FR22_03 Notification messages must be able to sent to more than one email address, for example to the author of a content item as well as an administrator.

FR22_04 Some content areas of the site should be able to offer visitors or users the option to subscribe to receive notification when new content is added.

FR22_05 Such notification messages should include a link to unsubscribe from future notifications – or another easy method of unsubscribing should be offered.

FR22_06 RSS feeds must be available and easily configurable for various sites and content types.


FR23 Email lists This package covers how email lists are provided and managed.

FR23_01 The solution should use a standard Mail List Manager for bounce processing, moderation, and other email list functionality.

FR23_02 The MLM must offer good multi-lingual functionality for template strings.

FR23_03 The solution must utilise the unique email addresses within the site-wide CRM system.

FR23_04 A subscriber to an email list must be able to unsubscribe from any email list easily. An unsubscription link should be included in each email sent to the list.

FR23_05 Email lists may be 'public' (open to subscription on public websites), 'restricted' (open to users but not visitors) or 'private' (available only to members of a group and/or via administrator subscription).

FR23_06 The existence of a list must only be visible to those with appropriate access permission.

FR23_07 A member of a restricted or private email list must be able to view the names of others subscribed to that list.

FR23_08 There must be an easy way for a user to review on one page those email lists available to him/her, and subscribe/unsubscribe as they wish.

FR23_09 When an email address is added to any email list by an administrator, an email message should be sent to that email address with a request for confirmation that the person wishes to subscribe to the list.

FR23_10 Email list membership and Group membership must be able to be synchronised. i.e. It must be possible for someone subscribing to an email list also to join the related Group, and vice versa.


FR24 Contact relationship management This package covers the management of contact relationship data in all its forms.

FR24_01 The solution must provide a flexible and secure method for storing and managing contact records. A contact record may relate to an organisation rather than an individual.

FR24_02 Contact records must be able to be linked to users records.

FR24_03 A user record must have a linked contact record, but a contact record need not have a linked user record.

FR24_04 The system must enable duplicate records to be easily found, and for safely deleting a duplicate.
maybe just avoid duplicate appearance ?

FR24_05 Most 'user' profile information should be stored with the contact record, so that data such as bio, photo, etc, can be used by the system even if the contact record has no linked user record.


FR24_07 Contact records must be able to be linked to one another (so that for example a married couple's records could be associated, and the employees of a company could be associated with that company, etc.)

FR24_08 It should be possible for linked contact records to share some address data. in CiviCRM there is the concept of 'household' which achieves this.

FR24_09 The visibility of contact record information must be limited to those who have permission to view/use it.

FR24_10 User contact information/profile will by default be visible to other users, but a user may control which parts of their information are hidden from other users.

FR24_11 Contact records not linked to a user will only be visible (via searching) to those users belonging to a group or role authorised to view the record.

FR24_12 Every contact record must be assigned to one, and only one, 'Data Controller', which will by default be the Data Controller role under which the user is creating the record.

FR24_13 When a new contact record is created by someone who is not acting in the role of a particular 'Data Controller', it will be assigned to a temporary 'Interim Data Controller' pending assignment to the appropriate Data Controller.

FR24_14 A contact record may only be edited by its assigned 'Data Controller' or by the linked user.

FR24_15 When a new contact record is created, an email should be generated to the email address of the record being added, detailing the data being added, and the purpose for which it is being added, and inviting confirmation of the accuracy of this action.

FR24_16 Admins and data-controllers must be able to filter records to extract a subset.

FR24_17 These subsets must be able to be displayed in various formats and printed to PDF.

FR24_18 Contact records must be able to be linked to nodes – initially to Articles (for authors, see FR06_03), and eventually probably to events (for event management) and other content types.

FR24_19 Records must be easily searchable.


FR25 Users This package covers functionality relating to the users of the system.

FR25_01 Users are required to undergo a registration process.

FR25_02 All users must agree to our terms and conditions.

FR25_03 Upon registering, a user by default becomes a Basic User, and therefore has the option to apply to become an Advanced User.

FR25_04 The submission of the registration form needs to use the Captcha or similar verification system.

FR25_05 The content of the registration form may vary depending on the context in which it is being submitted.

FR25_06 The registration form must allow entry of a special registration code which would authorise additional actions after submission, e.g. Immediate enrolling as an Advanced User.

FR25_07 The process of applying to become an Advanced User requires giving the name of a reference person. A notification system will be used.

FR25_08 Users who forget their login or password details must have an automated way of requesting a reminder, or password reset.

FR25_09 User activity must be logged and accessible to appropriate site administrators.

FR25_10 Users will be able to join groups within which they will be able to assume roles that give them permissions specific to that group (see FR02).

FR25_11 Users must be identified throughout the site by their full name, not by their user id.


FR26 Workflow This package describes the process of managing stages in the finalising of certain types of content.

FR26_01 A workflow is specific to a particular type of content.

FR26_02 Groups may have their own workflows for the same content types.

FR26_03 Dependent on the configuration of the workflow, users will be given a choice to advance a content item to the next stage of its completion whilst the item is either being created or edited.

FR26_04 Email notifications are used to inform appropriate users of a content items transition to a new stage.


FR27 E-commerce This package provides e-commerce to the system.

FR27_01 An online payments system must be provided to allow any visitor/user to purchase products or make donations.
The details of the online purchasing system will conform to the typical e-commerce requirements of small organisations – with final details yet to be defined.

FR27_02 The page/s where credit card information is entered must be secure.

FR27_03 The 'product' content type defines what will be available for sale.

FR27_04 A product must be able to be linked to another node. For example an event might have tickets for sale as products.

FR27_06 There must be a method for purchasers of digital products to download them after payment.

FR27_07 Any group must be able to offer products for sale or to invite donations.
How to invite donations?

FR27_08 An administrative interface must be provided for managing donor relationships effectively.
What does it mean “effectively” ?


Contact Relationship Management

FR001 Package Name Contact Relationship Management  
Details This package covers the management of contact relationship data in all its forms.  
Status Phase Version  
Proposed 1 1  
FR001_01 To support the high-level objectives of IofC’s global communications strategy: to embed the critical elements of personal transformation, forgiveness and remade relationships into the accepted thinking of policy-makers, academics and practitioners of peace-building and development; to equip, support and strengthen the network of regional and initiative-based IofC communities… giving cohesion to this movement for regional and global transformation.
FR001_02 To project a professional, consistent image of IofC into the public arena.
FR001_03 To support the personal relationship-building work of IofC activists with people in international organisations and peace-building institutions.
FR001_04 To support the development of the global network of IofC and help build a spirit of community.
FR001_05 To provide a method for offering a public web presence, and an intranet, for multiple IofC national bodies and projects.
FR001_06 To serve the global data management and marketing needs of IofC.
FR001_07 To maximise the sharing of informational resources across the global IofC network.
FR001_08 To provide a solid, easily managed, infrastructure to serve the web needs of IofC for at least the next 5-10 years.

NF - Non-Functional Requirements

Non-functional requirements can be broken down in to the following 2nd level packages:
  1. Business requirements These requirements describe needs of the IofC organization which are not directly linked to any particular functions of the solution but describe a business objective which must be achieved as a result of the system being developed.

  2. User Interface Requirements User interface requirements described how we would the solution to interact with the users of the system.

  3. Hardware Requirements Hardware requirements describe the hardware which will be available to be utilised by the application in order to achieve the solution objectives. This type of requirements is very closely related to the performance requirements.

  4. Software Requirements Software Requirements describe the various software needs of the solution such as operating system, browsers to be used, protocols, third parts software etc…

  5. Performance Requirements Performance requirements describe the expectations that the customer has in terms of how the solution will perform under specified conditions.

  6. Security requirements Security Requirements defines system access levels and data protection requirements. Desired security expectations should be described at both hardware (net topology, firewalls etc.) and software (checks, constraints, validations etc) levels.

BR-Business requirements


Package Name

Overall business requirements


This package contains business requirements, answering the question 'Why does this project exist?'








To support the high-level objectives of IofC’s global communications strategy:

  1. to embed the critical elements of personal transformation, forgiveness and remade relationships into the accepted thinking of policy-makers, academics and practitioners of peace-building and development;
  2. to equip, support and strengthen the network of regional and initiative-based IofC communities… giving cohesion to this movement for regional and global transformation.


To project a professional, consistent image of IofC into the public arena.


To support the personal relationship-building work of IofC activists with people in international organisations and peace-building institutions.


To support the development of the global network of IofC and help build a spirit of community.


To provide a method for offering a public web presence, and an intranet, for multiple IofC national bodies and projects.


To serve the global data management and marketing needs of IofC.


To maximise the sharing of informational resources across the global IofC network.


To provide a solid, easily managed, infrastructure to serve the web needs of IofC for at least the next 5-10 years. The decision to move into Drupal was taken because we considered the sustainability of our web projects to be more assured by building on an Open Source platform supported by a worldwide community of developers, with agreed coding standards, better security features, and with out-of-the-box functionality which would take much programming work to provide. The Drupal framework is also likely to move with the leading edge of web development in the years ahead.

HR–Hardware Requirements

Number HR1_001 Status
Title Server specifications Priority Hgh

The solution must use our present web server ('Atlas') -


  • CPU: 2 (shared) cores (3.2GHz Xeon)
  • Memory: 1GB
  • Disk: 20GB
  • Bandwidth: a 10 Mbit/s uplink, up to about 1Mbit/s sustained traffic


Difficulty Low
Version 1.0
Phase 1.0

Number HR1_002 Status
Title Upgrading options
Priority Unknown
Details The server specifications in regard to memory, disk capacity and bandwidth will be upgraded once the volume of traffic warrants it. Difficulty Unknown
Version 1.0
Phase 1.0

PR-Performance Requirements

Number PR1_001 Status Approved
Title Number of visitors Priority Hgh
Details We anticipate that the total daily number of visitors to the IofC sites will not exceed 25,000 in the forseeable future. Difficulty Low
Version 1.0
Phase 1.0

Number PR1_002 Status Unknown
Title Logged in users Priority Unknown
Details We anticipate that the total number of authenticated users will not exceed 10,000 in the forseeable future. Concurrent logged in users will not exceed 500. Difficulty Unknown
Version 1.0
Phase 1.0

Number PR1_003 Status Unknown
Title Server response times Priority Unknown
Details The typical response time for a browser request should not exceed 5 seconds. Difficulty Unknown
Version 1.0
Phase 1.0

Number PR1_004 Status Unknown
Title Bandwidth Priority Unknown
Details The applications should be designed with web users in Africa and Asia in mind, so graphics should be kept to a minimum. Difficulty Unknown
Version 1.0
Phase 1.0

Number PR1_005 Status Unknown
Title Availability of sites Priority Unknown
Details All sites, including log in sites, should be available 24/7. Difficulty Unknown
Version 1.0
Phase 1.0

SR-Software requirements

The solutions we develop often interact with one or more software elements on the client’s environment. Often these interactions constrain the way in which we can develop the solution or at least will guide the designers in design the best solution according to the scope of interaction with other software.

Number SR1_001 Status
Title Solution core - Drupal CMS Priority Hgh
Details Overall solution must be based on “Drupal” Content Management System.

Version 6.0 of Drupal CMS must be used.

Difficulty Low
Version 1.0
Phase 1.0

Number SR1_002 Status
Title Server environment
Priority Unknown
Details Solution must run on IofC web server 'Atlas'.
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_003 Status
Title Browsers to be supported
Priority Unknown
Details Application must be compatible with different browsers (IE 6 >, Firefox 2.0 >, Safari). Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_004 Status
Title Programming language
Priority Unknown
Details Application should use the PHP programming language (Drupal default)
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_005 Status
Title Database software
Priority Unknown
Details Application should use MySQL databases (Drupal default) - IofC webserver allows as many as we need. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_006 Status
Title Coding standards Priority Unknown
Details Solution should use Drupal's coding standards.
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_007 Status
Title Post deployment support
Priority Unknown
Details The solution will be supported by IofC's web team after deployment. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_008 Status
Title Data exporting
Priority Unknown
Details Solution must support CSV exporting, and output of PDFs on the fly. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_009 Status
Title Audio and video codecs
Priority Unknown

Audio and video codecs must not be encumbered by patents, and must not have DRM in them. Ogg/Vorbis and Ogg/Theora are prefered choices, with plugins and/or viewers available for many platforms.

Difficulty Unknown
Version 1.0
Phase 1.0

UR–User Interface Requirements

Number UR1_001 Status Approved
Title Required interface Priority Hgh
Details End user requires only a web-based interface. Difficulty Low
Version 1.0
Phase 1.0

Number UR1_002 Status Unknown
Title Branding and colour Priority Unknown
Details The branding and colour schemes should be the same as those currently deployed at Difficulty Unknown
Version 1.0
Phase 1.0

Number UR1_003 Status Unknown
Title Plug ins Priority Unknown
Details Media which require additional browser plug ins, such as Flash animations, should generally not be used. Difficulty Unknown
Version 1.0
Phase 1.0

Number UR1_004 Status Unknown
Title Monitor resolutions Priority Unknown
Details The solution should cater for 800 x 600 and higher resolution. Difficulty Unknown
Version 1.0
Phase 1.0

Number UR1_005 Status Unknown
Title Web page widths Priority Unknown

Public websites should be fixed width (770). Log in websites should be fluid width. The user should not be required to use horizontal scrolling bars for primary content.

Difficulty Unknown
Version 1.0
Phase 1.0

Number UR1_006 Status Unknown
Title Accessibility standards Priority Unknown
Details Web pages should meet the checkpoints of the Web Accessibility Initiative's Web Content Accessibility Guidelines to Level-A standards as well as Levels AA and AAA where possible. Difficulty Unknown
Version 1.0
Phase 1.0

Number UR1_007 Status Unknown
Title Multilingual requirements Priority Unknown
Details Both interface and content must be fully multilingual, including support for RTL scripts. Difficulty Unknown
Version 1.0
Phase 1.0

XR-Security Requirements

Number XR1_001 Status Approved
Title Type of solution Priority Hgh
Details It will be both an Internet application which provides public information, and an Intranet Web application. Difficulty Low
Version 1.0
Phase 1.0

Number XR1_002 Status Unknown
Title Level of data sensitivity Priority Unknown
Details Secret or highly sensitive material will not be stored on the websites, but security of user contact information needs to be ensured, to conform with data protection legislation. Difficulty Unknown
Version 1.0
Phase 1.0

Number XR1_003 Status Unknown
Title Authentication methods Priority Unknown
Details To be determined Difficulty Unknown
Version 1.0
Phase 1.0

Number XR1_004 Status Unknown
Title Password levels and logins Priority Unknown
Details A medium-level of password strength should be enforced. After 5 incorrect login attempts a user should be blocked and the administrator informed by email. All login attempts, whether successful or unsucessful should be logged. Difficulty Unknown
Version 1.0
Phase 1.0

Number XR1_005 Status Unknown
Title Session method and options Priority Unknown
Details To be determined Difficulty Unknown
Version 1.0
Phase 1.0

Number XR1_006 Status Unknown
Title SSL Priority Unknown
Details SSL should be used for all financial transactions. (This is already in place on our server.) Difficulty Unknown
Version 1.0
Phase 1.0

Evaluating Modules

This section is devoted to evaluating and cross-referencing modules which could be useful for us.

A spreadsheet of Drupal 6 modules we need, with their status, is at

Advanced contact

This simple module adds functionality to the core module Contact. Its main function is to allow the passing of parameters in the url to specify the category and/or subject of the email transmitted by the default contact form. This is useful if you have several categories and want to save the visitor having to choose the right one from the drop down list.

After installing the module, there is no configuration to do, and the module does not appear in the Admin section.

I found little documentation of how to use it, but something brief at

Example of usage might be;


This module makes it possible for a node being created/edited to be autosaved every x seconds. This would be very useful for users who might lose work if their computer crashes or some other unexpected happening occurs.

A JQuery plug in has to be downloaded, renamed (.txt removed), and placed in the module folder. To configure after installation, go to Content Types and choose the Autosave tab, and choose which types to apply it to, and how many milliseconds (1000 milliseconds in a second!) between autosaves. 

Content Access and ACL

The Content Access module ( enables you to limit view/edit/delete permissions by content type, and also by individual nodes.

If the ACL module ( is also enabled, you can limit view/edit/delete to particular users.


This module ( provides a block with links to increase and decrease the font size using JavaScript and CSS. See an example at


This handy module allows anyone with requisite permission to 'masquerade' as another user. This is really useful for Admins who need to troubleshoot problems reported by a user, and need to simulate the user's environment.

It is easy to configure. On the configuration page you can optionally specify a specific user to whom to switch easily via a Menu item 'Switch to test user', which would then need to be placed in the Admin menu. This could be useful if you have a bogus user configured with certain permissions, and you want to see what this role actually sees.

Once configured, Admin can go to a user's profile and click on the Masquerade link to switch to that user. Once masquerading, there is a link to switch back to the original user. But beware, you have set up this menu link BEFORE you masquerade! You will find it in the Menu but need to place it correctly.

Note also that while masquerading, any content you add will be shown as having been added by that user.

Watchdog logs all switches.


General Info:

The module page is here:
The author's blog is here:

The author alluded to future OGDomains and UserDomains modules (which would be useful to this project). But the statement was made in December 2006 and the modules are not yet implemented.

I will not yet pronounce at this stage about whether it is good or not for us.


- I am running Debian Linux.
- Made a clean install of Drupal.
- Enabled clean URLs, made my status report to give me no warnings.
- Enabled more themes.
- Configured the Apache Server to point drupal.test and one.drupal.test to the same Drupal installation directory.
- Installed the module.
- The module requires single signon module. It can be found here: So I installed this too.
- The module needs to apply a patch. The patch is provided. To apply the patch I opened a terminal window, browsed to the Drupal directory and executed patch -p0 < modules/multidomain/multidomain_alias.patch

Administer->Site Configuration->Multiple Domains

- Set the default domain to drupal.test.
- In the 'Content filtering by domain' setting chose 'All: all domains, including the default see their own content'.
- Added one.drupal.test domain.
- This module created a Vocabulary called domain. The domains I added where added to the vocabulary.
- Set the Domain Vocabulary to allow multiple selects.
- When creating the two domains, I've indicated that the Domain Vocabulary can apply to both of my only content types: page and story.
- Set marvin (different from default garland) theme for one.drupal.test domain.


- Added three stories: one assigned to both domains, and each of the other two assigned to one different domain. Both sites displayed the right set of stories.

Node Clone

This module allows you to clone a node and then edit it. After installation, you can configure permissions, and then when editing a node there is a Clone tab.

It seems to work well for basic content types, but the documentation at warns that it may cause problems with complicated types using a lot of CCK fields.

Profile/contact record module solutions

Getting one's head around a solution for our CRM requirements has not been easy. We have investigated the Nodeprofile family, but documentation is sparse, and it takes some understanding.

In brief: the Bio module is too limited, so we need Node Profile. The way it works is that the Usernode module has the effect of binding user data (which is not a node) to the node system by creating a node of content type 'usernode'. This is an empty node which does nothing much by itself, but allows you to attach nodes of other content types to a user. It also ensures that if a user is deleted, all nodes bound to the usernode are deleted.

  • Nodeprofile (with Nodefamily) allow us to create additional content types and link them to the usernode in a parent/child relationship.
  • One or more profile nodes can be put on the registration form.
  • It is possible to allow users to make certain fields private via the Node Privacy module.
  • CCK fields on the profile forms can be restricted via the CCK Field Permissions module.

We have to accept that all our contact records will have to have linked users, even if they are inactive/blocked. It would be very messy if we had separate content types for contact records which are not linked to users, as we could not merge the two contact record types in views, etc, and also it would be complex when a non-user contact becomes a user.

Some other points:

  • For an administrator to create a new contact record, he has to use the create user form. This allows the creation of new profile etc, which is not allowed if you try to create content of the profile type.
  • Through Usernode, if we delete a user, all the linked profile nodes are also deleted. But if we delete part of the profile (data of one content type) only that node is deleted.
  • Automatic Node Titles is good for hiding the title of a content type and automatically naming it based on tokens.
  • Pageroute allows us to set up good step-throughs of profile forms, and of linked admin nodes. So, for example, each ‘data user’ group will have its own content type (e.g. UK data user) and CAN (does not have to) have a node with data storing to a contact’s relationship to that data user (e.g. whether he receives a newsletter, or whatever) – and a custom pageroute can be provided for the datauser to go from the profile to an admin page.
  • Views Fusion is very good for building combined views.
  • Login Toboggan module is good for directing a registering user to a thank you page after registering.
Please add to this page any points you have!


This module enables users to subscribe to be notified of changes to nodes or taxonomies, such as new comments in specific forums, or additions to some category of blog. Once enabled, all nodes will have an additional link that allows the user to change their subscriptions. Users have tab on their user screen to manage their own subscriptions. Users can also set an auto subscribe function which notifies the user if anyone comments on posts they have made. Admins can set this on by default.

This module offers what we have at present allowing users to subscribe when new message in a forum, but with more control/management features, and with any content able to be subscribed to.

Tasklist and Tasklist Advanced

These two modules taken together provide powerful tools for managing tasks. They may meet and exceed our requirements in relation to the replacment of our old Work Management System (WMS). (Though one or two features of our system are missing, like the statuses 'Back to Work', or 'Test'.

Tasklist ( gives simple functionality: You can assign a task to a user, filter by complete/incomplete, colour code tasks for users, etc.

The Tasklist Advanced module ( extends the existing Tasklist module, and adds categorization, additional views, and filtering based on "Getting Things Done" by David Allen. For attaching dates to tasks, use the Event module.


(In addition to all of Tasklist's features)

  • Additional views
    • my tasks
    • all tasks, grouped by user
  • Categorization based on "Getting Things Done" by David Allen
  • Form or URL based filtering by
    Note: for advanced URL based filtering try this approach: tasks/user/1?status=1&taskcategory=unknown,next&tasktype=action
  • Status
  • Category
  • Task type
  • Tagging of tasks as action (default) or project (multi-action task)
  • Hierarchical tree listing

specify a task as a Project or an Action, and you can date it if you add in the Date module.


There is a module called Todolist which is development which might be worth exploring too. 

Taxonomy Node Operations

This module dds the ability to assign terms to nodes in the node operations dropdown in Content Management >> Content. It makes it easy to assign a taxonomy term to a number of nodes at the same time. There is no help file available, and the module once installed does not show up in the Administer by Module list, but if you go to the Node admin page, the 'Update Options' drop down includes options for assigning to terms. 


Install the main Drupal module first, then the separate TinyMCE files into new tinymce subdirectory.

For a detailed explanation of how to configure it all, see

Be aware that if you are deploying this module on a multilingual website, you may need to change the Visibility settings. Typically you choose the option to show tinymce "on only the listed pages:" "/node/* /user/* /comment/*". However, now there might be an /en/ or /fr./ in front of the /node/, because of the internationalisation, these settings would need to read "*node/* *user/* *comment/*" instead. 

Web File Manager

This file manager is based on a heirarchical directory structure unlike the traditional flat filesystem used to date. WebFM uses AJAX to allow administrators to arrange files on the server in the same way they do with file managers on their personal systems. This ability to hierarchically arrange files improves the manageability of large collections of documents.

A demo is available at

Download the module at 

Use Case List

We created a great list of use cases.

Guidelines for writing Use Cases

Use cases give us a structured way of capturing the behavioral requirements of a system, so that we can reasonably create a design from them. They help us to answer some fundamental questions:
What are the users of the system trying to do? What’s the user experience? A surprising amount of what your software does is dictated by the way in which users must interact with it.

Why Do We Need Use Cases in Addition to Functional Requirements?
Functional specifications are important, of course. But designing, coding, or estimating directly from a functional spec is like playing an enthralling game of “pick a random number.”
We need to do some exploratory work to even out the playing field. Use case modeling and preliminary design after it, gets us there.

The principles of writing use cases can be summed up as a list of guidelines.
1. Follow the two-paragraph rule.
2. Organize your use cases with actors and use case diagrams.
3. Write your use cases in active voice.
4. Write your use case using an event/response flow, describing both sides of the user/system dialogue.
5. Use GUI prototypes and screen mock-ups.
6. Remember that your use case is really a runtime behavior specification.
7. Write the use case in the context of the object model.
8. Write your use cases using a noun-verb-noun sentence structure.
9. Reference domain classes by name.
10. Reference boundary classes (e.g., screens) by name
A use case is often triggered by a user-initiated event that the system has to respond to. However, it can also be triggered by a system-initiated event to which the user responds. But in
either case, the use case follows the event/response flow.
So a use case really describes a dialogue between a user and the system. You need to write about the user side of the dialogue to keep your behavior requirements firmly user-focused, but it’s not sufficient to just write down what the user does, because ultimately you’re trying to spec software, and software really consists of the system’s behavior. So it’s vitally important to describe both sides of the dialogue between the user and the system in every use case.
Quite often, the user is reacting to a system action, so the use case starts with “The system displays the XYZ screen (showing ZZZ information),” and then the user does something in response. The main benefit of starting your use case with "The system displays..." is that the system showing something on the screen involves initialization behavior (getting ZZZ information from somewhere) that is often forgotten otherwise.

First a bad one use case; The capability is provided for users to log in, using a password-protected authorization

Here goes a simple, good one example.

The system displays the Login screen. The user enters her username and password, and
then clicks the Login button. The system looks up the user profile using the username
and checks the password. The system then logs in the user.

Remember this is the basic course—the sunny-day scenario that assumes everything goes correctly. There would also be an alternate course describing what happens if the username or password weren’t found.

Or another one ..

The user clicks the Edit Shopping Cart button, and the system shows the Edit Shopping
Cart page with a list of books in the user’s shopping cart. The user selects one of the
books, changes the quantity, and clicks the Update button. The system shows the page
with the quantities and price totals updated.

Site Structures

General Use Cases for our site structure.

Definition of our multisite requirements


  • A substantial number (40+) of websites, each of which MAY have either or both
    • A ‘public’ site for ‘anonymous’ users
    • A ‘private’ site for ‘authenticated’ users
  • Each website needs to have its own domain or subdomain.
  • Each website to be, optionally, multilingual. This includes all image captions as well.
  • Each website to have its own administration, including control over theme, user roles, menus and other module configurations.
  • Main content (nodes, images, user data, possibly also blocks) can be made available or shared (where the creator permits) to all sites but with each site retaining complete control at the individual site level over what appears on each.
  • Universal ‘authenticated’ users able to log into all websites, and once logged in to move freely between sites without new login request.
  • User data (contact info, biodata, etc) integrated fully, but with full security.
  • Within any given website, a group system allowing establishment of multiple groups with own group content and networking tools and controlled content sharing between groups.

[The following was added to this document by Edward on 14/11/2007, after agreement with team members, for transmission to stakeholders for comment.]

Proposals for the new 'architecture':

  • The IofC family of websites will consist of multiple public sites EACH of which CAN have additional private section(s) for the needs of activists from that particular network. For example, the UK public site might have a UK extranet with additional content restricted to the logged-in person. The F4F public site might have an F4F extranet... etc.
  • Each extranet would in effect be a different site with a different look and feel, but the content in it would INCLUDE all content on the related public site.
  • What we currently call the 'Extranet' will become the private extension of the Global website, and called the 'Global Extranet'.
  • Those IofC teams which do not need/want a public website, can have a team/group section inside an extranet - either the global one, or another, as appropriate. If in due course such a team wants to have a public site, it can move out of its parent extranet.
  • A 'Global Extranet member' will have access to ALL extranets without separate registration/log in.
  • Content on any extranet can (as at present) be restricted to only certain members.
  • Webmastering of a site will be more intuitive than in our present system.
  • The webmaster will log in to their site and be able to edit any page by navigating to the desired page, make changes, and review those changes before making them live.
  • Much content will be shareable across sites, but not in the way we have at present through shared 'fixed blocks'. 'Dynamic' content such as articles, documents, etc, will be sharable across sites.

Research on Multiple sites in Drupal -- remaining questions.

Dear Pavel,

Located one level up in this online book is a definition of our site requirements regarding multiple site functionality. By 'multisite functionality' I specifically mean having different domains and subdomains; the infrastructure to acheive that is an entirely separate matter.

The purpose of this memo is give you some background on the research that's been done to discern how closely Drupal comes to what we need. This research is incomplete and is intended to give you a solid footing as you begin to look at this more complex use case.


There are 3 pathways forward which we have been researching.

These have been narrowed down to the latter two options, given that the Multisite Manager module can not acheive our use case on its own. It is possible that Multisite Manager and OG_sites can be made to work together I suppose, but I see no immediate advantage to doing that.

You may be entirely familiar with these, but here they are again. The modules we are talking about are found below:

User Group Structures

We have groups.

Data Display and Theming

We display stuff.

Files and Attachments

We attach things to things.

User Roles and Permissions

Users need roles and permissions.

Content Creation and Sharing

We create things and share them between groups and sites.

Domain modelling

Here we gather documentation relating to our domain model.

A document describing our domain model using the metaphor of an indoor shopping centre is attached to this node

Definition of terms

DOMAIN MODEL: Definition of terms

Note: the terms defined in this document are not necessarily the terms which will be used to present the concepts to the ‘consumers’ – they are for the benefit of the technical team.

Principal domain objects and their definition

a combination of the public website (all content visible to any visitor) and a private area with additional content and functionality accessible only to logged in users.

the totality of all domains in the IofC family of domains.
Global website the public website of IofC International (

the private area of, accessible to all IofC users.

Hub domain
the global website and extranet, which forms the hub of a family of related websites.

Related domain
A sub-domain of serving an IofC national body, outreach programme or other related entity, which has a public website and a private area (site intranet), and which can share content with other IofC sites.

Site intranet
the private area of a related domain, accessible to all IofC users.

A collection of users within a domain who collaborate towards a particular objective, and which can have its own site area (group intranet), private content, email lists, forums, etc.

Group intranet
an area or group space within the extranet or a site intranet which serves the needs of the group. (Note: this group intranet may be completely private to the group, or parts of it may be accessible to non group members. Clarification: if a group with a group intranet develops a need for its own public website, a new related domain is created and the group moves with its content to this new domain, becoming the principle group of that domain.)

a piece of content which becomes accessible depending on the domain and role(s) to which it is assigned. (Important clarification: contact records are both users AND resources in the sense that contact data may be administered/used/viewed by users with permission to do so.)


General user objects

Public visitor
someone who visits a public website without logging in ('anonymous user' in Drupal terminology, but NOT a user in our terminology – see next item)

Basic user
someone who has logged in to any domain with whatever level of privilege (Drupal's  ‘authenticated user’ role). The two membership types that follow both have this role and add additional permissions.

Site member
a user who has limited access to the extranet or a site intranet. (Note: a site member is given membership without moderation)

Network Member
a user who has full access to all content which is not private to a group. (Note: this role requires moderation) Only full users would be able to join and administer groups. A full user is allowed to create new content of particular content types, e.g. ‘News’.


Domain roles

(Note: for each role below there will also be a ‘chief’ administrator with all-domain responsibility, supporting each domain-specific administrator.)

a user who has primary responsibility for public and restricted resources on a site. This role requires domain-specific permissions for:

  • site building: domain blocks, menus, themes, url aliases, views
  • content management, including administering nodes

a user with administration privileges. This role requires domain-specific permissions for:

  • site building: modules
  • user management
  • site configuration
  • logs

Super Administrator
a user who has access to everything and can administer everything

Groups administrator
a user who administers the formation and support of groups (limited to administering the ‘groups’ content type and the configuration of groups)

Email administrator
a user who administers email lists

Events administrator
a user who administers events (limited to administering the ‘events’ content type and the configuration of some views)

Forums administrator
a user who administers forums (limited to administering the ‘forums’ content type and the configuration of forums)

Translations administrator
a user who administers translations


Primary group administration roles

Group member
a user who is a member of a group

Group administrator
a user who administers all aspects of a group, including membership

Group webmaster
a user who administers the pages/content of the group’s intranet


Roles in special contact data administration groups

Group data controller
a user with full administration rights for those contact records belonging to the group. (Note: every contact record will be belong to one and only one group for the purposes of exercising ‘data protection’ responsibilities in relation to that data subject.)

Group data user
a user with permission to use for mailing purposes (but not change) those contact records for which the group has ‘use’ permission.


Resource access terms

visible to visitors

visible to users only. (Note: restricted will be further sub-defined to restricted basic and restricted full for the two general user roles of our universe.)

visible to members of a group. (Clarification: if a resource is publicthere would no point in also classifying it as restricted. But there will be times when a piece of content is public or restricted but is also classified as private. The effect of this would be for this content to be visible to non group members, but it would place the content additionally inside a group intranet.)


Other terms

those persons (whether visitors to a public website, a general user role, or a defined group of users) which may view content.

Contact record
a set of data relating to a person or organisation (data subject), including contact information like name, address, etc, and also including user data such as username and password. (Note: all contact records will have user data even if the person is not an active user of the system.)

Group data viewer a user with permission to view contact records for which the group has ‘view’ permission. (Clarification: any group member will be able to view contact data relating to other group members. But a group member may not necessarily have ‘view’ permission for all contact data which belongs to the group or for which the group has use permission.)

Image database
a repository of images, with each image storing data relating to it (including captions, sometimes in multiple languages), and categorised with keywords.

a defined set of stages through which a type of content flows until it is completed

The Plan

This section details the overall plan for the entire project. It breaks down into sections for each stage of the plan, and these naturally have their own steps which should be followed in a well thought out logic order. These sections are as follows: