This is a continuation of Requirement Categories – Part 1: Introduction and Functional/Performance Requirements and Requirement Categories – Part 2: Operational and –ility Requirements.

Physical Characteristics:

Physical characteristics may be different for different operational phases so think about that. There may be physical constraints that apply to transportation that are different than those during testing or operations. If you do not want to impose standards because many are related to the design, levy standards upon the next level of your architecture to both guide their design decisions and impose constraints on the next level of the architecture.  Your normal list should be part of your standard template.

Make sure that each of the physical characteristic requirements are needed and you have good rationale for specifying them.  It is easy to cross the line into implementation.  Stay at the “what” level, not “how”.

Memory space can be defined as a physical characteristic when it is a constraint.  If not, leave it up to the design team to determine the amount of memory needed now and in the future for system capability growth.

Design and Construction Standards. 

For many products, design and construction standards and regulations can represent over half of the requirements on your system.  Because of this, they represent a significant part of your development cost and schedule.

During scope definition, you should have identified standards and regulations that drive your design.  These requirements represent a big part of your verification and validation activities because each has to be verified and validated to prove your system is in compliance.  Your verification and validation planning must include producing the data required by the customer and regulatory agencies to show compliance with their requirements.  Failing to identify standards and regulations can result in your product not being in compliance and not being accepted.  This is a very big deal for products that are heavily regulated, like medical devices or products that emit pollutants like engines.

You need to make sure you include appropriate industry standards and regulations and any other standards and regulations mandated by government regulatory agencies as part of the project drivers and constraints during scope definition.  For systems targeted for use in the United States, chemical containment and emissions requirements from the Environmental Protection Agency (EPA), operator protection requirements from the Occupational Safety and Health Administration (OSHA), clinical trials requirements from the food and Drug Administration (FDA), materials flammability requirements from the Federal Aviation Administration (FAA) or National Aeronautics and Space Administration (NASA), or accessibility requirements mandated by the Americans with Disabilities Act (ADA) are a sampling of the type of outside drivers that must be reflected in the requirement set for your system.

If you are developing systems for use internationally, you need to find and incorporate the relevant standards and regulations in your requirements.

What if you are developing a medical product?  What verification and validation requirements will the government and medical insurers place on your product?  What extra reviews by outside experts and what liability insurance will be required before you can conduct tests involving human and animal subjects?

Other products may require outside experts for certification.  Does your product require an Underwriters’ Laboratories (UL) certification or maybe you have a pressure vessel that requires an American Society of Mechanical Engineers (ASME) Class 1 Certification?

Even if not explicitly stated by the customer or other stakeholders, be aware of and research the relevant outside design and construction standards.  Compliance is expected and failure to address relevant standards and regulations can result in failure during system validation and product rejection by the customer even if the customer did not explicitly communicate the drivers and constraints to you.

Failing to identify design and construction standards early in your product lifecycle can result in missing requirements and subsequent costly change later.  How can your product meet quality, security, or safety requirements if those requirements were not identified and included in your product’s requirement set?  If this happens, expensive rework and schedule slips result.

Standards and regulations are generated based on best practices which are the result of a multitude of lessons learned.  They most often address quality, safety, and security concerns.  Other standards may be defined to insure consistency within an enterprise or domain, e.g., display standards.

Design and construction standards and regulations can address such things as material selection, quality of parts, processes, interchangeability, and programming language.  Sources of standards and regulations can come from the government, international community, industry, your company, and your business unit.  Standards documents can address process, system/product/application, and verification requirements.

Caution:  Like all requirements, you should not include them unless you have very good rationale for doing so.  Read each standard or regulation and only call out those that really need to be defined for this system.

For more information relating to design and construction standards and regulations, refer to these other closely related articles:

• How to Refer to Other Documents within your Requirement Document
• Guidelines for Referring to Other Documents in Your Requirements Document

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.