How to capture and distinguish the requirements

[Suresh]

In requirements diagram, one can represent requirements. However,
requirements comes from different levels (for instance some
requirements come from customer, some after functional decomposition,
some from components which satisfy the functions).

How to capture and distinguish the requirements generated at different
levels using requirements diagram?

Does SysML framework has this support (if not any other pointers to
how to achieve this).

[Ray J]

Here's how I would address this question:
1) Create a separate requirements diagram for each set of
requirements. Put all the customer requirements on one diagram, all
the top-level requirements on another, etc.
2) Personally, I don't like the requirements listed on diagrams and
prefer them in a tabular form - with columns that allow you to create
associations to the source of the requirement or the target of the
requirement. (This will depend on the SysML tool.)
3) For each requirement, create an association between the source and
the requirement. If customer requirements, create a "Customer" actor
and then associate requirements from that customer with the Customer
actor.
4) For each requirement, create an association with the target and the
requirement. What is this requirement describing? This association
provides the primary means of filtering and sorting your requirements
set, with each requirement corresponding to the item that it is
describing.
For SysML, you'll need to use a Realizes relationship from the target
object to the requirement.

[Paul Ebert]

Section 12.3 of "A Practical Guide to SysML" gives some information on
how to do things like this. It talks about using properties (beyond
ID and text) including source (category), status, risk, etc. I do not
know how to access these additional properties in a particular tool
(I'm using Sparx EA and I haven't figured that out). It also talks
about defining additional stereotypes.

Another way to do it is to use containment hierarchies (as presented
in section 12.9). This is basically using packages to sort and provide
heirarchy to the requirements.

[Alberto Sampaio]

you can use the "containment" relationship.
regards
alberto

[frank alvidrez]

The beauty of SysML and modeling is that there is an artistic side of any
solution to a problem.

For example, the previous posts are all correct and reflect each analysts'
view and creativity. I like using the Top Level Domain Modeling (see Sandy
Friedenthal's book) for organizing relationships and then drilling down with
various diagrams to help the system engineers understand what belongs in
what drawer.

I find using color coding as a very powerful tool in MagicDraw for
requirements diagrams. Highest level one color, other levels other colors
and using similar colors in any block diagrams that may satisfy requirements
or use cases that do the same. Have a color code that is always on the
diagram that breaks things down (I am an enterprise architect so everything
looks like triangles to me anyway, with strategic on the top down to the
operational and system, etc). Color also helps the system engineers and
management understand when the architecture or requirements diagrams are
important to them or their customer because of the color that is consistent
throughout the model.

Frank


--
Frank C. Alvidrez
Senior Enterprise Architect

Moffett Field, CA
661-361-5252
frank.a...@verizon.net

[Henk Broeze]

Draw a dependency from your Component to your new Requirement. Or am I
missing something?

[Mo]

Package, Model and Component could be used to group the
requirements. The containment relationship can also be used.
According to Paul, SysML specification v1.1 also provides the non-
normative requirement stereotypes which are described in Annex C.
These kind of requirements contain additional properties beyond text
and id. These additional properties are source, risk,
verificationMethod. You can replace the original SysML requirement
with them. If these additional properties are not enough and you need
to add more additional properties to your requirements, e.g. level of
requirement, you may create your own stereotypes (extend the Class
meta-type or specialize from the Requirement stereotype) for applying
to the requirement elements.
In MagicDraw, you can customize the display of requirements using
stereotypes. So, the requirements which are applied with the same
stereotype can be customized for displaying with the same color (I
agree with frank that using the color coding is very helpful for
distinguish the requirements which are shown in the same Requirements
diagram).

Kritsana U.

[MRE]

Hm, I hope I am not going to upset the fans of SysML, but...

I'd recommend not to use SysML for Requirements management at all.
There
are much better tools than the Requirements diagram.

Two reasons:
1.) Requirements are (mostly) textual, so use a tool that can handle
text
(e.g. DOORS). A decent requirements management tool will let you
search, replace,
sort, link. None of the SysML tools can do this for a large number of
requirements.

