Requirements and the Required

(lost the beginning of this post, somehow, but I think I re-created it correctly)

I have previously written on the subject of Requirements Documentation, and I have had to fend off the Requirements groupies with a stick. They come in droves, at my door, throwing clothing at me and asking for autographs. It is only natural; I understand the universal sexiness of Functional and especially System requirements. My thoughts change as rapidly as the New England weather forecast, but there tends to be a thread of reason that follows.

So here is another post regarding requirements. First off, it makes sense to once again reiterate the common method of codifying requirements: MoSCoW. This link is not to Wikipedia, but it is to a post written my someone who puts PMP after their name, so beware.

Must Have items are items that, if not delivered, will make the effort a failure.

Should Have items are items that should be delivered unless they have a significant (negative) impact on the project.

Hang in there.

Could Have items are items that should be included if it is more or less, easy to do so.

Wont Have items are items that will be omitted from scope for the time being. In practice, the VP with a great idea is told that Wont have means “it will be in the next release because it really is a fantastic idea.”

Now, looking at those four flavors of requirements, which is actually required? Only one. Only the Must Haves are actually required. The others are ancilliary topics that fall into the Requirements Bucket because they are possibly going to find their way into the scope. They are really possible scope items, not requirements. At least, not yet.

This is a given, and no great insight. However, in writing RFPs or System specifications, I see people struggle with codifying their requirements. There is always someone who will say Requirement X is a Must Have because they need it, but the question is, does the System need it? Do the stakeholders need it? Does this effort, in hand, being executed and scoped, require the delivery of that item in order to be considered complete? This is a larger question and point towards what Requirements Definition really is; it is really project definition. Once you define a project, you can start work on it. This is breathing the first breath of life into something that you hope will start talking to you.

They say that the final scope is the codebase. This is true, but it is also a bit cutsey for me. The final scope is never met, because the System is never something that is placed on a shelf and considered “done”. The scope may be delivered, but that does not mean much in the larger sense. I am sure you have had a Client who signed off on requirements and was unsatisfied with what they got, despite. Well, I have. A long time ago, of course…

There is the concept of progressive elaboration or iterative refinement, but the classic PM Methodologies would have these ideas exist as transient entities that cease to exist upon project closure and documentation of the famous Lessons Learned. There is no final scope. There is only the current scope, and at times we might refer to that current scope as finalized, but in reality all we have is the product or project at a point where parties have decided that it is complete. Some times, it is considered complete because of budgetary constraints. Does this mean it is really complete, or that it is good enough for now? What is the difference? There is one. As always, you want to exceed expectations. For me, for instance, as long as I shave one day during the weekend, my wife is thrilled. In those cases, I have exceeded her expectations. We set the bar kind of low for me on the weekends, especially in the morning.

Some of the features or functionality present in that completed scope/project/product will not be listed as Must Haves. However, they were. Without them, the final scope would not be realized. There are dependencies, obviations, hallelujah moments, and other moments of serendipity that occur as you develop. This seems like semantics, but it is not. There needs to be life within the MoSCoW classification schema, and we need to allow for agility. As much as you are stating that X is a MUST HAVE, you have to understand that this may imply something else is a MUST HAVE BEFORE THAT, or a cant have after that. You get the idea.

Of course, much of the Big Up Front Requirements (please check out that site – Ambler is great to read and to make you feel like you know nothing) school of thought is fading and small teams of relatively informal developers are making remarkable things happen with only Story Cards and a burndown list. Nevertheless, in creating priorities for the agile framework, some sort of codification is useful. MoSCoW may be your codification of choice. You may, alternatively, number each 1-5 with 1 being most important and 5 being relatively unimportant. There are ways to represent just about anything, visually. It does not matter, in my opinion, which route you choose because the fact is, new items will find their way into your project and all you can rightfully hope for is a solid and informed starting point. Building software is not manufacturing widgets. I have been all over that topic, too.

What is required is an understanding that scope and functional and system behavior or characteristics is something that will breathe on it’s own if you start it on life support. You have to artificially get it up and running, and it will tell you what it needs, what it can do without, what falls away naturally, and what was forgotten and cost someone their job.

Here is what I suggest:

Write requirements in a declarative, positive fashion. Just like the old books say to do. State that the System SHALL do X if only because it is one of the rare times you can use the word “shall” without seeming pompous. Requirements ARE pompous. You are mandating. Each requirement shall be written in a way that removes ambiguity as to what the actual need is and is independantly testable upon delivery.

This brings up two other subjects: traceability and requirements that are more questions than requirements.

Regarding the latter, if you have a requirement such as “The Vendor shall describe what data export formats are supported by the reporting tools,” you really have a quesiton. There is nothing wrong with having both assertions (requirements) and requests for affirmation (questions) in an RFP. If the requirements document is detailing a product, these questions should be fleshed out with the team and answered before being documented as requirements. Simple enough. The Product Owner needs to step up sometimes.

Regarding traceability, this is something that I think goes overlooked far too often. Every requirement should have an associated identifier. Say, “1.2.4″ is your requirement identification. There is tremendous value in that number. First off, do not change it once the document is finalized. Secondly, it is telling to see a traceability matrix that shows how requirements are mapped to user stories or use cases, to development tasks, to test cases, and User Acceptance Testing (UAT). Yes, there will be changes along the way, but this will obviate where those changes occured. “Hey, what happened to 1.2.4? Oh, the Client decided that they didn’t want to export their data after all? Where is that documented?” It should be documented.

There are those who say the cost of maintaining traceability documentation and traceability is too high. These people, like Cockburn, who I cannot argue with and who’s fascination with fully-dressed Use Cases scares me quite thoroughly, can even quote studies:

On one project (corporate IT context), we deliberately studied the cost for both installing a traceability tool, and the human labor involved in keeping the information up to date. The cost was so staggeringly high that the client removed the traceability requirement from the contract.

Even Ambler has his doubts about traceability matrices.

I still like them. I like them as light, non-threatening ways to see what was delivered as compared to what was envisioned. I do not, however, recommend allocating too much time towards maintaining a master document. The goal of these is to trace. Obviously. With agile project, this may prove impossible or far too difficult to maintain. That is why requirements, in my opnion, should not be written with the Big Up Front model in mind. They are a starting point, and they should be as accurate as possible, if you are writing them at all.

The fact is, I do not like requirements. I think they are largely a waste of time. I much prefer Context Diagrams, Role Maps, and User Stories along with iterative development and lots of Client interaction. But this post is about requirements, since people love them. Sometimes, however, you really need traceability. Large clients and government entities may mandate it. So, in those cases, we become less “agile”, more formal, and do what the project calls for. Keep in mind, there is often a happy medium and one does not necessarily exclude the other.

Tip: after conference calls, send your notes to everyone who was on the call or make them available on a Wiki. That way, any directives or changes that are made can be traced back to their origin.

• I am going to plug a product here. I use  for note-taking. I think it is fantastic, and I encourage you to download and use it instead of OneNote or whatever you use. It is one of the only pieces of software I have purchased in recent years, and I only bought it because the free version turned me on *that* much. It even has an IPhone app, and well, I think its just fantastic.

In short, use some type of requirements prioritization technique. I think you have to, if only to make order of madness. However, anticipate change. Build your requirements so they stand strong, alone, and are provable as true or false upon *conceptual* delivery. Things change… all the time.

All of these things mentioned in the previous paragraph are Nice to Haves. That should tell you something?

Best,

Josh Milane