Return to Question

For the development of a next generation of a medical monitoring device consisting of several hardware systems with embedded software, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain architecture for one of the sub-systems and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit within that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of hardware modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Hardware module X shall be physically detachable from hardware module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Hardware module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.

For the development of a next generation of a medical monitoring device consisting of several dedicated hardware systems with embedded software, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain architecture for one of the sub-systems and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit within that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of hardware modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

My problem with it: The end-user wouldn't care how we divide up the system, as long as it is not a burden to work with. I also couldn't see any other stakeholders that would have a vested interest here.

Hardware module X shall be physically detachable from hardware module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

My problem: The intent of the requirement I can agree with and is something the end-user might care about, but I don't see how a requirement can refer to a hardware module whose existence is subject to a design decision that isn't a requirement.

Hardware module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

My problem: It could also have been decided to give hardware module X a more capable processor and let it handle software function S.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.

For the development of a next generation of a medical monitoring device, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain system architecture and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit within that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Module X shall be detachable from module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.

For the development of a next generation of a medical monitoring device consisting of several hardware systems with embedded software, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain architecture for one of the sub-systems and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit within that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of hardware modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Hardware module X shall be physically detachable from hardware module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Hardware module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.

For the development of a next generation of a medical monitoring device, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain system architecture and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit withing that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Module X shall be detachable from module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.

For the development of a next generation of a medical monitoring device, I am looking at the requirements for the current generation of the device to see what can be re-used. During this process, I cam across some requirements that explicitly specify a certain system architecture and requirements that presume that particular architecture.

My question is, is it correct to have such requirements, or should such design decisions really be relegated to an architectural design? I find the requirements that presume an architecture the most troublesome, as they do have merit within that architecture but might be nonsense when a different design had been chosen and it is not always possible to rewrite them in an architecture-independent way.

Some paraphrased examples of the requirements:

The system shall be composed of modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Module X shall be detachable from module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

An additional problem is that at least some of us have a strong belief that all module/software requirements must be traceable to a system requirement, which might not be true any more if those architecture-related requirements get thrown out.