You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/design.md
+43-12Lines changed: 43 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,7 +87,7 @@ Since the specification item IDs inherently look similar, load tests need to sho
87
87
## Importers
88
88
For each specification artifact type OFT uses an importer. The importer uses the specification artifact as data source and reads specification items from it.
89
89
90
-
## Import Event Listeners
90
+
## Import Event Listener
91
91
Importers emit events if they find parts of a [specification item](#specification-item) in the artifact they are importing.
92
92
93
93
### Specification List Builder
@@ -336,7 +336,7 @@ Needs: impl, itest
336
336
### Internal Data Structures
337
337
338
338
#### Specification Item
339
-
`dsn~specification-item~2`
339
+
`dsn~specification-item~3`
340
340
341
341
A `SpecificationItem` consists of the following parts:
342
342
@@ -351,10 +351,16 @@ A `SpecificationItem` consists of the following parts:
351
351
* Depends (List of `SpecificationItemId`, optional)
352
352
* Needs (List of `String`, optional)
353
353
* Tags (List of `String`, optional)
354
+
* Forwards (`boolean`, internal)
355
+
356
+
Comment:
357
+
358
+
See `req~forwarding_needed_coverage~1` for an explanation of the "forwards" fields meaning.
354
359
355
360
Covers:
356
361
357
362
*`req~specification-item~2`
363
+
*`req~forwarding_needed_coverage~1`
358
364
359
365
Needs: impl, utest
360
366
@@ -395,13 +401,13 @@ Needs: impl, utest
395
401
A requirement ID has the following format
396
402
397
403
requirement-id = type "~" id "~" revision
398
-
404
+
399
405
type = 1*ALPHA
400
-
406
+
401
407
id = id-fragment *("." id-fragment)
402
-
408
+
403
409
id-fragment = ALPHA *(ALPHA / DIGIT / "_" / "-")
404
-
410
+
405
411
revision = 1*DIGIT
406
412
407
413
Rationale:
@@ -435,6 +441,7 @@ Markdown titles show up in the outline and are a natural way of defining a requi
435
441
Covers:
436
442
437
443
*`req~markdown-standard-syntax~1`
444
+
*`req~markdown-outline-readable~1`
438
445
439
446
Needs: impl, utest
440
447
@@ -444,9 +451,9 @@ Needs: impl, utest
444
451
In Markdown specification item references have the following format:
Only one traced reference per line is supported. Any optional text after the reference is ignored if it is separated by at least one whitespace character
@@ -484,9 +491,9 @@ Needs: impl, utest
484
491
The Markdown Importer supports the following format for links to a different specification item which the current depends on.
Only one traced reference per line is supported. Any optional text after the reference is ignored if it is separated by at least one whitespace character
@@ -522,6 +529,30 @@ Covers:
522
529
523
530
Needs: impl, utest
524
531
532
+
#### Markdown Artifact Forwarding Notation
533
+
`dsn~md.artifact-forwarding-notation~1`
534
+
535
+
The Markdown Importer supports forwarding required coverage from one artifact type to one or more different artifact types using the following notation.
The following example shows an architectural specification item that forwards the needed coverage directly to the detailed design and an integration test.
Copy file name to clipboardExpand all lines: doc/system_requirements.md
+32Lines changed: 32 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -183,6 +183,21 @@ Tags are a way to label an artifact intended for grouping.
183
183
184
184
Needs: dsn
185
185
186
+
#### Forwarding Needed Coverage
187
+
`req~forwarding_needed_coverage~1`
188
+
189
+
OFT allows users to forward needed coverage from one artifact type to one or more different types.
190
+
191
+
Rationale:
192
+
193
+
Often a system requirement does not affect the high-level architecture. In this case it is convenient for the architect to hand it down to lower levels directly.
194
+
195
+
Covers:
196
+
197
+
*[feat~markdown-import~1](#markdown-import)
198
+
199
+
Needs: dsn
200
+
186
201
### Supported Formats
187
202
188
203
#### Markdown
@@ -211,6 +226,8 @@ Covers:
211
226
Needs: dsn
212
227
213
228
##### Markdown Outline Readable
229
+
`req~markdown-outline-readable~1`
230
+
214
231
The Markdown outline -- a table of contents created from the heading structure by various Markdown editors -- must be human readable.
215
232
216
233
Rationale:
@@ -238,6 +255,21 @@ Covers:
238
255
239
256
Needs: dsn
240
257
258
+
##### Artifact Type Forwarding in Markdown
259
+
`req~artifact-type-forwarding-in-markdown~1`
260
+
261
+
The Markdown format features a compact way to forward a requirement from the artifact type that was originally required to one or more different artifact types.
262
+
263
+
Rationale:
264
+
265
+
Often a system requirement does not affect the high-level architecture. In this case it is convenient for the architect to hand it down to lower levels directly.
266
+
267
+
Covers:
268
+
269
+
*[feat~markdown-import~1](#markdown-import)
270
+
271
+
Needs: dsn
272
+
241
273
#### Coverage Tags
242
274
243
275
Developers add coverage tags as comments to the source code to indicate where certain specification items are covered.
@@ -235,6 +235,18 @@ Requirements should be accompanied by a rationale in all cases where the reason
235
235
236
236
Needs: dsn
237
237
238
+
### Delegating Requirement Coverage
239
+
240
+
Consider a situation where you are responsible for the high-level software architecture of your project. You define the component breakdown, the interfaces and the interworking of the components. You get your requirements from a system requirement specification, but it turns out many of those incoming requirements are at a detail level that does not require design decisions on inter-component-level but rather affects the internals of a single component.
241
+
242
+
In those cases it would be a waste of time to repeat the original requirement in your architecture just to hand them down to the detailed design of a component. Instead what you need is a fast way to express "yes, I read that requirement and I am sure it does not need design decisions in the high-level architecture."
243
+
244
+
To achieve this OFT features a shorthand notation for delegating the job of covering a specification item to one or more different artifact types.
245
+
246
+
In the following example a requirement in the system requirement specification (artifact type `req`) stated that the web user interface of your product should use the corporate design. This clearly does not require an architectural decision (`arch`), so you forward it directly to the detailed design (`dsn`) level.
247
+
248
+
arch --> dsn : req~web-ui-uses-corporate-design~1
249
+
238
250
### Distributing the Detailing Work
239
251
240
252
In projects of a certain size you always reach the point where a single team is not enough to process the workload. As a consequence is the teams must find a way to distribute the work. A popular approach is splitting the architecture into components that are as independent as possible. Each team is then responsible for one or more distinct components. While the act of assigning the work should never be done inside of the specification, at least the specification can prepare criteria on which to split the work.
0 commit comments