As the customer, I'm going to tell you I want a quarter inch hole rather than give you specs for a quarter inch drill. What I want is the benefits the product will provide to me. The more technical-orien ted BAs can take a cue from marketers in this regard.

Clearly you did not define "state of the art" - so no, that would not be a requirement. If you consider requirements the things you must have in order to meet a specific need, then requirements are important! You have documented your "wants" as requirements, it would be okay to include them with the requirements, as long as it is clear that they are not requirements. . A good BA will be able to guide a "customer" into those things he needs and also document that certain things are "wants. I also suspect that requirements for a house (unless you have specific physical limitations) are not going to be as hard and fast as those for a business. If instead you documented the zoning laws and regulations for construction, then you would indeed have a list of true "requirements".

Requirements can be broken down into those that deal with data, actors, Use Cases(process), business rules, and non-functional issues. Some things need to be exact (e.g., data), some can be more abstract (non-functional ). I agree that having everything taken too literally or blindly will miss some key points. Prototypes (iRise) and frequent demos to the customer will hopefully sort out features that are on/off the mark. Words are very ambiguous and can bog a project down. Pictures are needed to add clarity.

I think the first example states what are lower level requirements (yes, I said it) for the higher level goals and objectives in the second example. What if you really, really wanted a log cabin? Think you will necessarily get it with the second example? What if you really, really want granite countertops? Is the "simple nature of a Maine kitchen" going to be intepreted exactly the same way by two different parties?

Yes, requirements ARE restrictive (and often stifling to solution provider creativity). They have to be especially if the work is going out to bid. The nature of many fixed bids is that if it isn't already included (or explicitly "listed"), then it is additional cost beyond the "fixed" bid. We BA's can learn a lot from Six Sigma... namely in truly defining the problem before embarking on the cost of the project. Your original list (missing the "budget" requirement?) to the architect is your idea of the solution with wants included, not your needs. One of the problems with projects is that we have requirements without enough context and too many of them are written from the solution perspective, not the need perspective. You can provide context to requirements using metadata or Tom Gilb's "Plangauge" keywords (recently picked up at BA World Boston). Whatever you use, context and perspective must be represented so there is enough understanding to what the needs are.

Bob - so you want 'state of the art' kitchen appliances (me too!). But as Dayle says above, what exactly does that mean? And is it in conflict with the simple nature of a Maine kitchen? Doesn't an archetypical Maine kitchen include a wood cooking stove? And what kind of cooking do you do? The kind that requires a high-end gas stove with precise burner control? And what if there's no convenient propane delivery and you're stuck with electric appliances? An yway, the point is that clients often give us a vision that includes conflicting requirements and we have to challenge them to get specific. People often don't want to do the hard work of thinking; we get paid for prodding them to make decisions that are in their own best interests.

Can I be so bold as to suggest that the issue here is that many PMs & BAs along with their business sponsors/stakeh olders seem to forget that everything in a project flows from and towards "fit-for-use" deliverables. I tied everything to the project deliverables so that I can trace everything back to the specific deliverable. All my project management actions are directed towards the production of "fit-for-use" deliverables -- pure and simple. If a requirement, or what I like to call features and capabilities, are not oriented towards the production of the agreed-upon deliverables, they are "out of scope." I use this concept to drive project focus, change management, and customer acceptance regardless of if the project deals with bits or atoms. V/R, Pau l

The way I see it is that both are needed. The second example is the customer needs (i.e, the business requirements).. . the "What". The first example is the functional requirements to meet that need after having interviewed the customer (business)... the "How". Great article!

Bob, I agree with your point regarding demanding anything specifically limits solutions. We should be trying to create solutions to business problems or opportunities. Ultimately you need to provide your ok as the customer as to what the solution will be. An architect will show you pictures and blueprints of what your house will look like. BAs can do the same thing utilizing visualization tools such as iRise to show the customer what their solution will look like and behave.

Correction: Sta ndard requirements traceability ends with metrics that prove the business goals were met by the requirements. The spellchecker doesn't recognize the word traceability!

Bob, that was good illsutration you made. Surprisingly, most of the comments were made by guys!!

From my experience, this is probably a situation where too many people, in various roles, are overreacting. Requirements, and the process to get to them, do not have to be restrictive. If money is not an issue, the project approach, the project timelines, and staffing timelines are usually the reasons for restrictions. If you have no time constraints to build your house, you can revisit the requirements scope over and over again. If you have cost contstraints, requirements scope changes may have to fit within whatever work has already been completed. So, you may not be able to get the newest gadgets unless you're willing to pour in more money, and time. Also, the same, or similarly qualified, subcontracting staff should be available too, and for the new duration of their part of the work. The point is that the level of overeaction, and degree of restriction placesd on the requriements, probably have to do with the understanding, or misunderstandin g, of what the project approach and the project constraints are. If everyone on the project agrees that all the time, staff, and money needed to build whatever you want is available, then the scope can remain open - but the restriction here is, 'only up to a certain point'. Even if the building process follows agile methods, at some point, the project has to come to an end. At that point, smaller enhancement projects, or another build project, can start up. Otherwise, when does the project end, so that at least some of the assigned resources can move on to other experiences and other projects that need them? Also, what cost do you measure against when you want to measure whether or not what you have, at some point in time, is worth the resources and time you've already burned through?

