Guide to

CMS Requirements
Specification



Choose the right CMS







M.Sc. Thesis by
J an Keller Pedersen & Miriam Tang

[email protected] [email protected]
http://www.cusix.dk/cmsguide



August 2007, IT University of Copenhagen

1
Table of Contents
1 How to assess and select a CMS................... 2
1.1 Why a CMS............................................................ 2
1.2 Basis of the report...................................................4
1.3 How to use this document...................................... 4
1.4 Send requirements specification.............................4
1.5 !a"uate rep"ies...................................................... 5
2 Manual for CMS requirements template.... 6
A Guidance to the supplier............................... 6
B High leel demands......................................1!
C "or# areas and tas#s..................................2!
C.1 Mana#e temp"ates................................................. 21
C.2 $dd%edit%de"ete content item................................. 23
C.3 &e!iew and appro!e content ................................2'
C.4 (u)"ish content .....................................................2*
C.5 Mana#e media "i)rary........................................... 2*
C.+ ,in- chec-in#....................................................... 3.
C.' Mana#e site structure............................................ 31
C./ Mana#e news"etter types.......................................32
C.* Mana#e news"etter su)scriptions.......................... 32
C.1. Mana#e news"etter su)scriptions from frontend.33
C.13 Browse news....................................................... 35
C.14 Mana#e course e!a"uation form..........................3+
C.15 &ep"y to course e!a"uation form......................... 3'
C.1+ Search content.....................................................3/
$ $ata to present.............................................%!
0.1 1orm......................................................................42
0.2 2uestion................................................................42
0.3 3ype...................................................................... 42
0.4 4ption................................................................... 42
0.5 &ep"y.....................................................................43
0.+ $nswer..................................................................43
& 'ther functional requirements...................%%
.1 Comp"e5 ca"cu"ations and ru"es............................ 45
.2 (rint6outs7 statistics and reports............................ 45
.3 0ynamic content components............................... 45
.4 5pansion of the system....................................... 4'
.5 Search en#ine optimisation................................... 4'
.+ 4ther functiona" requirements.............................. 4/
.+ 4ther functiona" requirements.............................. 4*
( S)stem integration with e*ternal s)stems..+!
1.1 0irectory ser!ice................................................... 51
1.2 $na"ytics software 6 8oo#"e $na"ytics................. 51
1.3 Course enro"ment system...................................... 51
1.4 9nte#ration with new e5terna" systems.................. 53
G ,echnical -, architecture........................... +%
8.1 Hardware and software requirements................... 55
H Securit).........................................................+6
H.1 $ccess ri#hts for users.......................................... 5'
H.2 Security mana#ement........................................... 5'
H.3 (rotection a#ainst data "oss...................................5*
H.4 (rotection a#ainst unintended user actions...........5*
H.5 (rotection a#ainst threats .....................................+1
- .sa/ilit) and design......................................6%
9.1 ,earnin# and efficiency in dai"y use...................... +5
9.2 $ccessi)i"ity and ,oo-6and6fee"............................ +'
0 'ther requirements...................................... 61
:.1 4ther standards to )e fo""owed.............................. +*
:.2 3rainin#..................................................................+*
:.3 ;ser 0ocumentation.............................................. +*
:.4 0ata con!ersion and import................................... +*
:.5 9nsta""ation..............................................................'.
2 Customer deliera/les................................ 32
4 'perations5 support and maintenance.......3%
,.1 &esponse times......................................................'5
,.2 $!ai"a)i"ity............................................................'+
,.3 Support.................................................................. ''
,.4 Maintenance.......................................................... '*
6 Glossar)........................................................ 1!
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2
1 How to assess and select a CMS
More and more organisations are facing the process of a CMS acquisition, and many
organisations find themselves on shaky ground, because they do not know where to begin or
what to expect of a CMS. Even people with knowledge of CMSs, might use a lot of resources
on clarifying needs, requirements and not least on structuring them in a way, that makes the
requirements manageable to the organisation as well as to consultants selling CMS solutions.
!his document contains a CMS requirements specification template and a guide that will help
identifying needs and requirements and convert them into a requirements specification that
solution providers can use to respond with uniform replies, making the comparison of
proposals easier. !hereby time and resources can be released for "! governance and
communication strategies that are important factors as well, but are outside the scope of this
CMS #equirements !emplate.
1.1 Why a CMS
$ebsites have gone from simple business card style static %!M& to dynamic extensions of a
companys image. ' website is much more now than ever before. ' website can be critical to
attracting and keeping customers as well as it can be the business for a company.
!he task of managing a website has grown in si(e as well, going from an "! supporter with flair
for %!M& managing a handful of pages to do(ens or hundreds of non)"! practitioners adding,
editing, deleting and arranging content on multiple domains simultaneously.
"t is therefore no surprise that the demands for systems to manage the web content have
grown, too. !oday, content management systems *CMSs+ can be as vital to a companys web
strategy as the E#, system is to the internal running and management of the company itself.
1.1.1 CMS distinction
CMSs can be categorised on many parameters and groupings. $e have chosen a distinction
based on functionality and flexibility, visualised in "llustration -, where a curve describes the
typical range of CMSs.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3
!he illustration has five points of interest.
-. /ut)of)the)box $eb CMS 0 'ble to manage web page content within certain limits
imposed by the system. 1ew ways for the customer or a third party to customise the
system beyond changing the frontend design.
2. 1lexible $eb CMS 0 Content is still web pages within certain limits, but the
customisability and extendibility is increased. Customer or a third party can make
extensive changes to the behaviour of the system.
3. 4evelopment tool 0 More of a platform to build on than a ready)to)use system. !he
customer or a third party will have few if any restrictions on how to use the system and
instead the system will facilitate common functionality through standard libraries.
%owever, practically nothing is working out)of)the)box and will have to be defined or
developed by the CMS developers or an experienced third party, meaning that the
customer relies heavily on their knowledge and skill with the CMS.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
-llustration 17 Basic CMS categories
4
5. 1lexible Enterprise CMS 0 Content is no longer web specific, but can be any content
from any system, published through the CMS and made available to internal as well as
external viewers based on the access rules defined in the CMS. 's with the 1lexible $eb
CMS, a wide range of possibilities exists for modifying and customising the system.
6. /ut)of)the)box Enterprise CMS 0 More specific functionality than the 1lexible Enterprise
CMS and more functionality directly upon installation and configuration. !his type of
CMS aims at supplying everything needed by the customers so customisations are
unnecessary.
/ne type of CMS is not better than the other. $hich CMS is the right one for a customer
depends on the customers needs. 7enerally speaking, the closer the CMS is to a development
tool, the more flexible is the system and the higher are the costs of customisations and
modifications will be in the implementation process.
1.2 Basis of the report
!he report is based on investigations on common needs and experiences collected from ten
CMS costumer organisations, five CMS consultants and one CMS developers, with the aim of
supporting the decision making in customer companies. !he report helps defining customer
needs and finding the right CMS to fulfil them in the process of *re)+defining their websites.
!he result is a template for CMS requirements specifications that can be used by companies or
organisations with a frequently updated website.
1.3 How to use this document
!his document is a guide of how to customise the CMS #equirements !emplate into a specific
requirements specification for a specific CMS acquisition pro8ect.
1or each requirement in the template, it should be considered, whether it is a requirement that
is relevant to the organisation or not. "f relevant, the requirement can be used as)is or refined
with further details or by filling in the solution example columns.
/nce the requirements specification is finished, it can be sent to candidate suppliers to fill in
the solution parts and their replies can be evaluated and compared.
1.4 Send requirements specification
$ith a requirements specification finished with all left)hand side columns filled and some right)
hand side column solution examples, it is time to send it to a range of suppliers and evaluate
the replies.
Screening candidate suppliers can be done in several ways.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5
Scenario -. Start /) selecting suppliers --. Start /) selecting s)stems ---. &. tender
Step 1 1ind competent supp"iers 1ind interestin# systems Ca"" for tenders
Step 2 Send requirements specification
<"ettin# the supp"iers se"ect the
system7 they wi"" use?
1ind competent supp"iers Send requirements specification to
interested supp"iers
Step 3 8et presentations in order to test
pre6contract proof of concept <see
chapter B261?
8et presentations in order to test
pre6contract proof of concept <see
chapter B261?
&ecei!e rep"ies
Step 4 !a"uate rep"ies !a"uate systems !a"uate supp"iers
Step 5 Se"ect <se!era"? supp"iers !a"uate rep"ies
Step + Send requirements specification
Step ' !a"uate rep"ies
,a/le 17Steps during selection
"t is recommended that at least three suppliers receive the requirements specification,
preferably more and definitely with competences within different systems. Especially in the
first case the specification should be sent to a higher number of candidate suppliers, whereas
case "", where the initial system evaluation has been performed beforehand, three can be a
reasonable number. E9 tenders have a minimum requirement of three candidates.
$hichever case is chosen, be sure to communicate what is expected of the supplier. "t is also
recommended to inform the potential suppliers that the same request is sent to other
suppliers, so the suppliers know what and how many they are up against.
1. !"aluate replies
$hen the replies come from the suppliers it is time to evaluate the proposals and select the
best one. "mplementing a CMS is a partnership and the customers work is not completed after
the selection process. !herefore, it is very important that there is a good working relationship
between the supplier and the customer, so take your time getting to know the suppliers before
committing to one supplier.
Since the acquisition process is about a C/!S *Commercial /ff)!he)Shelf+ system, it is fair to
assume that much of the required functionality will be available without any further
development. !his means that some, if not all, of the proof of concept requirements can be
validated by performing usability tests according to the tasks in chapter C and receiving a
hands)on demonstration from the supplier before making the final selection and signing any
contracts.
!his demonstration will
give a preliminary indication of usability and of how much development is needed to
fulfil the requirements.
bring you face to face with the supplier.
be a very good opportunity to make future daily users of the system perform as many
of the tasks in chapter C as the system allows and evaluate the usability.
!he next chapter Manual for CMS requirements template consists of sub chapters ' through
&, explaining the different parts of the requirements template, and is followed by a glossary.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+
2 Manual for CMS requirements template
!he manual for the CMS requirements template consists of the directions and advice on how to
use the template. !he chapters in the manual follow the chapters in the template.
!he template and this guide can be downloaded from http.::www.itu.dk:people:8ankp:CMS.
Some requirements and solution examples are in italic, meaning that it is purely an example
for illustrating purposes and that it is highly unlikely to be usable directly.
# $uidance to the supplier
3his chapter #i!es information to the supp"ier on how to read the requirements and is copied in fu""
from the correspondin# chapter in &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
# $uidance to the supplier
3his chapter e5p"ains the requirements format and how the supp"ier descri)es his so"ution.
3he requirements are or#anised in chapters accordin# to their -ind7 e.#. Chapter C a)out the user tas-s to )e
supported. Within each chapter7 the requirements are written in ta)"es7 e.#. a ta)"e with requirements re"atin# to
a specific tas-. 3he ta)"es ha!e three co"umns. 3he "eft co"umn descri)es the customer@s demand7 the midd"e
co"umn an e5amp"e of a so"ution or the proposed so"ution. 3he ri#ht co"umn specifies when the so"ution is
de"i!ered and whether it wi"" )e part of a C43S system.

