LG 02-02 (V2025) LZ 2-3 (V2023): Proposal to change structure of LG

[Stephan673]

In German the headline is called "Anforderungen klären und berücksichtigen können"

In Eng. Version its translated to "Identify and Consider Factors Influencing Software Architecture"

An Influencing-Factor (Einflussfaktor) is not the same as a Requirement (Anforderung).

Which headline is correct?

Thnaks

KR Stephan

[sippsack]

I understand your concern. I often speak about "Influencing factors" (Einflüsse or Einflussfaktoren in German) for architectural decisions when I introduce constraints (technical, organizational, ...) and qualitity attributes. And these are requirements in my point of view. Constraints are requirements which we can hardly or not at all negotiate and the quality goals are the architectural requirements we can influence.

To align it I would prefer to change the german heading to "Einflüße auf Softwarearchitektur klären und berücksichtigen."

[Stephan673]

Hi,

thank you. I understand. The problem I see is, that the IREB has a bit different definition. An Influencing factor does not exist there. The distinction between requirement and influence factor is often ask by participants because they know the definition of IREP CPRE The general term there is "Requirement" A requirement could be then

• functional
• quality attributes
• constraint

So the german version is more alligned to this IREB definition.

[Stephan673]

Hi,

sorry that i come back to this point again, but I am unsure regarding the ISAQB definition of this topic. I analyzed this topic again and tried to find a structure/explanation which is also aligned to other parts of SE (test, req E.)

I see the main differences here in the specification/definition and realization I agree that more or less all of these things have an influence on the architecture, either there are functional, quality attr, or constraints. So an overall term "influencing factor" is OK, but not more strength then "requirement". The importance of subparts of "requirements" like

• functional req.
• quality attributes
• constraints

cannot not be influenced by us, simply because they are driven by our stakeholders / context around. This has an impact to the definitions / terminology under this LG:

a) Also a "trend" is set outside, and because of business reasons, we have to follow it (e.g. customers expect, that we are innovative and up-to-date.). We do not have an influence on it regarding the creation/importance/need/expectation on market/customer side. Therefore it should be a constraint too. b) A quality objective/goal is set by the company/business. The business decides in which extend a given req. specification should be achieved that a defined level of quality is reached and to satisfy the customer. For example: In medicine are much tighter and harder quality goals defined as for a 93993736th version of a "jump and run" smartphone game.

Our influence is the feasibility and realization, to fulfill these requirements (or not to violate them if they are constraints.) In this manner we can also define additional quality attributes, if they help to fulfill the contextual given ones of the business. For example if the business requires a product line over many years in a high innovative market, maybe "maintainability" as a pre-condition for long-term success is not obvious from the business perspective because of just short-term "release-thinking" (LG 1-7). So here we can additionally define long-term architectural goals. However, also the need for long-term architectural objectives is finally business (domain) driven. For example: In case that we are working in the scope of a customer ordered rapid-prototyping just to give feedback regarding the feasibility, long term thinking would be less or not important.

Based on that thoughts I would propose the following structure.

LG 2-3: Identify and Consider Product Related Requirements Influencing Software Architecture (R1-R3) Software architects are able to clarify and consider requirements (including constraints that restrict their decisions). They understand that their decisions can lead to additional requirements (including constraints) on the system being designed, its architecture, or the development process.

Requirements ("influencing factors")

• functional requirements (what ?)
• quality attributes (how ?) such as
  • e.g 25010
  • architectural goal/objective

• constraints

  • technological such as ...
  • organizational such as ...
  • regulatory such as ...
  • trends such as ...

  What do you think?

Bye Stephan

[Stephan673]

ups structure was destroyed...here again the proposal of the previous comment: ... LG 2-3: Identify and Consider Product Related Requirements Influencing Software Architecture (R1-R3) Software architects are able to clarify and consider requirements (including constraints that restrict their decisions). They understand that their decisions can lead to additional requirements (including constraints) on the system being designed, its architecture, or the development process.

Requirements ("influencing factors")

• functional requirements (what ?)

• quality attributes (how ?) such as : e.g 25010 architectural goal/objective

• constraints: technological such as ... organizational such as ... regulatory such as ... trends such as ... ...

[Stephan673]

In case that we want to focus more on the difference between influence factor and requirement, I would propose this structure. Here the differences would be more on the possibility to influence it. This would be more aligned to your definition and would cause less changes (bit headline, trends as constraint, different constraints under the requirement/constraint topic).

LG 2-3: Identify and Consider Product Related Factors Influencing Software Architecture (R1-R3) Software architects are able to clarify and consider requirements (including constraints that restrict their decisions). They understand that their decisions can lead to additional requirements (including constraints) on the system being designed, its architecture, or the development process.

Requirements

• functional requirements (what ?)
• quality attributes (how ?)
• constraints: technological such as ... organizational such as ... regulatory such as ... trends such as ...

Architectural (quality) objectives

Bye Stephan

[gernotstarke]

I took the liberty to update the title of this issue, as the discussion centers around a new structure, and not the translation.

[gernotstarke]

Proposal: Leave the current version for the release of V2023, as the Working Group won't find the time to discuss and vote a structural update.

Move the issue to the backlog for future discussion. Keep @Stephan673 in the discussion loop.

[mikesperber]

Proposal: Leave the current version for the release of V2023, as the Working Group won't find the time to discuss and vote a structural update.

Move the issue to the backlog for future discussion. Keep @Stephan673 in the discussion loop.

I agree. Note that this issue also plays into the wider discussion on quality we're having elsewhere. It'll take a while to sort it all out.

Note that I see the same category confusion here as elsewhere: "quality attributes" are not requirements - they are merely properties the software has. Formulating requirements on them is a separate step.

Moreover, "functional requirements" are a subcategory of quality requirements as per ISO 250xx, and for good reason. (Unfortunately, it appears IREB gets this wrong as well.)

[Stephan673]

Hi,

thank you. I agree, we can do this also later. I arranged it now according to the cur. like that: -Infl-factor +Req. ++funct. req ++qualt. attr. ++constraint +++ technology +++ organization +++ regulatory +trend +arc obj.

I would recommend that we follow then at least the proposal of sippsack (see above), to have consistent language versions: To align it I would prefer to change the german heading to "Einflüße auf Softwarearchitektur klären und berücksichtigen."

Just a hint: In the current version, some of the product related topics were deleted (e.g. product line, distribution ...) For the topic technology "external factors" were deleted. We should be aware of that also the exam questions are then shortened.

IREB defines constraints, quality attributes (Qualitätsanforderungen), and functional req. as "requirements". Due to the fact that we have now a strategic alliance with IREB, I would recommend a common definition.

That "functional suitability" is listed in 25010 is in my opinion not a contradiction. Functional req. describe "what" the system should do. Quality attributes like 25010 describe "how" these functions should be realized. Functional suitability describes therefore "how" a function should work from a functional perspective (correct, complete, appropriate).

KR Stephan

[mikesperber]

That "functional suitability" is listed in 25010 is in my opinion not a contradiction. Functional req. describe "what" the system should do. Quality attributes like 25010 describe "how" these functions should be realized. Functional suitability describes therefore "how" a function should work from a functional perspective (correct, complete, appropriate).

This is the same category error: "Functional suitability" in 25010 is about the attributes the system has. In 25010, requirements don't enter the picture. Moreover, "how a system works from a functional perspective" is its functionality - requirements on that are functional requirements.

I did notice IREB made the same error - that's not a good reeson to make the same over here.

The distinction between "how" and "what" is IMHO largely meaningless, and definitely irrelevant for software architecture - there's no "what" without a "how".

[mahboubagharbi]

"How well the system should do the function" 😉

[Hruschka]

The TQM definition of quality = fulfilment of requirements. So any quality, including functional suitability is about requirements. Id no stakeholder requires a quality you should not bother about it.Regards PeterVon meinem iPhone gesendetAm 15.03.2023 um 09:00 schrieb Mahbouba Gharbi @.***>: "How well the system should do the function" 😉

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mikesperber]

@Hruschka I understand, but ISO 250xx uses a different definition - which also happens to be more in line with what the word means in common usage ("characteristic, property, condition"). (This is also what @gernotstarke usually cites in his talks.) This IMHO is also the more useful definition for us, but the argument for that is longer.

But I think this issue will take a meeting (or several) to resolve.

[gernotstarke]

FLWG: close, appropriate changes have been implemented by @sippsack and @ulibecker