- There is an aspiration to have something that a system specifier can give to sub-system designers that sets out what test support capabilities the sub-system should provide.
- There is an aspiration to have something that a COTS vendor can use to advertise to prospective customers what test support capabilities they can expect (which may have different "levels").
- There is an aspiration to have something that a system/sub-system designer can use to help select parts that have appropriate test support features and use them within a suitable architecture.
- There is an aspiration to have something that test designers/ATPGs can use to understand the test capabilities that are provided by the system/sub-systems.
1 is about specifying requirements but it feels like it works best (maybe only works) when it goes along with a standardised form factor for the sub-assembly that defines what interfaces are to be provided. I guess that can include in-house system designs with a supporting Interface Control Document, but I'm wondering if that ends up putting the cart before the horse.
When I first got involved with this group, I think 3 is what I was expecting SJTAG was going to answer for me, but the longer I've been involved, the less I feel that's necessary - there are often bigger functional issues on component selection that will trump testability (unfortunately), and once you've sorted out a few basics the "architecture" side isn't a huge deal. Instead, I've moved towards seeing 4 as being the problem that most wants to be addressed; it's probably the harder task.
In the broad perspective, all of the above indeed fit into the scope of "system test", but we're not trying to solve all of system test for all perspectives of what that might mean - that's just way too big a task. We need to pick our fight(s) carefully.