Inception/Business Modeling/Requirements Engineering: The KAOS approach (Goal-oriented)

https://en.m.wikipedia.org/wiki/KAOS_(software_development)

Quoting:
"KAOS, is a goal-oriented software requirements capturing approach in requirements engineering.
It is a specific Goal modeling method (as the  i* or I Star is).
It allows for requirements to be calculated from goal diagrams.

KAOS stands for Knowledge Acquisition in automated specification or Keep All Objectives Satisfied.

The University of Oregon and the University of Louvain (Belgium) designed the KAOS methodology in 1990 by Axel van Lamsweerde and others (...) for capturing software requirements."

A tutorial can be found here:
http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf

Books on Requirements?

For everything in life, there's a book. I even found some book for good friends of mine who ride the bicycle (that went something like "how to not ruin your sex life riding bikes"). Unfortunately a search for it in the Amazon store today does not yield results.

And then, there are good books on writing good requirements.

Some of them are pretty much old but they are still good books on the subject (this is an "old" art):

• https://www.amazon.co.uk/Mastering-Requirements-Process-Suzanne-Robertson/dp/0201360462/ref=sr_1_2?s=books&ie=UTF8
• https://www.amazon.co.uk/Mastering-Requirements-Process-2nd-second/dp/B008IT2WJW/ref=sr_1_3 (the 2nd Edition)
• https://www.amazon.co.uk/Managing-Software-Requirements-Approach-Technology/dp/0201615932/ref=sr_1_4?s=books&ie=UTF8
• https://www.amazon.co.uk/Managing-Software-Requirements-Addison-Wesley-Technology/dp/032112247X/ref=sr_1_5?s=books&ie=UTF8
• Writing Better Requirements: Amazon.co.uk: Ian Alexander, Richard Stevens: 9780321131638: Books

PS: Some classical papers on requirements:

• http://homepages.laas.fr/kader/Hooks.pdf

• http://www.win.tue.nl/~wstomv/edu/2ip30/references/smart-requirements.pdf

Additional references (sources for the INTERNAL QMS ENG02 Process) 

The main conceptual references for the process description, back in 2003, were:

Guide to the user requirements definition phase, ESA PSS-05-02 Issue 1 Revision 1 (1995).

Guide to the software requirements definition phase, ESA PSS-05-03 Issue 1 Revision 1 (1995).

Space engineering – Software, ESA ECSS-E-40B Draft 1 (2002)

Some additional references used were:

Managing Software Requirements: a unified approach, Dean Leffingwell, Don Widrig, 2000, Addison-Wesley

Mastering the Requirements Process, Suzanne and James Robertson, 1999, Addison-Wesley

Modelling for requirement engineering, Dr. Eric Conquet, 2002, ESA / ESTEC TOS- EME

Specifying Good Requirements, Donald Firesmith, in Journal of Object Technology, vol. 2, no. 4, July-August 2003, pp. 77-87. http://www.jot.fm/issues/issue_2003_07/column7

@2017-11, additional sources for QMS PCS. 

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.

Paper: Writing good requirements

There are full courses, papers and entire books on the subject.
It is indeed important to get requirements right (either from the customer or to be able to gather them properly from the customer).

Here's an interesting (old) paper on the subject:
http://homepages.laas.fr/kader/Hooks.pdf

Quoting:
"Abstract. The primary reason that people write poor requirements is that they have had
no training or experience in writing good requirements. This paper will address what
makes a good requirement. It will cover some of the most common problems that are
encountered in writing requirements and then describe how to avoid them. It also
includes examples of problem requirements and how to correct them.
(...)
Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not an official position of INCOSE."