This seems to be the exact issue that was addressed back in the 1980s as the difference between logical and physical models, (DeMarco 1978, McMenemin & Palmer 1984.) The 'customer' should be describing and modeling the capabilities or expected uses of the new product. The designers & builders should describe the available technical possibilities for accomplishing the capability and/or uses. After far too many years in this business, I see that customers are still asking for the latest whiz-bang technology that they've seen with little attention to how it will fit their business. Most designers and builders are just going along with the customer and implementing whatever they can, within the limits of their current environment, with little of that all-important negotiation going on before building begins.

If you want to be technical, a roof is more of a requirement for a house than a sauna. Counting you and your wife as one purchasing unit, the house will have have exactly one purchaser and user; therefore, your strong preferences really are requirements in the case of the house that you'll spend lots of money to design and build. If you don't make those strong preferences clear, your architect will be re-drawing or you'll be retrofitting your sauna, both at some cost. Either way, most applications have more than one user and preferences are things that have to be taken into context, along with ergonomics, best practices, cost, environmental stability, generalizabilit y and scaleability, etc. One thing I dislike about Agile is that boiling requirements down to acceptance criteria focuses too much on "requirements" and skirts the context, even though it advertises the opposite; the tendency, in the end, is for customers to "require" their preferences and for developers to deliver "good enough" because we too often trim the tail on anything extraneous. While I don't necessarily believe waterfall is the better approach, I prefer the waterfall-style elaborations in advance of agile delivery. The discussions we used to have during elaborations enhanced the developers' ability to assert their creativity because we had time to take true situational requirements like "needs 2-3 bedrooms" from your first list in context with design goals such as "I need an office" from your second list, discussing the options to combine or the need to keep separate -- and of course this is an oversimplificat ion. Once designers understand the usage/ergonomic s as well as the strict inflexibilities , something that comes from a larger discussion, they can be creative in presenting and negotiating solutions. We often forget that, even though our customers may purchase our output, they don't have to use it and can influence the purchasing decisions of others. Ergonomics and other preferential "non-requiremen ts" are still important, but should be part of that context. I'm advocating more balance. Many things impact how strictly we adhere to true requirements, including the specificity of the app (you can't be "creative" about certain calculations or functions), the size and skillset of the targeted user pool, budget, time, anticipated life, etc. Often, we negotiate "requirements" because of the practical trade-offs involved in delivering certain features. For a application targeted to a very specific function or user, such as the house analogue, preferences practically are requirements. Log cabin, italian tile, granite ... those are cosmetics and would typically be tweaked in an agile delivery; they often can be omitted from requirements altogether for systems development. But whether it's technically a "requirement" or not, if you intend to purchase a boat, you will need somewhere to put it, hence the "goal" will uiltimately be a requirement for your specific home. It might just be a task for Phase 2. Most systems are designed in a far mor generalizable manner by necessity. In my experience, neither of your lists alone would yield a good balance of practical adherence to the constraining realities and creative, robust design.

What a difference a week makes ;-). This post has received the most comments of anything I've written for BA Times. I'm quite thankful for the effort and insights shared by everyone. I do want to point out something that many (most...all) of the comments have missed. One of the key points to my article was creating request-based language between a customer and team (BA represented of course ;-) that fostered: - Conversations and collaboration - Visualization over words - Customer needs triggering the teams' creativity & innovation energy - A focus by the team, not on blindly delivering what they were told, but on creatively and simply solving the customers' problem It was this collaborative partnership, driving the teams' innovation, that I was keen to explore. It was the open-ended-ness of the second list that was intended to draw the two together and hope for some of this result. Instea d of focusing on this, and I know I'm generalizing, most of the replies focused on more of a contractual arrangement. While that's easier to define and deliver, the very premise of this post is that it often *restricts* the results. Tom Ryder & Henk came close to addressing this in their replies. A few others as well. But most of the replies were more of a "restrictive" nature. But all are making me think some more about this... Thanks to everyone! Bob.

