Effective requirements engineering

A traditional view of requirements from systems engineering.

Everyone should have effective requirements engineering. Everyone should have efficient requirements management. It would be nice to have a way to know that your work with requirements is well spent. The question is more easily asked than answered.

Continue reading

Legacy systems, a definition

Legacy systems come in many forms, here a Data I/O Model 29B

When we want to replace software systems, we often start calling them legacy systems. Sometimes we call legacy after we have made the decision to switch. Sometimes legacy is used as a pejorative to precipitate change. Keep reading for a discussion on a definition of legacy systems.

Continue reading

Worthless ideas and valuable innovation

Ideas as lightbulbs. How much are they worth?

Information is so durable that not even a black hole can destroy it. So what happens with a ubiquitous commodity that is more durable than even space itself? It quickly becomes worthless, even worse than worthless. Consider ideas: no sooner do people come up with ideas than they try to…

Continue reading

I need help with home automation IoT

Today, I am starting on a new project. I am going to automate my hen-house and I need your help to do it. I have never really been a gadget person. I have used the same personal computer at home since I built it from spare parts in 2003. I don’t own a tablet or a smart watch. I chop my wood with an axe, not a machine. It’s not that I don’t like gadgets, I just don’t see the business case. Continue reading

Agile projects requirements breakdown structure

fibonacci series in nature

In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to…

Continue reading

Change is the only constant in agile

Neon sign: change. Change is the only constant.

[bibshow] How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much [bibcite key=”citeulike:13415962″]. Typical rules of thumb figures for software development requirements change rate is cited as 1-3% [bibcite key=”citeulike:321639″]. But the rate of change is accelerating.…

Continue reading

Improved Agile Estimates

Planning poker is a first step towards improved agile estimates.

Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?

Continue reading

Do we Really Need to Know?

Traditional agile user stories are on the form: “As a user I want to xxx so that I can yyy”. A simple example would be “as a mobile phone user I want to make a phone call to my mistress so that I can arrange our next meeting”. But hey,…

Continue reading

User Story Life Cycle is Not Enough

The usual agile requirements life cycle consists of three simple states: “not started”, “in progress” and “done”. This is not enough! These steps only cover the software development part of the requirements life cycle. Do not forget about the stages before and after. First requirements are new, then they are…

Continue reading

You don’t Need User Stories to be Agile

Someone probably told you that you must have user stories to be Agile, right? But really, you don’t need user stories to be agile! I would have you consider what kinds of stakeholders and requirements you have and are trying to meet. Continue reading