Metrics for Defining the Complexity Level

I was sitting in a meeting when a whole bunch of folks started sharing ideas on how to assess the level of risk associated with a project or system under development (SUD). Some thoughts were to consider the number of requirements, others the number of change requests needed, and some suggested the level of engineering support needed for a requirement to be realized, for example does the requirement call for an architectural change, design change, development change, or just test or only support during testing.

I agree with the last proposal, analyzing the scope of changes is a good way of defining the complexity and hence the risk of the project, then we can create metrics that reflect these different levels of engineering support. Merely looking a total number of requirement, change requests or development teams involved might not provide the most accurate assessment. Instead, the system architecture needs to analyze and study the requirements impact and assess design complications, development challenges, testing validity and deployment issues. This integrated view can provide a more objective feel for the level of complexity involved in the SUD. A system might have only two system level requirements that drive the whole architecture change and hence brings in large design, development, testing, deployment and support efforts, compared to another system which has 2 dozen requirements which marginally impact development and will hence have a much lower effort in other areas and less overall complexity and risk.

I came across some interesting articles and papers on this topic.

A Complexity Assessment Methodology for Programmable Electronic Mining Systems
Software Complexity Measurement
Design Complexity Measurement and Testing
A Function Point Method for Software Complexity Measurement

How do you assess the complexity of a project in your environment?