2.) Even for small to medium sized systems the Requirements diagram
quickly becomes
cluttered. In a 2-D representation you only have links and color
coding to bring some
order into your requirements, in a small to medium sized system
project you'll have
a ton of different criteria acoording to which you'll want to
distinguish your requirements
(e.g. source, validity, priority, status of implementation, status of
validation, status of
verification).

In total I'd opine that in the analysis stage model based engineering
and requirements engineering only mix well if the requirements are
augmented by diagrams, not vice versa.

The purpose of the requirements diagram should be to highlight the
origin of some design decisions in the design stage.

Regards,

Marc

[Jørn Arild Hennum]

I would definitely agree with Marc here. In my view, requirements are
best maintained in a tool specially designed for that purpose, such as
DOORS, RequisitePro, TeamCenter SE or others, especially with medium
to large systems. For each "layer" of design, SysML diagrams of
various sorts are excellent as system design tools, discussion tools
and a splendid aid in getting the overall big picture in complex
systems. To make sure the requirements are taken into the design, the
design tool and the requirements management tool should be able to
interact, creating links between requirements and diagram objects.
However, as Marc says, if one attempts to do this for each and every
requirement in a diagram format, one would lose the major benefit of
SysML, namely that of getting a good system overview. The diagrams
would be cluttered and unreadable, and the user would gain far more
oversight by using good naming conventions on his diagram objects, so
a table linking requirements to diagram objects makes sense.

Jørn

[Stefan Schwabe]

Hi Marc!

I totally agree with you. SysML is not the ideal basis for
requirements management, after all it's for modeling.
So I also wouldn't recommend relying on SysML for defining,
maintaining and working on requirements.

But I like to give the discussion another turn:
with most SysML tools the integration of DOORS and SysML becomes
possible. I personally know Rhapsody quite well and in some projects
we used the DOORS-Gateway to import requirements into Rhapsody and to
export the model elements to DOORS.
As we link our model elements to the requirements now it's pretty easy
to find out which requirement was the reason for a specific block,
activity or whatever.
You can easily find out which requirements are still uncovered and
find blocks that were created but that are not described by a
requirement.
If you think about requirements work through all development stages
this approach helps you to create better and consistent
specifications, you will work in DOORS (system spec), then go to
SysML, define the system's components, go back to DOORS to add
additional requirements there (componentent's spec) and so on.

What's the most important part: we actually worked like that and it
really helped.

Best regards,
Stefan

[Raphael FAUDOU]

Hi all,

+1 to say that the requirement diagram is not really usefull as soon as you get more than 50 requirements, which is the common case.

-1 to create links between requirements and diagrams. Diagrams are only a partial view of the system. You can create a new association between two blocks to handle a change in a high level requirement and then your model will change. If you do not take time to update your diagram about those blocks the diagram will not take into consideration your modification and it will not reflect your requirement.
Model is the reference, not diagrams, except if you re build all your diagrams each time the model changes.
Links should be put between requirements and model elements.

Another point is to know whether SysML requirement concept is useful or not. To answer, I would like to raise another big issue : where is the best place to store links between requirements and model elements?
At first sight we could imagine that the links can be stored in the requirement tool (DOORS, ReqPro...). It works quite well till you create links between requirements and UC or blocks or states because the requirement tool can adapt the requirements links to those entities. But when you go further in details in the requirement coverage, you might be interested in creating links at a lowest granularity such as transitions, callBehaviourAction nodes, blocks properties...
When we think about impact analysis in the model we discover that the requirement tool should then be able to load the whole SysML model to be able to perform this analysis and it is probably not its purpose !
So my conclusion is now that the links between requirement and model elements should be stored in the modelling tool, with all "model query" capabilities to calculate impacts.
And to be able to create links in the modelling tool,  I need to be able to import requirements from the requirement tool so that I can see and manipulate my requirements easily. Because of this import  the SysML requirements makes sense (with a stereotype to add other attributes I need).

my two cents

raphaël Faudou

Stefan Schwabe a écrit :

--

Raphaël FAUDOU Responsable cellule Innovation / bureau méthodes Head of Innovation & Method Definition Embedded systems & critical systems Atos Origin Tel     : +33 (0)5 34 36 32 89 Tel     : +33 (0)6 10 53 50 44 Mail   : raphael...@atosorigin.com Atos Origin 6, Impasse Alice Guy BP 43045 31024 Toulouse Cedex 3, France P Avant d'imprimer cet e-mail, pensez à l'environnement. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. P Please consider your environmental responsibility before printing this e-mail. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

[Jack Ring]

OR, you could step into the Model-based SE era.

There you will a) model the Problem System; b) exercise the model to
reveal Problem System behaviors; c) highlight the behaviors to be
suppressed, preserved, enabled and vet this set of decisions with an
independent and objective party; then d1) decide what Effects (on the
Problem System) are desired then d2) what Capabilities will comprise a
necessary and sufficient Problem Suppression System; then e) get on
with design and architecting the ways of implementing the Capabilities.

