2

My question actually applies to a physical device development, but I guess it is equivalent to a software development workflow, so perhaps someone here can enlighten me.

Sometimes we've got requirements on the very top levels (system design level or even above, i.e. platform level and so on) that contain detailed implementation specifics. Examples:

  1. A non-functional requirement can come from above stating that the electrical interfaces of the whole product must conform to a specific safety norm, which describes all isolation, resistance and electrical values/characteristics. That has to be however passed on throughout all levels until it reaches the hardware design level (or module level), which has to take these values into consideration when choosing the physical connector.

  2. A functional or non-functional requirement can come from above stating how a specific interface should behave or what electrical characteristics it must contain in order to be connected or communicate with a specific external device. Here it also may be already defined which hardware electrical characteristics this interface must contain or even how a specific protocol should be followed for this external communication.

In these both examples we have there restraints coming from the very top levels, as the whole device/system is meant to achieve those goals when built (communicate with external systems or follow some country standard). Now I am struggling to break down these requirements to the lower levels. I can only picture these 2 approaches currently:

A. (SYS-REQ-01)System must comply with norm XYZ -> (COMP-REQ-01)External connectors must comply with norm XYZ -> (MOD-REQ-01)Connector K must comply with norm XYZ

B. (SYS-REQ-01)System must comply with norm XYZ -> (COMP-REQ-01)External connectors must comply with norm mentioned on SYS-REQ-01 -> (MOD-REQ-01)Connector K must comply with norm according to COMP-REQ-01, detailed on SYS-REQ-01

In the solution A we have the advantage that each layer must only "see" the immediately above layer in order to break down its requirements, whereas in B, the Component level must go up to System level to find out the needed characteristics. On the other hand, A can easily become redundant (i.e. when the system anyways only has the connector K as interface, all levels are saying the same with different words), whereas B is clearly linking everything to the norm XYZ mentioned just once.

Both of them are still not feeling the best way to approach this problem. When considering the example 2, it gets even worse. For example, if system level defines that one specific interface is needed to communicate with a given external system (i.e. SPI pins with a given baudrate), that would easily be repeated on the component level, since there is not much to break down.

Any tips to tackle this issue would be much appreciated.

EDIT: As pointed above, solution A and solution B have drawbacks considering what I believe to be best practices of system design (either redundancy, i.e. replicate of same requirement throughout different levels, or indirect linkage from one level to multiple levels above/below). Does any one know another approach that would avoid these two issues?

Improve this question
8
  • 3
    You have two options. Both seem valid. You have one that you feel is better. What else are you looking for? Keep in mind that resource or reference requests are not permitted here.
    – Thomas Owens ♦
    Commented Aug 6 at 10:50
  • 2
    This sounds like a tool-specific problem. But we don't deal with tool use here, either. Redundancy can be solved with parameterized requirements, for example - style A where you parameterize "norm XYZ" and use that in all levels would work, since changing the parameter would cascade the change. But not all requirements management tools support parameterized requirements. User rights is also a tool configuration issue and people shouldn't have any issues reading the full chain of requirements, even if you restrict editing. I don't see good questions for this venue yet.
    – Thomas Owens ♦
    Commented Aug 6 at 11:35
  • 1
    I don't see a tool question here, but rather a question on how to write subsystem and component requirements, when the top-level system requirement is to implement a particular norm. That is an answerable question.
    – Bart van Ingen Schenau
    Commented Aug 6 at 12:02
  • 1
    You are overthinking this. What you are dealing with here are known as constraints. These constraints should be integrated in your architecture decisions and should also be visible at low level. Don't try to engineer something that's supposed to be straightforward and simple to understand for anyone. Simply reference these constraints wherever necessary.
    – Ccm
    Commented Aug 6 at 12:57
  • 3
    "the whole product must conform to a specific safety norm" is not an implementation detail. An implementation detail is a detail which is only relevant to those who are implementing it. Adhering to an external standard is effectively a business requirement.
    – Flater
    Commented Aug 7 at 5:35

4 Answers 4

Reset to default
1

