A Quick Peek Over a Day in Our Life

To start with a statement, a clear view of: the System Engineer is the one who is leading the entire projects technical development, therefore standing side by side with the project leader, complementing him. So, the Systems Engineer becomes a point of convergence of the various expert’s opinions, recommendations and interests. All only seeing chunks of the entire problem, and trying to impose their perceived best solution. Here comes the Systems Engineer’s role in comprising the problem in it’s entire complexity as a whole, assuring that different pieces are still...

read more

Why Am I Doing This Thinking Online

In the last couple of days I had some debate with my wife on why writing everything down. This can be an annoying habit sometimes, I admit. Though, there is a long way towards I could say I’m exaggerating  Only trying to get out the best of me, and the situation at hand. Then I took some time for really thinking about it. All my big ideas implementation followed through to completion and all accomplishments came like this. Cause what good is a god given strike of genius that only happens into your head, when it dies being forgotten the second day, never having the chance of being...

read more

Distinguishing Between Requirements and Specification

I often hear the term specification used for referring requirements… Some organizations try to produce a single specification to act as both a requirements definition and a requirements specification. When a requirements definition is combined with a specification there is often confusion between concepts and details. There’s no really clear distinction in it’s usage, though the difference is really simple. Then, what are requirements and specification? If you look on the Project Performance International site, the difference is explained in a very simple manner:...

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