Non-functional requirements are important yet often forgotten


Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.

Just to set some context, I would describe “functional requirements” as software requirements that . . .

Consider wrapping properties maps or lists in their own class

A common pattern in Java is to use a List, Map, Set, or other collection object when faced with keeping a variable number of properties about an object. Sometimes this is seen in obvious anti-patterns like holding URL parameters in a map. Other times there is a legitimate reason. For example, the book Head First OO Analysis and Design illustrates modeling an unknown number of guitar features for items in a guitar shop inventory with a map holding values like {fretboard = maple, tuners = locking}. The available information to be held in this map varies depending on what the manufacturer has provided about a particular item. Continue reading “Consider wrapping properties maps or lists in their own class”


New around the web: The Perfect Company and A Little Architecture

This came up in my Twitter, and I’ve never read the blog before, but the post is a good one.

Whatever you do, do not join a company that values something you don’t believe in. Don’t fool yourself into thinking you can change it, or that you can adjust to it. It’s going to suck.

And then, a new one from Uncle Bob:

Woe is the architect who prematurely decides on a database, and then finds that flat files would have been sufficient.
Woe is the architect who prematurely decides upon a web-server, only to find that all the team really needed was a simple socket interface.
Woe is the team whose architects prematurely impose a framework upon them, only to find that the framework provides powers they don’t need and adds constraints they can’t live with.

Is business logic hiding in your data?

Databases are for data. Business logic is usually best stored in readable code. The main reason that it is not a good idea to store business logic in the database is that databases resist change, and business logic changes all the time. A good programming language coupled with a well-engineered application design allows a lot of flexibility for that change to happen on top of the database.

56021_peek-window_sm Continue reading “Is business logic hiding in your data?”