Numerous factors have lead us to put too much weight on the word “Requirement” and it has silently encapsulated us by the definition that we all believe it to be. I think the simple solution to our standardized (NOT organized) chaos is to completely denounce the word in the design context! “Requirement” is nothing more than a label for a unit of measure in determining a project’s completion but NOT project success or customer satisfaction which tend to be the most important. We use it as an excuse to never be held fully accountable (and decrease the probability for litigation). This word literally stifles our creativity and autonomy; the very reasons why we do what we do… But please don’t misinterpret my comment as a suggestion to blindly disregard your legal department! :-) NOT, the case… A little common sense usually helps with those situations! Anyway, so, let’s just stop using the word and see how things pan out… Let’s rename “Requirements” as “Use Articles” or “Charge Articles” or “Action Items” or “Deliverables” or anything less official. “Requirement” transcends too many markets so it has limited room for interpretation. These other terms require that designers be CONFIDENT in their own abilities, thus, being ACCOUNTABLE for their creativity and interpretation of customer use and fostering trust between all parties. I believe that customers rarely know exactly what they want but they most often can quickly and effectively convey what they DON’T want… If you present a myriad of options and require your customer to be engaged in the process, you will eventually get to one that they not only will accept, but that they will ultimately find the most USEFUL (and probably in ways they had never even considered). B As are travel agents… or Concierge… simply stated: “Use Agents” (*begin Inspector Gadget theme music in the background!* ;-) Some folks don’t know where they’re going, but they know how they want to get there… Some folks know where they want to go, but not the best or most effective way of getting there… And some folks know where they want to go and how they want to get there… we just work on the quality of the Rest Stops and Layovers… Know your traveler… Be Confident… Be Accountable… Deliver Function… Measure Satisfaction…

To me "requirements" are an artefact from a number of system/software design fads. I have seen them used to try to regularize the communications between the design organization and associated implementation organization(s) ; and to try to dissect larger problems into subsets that could then be implemented in parallel. As described in these fads I think there are some limitations: 1) Requirements do a poor job of guiding the development organization to an optimal solution. So, in the cabin example, if making the cabin out of logs increases the cost by 5x, then would the customer be willing to consider alternatives? A more subtle aspect of this is that there may be a range of answers to this question, for example, 2x is ok, 5x should halt the process to ask the customer, and 150,000x should automatically halt the process. 2) The larger the problem the more time the requirements process can take and the larger the risk that the fundamental need will have changed in the meantime. I have seen this a number of times where the requirements/fu nding process went on for so long, that when it came time to implement something, there was no longer a customer for the solution as stated in the requirements. 3 ) Requirements do not decompose well. What I mean is that a requirement as stated at one level of understanding may drive numerous contradictory requirements at lower levels. See my point 1) again, but the subtle problem is the loss of context within which to have a decision making discussion with the customer. From the cabin example: building codes for cabins at the lake may require mould protection, mould protection may come in a number of forms, so the customer is required to choose, but has no ability to understand how this choice affects the usability of the resulting cabin. 4) Some requirements processes have trouble keeping up to the rate of change of the real world. I don't think the problem is the "requirement". The problem is adapting the use of the "requirement" for each solution implementation system.

I try not to point out one comment over another comment, but rather to take each one and value it's intentions. I value them all. But sometimes someone truly "hits the mark" and gets to the essence of what I was trying to say. Often much better than I originally said it ;-) Mike T. - Thanks for your thoughtful and insightful comment. Whether folks agree or disagree with it, IT comes very close to representing the core idea of this post. And I thank you for taking the time to post it. Bob.

Requirements are in my opinion the result of the conversations with the customer and usable for the development team. Everybody has its own division of work and it would be strange if you hire a specialist in requirements engineering and you will have to come up with the specifications. Please, make the best use of the expertise of your listener. If you go to a dentist, do you make up the requirements or do you simply say 'oh sometimes in my left upper jaw it feels itchy drinking cold water' and leave the rest to the specialist. Bu t in the end, you will have to agree what will be built for you. For that you need the list of requirements. Requirements are not the starting point of the conversation, the are the end point of your talks with the requirements engineer and the starting point of the development.

Bob, I think your over-reacting to the term requirements. Requirements are utilized in both cases. The difference is a matter of responsibility. In the first case, the customer assumed responsibility. In the second, the customer delegated the requirements to the solution team whom the customer expected to interpret, collaborate, and create. In the case of building a house, I would think the requirements sit with the customer. I personally would not want "my architect to 'delight me' by interpreting my goals, collaborating with me, and leveraging their creativity to create something 'just right'. However, I recognize that everyone is different, and I do see some value in using an architect as such (to some degree). Desig ning a house (even a custom cottage on the lake) is more abstract then designng an IT solution. So, an empowered architect is not required. An IT solution certainly does require an "architect," but not one that will only interpret, collaborate, and then create, but also analyze and more often than no specify. Where there is a need, there will also be requirements. Who develops the requirements is the question.