Preliminary requirements document, review + comments #4

UweSteinkeFromSiemens · 2013-01-24T14:19:08Z

Several paragraphs and notes added to req_synthesis.tex.

First draft of requirement collection for means of description, methodologies and tools

Requirement is renamed to Requirement Collection Workspace (it should contain all documents used in the process of collecting the project requirements). Creation of "Project Requirements" which should contain the actual Project Requirements (in progress, and reference)

* Include remarks made by Stanislas Pinte on 2013-01-14 on WP2 mailing list. Signed-off-by: Stanislas Pinte <stan@ertmssolutions.com> Signed-off-by: David MENTRE <d.mentre@fr.merce.mee.com>

I removed all excerpts from other documents, until that IPR stuff is sorted out.

Signed-off-by: UweSteinkeFromSiemens <uwe.steinke@siemens.com>

sbaro · 2013-01-30T08:46:31Z

D2.3/Synthesis/req_synthesis.tex

What I had in mind in this section was more to define the purpose of the formalisation, not how it will be conduct. I think the points you list here shoud appear either in the requirement part of the document, or in a howto of wp3.

Do you agree?

Dear Sylvain,

I saw your list of comments of this morning.

However, the fact that git presents you theses changes as a completely
new document makes very hard giving feedback to the author of the
changes and to the list...

Do you know how we can handle this better?

I would propose a winmerge/diff export of your version of
req_synthesis.tex versus the one from Uwe and the one from Marielle, so
that we can see the changes.

what do you think?

Very kind regards

Stan

Le 30/01/2013 09:46, Sylvain Baro a écrit :

In D2.3/Synthesis/req_synthesis.tex:

+The purpose of the formalization is:
+\begin{itemize}
+\item to enhance the understanding of modelled subset;
+\item to allow formal analysis of the modelled subset;
+\item to be able to animate the model for testing and analyzing purpose;
+\item to provide information on the completeness and soundness of the SUBSET-26;
+\item to be used as a reference formal specification for the implementation of an OBU
+(by the OpenETCS project team and by industrial actors);
+\item \dots
+\end{itemize}
+
+In order to conduct this formalization, a part of the tool chain and methodology defined (see Goal 2)
+will be used.
+
+The formalization of the complete SUBSET-26 needs a strategy to perform the whole task step by step. This strategy shall
+\begin{itemize}

What I had in mind in this section was more to define the purpose of
the formalisation, not how it will be conduct. I think the points you
list here shoud appear either in the requirement part of the document,
or in a howto of wp3.

Do you agree?

—
Reply to this email directly or view it on GitHub
https://github.com/openETCS/requirements/pull/4/files#r2822833.

Stanislas Pinte e-mail: stan@ertmssolutions.com ERTMS Solutions http://www.ertmssolutions.com Sales Director Follow us on twitter http://twitter.com/#!/ertmssolutions Cell: +32 499 25 94 24 Rue de la caserne, 45 Tel: +322 - 612.41.70 1000 Bruxelles Fax: +322 - 522.09.30

Dear Stanislas,

I agree with you that it is a problem. I "pushed" the issue to the project management, and now wait for an answer on how to handle this. I think it really needs a HOWTO document on the complete conduct of review :

how you submit to review

how reviewer submit their comments and modifications

how you answer and take into account comments and modification

how you merge all this

how you submit back your document

Best regards,

Sylvain BARO

Dear Sylvain,

I saw your email, and I agree with you.

In the meanwhile, I'll try to provide an readbable diff with your
comments inline, so that we can go forward.

If needed also, I volunteer to help you merging the changes of the
various pull requests if needed.

I have time tomorrow.

Very kind regards

Stan

Dear Sylvain,
going back to your first comment: I agree, that there could be a better place in the document for the mentioned strategy requirement.
I would not shift it to WP3, since all subsequent WPs after WP2 are dependant from it. So WP2 seems to be the central place to find such a strategy.

