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â€
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.
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
Collision Detection
I was doing a code-read for a team member earlier this year, and stumbled upon an elegant algorithm. This is super-simple, I realize, but I believe it’s a great example of avoiding complexity. Einstein said it best – “as simple as possible, but no simplerâ€. Problem : Given two solid […]
Welcome to Tyner Blain
Howdy! I’ve set up this blog to keep track about thoughts I have in the software development space. I’m Scott Sehlhorst, president of Tyner Blain LLC. I wear a bunch of hats, playing different roles throughout the software development process. Tyner Blain was founded with two goals – helping customers […]