What are system requirements?

In the defense industry the word requirements means a series of statements that have the word 'shall' in them. These statements are testable, measureable, and specific. This approach has carried over into the IT industry so that those deploying systems have similiar documents with all the 'shall' statements that the system must do.

For the delivery of information systems, this approach sucks. No one, and I mean NO ONE, can take a document with 300 shall statements and understand what the system will do. Did I say no one?

But here's the rub: when it comes to design, development, testing and deployment, shall statements are very helpful. Shall statements are the machine code that makes the information system development process work, so we can't ignore them.

Too many times I see battles between those that work with users to identify requirements with group facilitation techniques, wireframing, etc. and say the systems engineer's won't connect with users due to their stupid requirements documents (and their right). And the systems engineer's say that the facilitators don't provide enough details to adequately develop systems (and their right).

This is the roll of the chief engineer and program manager - make sure both are happening and that what we discover from the user with user centered techniques translates into the machine code that the developers need.