This post is a continuation of the previous post:  “How to Refer to Other Documents within your Requirement Document”

Standards and Regulations that apply to your project should have been identified by the project during scope definition as drivers and constraints.  These documents can come from the government, industry, international standards organizations, your company, your business unit, or your organization.   Those that apply can be big cost drivers to your project and system development efforts, so it is important that the project carefully determine which standards and regulations apply and what portions of the documents apply.   If you are developing a product for an external customer, that customer will frequently  specify which standards and regulations apply.  In all cases, you will have to include specific requirements that invoke the requirements in these documents AND will have to prove, thru verification and validation, that your system is compliant with these requirements.  This compliance will be part of your customer’s qualification and acceptance activities.

Different types of requirements.  Many standards and regulations contain at least three types of requirements: Process requirements on the developer/provider; requirements on the product itself, and requirements dealing with verification and validation activities.

Quality and Nature of Requirements in Standards and Regulations.  The quality of the requirements in these documents varies considerably.  Some are well written and some are very poorly written.  Often there is a lot of ambiguity in the requirements.  One reason for this is that standards and regulations are written for a generic class of products rather than any specific product, and definitely not your specific product.

General Guidelines.  Keeping the above in mind, you should follow these general guidelines:
1. For each standard and regulation, determine which sections or specific requirements apply to your product.  In your requirements, call out only those that you think will apply.  It is very dangerous to call out a complete document when only a portion of the requirements apply. Remember that all the requirements you invoke on your system will have to be implemented in your design and verified.

2. At the system level include specific requirements invoking the specific paragraph number, section, or requirement number of the standard or regulation that  applies.  In general, reference the standard and don’t repeat what the standard says,  However, because of the “generic” nature and often ambiguous nature of requirements in these documents, you may have to write derived requirements that reflect the intent of the standard or regulation requirement that is stated in unambiguous and verifiable language.  Also, in the requirement just use the document number and not the often long and wordy title.  The title is included in Section 2.0 of your requirements document.

3. For every standard or regulation invoked by a requirement, include it in the “Applicable Documents” part of Section 2.0 of your requirement document.  Include the specific version and date of the document.  DO NOT put in a statement in Section 2.0 that says “The latest version of the documents in this section apply.”  This can be very dangerous.

4. Think ahead to allocation, traceability, and verification.  Rather than having one requirement in your set that refers to a whole document or section in a standard or regulation that has 100 requirements, you should find a way to break the 100 requirements into smaller “chunks” to make the chunks easier to allocation, trace, and verify.   Remember that you will have to verify each of these 100 requirements before you can complete the verification paperwork for your requirement that invoked the 100  requirements.

5.  Once you have completed the requirements at the level  your system of interest is at, you need to do  design work to come up with an architecture for the next level of your system.  Once you have defined your architecture, you will need to allocate the design and construction standards to the next level of the architecture. This can be done using applicability matrices as discussed in the previous post.

6.  At the next level, children requirements need to be written to either implement the allocated requirements or to sub-allocate them to the next level.

7. Given there are different types of requirements in standards and regulations as stated above, it is important that the process requirements be addressed in statements of work or task orders directing the developer or provider; product requirements are invoked in your product requirements documents; and the verification/validation requirements be invoked in the applicable verification/validation/test planning documentation.  Do not mix these three types of requirements in your product requirements document.

8. Determine ahead of time how you will handle changes to the standards and regulations you have invoked in your requirement document.  Not all changes will have an impact on your system.  If you are not impacted by the change, you don’t have to make any updates to your requirement document.  There are some changes that will have an impact, e.g., a change to a regulation (law) or a change to an interface definition document and you will not be able to interact successfully with the other system without invoking the change in your requirement document.

9.  Lastly, what do you do when a standard or regulation calls out another document that contains requirements?  This can be a real issue when one document calls out another and that document calls out yet another, and so on!   If you don’t address this issue, you have lost control of your project, because you no longer have a say if or which of these lower tier requirements apply to your system.   Assuming we call your requirement document “Tier 1” and any standard or regulation you call out directly by one of your requirements as “Tier 2” and any document that a Tier 2 document calls out as “Tier 3”,  then you can include a statement in Section 2.0 that says that ” “Tier 3” requirements called out by a Tier 2 document do not apply” to your system.  This seems drastic, however the way around this that keeps you in control is to also include the statement “Any Tier 3 requirements that apply to this system will be invoked directly as Tier 2 requirement.”

If you have any other questions on requirements, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.