We’ve dealt with user representatives who believed that they knew better than the users. We’ve dealt with people afraid to let consultants talk to the users, because the consultants might mis-set expectations and create bad will when the development team fails to deliver. We’ve dealt with over-protective information-hogs, who don’t want to telegraph their moves, for risk that they might lose control of the project, or lose credit for the project to someone else. How do we get past these barriers?
Polls / Requirements / Requirements Models / Use Cases
Posted on:
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.
Requirements / Requirements Models / Use Cases
Posted on:
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 […]
Communication / Requirements / Writing
Posted on:
Secret decoder ring
I’m having a little trouble reading the spec – I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be […]
Communication / Requirements
Posted on:
Everything I Needed To Know I Forgot in Kindergarden
“WHY?†is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.
Communication / Presentation / Requirements / Requirements gathering
Posted on:
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.
Requirements
Posted on:
Spec writer wanted
Tom Chi, has a new article at OK/Cancel about the needs and challenges of having a detailed functional spec. He throws open the floor for folks to comment on what works for them. As a long time reader of OK/Cancel, I can tell you that they will get a bunch […]
Communication / Requirements / Requirements gathering / Writing
Posted on:
A Picture Is Worth A Thousand Requirements
Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.
OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –
Requirements management software
Posted on:
Consolodation in the RM Software space?
SteelTrace is targeted as a likely takeover candidate in this post from the Computer Business Review online. Borland (CaliberRM) and Teleologic (DOORS) are the most likely suitors identified in the article.