Use Case Series: Formal Use Case

Posted on:

This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management.

Use Case Series: Introduction

Posted on:

Use cases can be difficult to talk about, because they immediately invoke so many different preconceptions and prejudices. High school English teachers know that some words aren’t just words – they are symbolic, and represent ideas. They had us write essays like “Who do I think is a hero” and […]

Active Listening and Cultural Cues – When No Means Yes

Posted on:

Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.

For a given project, there are three sets of requirements – the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.

Stop Wasting Your Time – Don’t Bother Writing Functional Specs

Posted on:

Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business