This will lead to a fielded system that is superior in quality,
parsimony and beauty to one that is designed by listing hundreds of
requirements, 'managing' them with DOORS, etc., then using SysML to
formulating several diagrams none of which reveals behavior. Also, it
will reduce the cost, cycle time and latent errors in the system
development project.

Your choice.

Jack Ring

[Paul Ebert]

I partially agree with Marc.  Based on my (limited) experience with SysML tools, they are not very suitable for requirements management.  Perhaps that's an understatement.

 

However, the integration of requirements into the model is the most desirable feature of SysML, in my estimation.  I've always felt that there was this problematic break between requirements and the activities of design. To me, anything that can be done to keep requirements front and center throughout the design process is exceedingly welcome.  Having separate tools hinders this.

 

It always seemed to me, and please correct me if I'm wrong, that requirements management - the assignment and use of attributes, in particular - serves more of a project management and process improvement role than assisting with design. In that context, I think requirements management is incredibly beneficial for those organizations that have their act together enough to pull it off.  Best I can tell, most don't.

 

Of course, the best case scenario is a tool that is equally powerful in requirements management and modeling. A not so close second (in my mind) is two seamlessly integrated tools.  Is the integration of DOORS and Rhapsody seamless? How about any other tools?

 

Paul

[b...@emailias.com]

I disagree with the vague concept that is "Requirements Diagram". As a "cross-cuting diagram" ANY diagram can be a requirements diagram. As such, the concept is meaningless.  However, I do find it extremely useful to put requirements on diagrams:

1) as a way to create traceable links from requirements to elements (use cases, classes (or blocks), messages on sequences etc) which can then be exported back out to DOORS for things like impact analysis and

2) to clarify the requirments of an element or coherent set of elements. For example, I typically create, for each use case, a diagram with that use case and the requirements with which it associates. Similarly, for a use case state machine, I show which requirements map to which transitions, states and actions. This makes for a compelling, readable, and usable graphical requirements specification.

I certainly would not recommend that someone sit down with the intent of creation dozesn to hundreds of diagrams with nothing but requirements on them. Tools like DOORS are a better means for that. However, mixing them into the model to create both traceable links (which export back to DOORS) and to show the requirements allocated or trace to specific model elements is a great usage.

- Bruce

On Oct 5, 2009, Raphael FAUDOU (raphael...@atosorigin.com) (Emailias: REPLY-MASKED) <reply-106630-e310-grbounce-xztydguaaaceo-7lbszvbqlf8rnddvlp==bpd==emailias.com=-googlegr...@emailias.com> wrote:

Hi all,

+1 to say that the requirement diagram is not really usefull as soon as you get more than 50 requirements, which is the common case.

-1 to create links between requirements and diagrams. Diagrams are only a partial view of the system. You can create a new association between two blocks to handle a change in a high level requirement and then your model will change. If you do not take time to update your diagram about those blocks the diagram will not take into consideration your modification and it will not reflect your requirement.
Model is the reference, not diagrams, except if you re build all your diagrams each time the model changes.
Links should be put between requirements and model elements.

Another point is to know whether SysML requirement concept is useful or not. To answer, I would like to raise another big issue : where is the best place to store links between requirements and model elements?
At first sight we could imagine that the links can be stored in the requirement tool (DOORS, ReqPro...). It works quite well till you create links between requirements and UC or blocks or states because the requirement tool can adapt the requirements links to those entities. But when you go further in details in the requirement coverage, you might be interested in creating links at a lowest granularity such as transitions, callBehaviourAction nodes, blocks properties...
When we think about impact analysis in the model we discover that the requirement tool should then be able to load the whole SysML model to be able to perform this analysis and it is probably not its purpose !
So my conclusion is now that the links between requirement and model elements should be stored in the modelling tool, with all "model query" capabilities to calculate impacts.
And to be able to create links in the modelling tool,  I need to be able to import requirements from the requirement tool so that I can see and manipulate my requirements easily. Because of this import  the SysML requirements makes sense (with a stereotype to add other attributes I need).

