{"id":399,"date":"2016-04-07T08:00:39","date_gmt":"2016-04-07T06:00:39","guid":{"rendered":"https:\/\/se-trends.de\/?p=399"},"modified":"2017-06-22T08:15:53","modified_gmt":"2017-06-22T06:15:53","slug":"from-the-requirement-to-the-model","status":"publish","type":"post","link":"https:\/\/www.se-trends.de\/en\/von-der-anforderung-zum-modell\/","title":{"rendered":"From the requirement to the model"},"content":{"rendered":"

An important discipline of systems engineering is the analysis of requirements. There are enough studies to prove that solving a problem in the requirements phase is orders of magnitude cheaper than in later phases. Requirements analysis is therefore of particular importance. In this article, I present a method for going from requirements to a solid model.<\/p>\n

The Cimatti method<\/h3>\n

This is based on the scientific work of Alessandro Cimatti et al, but that shouldn't put anyone off. In his paper From Informal Requirements to Property-Driven Formal Validation<\/a> Cimatti aims to formalize the requirements completely. I will limit myself here to the first step of a practical requirements analysis, which is an excellent preparation for subsequent modeling - regardless of which modeling language is chosen.<\/p>\n

The method is realized by a chain of tools based on de facto industry standards (such as Rational RequisitePro and Software Architect), together with an extended version of the NuSMV Model Checker. (Cimatti et. al.)<\/p><\/blockquote>\n

Cimatti deals with four challenges: Firstly<\/strong> natural language is inherently vague. Secondly<\/strong> there are often requirements that apply to the entire system and are therefore not easy to model. Thirdly<\/strong> often lack clear criteria for evaluation during validation. Less relevant for this article is the fourth<\/strong> Challenge: Formal modeling languages are not necessarily suitable for formal verification.<\/p>\n

Cimatti divides the work into three phases: In the first phase<\/strong> the requirements are broken down into sentence fragments and classified. I will describe this here.<\/p>\n

In the second phase<\/strong> the fragments are formalized in different ways, depending on the classification. In the third phase<\/strong> a formal analysis is carried out to detect problems such as inconsistencies and others.<\/p>\n

Classification of request fragments<\/h3>\n

It is not uncommon to classify requirements. A classic is the division into functional and non-functional requirements. But Cimatti's classification is particularly suitable for subsequent modeling. Before we start breaking down the requirements into fragments, let's take a look at the categories. The associated questions help to categorize them:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Condition for fragment<\/strong><\/td>\nCategory<\/strong><\/td>\n<\/tr>\n
Does the fragment define a concept of the domain?<\/td>\nGlossary<\/td>\n<\/tr>\n
Does the fragment describe a system module, and does it describe how modules interact?<\/td>\nArchitecture<\/td>\n<\/tr>\n
Does the fragment describe the steps that a module performs or the states that a module can assume?<\/td>\nFunctional<\/td>\n<\/tr>\n
Does the fragment describe messages that are exchanged between modules?<\/td>\nCommunication<\/td>\n<\/tr>\n
Does the fragment describe conditions or limitations of the future system?<\/td>\nBehavior<\/td>\n<\/tr>\n
Does the fragment describe restrictions regarding the environment or operating environment?<\/td>\nOperating environment<\/td>\n<\/tr>\n
Does the fragment describe a possible scenario of the domain?<\/td>\nScenario<\/td>\n<\/tr>\n
Does the fragment describe an expected property of the domain?<\/td>\nFeature<\/td>\n<\/tr>\n
Is the fragment an annotation in the specification that does not describe any information about the ontology or behavior of the specified system?<\/td>\nRemark<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The tried-and-tested elevator was used as an example and the following requirement was considered (whether this is a good \"requirement\" remains to be seen):<\/p>\n

Requirement:<\/strong> A typical elevator includes call buttons for selecting a floor.<\/p>\n

A number of fragments can be extracted from these requirements. Firstly, there are the three glossary fragments \"elevator\", \"call button\" and \"floor\". The fragment \"Selecting a floor\" is functional. There are more examples in the technical article.<\/p>\n

Relationships between fragments<\/h3>\n

In the next step, Cimatti establishes relationships between the fragments. Since he is aiming for a rigorous approach, this makes sense. When it comes to systems that are not safety-critical, this is certainly not absolutely necessary. Cimatti recognizes the relationships \"strong dependency\", \"weak dependency\" and \"refinement\".<\/p>\n

Modeling the fragments<\/h3>\n

Cimatti is concerned with complete modeling. To achieve this, he uses popular modeling languages such as UML whenever possible. The class diagram in the image above, for example, shows the glossary. However, this is not sufficient for all fragments, which is why he also uses more academic languages such as CNL (Controlled Natural Language) and LTL (Linear Time temporal Logic).<\/p>\n

How you proceed now depends on the specific project and the objectives. In my experience, it is difficult enough to gain acceptance for UML in practice. In this respect, I would recommend getting by with a mixture of UML and text. Even the cleanly classified fragments are an excellent basis for any further development.<\/p>\n

Here is my recommendation for UML-based development. At the end of the day, every project has different needs that need to be taken into account for the specific modeling approach.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Category
\n<\/strong><\/td>\n		Recommended UML model element<\/strong><\/td>\nCimatti<\/strong><\/td>\n<\/tr>\n
Glossary<\/td>\n\u00a0class diagram. This is also the recommendation of Cimatti<\/td>\n\u00a0UML classes<\/td>\n<\/tr>\n
Architecture<\/td>\n\u00a0Depending on the system, a component diagram or distribution diagram can be used here. A simple textual description may also be sufficient.<\/td>\n\u00a0-\/-<\/td>\n<\/tr>\n
Functional<\/td>\n\u00a0Cimatti recommends state diagrams, but activity diagrams can also be used here, sometimes the operations of classes are also sufficient.<\/td>\n\u00a0UML state diagrams<\/td>\n<\/tr>\n
Communication<\/td>\n\u00a0Communication diagrams or sequence diagrams can be used here.<\/td>\n\u00a0-\/-<\/td>\n<\/tr>\n
Behavior<\/td>\n\u00a0Here I recommend the use of constraints, which are supported by many UML elements.<\/td>\n\u00a0CNL<\/td>\n<\/tr>\n
Operating environment<\/td>\n\u00a0These can also be recorded with constraints, or centrally in natural language.<\/td>\n\u00a0CNL<\/td>\n<\/tr>\n
Scenario<\/td>\n\u00a0While Cimatti recommends sequence diagrams, application diagrams can also be used here.<\/td>\n\u00a0Sequence diagrams<\/td>\n<\/tr>\n
Feature<\/td>\n\u00a0Properties are classically modeled as constraints<\/td>\n\u00a0CNL<\/td>\n<\/tr>\n
Remark<\/td>\n\u00a0UML notes are the classic tool for annotations. However, these often also fit into the description of elements or into the package description.<\/td>\n\u00a0-\/-<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Conclusion<\/h3>\n

Actually, only two \"tools\" for requirements analysis were presented here: Breaking requirements down into fragments and classifying them. What is new here is that classification is ideally suited for subsequent modeling.<\/p>\n

I can recommend reading the whole Papers by Cimatti et al.<\/a> recommend. For really security-critical systems, the effort may even be worthwhile. For everything else, you have to cherry-pick - for example, the ones just presented.<\/p>\n

Image source: Alessandro Cimatti<\/span><\/p>","protected":false},"excerpt":{"rendered":"

An important discipline of systems engineering is the analysis of requirements. There are enough studies to prove that solving a problem in the requirements phase is orders of magnitude cheaper than in later phases. Requirements analysis is therefore of particular importance. In this article, I present a method to go from requirements to a solid model...<\/p>","protected":false},"author":1,"featured_media":407,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[110,4],"tags":[100,99,101,52,63],"class_list":["post-399","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-anforderungen","category-forschung","tag-anforderungen","tag-cimatti","tag-klassifizierung","tag-lehre","tag-modellierung"],"_links":{"self":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts\/399","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/comments?post=399"}],"version-history":[{"count":0,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts\/399\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/media\/407"}],"wp:attachment":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/media?parent=399"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/categories?post=399"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/tags?post=399"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}