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.
Communication / Project Management / Requirements / Writing
Posted on:
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 […]
Software development / Usability / UX
Posted on:
User Centric Design Yields (Not So?) Obvious Features
An application lives or dies by its ability to allow users to achieve the goals that drive the creation of (or purchase of) the software.
Requirements / Software requirements specification / Writing
Posted on:
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
Requirements / Software requirements specification / Testing
Posted on:
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.
Outsourcing / Requirements
Posted on:
Fixing the Requirements Mess
“71 percent of software projects that fail do so because of poor requirements managementâ€
Administrivia
Posted on:
Tyner Blain Added to Technorati (Rank: 983,109)
http://www.technorati.com/search/tynerblain.wordpress.com The newness of the blog has placed us at an absurdly low rank. Let’s see how long it takes to climb. First goal: Outrank existing, dead blogs with no new posts in the last year.
Process Improvement / Requirements / Testing
Posted on:
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]