my two cents

raphaël Faudou

Stefan Schwabe a écrit :

Hi Marc!  I totally agree with you. SysML is not the ideal basis for requirements management, after all it's for modeling. So I also wouldn't recommend relying on SysML for defining, maintaining and working on requirements.  But I like to give the discussion another turn: with most SysML tools the integration of DOORS and SysML becomes possible. I personally know Rhapsody quite well and in some projects we used the DOORS-Gateway to import requirements into Rhapsody and to export the model elements to DOORS. As we link our model elements to the requirements now it's pretty easy to find out which requirement was the reason for a specific block, activity or whatever. You can easily find out which requirements are still uncovered and find blocks that were created but that are not described by a requirement. If you think about requirements work through all development stages this approach helps you to create better and consistent specifications, you will work in DOORS (system spec), then go to SysML, define the system's components, go back to DOORS to add additional requirements there (componentent's spec) and so on.  What's the most important part: we actually worked like that and it really helped.  Best regards, Stefan On Oct 4, 10:26 am, MRE mailto:Marc.Enzm...@web.de wrote:   

Hm, I hope I am not going to upset the fans of SysML, but...  I'd recommend not to use SysML for Requirements management at all. There are much better tools than the Requirements diagram.      

[Jørn Arild Hennum]

Well, as long as you are dealing with customers with rigid requirement
sets and demands that you follow procedural requirement management
routines, I don't think you're getting away without requirements
management... But perhaps I misunderstood your message... Anyway, as
long as you manage to let the requirement management guide the design
process, and not the other way around, I think it's fully possible to
let your requirements (managed in DOORS or other tools) be an
integrated part of the design. As it should be, in my view. After all,
if there's no requirement for making a certain capability, it
shouldn't be incorporated.

Jørn

[MRE]

Jørn,

I agree that while you are working on requirements analysis and later
on the design, there should be interactivity between requirements- and
modelling- / design-tool. In the aerospace industry however, and
that's
my background, the only relevant information is a paper document.
That's
what my statement meant: augment the terse requirements text with
diagrams.

Jack: Having worked in the field of systems- and requirements-
engineering
for a couple of years, I am not yet convinced by the SysML tool
providers
that Model Based Engineering is mature enough. The main problem in
textual
requirements, the ambiguity of text, is currently transferred to the
ambiguity of the diagrams. If you have the possibility: draw a simple
behavioural diagram on paper. Discuss it with colleagues. Three people
will
give you four opinions what the diagram means. Then put SysML tools
with
simulation capabilities to the test: two tools, two simulation
results.

What MBSE is lacking is a well defined modelling language (or a
combination
of such languages). Simple to use and unambiguous in the syntax and
semantics.

One way to obtain this would be to use rather simple (to use) versions
of formal
methods. Take a look at http://www.speeds.eu.com to see what I mean.
(Yes, im
partial here, I was the project manager of this project ;-) )

Regards,

Marc

[Ray J]

I agree ... but then I disagree.

I agree the requirements diagrams have limited usefulness. To attempt
to manage ALL a project's requirements on diagrams would be rather
silly - diagrams are just not practical for managing the requirements.

However, the SysML tools (or at least EA) has a tabular view of the
contents of packages, so you can in essence create a DOORS-like view
of the requirements in a tabular format. Unfortunately, the tabular
views in the SysML tools are pretty clunky at best, yet.

I am not a fan of DOORS. It does provide a very nice tabular
presentation of requirements, and allows filtering, sorting, etc like
you state. But, it misses an essential ingredient - managing those
requirements within the context of the product architecture - both
logical and physlca architecture, which is captured in the model. By
managing the requirements in a stand-alone tool and the architecture
in a stand-alone tool, you are encouraging disconnected behaviors
between requirements and design.