Kind regards
Uwe

Dear Sylvain,

I agree with you.

In my opinion, the following list of points are not requirement on the
modelling process, but they describe the actual modelling process:

+\item determine the procedure of how the natural language SUBSET-26
specification can be formalized (via nonambious dictionary, definition
of variables, inputs, outputs, ...)
+\item determine which kinds of abstraction layers are required for the
formalization
+\item divide the whole functionality of SUBSET-26 into separate
components with minimized interdependencies, that allow to be
implemented and tested separately by different contributors;
+\item define how these (integrated) components can be simulated, tested
and executed;
+\item \dots

--> To me, this should be defined by the modelling task in WP3, not by
the WP2. What should be defined by WP2 is the process that applies to
this modelling.

What do you think?

Very kind regards

Stan

Le 30/01/2013 09:46, Sylvain Baro a écrit :

In D2.3/Synthesis/req_synthesis.tex:

+The purpose of the formalization is:
+\begin{itemize}
+\item to enhance the understanding of modelled subset;
+\item to allow formal analysis of the modelled subset;
+\item to be able to animate the model for testing and analyzing purpose;
+\item to provide information on the completeness and soundness of the SUBSET-26;
+\item to be used as a reference formal specification for the implementation of an OBU
+(by the OpenETCS project team and by industrial actors);
+\item \dots
+\end{itemize}
+
+In order to conduct this formalization, a part of the tool chain and methodology defined (see Goal 2)
+will be used.
+
+The formalization of the complete SUBSET-26 needs a strategy to perform the whole task step by step. This strategy shall
+\begin{itemize}

What I had in mind in this section was more to define the purpose of
the formalisation, not how it will be conduct. I think the points you
list here shoud appear either in the requirement part of the document,
or in a howto of wp3.

Do you agree?

—
Reply to this email directly or view it on GitHub
https://github.com/openETCS/requirements/pull/4/files#r2822833.

Stanislas Pinte e-mail: stan@ertmssolutions.com ERTMS Solutions http://www.ertmssolutions.com Sales Director Follow us on twitter http://twitter.com/#!/ertmssolutions Cell: +32 499 25 94 24 Rue de la caserne, 45 Tel: +322 - 612.41.70 1000 Bruxelles Fax: +322 - 522.09.30

Dear Uwe,
I agree that it can take place in the WP2 documents. But I would put this more in the D2.3 or D2.4 documents. I think these are neither goals, nor requirements (except the one which says that the SUBSET must be divided into functions), these are really in the methodology part of the WP2, because they describe the "how".

For a reminder, here are the D2.3 and D2.4 as described in the I/O document.
D2.3: Definition of the overall process for the formal description of ETCS and the rail system it works in
Description of the OpenETCS project : activities and case study (overall design plan)

description of the process to be applied in the OpenETCS :
- design and development par of the process
- usual safety activities of such kind of process : this activity is not a part of the project

description of the system study in the OpenETCS project and its environment
- high level description of the subset + link to reference documentation (subset 26)
- high level description of the environement of the system and main function
- reference document subset 091 to the list of safety properties

D2.4: Definition of the methods used to perform the formal description
Detailed process in regards of state of the art results and Cenelec standard requirements (detailed design plan)

For each step of the process defined in T.2.2.1 :
- objectives of the step
- Input/output
- proposed techniques

rules on languages and tools

What do you think of it?

Best regards,
Sylvain.

Dear Sylvain,
I agree. It is not a requirement of the formlization itself, but more that we need a proceeding how to eat up the whole SUBSET 26.
So it's ok, if this need is solved in a different task.
Best regards
Uwe

sbaro · 2013-01-30T09:01:39Z

D2.3/Synthesis/req_synthesis.tex

I am not sure it is really a requirement, at this level. For example if you do proof, will you need test generation?

