Standards: Code Quality Standards (CISQ)

Ways of measuring objectively (and automatically) Software quality (measuring things related to non-functional quality attributes such as Maintainability) and knowing if you should act or not. Very interesting indeed:

Quoting:
"Code Quality Standards

IT organizations can use code quality standards to detect critical violations of good coding and architectural practice in software. Measure software against code quality standards at every release, e.g., measure code compliance to secure architectures, and put CISQ software quality measures into contracts with outside developers or software vendors to track to established outcomes.

Published Standards (Available for Use)

Automated Function Points (AFP) and Automated Enhancement Points (AEP) for software sizing
Automated Quality Characteristic Measures for measuring the Security, Reliability, Performance Efficiency, and Maintainability of software

Automated Quality Characteristic Measures in Detail

The nonfunctional requirements of software (Security, Reliability, Performance Efficiency, and Maintainability) can be traced to the most damaging of security breaches and system failures and are at the core of code quality standards and recommendations. CISQ Quality Characteristic Measures are consistent with ISO/IEC 25010 definition. The measures are designed to be automated on source code to identify critical vulnerabilities in the software that are severe enough that they need to be fixed. Combined with a sizing measure, a density metric is produced for each quality characteristic. Thresholds can be set for each characteristic.

The CISQ Quality Characteristic Measures cover eighty-six well-established software engineering rules to ensure secure, reliable, efficient and easy to maintain software. The following table shows a snapshot of software engineering rules contained in the measurement of each quality characteristic at the unit level and system level."

More details (and source): http://it-cisq.org/standards/

Standards: Automated Function Point (AFP) Specification (from CISQ)

The beauty of standards continues: Now (some years ago, in fact), a standard for counting function points (which is a measure of "size" of software source code):

"AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). While there are several automated counters available in the market, there has never been a standard that ensures they are all counting the same way."

OMG has adopted it (in 2013 ;):

"The announcement by OMG of a specification for [AFP] counting should dramatically expand the use of Function Points for sizing IT applications," stated Dr. Bill Curtis, Director, CISQ. "By dramatically reducing the cost of counting and eliminating the problem of inconsistency among manual counters, automated Function Point measurement can become a standard component of the software development and maintenance process."

Source: http://www.omg.org/news/releases/pr2013/01-17-13.htm

The standard can be found here: http://www.omg.org/spec/AFP/

Also be sure to check the AEP and the ACQS (also from CISQ)

Requirements: Requirements Types (Functional, Non-Functional)

Requirement types are a useful categorization for your requirements catalog. There are several classifications and literature about the subject.
The following requirement types were identified according to European Space Agency (ESA) “Guide to the software requirements definition phase”.

FUNCTIONAL REQUIREMENTS

A function is a “defined objective or characteristic action of a system or component” and a functional
requirement “specifies a function that a system or system component must be able to perform”. Typically we will be describing functionality (features) with functional requirements at first. Then comes "the rest": Non-functional requirements.

NON-FUNCTIONAL REQUIREMENTS

• Performance Requirements specify numerical values for measurable variables used to define a function (e.g. rate, frequency, capacity, speed and accuracy). Performance requirements may be included in the quantitative statement of each function, or included as separate requirements.
• Interface Requirements specify hardware, software or database elements that the system, or system component, must interact or communicate with. Interface requirements should also be classified into “internal” and “external” interface requirements, depending upon whether or not the interface coincides with the system boundary.
• Operational Requirements specify how the system will run (i.e. when it is to be operated) and how it will communicate with human operators (e.g. screen and keyboards etc.). Operational requirements may describe physical aspects of the user interface. Descriptions of the dialogue, screen layouts, command language styles are all types of operational requirements.
• Resource Requirements specify the upper limits on physical resources such as processing power, main memory, disk space etc. They may describe any requirements that the development or operational environment place upon the software. A resource requirement should state the facts about the resources, and not constrain how they are deployed.
• Verification Requirements constrain the design of the product. They may do this by requiring features that facilitate verification of system functions or by saying how the product is to be verified.
• Documentation Requirements state project-specific requirements for documentation, in addition to those contained in Software Configuration Management Plan. The format and style of the Interface Control Documents may be described in the documentation requirements, for example. Documentation should be designed for the target readers (i.e. users and maintenance personnel).
• Security Requirements specify the requirements for securing the system against threats to confidentiality, integrity and availability. They should describe the level and frequency of access allowed to authorised users of the software. If prevention against unauthorised use is required, the type of unauthorised user should be described. The level of physical protection of the computer facilities may be stated (e.g. backups are to be kept in a fire-proof safe off-site).
• Portability Requirements specify how easy it should be to move the software from one environment to another. Possible computer and operating systems, other than those of the target system, should be stated.
• Quality Requirements specify the attributes of the software that make it fit for its purpose. The major quality attributes of reliability, maintainability and safety should always be stated separately. Where appropriate, software quality attributes should be specified in measurable terms (i.e. with the use of metrics).
• Reliability Requirements relate to the “the ability of a system or component to perform its required functions under stated conditions for a specified period of time”. The reliability metric, “Mean Time Between Failure” (MTBF), measures reliability according to this definition.
• Maintainability Requirements relate to the “the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment”. All aspects of maintainability should be covered in the specification of the maintainability requirements, and should be specified, where appropriate, in quantitative terms.

Source: Requirements Standard (INTERNAL) and ESA.