I much prefer one cohesive tool to manage my requirements and design
together, and use the framework of my architecture to manage
requirements. When you group requirements under paragraph headings,
what are you really doing? You are ARCHITECTING! Unfortuantely, most
people fail to realize the connection, so they manage requirements
within a document-centric perspective, and then attempt to build
architecture and design in a model-centric environment, and then
attempt to "link" the two together, which I find to be unsatisfactory.

I'm neither a fan of SysML nor of DOORS. I find major weaknesses in
both approaches... though I'm trying my best to help people apply good
system engineering techniques despite the tools that they use!

[Don Young]

Ray,

By your comments on DOORS it doesn't appear you are familiar with DOORS Analyst. This is a UML add in to DOORS from IBM Rational that provides the contextual analysis you reference. DA supports UML 2.0, DoDAF and SysML meta models within your DOORS module(s). It supports diagrams, model semantic and syntax checking, behavior simulation, etc. In context with our textual requirements and/or to help elicit your requirements. You could also use scenario diagrams during the analysis phase to drive your test case development.

A picture is worth a thousand words, but, which thousand words?

Don
Sent via BlackBerry by AT&T

[Laurent L Balmelli]

All,

Since I am the primary author of the requirement chapter in the original SysML specification, I would like to give my opinion in this thread of discussion.

As many people have noted, the requirement diagram is indeed not aimed at being used as a management tool or replacing existing tools (such as DOORS). In contrast, the requirement diagram is aimed a providing a visual representation of requirements. In other words, if the tool supports it, the requirement diagram will be usually generated in order to expose a diagram representing a "requirements perspective" of the product.

However, this is definitively value in being able to "refine" or "document" such a diagram using semantics provided through the underlying requirement metamodel. To do that, designer will conveniently add traceability information, for example dependencies, by editing the generated diagram in order to further characterize relationships between requirements. The edited viewpoint will then be synchronized with the tool where the requirements information is persisted. In the case where requirements are individually persisted and version-controlled, inter-relationships can be also persisted independently or added as annotation to requirements (e.g. as parameters).

The semantics described in the requirement metamodel cover "generally accepted" relationships between requirements, but can be easily augmented. This is most appropriately done in the scope of a design methodology, which will provide a set of semantic objects implemented on top of the requirement metamodel (and more generally on top of SysML). The profile mechanism is the easiest mechanism to realize that. Ideally, the methodology will also govern the authoring of requirements (usually derived from initially provided requirements, for example customer requirements), therefore the authoring of semantic relationships will be driven in the same manner.

The semantics provided by the requirement metamodel are geared towards improving traceability between requirements, but also to bridge the gap between requirements and the design. In addition, it allows the requirements to be explicitly represented by a set of design elements, i.e. using an additional model-based representation. For example using any model described with the rest of the SysML constructs.

