Preparing the Product Selection: Requirement Specification for a Content Management System
 |  | http://www.contentmanager.net/magazine/article_1283_requirement_specification_cms.html |
Purchasing a content management system (CMS) to setup and maintain a website involves making a far-reaching decision. Only choosing an applicable as well as future-proof content management solution can ensure the problem-free functioning and expansion of online projects. Otherwise, the decision for an unsuitable, inflexible solution may very soon cause additional costs.
In order to avoid these kind of problems it is recommended to develop a detailed requirement specification which, consequently, serves as a basis for the product selection and the purchase. During its conception general conditions concerning the content and the technology should be defined and put down. Such a document not only helps to choose the right content management solution but also serves the CMS vendors as a basis to prepare firm offers and may, thus, become integral part of the future contract.
Form and Structure
Two factors are particularly important to the structure of a requirement specification: precision and comparability are crucial to its future usefulness. Only if the questions and requirements are exactly defined in order to produce definite answers the offers of the different vendors become comparable.
Thus, a table structure as follows is suitable to use: description of requirement, kind of requirement (essential, desired, additional criteria) and a checkbox for the CMS vendor (requirement is fulfilled / not fulfilled). Moreover, an additional column should be left allowing the vendor to add comments.
Often the desired functions are simply listed among each other without any structure. At this, there is a permanent switching between Yes/No criteria (Does the CMS support MySQL 4.2.1?), requirements (The CMS must support MySQL 4.2.1.) and questions (Which database systems are supported?) which complicates the future comparability and evaluation of the corresponding answers.
Eventually, attention is to be paid to a precise and commonly used terminology: special terms bound to an organisation or company (e.g. user role) might be understood differently by the CMS vendor. Therefore, it is reasonable to explain ambiguous terms in an attached glossary.
After having defined the form and the structure of the requirement specification it is to be subdivided accordingly. At this, the following paragraphs and categories should not be missing. However, the extent and the number of the listed criteria depends on the application area of the content management system as well as on the technical preconditions. A CMS to manage a microsite does not need to be specified as precisely as an enterprise content management solution to be introduced within a whole company or a group of companies.
General Conditions
By defining general conditions the CMS provider should gain insight to the customer's development status, the structural circumstances (e.g. combination of project partners) as well as to the editorial and the work structure.
The introduction should include a general specification of the Internet or Intranet project, a description of the status quo as well as a specification of the concrete aims. Moreover, it is reasonable at this point to name the number and types of projects to manage, the number of editors as well as a rough quantity structure (number of pages and documents, user traffic, page impressions). Consequently, from this paragraph should already result whether the purchase of a CMS licence or an ASP model (for rent) is to prefer.
Additionally, the different criteria (essential, desired, additional) and the evaluation scheme (how to weight the different criteria) can be explained in the introduction.
Technical Conditions
Defining the technical conditions, as many requirements as possible should be specified in order to ensure the seamless integration of the content management system into the existing IT environment. Next to the server operating system, the favoured database system and the usable script languages, this paragraph should describe the existing IT systems and its interfaces. Moreover, the existing hardware resources can be specified and, accordingly, the inquiry of the corresponding requirements. Eventually, the available CMS interfaces are to be explicitly defined by the vendor.
Additionally, the client should provide information about the in-house hardware and software structure (e.g. number workstations in the editorial) as well as possible constraints. Many content management systems, for example, fail to manage a structure based on Linux or MacOS. Likewise, the possibility of installing plugins and the constraints of the browser versions in use should be specified (Internet Explorer, Mozilla).
The most important technical conditions should be defined as “must have” criteria (essential) because, on the one hand side, it is of little value to the CMS provider to complete the criteria catalogue if these criteria cannot be fulfilled and, on the other hand, it eases the subsequent selection procedure.
Usability of the CMS
Normally, the usability of a content management software is subject to a rather subjective evaluation. Experienced users may easily become acquainted with the operation of new software systems. Untrained editors, however, face difficulties with complex user interfaces and should, therefore, be included into the selection process.
In this section facts relevant to the user should be requested. These are, for example, the availability of an online help, the display of error messages, the available system languages or the possibilities to configurate and customise the user interface.
Moreover, it is recommended to request screenshots of the most relevant functions (e. g. generating content, creating a navigation tree, upload of images). These screenshots may be part of an attachment to the requirement specification.
Functionality of the CMS
Concerning the range of functions of the content management system it is expedient to draw up a cost-benefit equation also taking the future challenges into consideration. Also, on the market for content management systems the “all-in-one device suitable for every purpose“ is still an utopia. Every content management system has its strengths and weaknesses and, of course, its price. Moreover, many functions are advertising gimmicks which are either properly functional only in a well prepared presentation or altogether unsuitable for everyday use.
Therefore, the list of desired functions should be realistic and always consider the project budget. Important functions like the separation of layout and content, the possibility to generate content with a so called “WYSIWYG editor” (what you see is what you get) or to include multimedia contents in the CMS are offered by any content management solution.
Further functions to ease the editors’ work should be specifically selected and not arbitrarily ordered following the motto “the system should do anything”. Furthermore, the client ought to take into account that the corresponding functions are configurable and offer a rights management to make them available only for certain users. A user interface overloaded with functions hardly ever used may overstrain the editor and result in operating errors.
Concerning the functionality it is also necessary to clearly differentiate between front end and back end functions. Indeed, requirements like web accessibility, discussion forum or site recommendation may be supported by the content management system but are only realised in the template, the front end of the web site.
Template Requirements
Thus, for the selection of the content management system it is recommended to also take the intended functionalities of the Internet and Intranet pages into account. If a web site is to be configured web-accessible the CMS must be able to produce a valid HTML code. This function is a clearly definable criterion whereas the general requirement “web accessibility” constitutes a complex aspect of the conception and the development of Internet sites.
Even more important are flexible script and template languages, documented APIs and a wide network of integration partners to actively assist the template development.
Also, the range of topics of the search function mainly concerns the front end (template). Here, the functions the content management system should offer by default and the types of documents to index are to be defined.
Documentation and Support
Finally, special emphasis should be put on the issues documentation, training, support and software service. These aspects indicate whether the content management system is professionally developed. Also, a development roadmap can be requested which, with commercial CMS vendors, should be extensive and reveal a view over the six months into the future.
Concerning the aspects support and software service, concrete information about time and effort should be requested by the CMS vendor. The corresponding costs are normally based on a certain percentage of the licence fees and are levied annually. Also, the reaction time can be defined or even determined as a must-have criterion for critical Intranet or Internet projects.
Requirements for Complex Projects
With an increasing complexity of the planned Intranet or Internet project additional functions of the content management system are inevitably required and need to be defined. These functions include tools of workflow management which allow to define and process workflows in the CMS. Also, the issues archiving, revision control and logging are essential for extensive projects. Here, security requirements, for example a revision-secure data storage, should be specified and put down.
Finally, the aspects of user and rights management should be taken into consideration. What types of users and user roles are required? What are the classical authorisation processes like?
Answers to these and similar questions have to be found internally and, consequently, may be introduced to the requirement specification as must-have criteria. Additionally, it should be defined whether existing user directories (LDAP server, Active Directory) are to be integrated into the content management system.
The Need of Cooperation
The preparation of a detailed requirement specification should be supported by employees from the different departments. Next to definite technical parameters the buying department (licence conditions, software service), the editorial staff, the users as well as the marketing department (functionality of the front end) are to get involved. Often, it is even advisable to enlist the assistance of a vendor-neutral consultant or an experienced project manager.
A mistaken investment in a content management system does not only affect the licence costs but may also require a repeated implementation of the entire project as well as a high migration effort.
Published: 01/2007
Author: Matthias Steinforth
| | Matthias Steinforth is managing director of the kernpunkt GmbH and responsible for sales and marketing. Among the clients of the kernpunkt GmbH are well-known companies and public institutions like Bayer, the Police Department NRW or Vaillant.
|
