Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.software-eng Subject: Re: Metric for Requirements Complexity? Keywords: SRS, FS, metrics, system complexity Message-ID: <1991May24.200548.13851@netcom.COM> Date: 24 May 91 20:05:48 GMT References: Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 30 Requirements usually specify things like the number of languages, development hosts, targets, configurations, programming paradigms (e.g. AI, real-time, MIS). You also usually know the number of contractors involved, the number of sites involved, and the mapping of processes to processors. All of these factors contribute to complexity, so it seems that you could devise a metric that assigned weights to each factor and did the arithmetic to arrive at a number or set of numbers that said, essentially "This proposed system as specified in these requirements is about a 7 on a scale of ten.". I found it interesting in thinking about your question that the factors that I've found to most affect complexity ARE available in the requirements (explicitly or implicitly). It is not so much the implementation details of whether one uses one sort algorithm vs another that have an impact on the overall complexity of the project--it is the macro-scale factors listed above that determine the true complexity. There are other things affecting the success of a project that aren't directly related to complexity: the sophistication of the development environments used, the skill levels of the people on the team, the quality of the interpersonal dynamics on the team, etc. These are NOT usually in the requirements, but might need to be taken into account to normalize your comparisons of SRSs. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *