Manage and Trace Requirements
Bad Excuses Related to
Requirements Definition and Management
Failed software projects are usually easy enough to analyze after the fact. You can almost always spot some fundamental sound practice that wasn't followed; if it had been followed, the project would have succeeded, or at least failed less completely. Often the good practices that weren't followed are basic ones that practically everyone knows are essential. When that happens, project management can always cite a reason why the practice wasn't followed--an excuse or rationalization.
To save everyone a lot of time, we have collected some of the most common bad excuses for not using good practices.... The next time you're considering managing a project without a careful risk management plan, for example you needn't wrack your brain for an excuse. Just consult this page.
- The users don't know what they want.
- 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.
