Independence between functions or items protects against common development errors and is weighed when assigning levels, with confidence commensurate with the failure condition severity. Of the four attributes, functional independence (different functions, so different requirements, minimizing common requirement and interpretation errors, substantiated by analysis at all levels of decomposition, with the requirements that keep it managed throughout development) and item development independence (different item designs, for example different operating systems, languages, microprocessors, or teams and processes, minimizing common design, development and tool errors, substantiated in the light of the state of the art and service experience; not claimable if common error sources cannot be minimized) are the two used when assigning FDALs and IDALs. Physical independence (separation or segregation against common failures, damage or environmental effects) and process independence (an objective check by a person other than the one who did the work, for instance validation not left solely to the requirement's author) are not used for assignment; process independence may be used afterwards to reduce development errors. Functional independence protects the requirements from a common error; item development independence protects the item designs.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.