We covered a lot of information in our one day training course, here are the top 10 takeaways:

1. Systems thinking must be incorporated into all phases of product development

*  Focus on interdependencies of the parts that make up the system

*  Black-box, top-down definition: system then hardware, software, etc.

*  Overall system behavior, functionality, performance, and quality are a result of the interactions of the parts that make up the system.

*  Parts of the system may have to sub-optimized to optimize the system

*  Interactions between the parts result in interfaces, which must be identified, defined, documented (interface requirements), and closely managed. Read more about interfaces here.  

2. Because of the transition from hardware-centric systems to today’s increasingly software-centric systems, software needs to be moved up in the system’s architecture hierarchy

* Embedded software is not the same as application software development, embedded software interacts not only with the operators, but also other embedded software and system sensors.

3. Requirements must be communicated at the proper level

*  Done mix build-to “how” requirements with the design-to “what” requirements.

*  Keep design-to, “what” requirements “above the line” and build-to, “how” requirements “below the line”.

*  Check out my blog here to learn more about flowdown (allocation) of requirements and traceability.

4. Recognize the importance of well-formed and managed requirements to the success of a program/project

*  Requirements are the common thread that ties all lifecycle activities and artifacts together.

*  The success of a project is dependent on the quality of the requirements.

*  Learn more about risks and requirements on my blog here.  

5. There is a lot of work that needs to be done before documenting requirements

*  Define scope and stakeholder needs before developing requirements. Learn more Delivering Quality Products here.  

*  Identify a feasible concept before developing requirements.  Learn more about Concept Maturity Levels here.  

*  Must address form, fit, function, quality, and compliance to ensure a complete set of requirements

*  A set of feasible stakeholder needs must be defined before developing requirements

6. Adopt an information-based approach to requirement development and management

*  Writing requirements is not an exercise in writing, but an exercise in systems engineering.

*  Requirements must have an underlying data and information model from which they are derived. Learn more Integrated Data and the Foundation of Systems Engineering here.  

*  Use modeling/diagrams to help ensure completeness, consistency, and correctness of stakeholder needs and resulting requirements transformed from those needs.

7. A requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints).

8. Use the INCOSE Guide for Writing Requirements.

* This will help ensure requirements are well-formed having the characteristic that result from following the rules defined in the Guide.

9. Use the requirement attributes defined in the INCOSE Guide.  

* This will help you to better manage both your requirements and your project.

10. Due to the complexity of today’s systems, projects must use a SE tool

*  This will help manage not only the requirements but all artifacts developed across all life cycle activities.

In addition to the links above, here are some links to other resources you may find useful:

* Developing Requirements for Technology-driven Products

*  Technology Readiness Levels for Medical Devices

*  Everything you want to know about interfaces but were afraid to ask.