What’s in a Requirement ?

Once again a reminder that the opinions expressed in is blog are mine and not those of my employer.

One of the issues that I come across in my work as a senior technical professional is requirements. and more to the point what makes a good requirement vs a bad requirement. This somewhat simple process of understanding the requirements of the solution that you are being asked to implement, design, cost etc. is in my experience the major place where projects de-railed and without a reasonable approach to getting the requirements right & managing the changing of requirements you get yourself all knotted up & tend to have to do a lot more work to make it all right again.

So what makes a “good” requirement – and for this post a reminder that there are 2 types of requirements.

• “Functional” requirements that states what you want the solution to do
• “Non-Functional” requirements that states the constraints on the solution

Wikipedia has 2 great articles on the differences between these.

A good (functional) requirement is one that is stated in the third person and states what the requester wants the solution to do, has a number against it (for tracking purposes) & in my situation (especially for Infrastructure) has a priority, e.g.

Req #	Description	Priority
FR-001	Ensure that all widgets that arrive at the input chute exit by the output chute black in colour	Mandatory

in other words make sure everything is black,

From the above I could burn everything in a high temperature incinerator and still satisfy the requirement, so we describe non-functional requirement to ensure we get the outcome that we are really looking for ;-

Req #	Description	Priority
NFR-001	Ensure that all widgets do not have their weight, size or shape modified by the black painting process except as necessary & caused by the paint being applied	Mandatory

(and yes I know these are fairly obtuse examples, I don’t want to be publishing via this site my IBM work)

On the contrary a bad requirement is one that states the solution e.g;-

“Install an Acme 1000  widget blackening device”

It may be the eventual solution however when you are deciding which solution you want from the alternatives – be that as an IT architect or as a customer – the well stated requirements will be the basis by which you will find the solution that best matches your needs.

Later I hope to post on how do you use your requirements to do this evaluation.

Thanks for reading.

Knowing when to “Stop Digging”

(c) iStockPhoto

One of the skills in any IT Architect needs to develop is knowing when a solution that you are pursuing does not work and you need to stop, take a fresh look at the problem and start all over again.

I see it over & over in my work where a solution is pursued way beyond the point where it will solve the business problem.

So why does this happen & what can you do to prevent it ?

The “why” question is a very difficult one – there is a human tendency to, once you have put a lot of your energy into solving a problem that you don’t want to see it not used, in counterpoint to which I would say that this is not a failure but a discovery of what doesn’t work. Usually every solution has some part which works – and it comes to figuring that out when you start again.

It may not be the project team or the designer that is the cause – there can be pressure to use a particular solution that was used for, what on the surface, may be a similar problem, and this “saves” both time and money in the implementation.

The “how” question is a bit easier.

Requirements are the answer, or more to the point well documented functional & non-functional requirements.

Being an Infrastructure IT Architect, I like the non-functional ones better because in the delivery environment that causes you the most issues, however today I will share with you how I use functional requirements to ensure that I know when to “stop digging” or more to the point (& to stretch the metaphor) know where you should be digging in the first place.

I refer you to the definition of “Functional Requirements” on Wikipedia (as good as any I have found). What do you need the application or service to do.

I have simplified it down for Infrastructure services to be documented something like this (from an email system)

FR #	Requirement Description	Importance
FR-001	Support the ability to route a correctly addressed email from the user to the address or addresses email systems or mailboxes designated in the “To”, “CC” or BCC” field of the email	Mandatory

The use of Use Cases & requirements analysis is obviously part of the development of the requirements and any reasonably mature IT Architecture method will have techniques that document how to do them.

So, when you are having trouble getting to completion, map what you have back to functional requirements & you will fairly soon understand if you need to “stop digging”

Thanks for reading.