Lessons Learned: Traceability on the Run, the Plan First

Always plan what you wanna do first, running to keep up isn’t fun…. Last month I had a not so pleasant experience regarding a (misdone) traceability, in the sense not done in time! I always preach that, when you are deriving requirements for whatever next level, the link to the higher level your requirement satisfies should be done right on the spot, immediately! That applies for requirements, standards, legislation, or whatever source a requirement might have. That way the effort for generating traceability becomes negligible. It’s not a separate dedicated activity any...

read more

How to: Handling Open Items Files

We are living in an ocean of information. Always on the edge, laying out new stuff, still having to consider everything for the end result to be in the realm of real, useful and reliable. But how do you cope with that afflux of information, how do you grasp all it’s its intricacies and interconnection. How do you fund out what’s conflicting or missing? Can you hold everything inside your head? I cannot! And that’s why I need a tool to help. Something that can help organizing and managing  every finding of the entire team, and self. Why I found to be very helpful and...

read more

Managing the Customer – Training Notes

Out there, in the working field you sometime find yourself facing or handling all kinds of customers. When you have to deliver “bad news”, say “no” to customers or to people in power, you are often tempted to placate with a “yes”. It is indeed a challenge trying to balance the need to be customer-oriented and the need to deliver difficult messages to our customers. You always want to provide exceptional service to both your internal and external customers. However, in the real world, things might go wrong and mistakes are made. Nevertheless, your goal is to have a happy customer...

read more

How to Write Your First Requirement

People always complain about the poor quality of requirements, but usually that all they do say: requirements are a mess. What would really be useful is they say what’s wrong with them, why they don’t like then, what to improve, what cannot be implemented or tested; generally, where they need to be able to do their work. There are of course some recommendations and rules to writing requirements. Good practice and a complete document nevertheless come following an optimal combination between experience, product knowledge, industry know-how and a solid and clear systematic...

read more

How to: 10 Sure Ways to Blow Your Requirements!

What do you achieve when you don’t know what you want? Sometimes the best way to perform is not to know what to do, but what not to do. This is best start not only to new comers, but also to experienced Requirement Engineer who takes over a new challenge. Experience and project specificity will of course add and tailor features and work process, but you already have a pretty solid and complete skeleton of your work product: the requirements document. So, here’s a list with some basics you can start with in order to fail: 1. Start working on phone/email basis: don't ask for a...

read more
Page 2 of 212