Technical analysis in software development

Question

What should a good technical analysis include in software development?

Why do we need a technical analysis? why can't we just start coding?

I got this question from a customer who won't pay for the analysis.

Answer 1

First, I suggest you read this great article from Joel Spolsky about "functional specs" (which is just another word for "technical analysis"):

http://www.joelonsoftware.com/articles/fog0000000036.html

So I hope this article convinces you that a technical analysis makes sense, to make sure the development runs into the right direction, and to make a rough estimation about the project costs.

The other question is "how to convince the customer that he should pay for the analysis", or just "who should pay for it" (seriously, not making an analysis at all is a no-go, even if you have an agile process). The problem here is that an analysis is primarily something you will need to fullfill the customers wishes, and the benefit for your customer comes only indirectly (for example, when he has a chance to cancel the project when the analysis tells him that the development will cost more than he expected). The answer to this question depends on how you are going to make a contract, and how the payment regulations are done, for example, if you are paid by working hours, or for a fixed price.

Answer 2

Analyzing is a very important part of SDLC, if you failed to analyze & convert given requirements into proper design you may end up with a huge list of enhancements/change requests which will result in unstable code.

Why do we need a technical analysis? why can't we just start coding?

If you start coding without a proper planning you may do a lot of things wrong like you might choose wrong controls (buttons instead of hyperlinks etc), at code level you might use wrong data type which might be very memory consuming in later stages.

Answer 3

I'm your client, answer my question, why do you need all these analysis before start coding?

All "this analysis" is usually about knowing to a a comfortable detail level, what you are supposed to build and agree to deliver. It is much like if I ask you to build me a car. If you just say OK and take my money, I would think of you as a crock! There are many questions you need to ask me if you are an honest person.

Here is a sample of what you get at the end of analysis...(there many ways to put this and this is not all, but I guess is enough at this point):

1. Finding who is the customer.

2. What is the problem(s) to be solved.

3. How is the proposed solutions will actually make a difference.

4. What are the risk areas?

5. What is the best solution among candidate solutions?

6. Am I the right company to solve your problem (technically)?

7. What is the cost of the solution (alternatives) - Solution feasibility?

8. What are your business rules?

9. Whom will help me from the business side, do they have knowledge and time?

10. What is the acceptance criteria and milestones?

The cost of missing requirements is huge after writing code.

The technology we use to build software is not advanced enough to make software development via endless iterations feasible or practical in may of the real world situation.

The picture in this article is very famous, and is a classic showing the value of analysis and capturing accurate requirements.

Examples of customer dis-satisfaction with implementations of even ERP systems with 100s of well crafted modules is not uncommon.

Having said this, there are businesses that are rich enough to start projects with no dead-lines and ever lasting pilots. For those, the approach may be different.

Answer 4

Would you build a house without a blueprint first? Would you trust a building contractor who wanted to do that to save money? Do you think it would actually save you money?

We do the analysis to make sure we know what code to write and to make sure the customer knows what is involved in what he is asking for. The chances of any major project succeeding and the client accepting it without an analysis of some kind is virtually 0. You will have to pay the price to do the analysis either up front when it is cheaper or during acceptance testing or after the system is in production when problems are far more expensive to fix (Like relocating the kitchen after you built the house - easy to do at the blueprint stage, harder and far more expensive to do later).

As a customer what you don't want to do is hire someone who is so unprofessional that he doesn't suggest an analysis. That is a virtual guarnatee that the product will be poorly built. Customers who hire those people tend to get what they pay for and then have to pay again to a real professional to do the job correctly. It is almost always cheaper to do the analysis than to skip it.