Very good presentation, thanks for sharing it. He took the slides one by one from "Airborne Electronic Hardware Design Assurance" - R.Fulton & R.Vandermolen. Very good book, definetily worth a read. Also he mentions that everyone should be using DOORS, but there are modern alternatives such as Polarion or Jama with a much more user friendly interface.
"Took the slides one by one...": Yes, but I think he misunderstood the message in a couple of cases. E.g. "Each level of abstraction can repeat its allocated requirements until there is a design" does NOT mean that the same functionality can occur in multiple places in the design, as he appears to claim. As written, it appears to contradict the earlier statement that requirements should not be so detailed at a high level that decomposition merely means replication or cloning down through the levels of decomposition; however this conflict can be reconciled by earlier guidance which states that the requirement should be written for the audience at that decomposition level. That means not only that it is written for the person who is doing the work at that level, but that it should be written for the implementation context at that level. A circuit board knows nothing of weight on wheels, for example, only the inputs that carry that information, and should be written as such. Similarly, software cannot turn on an indicator lamp, only activate an output allocated to that indicator lamp, so again, the requirement should be written as such. "DOORS": Agreed; Jama, being natively graphic, has - as just one example - an excellent method of showing decomposition traceability in an intuitive left-to-right layout. I've been in a love/hate relationship with DOORS since 2003, and after a brief taste of Jama last year, I'm eager for the opportunity to join the twenty first century with a new tool!
This is fabulous, I am working on an engineering project for the rail industry and this is exactly what I needed, I also need some detailsn on how you manage Hazards and risks
Around minute 19:00, the presenter is talking about the use of "shall" to identify a requirement and the move away from the use of "shall" from industry. I will add that regulators, not sure if EASA, but at least the FAA have instructed their employees to avoid the use of "shall". In FAA Order 1000.36 the FAA recommend avoiding the use of "shall" and instead use "must" to impose requirements.
If functional requirements are the only verifiable requirements why are other types of requirements included? I read the source book on this and it says treat the non-functional requirements as textual information in the requirements document since they are not verifiable by test but just inspection. I'm not sure how you could reconcile functional and non-functional requirements if this is the case.
Verification is bigger than just Testing. You are right saying that non-functional requirements are not verifiable by tests but we can (and we should) verify them by the engineering review and inspections, when you manually inspect the design and/or implementation of your product to ensure that the non-functional requirements are met.
@@denisevstratov Right! Functional requirements aren't the only _verifiable_ requirements, they're just the only (behaviorally) _testable_ requirements. As you say, inspection and analysis (and demonstration/observation for process requirements) are how we verify non-functional requirements.
