Download to read offline
Uploaded byElizabeth Steiner
Improve Product Design with High Quality Requirements
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.
More Related Content
Similar to Improve Product Design with High Quality Requirements
![[2].the requirement engineering handbook](https://cdn.slidesharecdn.com/ss_thumbnails/2-211026083124-thumbnail.jpg?width=640&height=640&fit=bounds)
Improve Product Design with High Quality Requirements
- 1. Webinar Improve Product Designwith High Quality Requirements Host: Steve Dam
- 2.
- 3. Meet Your Host • Presidentand 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 • Understandwhat 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 • Conceptof 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 LeaveRoom 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 BeToo 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 • Arequirement 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 WordsShall, 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 Toimprove 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 HelpWrite High Quality Requirements 3/14/2018 Webinar: Improve Product Design with High Quality Requirements 16
- 17. Use Innoslate’s Quality CheckTool • 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 andMore 3/14/2018 Webinar: Improve Product Design with High Quality Requirements 20
- 21. 3/14/2018 Webinar: ImproveProduct Design with High Quality Requirements 21 Live Demo
- 22. To Write High Quality Requirements KnowYour 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 forJoining Us Stay Connected! 571.485.7800 blog.Innoslate.com innoslate.com SPEC Innovations Innoslate User Group @Innoslate
Editor's Notes
- #5 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).
- #6 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
- #8 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
- #9 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.”
- #10 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.