This post isn’t about composition of requirements. It is about using the object-oriented concept of composition when expressing requirements. Composition is the notion that one object or entity is made up of multiple smaller objects. Grady Booch’s Object Oriented Analysis and Design with Applications (2nd Edition), is the de facto […]
Ideavirus – Marketing By Word Of Mouth
When you launch a new software product, or start a new blog, or a website, one way to get the word out is by viral marketing. Thanks to this post on the Presentation Zen website, I found a great presentation by Seth Godin here. Lots of good examples, from Google […]
Agile Requirements
One of the key points that enables James’ approach is “tight collaboration†between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.
More on talking to your audience
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 […]
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.
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