Mixed Strategies for SRD: Open Challenges & Final Exercise

1. Session 4 - 2:30 to 3:00 • Mixed strategies (6) • Open challenges (7) • Final exercise & sharing

2. Different SRD challenges & tactics Applications – • E-commerce website • Insurance eligibility screener • Tax preparation • Smart phone app • Autonomous vehicle controller • Outsourced/Procured system Forms – • No specs • Behavior rules • Usage scenarios • Acceptance tests • Equations • Prototypes • Mockups • Quality goals

3. Different SRD strategies Consider the need for different requirement specifications (to manage understanding risk) in different situations ondifferent projects.

4. Different situations on the same project Consider different component-level situations on the same project.

5. Need a mixed SRD strategy Consider SRD for Windows 10

6. No SRD silver bullets The solution is not in the textbook, nor in simplistic development models e.g., V, spiral, waterfall, or Agile models

7. Mixed SRD PhasedSRD i.e., BRUF Iterative SRD Mixed SRD does what’s needed, when and where it’s needed

8. Session 4 - 2:30 to 3:00 • Mixed strategies (6) • Open challenges (7) • Final exercise & sharing

9. SRD open challenge 1 Most stakeholders have a singular focus on functional requirements and testing

10. SRD open challenge 2 Parable of the blind men and the elephant Most stakeholders do NOT understand • collection of quality attributes (> 60) • their organization • their relationships • qualities and functions have almost nothing in common • understanding one quality doesn’t help in understanding another [think periodic table] • one quality may support, conflict, or be unrelated to another • their common characteristics (> 30) e.g., priority • quality verificationbeyond testing

11. SRD open challenge 3 Most stakeholders do not understand that a usefulquality model is essentialfor the cost-effective: • selection • specification • achievement • verification of quality attribute requirements e.g., safety requirements

12. SRD open challenge 4 Few developers ( < 25%) have taken a course in requirements development. Most courses in requirements development are based on simplistic models.

13. SRD open challenge 5 Very few stakeholders are concerned about the dangers in the current approach to Autonomous Vehicle SRD e.g., no industry-standard AV glossary, nor public review of AV requirements Remembering “Define, then Design” & developer SRD ignorance should cause great concern for your personal safety and the safety of your loved ones

14. SRD open challenge 6 - 1 Defining verifiable requirements for: • Safety e.g., • Perfect safety of AVs = no fatalities or injuries • Near perfect safety of AVs = no fatalities or permanent injuries • Achievable safety of AVs? = less than 3,500R fatalities and less than 200,000R permanent injuries, where R is the average ratio of autonomous vehicles on US roadways in a year. [The two constants are 10% of the actual carnage.] For 250M registered vehicles in the US, R = 4 x 10-9for one AV. This means less than .000014 fatalities and less than .0008 permanent injuries per year for an average AV. • AI components

15. SRD open challenge 6 - 2 Defining verifiable requirements for: • Safety • AI components Consider a component that identifies ‘people’ or ‘people indicators’ or ‘substantial objects’ and calculates their distance from the front bumper. Assume this component receives information from several sensors. The accuracy of the component’s output will depend on the accuracy of the sensor outputs – are sensors effective in a snowstorm? – as well as the reliability of the component’s AI-based identification process and computational algorithms. What should accuracy requirements for this AI-based component look like?

16. Session 4 - 2:30 to 3:00 • Mixed strategies (6) • Open challenges (7) • Final exercise & sharing (5 mins) Ask yourself which of these ideas could improve outcomes at work?