The 2nd Semat Workshop
2010/07/23
Following the first Semat workshop in Zurich on March 2010, the second Semat workshop took place in Washington D.C. on July 13–14, 2010. The workshop was attended by 21 people who have been actively involved in the contributions and discussions of the six Semat tracks’ activities. The workshop’s atmosphere was very positive, accompanied by rigorous discussions, constructive comments, and a collaborative spirit. The general consensus of the meeting is that we are making steady progress towards the goals laid out before and will reach our one-year milestone with anticipated results. Please find the full report by Shihong Huang on the Semat website.
The 3rdSemat workshop will be held on September 30–October 1, 2010, at the PricewaterhouseCoopers (PwC) Office in Milan, in the “Il Sole 24 Ore” headquarters building, designed by Renzo Piano architect. There will be a pre-meeting day on September 29 for individual track preparations. The 3rd workshop will be co-located with the 5th International Forum on Agile Modeling Architecture. Detailed information of this event will be posted on the Semat website.
2010/07/30 at 07:21
The last paragraph of Domain_definition_v_1.3.pdf says: “[The kernel language] shall have at least two conrete syntaxes, a graphical form and optionally a textual.”
Why is it a primary requirement to have at least two syntaxes? I also find it difficult to understand the exact meaning of the sentence. Does it mean there must be two _kinds_ of syntaxes, one of which _must_ be graphical, and the other _may_ be textual, but maybe something else?
I see syntax as no different from any other artifact: don’t do it unless some usage really requires it. I assume you have already identified usage for a graphical syntax. But what usage dictates the _number_ of syntaxes?
This is just speculation, but from other contexts I would predict that a textual syntax will come handy, often even more than a graphical (difficult to process) one.
I see more often textual descriptions of formal languages (e.g. BNF) than graphical ones, and most of the time the graphical ones are more difficult to read.
I’m pretty sure I misunderstood something really bad, so if I’m not the only one, this part may need some more explanation.
2010/09/09 at 21:08
It is hard to keep track of all that’s happening with groups here and there, and a lack of introduction for the Universals track (which are quite important) is really annoying.
Also, teleconferences can usually be recorded as MP3s by the teleconference operator and it would be great to have them available (have been working with clients when they were occuring).
2010/09/14 at 05:55
I have been reading the documents available on your website and various blogs looking for information about SEMAT’s view on requirements engineering (for a school project). I have been unable to find any such information.
Have you formulated a view on requirements engineering, if so where can I read about it?
From what I have read I have gathered that SEMAT is still in an early stage and that there may not be that much information about requirements engineering yet. If there is no information, when do you think such information will be available?
2010/09/14 at 06:11
Initially Semat is working on a generic approach to describe methods based on a few ideas including:
– Each method can be described as a composition of practices
– A practice is described in terms of a small set of universals and a language
– The universals and the language constitute a kernel
We are now in the process of identifying and defining the universals and developing the language. We will assess the work we are doing against a set of requirements also developed within Semat. These requirements of Semat have been specified by industry representatives.
The work on specific practices will not start until we have delivered what I just described, say April 1 next year.
You are interested in specific practices related to requirement engineering. This is not on the agenda right now, but it will most likely be there next year.