March 2009 - Posts

software requirements
Monday, March 16, 2009 11:39 PM

 

In my earlier posts I have written about why should software be documented and what should we document, and today I will write about software requirements. Requirements are written documents that describe system that should be developed and serve as communication tool between customers and developers. Requirements are also thinking tools that help you understand what you need to build so you don't waste money building the wrong thing.

"The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed." [Joel on Software]

 

Approach to writing requirements

 

You can organize your requirements in more or less formal or agile fashion but the main point in requirements isn't the document templates and complex diagrams. The main point is information. I learned this from few starting chapters of Writing Effective Use Cases (Alistair Cockburn). I was expecting to find template for Use Cases that will help me write better documentation, and instead I found out that approach to writing documentation is more important than document template. (Read more...)

by vukoje
What should we document?
Sunday, March 1, 2009 9:59 PM

There are lots of things that can be documented in software development. That doesn't mean that you should document them all. You should document things that are important and specific, things that everybody working on project should know and that you will forget if you don't write them down.  Most important things that should be documented are:

  1. project vision
  2. requirements
  3. architecture and code


Project Vision

"The Vision summarizes the "vision" of the project. It servers to communicate the big ideas regarding why the project was proposed, what the problems are, who the customers  are, what they need, and what the proposed solution looks like. The vision defines the customer’s view of the product to be developed, specified in terms of the key needs and features. Containing an outline of the envisioned core requirements, it provides contractual basis for the more detailed technical requirements." [Craig Larman, Applying UML and Patterns]  

Read rest of the post...

by vukoje