#.1 %unctional requirements & constructed e'ample
Here is a constructed e5amp"e without re"ation to the present de"i!ery. 3he purpose is on"y to i""ustrate the
requirements format. 3he hi#h6"e!e" requirement is that the system must support a num)er of tas-s7 inc"udin#
C57 and prefera)"y e"iminate the current pro)"ems.
C.+ Handle a request
. . .
.sers7 Ca""6center staff7 often temporari"y emp"oyed.
&nironment7 4pen6p"an7 noisy office where users sit c"ose to each other.
(requenc)7 9n tota" around 5.. ca""s per day7 and a ma5imum of 1.. ca""s per user.
. . .
0emandA So"utionA Code
1. &ecei!e the ca"" throu#h mai"7 phone or emai".
9t may )e a new request or information a)out
an e5istin# request.
2. 1ind the request fi"e . . . 9n case of an emai" ca""7 the system automatica""y
transfers data from the emai" to the search screen.
2a. Create a new request fi"e.
2p. (ro)"emA 3he request fi"e may )e hard to
"ocate7 e.#. )ecause the ca""er doesn@t -now the
request 90 or cannot remem)er his persona"
90.
3he system shows possi)"e matches with the
ca""er@s name or parts of it.
. . .
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'
3he ta)"e "ists the su)tas-s of tas- C5. 3here is thus a requirement to support each of the su)tas-s to some
e5tent. 3he information a)out Users7 Environment and Frequency is not in the ta)"e7 so it is not requirements7
)ut assumptions )ehind the requirements. 9t means that the tas- must )e supported for this -ind of users7
en!ironment7 etc. <3he rea" requirements a)out for instance response time7 are stated in Chapter ,?.
3he requirements are enumerated. Bariants of a requirement are mar-ed with "etters a7 )7 etc. (ro)"ems re"atin#
to a requirement are mar-ed with the "etters p7 q7 etc. $s a consequence7 a cross reference to a requirement7 a
!ariant7 or a pro)"em wi"" "oo- "i-e thisA
See pro)"em C562p.
$emand. 3he "eft6hand co"umn of the ta)"e specifies the customer@s demand7 e.#. a su)tas- the system must
support7 or some data the system must store.
Solution. 3he midd"e co"umn specifies the system@s support of the demand. 9n a request for tender7 the co"umn
shows the customer@s current ima#ination of a so"ution. 3his is not a requirement or a wish7 )ut on"y a possi)"e
so"ution to he"p the supp"ier understand the demand. 9 many cases the fie"d wi"" )e empty. 9n the rep"y7 the
supp"ier wi"" fi"" in the so"ution he proposes <see section $.3?.
Code. 3he supp"ier fi""s in the ri#ht6hand co"umn with a code that specifies whether the proposed so"ution is
part of a C43S system7 an addition7 etc. <see section $.3?. Sometimes it is meanin#"ess to specify a code7 and
then the customer has written C%$ in the fie"d.
#.2 (uality requirements & constructed e'ample
Some requirements specify a qua"ity where the customer doesn@t want functiona"ity )ut an amount7 a time "imit
or the "i-e. Here is a constructed e5amp"eA
81. ;se of e5istin# hardware and software
Current"y the customer has the fo""owin# 93 equipment intended for operation of the systemA
1. 2. ser!ers of type . . .
2. . . .
9n future pea- "oad periods7 the equipment wi"" run other app"ications at the same time as fo""owsA
3. Ser!ers . . .
4. . . .
("atform requirementsA 5amp"e so"utionsA Code
1. 3he proposed system must initia""y run on the
e5istin# equipment and meet the response time
requirements in ,1.
;nder these conditions7 the system can support
DDD users. <3he customer e5pects 2. users?.
2. . . .
3he customer sti"" states his demand at the "eft7 )ut now the midd"e co"umn specifies how he wants to measure
or structure the rep"y. 9n addition7 he may state what he e5pects7 i.e. when the so"ution is fu""y sufficient.
Howe!er7 the customer may accept somethin# "ess than e5pected7 )ut wi"" then score the so"ution "ower on this
point.
3he introduction to the ta)"e specifies the assumptions the supp"ier can ma-e.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
/
#.3 )he supplier*s reply
9n the rep"y7 the supp"ier fi""s in the midd"e and ri#ht6hand co"umns to specify the so"ution he proposes. He may
show a"ternati!e so"utions and specify de"i!eries in se!era" sta#es or re"eases. Here is a possi)"e rep"y to the
first e5amp"e a)o!eA
C+. Handle a request
. . .
Su)tas-s and !ariantsA (roposed so"utionsA Code
1. &ecei!e the ca"" throu#h mai"7 phone or emai".
9t may )e a new request or information a)out
an e5istin# request.
<3he system doesn@t catch emai"7 etc. 3he user
must initiate the re#istration.?
5
2. 1ind the request fi"e . . . See search screen 12 in $pp. 5. 1
9n case of an emai" ca""7 the system
automatica""y transfers data from the emai" to
the search screen.
&e"ease 1/ pro!ides a semi6automatic transfer
from emai". See the description in $pp. 57 pa#e
y.
4.1/
2a. Create a new request. See screen 13 in $pp. 5. 1
2p. (ro)"emA 3he request fi"e may )e hard to
"ocate7 e.#. )ecause the ca""er doesn@t -now the
request 90 or cannot remem)er his persona"
90.
3he system shows possi)"e matches with the
ca""er@s name or parts of it.
3he system pro!ides phonetic search <see
search screen 12?.
2.1
<a"t.$?
2.3
<a"t.B?
. . .
3he supp"ier has chan#ed the headin# of the midd"e co"umn to proposed solution, and he has crossed out the
e5amp"e so"utions that are not re"e!ant anymore.
Codes
3he ri#ht6hand co"umn uses the fo""owin# codesA
1 (art of a C43S system.
2.5 $n e5tension of a C43S system7 )ut the e5tension is co!ered )y the ordinary maintenance a#reement.
Wi"" )e a!ai"a)"e from de"i!ery sta#e 5.
3.5 Custom6made software or an e5tension of a C43S system that is not co!ered )y the ordinary
maintenance a#reement. Wi"" )e a!ai"a)"e from de"i!ery sta#e 5.
4.y (art of a future re"ease that wi"" )e supp"ied under the ordinary maintenance a#reement. Wi"" )e
a!ai"a)"e from re"ease y.
5 Co so"ution is offered for this requirement.
a"t.E $"ternati!e so"utions are offered. 3his so"ution is part of a"ternati!e E.
9n the e5amp"e7 the supp"ier has stated that su)tas- 1 is not supported )y the system. 3he customer has to do it
as today <code 5?.
3he so"ution for su)tas- 2 consists of two parts7 and the supp"ier has sp"it the rep"y accordin#"y. (art 1 is the
C43S so"ution shown on screen 12 of $ppendi5 5 in the proposa" <code 1?. (art 2 is a feature that
automatica""y ana"yses an emai" and transfers the data to the search screen. 9t is descri)ed in $ppendi5 5 of the
proposa" and wi"" )e de"i!ered as part of re"ease 1/ <code 4?. 3he customer@s samp"e so"ution isn@t re"e!ant any
more and has )een crossed out.
Bariant 2a is supported throu#h screen 13 <code 1A part of C43S?. 9n princip"e7 the supp"ier doesn@t need to
descri)e a so"ution7 )ut can do with specifyin# code 1. Howe!er7 e5perience shows that this ma-es the
customer fee" uneasy. 0oes the supp"ier understand our demand at a""F 3his -ind of dou)t si#nificant"y reduces
the supp"ier@s chance of winnin#.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
*
(ro)"em 2p i""ustrates one more comp"e5ity of the proposa". 3he supp"ier offers two a"ternati!es that the
customer can choose )etween. $"ternati!e $ has a traditiona" search feature that can )e de"i!ered in sta#e 1.
$"ternati!e B has ad!anced phonetic search that can )e de"i!ered in sta#e 3. Both features are co!ered )y
ordinary maintenance <code 2?.
3he customer may find it !ery hard to understand a proposa" with se!era" a"ternati!es7 sta#es and re"eases. 9t is
stron#"y su##ested that the supp"ier su)mits an o!er!iew of the a"ternati!es7 the sta#es in!o"!ed for each7 and
the re"eases. 9t is con!enient if the prices are shown in the same p"ace.
Here is a possi)"e rep"y to the second e5amp"e a)o!eA
81. ;se of e5istin# hardware and software
. . .
("atform requirementsA (roposed so"utionsA Code
1. 3he proposed system must initia""y run on the
e5istin# equipment and meet the response time
requirements in ,1.
;nder these conditions7 the system can support
1. users. <3he customer e5pects 2. users?.
1
2. . . .
3he supp"ier has specified that his so"ution can support 1. users. Since this is fewer than the customer hoped
for7 he -nows that he wi"" score "ower than a competitor who promises to support 2. users. 4n the other hand7
if he had offered 4. rather than 1.7 this wou"d #i!e him no ad!anta#e to the competitor who promised 2..
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
1.
B Hi+h le"el demands
B.1 Business +oals
!he business goals are important. ;oth as a communication tool towards the rest of the
organisation *why are we doing this<+, towards top management *what will be the benefits for
the organisation<+ and towards the evaluation process and towards the supplier *how do we
know, if the pro8ect was a success<+. !he goals should be quantifiable, when possible, to
enable measuring the success of the implementation, as long as the measurement is possible
with a reasonable amount of effort.
' goal such as =increase sales by ->?@ can be very difficult 0 if not impossible 0 to measure,
since many factors come into play when sales increase. %owever, =increase sales coming
through the website to 2>? of total sales within -2 months@ can be measured and used for
evaluation.
$hen determining the business goals, requirements to accomplishing the goal will be identified
along with requirements to measure the goal. E.g. to increase sales coming through the
website to 2>? of total sales, clients will have to be able to make purchases via the website,
either directly or through contacting a salesperson. !o know whether the sales coming through
the website has indeed increased to 2>? of total sales, a method of deciding whether a sale is
coming through the website is required.
1. Increase sales through the web by 20 % within 12 months
' common use of a website is to allow customers from anywhere to place orders with the
company or to place orders without employee interaction. !herefore, the goal of many CMS
implementations is an increased use of the website as a sales channel, increasing revenue
from the web.
2. Increase page views / visits with 20 % within 12 months
1or most organisations, a website is a marketing channel intended for raising awareness of the
organisation and its products. ,age views and visits are in itself not a revenue)increasing goal.
%owever, with increased page views and increased visits, awareness is raised and the chance
of gaining new or retaining current customers increase.
!o increase the page views and make visitors come back, the website should contain relevant,
up)to)date content and respond quickly to the visitors browsing. !o get the visitors to come in
the first place, optimising for search engines can make a large difference.
3. Distribute website content updates across organisation
More people updating the content increases the likelihood of the content being updated
regularly, making the content more reliable and, since there are fewer steps from the people
with know)how to the people updating the content, more correct.
4. Knowledge sharing. 7% o! all procedures available on the intranet within 12 months
$hen employees can find and add needed information by themselves, less knowledge will be
stored within departments in folders or inside the heads of department employees. !his means
less time spent on information search and more time spent on information use, increasing
productivity.
5. "educe user management wor#load by $0%
"ntegrated user management reduces the workload for "! administrative personnel, who can
focus on other tasks.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
11
B.1 Business +oals
3he customer@s reason to acquire the system is to reach some )usiness #oa"s. 3he customer e5pects that the
system contri)utes to the #oa"s as stated )e"ow. 3he supp"ier can rare"y reach the #oa"s a"one. Customer
contri)ution is needed too. 3his means that the #oa"s are not requirements to the supp"ier. 3hey are shown in a
ta)"e on"y to pro!ide o!er!iew.
$"" #oa"s are important and the sooner they can )e met7 the )etter. Some #oa"s are crucia" to meet at a specific
date7 for instance for )usiness or "e#a" reasons. Such dead"ines are shown in the ta)"e.
8urpose with the CMS 'erall solutions 9elated requirements $eadline
:if an);
1. 9ncrease sa"es throu#h the
we) by 20% within 12
months
$utomated sa"es process
Consistent desi#n
Sa"es%si#n6up system with statistics
<chapter 0?
Site temp"ates <chapter C.1?
2. 9ncrease pa#e !iews % !isits
)y 20% within 12 months
&e"e!ant data on we)site
1ast response times
Statistics functiona"ity <chapter .2?
Short response times <chapter ,.1?
Search en#ine optimisation <chapter
.5?
3. 0istri)uted we)site content
updates across or#anisation
na)"e non693 proficient
users to add and update
content
;sa)i"ity7 ducation7 8uides
<chapters 9 and :?
4. Gnow"ed#e sharin#. 75% o
all procedures available on
the intranet within 12
months
Ma-e content easy to
pu)"ish and easy to find
asy content pu)"ishin# <chapter
C.4?
Search functiona"ity <chapter C.1+?
5. &educe user mana#ement
wor-"oad by !0%
$uthentication
Security
0irectory ser!ice inte#ration
<chapter 1.1?
+. &educe repetiti!e customer
ser!ice ca""s by 25% within
12 months
Ma-e content a!ai"a)"e and
easy to find on the we)site
asy content pu)"ishin# <chapter
C.4?
Search functiona"ity <chapter C.1+?
'. Mo!e !5% of the resources
from technica" de!e"opment
and operations to
production of content
Stream"ine user and
we)site mana#ement
0irectory ser!ice inte#ration
<chapter 1.1?
asy e5pansion of the system
<chapter .4?
/. $ccessi)i"ity standards
comp"iance
nforce accessi)i"ity
standards
Chapter 9.2
*. 9ncrease update frequency
to
5 times a wee" on 1
st
"e!e"7
5 times a month on 2
nd
"e!e"7
# times per year on 3
rd
"e!e"
from the front pa#e
asy to use and efficient
CMS
Hi#h usa)i"ity <chapter 9?
&eminders to pa#e responsi)"e7
when pa#e has not )een updated
recent"y <chapter .+?
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
12
6. "educe repetitive customer service calls by 2% within 12 months
When customers can find the information they need on the we)site7 fewer ca""s wi"" )e made to
customer ser!ice7 who can focus on pro!idin# a )etter ser!ice rather than answer the same questions
a#ain and a#ain.
7. %ove $% o! the resources !rom technical development and operations to production o!
content
!echnical solutions by themselves do not increase revenues or give a better service. $ith less
resources needed for maintaining the website, more resources can be spent on enhancing the
website and its content, supporting the people, who can provide better services.
8. &ccessibility standards compliance
More and more organisations 0 especially municipal authorities 0 face requirements from laws,
stating that disabled people must be able to access content on their websites. $hen this is
supported by the system, content providers can focus on what to publish instead of how the
content should be structured.
9. Increase update !re'uency to
times per wee# on 1
st
level
times per month on 2
nd
level
( times per year on $
rd
level pages
/ften the front page and pages placed high in the site structure, are apt to contain information
which needs to be updated more often, than pages on a lower level, which are often more
specialised and seldom needs to be changed. !he easier it is to update a website, the more
likely is it to be updated regularly.
B.2 !arly proof of concept
!his chapter describes the requirements that are considered to be the most risky, and why an
early proof is needed. !he goal of the supplier is to convince the customer that the suppliers
system can meet the requirements within the allocated time frame.
1. &!ter a short instruction by super users to the )%* bac#end+ the ordinary users must be
able to carry out all tas#s in )hapter ) within their own wor# areas without critical usability
problems
!he easier the system is to use, the less resources will be spent on training, re)training and
support.
;ringing super users into the evaluation and customisation process will also have the added
benefit of involving the super users. 9sers, who are involved with a system implementation are
usually much more inclined to use it properly and explore the possibilities than users, who get
a system =pulled down on them@ that they are forced to use.
2. "esponse times with the re'uired number o! users
"mplementing a system without knowing if it can deliver the required response times would
rate high among the biggest errors that can be made. ,romises from a supplier should be
proven as soon as possible with expected data volumes, so the supplier will know whether
additional measures, such as caching solutions or better hardware, are needed.
3. Integration with large e,ternal systems such as -avision+ *iebel or *&.
"f the organisation relies on automatic order processing or lead generation, this integration will
be vital. Anowing as early as possible that the connectivity and transfer of data from one
system to the other is working, increases the likelihood of the full integration working at the
specified time.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
13
B.2 !arly proof of concept
3he customer wants to a!oid the situation where the tri!ia" parts of the system are de!e"oped ear"y7 whi"e the
hard parts are postponed and pro!e impossi)"e to de"i!er. 3o pre!ent this7 the customer requires an ear"y proof of
concept.
$ccordin# to the contract7 )oth parties can terminate the contract if the ear"y proof fai"s.
3he fo""owin# requirements are considered hi#h6ris-. Su)stantia" deficiencies in these areas can hard"y )e
corrected "ate in the proHect. 9n his rep"y7 the supp"ier must state how he wi"" carry out the proof of concept and
when. 3he date must )e stated as the num)er of wor- days after si#nin# the contract.
9is#) requirements where earl) proof is
required
&*ample of proof $ate
possi/le
1. $fter a short instruction )y super users to
the CMS )ac-end7 the ordinary users must
)e a)"e to carry out a"" tas-s in Chapter C
within their own wor- areas without critica"
usa)i"ity pro)"ems.
3as- in chapter C shou"d )e tested as descri)ed in
chapter 9.1 <p. +4?
Can )e done )efore contract si#nin#.
2. &esponse times with the required num)er of
users <a"" requirements in chapter ,.1 for
)ac-end and frontend?.
$ test setup with dummy rontend contend is used
to simulate the required number o users% &he
response times are measured% 'an be done
within ((( wor"in) days%
3. 9nte#ration with "ar#e e5terna" systems such
as Ca!ision7 Sie)e" or S$(
*roo o connectivity with dummy data%
'an be done within ((( wor"in) days%
4. Cews"etter su)scription process *roo o wor"in) prototype%
'an be done within ((( wor"in) days%
5. (ossi)i"ity for third6party e5pansion of the
system.
+ocumentation o parts o the system and the
technical interaces is studied by an independent
sotware house in order to assess whether it is
adequate or e,pandin) the system% 'an be done
within (( wor"in) days%
+. ,0$( inte#ration with more than one
domain
-or"in) prototype with .+$* authentication o
users rom 2 domains%
'an be done within ((( wor"in) days%
'. ;sa)i"ity of supp"ier6de!e"oped pa#es7 ie.
user test of data !iew and functiona"ity at
the frontend of the CMS
&est o a prototype o the pa)es data and
unctionality /maybe a paper moc" up0 is
assessed by e,pert users%
'an be done within ((( wor"in) days%
/. ;nderstanda)"e error messa#es *resentation or listin) o error messa)es, as"in)
uture users whether they understand the
meanin)%
'an be done within ((( wor"in) days%
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
14
4. -ewsletter subscription process
Bewsletters can be very important to a company. "t is an excellent way of communicating to
many customers at once and it is extremely easy for the recipients to forward a newsletter to a
friend. %owever, newsletter subscribers expect easy subscription and unsubscription. !his is
considered a high risk functionality, because in case the unsubscription process does not work
properly, the newsletters sent to unsubscribed email addresses are effectively =spam@ mails
which can result in substantial fines. 'dditionally it is bad for the image of the business to send
out newsletters to customers, who has stated, that they do not want to receive newsletters.
5. .ossibility !or third/party e,pansion o! the system.
' website is an organic entity where visitors expect changes and new initiatives on a regular
basis. %aving the possibility of hiring consultants to expand the system with custom
components 0 or have an "! department do it 0 will allow you to react quickly to new ideas and
lessen your dependency on the supplier.
6. 0D&. integration with more than one domain
&4', integration 0 should it be a requirement 0 can make user administration much simpler
for the "! department. %owever, experiences with multiple &4', domains show that it can be a
large task integrating them into one web application. Since the CMS is impossible to manage
without the login procedure working, it is important to know with certainty that it will work.
7. 1sability o! supplier/developed pages+ ie. user test o! data view and !unctionality at the
!rontend o! the )%*
Similar to risk -, usability is very important to test as early as possible. %owever, since these
pages are developed by the supplier in the implementation process, it *usually+ cannot be done
before the contract is signed, as opposed to risk -.
8. 1nderstandable error messages
Error messages are only useful, if they make sense to the user. !herefore the
understandability of the error messages should be tested and the supplier instructed to change
those that cannot be easily understood by the users.
B.3 ,mplementation time frame
!he implementation schedule is important to consider as well. %ow early can you get a proof of
concept< %ow early can the users get training< $hen can you expect your new website to be
up and running<
Since you are looking at standard systems, it is fair to assume that much of the required
functionality exists, although it will usually need adaptation to fit specific needs. !herefore it is
also fair to assume that you can get a proof of concept before you have even selected the
system and signed the contract. "n the final CMS solution you should expect that standard
modules can require some customisations to fit in with the customers desires, even though
the module doesnt have to be developed from scratch.
B.4 Selection criteria
!o gain overview of the proposal each selection criteria from section ;.5 can be given a weight
that states the importance of the criteria. "n the different proposals, the handling of each
criteria should be given a score, stating how well the criteria is met by the suppliers.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
15
B.3 ,mplementation time frame
3he system de"i!ery steps as e5pected )y the customer. Missin# steps can )e added )y the supp"ier. 3he !arious
dates shou"d )e estimated )y the supp"ier as if the decision to si#n the contract is done two wee"s ater the
su##ested date for proof of concept I pre6contract proof.
$elier) $ate
1. (roof of concept I pre6contract proof 200710#1!1
2. (roof of concept I remainin# proof
3. 0esi#n app"ied
4. 3est set up I usa)i"ity and functiona"ity tests
5. 0ata con!ersion and import
+. ducation materia"
'. ducation of users
/. System documentation
*. (roduction set up I acceptance tests
1.. ,aunch 20071121!1
B.4 Selection criteria
3he customer chooses the so"ution that is best rom an economic point o view. ach criteria is #i!en a wei#ht
)etween 1 and 1. to indicate the importance of this criteria. 3he supp"ier@s so"ution wi"" )e #i!en a score )etween
. and 4 for each criteria and this score is mu"tip"ied )y the wei#ht. $ddin# the wei#hted scores for a"" criteria
#i!es the tota" score for the so"ution. $dditiona""y7 each criteria has a minimum score assi#ned that wi"" resu"t in
so"ution disqua"ification re)ardless o the scores in other criteria7 shou"d the so"ution score "ess.
Criteria Wei#ht Min. score
1. ;sa)i"ity requirements in chapter 9 and C 2 !
2. Business !a"ue of the so"ution. $ssessed as a num)er
for each of the )usiness #oa"s <B.1?. 3 !
3. 3he ris-. $ssessed from the time for the ear"y proof
<B.2? and the fraction of the so"ution that a"ready
e5ists in the CMS. 4
2
4. 0e"i!ery time B.3. ! 1
5. (rice inc"udin# the customer@s costs for new
equipment7 data con!ersion7 and user trainin# B.5. 4 2
+. Mar-et ro)ustness7 i.e. How safe the so"ution is in
re#ards to "on#e!ity7 financia" )ac-up7 rate of
de!e"opment and simi"ar. 5 2
'. 5tenda)i"ity. How easy wi"" it )e to e5tend the
system )y addin# modu"es <.4?or inte#ratin# with
other systems <chapter 1?. 10 !
/. Bia)i"ity of the community supportin# the CMS 2 1
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
1+
Wei+htin+s
"t is not easy to set the weightings, and it can be done in different ways. !he optimal way to
set the weights would be on basis of a cost)benefit analysis. "n some situations, like when a
requirement specification is the basis of an E9 tender, it actually is a requirement that the
selection criteria have weightings, but this is a large area, on which information can be found
at various websites
-
. !he weightings are set in proportion to the estimated business value, so
there are no upper limitation on the weightings to be set. !he potential suppliers should be
informed of the selection criteria and their weightings.
Score
$hen receiving proposals of suppliers on basis of the requirement specification, the proposals
should be evaluated one by one. 1or each of the proposals, the criteria are given scores
between > and 5, stating how well the proposal handles each criteria, as shown in the table
below.

