I was reading ok-cancel today, and saw an article about getting UI designs ‘through the gauntlet’ of different groups of people at the client. Kevin and Tom consistently provide great insights on how to thrive in the HCI world, providing insights both in how to navigate customer-politics and processes, and […]
Requirements mess article in CIO magazine
Btw, here’s a link to the article in CIO magazine, that I mentioned indirectly in my previous post about the requirements mess. This really is a great article – it includes 3 case studies of how different CIOs dealt with the problems on their teams.
Intimate Domains – navigating areas of expertise
People who elicit and manage requirements – product managers, business analysts, program managers, and others – also orchestrate and communicate with their clients. In an enterprise software project, the requirements manager (RM from here on out) has to communicate with people across the client organization. To pass along information, gain […]
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
How To Deal With Untestable Requirements – Rewrite Them
The premise behind the rule that requirements must be testable is driven by the goal of avoiding ambiguous language in your requirements. Statements like “the application must have a clean user interface†or “search response times must be fast†are also untestable, but more because of language than anything else.
Fixing the Requirements Mess
“71 percent of software projects that fail do so because of poor requirements managementâ€
Requirements and Software Development Process and Where Bugs Come From
[Ed: This post was retitled, edited, and updated as Where bugs come from due to recurring issues for some readers with accessing this page. Please read the updated version (there are some revisions to the content and new links to other content). Thanks]
Telescopes, Microscopes, and Macro-scopes – How to View Requirements
Writing good requirements is more than just taking dictation. It is about documenting the goals and needs of the stakeholders (users, project sponsors, etc), in language that the creators of the system (developers, testers, etc) can read. The requirements have to be complete and correct, and they also have to […]
Concept Maps – Great Tool for Eating the Elephant (Brainstorming Ideas for a New Product)
Concept mapping is a tool I use for the brainstorming process of defining a product’s specification. IHMC developed the concept mapping software that we show in this article