The requirements capture process involves assimilating documents received from external or internal sources, identifying individual need statements in them, and producing an initial set of requirements.
Each document formally received by a project is considered a source document whose content has to be analysed. This analysis seeks to identify individual requirement statements, termed source statements, which will have to be addressed in the course of the project. Each source statement will be satisfied by, and cross referenced to, one or more formal requirements.
When received by a project, a source document must be registered into the systems engineering toolset in terms of items such as:
The document is then scanned to identify source statements. This scanning can be automated. It normally occurs on the basis of a paragraph-by-paragraph examination of the document, but is often done by searching for words such as:
It is likely that each paragraph in a source document will contain more than one source statement.
For each source statement (customer requirement) located, the scope of the source statement is identified in terms of a range of lines within the source document. One or more ranges of lines may be required to scope the source statement. Once the scope is defined, the source statement (customer requirement) can be examined and possibly captured into the project database.
Examination of the source statement occurs on a project-specific keyword basis using a glossary created for the project and maintained during its life. The contents of the glossary can be used to scan the requirements set to identify any existing requirements that relate to the source statement. This process identifies instances where more than one source statement is to be satisfied by a single requirement.
In such instances, the text of the pre-existing requirement can be amended to reflect the current source statement. This will be an automated process within the systems engineering toolset in which:
-
The text of the source statement is optionally appended to a specific component of the existing requirement to provide a starting point for further editing
-
A cross reference between the source statement and the requirement is created
In the situation where a pre-existing requirement does not exist for the source statement, a new requirement must be generated. This will be an automatic process within the systems engineering toolset in which:
-
A new requirement is created The text of the source statement is optionally copied to a specific component of the new requirement to provide a starting point for further editing
-
A cross reference between the source statement and the requirement is created
This process repeats until all of the source document has been scanned.
It is important that a clear distinction is drawn between the paragraph numbers in the source document and the numbers associated with the generated requirements. The paragraph numbers are merely a side effect of the section and subsection structuring of the source document. They may have no other meaning, especially if the customer is content for paragraphs to be renumbered as new issues of the source document are produced.
As a result, it is recommended that requirement numbers have a format different from the paragraph numbers of their source statements. Unless there is good reason to the contrary, a simple numbering scheme 1, 2, 3 ... should be used, potentially hierarchical in nature, grouped by Subject or major system area, and decomposed with levels of decomposition of the requirements as they are engineered.
New issues of source documents should be compared with the previous issue as a first step in the analysis of subsequent versions of the source document. This process should also be automated in the systems engineering toolset and will identify additions, changes, and deletions in the source document's text.
For each addition, one or more new requirements will be generated, as previously described. For changes and deletions, the toolset should identify the source statements within whose scope the change or deletion has occurred, and the requirements associated with these source statements. It is then a matter for the project to determine the manner in which the amendment to the source document should be reflected in these associated requirements, in terms of:
If the requirement set has been registered into a formal project baseline, then one or more Change Requests (CHRs) and Change Tasks (CHTs) must be raised to implement the actions resulting from these deliberations.
At any time, the systems engineering toolset should allow the production of a traceability report between the source statements in a source document and the requirements set, and vice versa.
