Analysis is a step in the development process that I think gets thrown out of our ServiceNow projects too often. Too many times I have seen analysis done on-the-fly during development! And prototyping or proof-of-concept? Shoot we'll do that when and if we run across something during development; that requires it! Right? Wrong!
So what are these necessary processes? How can they be used to best effect in a ServiceNow project? What is the best way to capture and use what is found?
Analysis and prototyping are just as necessary to software engineering as requirements gathering. They are part of a thoughtful and necessary progression from requirements to final product.
So let's break the two out.
1. Analysis - the investigation into the actual execution of the requirements. This is the gathering of all business process, and necessary technical requirements. Analysis encompases the discovery of what it will take to actually do the work, and is usually where sizing comes in. With this step you are finding out what it will really take to accomplish the tasks. This can lead to a revisiting or rethinking of the requirements if a discovery is made that makes the current requirements invalid.
2. Prototyping or Proof-of-Concept - this is where the analyst and/or senior developer will determine if any special technical requirements are feasible or even doable. This can trigger make-or-break decision by management if the technical requirement is undoable. Alternatively the prototype can become the core component to the solution.
A couple of notes:
1. Beware! Push back if management suddenly views the prototype as the complete solution. I have bumped into this situation several times. If you can stop this "short-cut" (which isn't) to development then do so! What usually ensures is a situation where management says: "The POC is sufficient, we can add features later." If you allow this then everything becomes unplanned, untrackable, and unsizeable! The prototype will the become a frankenstein! If management pushes for this then you need to go back to the negotiating table, and rework the entire project. Get it back under control or it will be out-of-control. Those ARE the options.
2. Make sure when doing the requirements, and you get a handle on what the general scope will take, that you make room for the Analysis and Prototyping phase. Don't short-change yourself on time and money with this or you WILL end up doing it anyway in the development phase, and run out of both. The idea with all software engineering is that there will be NO real surprises, and that planning captures the majority of the facets for the solution. The only surprises I like to see are things like: "Gee, our performance from the code is better than we expected!"
So let's talk about the nitty-gritty.
Analysis Elements:
1. Interviews
As a developer you want to have a chat with any relevant SMEs, business owners, process owners, other developers; that may have worked on a similar project, and may have code or design components to contribute. Your task here is to dig out the corners. Anything relevant to implementing the requirements. Your take-aways will be notes, emails, code-snippets, design documentation.
2. Business Rules (this is not ServiceNow BRs) and Processes
During the interviews you will want to try to garner any business rules or processes that may be relevant to the requirements. These could affect the way you implement the requirements. It is good to get these written down. If you don't already have them; I guarantee that you will develop good note-taking skills. Take-ways will be notes, process documentation.
3. Technical requirements
These are interesting in that while some may come from the requirements gathering phase; most will come from the analysis phase. Technical requirements can encompass execution location (server or browser), components (MID Server), installation (AD Extensions for Powershell), interface (Service Catalog, UI Page), and so on. Basically anything that is technically specific to implementing the requirements.
4. Necessity of a prototype, and prototype construction
This is really an extension of the technical requirements. Creation of a prototype is necessitated whenever there is a technical requirement, and it is complex enough that it will require a model to see if the requirement(s) can even be implemented. I run into this usually when I can't find an example from my library, my company's library, or the web (in that order), AND it is something I have never seen done before. Sometimes I have had this be a request from a customer so that they can see what a particular customization will actually look and feel like before making the move to proceed (the POC).
5. Sizing the project
One of the two major take-ways of the analysis phase: The actual scope of the development. What will it take to accomplish to realize requirements into reality? How many hours? How many people will be needed? You have some of these from the requirements phase, but not all. Here you should be able to nail down how many developers, testers, etc. you will actually need, and how many hours to accomplish all the tasks. This will make your project manager very happy. It is always good to be pre-emptive with this information. You will look the hero!
6. Design Structure
Here is one I don't see much of, and it really is the other major take-away of the analysis phase. Essentially this will be, at a high level, what will be in the design. The analysis should lead directly to a better organized and structure design phase. Usually by the time I sit down to design the solution I am mostly there because of my analysis.
7. Risk
This can be another major deliverable if there is a probability of any failure points. This is where the prototype is of great benefit as it can mitigate a possible technical failure by determining if something is even feasible. I try real hard to identify these during the requirements gathering phase, but that is due to my experience and background. Even with that I still end up re-reviewing everything while I am wrapping up my analysis to determine if there are any major (or minor risks) that could cause a failure to complete the project. BTW, the sizing could be a failure point. It could size out to be too big to complete in the timeframe demanded in the requirements.
Analysis Resources:
Subject-Matter-Experts (or SMEs) - these are the people who actually know what the current processes are. They are mostly involved if there is an automation of a manual process.
Requirements Documentation - this is any pertinent documentation from the requirements phase. I use it as my baseline when digging out everything in the analysis phase.
Previous projects (what I like to call precedents) - if someone has done something even remotely like what is being asked for then why reinvent the wheel? This may very well contain code snippets that are directly useful to your project!
Code libraries - what? You don't have a code library? High time to start one! Just saying! One of our Implementation Specialists calls my code library "The Basement." Guess it is; I have so much junk in it now that it is hard to find stuff.
Emails - anything you may be sent from a SME or business owner or developer or...you get the idea. These usually have bits of gold in them that can be used to help define something in the design.
Interview notes from the meetings you have scheduled with the SMEs, business owners, developers, etc.
ServiceNow Community - need I say more?! You really need to be using this. It could help short-cut the need to doing a prototype! It may be that someone already has!
ServiceNow Wiki links - 'nuff said.
Web surfing for information - search engines are your friend! I prefer Google for technical searches, but I also use Bing and Duck Duck Go a lot. Exhaust your avenues of research. I find a lot of OIDs, MIBs, Javascript snippets, and ServiceNow stuff.
Investigation notes - your own musings on what may be necessary. I usually will keep a running commentary of what I have found, and where, to help me organize my analysis. Basically this is how I keep track of everything, and what may occur to me. It is also where I put my "questions to ask" for my interviews.
Recording Tools:
Essentially your note-taking tool has to be robust enough so that you can drop screen prints, graphics, and text onto it. The tool has to be somewhat useful to help you organize it all. I prefer Microsoft OneNote as it has the ability to break everything up into tabbed pages. You could do something on the cheap I suppose with Excel and keep things on different worksheets.
Here is the non-exhaustive list:
Microsoft Word or OpenOffice or Libre Office or notepad. Pick your favorite.
Evernote - a cloud-based OneNote. Similar, but not quite the same in functionality. This has a great price: Free. It has the ability to allow you to break things apart for organizing it, but I just don't quite get the usage out of it as I do with OneNote. It has a super feature in that it allows very easy real-time web-based collaboration.
OneNote - With Office 365 this is now on the cloud as well. However, most of the background I have with this tool is with real-time Analysis and Design collaboration on an internal network. This is my favorite as I like the tab/page feature. It allows me to keep multiple analysis, and design elements organized at the same time.
Example of a possible OneNote project:
Deliverables:
In a nut-shell this is basically what should come out of your Analysis:
Sizing - major deliverable
High-Level Design Elements and Organization - major deliverable
Code snippets (if any)
Prototype (if needed)
Risks and Issues (if any) - usually these are technical
Conclusion
Let me take a moment to argue for you to have a corporate Sandbox instance. If your company does not have one then my advice would be to push for one. With this you can do your prototyping, POC, and or investigative research without doing these tasks on your development instance; with the possibility (very real) of causing problems for other developers. Technically you could use your own instance to develop code snippets, but resist the urge to use it for company development. You should never keep company data on a personal instance.
Use Fix Scripts for code-snippet investigation instead of Scripts - Background. They have the added benefit of versioning, and audit trails.
Don't forget to use an update set when you are working on your prototype. It is the best way to hang onto a copy of what you have developed. Place it in your library for later reference.
As you can see the Analysis Phase is a step that needs to be done separately from the Design or Development Phases. It is a major factor in mitigating risk! It helps in the further detailing of the requirements. It helps in the organization of the design. In my book it is too important to do on-the-fly. It is a fundamental step in software engineering.
In my next article I will be tackling Design Best Practices for developers.
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!