Finally and most importantly, the requirement diagram and the attached metamodel are aimed at being an analysis tool. This is the most valuable contribution. Not all requirements against the product need to be expressed through a requirement diagram. However the complex ones, i.e. the ones that require a special attention should be analyzed through a requirement diagram (e.g. generated as output of a analysis process) and an appropriate methodology. Note that to perform the analysis, any model can be used, for instance sequence diagram, activity diagram, etc. However some of the analysis results can be expressed via requirements inter-relationships, and in turn stored within the persistence layer. This is an important mechanism to bridge model and traceability information between stakeholders in the development process. For example, in case people in charge of managing requirements (in particular performing changes), can be different from people performing analysis in relation with a particular aspect of the design (let's say Safety). The results of the analysis, partly translated into semantic relationships between requirements will be identified by safety specialists, but leveraged by the project manager in order to perform general impact analysis stemming from design changes.

My team and I have been developing these concepts and implementing them in Rhapsody and Rational Software Modeler via new tool extensions to support better modeling practices.

I hope that this is helpful, let me know if you have any comments or questions,

Laurent

----
Laurent Balmelli, Ph.D (春芽利　楼蘭）
Manager, IBM's SysML Representative
Systems and Product Lifecycle Research and Development
Rational Development & Services, Yamato Software Lab
1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken
242-8502, Japan
Phone: +81 46 215 4868, Cell +81 80 6597 0578

[David W Oliver]

In the development of requirements it is useful to be able to connect or link them to modeling entities that they represent. Since the modeling entities are finite in number it is possible to facilitate this process with a default set of categories of requirements , each category linked to a particular kind of modeling entity. Without such a  set of default categories, different groups of workeers on the same project are likely to link in different ways. The result is a tangle of information between requirements and important executable models used in analysis, specification, and trade studies.

 

 

----- Original Message -----

From: Laurent L Balmelli

To: sysml...@googlegroups.com

Cc: SysML Forum

Sent: Wednesday, October 07, 2009 10:01 PM

Subject: [SysML Forum] Re: How to capture and distinguish the requirements

[李雪]

Hi，

   Thank you for your suggestion.

   I have met another problem when modelling requirement. when I want to represent the "containment" relationship in the Requirement Diagram, I cannot find the exact method to add the "containment" relationship. By the way, I use the embeddedplus' SysML Plugin to  construct my requirement diagram. "containtment" relationship between requirments is supposed to be represented using  a line with a cross within a circle in the end, but I don't know how to add this symbol, in the environment of SysML Plugin.

  Thank you for your helping very much!

   

2009/9/28 Alberto Sampaio <a...@dei.isep.ipp.pt>

[panda72]

Hi.

I use Embedded Plus' SysML Toolkit in my master thesis.

The solution is to use the model (the structure on the left hand
side).

Drag the requirements over the requirement which should contain them.
When you drag the requirements out into the requirement diagram, you
will get the cross hair symbol.

Tonje

[李雪]

hi,

Thank you very much. According to your suggested method, I have succeeded to add the “containment“ relationship. Thank you for help again! 

2009/10/16 panda72 <panda...@gmail.com>

[李雪]

hi,

I have met some problem in modeling Sequence Diagram. When I use the embeddedplus' SysML Plugin to  construct the Parallel Combined Fragment in the Sequence Diagram, but I don't know how to add the parallel. the Parallel Combined Fragment that I add into the diagram only exhibit one interaction, not several interactions at the same time.

 

so. I wonder how to set  Parallel Combined Fragment in the embeddedplus' SysML Plugin.

 

thank you!

 

2009/9/28 Alberto Sampaio <a...@dei.isep.ipp.pt>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en
-~----------~----~----~----~------~----~------~--~---

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[Alan]

I disagree with some of the statements made above that advocate
continuing a document-based (vice model-based) systems engineering
approach and maintaining a purist view of requirements. An isolated
bunch of experts sitting around in a room writing requirements is a
process fraught with error. Several modern software engineering
techniques attempt to deal with this well-known problem. Requirements
are usually wrong, incomplete and unclear. No set of checklists will
produce perfect requirements.

In model-based systems engineering (MBSE), you discover new
requirements, new requirements decompositions, and errors in
requirements as you define a system's structure and behavior. This is
an analysis and a discovery process based on the formality forced by
modeling.

A tool like Enterprise Architect allows you to easily allocate and
modify requirements, as well as graphically allocate them to the
structural (e.g., components) and behavioral (e.g., use cases) models
of the system. It is 1000 times easier to use that DOORS. DOORS is
at best a glorified database that focuses on traceability --- nothing
else. Many tools can do traceability without torturing the user like
DOORS does.

As far as requirements go, as noted above, packages are containers
for anything, including requirements. One commonly useful partition
of requirements is functional requirements and non-functional
requirements. Someone mentioned "A Practical Guide to SysML" above.
Table 12.1 of that book gives some example stereotypes from SysML that
are also commonly useful, e.g.: Interface Requirements, Physical
Requirements, and Design Constraints.

If you have a lot of requirements, organizing them into categories
helps manage the complexity. This can be done in the SysML
requirements view at least as easily as in hundreds of pages of text
found in a requirements document. In each case, there are typically
categories and sub-categories. In a tool, you can add additional tags
to your requirements, so you can sort them in multiple ways when that
is useful.

Alan

On Sep 28 2009, 3:06 am, Suresh <sureshkumar...@gmail.com> wrote:
> In requirements diagram, one can represent requirements. However,
> requirements comes from different levels (for instance some
> requirements come from customer, some after functional decomposition,
> some from components which satisfy the functions).
>
> How to capture and distinguish the requirements generated at different
> levels using requirements diagram?
>
> Does SysML framework has this support (if not any other pointers to
> how to achieve this).

[Kevin Durand]

Alan,

I appreciate your words of experience. I am sharing with my peers at NASA as we pursue MBSE and SysML here on campus. I am relatively new here but can tell you there is a lot of interest among our Engineering Community.

Thank You,
Kevin Durand
Sr. Systems Engineer
Kevin....@NASA.gov
216-433-2594-office

Sent via BlackBerry by AT&T

-----Original Message-----
From: Alan <jalan...@verizon.net>
Date: Tue, 18 May 2010 09:47:06
To: SysML Forum<sysml...@googlegroups.com>

[Alan]

FYI, I am also looking into translating among SysML, Colored Petri
Nets (CPNs, a mathematically formal modeling methodology), and Agent-
Based M&S.

Alan

[Michael Jesse Chonoles]

Almost all projects that use SysML appear to be still using formal requirements writing. Whether they write their requirements and place them in Doors (or equivalent) or place them in their SysML tool doesn't seem to make any difference as the tool are becoming increasingly more integrated. The stereotypes mentioned in "A Practical Guide to SysML" are a good start, though larger projects tend to need a larger scope of such stereotypes and additional flags. Such stereotypes and flags are easily mapped into the requirements management tools and exchanged.

Use of Doors (or equivalent) with a SysML tool is just using the best tool for it's best purpose, DOORS being good at CM, reporting, and traceability, and the SysML tool being more supportive of modeling. If eventually all the DOORS functionality is moved into the modeling tools, or if instead the tools are transparently integrated, it makes absolutely no difference to the users (except perhaps for cost).

Generally seperate tools with specialized capabilities but exchanging data via standards interfaces is better for the market place competition.

As you say, the DOORS user interface is arcane and requires specialty-trained support. If you're more comfortable with a better tool, or don't need the enhanced reporting/tracability/cm that it supplies, most of the modeling tools will be sufficient. We have found that on the larger projects those features are worth investing in DOORS (or equivalent) learning curve.
Michael

---

From: Kevin Durand <kevin....@nasa.gov>
To: SysML Forum <sysml...@googlegroups.com>
Sent: Tue, May 18, 2010 8:48:28 PM
Subject: Re: [SysML Forum] Re: How to capture and distinguish the requirements

To unsubscribe from this group, send email to sysmlforum+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.

To unsubscribe from this group, send email to sysmlforum+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[Jack Ring]

No such formal ontology.
In fact, INCOSE has given the idea a limp leg for more than four years, now.
Closest thing is the description of terms used in AP233.
Jack Ring

[Jack Ring]

Requirements engineering and model-based system engineering are somewhere between 90 degrees and 180 degrees out of phase. SysML can be used to do part of each but  doesn't, yea, can't harmonize them.

[Richard E. Nance]

Alan,

Please keep in mind that Agent-based M&S is only a modeling perspective
applied to the process interaction conceptual framework enabled by SIMULA
67 and contrasted so well by Phil Kiviat in his classic RAND reports.

Digital Computer Simulation: Modeling Concepts, RAND Memo RM-5378- PR, RAND
Corporation, Santa Monica, California, August 1967.

Digital Computer Simulation: Computer Programming Languages, RAND Memo
RM-5883-PR, RAND Corporation, Santa Monica, January 1969.

In further explanation, the Simula 67 process has all the expressive and
computational capability of the "intelligent agent," but both lack the
potentially chaotic behavior of the original actor concept of Gul Agha.
I bring this to your attention to underscore the strong relationship between
discrete event simulation and the model-based systems engineering approaches
to development and representation.

Richard E. Nance
Emeritus Professor of Computer Science
Virginia Tech

-----Original Message-----
From: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] On
Behalf Of Alan
Sent: Wednesday, May 19, 2010 8:20 AM
To: SysML Forum
Cc: Kevin Durand
Subject: [SysML Forum] Re: How to capture and distinguish the requirements

[Alan]

Richard,

Yes, I understand it's role. My focus is moving between systems
modeling methodologies that have a variety of complementary uses.

Thanks, Alan