Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments…
Use Case Series: Formal Use Case
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
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
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
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
Fixing the Requirements Mess
“71 percent of software projects that fail do so because of poor requirements managementâ€