As a developer you should be intently interested in, yes, requirements! A lot has been written on this topic, but not much from a developer perspective I am afraid. So with that in mind here goes!

Requirements fall out of a request from someone for new functionality to be created or added to software. This would be a request from the business and/or management side, and would usually be devoid of technical information (there are exceptions).

So, what has this to do with the developer, you say. Everything! As the developer you should know what good requirements should contain. Poorly defined requirements are, unfortunately, all too common. Remember the old adage: Garbage-in-garbage-out (GIGO)? That works for requirements as well. Too vague and they lead to back-and-forth with the requestor that could take days and push any deadline way out into the future. Too detailed, and they 1) could take too long to write down, and 2) constrain the solution to such a point that any other better way of solving the problem could, and probably would, be tossed aside! Oh, and push the deadline out into the future.

So what exactly are "good" requirements? And what exactly is a good requirements gathering process?

1. Let's start with who gathers the requirements?

You want someone who has some idea of what the technical solution will probably be after the request has been made. This person should guide the requestor in the technical capabilities (i.e. what can-and-cannot be done). This should be done by either a Business Analyst, or by a developer.

Business Analysts are trained to act as a mediary between requestor and developer. They have enough technical knowledge to make recommendations as to best approaches for a solution. Here at Cloud Sherpas many of them have their Admin Certification, and some have completed their Implementation Specialist certification. This gives them insight into the workings of ServiceNow and what would be proper as far as a solution to a request. Another benefit of having a Business Analyst is to insulate the developer from the requestor. This allows the developer to focus on, well, development!

Developers usually do not have the experience with, or the exposure to the requirements gathering processes. For some companies it simply boils down to not having a large enough organization; such that the line between the requestor, and the ServiceNow admin is simply walking to the next cubicle. The luxury of a Business Analyst just does not exist.

2. What are requirements?

Simply put these are the detail of any request. They spell out how the request will be solved.

1) The problem to be solved

2) The solution to the problem to be solved

For example if a request is made to add the field "Tracked By" to the Incident form the requirements might be:

Problem:

1) There is a business need to have a designated incident tracker. This person will be made responsible (volun-told) by management to oversee a particular incident.

Solution:

1) Add a new field labeled "Tracked By" to the Incident form directly under the "Assigned To" field.

2) This field will only be editable by users who have the ServiceNow Admin role, or those that have ITIL Manager role.

3) The manager will be responsible for choosing a person to be the tracker and entering that individual into the Incident form (process)

4) Once entered into the field the "Tracked By" individual will be notified by email that they have been assigned as an official tracker of the incident.

5) A report will be created that will allow for monthly tracking of the "Tracked By" users.

And so on. This could include screen mock-ups, workflow mock-ups, process story-boarding, etc.

In regard to the ServiceNow platform I am a HUGE advocate of mock-ups and story-boards!

For mock-ups I will often use a screen print and MS Word, and will draw in what is wanted by the requestor. However this could be Visio, or a printout, or if no screen print then a white board, or chalk board, or napkin. Gosh, I love phone cameras!

With story-boards I will often use a series of mockups to show process flow. A leads to B leads to C. This could be a high-level workflow as well as screen prints showing what happens. Visio rocks!

The idea is to convey meaning by both sides and to get a VERY good idea of what is wanted and how it is to behave.

The developer or Business Analyst must guide this process, and help the requestor understand what is possible, and more importantly: what is not!

3. Recording Requirements

Now to address the part most developers simply hate: documentation. Let me start by saying I USED to hate it, but now consider it a most necessary evil!

Develop excellent note-taking skills! Write down everything! I like using exclamation points!!!!

Get everything nailed down. Use the following questions as a guide-line:

i. What is the problem?

ii. What is the existing process (if any)? Are there diagrams showing the existing process? Workflows? How complex is what exists? Any relevant process documentation?

iii. What is the perceived solution? Avoid vagueries. Don't be lazy. Search out the corners. Do the due diligence.

iv. Does a workaround exist? 3rd party? Custom? Manual? Is a simpler solution available? If you have one; will the solution you are thinking of work instead (for example: Discovery and ServiceWatch vs. Help-the-Helpdesk)?

You must, must, must (ad infinitum) organize the requirements into a format that can be viewed by both the requestor AND developer that allows for an understanding by both parties as to what WILL be accomplished. How's that for a run-on sentence?

This must include all of the mock-ups, process flows, and descriptions that describe not only the problem, but the proposed solution.

Each requirement must be numbered! This is probably the single most important thing that is left out of the Agile methodology today, and is being leaked back in through Agile-Waterfall hybrids. The lack of these, as a developer, is a pet peeve of mine!

If there isn't a clear picture, and if things aren't organized you can't expect to deliver what is wanted, let alone on time!

Numbering allows for traceability: The ability to trace the requirements all the way to QA and UAT testing. How else would anyone know that all the requirements had actually been achieved? The next step in the process, Analysis, does not rely so heavily on this, but the step after, Design; most definitely does. You must be able, as a developer, to show that you met ALL the requirements. Traceability is all!

BTW, a side-note: This seems to be some sort of religious thing. The rabid frothing-at-the-mouth Agile-only advocates do not believe in numbering let alone traceability. They say: "Stories should be small enough that they encompass only a few requirements at a time, and therefore it is unnecessary to do numbering or even a true requirements document." This is bunk. In the real world what I have observed and dealt with is serious abuse of stories. Instead of keeping each story small (the exception); the person creating the story crams as much as possible into it (the rule). I don't know how many times I have seen a story that is really an Epic, or an Epic of Epics! This is a training issue you say? No, I have seen this done by Agile certified individuals! The temptation appears to be too great. It does not self-correct at sizing (should that step even be observed). And lest you think I have limited exposure to this; I would remind you that I have been a software developer for over 30 years and have extensive Agile experience.

4. Approval

Finally get the completed requirements approved by the requestor. Meet with the requestor. Together agree that the proposed requirements are correct and will result in a satisfactory solution. There must be sign-off of the proposed solution, or you should NOT move forward. I don't know how many times I have heard from a requestor: "Looks great! Roll with it!", but had nothing in writing; only to have the requestor say at roll-out: "That isn't what I asked for!" Get an email confirmation from the requestor at least! Get buy-in. It is important. Do not cave in on this as it is the closure point of the requirements process. Again, you should not move forward unless you have it.

Once approval is received (again in writing; not verbal); then you are done with the initial requirements. Uh...initial?! That's right; it is a living document, and can be revisited if something was left out. This will usually be discovered during the Analysis and Prototyping phase. Be careful that the "revisit" does not cause too big a change. If that happens you will be forced to reevaluate the solution, timelines, and effort! Don't fall for the old: "...and can you get it all done by the agreed upon deadline?" Really? I usually jump up-and-down and pitch a fit if that happens, and the answer will be no.

What's next? Analysis and POC/Prototyping which I will cover in my next article.

Steven Bell

If you find this article helps you, don't forget to log in and "like" it!

Also, if you are not already, I would like to encourage you to become a member of our blog!