Score Meaning
. Cot hand"ed
1 Cot as #ood as today % ,ess than e5pected
2 3he same as today % ,itt"e "ess than e5pected
3 $s e5pected
4 Better than e5pected
,a/le 27 Score
' criteria can also have set a minimum score to disqualify unacceptable proposals no matter
their score in other criteria as shown in the table below in the columns with the header Min..
!he total score of each proposal can be calculated by summarising the criteria value multiplied
with the weight.
CMS7 proposal < proposal = proposal > ...
Selection criteria "eight Min. Score "eighted Score "eighted Score "eighted ... ...
1. ;sa)i"ity / 3 4 32 5 5 5 5
2. Business !a"ue 1. 4 4 4. 5 5 5 5
3. &is-s + 2 3 1/ 5 5 5 5
4. 0e"i!ery time 2 1 1 2
5. (rice 3 2 3 *
+. Mar-et ro)ustness ' 2 2 14
'. 5tendi)i"ity + 2 3 1/
/. Community 1 . . .
,otal score7 133 ...
,a/le 67 &aluation of proposals
- !he E9 directive 2>>5:-C:EC is a good term in search engines when looking for information and can be found in
full, legal text at http.::europa.eu.int:eur)lex:pri:en:o8:dat:2>>5:lD-35:lD-352>>5>53>en>--5>25>.pdf
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
1'
!he scores should be used to indicate which proposals are simply not good enough compared
to the others. !he proposal with the highest total score is not always the best proposal, but it
is recommended to select a proposal with a high total score.
-sa.ility
9sability can be measured in the pre)contract signing proof)of)concept phase as described in
-.5 assigning scores depending on the number of issues and their severity.
Business /alue
!he business value is an estimation of how well the proposal will fulfil the business goals.
0is1s
!he risk is a measurement of how convinced the customer is on whether the supplier delivers
the expected CMS. !he earlier the proof)of)concept risks can be proven, the better. /ther
indicators of low risks could be, that the right side of the tables are filled in with good
solutions, it could also be, that the supplier has solved similar problems before as well, as it
can be experiences from previous deliveries from the supplier. !he more indicators of low risk,
the better should the score of the proposal be in this criteria.
2eli"ery time
!he rule of thumb is naturally =the sooner, the better@. %owever, be careful not to apply too
high weightings to this criteria, ending up with poor system functionality delivered quickly. /ne
way of evaluating delivery times is to set an expected date for the system launch. /ffers
delivering around this date gets a score of three 0 as expected 0 with earlier offers achieving a
score of four and later offers two, one or (ero, depending on the difference to the expected
date.
3rice
"f the price of the CMS acquisition is above a certain amount, there must be an E9 tender, an
open proposal evaluation to avoid corruption and nepotism. !his requires ob8ective selection
criteria. !here are two different ways to choose a proposal in an E9 tender..
-. !he cheapest proposal is simply the proposal with the lowest price. "f the requirements
are met, it will not be taken into account that one of the proposals might have a higher
business value.
2. !he economically most attractive proposal is the proposal that gives most value per
price unit, i.e. the highest coefficient. !here might be cheaper proposals, but the focus
is the value compared to the amount of money spent, as shown in the coefficient
calculation example.
Business !a"ue I &is-
(rice
JKL
4..7... I 1..7...
1..7...
K
3
!he risk is estimated as a quantification of the risks involved with the suppliers bid, the
amount of functionality that will need to be developed and the amount of functionality that is
available for a proof)of)concept session. "f the cheapest proposal has to be chosen, the
suppliers reservation about requirements, which are described in the requirements
specification, can be estimated as a quantification of the risks and added to the price, when
finding the cheapest proposal.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
1/
E9 tendering is a large area, and if the CMS acquisition has to call for a tender, it is important
to look further into the area, since the selection criteria must be substantiated in the
requirements specification and the type of E9 tender chosen beforehand.
Mar1et ro.ustness
$hen evaluating a candidate system, it must be considered, how stable the organisation
behind the system is. !his includes both the supplier, the system developer *if the CMS is
developed by someone else than the supplier+ and the system developers other partners. $ill
the system be maintained and updated in the future< $ill consultants be available< "s there a
customer base large enough, so that the developers most likely have made improvements to
the system, based on feedback from suppliers and their customers<
!'tendi.ility
Customer needs do change and it can be extremely difficult to predict, what will be needed of
the CMS in the future. Ensuring that the CMS can be extended with new content types, new
functionality and new integrations increases the probability that the CMS will fulfil future
needs.
Community
Sharing experiences and getting advice from people in a similar situation is a good way to
improve the use of a CMS in an organisation. 'dditionally, if the customer would like to be able
to make development on the system themselves, it is important that there is a viable
community supporting the product. 4oes the community have independent contributors or is it
only the CMS supplier that makes contributions< %ow active are mailing lists and web sites< "s
there a friendly culture in the community, and are they welcoming newcomers<
B. 3rice
%ow much you are willing to spend on the website is an important consideration from a quite
early point in the process. "ntegration with other systems as well as development of custom
content and design will be consultancy pro8ects that can weigh heavily on the budget after the
system acquisition and license payments.
"t is always a good idea to get a solution built from modules, where each module can work
independently on a basic module. "n case the price exceeds the budget at the time, it will still
be possible to launch a smaller solution that can be extended later, without having to rebuild
the existing solution.
!his would also be a good place to ask questions of the supplier regarding what is included in
the agreed price.
Can the customer claim that the supplier corrects errors for free, if they are caused by the
suppliers code< 'nd if so, for how long<
Can the customer expect that the supplier corrects errors for free, the CMS has them from the
beginning<
$ho pays in case the supplier with a correction introduces new errors<
7etting the prices specified in as much detail as possible will help you determine the total price
and running costs better and lead to fewer costly surprises.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
1*
B. 3rice and deli"era.les
9n this "ist7 the supp"ier sha"" input the prices for the !arious de"i!era)"es in as much detai" as possi)"e as we"" as
he is encoura#ed to add missin# items on the "ist. 3he "ist is di!ided into one6time costs in the imp"ementation
process and runnin# costs after imp"ementation.
'ne?time costs 8rice Specifications
1. Start "icence
2. 9mp"ementation
0ocumentation
;ser and de!e"oper #uides to the CMS
2a. BariantA Hour"y rate durin# imp"ementation
3. Hardware
4. 0esi#n
9unning costs 8rice Specifications
5. Maintenance "icence
+. ducation
'. ;ser support
/. Hour"y rate for post6imp"ementation
de!e"opments
*. Correction of errors caused )y de!e"oper
updates to the CMS
0 5ncluded in maintenance license
1.. Correction of errors caused )y the supp"ier 0 5ncluded in maintenance license
11. Correction of errors in the CMS7 present at the
time of imp"ementation
0 5ncluded in implementation costs
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2.
C Wor1 areas and tas1s
!he work areas of this chapter contain tasks that are used in the CMS on a regular basis. Most
of the functional requirements will be in this chapter. $hen defining the tasks, you should
consider the following.
Chapter C contains CMS requirements which are related to procedures and tasks, that the
system must support. !he requirements have their starting point in user needs, and the
requirements are formulated in a way, that leaves it to the supplier to find out, how to satisfy
them. "n this way the specification will not restrict the developers or the range of potential
systems unnecessarily.
"n the following, some of the requirements are explained further, in order to help the
customer decide, if the requirements and any related problems are relevant in their situation.
C.1 Mana+e pa+e templates
!emplates are usually used to maintain a certain layout on pages of a site. !emplates can be
on site)level, where they determine the general layout of items, headers, navigational links
etc. or they can be on page)level, where they determine the layout of the page itself.
Most CMSs employ this concept in some form.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
21
C Wor1 areas and tas1s
3he system must support a"" user tas-s in this chapter7 inc"udin# a"" su)tas-s and !ariants7 and miti#ate the
pro)"ems. 3he su)tas-s are num)ered for reference purposes. 3hey don@t ha!e to )e carried out in this sequence7
and many of them are optiona". $ su)tas- may a"so )e repeated durin# the same tas-.
C.1 Mana+e templates
;sin# temp"ates is a way to contro" the "ayout and a too" to create a uniform appearance of a"" the pa#es that
ma-e up the site7 no matter who updates them.
$ CMS is often set up in a way7 that forces the users to use the temp"ates7 and therefore it is important7 that there
are enou#h temp"ates to pro!ide f"e5i)"e presentation of content whi"e -eepin# the num)er "ow enou#h to retain
the o!er!iew of a!ai"a)"e temp"ates and when to use which temp"ate.
Start7 $ pa#e temp"ate needs addition7 updatin# or de"etion
&nd7 (a#e temp"ate is sa!ed or de"eted
(requenc)7 &are"y once set up
.sers7 We)site administrators7 #raphica" desi#ners
Su/?tas#s and ariations Solution e*ample Code
1. ,ist temp"ates
1p. 9t can )e difficu"t to distin#uish )etween the
"ayout of temp"ates7 if they on"y are identified
)y names
9nstead of choosin# amon# the temp"ates from
their names on"y7 it mi#ht )e easier to o!er!iew
and choose the ri#ht temp"ate7 if they are
represented )y sma"" rou#h mode"s of their
"ayout for instance.
2. $dd temp"ate
3. dit temp"ate
4. ;ndo chan#es
5. Sa!e temp"ate
5a. BariantA Sa!e temp"ate with another name%copy
temp"ate
+. 0e"ete temp"ate
+p. (ro)"emA 3emp"ate is in use. 9f a temp"ate is
)ein# used )y pa#es7 the system shou"d pre!ent
that it is de"eted7 and if the temp"ate is to )e
rep"aced )y another one7 it is usefu" to )e a)"e
to see which pa#es are usin# the temp"ate.
B"oc- de"etion and "ist pa#es usin# this temp"ate
4ption to se"ect a rep"acement temp"ate to )e
app"ied to a"" pa#es usin# this temp"ate
+q. (ro)"emA ;sers cannot see which temp"ates are
in use )efore tryin# to de"ete them. 3here may
e5ist numerous temp"ates in the CMS7 and
some of them may e!en )e e5act copies of
others7 meant to )e chan#ed in some way. 3o
)e a)"e to c"ean up amon# the temp"ates7 it has
to )e c"ear which are in use and which are not.
,ist temp"ates with indication of whether it is in
use
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
22
C.1 Mana#e temp"ates <continued?
Su/?tas#s and ariations Solution e*ample Code
'. When new desi#n temp"ates are imp"emented
or new pa#e "ayout temp"ates are created to
rep"ace e5istin# temp"ates7 a method to rep"ace
the o"d temp"ates with the new is needed.
'p. (ro)"emA ;ser can on"y rep"ace the temp"ate
one pa#e at the time. Sites can ha!e thousands
of pa#es7 and chan#es to the #enera" "ayout on
on"y parts of the site do occur. Hence7 it shou"d
)e possi)"e to rep"ace the temp"ate of many
pa#es a"" at once.
&ep"ace temp"ate of se!era" pa#es a"" at once. 1or
instance )y rep"acin# the temp"ate from a certain
site6node and )e"ow or )y mar-in# the pa#es7 in
a mode" of the site tree structure7 and rep"ace
with another temp"ate a"" at once
/. &ep"ace temp"ate for a certain pa#e node and
for a"" pa#es )e"ow. (a#es )e"ow another pa#e
are often re"ated and so is the "ayout.
3herefore7 it ma-es sense to optimise the
"ayout chan#e for a pa#e node and a"" the pa#es
)e"ow it.
/p. (ro)"emA (a#es )e"ow a certain pa#e node may
ha!e )een specia""y de!e"oped or they may use
another temp"ate that shou"d not )e rep"aced
&ep"ace pa#es with a specific temp"ate on"y.
(a#es usin# other temp"ates wi"" stay unchan#ed.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
23
C.2 #dd4edit4delete content item
'dd, edit and delete content are basic functionalities in every CMS, and every CMS will contain
the functionality. !he interesting things are therefore the problems that users have
experienced when adding, editing or deleting content. !hese problems are explained below
because these are problems that are handled differently, if at all, in different systems.
Most pages will include media files, most often images, to liven up the page and aid the
readability.
C.2)2p .roblem3 )opy/pasting to the )%* editor does not automatically upload picture to
media library
!he fact that media files have to be uploaded to the server to be visible to the public on a
website, is an abstraction that some new or rare users of CMSs forget. ' user writes some
content in a $ord document, inserts some pictures and tries to copy and paste text as well as
pictures into the CMS editor. !his is a intuitive thing to do, but usually CMSs cannot handle
the pictures this way. !he ideal solution would be a CMS that could handle this, and
automatically upload the picture to the media library and change the reference in the text from
the local pc to the media library on the server. 'nother way of handling the problem could be a
message telling the user to upload the picture to the media library, if a picture is pasted into
the editor.
C.2 #dd4edit4delete content item
"or# areaA CMS )ac-end
StartA Content has to )e edited7 feed)ac- recei!ed7 resumption of par-ed content
&ndA Content sent for appro!a"7 pu)"ished7 or par-ed for "ater resumption
(requenc)A 0ai"y
.sersA $dministrators7 editors and authors
Su/?tas#s and ariations Solution e*ample Code
1. 1ind content item. When a user edits or creates
a pa#e7 there mi#ht )e a )rea- in the tas-7 and
the user wi"" ha!e to sa!e the unpu)"ished
content item in order to resume the tas- the
ne5t day7 or hand o!er the tas- to a co""ea#ue.
3herefore the users wi"" need an easy way of
"ocatin# content to resume editin#.
,ist of content items
0irectory structure with content items
1p. (ro)"emA$ par-ed content item can )e difficu"t
to find
4ption to "ist on"y unpu)"ished pa#es
Mar- unpu)"ished pa#es with appropriate icon or
co"our
2. dit pa#e%content
2a. BariantA Create pa#e )ased on temp"ate
2q. (ro)"emA CMS editor on"y shows a "itt"e part
of the pa#e7 so the o!er!iew of the pa#e in its
conte5t is missin#
CMS editor shou"d )e a)"e to show the entire pa#e
and not on"y the )o5 that is )ein# edited
2r. (ro)"emA Someone edits a pa#e he shou"d not
edit
(ermissions shou"d )e set up so that on"y re"e!ant
pa#es are !isi)"e to and edita)"e )y a user
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
24
C.2 $dd%edit%de"ete content item <continued?
Su/?tas#s and ariations Solution e*ample Code
3. Search amon# media fi"es in the media "i)rary Meta data for search purposesA Came7 te5t7
photo#rapher7 date ....
4. 9nsert a media fi"e on the pa#e
4p. (ro)"emA Copy6pastin# <from Word for
instance? to the CMS editor does not
automatica""y up"oad picture to media "i)rary
CMS editor7 that automatica""y up"oads media fi"e7
when copied into the editor and prompts the user
for meta data
Messa#e7 that te""s the user to remem)er to up"oad
a picture
4a. BariantA 9nsert other content <see .3 0ynamic
content components?
5. ;p"oad a media fi"e and set meta data
5p. (ro)"emA ;ser o!erwrites fi"e used on pa#es
with an unsuita)"e ima#e7 thin-in# that it is not
in use.
8i!e a warnin# that the fi"e is in use and )"oc- the
o!erwrite
+. $dd%chan#e meta data to a content item such
asA responsi)"e person7 creation date7 !a"id
from7 !a"id to7 -eywords
Some of the !a"ues cou"d ha!e defau"t !a"ues set
automatica""y e.#. creation date and responsi)"e
person defau"tin# to the current user
'. 0e"ete content
'p. (ro)"emA 0e"eted pa#e has su)6pa#es in the
tree7 resu"tin# in MorphanN pa#es without
parent pa#es
Warnin# a)out consequences when tryin# to de"ete
the pa#e7 )"oc- de"etion
'q. (ro)"emA 0e"eted pa#e is "in-ed to from other
pa#es. &eferencin# pa#es wi"" ha!e a dead "in-
to the de"eted pa#e.
B"oc- de"etion and show "ist of referencin# pa#es
/. (ar-%Sa!e content for "ater resumption7 i.e. it
has to )e sa!ed without )ein# pu)"ished or sent
for appro!a"
/p. (ro)"emA 3he tree structure in the )ac-end can
)ecome pretty deep7 and the window that
contains the tree structure is refreshed e!ery
time the user presses the sa!e )utton and he is
redirected to the top of the tree structure
instead of to the fo"der where he is current"y
wor-in#. 3hen he has to scro"" down and
may)e e!en e5pand the tree structure a#ain to
)e a)"e to continue where he "eft.
* Send for appro!a" Manua""y )y mai"7 phone or !er)a""y or )y an
automated wor-f"ow functiona"ity
1.. &ecei!e feed)ac- from appro!er%editor Manua""y )y mai"7 phone or !er)a""y or )y an
automated wor-f"ow functiona"ity
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
25
C.2 $dd%edit%de"ete content item <continued?
Su/?tas#s and ariations Solution e*ample Code
11. ;ser shou"d )e a)"e to see how the edited
content wi"" "oo- on the pa#e without
pu)"ishin# it
11p.(ro)"emA (re!iew doesn@t "oo- e5act"y as the
pa#e does7 when sa!ed. ;sers do a "ot of
editin# and wi"" ha!e to pu)"ish e!ery time
they want to see what it rea""y "oo-s "i-e in the
pa#e@s conte5t.
(u)"ish to sta#in# ser!er with )rowsin# as if it was
pu)"ished
(re!iew on"y se"ected pa#e in frontend desi#n as if
it was pu)"ished
11q.(ro)"emA 9t is difficu"t to se how the edited
content item is #oin# to "oo- on the pa#e7 if the
pre!iew does not contain the rest of the pa#e
12. ;ndo chan#es &o"" )ac- to ear"ier !ersions
;ndo in editor
13. (u)"ish <See "on# su)tas- C.4?
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2+
C.3 0e"iew and appro"e content
,ublish content has been separated as a long subtask to C.2 to give a better overview of the
process. !he subtasks can be called a workflow, which supports and enforces publishing
restrictions.
' workflow is a chain of tasks that are carried out by different user roles. 'n example could be
that an author writes an article and an editor approves the article before it gets published. '
workflow system can enforce and support these organisational procedures directly in the CMS,
thus not allowing for content providers to skip this step.
"f the customer wants to enforce content review prior to publishing and:or enforce that only a
few people can publish content, this long subtask is relevant. "n our experience, though, it is
often thought of as needed in the requirements, but rarely used in the finished solution, due to
the increase in bureaucracy and the fact that the process could 8ust as easily be manual with
content providers communicating directly, asking for a review, when in doubt.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2'
C.3 0e"iew and appro"e content
StartA Content is ready for re!iew7 notification recei!ed )y re!iewer
&ndA Content re!iewed and feed)ac- #i!en to content pro!ider or content appro!ed and pu)"ished
(requenc)A Baries )etween many times a day to wee-"y7 month"y or year"y
.sersA Content editors
Su/?tas#s and ariations Solution e*ample Code
1. &ecei!e notification a)out content ready for
pu)"ishin#
Manua""y )y mai"7 phone or !er)a""y or )y an
automated wor-f"ow functiona"ity
2. ,ocate content
2p. Content created or "ast edited )y another editor
can )e difficu"t to find
,in- in notification emai"
Search functiona"ity
,ist of unpu)"ished content items
We""6arran#ed directory structure7 where
unpu)"ished content items can )e identified easi"y
3. Correct content
4. (u)"ish <See "on# su)tas- C.4?
4p. (ro)"emA 9t is on"y possi)"e to pu)"ish either
one sin#"e content item or a"" unpu)"ished
content items at the same time. Sometimes7
editors wor- on se!era" items and pu)"ishin#
content items one )y one is too s"ow7 whi"e
pu)"ishin# a"" items in the queue wi"" pu)"ish
items not ready for pu)"ishin#.
(ossi)i"ity to pic- out a num)er of content items
to pu)"ish in one #o
4q. (ro)"emA 9t is time consumin# that the CMS is
"oc-ed with an hour#"ass whi"e a pa#e is )ein#
pu)"ished. 9t shou"d )e possi)"e to continue the
wor- whi"e a pa#e is )ein# pu)"ished
5. &eHect content Manua""y )y mai"7 phone or !er)a""y or )y an
automated wor-f"ow functiona"ity
+. Cotify user a)out reHection or pu)"ishin# of the
content
Manua""y )y mai"7 phone or !er)a""y or )y an
automated wor-f"ow functiona"ity
+a. BariantA $dd a messa#e to the notification
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2/
C.4 3u.lish content
&ong sub)task to C.2 and C.3.
C. Mana+e media li.rary
'll websites need at least a few hand)typed pages with text, images and links to other pages
or websites. Most CMSs have a repository for media files 0 images, video files, $ord and ,41
documents etc. ) that can be inserted on a page. !his is a basic requirement that must be
present, although the specific functionality can vary.
!he requirements to media library varies, but if the site contains many pages referring to
media files, or if the media library contains a lot of media files, it is recommended to look for a
CMS with a good media library.
!he media library can resemble a file system with folders and files as in the Composite CMS,
but can also contain meta data that will aid when searching for relevant files. Some
organisations 0 mainly those with many content providers 0 will need the searchable media
library whereas others will 8ust need to set up a relevant category:folder structure so users
can browse for the relevant files.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
2*
C.4 3u.lish content
(requenc)A Baries )etween many times a day to wee-"y7 month"y or year"y
Su/?tas#s and ariations Solution e*ample Code
1. Set pu)"ish date and time
2. Set un6pu)"ish%e5piry date and time
3. Sa!e pu)"ished content item
4. (u)"ish to sta#in# ser!er
5. (u)"ish to production ser!er
C. Mana+e media li.rary
"or# areaA CMS )ac-end
StartA ;ser recei!es%co""ects one ore more media fi"es such as (01 documents7 pictures and !ideos7 to )e
a!ai"a)"e on the we)site
&ndA 1i"es are up"oaded
.sersA $dministrators7 editors and authors
(requenc)A Baries )etween many times a day to wee-"y7 month"y or year"y
Su/?tas#s and ariations Solution e*ample Code
1. ,ocate media fi"e on "oca" pc Browse functiona"ity
2. ;p"oad media fi"e to media "i)rary
2p. (ro)"emA ;p"oadin# many fi"es to the media
"i)rary one )y one is cum)ersome7 since they
ha!e to )e up"oaded indi!idua""y to set meta
data for each fi"e
Mu"ti6fi"e6up"oad form with fie"ds for meta data
3. Set meta data 1ie"ds for meta data in fi"e up"oad form
3a. BariantA dit meta data of a media fi"e which is
in the media "i)rary a"ready
4. Search amon# media fi"es in the media "i)rary
5. Show media fi"es in the "i)rary
+. Show which pa#es refer to a media fi"e
'. 0e"ete media fi"e
'p. (ro)"emA 3here are references to the media fi"e
from pa#es that wi"" either "in- to an non6
e5istin# fi"e <a dead "in-? or may refer in the
pa#e contents to a fi"e that is no "on#er
disp"ayed.
B"oc- de"etion and "ist pa#es usin# the fi"e
$""ow user to rep"ace the fi"e with another fi"e that
is su)sequent"y used on the pa#es instead
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3.
C.5 6in1 chec1in+
&inks referring to pages on external sites, uncontrolled by the organisation, can be outdated if
the external page is removed. ' periodical link check that checks whether links are still valid,
is often used to avoid dead links on the site. 9sually a CMS has some functionality, that
prevents the site from containing internal dead links *see C-)Eq+, but if this is not the case,
the link check should also include checking of links to internal pages.
C.5 6in1 chec1in+
9nterna" "in-s to and from a pa#e are usua""y chec-ed when the pa#e is sa!ed7 )ut e5terna" resources can chan#e
independent"y. 3herefore7 it can )e necessary to periodica""y chec- whether these "in-s are sti"" !a"id.
"or# areaA CMS )ac-end
StartA ;ser wants to chec- for dead "in-s or retrie!e an ear"ier "in- chec- resu"t
&ndA Site or su)6site without dead "in- or "ist of pa#es with dead "in-s par-ed for "ater resumption
(requenc)A Baries )etween many times a day to wee-"y7 month"y or year"y
$ifficultA Many pa#es with dead "in-s require editin#
.sersA ditors and authors
Su/?tas#s and ariations Solution e*ample Code
1. 1ind sa!ed "in- chec- resu"t "ist
2. Start "in- chec-
2p. (ro)"emA ;ser mi#ht on"y )e interested in
doin# a "in- chec- of a particu"ar part of the
site. $ site can contain se!era" thousands of
pa#es7 and a "in- chec- of the who"e site is !ery
time consumin#
,in- chec- on pa#e "e!e" or su) tree "e!e" of the
site structure
2q. (ro)"emA ,in- chec- is too sensiti!e7 and
considers "in-s to "ar#e fi"es as dead "in-s
3. 9t shou"d )e easy to find the pa#es with dead
"in-s
ach item in the "ist has a "in- to edit the pa#e
with a dead "in-.
3p. (ro)"emA ,in- chec- resu"t "ist disappears
e!ery time the user #oes to one of the pa#es to
correct dead "in-s.
4pen in new window
M&emem)erN "in- chec- resu"t "ist for when the
user returns
4. Sa!e "in- chec- resu"t "ist for "ater resumption
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
31
C.7 Mana+e site structure
Site structures change with time and one or more pages will be moved from one place in the
site tree to another. 'lthough it is not a daily recurring task, it can be time consuming if each
page has to be moved individually, if references are not updated automatically or if user
permissions are not handled automatically.
C.7 Mana+e site structure
"or# areaA CMS Bac-end
StartA $dministrator recei!es information a)out or#anisationa" chan#es% maHor chan#es to the we)site.
&ndA Site structure reor#anised
(requenc)A 0ai"y%Wee-"y%year"y depends of the num)er of sites
.sersA $dministrator
Su/?tas#s and ariations Solution e*ample Code
1. Create su)6site Su)6sites are first "e!e" pa#es in the pa#e tree
)e"ow the root
1p. (ro)"emA 9t is difficu"t to #et site o!er!iew ,ist sites and su)6pa#es in a tree hierarchy
2. Mo!e su)6site 0ra# and drop pa#es and su)6pa#es from one
p"ace in the tree to another
2p. (ro)"emA &eferences to and from other pa#es
ha!e to )e chan#ed to a!oid dead "in-s pointin#
to the su)6site that is now de"eted.
2q. (ro)"emA ;ser permissions mi#ht )e wron# after
a su)6site has )een mo!ed to another p"ace in the
site structure
3. Maintain user ri#hts and responsi)i"ities to su)6
site <see H.2 Security mana#ement?
4. Cotify responsi)"e for pa#es on a su)6site a)out
the chan#e in site structure
5. (u)"ish chan#es
5p. (ro)"emA ;ser cannot see chan#es from the
!isitor@s point of !iew )efore pu)"ishin#. With
maHor chan#es "i-e the mo!ement of a su)6site7
na!i#ation menus and other e"ements affectin#
the "ayout may chan#e7 too.
(u)"ish to sta#in# ser!er7 where chan#es can )e
seen in frontend !iew )efore pu)"ishin# to
pu)"ic ser!er
or a #raphic mode" of the chan#ed pa#e
structure
+. dit pa#e responsi)"e%contact information
+p 9t can )e difficu"t to ma-e chan#es in responsi)"e
contact information if it has to )e done on each
pa#e
Contact information stored centra""y I perhaps
in a separate modu"e I and referenced from the
pa#e.
+q. 9f a pa#e responsi)"e needs to hand o!er the
responsi)i"ities to another emp"oyee it is
unproducti!e if it is done pa#e )y pa#e
;pdate references centra""y7 rep"acin# with the
new emp"oyee
'. &emo!e su)6site consistin# of one or more pa#es
'p. (ro)"emA (a#es are referenced from other pa#es B"oc- de"etion and "ist referencin# pa#es
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
32
C.8 Mana+e newsletter types
'n organisation might have several newsletters that need to be managed. 9sers should have
the possibility of creating new newsletter types as well as changing the layout and name of an
existing newsletter.
C.9 Mana+e newsletter su.scri.ers
Managing subscribers from the CMS backend can be very useful. 1or instance when a
marketing campaign at an exposition yields a *possibly handwritten+ list of email addresses of
people interested in the organisation.
C.8 Mana+e newsletter types
$ news"etter type is a series of news"etters I e.#. the month"y promotiona" news"etter or the year"y Christmas
news"etter I that wi"" ha!e a num)er of su)scri)ers and information common to a"" news"etters sent with this
type7 such as su)Hect and sender address.
"or# areaA CMS Bac-end
StartA Cews"etter type is to )e added7 edited or de"eted
&ndA Cews"etter types are up to date
(requenc)A 162 times a year
Su/?tas#s and ariations Solution e*ample Code
1. ,ist news"etter types
2. Create news"etter type
3. dit news"etter type
4. 0e"ete news"etter type
C.9 Mana+e newsletter su.scriptions
Su)scri)ers to a news"etter can come from many sources. Many can su)scri)e direct"y from the we)site7 )ut at
trade fairs7 throu#h customer studies or simi"ar7 a "ist of new recipients can )e #athered7 which has to )e
manua""y imported.
"or# areaA CMS )ac-end
StartA 4ne or more emai" addresses are to )e added to a news"etter type
&ndA mai" addresses added to the news"etter type
(requenc)A(eriodica""y
.sersA ditors7 administrators
Su/?tas#s and ariations Solution e*ample Code
1. Su)scri)e recipient to news"etter type
2. 0e"ete recipient from a certain news"etter
3. Chan#e emai" address of recipient
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
33
C.1: Mana+e newsletter su.scriptions from front end
Subscribing and unsubscribing to a newsletter should be easy to do for a website visitor.
%owever, the subscription and unsubscription processes should be handled with care and
security so the customer can be safe in the knowledge that he is only sending out newsletters
to people, who have opted for it. Sending newsletters to people, who never signed up or who
have followed the unsubscription process is classified as =spam@ and it can be a costly affair, if
the organisation is fined for it.
C.1: Mana+e newsletter su.scriptions from frontend
"or# areaA 1rontend
Start7 ;ser wants to su)scri)e or unsu)scri)e to a news"etter
&nd7 ;ser su)scri)ed%unsu)scri)ed
(requenc)A ;serA 4nce a year7 SystemA 0ai"y)
.sersA Bisitors on the we)site
Su/?tas#s and ariations Solution e*ample Code
1. Su)scri)e to a news"etter
1p. (ro)"emA Bisitor mi#ht su)scri)e another
person@s emai" address or )e unsure whether the
su)scription is confirmed
Send su)scription confirmation emai" to user
2. Confirm su)scription Su)scription emai" contains "in- that the user
must fo""ow to confirm the su)scription
3. 0e"ete su)scription to a certain news"etter
3p. (ro)"emA Bisitor can unsu)scri)e another
person@s emai" address or )e unsure whether the
unsu)scription is confirmed
Send unsu)scription confirmation emai" to user
4. Confirm unsu)scription ;nsu)scription emai" contains "in- that the user
must fo""ow to confirm the unsu)scription
5. ,ist news"etter types with indication of whether
the user is su)scri)ed or not
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
34
C.11 Send newsletter
;e sure to confirm before sending a newsletter. Bewsletters are sometimes sent out to a huge
amount of subscribers, and there are often advertisers who pay to have their products in the
newsletters. "f the newsletter is not entirely ready, it gives the receivers an unfavourable
impression of the company and:or the advertisers.
C.12 Mana+e news
!he ability to display news is desirable by the ma8ority of organisational websites. "t can be
news about the company, the market, products available, new employees and much more. !o
really benefit from the versatility of =news@, articles should assigned to categories so it is
possible to pull a =latest news@)component with only press releases or only new employees,
relating the content to the context in which it is used.
Most CMS suppliers will be able to fulfil this task with a standard component.
C.13 Browse news
&isting too many news articles on a =&atest news@ page will only annoy the visitors, but
manually transferring articles to an archive is equally impractical to maintain. !he CMS should
in this standard component be able to only list a limited number of news in the various
categories and have a common interface with numerous search and filter options in a news
archive.
C. 11 Send newsletter
"or# areaA CMS )ac-end
StartA ;sua""y sent periodica""y7 for instance twice a wee-
&ndA Cews"etter sent or par-ed for "ater resumption
(requenc)A 4nce a day%wee-%month
.sers7 ditor7 author7 $dministrator
Su/?tas#s and ariations Solution e*ample Code
1. Create news"etter
1a. BariantA dit news"etter
2. 9nsert te5t
3. 9nsert media fi"es in news"etter
4. ;ndo chan#es
5. Send news"etter to recipients
5p Cews"etter can )e sent out )efore it is ready
+. Cews"etter shou"d )e appro!ed )y some)ody
e"se in the or#anisation )efore is can )e sent
'. Send test7 which sends the news"etter to one
emai" address on"y
/. (ar- news"etter for "ater resumption
*. 1ind par-ed news"etter for resumption
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
35
C.12 Mana+e news
Wor- areaA Bac-end
Start7 $ press re"ease7 new emp"oyee or simi"ar news is recei!ed )y the editor
&nd7 Cews story pu)"ished
(requenc)7 SystemA 0ai"y7 ;serA Wee-"y
.sers7 ditors
Content Solution e*ample Code
1. Create news story
2. dit news story
3. 0e"ete news story
4. 9nsert media fi"e
5. ;ndo chan#es ;ndo in the editor or ro"" )ac- to ear"ier chan#es
+. Sa!e and pu)"ish news story
C.13 Browse news
"or# area7 1rontend
(requenc)7 SystemA 0ai"y7 ;serA Wee-"y
.sers7 1rontend !isitors
Content Solution e*ample Code
1. Biew news o!er!iew (a#e with "atest 5 news "isted
2. &ead news story
3. Biew news archi!e
3p. (ro)"emA Cews accumu"ate to the thousands7
too many to disp"ay on one pa#e
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3+
C.14 ; C.1 Mana+e course enrolment and enrol to course
!hese two tasks are example tasks, connected to the data example in chapter 4.
C.14 Mana+e course e"aluation form
3his tas- is part of a custom inte#ration with an e5istin# course re#istration app"ication. See Chapter 0 for
descriptions of data.
Start7 2uestions need to )e added or remo!ed from a course@s e!a"uation form
&nd7 Chan#es sa!ed
(requenc)7 once a wee-
.sers7 ditors
Sub-tasks and variations Solution example Code
1% 'reate new question
1a% 6ariant7 .ocate and edit e,istin) question
2% 8et question type and answer options
!% 8ave question
4% $dd question to a speciic course
5% 9emove question rom a speciic course
#% Undo chan)es Undo in the editor or roll bac" to earlier version
7% *ublish evaluation orm
2% E,port replies to :icrosot E,cel ormat
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3'
C.1 0eply to course e"aluation form
3his tas- is part of a custom inte#ration with an e5istin# course re#istration app"ication. See Chapter 0 for
descriptions of data.
"or# area7 1rontend
Start7 Course participant wants to e!a"uate a course
&nd7 !a"uation finished
(requenc)7 SystemA 2.63. times a wee-7 ;serA 162 times per year
.sers7 We)site !isitors
Sub-tasks and variations Solution example Code
1% 6iew a list o courses
2% 6iew course evaluation orm
!% 9eply to evaluation orm
!p% *roblem7 6isitor evaluates a course he did not
participate in
.oo" up participant with username and password
in course enrolment system
!q% *roblem7 6isitor evaluates a course multiple
times
9e)ister that the user has evaluated the course%
!r% *roblem7 Users with database access can see,
who has )iven which reply
8ystem does not allow anyone to connect a
speciic evaluation to a speciic person
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3/
C.15 Search content
"f visitors cannot find the desired information, they go elsewhere. %aving an easy)to)use
search functionality can be vital to a website.
Most CMSs have basic search components, but real search engines are usually not a kernel
functionality in CMSs. Search engines are a rather large area with specialised search engine
suppliers, and performance and features vary from simple database searches to search index
engines with phonetic and synonym recognition that record searches without results. !he latter
type can come with a high price tag, but is very useful especially on legal and public authority
websites where the language used in the content can differ from the language used by the
visitors. %owever, a cheap solution will often suffice to begin with, while the customer
discovers the specific user requirements to a search engine. !he search engine is usually easy
to replace, so the choice of search engine is not tied to the choice of CMS. Bevertheless, a
good search engine is often a prerequisite for the website to become a success 0 especially if
the CMS is used for an intranet.
C.15 Search content
"or# areaA 1rontend
Start7 ;ser is "oo-in# for content
&nd7 Content found
(requenc)7 SystemA Bery frequent"y7 ;serA Wee-"y
.sers7 1rontend !isitors
Content Solution e*ample Code
1. Search for content with a search term
1p. (ro)"emA Search does not find terms inside
documents
Search inde5 reads (017 Microsoft Word and
401 documents
1q. (ro)"emA Search term is misspe""ed (honetic searches
Search inc"udes a "ist of common misspe""in#s and
their correct term
1r. (ro)"emA Search term has a synonym that is
used in content
Search for synonyms to the search term
2. Biew search resu"ts o!er!iew
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
3*
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
4.
2 2ata to present
!his chapter is about structured business data that should be presented on website pages. !he
data will be used by the CMS either by storing the data inside the CMS or by integrating with
other systems that contain the data already. !he tasks that are carried out in connection with
the structured data 0 from the frontend as well as from the backend should be described as
tasks in chapter C in the requirements specification.
!o manage these data, the developers need to know the data structure and how it should be
used and presented. !his is done in the tables with descriptions of necessary data and
information about where the data are currently stored. 1or these data, the customer is the one
with the domain knowledge, as opposed to other parts of the CMS, where the suppliers are the
experts. "t is usually a good idea to consult the users, who are going to use the pages, about
the procedures. ;e aware of the fact that it is very likely that users have exceptions from
official procedures, and this is impossible to handle by a system, unless the exceptions are
analysed thoroughly and accounted for in the system. !o avoid this kind of problems, be
careful that the system doesnt restrict the users unnecessarily, and be sure to ask the users
what they need for the system to become a success.
!he data should be presented on specially developed pages. "n order to ensure that the
supplier can deliver an appropriate solution, the customer should give as much information as
possible in data models. 'lternatively, the customer can provide mock)ups of pages containing
the data and let the implementation details be up to the supplier.
"f the same kind of data is used by other systems as well, it might be a better solution to
integrate with relevant databases or systems outside the CMS, since redundant data are hard
to keep consistent and lacks scalability. "ntegration with external systems is covered in chapter
1.
2ata e'amples
/rganisations often have data collected without really thinking of it as data. !he example in
the requirements template is an existing course enrolment application that should be extended
with a course evaluation functionality, accessible on the website.
7etting this information into structured form inside the CMS can make updating and looking up
information easier for everyone in the organisation as well as be of use to website visitors.
"t is important to describe the existing data in as much detail as possible since the supplier will
either build a new extension from scratch or try to apply the data to an existing extension with
or without modifications. "f the data are not thoroughly described, the supplier may think that
an existing extension can be applied and only late in the process discover that a new extension
or large modifications are needed that he has not included in the estimates.
!he data model in shape of E:# diagrams presents.
-. #elevant parts of the existing data, that are used in connection with an existing course
enrolment system
2. ' course evaluation system that should be developed and presented on the site. !his
diagram is an example of how the business data could be structured.
"f the data volume is very large, the supplier would have had to take it into consideration when
making time and price estimates, so the customer should give an estimate on current and
prospective volumes.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
41
2 2ata to present
3he customer needs the system to present data descri)ed in this chapter. 3he ta)"e )e"ow shows the data7 that
shou"d )e presented on different pa#es on the we)site. Besides presentin# the data7 the CMS shou"d pro!ide
functiona"ity to search7 create7 de"ete and edit the data as descri)ed in chapter C7 tas-s C.14 Mana#e course
e!a"uation form7 and C.15 &ep"y to course e!a"uation form.
3he CMS sha"" e5tend an e5istin# course enro"ment app"ication with course e!a"uations performed throu#h the
we)site. 3he course enro"ment app"ication is accessi)"e throu#h we) ser!ices supp"ied )y the customer.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
-llustration 27 $ata model for course ealuation
Course
name
description
"ocation
term
price
ma5Dparticipants
minDparticipants
enro"mentDstart
enro"mentDend
(erson
isDpaid
dateDenro""ed
hasDanswered
dateDanswered
02. question
03. type
name
04. option
password
"o#in
name
emai"
address
phoneD1
phoneD2
Came
2uestion
01. form
!a"ue
date
enro""edDin
05. rep"y
0+. answer
question
has
options
a form has rep"ies
a rep"y consists
of answers
a question
has a type
$n answer
)e"on#s to
a question
form has questions%
questions )e"on#s to forms
&*isting data
@ew data
teaches
has
42
2.1 %orm
'onnects questions to courses, speciyin) which questions should be as"ed in the evaluation o which courses%
;ote that a question can be re1used or several courses%
Data volume: #00, increasin) by 200 per year
;o ields, only orei)n "eys% &able is here to create one sin)le point o inte)ration with e,istin) data%
2.2 (uestion
Data volume: 400, increasin) by 100 per year
(ields and relations Solution e*ample Code
1% <uestion5+
2% ;ame, used or short identiication e%)% 5n loo"1
up lists when addin) questions to
questionnaires
!% <uestion in ull len)th
4% <uestion type, reerence to types
2.3 )ype
Data volume7 10120
(ields and relations Solution e*ample Code
1% &ype5+
2% ;ame, used or short identiication e%)% 5n loo"1
up lists
!% <uestion type, whether it is a )roup o
chec"bo,es or radio buttons, te,t ields or te,t
areas
2.4 <ption
8ome question types have i,ed options, e%)% 'hec"bo,es, radio buttons and drop1down selection lists
Data volume7 1000, increasin) by 200 per year
(ields and relations Solution e*ample Code
1% <uestion5+, reerence to questions
2% 6alue, i%e% the option te,t
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
43
2. 0eply
$n answer is the reply to one course evaluation
Data volume7 50 thousand, increasin) by 4 thousand per year
(ields and relations Solution e*ample Code
1% Form5+, reerence to orms
2% 9eply date
2.5 #nswer
$n answer o one question to one reply
Data volume7 200 thousand, increasin) by #0 thousand per year
(ields and relations Solution e*ample Code
1% <uestion5+, reerence to questions
2% 9eply5+, reerence to reply
!% 6alue, answer to the question
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
44
! <ther functional requirements
!.1 Comple' calculations and rules
,rocessing data in chapter 4 will often be straight forward relationships between data, but
there may also be calculations and rules that the system must obey, which only the customer
can supply. !hese calculations and rules could be the logic behind determining who are eligible
for discounts, which only the customer can decide.
!.2 3rint&outs= statistics and reports
4o not underestimate the use of prints. Even though we are in the age of digitalisation, prints
are often used at meetings, as reminders or to show friends and colleagues. Making sure that
the product descriptions, service offerings or similar can be printed on standard paper directly
from the browser will make the pages readable on printouts.
$hen it comes to visitor statistics, the customer will have to define what kind of statistics
reports are needed. !his is especially important if the organisations business goals is to
increase trafficF if the customer cannot get a report of weekly and monthly visits, he cannot
determine if the goal is reached. 'nalyse the needs and make report mock)ups 0 this will be
needed by the supplier as well as it gives the people, who are going to use the reports, an idea
of what to expect.
!.3 2ynamic content components
"n this table, you should input the components, you want to use on a page. !he content will be
managed centrally and =pulled@ into the page based on the configuration on the page.
1or example, news articles can be managed in a news module that allows content providers to
write articles in different categories. !hen, they can add a component with a list of the 6 latest
news articles 0 possibly confined to one category 0 and place it on any page in the system.
$hen a new article is added, the component is automatically updated on all pages, where it is
used, instead of content providers having to edit each page individually.
"n a customer organisation interview, we learned of a CMS implementation that allows for the
content provider to select a contact person for each page. !his persons contact details is
visible when viewing the page, letting visitors know how to contact the person responsible for
the page content. $hen a person leaves the organisation or responsibilities shift, all pages
connected to one person can be transferred to another contact person in one go, instead of on
each individual page.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
45
! <ther functional requirements
!.1 Comple' calculations and rules
(unction Solution e*ample Code
1% $ course evaluation cannot be viewed or
submitted beore the end o the course term
and not more than ! months ater the term
ends
!.2 3rint&outs= statistics and reports
9equirements Solution e*ample Code
1. $"" pa#es disp"ayed at the system front6end
must )e printa)"e on standard $4 paper
2. 3he system sha"" re#ister pa#e !iews and
!isitor statistics in a way so that the customer
can pu"" reports onA
a? Month"y !isitors
)? Month"y pa#e !iews
c? Sa"es%si#n6up transactions started
d? Sa"es%si#n6up transactions comp"eted
e? Bisitor paths throu#h the we)site
3. $"" reports must )e printa)"e on standard $4
paper
4% $ll course evaluation replies or a course shall
be possible to e,port to :icrosot E,cel ormat
5% 8tatistics on user activity in re)ards to pa)e
updates o these types7
a0 *a)e1centric= when were the pa)es updated
and by whom>
b0 User1centric= -hich pa)es have the users
updated in a speciied period>
!.3 2ynamic content components
3he customer wants to )e a)"e to add the fo""owin# content components on any pa#e in the CMS7 either as part
of the pa#e content or in predefined areas of the pa#e.
Components Solution e*ample Code
1. ;ser input forms with confi#ura)"e input fie"ds
and post6su)mit actions
2. Cews artic"e "ists7 "istin# tit"es of artic"es and
"in-in# to the fu"" te5t.
2a. BariantA ,ist 5 "atest news items
2). BariantA ,ist 5 most read items
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
4+
!.4 !'pansion of the system
CMSs are made to be expanded 0 or they should be. $ebsites on the "nternet have changed
enormously over 8ust a single decade and website owners are expected to explore new
possibilities and expand the use of their websites continuously. !herefore, being able to
expand the CMS with new content types, modules and dynamic components is a must)have
requirement for any CMS and a customer should be able to change certain things very quickly
or hire a third party to do so.
!he CMS itself can be closed source, but the source code of custom built extensions paid for by
the customer, should be available to the customer. "t should be possible to have other
developers extend the system, and therefore the customer needs access to a well)documented
'," for the CMS. /therwise the customer will in practice be dependent on the initial developer,
and that is usually not a good way of securing quality and reasonable prices.
!. Search en+ine optimisation
!he optimisation of a website to be found high in the lists of popular search engines is a
science of its own. !he CMS can be an obstruction to this process or it can be a facilitator, but
it will not be the sole answer to search engine optimisation. Many factors come into play, but
the most important ones relate to the actual content written by the content providers 0 i.e.
,eople outside the control of the CMS supplier. !he design can be structured properly, the CMS
can allow e.g. !itles on hyperlinks, set meta tags on the page and provide a page title, but if
the users do not set a proper hyperlink title, relevant meta tags and good page titles, all the
CMS offerings will bring few results. %owever, the CMS should not prevent users from setting
these and therefore, the requirements in this chapter are likely used to disqualify the poor
CMSs rather than to select the right one.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
4'
!.4 !'pansion of the system
3he customer or a third party hired )y the customer sha"" )e a)"e to e5pand the system without in!o"!in# the
supp"ier. 9n this section7 OcustomerO means his own 93 staff or a third party authoriEed )y him.
9equirements to the e*tension possi/le Solution e*ample Code
1. 3he customer can add new content types with
correspondin# mana#ement and output
$dd components7 e.#. #eneration or consumption
of &SS feeds
2. 3he customer can chan#e )eha!iour of
components and modu"es7 e%)% $dd unctionality
to send an email to a teacher, when a course
evaluation is submitted
dit%rep"ace components7 e.#. &ep"ace the
news"etter modu"e with another
3. 3he customer can chan#e "ayout of e5istin#
content types
Content types use temp"ates that can )e edited
throu#h the temp"ate mana#ement7 simi"ar to pa#e
temp"ates
4. 3he customer can use a we""6defined $(9 to
communicate with the core system. (refera)"y7
the CMS source code is a!ai"a)"e.
We""6defined means that e!erythin# that can )e
done )y an administrator can )e rep"icated
usin# the $(9.
5. 3he source code of a"" components constructed
specifica""y for this imp"ementation sha"" )e
a!ai"a)"e to the customer a"on# with de!e"oper
documentation. 3he customer sha"" ha!e the
ri#hts to use and modify )oth source code and
documentation.
!. Search en+ine optimisation
9equirements &*ample solutions7 Code
1. 3he system shou"d #enerate human reada)"e
;&,@s to we)site pa#es and interna" "in-s in
content
2. Search en#ines must )e a)"e to )rowse the site Site na!i#ation is functiona" without :a!aScript7
1"ash or other non6H3M, techno"o#ies
3. (a#e code structure is tar#etin# search en#ines H3M, code is structured with na!i#ation "in-s
first7 then the pa#e@s unique content7 then content
common for se!era" or a"" pa#es
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
4/
!.5 <ther functional requirements
1unctional requirements that are not directly involved with use tasks can be specified here.
!.5&1 /isitor accounts
9ser management through a directory service is an excellent tool to keep the "! departments
workload at a minimum, but when the site also allows visitors to register accounts, certain
considerations must be taken. 4o we want 8ust anybody into our directory service or should
internal users be managed separately from external users< %ow will the system distinguish
between them< Should internal users create external user accounts to participate in
discussions and use the internal account purely for other content management<
!here are many questions, so the requirements should specify in as much detail as possible,
what would be acceptable and what not.
!.5&2 -ser action lo++in+
&ogging the actions of users can be helpful to determine who has done what and when. "t can
be used for keeping an eye on users 0 are they updating the pages, they are responsible for< )
and it can be useful when investigating a breakdown or 8ust determining, who has added a
specific piece of content.
%owever, 8ust as with statistics gathering, the level of user action logging should be specified
as well as the filtering of data. Anowing exactly which part of the CMS backend is accessed by
which user can be useful at times, but usually only one users actions or one type of actions is
necessary and filtering for this will reduce the noise of, in this case, unnecessary information.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
4*
!.5 <ther functional requirements
9equirements &*ample solutions7 Code
1. Bisitors can create accounts and participate in
discussions7 mana#e news"etter su)scriptions
etc.
1p. (ro)"emA Bac-end users authenticate throu#h
,0$(7 !isitors shou"d not I )ut they shou"d )e
a)"e to participate in the same discussions
2. ,o# user actions with timestamp7 user name
and a description of the action when
6 a user is created7 updated or de"eted
6 a pa#e is created7 edited7 de"eted7 !iewed or
mo!ed
6 user su)scri)es%unsu)scri)es from news"etter
6 news"etter sent
3. ,o# ser!er errors7 e#.7
6 4.4 (a#e cannot )e disp"ayed
6 5.. Ser!er error
4. 3he system sha"" support content in mu"tip"e
"an#ua#es7 a""owin# easy trans"ation of pa#e
content into different "an#ua#es and "in-in# to
Mthis pa#e in Pother "an#ua#eQN when disp"ayin#
the pa#e.
5. Bac-end users can choose )ac-end interface
"an#ua#e
+. Cotify person set as responsi)"e for the pa#e7 if
a pa#e has not )een updated within 14 days
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5.
% System inte+ration with e'ternal systems
%.1 2irectory ser"ice
"f there are many users of the CMS, it might be a good idea to consider integration with a
directory service.
' directory service is basically a network based application, that contains information about
users and resources on a network. Examples of directory services are 'ctive 4irectory, Bovell
and e4irectory, and the information in these directory services is accessed with a protocol
called &4',
2
, and therefore integration with a directory service is also referred to as &4',
integration.
!he directory service is used to centrally manage users, resources, services and users access
to resources and services such as the CMS. !his means, that the user can use the same user
name and password to the CMS as to other systems that also use the directory service.
!he main benefit with &4', integration is, that users have only one user name and password
combination to remember and can change it once for all the systems authenticating with the
directory service. "t is often used in connection with single)sign)on where a user is granted
access to several systems as soon as he has locked on to the domain administered by the
directory service.
' directory service can have several domains, that reflect the geographical or organisational
structure of the organi(ation. 'n example could be a multinational cooperation, that has
affiliates around the world on different domains. "n this case each affiliate might have a sub)
site with locally relevant information communicated in different languages. "t might have its
advantages to let the website reflect the structure of the organi(ation, and grant some users
from each domain access to edit their sub)site.
2 &ightweight 4irectory 'ccess ,rotocol
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
-llustration 67 4$A8 integration ? same authentication to different s)stems
0irectory Ser!ice
Cetwor- "o#6on CMS
4ther authenticated
systems
,
o
#
i
n

