Category: Requirements 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.

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.

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…

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

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…

[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.…

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?

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,…

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…

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