4

I am currently working on the definition of the documentation architecture of a system, from customers needs to software/hardware requirements. I encounter a big problem with the level of refinement of requirements.

The classic architecture is : PTS --> SSS --> SSDD --> SRS/HRS with PTS : Purshaser Technical Specification SSS : Supplier System Specification SSDD : System Segment Design Description SRS / HRS : Software / Hardware Requirement Specification.

Requirements from PTS are reworked in SSS, this document only expressed the needs (no design requirements are defined at this level). Then, the system design is described in SSDD : we allocate requirements from the SSS to functions from the design and functions are then allocated to component (Software or hardware) (we are still at the SSDD level). Finally, for each component, we write one SRS or one HRS. Requirements in SRS or HRS are refinement of requirements from SSS (and traceability matrix are made between these two levels).

My problem is the following one :

Our system is a complex one, and some of the requirements in the SSS needs to be refined twice to be at the right level in the SRS (means that software people can understand the requirement to make their coding). But, with this document architecture, I can only refine once the requirements from the SSS. The second problem is that only a part of the requirements from the SSS needs to be refined twice. The other part only need one refinement.

On the picture below, the green boxes are requirements at the right level for SRS or HRS. And purple boxes are intermediate requirements which can not be included in SSS since they are design requirements. Where can I put these purple requirements ??

Is there someone who has already encountered this problem ? Should I write two documents at SRS level ? Should I include intermediate requirements in SSDD ? Should I includes the two refinement levels (purple and green) in the same SRS document (not sure that's possible since a SRS is only for one component) ???

Thanks for your help and expertise ;-)

Requirement refinement

user107149
  • 41
  • 1
  • 2
  • 2
    Your description is really confusing, especially by what your definition of PTS, SSS, SSDD, SRS and HRS are. Maybe some examples would help clarify? – Dunk Nov 07 '13 at 17:55

3 Answers3

2

The purpose of specification refinement is twofold:

  • Translate higher level requirements to something usable by developers: e.g., from I want a "Google Maps" with space imagery to The spacecraft shall follow a polar orbit to a bunch of equipements --sensors and actuators-- and a software implemented control loop involving quaternions and some real time OS.

  • Provide a way to check that every customer need has been implemented, through traceability.

Therefore, you only have to make clear whether Req 3.1 is entirely implemented by Req 4.1, so that the developer either focuses on Req 4.1 (and I would put Req 3.1 in SSS) or has to implement both Req 3.1 and Req 4.1 (and I would put Req 3.1 in SRS).

mouviciel
  • 15,473
  • 1
  • 37
  • 64
0

Since the question is vague I'll answer 2 ways.

1) Assuming that your system only has 1 configuration item, which is why that document appears to be missing in your above description then you are merely mapping SSS Requirements to Hardware and Software Documents. In which case, there are no "Purple" requirements. The people writing the SRS/HRS are responsible for turning the SSS Requirement (possibly using the SSDD and any DIDs as a reference, which might be where your "purple" requirements come from) and turning those SSS and derived requirements into the appropriate SRS/HRS requirement.

2) If your system has multiple Configuration Items then the SSS Requirements are mapped to the "Configuration Item" Performance Specification Document. This document is where your "Purple" Requirements would go along with module specific reinterpretations of the SSS Requirements mapped to it (again possibly using the SSDD/DIDs as reference). Then that document is used to map down to the hardware and software which are then used to create a separate SRS/HRS. I suspect this is what you are trying to do.

Dunk
  • 5,059
  • 1
  • 20
  • 25
0

If you had a spec that said 'we need a an aircraft carrier with a flag' then it would obviously be insane to split the system into those two parts, and then specify the carrier and the flag to the same level of detail.

Most such formal development standards recognise this, and have some way of tailoring the level of decomposition and traceability to something that makes more sense contextually. The problem is that this tends to get treated as an advanced special case you would learn how to do properly sometime after you have specified and delivered your third aircraft carrier.

Which is a lot to ask of a flag supplier.

I suspect that the issue is that the elements listed in the SSS should be ones that are appropriately sized for being specified in the standard way. If that split is wrong, it should be changed so that it is right. Hopefully that doesn't have contractual implications.

soru
  • 3,625
  • 23
  • 15
  • 1
    You would be surprised at the level of detail that simplistic things need in order to get what you want. For example, while not written as a formal "word" requirement, mechanical drawings are usually submitted to subcontractors that spell out with extreme precision what the subcontractor is to provide. This includes mundane things like sticker sizes, locations and tolerance levels. It may seem of little importance if a sticker is off by 3 mm, but if that means you have to disassemble the product to view a serial number then that 3 mm difference will cost lots of money to manufacturers. – Dunk Apr 07 '14 at 15:25