I not optimistic enough to expect that the proofs will cover 100 % of all required functions. More realistic, there will be a combination of formal proofs and test cases. Test cases can be be specified in a more abstract way via test models with automatically generated testsequences derived from the test models.

OK, I agree with you. I will try to find a proper formulation.

Le 30/01/2013 12:55, Uwe Steinke a écrit :

In D2.3/Synthesis/req_synthesis.tex:

...
+\end{issue}
+\marginpar{The tool chain should provide model based testing. For that, generating test cases from test models will be required}

I not optimistic enough to expect that the proofs will cover 100 % of
all required functions. More realistic, there will be a combination of
formal proofs and test cases. Test cases can be be specified in a more
abstract way via test models with automatically generated
testsequences derived from the test models.

A small comment about test models: in ERTMSFormalSpecs, we interpret the
"test model"s directly, to test the "model under test". We don't have to
generate code in order for test cases to be executed. My point is that
test code generation is optional.

—
Reply to this email directly or view it on GitHub
https://github.com/openETCS/requirements/pull/4/files#r2825208.

Stanislas Pinte e-mail: stan@ertmssolutions.com ERTMS Solutions http://www.ertmssolutions.com Sales Director Follow us on twitter http://twitter.com/#!/ertmssolutions Cell: +32 499 25 94 24 Rue de la caserne, 45 Tel: +322 - 612.41.70 1000 Bruxelles Fax: +322 - 522.09.30

I think the point is to be able to produce test scenarios from high level inputs (whatever is this input, except maybe the model itself).

I also agree with Uwe that generated test cases can be useful to supplement formal proof:

either in upstream phases (to try to find some bugs before the proof itself)

or for availability issues in which we could avoid proof.

... and for realistic operational scenarios.
Besides proofs, it is required to see the subset-26 functions travelling through scenarios close to operational reality and have these as part of the verification suite.

Uwe and Sylvain, I fully agree...

As official ERTMS operational scenarios are defined in Subset-076, I suggest that we include that Subset in the tool chain requirements, as follows:

+\req{The tool chain shall allow to execute Subset-076 test cases on the model}

MERCEmentre and others added 23 commits January 9, 2013 00:57

Merge pull request #1 from janWelte/master

daced25

First draft of requirement collection for means of description, methodologies and tools

New file

23d1ba1

Update RequirementManagement.md

f21f8d3

Fix typo in RequirementManagement.md

3dac42f

Update RequirementManagement.md

84e1080

Creation of the Project Requirement folder

0056e2e

Explanation of the purpose of folders

93e082c

cleaning

50a3d4c

Create FolderOrganization.md

8d975fe

Update FolderOrganization.md

884268e

Update FolderOrganization.md

eb63888

Update FolderOrganization.md

358746c

Requirement Synthesis - preliminary version

787d95f

Req Management script and macro

a9888f2

Reorganization

94c5e51

Create Test

cc5820e

With nested lists thanks to Matthia!

4852fc7

Add details on paragraphs needed to be modeled in §3.13

6a6488b

* Include remarks made by Stanislas Pinte on 2013-01-14 on WP2 mailing list. Signed-off-by: Stanislas Pinte <stan@ertmssolutions.com> Signed-off-by: David MENTRE <d.mentre@fr.merce.mee.com>

Safety Requirements through two examples

e62f80c

.gitignore

3e7ae60

Removal of excerpts from other documents

2b5dfcc

I removed all excerpts from other documents, until that IPR stuff is sorted out.

Some issues and margin notes added to the document req_synthesis.tex.

c1f73f3

Signed-off-by: UweSteinkeFromSiemens <uwe.steinke@siemens.com>

sbaro reviewed Jan 30, 2013
View reviewed changes

Preliminary requirements document, review + comments #4

Are you sure you want to change the base?

Preliminary requirements document, review + comments #4

Uh oh!

Conversation

UweSteinkeFromSiemens commented Jan 24, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants