Requirements as a means to answering the question “Are we there yet ?”

Over the 14+ years I have worked in this industry I have been witness to advertisements for courses, books and every other form of delivery in relation to “defining requirements”. I have heard requirements gathering referred to as an art, a skill and a science with there being many of the afore mentioned delivery methods to teach the practice as one of these. I have read some requirements specifications that are fantastic to read and really hit the spot in getting me to understand the business problem whether I’m looking at it from a developers perspective or otherwise, while some have been not so good to virtually non-existent.

I recently received in a corporate newsletter a blurb on the definition of “Requirements” in reference to of course customer/project requirements. The article opened with a set of clear definitions (sourced from an open source forum) as to what a requirement was and what makes a good requirement ie. “the requirements for good requirements” Although the base set of points was excellent the last one; “Verifiable – The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis” really made my ears prick up. To further add to my interest the author footnoted the list with his own addition “Acceptance criteria – Part of being verifiable is to have acceptance criteria.  Poor acceptance criteria is perhaps the major cause of poor outcomes in IT project. From your requirements, come up with a set of acceptance criteria (or tests) which they agree will form the basis for acceptance. This will limit the potential for scope creep.”

So why did I get so excited by the works “verifiable” and “Acceptance Criteria” ?

At this point I step past the implementation phase and towards the end game of delivery. Given a documented set of requirements (written or verbal), most IT people with an element of skill can produce an outcome. They’ve had their use at producing an outcome, however it is really at this time that the requirements will be important as the enablers for completing the project.

If the acceptance criteria has been setup as a set of simply stated requirements the instant spin off will be a well stated Acceptance Criteria document. It seems to be the easiest of concepts: “Requirement# ->1-n Acceptance Criteria#” but is too often not the case. A well documented Acceptance Criteria is one that provides technical staff the navigation and structure in the Development->Test phase, but this it should also be the basis for higher level UAT in eventually presenting the solution to the client. Too often I see either the client or the provider running around at the end of the project writing a set of acceptance criteria (UAT Test plans etc). This may seem valid but this approach is doomed. The project has been signed off based on the initial requirements set therefore the project needs to be accepted on this basis. Instead by doing in late in the cycle we’re now writing acceptance criteria based on the state of the project as it is. This is a great way to focus on testing the way the system has been built to date (which may or may not satisfy the requirements), but not actually what was required. The acceptance test may pass because it has been written on this basis, but will fail the ultimate goal of getting the client to accept that the system does as was “required”. 

We too often hear of projects failing due to “poor requirements” specification,  however I’ve walked into many projects which are failing due NOT to inadequately specified requirements rather poorly delivered (if delivered at all) acceptance criteria (development and delivery) which eventuates in that awful tail end in the delivery of everyone asking “are we there yet ?” as the team moves back to try and find the missing way of defining what is the end result. If the Acceptance Criteria does not come from directly as a result of the Requirements,…..then “where are the goal posts ?” and if we don’t have goal posts are; the answer when asked “when is the project complete” can only be “How do we know ?”.

The end point in this blog back to what makes good requirements. Forget the “art”, “the science” or the “magic” of requirements. Try treating the process as defining the test plan that will be run so that you have a real chance of answering the question “are we there yet ?”.

Are Desktop Applications and developers bound for the the scrapheap ?

If you believe the opinion of the growing number of Web Application developers in the field the answer to the question in the title will be a resounding Yes, but lets examine this a little closer. In starting my entry, I have to restate the fact that yes, by trade and experience I am a desktop developer. From Visual Basic 3 through 6 and into C# .NET and VB .NET I have done most of my best work on typical desktop applications and associated backends. Until the .NET swept onto the pages of the job recruitment pages, I was adament that Web development was something that "graphics people" did and that the "real" IT people supported the underlying web site infrastructure and occascionally put together some backend "stuff" when the sites got complicated and wanted fancy features like "shopping baskets".

 

Being self defined as open minded, I even took an 8week course on ASP.NET development in the early throws of the .NET platform. Even after several long nights of putting together "Hello World" web pages, I walked away understanding the platform; seeing what I thought was its potential; but fundamentally thinking that it would just mean that the "graphics guys" would simply need to skill up towards us programmers rather than the other way round. I liked it but couldn’t see my desktop bread and butter being affected.

 

Several years on, a scan of the recruitment pages would appear to show a different story. The need for Web Application developers vs desktop developers would certianly indicate that I was wrong and that desktop applications/developers are bound for the scrapheap. Everyone wants to be "In the Cloud" and business lust for the promise of a lighter TCO (Total Cost of Ownership) by way of a desktop that does not need constant re-application of desktop patches. I mean really Why upgrade 1000 desktops when you can upgrade a single Web Server ? I admit that desktop deployment is never an easy task even when rolling out in an environment with a well structured and managed SOA. The fact that those 5 PC’s out of 1000 don’t take the patch correctly is what keeps IT departments and IT Service companies in business right ?

 

So desktop is expensive and paiful to deploy therefore we want to replace it……right ? Before taking that line, lets fairly simplisticly consider three common deployment models used in businsess today (small and large) and review at their pros and cons:

 

1. The FAT desktop – In this model the user has a desktop PC loaded with all sorts applications such as an Office Suite and internally developed applications to do everything from CRM to accounting for the business.

Pros:-

1. Everyone loves their own desktop with "their" stuff setup the way they want it. Even in a tight corporate environment there is something to be said for the bond we gain with out PC’s through the good (in the first two days its built) and the ugly when we call it all sorts of names when it takes a week to simply logon in the morning
2. Simpler configuration. Fix the problem with a single PC without worrying about the downstream effect to other PCs.

Cons:-

1. Initial setup costs…..the machine
2. Ongoing costs….anti virus, hardware upgrades as version 2012 of your favourite application doubles RAM requirements
3. Users "breaking" them both with a hammer (from point 1 above) and through whatever it is they do to break them (as a PC Support person often mumbles…….the how the heck do you do that ?)

 

2. The Terminal Served Environment – In this model, the business has a X servers for N users (yes I know the joys of on tap computing, but lets face it there are user count limits and redundancy isses that mean that as the business grows X will too). Lets work on a small business with 1 application server with 20users for the sake of demonstration.

Pros:-

1. Fewer number of places to deploy and therefore less chance of deployment failures and within that the ability to stage deployments for differing user groups
2. Cheaper TCO if combined with a thin client deployment
3. Excellent solution for remote workers
4. Easier deployment of an SOA

Cons:-

1. Initial setup costs can be high
2. Rather than 5 PCS in 1000 failing on an upgrade, you are now faced with 1000 simultaneous.
3. Cost of Configuration Management process increases as a result of point 2

 

3. The Web, The Cloud etc. – This is somewhat theoretical in my mind still never having seen a business run completely in this manner (bar front end processing), however the idea is simple. Build a web application/site and have everyone login securely and do all the "stuff" online.

Pros:-

1. Fewer number of places to deploy and therefore less chance of deployment failures and within that the ability to stage deployments for differing user groups
2. Excellent solution for remote workers

Cons:-

1. Reliance on the Network layer ie. stability in the ADSL etc underlying

 

1. Scale is not as simple as one would hope and expect
2. Generally slower than desktop applications

  

OK, so I still haven’t gotten to the point as to whether the desktop is dead, as each model provides its share of benefits and problems. It is only the business/individual that can really decide what is best for them so we drop back to the old "It depends on the client (being the person or the business)" which leads into my next point… 

 

What about the users ? (something we are always reminded of as non-IT people assume IT people think of nothing except the client/users).  Well even though we (yes I am one too) are loving the fact that we can do so many things online, we also tend to rely for most of our critical "thinking work" not yet being "webified". Really, how many people are more comfortable preparing a client brief in a web based word processor as opposed to firing up MS Word, and when we present that business case, we’re sure to be doing it using a desktop based Powerpoint type application. The fact is that desktop applications at least for now provide a richer set of features than their web based cousins.

 

 

The reality is that most enterprises have found that a mixture of applications is the best solution. Lets take for example a service business that prepares resumes for clients.

 

1. The client logs on to the web site and inputs their information and pays for the server (Web Application)

2. The author writes the resume in Micrsoft Word (Desktop)

3. The author saves the resume and updates the central database with the new resume to notify the client that the resume is ready for collection (Desktop?/Web?)

4. The client receives notification that their resume is ready for collection (Email/Twitter/SMS) and logs on to complete the service by collecting the resume (Web)

 

So, out of these 4 steps the middle 2 which are the actual service delivery was done via a desktop application while the web facilited. Remove the web aspects and this business would survive albeit hobbled.

 

In delivering a solution for this business if it were to be built to tomorrow, step 3 would require a decision being made as to whether the internal management service is desktop or web. This decision would be base on the initial platform selection and could be justified either way (including the expereince of the development staff at the time).

 

I believe that the best solutions are built on a combination of solution delivery based on the particular business area of the solution. As a solution that enages both technologies in the same solution, Microsoft has done a great job in its delivery of desktop tools to support its online services (such as Live Writer in which this is being written), allowing us to take the best of both worlds in have a great tool to use with full data protection. OfficeLive also is a great demonstration of this capability as it allows me to seamlessly access the cloud from my favourite desktop applications. (Over the coming weeks, I plan to write of my experience with moving into the world of cloud computing from the perspective of both a user and a business owner in the hope of finding this write mix and testing my theory using technologies such as these)

 

 

So to finally conclude the desktop application/developer is not destined for the technology scrapheap as some would suggest. Happlily, the web is now providing a great way of providing functionality that both benefits those using as well as those deploying technology.  SAAS as business is now an accessible and potentially profitable, and for the users a potentially great solution for a number of factors. However, the core "thinking" applications that we use in out daily jobs remain on our desktop which is where it is destined to remain for some time. From this conclusion I offering the following:

1. For the client about to invest in a solution, ensure that you question any solution that is completely based on either Desktop or Web architecture
2. For the developer (desktop or web), at least try to understand each others world, if not at leasr be profficient in working in it. Take the time to watch each others spaces and design evolution. Although everyone has watched as web site have gotten "prettier", most people have neglected to notice that desktop applications even at a shareware level now provide an ease of use and visual explosion like never before
3. Truly delivering to a client requirements should always remain our goal, not a competition to see who outlasts who (desktop or web developer). Their is scope for both camps and with a bit of clever and appropriate design we all remain doing what we love and deliver the solution a client really needs and delivers to their requirements.