R

e
n
c
r
y
p
t
e
d

p
a
s
s
w
o
r
d
$
c
c
e
s

#
r
a
n
t
e
d

%

n
o
t

#
r
a
n
t
e
d
2
1
,
o
#
i
n

R

e
n
c
r
y
p
t
e
d

p
a
s
s
w
o
r
d
$
c
c
e
s

#
r
a
n
t
e
d

%

n
o
t

#
r
a
n
t
e
d
2
1
,
o
#
i
n

R

e
n
c
r
y
p
t
e
d

p
a
s
s
w
o
r
d
$
c
c
e
s

#
r
a
n
t
e
d

%

n
o
t

#
r
a
n
t
e
d
2
1
,
o
#
i
n

R

e
n
c
r
y
p
t
e
d

p
a
s
s
w
o
r
d
$
c
c
e
s

#
r
a
n
t
e
d

%

n
o
t

#
r
a
n
t
e
d
2
1
,
o
#
i
n

R

e
n
c
r
y
p
t
e
d

p
a
s
s
w
o
r
d
$
c
c
e
s

#
r
a
n
t
e
d

%

n
o
t

#
r
a
n
t
e
d
2
1
51
% System inte+ration with e'ternal systems
3he CMS sha"" inte#rate to the fo""owin# e5terna" systems
1. ,0$( 0irectory ser!ice
2% ?oo)le $nalytics, website statistics )atherin) solution
!% 'ourse enrolment system
%.1 2irectory ser"ice
3he directory ser!ice is used to authenticate interna" users with the same username and password as in other
systems
-ntegration requirements Solution e*ample Code
1. 3he CMS sha"" authenticate users throu#h
,0$( in rea"6time
1p. 9f a user is de"eted in the directory7 the CMS
can sudden"y ha!e pa#es with a pa#e
responsi)"e that no "on#er e5ists
5nvo"e code in the ':8 when a user is deleted in
the directory, notiyin) relevant people about the
deletion%
%.2 #nalytics software & $oo+le #nalytics
?oo)le $nalytics )ather statistics on pa)e views and visitors
-ntegration requirements Solution e*ample Code
1% 9e)ister pa)e statistics in ?oo)le $nalytics $ll pa)es must include the ?oo)le $nalytics
@ava8cript code
%.3 Course enrolment system
&he course enrolment system can communicate throu)h web services or, i the ':8 is hosted at the customer,
direct database access to certain views in the Aracle database runnin) the enrolment system% 5 the ':8 is
e,ternally hosted, only web services are available% -eb services or database views will be created by the
customer to ulil the supplierBs requests%
5 the supplier provides a solution with a hi)her de)ree o inte)ration /1 is lower than 2 is lower than !0, he does
not need to provide a solution to a lower de)ree%
-ntegration requirements Solution e*ample Code
1% &he ':8 periodically replicates course
enrolment data
2% Users can initiate manual replication, when
needed
!% &he ':8 pulls data about courses, its teachers
and students rom the course enrolment system
in real1time%
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
52
%.2 #nalytics software
Statistics gathering is important, as can be read from the business goals in chapter ;.
'dditionally, website statistics can give valuable information on which content is read by
visitors, which pages are linked to from other websites and on which pages the visitors leave
the website. !his knowledge can be used to improve the website structure and content.
%.3 2ata.ase systems
9nte#ration with systems such as Ca!ision7 Sie)e" or S$(7 can )e of #reat !a"ue to the automation
of a we)site. 9t is a"ways )eneficia" to consider direct inte#ration with other systems rather than
inputtin# data into se!era" systems. 9f the we)site is asynchronous with the other systems7 data wi""
ha!e to )e updated in )oth systems7 thus dou)"in# the wor-"oad and ma-in# data "ess re"ia)"e.
%.4 ,nte+ration with new e'ternal systems
$hen integrating with other systems, the CMS can have the role as either the server where
other systems initiate functionality or the CMS exports data, or as the client where the CMS
imports data from other systems or initiates functionality in other systems.
!o facilitate the integration, it is also important to evaluate the developer documentation and
rights to data, ensuring that you 0 or someone you hire 0 can integrate other external systems
with the CMS and the data within the CMS without involving the supplier
%.4&3 2ocumentation and ri+hts
;eing =locked@ to only one vendor after the CMS acquisition is a risk that should, and usually
can, be avoided. Complete portability between different CMS systems 0 where content from
one can be automatically transferred loss)less to another 0 is unrealistic without customised
migration scripts or programs, but data should be stored in a standard database and the
database schema available, so data are always reachable with other tools than the CMS and a
skilled developer will be able to ascertain which information is stored in which tables.
$e recommend that you ensure that there are multiple consultants available for the CMS so
you have alternatives, should the first consultant suddenly increase prices, drop in quality,
become hard to reach or go out of business. %ealthy competition in the area of consultancy
services will only be of benefit to you as a customer.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
-llustration %7$ata/ase s)stem integration
$nother system CMS
$nother
data)ase
CMS
data)ase
0
a
t
a
0
a
t
a
0
a
t
a
0ata % data request
0
a
t
a
0ata % data request
53
%.4 ,nte+ration with new e'ternal systems
3he customer e5pects to inte#rate the CMS with other systems7 possi)"y usin# a third party consu"tant. 3he CMS
sha"" )e prepared for this inte#ration throu#h the fo""owin# requirements.
%.4.1 Ser"er role
S)stem interface in serer role Solution e*ample Code
1. 3he system sha"" )e a)"e to e5port data in a
format7 reada)"e to other systems
8tandardised e,port ormat
*lu)1in architecture or sendin) data
2. 1unctiona"ity in the CMS can )e tri##ered )y
other systems.
9t sha"" )e possi)"e to use an $(9 accessi)"e
from other systems to
6 Create a new or modify an e5istin# user
6 Create a new pa#e with content
6 (erform a search in the CMS@ search en#ine
-ebservice $*5, C:.19*' etc%
3. 3he data)ase is a!ai"a)"e for use )y other
systems
%.4.2 Client role
S)stem interface in client role Solution e*ample Code
1. 3he system sha"" )e a)"e to import data from
other systems and automatica""y create new
pa#es in the pa#e hierarchy.
8tandardised import ormat
2. 1unctiona"ity in other systems can )e tri##ered
)y the CMS7 e.#. Ca""in# a we)ser!ice and
processin# a rep"y
-ebservices, C:.19*' etc%
%.4.3 2ocumentation and ri+hts
$ocumentation and rights Solution e*ample Code
1. $(9 documentation shou"d document a"" areas
of the $(9 a!ai"a)"e to e5tensions and
components in a way so it is understanda)"e to
a third party
2. 3he customer or a third party appointed )y him
has a"" ri#hts to use the documentation and $(9
3. 3he customer ho"ds a"" ri#hts to a"" data stored
in the CMS
4. Content data are stored in a standard data)ase7
with connecti!ity throu#h standard data)ase
too"s7 ma-in# access to data a!ai"a)"e without
usin# the CMS
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
54
$ )echnical ,) architecture
$.1 Hardware requirements
$.1&1 !'istin+ hardware
"f the customer has hardware that he expects will be sufficient for running the CMS, he should
list the specifications and the supplier can reply with expected capacity of such a system.
$.1.&2 Hostin+
!he customer hosting the CMS will ensure physical access to the servers and complete control
of what is running on which servers. %owever, it also requires "! personnel with web server
management competencies to keep the servers secure and running.
%iring a data centre to host the CMS can outsource the need for web server managers in
exchange for less control with the physical servers 0 and perhaps a higher price.
/ften, CMS suppliers offer to host the CMS for customers. !he advantage of this solution is
that it will be hosted with someone, who knows the CMS very well and who can include CMS
security updates in the normal server maintenance procedures.
$.1&4 )est and de"elopment en"ironment
'dding new features, updating the CMS or changing the set up can be an intimidating task on
a production website with many risks ranging from misplaced images to server errors.
!herefore it can be useful or even necessary to have a range of servers for developing, testing
and staging these changes
Development server
!he server used by developers *in)house or external+ to develop new features, modules,
templates etc. Content is test content to test whether a feature works or a template looks
correct. Bot everything is finished and ready for deployment to the test server.
Test server
Server used by developers for testing whether developments work together with other
developments and to show changes to interested parties before deployment on the staging and
production servers.
Staging server
!his server is used by content providers to make changes to the content or site structure
without affecting the website visitors, until the changes are published to the production server.
Content should always be synchronised with the production server, barring the unpublished
changes.
Production server
Server *or several servers in a load balancing solution+ accessed by the website visitors.
1or organisations with large websites containing critical data or functionality vital to the
company, all of the servers mentioned in the requirements template are likely to be necessary.
1or others, only the production server. 1or most, a development and test server can be
combined into one and a good versioning and preview function can combine staging and
production servers.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
55
$ )echnical ,) architecture
$.1 Hardware and software requirements
3he customer current"y has the fo""owin# equipment7 to )e used in the CMS operationsA
1% 2 servers with these speciications %%%%
2% 100 :bps connection to the 5nternet
!% 4 Aracle database licenses
9equirements to hardware and software of the
customer
'ffered solution Code
1. 3he system is e5pected to run on e5istin# hardware7
comp"yin# with the requirements in ,.1 and ,.2
;nder these circumstances7 the system can
hand"e DDD hour"y pa#e "oads.
<3he customer e5pects DDD pa#e "oads?
2. With increasin# traffic and use7 the hardware wi""
need to increase7 too7 to comp"y with requirements in
,.1 and ,.2
1or each DD hour"y pa#e "oads7 the hardware
requirements increase DD to comp"y with ,.1
&esponse times
3. 3he so"ution sha"" )e hosted )y the supplier
4. $ testin# and de!e"opment en!ironment where new
and edited components can )e tested as we"" as new
desi#ns and other temp"ates can )e showcased to
interested parties.
$ test server is required with these
speciications7
%%%%
$ development server is required with these
speciications7
%%%
5. 4peratin# system requirements
+. 4ther software requirements
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5+
H Security
Somethin# that is ta-en for #ranted )y many CMS customers is the aspect of security. 9f considered
at a""7 emphasis is usua""y on accidenta" addin#%editin#%de"etin# of content )y users or unauthorised
access to the ser!er itse"f. Howe!er7 other areas shou"d )e forma"ised and considered proper"y.
H.1 #ccess ri+hts for users
$ )asic feature of any CMS is the a)i"ity to )"oc- off areas of the we)site from the eye of the
#enera" pu)"ic. Most nota)"y7 the administration )ac-end shou"d ne!er )e accessi)"e without proper
user authentication.
H.2 Security mana+ement
Managing users and their access rights should be targeting the "! department and
accommodate their wishes of easy user administration 0 possibly centralised through a
directory service as covered earlier.
Managing the permissions in the directory service is rarely available, but some CMSs have
synchronisation of user groups and user group memberships between the directory service and
the CMS, so defining the permissions on a user group basis allows for moving users in and out
of groups directly in the directory service management application, saving the "! department
from keeping user group memberships synchronised manually.
Should the requirements not include authentication through a directory service, it is important
to ensure that the user and permissions management is suited towards the number of users.
$ith many user accounts, it becomes a very large task to assign permissions to each and
every one of them or assign users to user groups individually.
"n chapter E.6, we suggested that the system should log user actions. %owever, for the
logging to hold real value for the users, there should be a way of reviewing and filter this log
so only data relevant to the reviewer is presented.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5'
H Security
H.1 #ccess ri+hts for users
Mana#e users7 ri#hts7 ro"es7 and responsi)i"ities
9equirements to securit) 'ffered solution Code
1. $ccess security7 ensurin# that on"y authorised users
access re#u"ated areas
1.p (ro)"emA ;sers use se!era" systems and for#et user
names and passwords if there are too many.
8in)le1si)n1on throu)h directory service
Access rights7
1. &i#ht to !iew pa#es
2. &i#ht to add%edit pa#es from a certain "e!e" and down in the document tree
3. &i#ht to de"ete pa#es )e"ow a certain "e!e" in the document tree
4. &i#ht to up"oad fi"es to the media "i)rary
5. &i#ht to edit or de"ete fi"es in the media "i)rary
+. &i#ht to use H3M, and :a!aScript in pa#e content editin#
$n editor mi#ht ha!e ri#hts 273747 whi"e a content pro!ider may ha!e on"y 273 and an administrator has a"" ri#hts
from 2 throu#h +.
H.2 Security mana+ement
3he wor- in security mana#ement inc"udes the fo""owin# su)tas-s.
$ifficult7 -hen 120 new people have been employed and need access ri)hts rom day one%
Su/tas#s for securit) management7 &*ample solutions7 Code
1. $ssi#n or remo!e access ri#hts for a user.
1a. BariantA 3he user must )e created.
1p% *roblem7 $ lot o users have to be created, e%)%
when they start the irst day in the month%
$utomatic transer o data rom the personnel
system%
2. Create new user ro"es
3. $ssi#n ro"es to a user
3.a BariantA $ssi#n users to a ro"e
4. $ssi#n permissions to ro"e
5. 8et an o!er!iew of who has which ri#hts and
whether some ri#hts ha!e not )een assi#ned to
anyone.
+. &e!iew user action "o# <see .5?
+p. (ro)"emA ;ser action "o# is fi""ed with data
a)out norma" or unimportant actions
$)i"ity to fi"ter "o# on user7 action7 time period or
simi"ar parameters
'. 0e"ete user
'p. (ro)"emA ;ser is responsi)"e for one or more
pa#es
$s- for rep"acement user to ta-e o!er
responsi)i"ities
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5/
H.3 3rotection a+ainst data loss
Measures protecting against loss of data should cover three situations.
-. !ransfer of data between servers or systems 0 ensuring that data are received correctly
before being purged from the sending system.
2. Concurrent use of the system by multiple users 0 protecting against corrupted data as a
result of several concurrent writes of the same item.
3. ,hysical damage to or theft of servers 0 protecting the servers from physical access by
unauthorised personnel, proper fire extinguishing measures and backup power supplies.
$hatever measures are taken, always be sure to test the backup and restore procedures
regularly 0 at least once a year 0 both to be certain that the backup and restore procedures
are working and to ensure that the responsible persons are familiar with them, so they know
what to do and how to do it properly.
H.3&1 )ransfer of data
!ransferring data from one system to another is always a situation to be cautious. Many
factors influence a proper data transfer, ranging from the physical condition of wires to the
other processes performed by the servers running the systems. !herefore, it can be resources
well spent, ensuring that data are transferred correctly, thus not ending in a situation where
data have been deleted in one system without being properly received at the other end.
H.3&2 Concurrency issues
$hen two users open the same page for editing at the same time and then save it, the CMS
can have difficulties determining which edition is the right one to use. Should it overwrite the
first with the second< 4isallow saving the second since the original has been changed< 4isallow
opening the second for editing while it is open for editing by someone else< Save the second
as a new version so the first is still available< Should some users have privileges that overrule
the restrictions<
!here are advantages and drawbacks with all the mentioned solutions 0 and for most
organisations it will be a non)existing problem. 9sually, site content responsibilities are divided
among users, who each have their area. "f the responsibility for a pages content is shared
among several users, they will usually work closely together and communicate about changes
to pages without the need for CMS enforcement of edit rules. %owever, an indication or
warning that a page is already open for editing, would facilitate the communication.
H.3&3 3hysical dama+e or theft
$eb servers should be kept protected from physical damage or theft 8ust like any other asset,
vital to an organisation. !his could be an argument in favour of using a hosting company to
host the physical servers, if adequate protection is not available at the customers location.
$hen the customer is not hosting the CMS it is particularly relevant to ensure that the data on
the servers belong to the customer and not the hosting company and that the customer
frequently receives back)ups of all data required to reproduce the website*s+ on another
platform.
H.4 3rotection a+ainst unintended user actions
Bo matter if a user is a long)time "! professional or has only 8ust found the power button of his
workstation, CMS users can perform actions that are not intended to be performed. #anging
from answering =yes@ instead of =no@ in a confirmation dialogue to editing the wrong page,
users can do the wrong thing and will need to undo it. %ow much can be undone and how it
can be undone is very different from CMS to CMS, but at no point should the system shut
down or otherwise malfunction from a regular users wrong click on a button. "f the users can
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
5*
also be certain that they cannot make functional mistakes like writing a date in a text field, a
number in a date field and text in a number field or that they can revert to a previous version
of a page, they will feel more secure with the system and less nervous of making mistakes.
H.3 3rotection a+ainst data loss
0ata may unintentiona""y )e "ost or misinterpreted.
,he s)stem must protect against7 &*ample solutions7 Code
1. ,oss or rep"ication of data transferred )etween
two systems7 e.#. )ecause one or )oth systems
c"ose down.
2. Concurrency issues7 e5. two users editin# the
same pa#e at the same time shou"d not resu"t
in data "oss.
3. ,oss of data7 )ecause of fire7 theft or hardware
fai"ure
(eriodica" )ac-ups
3p. (ro)"emA 3he )ac-ups can )e "ost if it is -ept
in the same "ocation as production data7
shou"d the "ocation suffer theft7 fire or simi"ar
physica" dan#ers
Store )ac-ups at different #eo#raphic "ocations
H.4 3rotection a+ainst unintended user actions
;nintended user actions mean that the user happens to do somethin# he didn@t intend to do7 e.#. hit the wron#
-ey or use a command that does somethin# he didn@t e5pect.
9equirements7 &*ample solutions7 Code
1. ;nintended user actions may not cause the
system to c"ose down7 neither on the c"ient nor
on the ser!er.
2. $"" data entered must )e chec-ed for format7
consistency and !a"idity. 9n case of dou)t7 the
user must )e warned and as-ed what to do.
3. Bersionin# shou"d )e a!ai"a)"e7 so users can
ro"" )ac- to a pre!ious !ersion
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+.
H. 3rotection a+ainst threats
Bot many consider 0 or have the knowledge 0 to ask questions to suppliers about the security
level of the CMS when it comes to SG& or code in8ections, allowing malicious users to make
changes to the database or run unauthorised code on the system. !herefore, it can be
beneficial to consult with a security expert to evaluate the security of prospective systems.
%owever, some aspects can be covered beforehand, by asking the supplier to specify certain
security measures.
H.&3 S(6 ,n>ections
,ages in a CMS are for the most part dynamically generated by looking at the users input
*accessed 9#&, parameters in the request+ and looking up the corresponding pages content in
the database. "f the input from 9#& and parameters is not handled correctly before being used
in a database query, malicious visitors may be able to include SG& syntax that will be
executed. !his could lead to discovery of passwords *another good reason to use a directory
service for authentication+, modification of content or change of user permissions, giving the
visitor administrator rights in the CMS.
' good CMS will ensure that all user parameters are handled as not)to)be)trusted and filtered
before being used in database queries.
H.&4 Cross Site Scriptin+ ?@SSA
Even if the CMS filters the user parameters to avoid SG& in8ections, the user submitted input
can still be of danger to the website and its visitors. Cross Site Scripting *abbreviated HSS to
avoid confusion with CSS 0 Cascading Style Sheets+ involves adding IavaScript code to the
user input, which will be executed by the visitors browser, when he visits the page with the
code. HSS attacks can result in cookies being stolen or redirecting the visitor to a malicious
site with even more malicious code to attack the visitors computer.
!his is mainly an issue for websites where visitors can contribute content, e.g. write comments
in a discussion forum.
!o avoid HSS problems, the CMS should escape the input so that it is not executed when
displayed on a web page. 'dditional measures could be logging HSS attempts and notifying
server administrators of the possible attack.
H.& Cross Site 0equest %or+in+ ?CS0%A
!he %!!, protocol used by web browsers to communicate with web servers is a state)less
protocol, meaning that each request sent by the browser will be handled by the server as if
there have been no previous requests. !herefore each request must contain all the information
needed by the web server to serve the correct page. !his also means that anybody can build
an %!!, request and send to a web server, which will handle the request based on the
information.
CS#1 attackers exploit this, by forging a request to look like it is coming from an authenticated
user, who is allowed by the server to perform actions, such as modifying content or granting
CMS access rights.
!he usual way to determine whether a request is genuine and part of a session for a logged)in
user, is to set a cookie on the users computer that will be sent along with the request.
,rovided that the malicious person has not stolen cookies through HSS or physical access to
the users computer, it is very difficult to know the cookie content to send with the request.
%owever, if the malicious person can somehow get the user to send the re'uest himsel!, the
cookie will be included and the attack may succeed.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+1
H. 3rotection a+ainst threats
$ ris- assessment has shown that the fo""owin# threats are serious. 3he system must protect a#ainst them.
,he s)stem must protect against7 &*ample solutions7 Code
1. ;nauthorised persons o)tainin# administrator
ri#hts trou#h the 9nternet <hac-in#?.
$dministration can only be accessed on the
internal networ" A9
$dministration can only be accessed rom a
whitelist o 5* addresses
2. Wire6tappin# of passwords. *assword encryption
88. encryption on lo)in pa)e
3. S2, 9nHection protection
4. Cross6site6scriptin# protection
5. Cross6site6request6for#in# protection
+. Session hiHac-in# *rivile)ed users cannot chan)e 5* address within
a session
'. Bisitors su)scri)in# or unsu)scri)in# other
peop"e@s emai" addresses to%from news"etters
<see chapter C.1.61p and C.1.63p
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+2
!here are several methods for a malicious person to trick the user into sending the forged
request.
-. "f the web server performs the desired actions with 7E! parameters *parameters sent
through the 9#&+, the attacker can merely add a link in a comment, hoping that a CMS
administrator will click on it or 0 if the comment system allows this 0 add an image with
the attack link as its source. $hen a CMS administrator clicks on the link or views the
page with the image, the 9#& will be invoked with a request from the administrator and
the web server will perform the desired actions.
2. "f the web server allows %!M& in the discussion comments, a malicious person can build
a web form, e.g. $ith an image as the =submit button@ and writing something along the
lines of =click on the image to see an enlarged version@, hoping that a CMS
administrator will do so, thus submitting the form.
3. "f neither option is available, the malicious person can build the attack form on another
website where an option is available 0 or his own, where he can add content without
restrictions 0 and then trick the CMS administrator into visiting the website and clicking
the link. !his is of course a very unreliable method for the attacker, but it happens
nevertheless.
,rotection against CS#1 attacks can consist of
Bever accepting database changes from 7E! requests 0 except logging and similar
actions.
4isallowing %!M& for website visitors or have a small white)list of accepted %!M& that
the visitors can use, filtering or escaping all other %!M&. Many websites allow no %!M&
but instead allows the use of so)called =bbcode@ where pseudo)code is transformed into
%!M& within very restricted limits.
Checking the %!!,D#E1E#E# property of the request. !his will contain the 9#& the user
is coming from. "f it does not come from the same web domain as the website, it can be
discarded. %owever, many software firewalls block this information to protect users
privacy, since it allows websites to register, where the user is coming from.
Ensuring that submitted forms include keys that a malicious user cannot know about
and incorporate in his attack forms. !his could be a randomly generated key saved in
the users session data *which is stored on the web server+ that is only valid for a
period of time and added to the form dynamically. $hen the form is submitted, the web
server can check to see whether the key is there and whether it corresponds to a key in
the users session.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+3
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+4
, -sa.ility and desi+n
9sability of the CMS is a decisive success criteria. !he usability has often been ignored,
because the focus has been on the usability of the CMS frontend, i.e. the website, or because
the customer does not know, what to look for when the CMS is chosen.
$hen choosing a CMS it is decisive to test the usability of the backend before contract signing
as described in chapter ;, while the usability of the frontend design can be tested after
contract signing. 's the design of the CMS backend is a basic part of the CMS, it is usually not
easily changed, and therefore the usability has to be evaluated before a CMS is chosen and a
contract signed.
' way of measuring usability, is to let a user carry out relevant tasks *chapter C+ and count
the number of critical usability problems and demand, that there may only be a certain
number of critical usability problems. !he definition of a critical usability problem is a problem,
where the user.
1. cannot carry out the tas- on his own
2. or )e"ie!es that the tas- is carried out e!en thou#h it is not
3. or e5presses that this is difficu"t7 rea""yS
4. or the test sees7 that the user does not use the system in an efficient"y manner
,a/le %7 Critical usa/ilit) pro/lems
!o perform a usability test, require that the suppliers show the backend from an existing CMS
solution, and perform think)aloud)tests with future users to find potential problems. !he think)
aloud)test should contain as many tasks from the requirements specification chapter C as
possible, as we have also described in chapter ; about proof of concept.
,.1 6earnin+ and efficiency in daily use
9sability is primarily about how convenient it is to use the system. !he typical users of the
backend are editors, administrators and authors. !o frequent users of the CMS, efficiency is
the most important usability factor, while ease)of)learning is the most important usability
factor to users, who seldom use the CMS. %owever, both usability factors are important,
because the bigger a site is, the more likely it is that the responsibility of different pages and
sub)areas are taken care of by many not)so)frequent users in an organisation, while the few
people overall responsible of the site use the CMS very frequently.
"f the backend is not logical or intuitive, it will be a problem especially to infrequent users. !he
result of poor usability can be that organisations give up distributed update, using only one or
two people to do all the editing. "f the CMS is not efficient, it is very inconvenient to frequent
users, who use the CMS as their primary work application. Either way, it will make the users
less motivated to use the CMS and thus less motivated to update the content frequently and
fulfil the ;.-)3 and ;.-)J business goals. !he ideal situation is that the CMS supports the
organisation rather than the organisation having to fit to the CMS, so it is a good idea to spend
time and resources to check the usability of different systems thoroughly.
/ften it is much easier to find =ease)of)learning@)usability problems than it is to find
=efficiency@)usability problems, because the =efficiency@)usability problems become visible only
to users, who have to do the same inefficient task 6> times a day.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+5
,.1 6earnin+ and efficiency in daily use
9t is important that the system o)tains adequate usa)i"ity. 3his is )est done throu#h ear"y usa)i"ity tests. $fter the
ear"y tests7 customer and supp"ier Hoint"y decide the detai"ed requirements to )e !erified at the time of system
de"i!ery. 9t may for instance )e a detai"ed specification of the tas-s to )e tested7 and the acceptance criteria to
write in the midd"e co"umn.
.sa/ilit) test of proof of concept &*ample solutions7 Code
1. 3he supp"ier must test the user interface for
usa)i"ity )efore si#nin# the contract.
;sa)i"ity testin# <thin-in#6a"oud testin#? is carried
out for e5istin# parts of the system in a suita)"e
setup.
2. 3he most serious usa)i"ity pro)"ems must )e
corrected unti" usa)i"ity testin# #i!es
accepta)"e resu"ts. 9n addition the parties must
a#ree on the detai"ed usa)i"ity requirements.
1or parts that don@t e5ist yet7 thin-in#6a"oud testin#
is done with paper moc-ups. 3hree new users
participate in each round of testin#.
3. $fter a short instruction )y super users7 the
ordinary users must )e a)"e to carry out a""
tas-s in Chapter C within their own wor- areas
without critica" usa)i"ity pro)"ems.
Within each wor- area7 thin-in#6a"oud testin# is
done with DDD ordinary users. $ ma5imum of DDD
critica" usa)i"ity pro)"ems may )e o)ser!ed.
4. rror messa#es must )e understanda)"e and
he"pfu".
0urin# the usa)i"ity test7 a se"ection of error
messa#es is shown to the user7 who tries to e5p"ain
what the messa#e means and what to do a)out it.
DDDT of the e5p"anations must )e accepta)"e.
5. Super users must )e a)"e to "earn the system
quic-"y so they can train other users.
3rainin# of a super user ta-es DDD days. <3he
customer e5pects D days?.
+. $ user who has used the system for a wee-7
must )e a)"e to quic-"y create a new pa#e and
add content
$ typica" user is a)"e to create a pa#e with te5t and
ima#es in DD minutes.
'. ;sa)i"ity of consu"tant6de!e"oped interaction7
ie. user test of data !iew and functiona"ity at
the frontend of the CMS
Within a"" consu"tant de!e"oped interaction
modu"es7 thin-in#6a"oud testin# is done with DDD
ordinary frontend users. $ ma5imum of DDD
critica" usa)i"ity pro)"ems may )e o)ser!ed on
each modu"e.
/. asy access to CMS6)ac-end Sin#"e si#n6on I 9f the CMS is inte#rated with a
directory ser!ice7 there wi"" )e access to the CMS
as soon as the user has "o##ed on to the domain
accordin# to their permissions
3his can )e done within DDDdays.
*. asy access to intranet Sin#"e si#n6on.
M&emem)er meN functiona"ity.
9f the CMS is inte#rated with a directory ser!ice7
there shou"d )e access to the intranet as soon as the
user has "o##ed on to the domain.
3his can )e done within DDDdays.
1.. Consistent desi#n of functiona"ity. 1or
instance7 a @sa!e@ or an @edit@ )utton or menu
shou"d )e a"i-e7 no matter if it is a temp"ate or
a content item that is )ein# sa!ed or edited.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
++
1or instance, we have interviewed a user who frequently publishes a lot of content items on a
large website. Every time he presses publish, he has to wait about -> seconds while the
pages are being published, without being able to do anything in the meantime. 'part from that
the system can either publish a single content item or publish all unpublished content)items.
$hen the user publishes e.g. 55 out of K6 unpublished content items, he can only do it one by
one and each time wait at least -> seconds. !his is inconvenient as well as time consuming. 'n
additional problem is the preview functionality that does not look exactly like the published
content item. !herefore the user actually has to publish every time he makes small changes, if
he needs to see how it really looks. !his is especially relevant on the frontpage of the website,
where line breaks have to be controlled and text has to fit into different boxes on the page.
!hese are typical efficiency usability problems that are often not noticed in time and reduce
efficiency and flow in daily work tremendously. !herefore it is recommended to pay special
attention to the problems, that are connected to the different tasks in chapter C when carrying
out usability tests as well as to specify usability tests with enough volume to test the
efficiency.
,.2 #ccessi.ility and 6oo1&and&feel
!he CMS backend is usually not optimised towards visually or otherwise impaired people, while
the accessibility to the frontend to some extent can be supported or restrained by the choice of
CMS. !his is a large sub8ect, with many different approaches to linking, titling, content
organi(ation and rapid navigation, as well as generation of multiple sites optimised towards the
special browsers used by people with different kind of impairments. !herefore the accessibility
requirements might not be satisfactory, and if accessibility is a critical issue, where it isnt
enough to follow an accessibility standard such as $'", it is necessary to consult an expert in
this area.
Many CMSs attempt to exploit the general users familiarity with applications such as Microsoft
$ord by creating page text editors with a similar toolbar layout as Microsoft $ord. 1amiliarity
with known programs, usually makes them easier to learn and remember, but as such a
familiar look is not always followed by familiar functionality, and if that is the case, the user is
better off without the familiarity.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+'
,.2 #ccessi.ility and 6oo1&and&feel
Accessi/ilit) requirements Solution e*ample Code
1. We) pa#es must )e suited for screen readers7
sca"in# to !isua""y6impaired users7 and uti"isin#
the fu"" screen siEe on sma"" as we"" as "ar#e
screens.
3he pa#es fo""ow the H3M, #uide"ines for
$ccessi)i"ity <WC$81. from W3C?.
1a. BariantA $"ternati!e te5t in connection with
pictures7 so that the screen reader has
somethin# meanin#fu" to read
CMS supports or e!en forces the user to type in
an a"ternati!e te5t to the picture
1). BariantA Chec- for comp"e5ity of "in- names
for the sa-e of disa)"ed who use screen readers
8i!e a warnin# if for instance a "in- is ca""ed
@here@7 "i-e in @&ead more a)out S4$ here@ which
ma-es it difficu"t for a !isua""y impaired to Hump
from "in- to "in-7 and #et any meanin# out of it.
9nstead it shou"d say @&ead more a)out the su)Hect
in the artic"e a)out S4$@
1c. BariantA asi"y adHust font siEe for )etter
reada)i"ity
1d. BariantA 9nput fie"ds shou"d )e connected to
their tit"es out of consideration for screen
readers
3it"e "a)e" for input fie"ds
2. ;ser interface shou"d )e fami"iar to most users
2p. 1ami"iar "oo- is not a"ways fo""owed )y
fami"iar functiona"ity and the fami"iarity is
confusin# rather than an ad!anta#e.
4n"y use fami"iar icons when they perform
compara)"e actions as in the pro#ram or operatin#
system they are )ased on.
3. 9t shou"d )e easy to na!i#ate in the CMS
)ac-end
9n a usa)i"ity test7 users sha"" )e a)"e to "ocate a""
functiona"ity re"e!ant to their tas-s without any
critica" pro)"ems.
4. 3he interface sha"" pro!ide the user with
enou#h information so that he can determine
how a pa#e wi"" "oo- when pu)"ished
WUS9WU8 <What Uou See 9s What Uou 8et?
editor7 where content is disp"ayed with the
formattin# as e5act"y as it wi"" "oo- on the front
end .
ditor surrounded )y content as it is on the front
end
3here cou"d )e an easy and fast pre!iew function7
where the front end pa#e is "oaded with the edited
content.
5. Mo!in# content in pa#e hierarchy shou"d )e
easy and intuiti!e
*a)es should be movable by dra))in) and
droppin) a pa)e with all sub1pa)es or mar"
pa)es to move and selectin) the destination

