Return to Answer

added 677 characters in body

Source Link

edited Oct 9, 2014 at 9:48

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 any trouble with it.

This should be documented inIt depends. If the hardware modules are internal parts of your device, then this doesn't belong in either requirement, nor in software architecture. You tried approach A in the prototype

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 didn't workfor a prototype is irrelevant. Approach B worked greatYour rationale can go to a document related to the hardware.

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

If you are having some kindBetter text (in an agile approach) would be : As a user of plug-insdevice ABC, which your userI want to be able to detach X so that it can write on their ownbe replaced in case of problems.

Yes, then itthis belongs to the requirements. But as it is written, it sounds like modules X and Y are internal things, about which users shouldn't know. ThenAnd it belongs toinfluences the architecturesoftware.

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

Ok, this one is weird. Sounds moreThis doesn't sound like a requirement. Actually, that may be an implementation detailinternal requirement for the HW department, which influences the software as well. As such I would just skipput it in the architecture (we tried to implement this in software, and not include in either document. If it is really critical, then adddidn't go well. We do it somewhere in the architectureHW instead).

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

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.

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.

This should be documented in the architecture. You tried approach A in the prototype, and it didn't work. Approach B worked great.

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.

If you are having some kind of plug-ins, which your user can write on their own, then it belongs to the requirements. But as it is written, it sounds like modules X and Y are internal things, about which users shouldn't know. Then it belongs to the architecture.

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.

Ok, this one is weird. Sounds more like an implementation detail, which I would just skip, and not include in either document. If it is really critical, then add it somewhere in the architecture.

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.

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.

Source Link

answered Oct 9, 2014 at 8:37

BЈовић

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.

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.

This should be documented in the architecture. You tried approach A in the prototype, and it didn't work. Approach B worked great.

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.

Ok, this one is weird. Sounds more like an implementation detail, which I would just skip, and not include in either document. If it is really critical, then add it somewhere in the architecture.