Codifying architecture in requirements

Question

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.

Answer 1

In principle requirements should deal with the problem space and not the solution space. However when you are working with medical devices there is a regulatory justification to include this as a design constraint as you must be able to prove certain behaviour. This is especially true when it comes to proving changes, where a defined independence between modules will make it easier to explain to regulators.

The rationales that you show don't really line up well with what I said above, but you also have to consider that there are some implied hardware constraints which you have to live with (ex computing power in module Y).

So I think this has to be considered as a design constraint. Stating it as a requirement will ensure that someone doesn't decide to change this without triggering a review.

Answer 2

"The system must use Windows technologies" may be a requirement because the end-user is a Windows shop and cannot run, say, Linux solutions. This is an architectural decision but will still be part of the user requirements.

Similarly modularizing along these lines might have a good reason based on the end-user's systems where these broad components must be defined in this way, you can still implement them any way you like of course.

Sometimes architectural decisions are part of the requirements, consider the most common example of whether an application will be a webapp or a desktop one. This is definitely an architectural decision, yet will often be seem in user requirements.

So whether your particular requirements are just an overzealous, micromanaging customer, or have some grounding in sensible reasons isn't something we can tell. It might depend how 'module' is defined, if they're running on a suite of hardware boxes then they sound quite realistic. If you're writing a monolithic desktop application and they're analogous to dlls, then they're probably not sensible and you should push back on them.

PS. If you require strong traceability, you cannot map everything to a user requirement as many aspects will not be defined by the end-user. In these cases, you will have to map them to a design requirement that you define yourselves.

Answer 3

No, what you wrote doesn't belong to requirements, but to the architecture.

The requirements consists of user wishes, and users shouldn't know and shouldn't care whether you used library X, or module Y.

Also, adding rationales to requirements doesn't make sense.

---

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.

It depends. If the hardware modules are internal parts of your device, then this doesn't belong in either requirement, nor in software architecture.

But, if the hardware modules are something users can plug in and out, then they do belong to requirements. For example, they want to be able to connect USB sticks. Or they want to connect a specific probe to an ultra sound system.

The fact that you did it for a prototype is irrelevant. Your rationale can go to a document related to the hardware.

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.

Better text (in an agile approach) would be : As a user of device ABC, I want to be able to detach X so that it can be replaced in case of problems.

Yes, this belongs to requirements. And it influences the software.

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.

This doesn't sound like a requirement. Actually, that may be an internal requirement for the HW department, which influences the software as well. As such I would put it in the architecture (we tried to implement this in software, and it didn't go well. We do it in HW instead).

This doesn't belong to user requirements, because user doesn't care how you implemented some functionality.