3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+/
B <ther requirements
B.1 Standards
Concerning requirements to follow standards, it is important to be specific and have some
background knowledge. Some CMSs use accessibility standards compliance *$'")compliant+
as a sales parameter, even though many of the requirements in this standard are virtually
impossible to enforce by the CMS. !he CMS can enforce an alternative text to images and title
properties on hyperlinks, but the $'" standard says that these texts and titles must be
meaning!ul, which 0 so far 0 no computer can determine reliably. !herefore, the requirements
specification should include specific requirements dealing with these standards rather than 8ust
state that they must be followed *See ".2 in the requirements specification template for
examples of requirements related to the $'" accessibility standard+
B.2 )rainin+
!he easier the CMS is to use for a common user, the easier it will be to return to the CMS after
a break or to include many users in different areas of the organisation, so pay attention to the
9sability parameters *see chapter " 9sability and design+
$ith increasing complexity of the CMS, the need for training the users and administrators also
increases. !he availability of courses from the CMS supplier or a third party can be an
important factor in choosing the right CMS.
B.3 -ser 2ocumentation
4ocumentation is equally important for the user training. 7ood documentation of an easy)to)
use CMS may even eliminate the need for formal training, although it should not be expected.
!he documentation should be sufficient so that.
-. Superusers can train other users.
2. Superusers have a reference guide for all functionality available to them.
3. 'ny competent third party can read documentation and learn enough to extend the
system.
1urthermore, documentation should be machine readable so it can be electronically adapted
and redistributed. !hat way, the customer can make his own documentation that for instance
not only explains how to perform actions, but also related company policies or common
mistakes.
B.4 2ata con"ersion and import
/ften, the organisation will have a website already, and desire to quickly import the contents
of this into the CMS. #equirements to import functionality should be listed here.
"mporting data can be a large implementation task and therefore it should be very well
established, how this import can occur. !he customer should decide on using formats that
explain the data thoroughly, using standardised formats wherever possible.
#emember 0 importing takes time. "f K>>> pages are to be imported from an old website,
these pages will need to be validated to ensure that they are correctly imported. "f they also
need some manual processing, -6 minutes per page amounts to -6>> hours that should be
included in the manpower calculations.
B. ,nstallation
!his chapter establishes the formalities surrounding who installs which parts of the solution.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
+*
B <ther requirements and deli"era.les
B.1 <ther standards to .e followed
9equirement Solution e*ample Code
1. (a#e output sha"" comp"y with the standards in
<V?H3M, version 1%0 strict
2. CSS fi"es sha"" comp"y with the standards in
W3C@s CSS standards
B.2 )rainin+
9equirement Solution e*ample Code
1. 3rainin# needed to )ecome superuser of the
system
2. 3rainin# needed to )ecome re#u"ar )ac-end user
of the system
3. 3rainin# needed to use the system after a period
of a)sence I trainin# performed )y a superuser
4. 3rainin# needed to administrate the system
5. 3rainin# needed to e5tend the system
B.3 -ser 2ocumentation
9equirement Solution e*ample Code
1. Course materia" sha"" )e a!ai"a)"e for
superusers for trainin# other users at least one
month beore trainin) be)ins
2. 0ocumentation of a"" user functiona"ity sha"" )e
a!ai"a)"e to superusers
3. Custom de!e"oped code must )e documented
sufficient"y for a third party to de!e"op it further
4. 0ocumentation must )e machine reada)"e and
the customer must ha!e permission to use and
modify it7 ena)"in# the customer to impro!e the
documentation or modify it to ref"ect the
customer@s specific ru"es and processes.
B.4 2ata con"ersion and import
3he supp"ier sha"" perform the import of data from the fo""owin# systemsA
9equirement Solution e*ample Code
1% 5mport data rom old course evaluation
application% +ata will be available in an C:.
ormat, described in $ppendi,%%%
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'.
B. ,nstallation
3his chapter specifies7 who insta""s which components I hardware as we"" as software I and who imports data
from other sources.
9equirement Solution e*ample Code
1. Cew hardware sha"" )e insta""ed at the
hostin# "ocation
8upplier installs new hardware
2. 4peratin# system and software sha"" )e
insta""ed
'ustomer sets up server operatin) systems, web
servers, F&* servers and database servers
3. CMS sha"" )e insta""ed and confi#ured 8upplier installs and coni)ures the ':8 to
production setup
4. 0ata sha"" )e imported as descri)ed in :.4 8upplier imports data
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'1
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'2
C Customer deli"era.les
!he implementation pro8ect is not a one)sided affair. "n order for the suppliers to deliver a
good solution, certain practicalities must be handled by the customer organisation.
-. %ardware 0 physically procuring the required hardware, allowing time for delivery
delays, is the customers responsibility, unless the desired solution involves hosting by
the supplier or another third party.
2. /ffice space 0 even consultants have to sit somewhere, preferably in a close proximity
of the customer organisations pro8ect team members.
3. ,roduction data samples 0 4emonstrations and dummy data can aid in development,
but production data ensure greater resemblance to the end solution.
5. !est cases 0 Supplying test cases so the supplier can test the solution.
6. !est sub8ects for usability tests 0 1uture users of the system must be allocated time to
perform usability tests, even if it interferes with their daily tasks.
K. ,ro8ect team members 0 !o ensure good communications between customer and
supplier, at least one pro8ect leader from the customer organisation should be available
to the supplier. 4epending on the pro8ect si(e, needs can range from a part)time
contact person to several full)time positions, working with the supplier to evaluate
development, answer questions about processes etc.
E. Superusers 0 Superusers must be trained in the CMS sufficiently to pass their
knowledge on to other users.
C. Lalidation of converted data 0 !he supplier may not be able to properly validate that
converted data have been converted correctly and resources from the customer
organisation should be allocated to ensure correct conversion.
J. Contributions to course material 0 7iving feedback on course material can help the
supplier improve the quality, benefiting both the customer and other users of the CMS.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'3
C Customer*s deli"era.les
3he fo""owin# "ist of the customer@s de"i!era)"es and ser!ices must )e e5hausti!e. 3he supp"ier cannot e5pect
more. 9f necessary7 the supp"er must add to the "ist in his proposa".
3he customer de"i!ersA 5amp"e so"utionsA Code
1% Dardware, sotware, and e,ternal systems that
the ':8 system requires /see the details in
'hapter ?0% &he equipment must be available
when the installation test starts%
C%$
2% Aice with three 5& wor" places rom one month
beore the planned installation test to one month
ater system delivery%
C%$
!% 8amples o production data or testin) purposes
and the ull data set or conversion%
C%$
4. 3est cases for dep"oyment testin#. C%$
5. 3est su)Hects for usa)i"ity tests. C%$
#% $ hal1time proEect mana)er and a hal1time
secretary%
C%$
'. Super users%instructors who "earn the system in
order to train ordinary users.
C%$
/. 5pertise for !a"idation of con!erted data. C%$
*. Contri)ution to the course materia" on future
wor- processes <cf. :361?.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'4
6 <perations= support and maintenance
6.1 0esponse times
4efining fair requirements in the area of response times is a difficult task since many factors
come into play with web servers. !he number of visitors and subsequent strain on web server
and database server as well as latency and physical distance between content providers and
the web server can all have negative effects on the response times of the system. %owever,
the CMS should provide measures to ensure that the most used tasks are performed as quickly
as possible without too much going on in the background, affecting the response times.
' possible solution to lowering the response times is a caching solution. $hen the content on a
web page is the same for everyone visiting at all times, pre)publishing, where a page is saved
in a generated form and subsequently delivered directly and only updated when the page
content is changed, should be possible. 1or dynamic content that pulls information from other
systems, a time)based caching will most certainly help cope with peak situations with many
concurrent visitors.
Most CMSs include some kind of internal caching mechanism, generating a page once and
keeping the generated output for a certain time period to serve it to new visitor requests
instead of regenerating it on every request. %owever, there are also other solutions available,
called reverse proxy caching solutions, where the web server *or an extension hereof+ does the
caching and serving without executing CMS code at all.
Baturally, serving a complete page to several visitors will only work well, if the page for visitor
- is identical with the page for visitor 2. %ence, if the website has visitor login and visitor
specific information available, caching the entire page and serving it to other visitors will not
work. "n those cases, the CMS will be required to cache the common parts and leave the
visitor specific parts uncached.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'5
6 <perations= support and maintenance
6.1 0esponse times
3he system "oad !aries throu#h the day and wee-. &esponse time is particu"ar"y important durin# the )usiest
hours7 the pea" load periods.
8ea# load
1% 100 users wor" with the content mana)ement bac"end%
2% 1000 visitors browse the rontend%
Measuring response time
3he response time is the period from the user sends his command to the resu"t is !isi)"e and the user can send a
new command. $ command means su)mittin# a form or fo""owin# a hyper"in-.
Measuring generation time
3he #eneration time is the period from the ser!er recei!es a request to the processin# is finished and the response
sent to the user.
9n the )ac-end7 measurements wi"" )e response times7 whereas for frontend pa#es7 the #eneration time is
measured7 since the supp"ier is not responsi)"e for the amount of content and #raphics on frontend pa#es. $""
measurements are made durin# pea- "oad. 3he specified times must app"y for *5T of the response times in these
periods.
8roduction wor# through local area networ#7 Measurements are made with a setup correspondin# to the dai"y
operation.
,he pu/lic we/ part7 Measurements are made on a (C connected to the 9nternet throu#h a 5+ GB modem with
"ow traffic on the route to the ser!ers7 )ut pea- "oad of the ser!ers themse"!es.
9t is important that response is so fast that users are not de"ayed. 3he fo""owin# requirements aim at that.
9esponse time requirements7 &*ample solutions7 Code
1. (a#e response and #eneration time
measurements must )e performed re#u"ar"y.
&he system measures pa)e )eneration times
continuously%
1requent response time measurements are
performed with a stopwatch
2. 8eneration time for a frontend pa#e 8eneratin# a frontend pa#e ta-es DD seconds
3. ,oadin# time for a )ac-end pa#e ,oadin# a )ac-end pa#e comp"ete"y from within
the "oca" networ- ta-es DD seconds
4. 3ime for sa!in# a pa#e Sa!in# a pa#e ta-es DD seconds
5. 3ime for pu)"ishin# a pa#e to production
ser!er
(u)"ishin# a pa#e ta-es DD seconds
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'+
6.2 #"aila.ility
!o avoid different opinions on how to define availability, the customer can write his definition
and expectations to availability values. "t should be considered, how a breakdown is defined,
based on the consequences of a breakdown of various lengths. 1or a very well visited website
with many updates every day, a 2> minute breakdown can result in bad publicity, missed sales
and employees without access to their everyday work tool. 1or a small website with weekly
updates, a 2 hour breakdown can be a nuisance without further effects on the revenue.
6.3 Support
9ser support can benefit from standardised systems in the way that some CMS developers
have user support hotlines for any user in any customer organisation with a support
agreement. !his means that much of the load is taken off the shoulders of the consultants,
who specialise in developing and implementing the system and usually are not interested in
end)user support, and off the shoulders of super users within the customer organisation.
Baturally, some support must be given by the consultants, especially when it comes to
customised or custom developed functionality, but the =how do " insert a hyperlink:an image
on a page<@)type of questions can be handled by the centralised phone support.
6.2 #"aila.ility
3he system is out of operation when it doesn@t support some of the users as usua". 3he cause of the )rea- down
may )eA
1. 3he customer@s issues7 e.#. errors in the customer@s equipment.
2. 5terna" errors7 e.#. power fai"ure.
3. 3he supp"ier@s issues7 e.#. errors in software or a wron# confi#uration.
4. ("anned maintenance.
5. 9nsufficient hardware capacity.
Measuring aaila/ilit)
$ )rea- down is counted as at "east 2. minutes7 e!en if norma" operation is resumed )efore. 9f the fo""owin#
period of norma" operation is "ess than +. minutes7 it is considered part of the )rea- down period.
Anly brea" downs caused by the supplierBs issues are included in the availability statements%
3he operational time in a period is ca"cu"ated as the tota" "en#th of the period minus the tota" "en#th of the )rea-
downs for which the supp"ier is responsi)"e. 3he aaila/ilit) is ca"cu"ated as the operationa" time di!ided )y the
tota" "en#th of the period. When on"y some of the users e5perience a )rea- down7 the a!ai"a)i"ity may )e
adHusted. 4ne way is to ca"cu"ate the a!ai"a)i"ity for each user and ta-e the a!era#e for a"" users.
Aaila/ilit) requirements7 &*ample solutions7 Code
1. 3he a!ai"a)i"ity must )e stated re#u"ar"y. 3he
statement may compensate for the num)er of
users e5periencin# )rea-downs.
2% 5n the period rom 2700 to 12700 on wee"days,
the system must have hi)h availability%
9n these periods the tota" a!ai"a)i"ity is at "east
DDDT.
<3he customer e5pects **T?.
!% 5n other periods the availability may be lower% 9n these periods the tota" a!ai"a)i"ity is at "east
DDDT.
<3he customer e5pects *5T?.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
''
6.3 Support
Support comprises he"p to users7 monitorin# the operation7 and confi#uration mana#ement. 3he specified times
must app"y for *5T of the cases. Super users are the ordinary user@s first point of contact. 3his means that the
supp"ier on"y has to he"p when the super users cannot remedy the pro)"em.
Support requirements7 &*ample solutions7 Code
1. 3he supp"ier must he"p the super users when
they cannot remedy the pro)"em themse"!es.
He"p co!ers a"" equipment and software
pro!ided under this contract.
1p. (ro)"emA Super users cannot decide which
product a specific pro)"em re"ates to. 9t is e!en
harder to mediate )etween se!era" supp"iers.
3he supp"ier in!o"!es the necessary other parties
on his own initiati!e.
2% 5n the period rom 2700 to 12700 on wee"days,
super users can quic"ly )et phone contact with
the supplierBs support or)anisation%
5n this period, contact is available within ((
minutes% /&he customer e,pects 10 minutes0%
3. Whether the pro)"em is recei!ed )y phone or
emai"7 the supp"ier wi"" rep"y quic-"y. 3he
rep"y is he"p to the super user unti" the
pro)"em is remedied7 or a decision that it is a
system defect.
&he supplier replies within (( hours in the period
rom 2700 to 12700 on wee"days% /&he customer
e,pects (( hours0%
4. 9n case of a system defect7 the supp"ier wi"" as
far as possi)"e he"p the super user circum!ent
the pro)"em7 and in addition report the defect
to the maintenance or#anisation.
5. 3he supp"ier sends a support person when this
is necessary to remedy the pro)"em.
+. 3he supp"ier can perform remote dia#nostics
to remedy the pro)"em.
'. 3he supp"ier records data that a""ows
computation of support response time7 as we""
as data for identification and pre!ention of
frequent pro)"ems.
3he supp"ier -eeps a "o# of a"" requests from super
users with indication of the pro)"em cause and the
time when the pro)"em had )een remedied.
/. 3he supp"ier monitors the operation in order to
foresee a!ai"a)i"ity pro)"ems7 and ta-es steps
to chan#e the technica" confi#uration so that
a!ai"a)i"ity is maintained.
*. Supp"ier pro!ides a sin#"e contact for the
customer.
1.. Customer is informed re#u"ar"y a)out the
status of pre6paid support or the outstandin#
)a"ance
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'/
6.4 Maintenance
$hen consultants customise the CMS to the organisation, it is essential to have clear
established agreements that say that the consultants have to see the pro8ect out and correct
errors that comes with it.
'dditional modules or modifications naturally have to be paid for, and when new modules or
functionality are bought, it is important to have a developer that you have confidence in, when
it comes to development time, costs and quality. 9sing a standard method for estimating a
pro8ects si(e, and arranging a fixed price per estimation unit, can give the customer a way to
include new developments in the yearly budgets. !he requirements template uses function
points, because it is based on transactions and user interaction, but there are several
estimation methods available for the customer to choose from.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
'*
6.4 Maintenance
Maintenance inc"udes defect remo!a" and system chan#es. 3he specified times must app"y for *5T of the cases.
9equirements for defect remoal7 &*ample solutions7 Code
1. 3he supp"ier -eeps a "o# of reported defects as
we"" as chan#e requests.
2. 1or a"" reported defects7 the supp"ier quic-"y
assesses whether the defect is )usiness critica"7
possi)"e to circum!ent temporari"y7 or
possi)"e to circum!ent permanent"y <i.e.
reHect?.
5n the period rom 2700 to 12700 on wee"days, the
supplier completes the assessment within ((
hours% /&he customer e,pects (( hours0%
3. Business6critica" defects are remo!ed quic-"y. Business6critica" defects are remo!ed within
DDhours. <3he customer e5pects DD hours?.
4. Customer and supp"ier meet re#u"ar"y to chec-
the defect assessments7 and to decide what to
repair or chan#e7 and what it wi"" cost.
3he parties meet e!ery DDDD.
<3he customer e5pects DD"y meetin#s?.
9equirements for s)stem improement7 &*ample solutions7 Code
5. 3he supp"ier insta""s new !ersions and re"eases
of the de"i!ered software without undue de"ay.
9nsta""ation ta-es p"ace within DDD days after
re"ease of the new !ersion or re"ease.
<3he customer e5pects DD days?.
#% -ithin a period o (( years, the supplier must
oer chan)es at a i,ed cost per unction
point%
&he price per unction point is (((( U8F%
7% +isa)reement on the unction point
calculation must be resolved by % % %
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?
/.
3 $lossary
CMS Content management system.
Consultants Company implementing a CMS for a customer or aiding a customer selecting
the right CMS.
Content item "n some CMSs it is possible to publish 8ust a small part of a page, in other
CMSs it is the whole page that is a content item.
C/!S Commercial /ff)!he)Shelf, a standardised software product that can be
*imagined+ packaged in a box and put on a shelf in a computer shop.
Customers CMS buying organisation
4evelopers Company developing a CMS
&4', &ightweight 4irectory 'ccess ,rotocol. ,rotocol used for authenticating users
through a centralised directory service.
Supplier Company supplying a CMS to the customer. #eceives the completed
requirement specification from the customer and fills out the right side of the
tables with their solutions.
3his specification is )ased on &equirements 3emp"ate S,6.' <= S>ren ,auesen7 2..'?