Commit: 0c4783c02466d9cce02c86ee44097a35706be6c0 - MESS (hg)

Commit MetaInfo

• Revisión: 0c4783c02466d9cce02c86ee44097a35706be6c0 (tree)
• Tiempo: 2020-02-08 06:26:57
• Autor: Albert Mietus < albert AT mietus DOT nl >
• Commiter: Albert Mietus < albert AT mietus DOT nl >

Log Message

asis BUSY

Cambiar Resumen

• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/TraceAll.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/demo1-tracking.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/demo1.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/demo2-tracking.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/demo2.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/demo/index.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/goal/index.rst
• modified: SoftwareCompetence/RequirementsTraceability-demo/index.rst
• modified: _external_templates/conf/std_conf.py
• modified: _external_templates/static/SwBMnl+rtfd.css
• modified: _generic.inc
• add: SoftwareCompetence/RequirementsTraceability-demo/notes/index.rst

Diferencia incremental

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/TraceAll.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/TraceAll.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/TraceAll.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -1,10 +1,20 @@
-Generate a big tree
+.. Copyright (C) ALbert Mietus & Sogeti.HT; 2020
+
+All needs [BigTree]
 ===================
 
-We can also show the relations between all product (cq releases) and it *needs*.
+We can also show the relations between all product (cq releases) and it *needs* in one big tree [#forrest]_.
 
 .. _all_graph:
 
 .. needflow::
 
-.. thats it.
+This
+
+.. rubric:: Footnotes & Links
+
+.. [#forrest] In general, and strictly speaking, this graph can be a “forrest”: a collection of trees. Mostly, people
+              like to use the term “tree” anyhow.
+              |BR|
+              However as this chapter is about requirements and quality, and I’m trying to convince you to be
+              strict, this footnote seems non-trivial ...

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/demo1-tracking.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/demo1-tracking.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/demo1-tracking.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -1,11 +1,44 @@
-Requirements Traceability, for demo1
-====================================
+Requirements Traceability [Demo 1]
+**********************************
 
-Given all (kind of) specifications that are defined for :need:`CALC1`, we can generate a overview of *needs*. There are
-several ways to show that information; we use 2
+With the defined ‘needs’, their relations can be shown automatically, or some tables with relevant ones can be
+listed. Below you will find two examples, for :need:`CALC1`.
+
+.. _demo1_graph:
+
+A graphical view (“tree”)
+=========================
+
+This view shows the relationship between all kinds of specifications. It is fully automatically generated and will be
+updated when the specifications change.
+
+.. needflow::
+   :tags: demo1;general
+
+
+Lessons learned
+---------------
+
+#. This graph clearly shows there are **no tests** for :need:`CALC_DIV`. This is easily overseen as there are four
+   requirements *and* four tests defined.
+#. When the requirement :need:`CALC_ADD` changes, two tests might need an update.
+#. Likewise, for the other requirements, it is directly visual where the relations are.
+
+.. attention::
+
+   .. _forgotten_test:
+
+   The “forgotten test” is intentional in this first demo.  It will be fixed in the :ref:`next chapter<test_hotfix>`,
+   and you will see it in the other graphs.
+
+   Therefore I had to use some “trick” in needs; see :ref:`the notes about the forgotten test<about_forgotten_test>` for
+   more info.
+
 
 The Requirements Matrix (table)
---------------------------------
+===============================
+
+Some people prefer to see the same information in a table; again this one is automatically generated.
 
 .. needtable::
    :tags: demo1;general
@@ -13,48 +46,38 @@
    :columns: id;type;title;incoming;outgoing
    :sort: type
 
-.. note::
+.. hint::
 
    For now, ignore the *links* to CALC2 and CALC2_1000ND. Those will be in explained in :ref:`demo2`
 
-A graphical view (“tree”)
--------------------------
-Some people prefer to see the same information in a graphical way:
-
-.. _demo1_graph:
+Lessons learned
+---------------
 
-.. needflow::
-   :tags: demo1;general
-
-.. attention::
-
-   .. _forgotten_test:
-
-   The graph (as well as the table) clearly shows there is no tests for :need:`CALC_DIV`. For this demo, it’s
-   intentional. Note, however, that --as there are :need_count:`type=='test' and 'general' in tags` tests defined-- one
-   can easily oversee this; even in this simple case!
+#. This generated tabular overview kind of act as an index to all “clickable” *needs* It a great page to bookmark.
+#. One can even add a status-column (not shown here), or filter on (show only) e.g. test that fails.
+#. It gives less insight; therefore it good to have both overviews.
 
 
 Summary
---------
+=======
 
 This very simple demo has only *one* product with *four* requirements and a few tests. There are no product-variant, no
 product-increments (“new releases”) and no intermediate (or hierarchical) specifications. As a (deliberate) result, its
 **Requirements Traceability** is simple.
 |BR|
-Everybody can understand the when product-definition --one of the four requirements will change-- the implementation
+Everybody can understand that when product-definition --one of the four requirements-- will change, the implementation
 will (partially) change. And so that, some tests have to be re-run.
 
-Also, a changed requirement(s) and the corresponding test are only one click aways.
+Also, a changed requirement(s) and the corresponding test are only one click away.
 
 Next steps
 ----------
 
-When we introduce variants, sprint-increments, multiple (sub)components, libraries, versions, releases, etc. the
-challenge becomes bigger. Especially when a project-teams grows, its might become a nightmare to know which test has to
+When we introduce variants, sprint-increments, multiple (sub)components, libraries, versions, releases, etc, the
+challenge becomes bigger. Especially when a project-teams grows, it might become a nightmare to know which test has to
 be re-run, when a specification changes.
 
-Unless one uses a (simple) approach as shown above. Then, everbody can just see which *rework* is needed when something
+Unless one uses a (simple) approach as shown above. Then, everybody can just see which *rework* is needed when something
 “upstream” changes. And, by adding a “status” to each spec, we can even make this visual.
 
 See :ref:`demo2` for a bit more complex example: Adding a product-variant and (only) one extra (non-functional)

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/demo1.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/demo1.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/demo1.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -2,7 +2,7 @@
 
 .. _demo1:
 
-[Demo 1] The Simple Calculator
+[Demo 1] A simple calculator
 ******************************
 
 The specifications are quite trivial ...
@@ -15,71 +15,81 @@
    :ID: CALC1
    :tags: demo1
 
-   In this demo, a simple calculator should be designed. It should work with intergers; with a maximal length of 8 digits,
+   For this demo a simple calculator is used. It should work with intergers; and has only a few requirements. See below.
 
-   We use a very simple example, as you probably understand the specifications even with spending a lot of text on it.
+We use this extremely simplistic example as you will agree on its requirements.
+
 
 Some general requirements, for all  calculators
 ===============================================
 
-.. req:: Simple Add
+.. req:: Generic Add
    :ID: CALC_ADD
    :links: CALC1;CALC2
    :tags: general
 
    All calculators should be able to sum two numbers and show the result.
 
-.. req:: Simple Sub
+.. req:: Generic Sub
    :ID: CALC_SUB
    :links: CALC1;CALC2
    :tags: general
 
    All calculators should be able to subtract a number form another number.
 
-.. req:: Simple Multiply
+.. req:: Generic Multiply
    :ID: CALC_MULT
    :links: CALC1;CALC2
    :tags: general
 
    All calculators should be able to multiply two numbers.
 
-.. req:: Simple Divide
+.. req:: Generic Divide
    :ID: CALC_DIV
    :links: CALC1;CALC2
    :tags: general
 
    All calculators should be able to divide two numbers.
 
+
 Add this is how we test it
 ==========================
 
 As we have defined only general requirements, we only need some generic tests.
 
-.. test:: Basic Simple Addition test
+.. test:: Basic addition test
    :id: CALC_TEST_ADD_1
    :links: CALC_ADD;CALC2_1000ND
    :tags: general
 
-   Add the numbers ``2`` and ``5`` and check the result is **7**
+   Sum two numbers and verify the result is correct.
 
-.. test:: Advanced Simple Addition test
+   By example: Add  ``2`` and ``5`` and check the result is **7**
+
+.. test:: Big  addition test
    :id: CALC_TEST_ADD_2
    :links: CALC_ADD;CALC2_1000ND
    :tags: general
 
    Add the numbers ``2222`` and ``5555`` and check the result is **7777**
 
-.. test:: A  Simple Subtract test
+.. test:: Subtract test
    :id: CALC_TEST_SUB_1
    :links: CALC_SUB;CALC2_1000ND
    :tags: general
 
+   Feed two numbers to the calculators, in the right order and verify the result.
+   |BR|
+   E.g:
+
    * Subtract ``5`` from ``7`` and check the result is **2**
    * Subtract ``5555`` from ``7777`` and check the result is **2222**
 
-   Here we specify two test in one test-requirement; just to show another style
+   .. note::
 
-.. test::  Simple Multiplication test
+      Here we specify two test in one test-requirement; just to show another style
+
+.. test:: Multiplication test
    :id: CALC_TEST_MULT_1
    :links: CALC_MULT;CALC2_1000ND
    :tags: general

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/demo2-tracking.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/demo2-tracking.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/demo2-tracking.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -1,10 +1,25 @@
-Requirements Traceability, for demo2
-====================================
+Requirements Traceability [Demo2]
+*********************************
 
 As in :doc:`demo1`, we can automatically generate the an overview of the requirements.
 
-Generated overviews
--------------------
+The tree view
+=============
+
+.. _demo2_graph:
+
+.. needflow::
+   :tags: demo2;general
+
+Lessons learned
+---------------
+
+.. todo::
+
+   XXX
+
+The table view
+==============
 
 .. needtable::
    :tags: demo2,general
@@ -13,11 +28,11 @@
    :sort: type
 
 
-.. _demo2_graph:
+Lessons learned
+---------------
 
-.. needflow::
-   :tags: demo2;general
+.. todo::
+
+   XXX
 
 
-Summary
--------

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/demo2.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/demo2.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/demo2.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -2,10 +2,10 @@
 
 .. _demo2:
 
-[Demo 2] The Exact Calculator
+[Demo 2] The exact calculator
 *****************************
 
-This demo is just a bit more complex as :ref:`demo1`; it just add a product-variant with *one* extra requirement.
+This demo is just a bit more complicated then :ref:`demo1`: this product-variant has *one* extra requirement.
 
 A bit more complicated product
 ==============================
@@ -15,45 +15,80 @@
    :tags: demo2
    :links: CALC1
 
-   This calculator should work with `Fractional Numbers <https://en.wikipedia.org/wiki/Fraction_(mathematics)>`_ and be
-   exact (and able to show/process) for very big numbers; as defined in :need:`CALC2_1000ND`
+   This calculator should work with `Fractional Numbers <https://en.wikipedia.org/wiki/Fraction_(mathematics)>`_, and be
+   exact for very big numbers; as defined in :need:`CALC2_1000ND`
 
    .. warning::
 
-      This implies, ``floats`` are not possible in the implementation
+      This implies ``floats`` are not possible in the implementation
 
 
 The extra requirement
 =====================
 
-.. spec:: Fraction
+.. spec:: Big fractional numbers
    :id: CALC2_1000ND
    :links: CALC_ADD;CALC_SUB;CALC_MULT;CALC_DIV
    :tags: demo2
 
-   The :need:`CALC2` should work with fractions; where nominator and denominator can be long: 1000 digits.
+   The :need:`CALC2` should work with fractions; where nominator and denominator can be very long: up to **1000
+   digits**.
 
 .. _test_hotfix:
 
-Hotfixing the missing test
---------------------------
+Hotfix the missing test
+-----------------------
 
-We also *repair* the missing test in demo1, but only for demo2 (Because it is a *demo!**).
+We also *repair* the missing test in demo1, but only for demo2 (Because it is still a *demo!*).
 
 .. test:: DIV test (demo2 only)
    :id: CALC2_TEST_DIV_1
    :links: CALC_DIV; CALC2_1000ND
    :tags: demo2
 
-    .. note::
-
-       Documentation Hotfix! Therefore intentional added only for demo2 :ref:`CALC2`
+   Subtract ``1/3`` from ``1/2`` and check the result is **1/6**.
 
-Demo Notes
-===========
+   .. note::
 
-In this demo some *tricks* are used; like the fixing a missing test :need:`CALC2_TEST_DIV_1`, and combining some
-requirements for demo1 (:need:`CALC1`) and demo2 (:need:`CALC2`).
+      This test is was intentionally “forgotten” as explained in the :ref:`forgotten test <forgotten_test>`.
 
-Therefore the ``:tags:`` `general`, `calc1` and `calc2` are used in the ``req::` and ``:spec`` *directives*, to be
-able to filer them in the tables and graphs.  
+      Therefore it is only added for the :need:`CALC2`. See :ref:`the notes about the forgotten
+      test<about_forgotten_test>` for more info.
+
+How to test?
+============
+
+The :need:`CALC2_1000ND` requirement is a good example of a “*nonfunctional*” (actually: a non-distributable)
+specification. It is valid for all other requirements; all parts of the implementation should adhere to it.
+
+Testing this requirement is also different too.  The same tests are valid: we have to add, subtract, multiply and
+divide.
+|BR|
+Only, now we have to use other numbers; really big ones!
+
+Traditionally
+-------------
+
+In the traditional world, using the TMAP-terms, this approximately come down to:
+
+* Reuse the *logic test*.
+* Change a *physical test* (or add one).
+
+Modern
+------
+
+When using an agile test-automation framework this implies
+
+* The ATS (Automated Test Script) isn’t altered.
+* Some “Test-Vectors” (or test-data) is added: the big-fractions.
+
+Specification Traceability
+--------------------------
+
+To be able to trace some test need to be adapted, we only have to add some “links” between the relevant test and the
+additional (test) specification. That is done in :need:`CALC2_1000ND` (possible you have to click/open the see the
+details), by adding some (outgoing) links to the existing tests.
+
+.. note::
+
+   The incoming links are added automatically

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/demo/index.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/demo/index.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/demo/index.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -1,29 +1,28 @@
 .. Copyright (C) ALbert Mietus & Sogeti.HT; 2020
 
-
+**********************
 Demo: Some calculators
-======================
+**********************
 
-This section contains a few demonstrations of the  Requirements Traceability concept.
+This chapter contains a few demonstrations of the  Requirements Traceability concept.
 
 We start with a very simple product: the :need:`CALC1`; with only a few generic requirements and tests. By defining
 those “needs”[#needs]_ it becomes possible to show a (generated) :ref:`graph <demo1_graph>` with the relations between
 them.  |BR| Probably, you will be able to implement and verify this simple product without (formal)
-requirements-traceability; but it give a nice introduction to the concept.
+requirements-traceability; but it gives a nice introduction to the concept.
 
 
 Then, a new product the :need:`CALC2` is defined, in the same way.
 |BR|
-It has only one (tricky) additional requirement; which make both implementation and validation (testing) more
+It has only one (tricky) additional requirement; which makes both implementation and validation (testing) more
 defiant. Again, a nice :ref:`graph <demo2_graph>` is shown.
 
 Likewise, we could add more demo’s with more and more specifications, tests and *need* at multiple-levels; but you will
 get the idea: By simple ‘defining’ the needs, it becomes possible to get insight; independent of the size of the products
-of the numbers of specification.
+or the numbers of specifications.
 
-Finally an :ref:`overal graph <all_graph>` is shown, with all products, all test and all the needs in beween. Just
-because it is easy to include it; it takes a handful of lines, only.
-|BR|
+Finally, an :ref:`overall graph <all_graph>` is shown, with all the products, all the tests, and all the connecting
+*needs*. Just because it is easy to include it; it takes a handful of lines, only
 
 
 .. toctree::
@@ -38,7 +37,7 @@
 
 .. rubric:: Footnotes & Links
 
-.. [#needs] The universal term *needs* is used for all kinds of requirements, specifications, test(specs), etc.
+.. [#needs] The universal term ‘*need*’ is used for all kinds of requirements, specifications, test-specs, etc.
             This name comes from the “needs” extension to “sphinx-docs” that we use in this demo.
 
 Needs:

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/goal/index.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/goal/index.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/goal/index.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -1,7 +1,8 @@
 .. Copyright (C) ALbert Mietus & Sogeti.HT; 2020
 
+*****
 Goals
-=====
+*****
 
 .. toctree::
    :glob:

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/index.rst
--- a/SoftwareCompetence/RequirementsTraceability-demo/index.rst	Mon Feb 03 22:21:22 2020 +0100
+++ b/SoftwareCompetence/RequirementsTraceability-demo/index.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -4,6 +4,23 @@
 Requirements Traceability Demo
 ==============================
 
+.. post:: 2020/02/02
+   :tags:
+   :category:
+   :location: Eindhoven
+   :language: en
+
+   Requirement-Management, and especially *“Tracking Requirements”* isn’t that complicated; but it needs some discipline.
+   Often that discipline is “replaced” by a tool, which is encouraged by tool-vendors. That hardly ever works.
+
+   This chapter introduces requirements traceability in a conceptual, but pragmatic way. Its shows what a team has to do
+   (defining requirements and describing the relations) and what the benefit is. It assume a (more of less) agile
+   way-of-work, and shows how ti can becomes lean. A small investment in good requirements definitions make validations
+   a lot easier.
+
+   And yes, it used a tool: a free one: A simple way to write maintainable documentation, including all
+   requirements. With a plugin that can visualize all specifications and their relations.
+
 .. admonition:: Summary (testers view)
 
    .. image:: ./V-IdeaWorkProduct-alfa.png

diff -r 04496147be8d -r 0c4783c02466 SoftwareCompetence/RequirementsTraceability-demo/notes/index.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/SoftwareCompetence/RequirementsTraceability-demo/notes/index.rst	Fri Feb 07 22:26:57 2020 +0100
@@ -0,0 +1,35 @@
+.. Copyright (C) ALbert Mietus & Sogeti.HT; 2020
+
+***********************
+Some notes on this demo
+***********************
+:status: Just notes
+
+
+To be able to make a compact demo, some “tricks” are used; like the “forgotten test”. Those tricks are documented here.
+
+.. _about_forgotten_test:
+The forgotten_test
+==================
+
+Intentionally, for the first demo one test is “forgotten”. This shown and documented in :ref:`forgetting a test <forgotten_test>` on one page, but needed to be fixed for the second demo; see :ref:`test_hotfix` on another page. And test:need:`CALC2_TEST_DIV_1` itself.
+and combining some
+
+Surely this is not typical in one documentation-release. Therefore the ``:tags:`` `general`, `calc1` and `calc2` are used in the ``req::` and ``:spec`` *directives*, to be able to filer them in the tables and graphs.
+
+
+LATER/ADD
+=========
+
+* We can count the numbers of test, and we can insert links to each one automatically. By example, for the calculator requirements:
+
+  :need:`CALC_ADD`:  has :need_count:`type=='test' and 'CALC_ADD' in links` tests defined. (:need_incoming:`CALC_ADD`)
+
+  The count is only selecting the TEST. The list is alos showing the SPEC!
+
+* Count/Ref all or only 1 step?
+
+  :need_count:`type=='test' and 'CALC1' in links` test for CALC1.
+
+Demo Notes
+===========

diff -r 04496147be8d -r 0c4783c02466 _external_templates/conf/std_conf.py
--- a/_external_templates/conf/std_conf.py	Mon Feb 03 22:21:22 2020 +0100
+++ b/_external_templates/conf/std_conf.py	Fri Feb 07 22:26:57 2020 +0100
@@ -80,5 +80,6 @@
     dict(directive="test", title="Test_Case",      prefix="T_", color="#F6E27F", style="folder")
 ]
 
-needs_global_options = {'style': [("[[copy('type')]]", 'True')]}
-needs_default_layout = 'complete'
+### For needs-0.5+; which we don't use
+#needs_global_options = {'style': [("[[copy('type')]]", 'True')]}
+#needs_default_layout = 'complete'

diff -r 04496147be8d -r 0c4783c02466 _external_templates/static/SwBMnl+rtfd.css
--- a/_external_templates/static/SwBMnl+rtfd.css	Mon Feb 03 22:21:22 2020 +0100
+++ b/_external_templates/static/SwBMnl+rtfd.css	Fri Feb 07 22:26:57 2020 +0100
@@ -75,8 +75,9 @@
     border-radius: 33%;
 }
 
