RE: [SysML-Evaluators] Review of requirements chapters in both submissions

[Erik Herzog]

Sandy, All,

 

Some clarifications to my previous comments on requirements chapters in both submission based on a reply from Sandy. My comments are inserted below in your text in red colour.

 

Kind regards

 

Erik

 

---

From: Friedenthal, Sanford [mailto:sanford.f...@lmco.com]
Sent: den 14 december 2005 22:40
To: her...@syntell.se
Subject: FW: [SysML-Evaluators] Review of requirements chapters in both submissions

 

Eric

 

Thanks for your comments. Our team (SST) will look at your inputs and try to address them as best we can for the February submission. The following are some comments we would like to discuss further if we have the opportunity.

 

You proposed using a single mechanism for representing requirements allocations (e.g. callout notation or compartment notation). SST considered multiple options (initial discussion in meeting with you, Asmus, back at INCOSE IW in Jan) but have found they each provide value for being able to effectively relate requirements to other elements (e.g. satisfy, verify, refine, etc).  We certainly could eliminate one or alternatively, we could leave it to the user to make that decision.

 

I have sympathy for the approach as I too do not like the standard UML approach to capturing traceability, but keeping two redundant representations means that

 

-          A tool vendor will need to implement handling for both alternatives.

-          A user will have problems determining if two specifications are equivalent

-          A user may be tempted to use both mechanisms within a single specification leading to confusion.

So the approach would create more confusion than benefits and, while superficially appealing, it will not please anyone. So I would urge you to drop it

 

We decided to leave the table specification as a tool vendor implementation concern for this version and consider adding more clarity in future revisions. Providing tabular represenations is a big step forward, but we did not want to overly constrain the approach at this time. We may be able to address some of this in the FTF (Finalization Task Force) assuming we get a vote to recommend adoption in Feb.

 

I agree it is important with tabular representations for requirements, but if the specification is not clear then it will not help anyone. I suspect the tool vendors will sense that there is a need for a tabular requirement representation and will eventually implement such a thing regardless whether this is in the specification or not. The present approach does not provide any real guidance to help the tool vendors. An alternative could be to extent one of the non normative appendices with information stating that the requirements management support in SysML is not the best and that tabular approaches for requirements representation would be preferable.

 

Relative to comment 14.12, the approach to test cases are the same in the two submissions, but SP included a constraint and we did not.  Our focus for v1.0 for verification in general was to provide a rudimentary capability and be generally consistent with the UML testing profile. We did do an assessment of the level of integration and believe we are in good shape to more fully integrate with the testing profile in the post v1.0 SysML and fill any gaps at that time.

 

No, SP separates the verdict from the testcase, SST does not. The SP solution allows you to state that you have executed the same test multiple times. However, none of the submissions support representation of the actual realised system configuration tested. Extending SysML to handle this is not very complex and very important for the end user community!

 

We will try to incorporate selected aspects of your input in v1.0. We are somewhat constrained as to the magnitude of change that we can introduce if we want to stay within the February timeframe to begin the vote to adopt. If we miss this gate, we end up having to move the vote to adopt out 2 meeting cycles to the June meeting, and possibly further. As you will recall, our philosophy is to get SysML into the hands of the users now and improve it over time based on the feedback from the vendors and users. We believe this incremental approach is effective for evolve the spec.

 

As a reviewer I can only point out what I find important and also point out that I am suggesting two reductions and only one addition... Things could have been much worse!

 

Thanks again for your valuable comments.

 

    Sandy

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Erik Herzog
Sent: Tuesday, December 13, 2005 4:53 AM
To: 'SysML Evaluators'
Subject: [SysML-Evaluators] Review of requirements chapters in both submissions

All,

 

The attached file contains my comments on the requirements chapters in the respective SysML submission. I hope you will find them of value!

 

Kind regards

 

Erik

Erik Herzog, Ph.D.

Syntell AB
PO Box 10022
S-100 55 Stockholm, Sweden
Tel. +46-(0)8-660 02 80
Mobile. +46-(0)70-541 82 57
Fax. +46-(0)8-660 09 65
her...@syntell.se
www.syntell.se
______________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.