Software Best Practices

So, I was driving along, making a right turn into a driveway like I have done a thousand times before. I did what one always does when making a right turn: I checked carefully for pedestrians and watched the driveway to make sure nobody was coming down it. I then signaled my intentions and proceeded...

I just finished reading Scott Berkun's new book, The Myths of Innovation (O'Rielly 2007). While taking on the role of myth-buster; Scott provides insights into how innovations really happen and more important how they gain adoption. Like his first book The Art of Project Management (O'Reilly...

Here was one situation we found ourselves in one of the project: In the initiation stages of the project, a very high level requirement was done. It seemed to indicate that this could be a problem that seemed to fit "Business rules" space. We then had to understand the business rules space...

I like to think of it as a requirement that is in the problem space as fixed and one in the solution space as flexible. A requirement in the solution space should map to a requirement in the problem space but should ALWAYS have at least one other requirement that you have or can discard. So for the "We've...

I think our task is to make things clear to the customer. It is common that a customer states his requirements in solutions rather than the real requirement. In that case we have to split up the requirement in to things: the 'real' requirement and the solution that is proposed. In the example...

I agree that the customer *isn't* always right, but they do have the final say because yes, it is in fact their money that's being spent. The customer may not care if the drop down makes the app more difficult to use or whatever. My point here is that "doing our duty" involves pointing...

When I tell people "the customer is not always right", I often get into a debate about the customer paying the bills so we have to do it the way they said. The customer often doesn't care that a drop down may make the application more difficult to use or violate UI guidelines. But what...

As Earl has been teaching the course at my company the "Problem Space vs. Solution Space" concept has really helped us with the major problem of trying to get to the underlying needs of the customer. Marketing so often gives Engineering the solution with no rationale or background to the problem...

Earl's second issue first: '... how do you know you need to "educate" the customer (as Steve McConnell) if you are "required"?'. That's what the "Five Why's" technique is all about. Literally every time a customer gives you a "requirement" you...

In the requirements forum at Construx Conversations, I asked a question about how to present the concept of problem space vs. solution space. You see, I think this is a fundamental aspect of good requirements. My very smart and never opinionated Construx Steves (Tockey and McConnell) told me I was spaced...