A. (SYS-REQ-01)System must comply with norm XYZ -> (COMP-REQ-01)External connectors must comply with norm XYZ -> (MOD-REQ-01)Connector K must comply with norm XYZ

This is one way to pass the requirement down and it works best if the developers at the component and/or module level need to know and understand the majority of norm XYZ to create a compliant design.

If only certain sub-sections of norm XYZ are relevant for the external connectors, you can also have a breakdown like

  1. (SYS-REQ-01)System must comply with norm XYZ -> (COMP-REQ-01)External connectors must comply with sections 24 and 42 of norm XYZ -> (MOD-REQ-01)Connector K must comply with sections 24 and 42 of norm XYZ

And while the COMP-REQ-01 and MOD-REQ-01 still state the same thing, I would not consider one of them redundant. It is inevitable that you will run into situations where a particular requirement must be passed on in its entirely to the next lower level. That can be both the result of the nature of the requirement (typically when compliance is involved) or of a design decision.

Besides that, a good requirement contains additional information, like linkage to the above and below layers or who brought up the requirement.

The advantage of norms and protocols used for interoperability is that they typically change so slowly that it is quite rare to have a requirements change during a project on which norms to comply with. Interoperability requirements might change more often, but both kinds of changes have a big impact on a project. That makes it even more important that the architects working at the higher levels are aware of the norm and interoperability requirements, so they can properly assess the impact of a change. And the developers at the lower levels naturally also need to be aware to be able to design a compliant system. So, there is not really a level where you could leave those requirements out, even if they look nearly identical.

B. (SYS-REQ-01)System must comply with norm XYZ -> (COMP-REQ-01)External connectors must comply with norm mentioned on SYS-REQ-01 -> (MOD-REQ-01)Connector K must comply with norm according to COMP-REQ-01, detailed on SYS-REQ-01

This I would not recommend. While it makes it easy to change the referenced norm, it is more important that the developers at the lower level(s) can immediately see which norm they have to comply with.

Besides that, as mentioned before, it is very rare that during a project the set of norms that you have to comply with change, so making that change easy should not be a consideration. A change in norms (even to a new revision of the same norm) has a much bigger impact on the project than just the effort to update the norm reference in N linked requirements.

Improve this answer
2
  • Interesting approach. But considering a physical constraint (i.e. power line must be 24V). This is something that mainly only affects the lowest level, designing the physical board. All other layers need only to state that there is a power line, regardless of it's value. In this case, that information becomes irrelevant for the upper layers, no? However, it is indeed decided from the top layer designers and must achieve the bottom layer. That is where in my head it starts getting messy... (how to achieve that)
    – felipe
    Commented Aug 7 at 9:21
  • @felipe, it is very relevant also to the intermediate layers that there is no design freedom with regards to the voltage on that power line. If that knowledge isn´t present at all levels in the requirements, someone on those middle layers could start making wrong decisions, like modifying the requirement to allow a 5V power line (and I have seen that exact problem in practice. As the power line provided power to read a switch, this only resulted in intermittent failures and was caught only when thousands of products were already shipped).
    – Bart van Ingen Schenau
    Commented Aug 7 at 14:45
5

In my experience, none of your approaches makes really sense. A high level requirement is always one which might affect different modules or components, but which ones is not subject of the step of requirements gathering - we should assume we don't know which levels are affected from it. So it just gets a number like REQ-01.

Getting from there to lower-level requirements for certain modules or components requires an extra step - an impact analysis which tries to answer the questions

  • which modules will be affected by REQ-01?

  • what does "comply to norm XYZ" specificially mean for module no1, no 2, no 3?

Here, one has to read and understand the REQ-01 documents like the norm, take the existing modules into account and find out what impact REQ-01 will have on module 1,2, and 3, if any or if a new module is needed.

This results in lower-level requirements, for example a requirement for module 2 M002-REQ01 like "must implement protocol Foo".

Of course, this works best when one can describe requirements as changes to an existing system, in an iterative fashion, not in a pure waterfall approach.

