Napkin Requirements

No, this post isn't a dump for requirements for the manufacture of napkins.

Becky Winant explains what we're after:

We believe in miracles. Ever hear a story about how some genius sold his idea based on a napkin sketch? I think sometimes we expect our analysts to do the same. Hey, once the sketch is down, we’re done! Time to hand the napkin over to production.

Requirements come from customers, but Frank Sommers notes that (as Jim Herrick would say) "it's hard":

Many books and tutorials about agile development start out with a familiar scene: a developer sitting with a customer, together defining the requirements and setting the milestones for a project. Complex project management tools, as well as suit-and-tie business analysts, are shunned in favor of paper and pencil or, better yet, the back of a napkin or an envelope.

This scene about agile requirements gathering came to mind earlier this week, when I interviewed for an Artima news story Rob Cheng, Borland's director of developer solutions. Cheng, whose job involves talking not only to developers, but also to CIOs and CTOs, noted that real-world requirements gathering is far from being agile in most IT shops...

But what are requirements? Richard M. Marshall elaborates:

There is an amazing diversity of ideas about what constitutes a set of requirements, let alone what makes good requirements. Everything from a few words scribbled on a Starbucks napkin to full-scale UML models are candidates. As with many things in IT, and despite what some gurus might say, there is no "right" form of requirements. The correct form for requirements will vary from project to project.

Yes, there is a wide range of views on requirements, as Roger Jack reiterates:

I realize that the level of formality in requirements is related to the size of the project. In other words, a programmer that develops a tool for his own use may only need to sketch requirements on a napkin, if at all. On the other hand, a large business project with many developers SHOULD have requirements specified in some sort of document.

Larry Borsato looks at requirements from the entrepreneurial point of view:

Of course there does exist some basic requirements or a back of the napkin sort, but the formal requirements process doesn't usually pop up until a little later. In most startups, one person might wear that hats of engineer, product manager, and salesperson.

Martin Beechen also discusses the wide range of views on requirements:

In my experience, requirements is a very touchy subject in the development community and is highly subjective. To some people its a few random sentences written with crayons on a napkin, and to others its several hundred pages of detailed analysis based on extensive interviews, market research, user groups, and sales trends. A lot of people also tend to push product requirements, functional specifications, and technical implementation all under the general "Requirements" umbrella.

Let's turn to Anton Aylward:

InfoSec is writing the specs - the policy, the requirements, and they are doing it in cooperation with not only IT but also with other stakeholders.

This is no different from a software or hardware development situation, or, for that [matter], the original set-up and procurement that went onto IT. Someone did a needs analysis (even if it was only guesswork and a paper napkin), wrote up a requirement and handed it over to the people that “made it so”.

I appreciate that this ‘formal’ approach is being depreciated by ‘agile’ methodologies where the techies work without any of the formal management structure, without specifications or formal requirement, writing and running their own tests, all in the name of “Web 2.0″.

And, speaking of agile methodologies, let's hear what James Shore has to say:

Simplifying your process sometimes means sacrificing formal structures while increasing rigor. Think of your agile method as an elegant mathematical proof sketched on the back of a napkin. For example, although sitting with customers decreases the amount of formal requirements documentation you create, it substantially increases your ability to understand requirements.

So there's a summary of the thoughts related to napkin requirements. I will try to cover paper towel requirements in a later post, but remember that the paper towels have to be rolled back up, requiring a certain level of...agility.

napkin

Sphere: Related Content