IBM BS029ML Self Help Guide - Page 28

Addressing non-functional requirements

Page 28 highlights

System Component / Roles Administrators Content Developers Content Authors Content Approver PDM WCM TAM System A System B Description Administrators are responsible for the management of the Portal. They are responsible for adding new portlets, new pages, new administrative users, and so on. Content Developers are responsible for creating Web Content Management (WCM) design artifacts, such as site frameworks, and authoring and presentation templates. Content Authors are a subset of Authenticated Users that are delegated the responsibility of creating WCM content. Content Approvers are a subset of Authenticated Users that are delegated the responsibility of approving WCM content. Such users approve or reject content prior to releasing the content for delivery. Portal Document Manager (PDM) is a subcomponent of WebSphere Portal Server responsible for archiving and managing documents. Web Content Management (WCM) is a subcomponent of WebSphere Portal Server responsible for the complete life cycle of Web content information. Tivoli Access Manager (TAM) is an External Security Manager responsible for providing enterprise wide security. System A is responsible for function X. System B is responsible for function Y. 2.1.5 Addressing non-functional requirements Capturing the non-functional requirements is a preliminary task that not only provides a starting point for selecting and sizing the physical components of a Portal solution, but also establishes such key aspects as availability, backup and recovery, disaster recovery, and systems management. In terms of the former aspects, a resulting sizing estimate is normally calculated based on those non-functional requirements giving an approximation of the physical resources required to support the proposed implementation. Of course, many factors influence the selection of the physical resources and actual experiences will vary from that of the sizing estimate for many reasons; the degree of variability can range from the small to the very significant. For those latter aspects, which by no means are exhaustive, the required solution characteristics and capabilities take shape and drive the selection of the hardware and software technologies needed to deliver the proposed implementation, within the constraints of technology, skills, and budget. Unfortunately, the non-functional requirements of a solution also tend to be treated as "second-class citizens" because they do not add any new or improved functionality. Thus, they typically do not receive the proper attention of executives, the project manager, or even the technical team. However, a project must address the likes of availability and performance in all phases of a project life cycle to be successful. For those customers finding themselves in the unfortunate situation of having selected and purchased "bare metal: systems, without having undertaken a thorough non-functional requirements study, the degree of usefulness attributed to fully capturing the non-functional requirements at a later stage is somewhat limited. There remain a number of key objectives that the implementation should strive to meet. 14 IBM WebSphere Portal V6 Self Help Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

14
IBM WebSphere Portal V6 Self Help Guide
2.1.5
Addressing non-functional requirements
Capturing the non-functional requirements is a preliminary task that not only provides a
starting point for selecting and sizing the physical components of a Portal solution, but also
establishes such key aspects as availability, backup and recovery, disaster recovery, and
systems management. In terms of the former aspects, a resulting sizing estimate is normally
calculated based on those non-functional requirements giving an approximation of the
physical resources required to support the proposed implementation. Of course, many factors
influence the selection of the physical resources and actual experiences will vary from that of
the sizing estimate for many reasons; the degree of variability can range from the small to the
very significant. For those latter aspects, which by no means are exhaustive, the required
solution characteristics and capabilities take shape and drive the selection of the hardware
and software technologies needed to deliver the proposed implementation, within the
constraints of technology, skills, and budget.
Unfortunately, the non-functional requirements of a solution also tend to be treated as
"second-class citizens" because they do not add any new or improved functionality. Thus,
they typically do not receive the proper attention of executives, the project manager, or even
the technical team. However, a project must address the likes of availability and performance
in all phases of a project life cycle to be successful.
For those customers finding themselves in the unfortunate situation of having selected and
purchased “bare metal: systems, without having undertaken a thorough non-functional
requirements study, the degree of usefulness attributed to fully capturing the non-functional
requirements at a later stage is somewhat limited. There remain a number of key objectives
that the implementation should strive to meet.
Administrators
Administrators are responsible for the management of the
Portal. They are responsible for adding new portlets, new pages,
new administrative users, and so on.
Content Developers
Content Developers are responsible for creating Web Content
Management (WCM) design artifacts, such as site frameworks,
and authoring and presentation templates.
Content Authors
Content Authors are a subset of Authenticated Users that are
delegated the responsibility of creating WCM content.
Content Approver
Content Approvers are a subset of Authenticated Users that are
delegated the responsibility of approving WCM content. Such
users approve or reject content prior to releasing the content for
delivery.
PDM
Portal Document Manager (PDM) is a subcomponent of
WebSphere Portal Server responsible for archiving and
managing documents.
WCM
Web Content Management (WCM) is a subcomponent of
WebSphere Portal Server responsible for the complete life cycle
of Web content information.
TAM
Tivoli Access Manager (TAM) is an External Security Manager
responsible for providing enterprise wide security.
System A
System A is responsible for function X.
System B
System B is responsible for function Y.
System Component / Roles
Description