High-Level Requirements; The Good, The Bad, The Ambivalent
During the Discovery phase, High-Level Requirements can be a fair way to ascertain your effectiveness. If stakeholders sign off on your High-Level Requirements, you know you are not totally missing the boat. It is a good way to make sure you don’t put too much effort into doing more detailed Requirements that are not accurate. It also helps you identify the “nice to have” Requirements versus the “must have” Requirements.
This is what they tell me. I dont believe it at all.
First, a Requirement is something that is required. If a Requirement needs to be removed from the scope of the project because of time, budget, or other constraints, it is cut. It does not fall away because it never really mattered all that much and was a “nice to have” to begin with. It was a Requirement. Now, it has been cut from the scope and methodically, deliberately, purposely removed from the list of Requirements. There is no such thing as a “nice to have” Requirement, although many folks who teach Requirements Analysis would have you believe that there are.
Requirements are required under the contextual scope. If they are removed from the scope, they are no longer Requirements.
Now, there may be reason to note which Requirements are more important than others so if it comes down to it, scope items can be removed with intelligence. You can cut an expensive scope item if you need to, and you can know that item A is mandatory and item B is mandatory but if need be, item B can wait. Or, while it is mandatory under the current scope, we can go back and manage stakeholder expectations, explaining why it has been removed while making it clear that it was a business decision, not arbitrary. Still, I maintain that our fated Item B is a System Requirement. It is required against the project baseline. We have simply adjusted the project baseline - and as you know, baselines adjust, shift, and change.
A shifting project baseline is normal. A non-required Requirement is not.
High-Level Requirements do very little good in and of themselves. While they are the PM/BA equivalent of sticking your toe in the water, you are going to have to swim. Talk to your stakeholders. You are supposed to be doing Discovery. There should be no need to stop at High-Level when the client wants their system documented, not their general intent. The Business Case will do enough towards that end. High-Level Requirements are, in a way, cowardly.
There is a major caveat here; when involving third party consultants, it may be very beneficial to have them draw up High-Level Requirements. Ideally, this would not be the case, but reality is that even the most well-respected consultants sometimes get it all wrong. What I object to is a *deliverable* consisting of High-Level Requirements that carries a price tag.
I know I may be alone in thinking this, but that’s okay. I simply do not see the point in wishy-washy Requirements and timid documentation. We are here to build systems and to earn our money. We are not here to create artificial deliverables or Requirements. Project Management and Business Analysis get a bad rap as it is. I cannot tell you how many IT professionals I have encountered that consider Project Management a pseudo-skill, a collection of soft skills, a discipline without metrics to gauge its efficiency.
PMs can be the people that make or break the simplest and the most ambitious projects. Act with Boldness. Roll your sleeves up and get involved in your projects.
A little venting, today. 
System Requirements probably need to start at a High Level, but they are not worth much of anything until you drill down a bit. Functional Requirements at a High Level are just a collection of generalizations and broad swipes at meaning. Consultants and professionals have no business billing for the delivery of a High Level document. They can be called Roadmaps, Development Guides, or masquerade as Statements of Work that trap the client and provide the consultant with carte blanche. They are bad news and bad business, in my opinion. All too often they are “Get Out of Jail Free” cards for unsavory consultants. You sign off, because they are accurate, but then the consultant is only bound to the High Level. Big deal. They may not present you with anything else to sign off on besides the Statement of Work and Contract. Be sure you know what you have coming in regard to documentation. Documentation may be all you have to fall back on.
That said, if the MoSCoW approach is to be taken to heart, it should be a guideline and not a rule. In my opinion, as of today.
Best,
Josh Milane
MIT Technical, Boston