The webinar discussed improving product design through high quality requirements. It emphasized the importance of understanding stakeholders, determining real needs through concept of operations documents, writing specific but not overly specific requirements, including traceability, and using tools to automatically check requirements quality. The presenter demonstrated Innoslate's requirements management tools.
3. Meet Your
Host
• President and Founder of SPEC
Innovations
• Participated in the development of
C4ISR and the DoDAF
• Expert Systems Engineering
Professionals Certificate
• steven.dam@specinnovations.com
• @stevenhdam
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 3
4. Know Your
Stakeholders
• Understand what common knowledge they
have.
• Make sure the whole team is on the same
page.
• Understand what each group of
stakeholder’s priorities are and their
objectives.
• Collaborative software that allows for
continuous reviewing will help you keep up
with all the stakeholders needs.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 4
5. Understand
What Is Really
Needed
• There is a huge difference
between want and need.
• Will the system work without a
particular requirement?
• List what is actually needed not
possible solutions.
3/14/2018
Webinar: Improve Product Design with High Quality
Requirements 5
6. Remember the
CONOPS
• Concept of Operations (CONOPS) is a valuable artifact.
• The CONOPS will be something that all the
stakeholders understand and collaborate on together.
• Create different scenarios and needs. From there you
will have a better understanding of where to start with
your requirements.
• The CONOPS will help you write quality requirements
by finding all the assumptions.
• It will help evaluate the ‘what if’ scenarios, make
testing easier, and formulate your needs into the
requirements.
3/14/2018
Webinar: Improve Product Design with High Quality Requirements 7
7. Be Specific
(Don’t Leave Room For Assumptions)
• Words such as minimize, maximize, etc., and/or,
more efficient, forces the stakeholders to assume
• Etc. can mean so many things
• And/or causes the reader to guess whether its ‘and’
or ‘or’
• Min. max. don’t just say minimize expansion, say
minimize expansion to 300
• Don’t just say quick, say how quick
• Give actual numbers
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 7
8. But Don’t Be Too Specific
• Be specific, but not too specific.
• Carefully review your requirements before baselining.
• During this review delete any unnecessary specifics.
• Have any numbers be based on the results of
analyses, not just someone’s “engineering judgment.”
• Allow scope with your numbers.
• If a requirement is good enough at expanding
300% +/- 10%, then give that option.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 8
9. Give Requirements Not
Instructions
• Understand what is needed and create requirements from
those needs.
• This is why knowing your stakeholders is so important.
• If you understand your stakeholders needs writing
requirements and not instructions becomes an easier
task.
• Requirements should provide enough information to allow
the builder to provide the most cost-effective solution to the
problem.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 9
10. Include a Number, Name, and
Description
• All requirements should have a name identifying what it
represents.
• All requirements should have a number to catalog it in the
database.
• All requirements should have a description that elaborates on
its meaning for the benefit of team members and other
reviewers.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 10
11. Must Have
Traceability
• A requirement that refers to the name of
another entity may be related to that entity
with a "traced to,“ "satisfied by," or
"verified by" relation, as appropriate.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 11
12. Use the Words Shall,
Should, and Will
• The industry’s standard word
usage for a requirement is
“shall”, a goal is “should”, and
a statement is “will”.
• If you do not use these
standard word choices you
will confuse other
stakeholders.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 12
13. Include a Rationale
• A rationale justifies the inclusion of a specific requirement.
• Attach a rationale to each requirement by explaining the need
for the requirement.
• The rationale provides reviewers and implementers with
additional information on the intent of the requirements
• Avoids confusion down the line.
3/14/2018
Webinar: Improve Product Design with Write High Quality
Requirements
13
14. Here’s an Idea
To improve grammar use bullet
points first and then construct
sentences out of them.
Use Proper Grammar
• You will prevent costly mistakes
due to confusion.
• Run on sentences will result in
two requirements appearing to
be one.
• Other grammar mistakes that
cause confusion:
• Their, they’re, and there
• Misspellings
• To and Too
• Diverse teams especially need
to use proper grammar and
spelling (context can be difficult).
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 14
15. Use a Standard
• Use a standard to
ensure consistency.
• Common standards
are: MIL-STD-490,
IEEE, and ISO.
• Choose one that is right
for your industry.
• MIL-STD-490: The United States Military
Standard establishes the format and content for
the United States Department of Defense’s
objectives. It can be useful in other areas as
well.
• IEEE: The Institute of Electrical and Electronics
Engineers Standards Association develops the
IEEE standards. Unlike the MIL-STDs, the IEEE
reaches a broad range of industries, including
transportation, healthcare, information
technology, power, energy, and much more.
• ISO: The International Organization for
Standardization develops standards for business
to optimize productivity and minimize costs.
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 15
16. Tools to Help Write High
Quality Requirements
3/14/2018
Webinar: Improve Product Design with High Quality
Requirements
16
17. Use Innoslate’s
Quality Check Tool
• Saves the whole team time
• Ensures accuracy
• Develops complete requirements
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 17
18. Automatically Check Quality
• Correct – i.e., describes the user’s intent and legally possible
• Complete – i.e., expresses a whole, single idea, and not portions of
one or many
• Clear – i.e., explicit and not confusing to readers
• Consistent – i.e., does not conflict with other requirements
• Verifiable – i.e., proves within realistic cost and schedule that the
architecture meets the requirement
• Traceable – i.e., uniquely identify, and able to be tracked to
predecessor and successor lifecycle items/objects, such as functions
or components
• Feasible – i.e., implement with existing or projected technology and
within cost and schedule
• Modular – i.e., changes without excessive impact on other
requirements
• Design – i.e., does not impose a specific solution (“what” not “how”)
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 18
19. Use Intelligence
View Tool
• Checks your entire project
• Automatically finds issues
in your requirements
document that goes further
than the quality check
• Let’s you quickly fix or
ignore issues
• Customize warning types
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 19
20. Ensure Traceability and More
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 20
22. To Write High
Quality
Requirements
Know Your Stakeholders
Understand What Is Really Needed
Remember the CONOPS
Be Specific
Don’t Be Too Specific
Give Requirements Not Instructions
Include a Number, Name, and Description
Must Have Traceability
Use the Words Shall, Should, and Will
Include a Rationale
Use Proper Grammar
Use a Standard
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 22
23. Next Webinar
What?
One Lifecycle, One Tool
When?
Tuesday, May 15, 2018 at 2:00pm ET
Where?
Go To Webinar
3/14/2018 Webinar: Improve Product Design with High Quality Requirements 23
24. Thank you for Joining Us
Stay Connected!
571.485.7800
blog.Innoslate.com
innoslate.com
SPEC Innovations
Innoslate User Group
@Innoslate
Editor's Notes
You do not want each group to develop their own priorities and objectives separately. Separate priorities and objective result in a time consuming and expensive review process with lots of conflicts.
You never want to give them a completely finished product and then ask for review (although that is common practice).
A common mistake systems engineers make is listing possible solutions to needs rather than the actual needs. If your need is an efficient way to communicate, don’t specify cell phones, since there are many other forms of communications that may be more feasible, less expensive, or effective. List what is actually needed; don’t list possible
Leaving room for assumptions is leaving room for error. If you are not careful with the language you choose you could end up making costly assumptions. Using words such as minimize, maximize, etc., and/or, more efficient, forces the stakeholders to assume. Don’t let the stakeholders assume how much you want to minimize.
etc. can mean so many things
and/or causes the reader to guess whether its ‘and’ or ‘or’
min. max. don’t just say minimize expansion, say minimize expansion to 300
don’t just say quick, say how quick
give actual numbers
The only mistake worse than not being specific enough is over specifying. You want to be specific, but not too specific. Carefully review your requirements before baselining. During this review delete any unnecessary specifics.
Allow scope with your numbers. If a requirement is good enough at expanding 300% +/- 10%, then give that option. Have any numbers be based on the results of analyses, not just someone’s “engineering judgment.”
Understand what is needed and create requirements from those needs. This is why knowing your stakeholders is so important. If you understand your stakeholders needs writing requirements and not instructions becomes an easier task. It might be tempting to just writing instructions, but that is not what requirements are for. Requirements should provide enough information to allow the builder to provide the most cost-effective solution to the problem.