As a Software Engineer with 4 years of working experience, we are asked to deliver a product out of nothing but idea.

Software Development Life-Cycle (SDLC) comes in various styles and practices, but formally we have these processes:

1. Analysis

2. Design

3. Development

4. Testing

5. Deployment

6. Documentation

7. Maintenance

For me, the "Analysis" is the hardest part. In this article, I would like to tell you why upfront requirement analysis is so important and how to deal with the way high pace startup works.

What is Requirement Analysis

Its goal is for us to have an understanding of the business requirement. To be able to do that, formally we can set this three outputs:

1. Scope of Work

2. Options evaluation

3. Cost-benefit

Most of the time, we often only produce "Scope of Work", because intuitively it can save our ass when we were missing some features.

Evaluating possible options could give us the grand picture of what would it look like. It is also a way to have mutual knowledge with the product owner. Remember, the word "options" is plural, then we need to produce some.

As a professional Software Engineer, we must communicate the possible cost and demonstrate the benefit of each option. The product owner will find it very helpful. It also prevents underestimate and overestimate feeling from stakeholders toward us.

Miss Conception of Requirement Analysis

Waterfall methodology as in SLDC is something Every computer science graduate should know, and also everyone hated. Got their first job working in Waterfall, and believe me, they will be begging for their life to move on.

For some reason, I often got confused when performing requirement analysis means we are going back to the way Waterfall does: doing it up first, continuing with the upcoming process, and never going back.

Working in a high pace startup with a very ambitious and tight deadline, for example, it is normal that we tend to skip taught-to-be non-essential formal processes. I agree that we need working software as our top priority, but how can we do that when not understanding the requirement?

Even in a near-perfect environment, performing requirement analysis also tend to be forgotten. Try to imagine, we are given very detailed business requirements, access to the business team, communicative product owner. The very first thing we gonna do is jumping into coding, what a shame.

I am not suggesting holding back product delivery with a mouthful of discussion. What we assume to be a mouthful, actually is something fruitful later process in our SDLC.

When Working in a High Pace Startup

Those who are very fans of the startup movement will find a time-consuming analysis as something wasteful. I agree with them though. Spending too much time thinking will not get us anywhere, but leads us to useless overthinking.

When I was reading Lean Startup, it just clicks into my mind, as a Software Engineer we tend to overdo analysis, design, and even coding!

Lean Startup tells us, to handle the uncertain reality of the business we need a fast and frequent feedback loop: build, measure, learn

Lean Startup is talking about business and product development, but I find resonance with what we are doing in software engineering. Since the business and product team is working under an uncertain business reality, so do we when facing product requirements. By applying this fast and frequent feedback, we are hoping to see high-quality software day by day.

We expect ourselves to analyze requirements differently by now:

1. Tactical win vs strategic movement;

2. Just do it, look it for ourselves;

3. Be friends with data usage: log, metrics, data, etc.

First Step toward Perfection

Learning by doing is the best learning method for beginners. So, there are some ways for us to practically learn how to perform requirement analysis better in a high pace startup environment.

Expose yourself to the discussion. When your product owner or tech lead presents the very basic background and product requirements, don't just stare at them blankly. Write a note, make some questions, and draw a diagram to make you understand. Direct communication is the most effective communication for thousands of years now, don't let this timing getaway.

The discussion is still running on, even after everyone has agreed. Leave a comment on the requirement, ask some questions, and ask for clarification.

Write something, talk is cheap and it will spoil in no time. Writing your requirement analysis will make your argument comes stronger than anyone. My experience proves it, we do not need a sexy leadership role to influence the technical decision.

Remember the formula, it will help you on performing the analysis. Requirement analysis produces the scope of work, choices evaluation, cost-benefit.