Static Requirements Analysis

Home » Static Requirements Analysis

Definition:  Static Requirements Analysis is the automated testing of software requirements for quality and measurement.


Software requirements, or user stories, are written statements describing the functional need and purpose of software to be developed.  Authors of these user stories will typically write them from the perspective of a business user.   It is then the job of the developer to read the user stories, and design and code to meet these needs.  The user stories are therefore a means of communication.  With poor choice of wording, communication can become mis-communication.  Poor wording leads to misunderstandings that lead to design and coding mistakes.  These mistakes we call bugs.  Bugs that are not found until later in the development cycle can cause a lot of extra work and therefore very costly.

Static Requirements Analyser

Is the tool used to test written requirements for quality and insight.  It may sound counterintuitive that a machine can test requirements, but it can.  (That is what ScopeMaster has been designed to do.)

Back in the 1990’s Nasa created the ARM tool that was recreated, for basic requirements text testing.  Nowadays we have more computing power available and are able to perform more advanced testing of requirements.  IBM has recently 2018 released the IBM Requirements Quality Assistant for Doors  This is a trainable extension to their requirements management tool that tests for common language errors in written requirements.   ScopeMaster combines Natural Language Processing (a detailed analysis of the wording and sentence structure) together with several other algorithms, in order to maximise the insight into the quality and metrics of written requirements.

Insight from Static Analysis of Requirements

The insight achievable by analysing Individual Requirements includes:

  • Volume (word and sentence statistics)
  • Identify types of words (nouns, verbs, adjectives)
  • Links between words (dependency chain)
  • Intent from a data manipulation perspective.
  • Patterns of usage of words

Insight achievable by analysing Sets of Requirements

  • Consistency in naming of nouns
  • use and misuse of word types
  • Duplication of intent
  • Potential missing requirements!
  • Ambiguity caused by failure to use language appropriate to software construction.
  • Measurement by detecting the data movement intent

More and more developers include static program analysis as a technique for testing code early (as you write it) this testing becomes part of the daily activity of preparing a build for deployment.  It helps to identify potential causes of problems before they are exposed to anyone else (testers, users) so that they can be resolved quickly and efficiently.  The same is true of static requirements analysis, it is a very useful technique to find and fix problems before they are exposed to others in the team.

Continuous Integration

Most static code analysis becomes part of a continuous build process.  This idea does apply to requirements except that every time a requirements statement changes, it should be re-checked (in itself) for being unambiguous and (across other user stories) for consistency, duplication and omissions across all other requirements.



Taming software requirements and bringing certainty to software development.

Interpreting software requirements