Improve this answer
2
  • I also like this approach, if an implementation detail does not affect at all the design of a higher level, it should not be mentioned there. The counter argument (which also makes sense), is that these constraints are not decided by the lower level designers, but rather from the higher level ones. So in this case you mean it would be fine that the system architect would be the one that writes a constraint into the module requirements document, so to say? If not, how does it come formally from the system architect's hands to the module's architect?
    – felipe
    Commented Aug 7 at 9:15
  • @felipe: an analyst who knows the system well and the responsibilities of the different modules can surely work out the requirements for the different modules from a given high-level requirement. But in most organizations I have seen, this would be a team task - if there are really different people involved, with different expertise, they have to talk to each other.
    – Doc Brown
    Commented Aug 7 at 18:43
1

From my experience in medical device development, I have separate observations on your two input points:

  1. A non-functional requirement is orthogonal to the functional requirements anyway, and can be treated separately. At a high level, it needs no detail - if there is a specific safety norm, mention the safety norm (or process norm). What is in that norm is irrelevant at that level - only that the norm is satisfied. You may decide to add actual details of the norm at the actual level that you want the engineers to work with, or you can just refer to a relevant, up-to-date version of the norm documentation at that level, so that engineers can find it. Put detail where it is needed. There's no real redundancy here beyond what you would expect anyway (norms and standards tend to get repeated, a lot, across all the documentation).

  2. Details on how an interface should behave do not belong at high level. Per your example - at high level if your device needs to communicate with a specific external device, that's all the information that's needed. Let the lower levels figure out what that means technically - both the specs for the external device and the best way to implement it for yours. Similar for other interface - I've seen the temptation for it to be defined very early on / high level, but just don't. Describe the goals for the interface - let the lower levels figure out the best way to hit those goals.

Improve this answer
4
  • Agreed. This was also my argument at work but the counter argument states "the communication details is defined already at top level by system architects because they are the ones that know with whom we will interface. Therefore it is a top level constraint". So even though only lower levels need this information, it is still decided at the top level. My suggestion was that the top level designers than write lower levels contraints directly on their layers, but I am not sure if that is a good practice. The writer of lower level requirements should be a lower level engineer, or not necessarily?
    – felipe
    Commented Aug 7 at 9:26
  • @felipe - stratification or "silos" are bad - when working on medical devices we were often working on multiple levels at once if we had the cross-cutting knowledge. Sometimes in groups - me as an engineer with technical knowledge, someone with clinical knowledge of the product, and someone from testing to ensure that the requirement was written in a testable way.
    – Joris Timmermans
    Commented Aug 7 at 9:36
  • So you mean it is not necessarily considered bad practice if one, for example, creates a kind of "global constraints document" and everyone, that hast a constraint to add, could add it to this document, stating to which level it should apply? Then, this constraint would be only be fed as input to that specific layer when modelling that layer, even though the constraint writer is not necessarily part of the development/architect team of that layer?
    – felipe
    Commented Aug 7 at 12:20
  • 1
    No, not a global constraints document - but making sure that at high-level there were only high-level descriptions, with the details of their implications at lower levels possibly written at the same time by the same group of people.
    – Joris Timmermans
    Commented Aug 7 at 12:36
1

I would go with option A. A requirement document is easiest to read if the requirements can be understood by themselves, without constantly referencing out to other requirement documents.

Sometimes that means that a requirement on a sub-system is an exact cut-and-paste of the higher level requirement. Live with it.

Improve this answer
3
  • It does increase the independency between levels doing like this, agreed. However it also introduces overhead and inconsistency chances, no? If the above layer for example chance it's requirement, all other layers must be watching out and update its own "copy/paste" version of it. That was the reason I wanted to avoid that approach at first
    – felipe
    Commented Aug 7 at 9:18
  • 1
    @felipe Changing high-level requirements is always hard work, and requires care to ensure consistency. Using "See top level requirement 123" risks people not noticing that their requirements have changed. Maybe requirement 123 has been reassigned to a different subsystem, or even deleted.
    – Simon B
    Commented Aug 7 at 15:13
  • @felipe, even without "copy/paste" requirements, you need to carefully inspect all derived requirements for consistency with the source requirement if that source changes. Maybe it changed in a way that makes some of the breakdown invalid.
    – Bart van Ingen Schenau
    Commented Aug 9 at 9:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.