Posts

Showing posts with the label SRS

How to write a good software design doc

Image
As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing  what makes a design document great . The article is split into 4 sections: ·          Why  write a design document ·          What  to include in a design document ·          How  to write it ·          The  process  around it Why write a design document? A design doc — also known as a technical spec — is a description of how you plan to solve a problem. There are  lots of writings  already on why it’s important to write a design doc before diving into coding. So all I’ll say here is: A design doc is the most useful tool for making sure the right work gets done. The main goal of a design doc is to make you more effective by forcing you to think through the design and gather fee

Importance of Documentation in Software Development

Image
Why you should always do documentation before development Doc-driven development focuses your code toward a specific blueprint of how an application is meant to work. x Subscribe now Get the highlights in your inbox every we Programmers and project managers sometimes think the phrase "doc-driven development" means putting a lot of comments in code or working closely with doc writers as development happens. That's because it's hard to imagine how development can possibly happen  after  documentation, because surely documentation can't happen until there's something to actually document. Documentation traditionally is seen as a sort of journalistic endeavor. Doc writers are given some software, and they take it into the lab and poke it and prod it until they've figured it all out, then they write it down for everyone else to never read. This misses the all-important process that happens naturally