We don't need people from the field to be involved in defining system requirements because we have people in the program office with domain experience.
We won't do any prototyping of the user interface until we've finished design, because coding shouldn't begin until design is finished.
We can't ask the user; we're too far down the road.
We are at the leading edge of technology. We can certainly figure out how to run a mailroom better than the low-skilled people who work there.
This is an OO project so we never stop iterating among requirements analysis, design, and coding.
Future users were involved in requirements definition-they reviewed the A-spec written by the development contractor.
The system reliability and safety requirements were allocated to software by the systems engineers because software is very flexible, and these requirements would be too hard to implement in hardware.
There are no software engineers on the systems engineering team for this embedded system because software engineers are not real engineers.
This is evolutionary development. We'll define security and safety requirements after we field the tenth incremental release.
This is evolutionary development, so we won't have stable requirements until eighteen months after project start.
We have experienced a lot of requirements volatility and it's all the government's fault.
We only trace requirements to the Computer Software Configuration Item (CSCI) level because the buyer only requires functional, allocated, and product baselines to be under configuration control.
We can't do requirements traceability because the CASE tools we are using don't support it.
Our requirements traceability information is not up to date because it takes a lot of time to do this manually.
How could we have known before integration test that modifying this algorithm would have anything to do with the response time to that user request?
We do exhaustive regression testing for every change to the operational software because you can never know everything the change might affect.
How could we have known that errors in that code module would cause secure data to be transmitted in the clear?
We can't be sure that system requirements are mapped correctly into software requirements because we used different CASE tools for systems engineering and software design.
We can't use a rigorous methodology for systems requirements definition because functional people are defining these requirements and they are not technical.
We award the Systems Engineering Technical Assistance (SETA) contract to the lowest bidder because that contractor only defines requirements.
We are using leading-edge concurrent engineering methods to define CSCI external interface requirements in parallel with designing the CSCI.
There was no way to know for sure before integration test that the database stored all the data needed by the application software, because we used different CASE tools to design the database and the application software.
There is no top-down requirements traceability because this is the Demonstration and Validation Phase.