-/* Whitespace between/around footnotes should be small(er) */
-.rst-content div.footnote table.footnote tr td { padding: 1px 2em;}
+div.disqus h2 {background-color: #000066;}
+
+
 
 /*
  * Needs
@@ -86,9 +87,12 @@
 /* For NEEDS-043
  ****************/
 
-div.need.need-demonstrator {background-color: #9DC5BB;}
-div.need.need-requirement  {background-color: #C5EBC3}
-div.need.need-test_case    {background-color: #F6E27F;}
+div.need.need-demonstrator   {background-color: #9DC5BB;}
+div.need.need-requirement    {background-color: #C5EBC3}
+div.need.need-specification  {background-color: #FEDCD2;}
+div.need.need-implementation {background-color: #DF744A;}
+div.need.need-test_case      {background-color: #F6E27F;}
+
 /*Make the box standout (a lttile), style the ID as a links, no margin below last p*/
 div.need {border: 2px solid #000066;}
 div.need span.needs-id a  {color: #000066; text-decoration: underline;}

diff -r 04496147be8d -r 0c4783c02466 _generic.inc
--- a/_generic.inc	Mon Feb 03 22:21:22 2020 +0100
+++ b/_generic.inc	Fri Feb 07 22:26:57 2020 +0100
@@ -10,3 +10,5 @@
 
 .. role:: sogeti-email
    :class: sogeti-email
+
+.. EOF