“[...]Is the challenge about requirements or the formal requirements process? If the latter, what’s really being asked is “Can one build great software in a committee?” And the answer is “no.” Committees bring compromise at every step of the process and the result is a hodge-podge of technology.”

“[...]The negative vibe on requirements generally comes down to two problems: 1) poor product management and 2) a misguided view of innovation.”
“[...]Railing against requirements is often another way of railing against poor product management. Too often, product managers are trying to document their opinions of a successful product. Students of Pragmatic Marketing have learned that product managers are messengers for the market. They know that “your opinion, although interesting, is irrelevant.” Product managers should bring market facts to the planning session instead of their opinions. And most of all, they should put those facts into context with problems, use scenarios, and personas.”

“[...]Formal requirements are about getting what you ask for, and about documenting what you ask for so that execs, marketing, sales, and all the other parts of your organization know exactly what they are supposed to be doing. It’s even more critical if you are outsourcing parts of your development, like validation, for example. In outsourcing, if it’s not documented in a formal spec, it definitely won’t be done properly (but it’s not a guarantee, either…).”

“[...]And what the hell is a “software work of art?â€? Before you write a reply, I used to be a coder, programmer, software developer, whatever you want to call it; I understand the concept of “elegant code.â€? It’s has the same recognition criteria as “pornographyâ€? vs. art…people can only identify it by example, as in “I’ll know it when I see it.â€? I’ll observe that elegant code does not affect a product’s probability of success because it’s not visible to the folks who buy and use the software.”

My thoughts on his response
These are some great comments about the value of a methodical software development process being critical to the success of critical software.

However, I do not believe that engineering and art are mutually exclusive. Elegance in engineering isn’t just about bit-twiddling, it is about understanding what problems to solve and finding innovative ways to solve them.

The notion of using Lagrange functions to estimate traffic levels and manage quality of service in telecommunication hardware is elegant. It redefines the problem in a tractable way, allowing for reasonable solutions.

Sending information on an AC power line by superimposing higher frequency data is elegant, as are TDM and WDM protocols for optical communication.

Being able to control the tire pressure on a Humvee from the driver’s seat, both to reinflate a flat and to adjust traction levels based upon terrain is a great solution to the “I get shot when I try and change a flat” problem. Much better than trying to design the perfect tire.

Velcro for little kids shoes probably saves every mom an hour a week.

Putting soap on the tip of a screw before driving it into wood (to prevent splitting) saves the time of predrilling a hole for the screw, and yields a stronger joint.

These same “higher level” signs of elegance are present in software too.
o Gmail uses tags for organizing email.
o Search-based configuration software allows solutions to otherwise intractable problems.
o Mapping software calculates fastest routes for me (and incorporates construction information)
o RSS readers allow me to pull information instead of publishers having to push it.

I’ve also received a handfull of emails from folks who chose not to post. I’ll post some excerpts from these emails (anonymously) in the following comments. Thanks again all!

The goal isn’t to document every detail, but to reduce the chance that customers, management, sales, and the product manager are surprised by what got built.

The are cases where (maybe big) up-front requirements are necessary — when the software contains complex calculations based on domain expertise. Likewise, if the software is to implement new algorithms or a new architecture these should ideally be designed via prototypes, and then specified in detail before being handed to the implementation team. These specifictions must include details of why things were and were not done a certain way, so that implementation team can improve that design. This makes them “big”, but necessarily so.

I’ve found that agile development works best for those parts of the system that are “shallow” like user interface, navigation, reporting, workflow. Agile techniques also work best when the team is already experienced, disciplined, and can instrictively head toward optimal solutions most of the time.

So agile methods avoid BUFR (big up-front requirements) and BUFD (big up-front design). But agile still calls for UFR and UFD, just wihout the “big” part. Then you iterate, revisiting and revising the requirements and design each iteration. Essentially, you do a bit of top down and a bit of bottom up each iteration.

99.9% of software is written by developers who place the keyboard squarely in front of the monitor and sit with good posture in chairs while they work.

We know from the body of ergonomics research that this is a good way to sit at the keyboard, but it certainly isn’t sufficient to make software not suck. Proper posture definitely won’t assure great software – and neither will managing requirements. Doesn’t mean that we shouldn’t do either one of them.

Would love to hear more about why you’ve lost faith in RDD. I believe that if you’re not getting value out of requirements, you’re not doing them right or you didn’t have the right people doing them.

Your analogies using Shakespeare are apt – it is unlikely that Shakespeare, given either “end” of the requirements driven process (defning or implementation) could have produced the works of art he did.

To produce software works of art, an assembly line doesn’t work. If you can point to even a few examples of software works generally considered brilliant that were built this way, I would be surprised. And if you had to look hard, it makes my point – 99.9% of software is built this way, and it sucks.

http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=352&entry=96749

It’s worth a read

In many cases, use cases often aren’t sufficiently granular (nor should they be) for scheduling. Craig Larman recommends dividing use cases into versions in such cases. I touch on this approach here:

http://cauvin.blogspot.com/2005/08/approaches-to-iterating.html

An example is a Purchase Items use case. You can break it into versions as follows:

Purchase Items (cash only, no receipt)
Purchase Items (cash, receipt)
Purchase Items (cash and check, receipt)
Purchase Items (cash, check, credit, receipt)

That way you’re delivering end-to-end value to the user after every version.

Thanks, Brad, and please let us know your thoughts on the other posts in the series as I get them out.

Scott

Nice series so far on Use Cases – a few comments:
- On the “cons” side firms should consider training costs as well. Not everyone is going to be comfortable writing and using Use Cases day one. Not that training is a big cost – just need to budget time to take care of it. Of course, Use Cases are no different than any other artifact of software development – and believe me, it’s a lot easier to teach someone to read a Use Case and get feedback from them than to read a functional spec.
- Maintenance is certainly a factor when collecting a lot of detail. And once you go into Design, you know things are going to change. One option is to use Use Cases to bootstrap the project – get everyone on the same page and get rolling into requirements, then drop them. Of course, you don’t get the benefit of using Use Cases in the future that way (e.g. Test Scripts, starting point for future projects/enhancements).
- I like the IMS link, never came across that one before. Interesting idea, though there’s not a lot there yet.

Your example about red/green buttons is a good “real world” example, because it can go either way, imho. It’s definitely not a requirement – I agree on that. I also completely agree with the rationale (it could also be structured as a goal) to minimize user confusion in the UI design.

Depending upon the nature of validation/signoff conversations with the stakeholders, it may be a constraint. I’ve worked with clients before who had ‘corporate policies’ to which all new software development must adhere. And I’ve seen those policies talk about the minimum number of pixels between controls, specify fonts, graphics, screen layout, etc. When those are in place, and considered to be “out of scope”, they should be captured as constraints – and referenced as external documents.

I also worked with a client who was given dietific power over all things related to the project (by his boss, who signed the check), and who was a micro-manager with “very strong opinions”. After beating your head against the wall of trying to remove his constraints about every nuance of the deployment, ultimately we elected to pick our battles and fight against his fiats for only the most important issues. In that case, his omnipresent opinions became constraints for our project.

Roger’s right – when you can remove “design details” from the acceptance criteria definitely do it. When you can’t, capture them as constraints.

But I think there’s some confusion here about the difference, if any, between a “rationale” and a “requirement”. In many cases, the requirement and the rationale are one and the same. In fact, if you find yourself tempted to append explanatory rationale to a specification, it’s worth questioning whether the specification is a requirement or a design specification.

To illustrate, here is a concrete example. In my MarketingProfs.com article on requirements (see http://www.cauvin-inc.com/articles/ProductFailure.htm), I wrote:

“Imagine that you tell the user interface designers of a software application that ‘OK’ buttons should be colored red and ‘Cancel’ buttons should be colored blue. You have an important reason for this mandate: all of your key users are used to this color scheme and may press the wrong buttons if you deviate from it. Eureka—now you’re closer to the real requirement—avoiding the data loss or waste of time that might result from a different color scheme.”

In this example, you might categorize the OK and Cancel button specifications as requirements. The rationale for this mandate is avoiding data loss and waste of user time and effort. I don’t agree with these categorizations.

User interface design specifications are not requirements. In this example, contraints on data loss and user time and effort are not just the rationale, but the requirement. Mandates about the OK and Cancel buttons are useful solutions for the UI designer to consider, but they are not requirements.

My definition of requirement (see http://cauvin.blogspot.com/2005/06/definition-of-requirement.html) is:

“A requirement specifies the least stringent condition that must hold to solve or avoid a prospect problem (problem that a prospective customer faces).”

In the example, mandates about the colors of UI buttons may be binary conditions, but they by no means are the least stringent ones that must hold to solve or avoid the customer’s problem.

Tony, I hadn’t heard of the technique of including the rationale in italics under each requirement that supports them. As you alluded, in complex systems (where multiple requirements support a given rationale, or where multiple rationale are supported by a given requirement), this would be very hard to manage. Rationale are more stable than requirements, but they are still a moving target – especially in Agile development.

Would it make more sense to reference the rationale from the requirement body? We reduce the risk of stale rationale hiding in the requirements, and we avoid the cost of updating the rationale for a bunch of requirements. Maybe keeping it in the body of the requirement forces us to validate that changes in rationale do/don’t affect their supporting requirements this way.

What do folks who’ve used this (embed the rationale) technique think?

Without a tool the traceability that you mentioned is very difficult, especially if there are a lot of requirements. In an environment where a requirements management tool is not being used, how do you do the traceability between goals and requirements?

The standard way to document a rationale is to include it under the requirement and in italics. There may end up being some repetition if a single rationale maps to multiple requirements.

Great minds think alike, Scott!

By the way, I don’t agree that “controls must be at least 10 pixels apart” is a requirement. My belief is that true user interface requirements generally specify how easy it is to accomplish functional goals, not designs or design guidelines. See “Mistake 5″ in my article, “How to Guarantee Product Failure”. The link is http://www.cauvin-inc.com/articles/ProductFailure.htm.

Thanks for the comment and insight. I completely agree that it is the responsibility of someone on the development team (coder or tester) to design the particular tests – or in the car example, a quality engineer.

However, part of the validation of a requirement is that it can be implemented – or it shouldn’t be a requirement. One component of validating a requirement is assessing the language of the requirement, to determine if you can unambiguously identify it as being complete. The QE needs to manage the design of the test, but as part of accepting the requirement from the requirement writer, the QE should make sure that he knows how to test it.

Collaboration and iteration are key to writing great requirements – feedback from the QE is what helps the requirement writer rewrite the requirement. And that feedback cycle is important, because the requirement writer will then have to get signoff from the stakeholders that the rewritten requirement is sufficient – perhaps they only need 80% confidence.

Also, the design engineers need to know when they’re done. Do they have to build a Yugo, or a Volvo? Without an objective criteria as an input to their design process, you can reasonably expect that they will design something you don’t want.

You make an excellent point about “losing sight of the real requirement” – I will post in depth on this topic soon. The goal (or “Goal”) is high reliability for the car, and presumably someone has done an ROI analysis that says that 7 years without breakage is more profitable than 6 or 8. This should absolutely be documented. A supporting functional requirement should include the actionable details.

Thanks again for the comments, and keep posting good stuff to your blog – I enjoy it. Oh yeah – Tyner Blain is the company – I’m Scott :)

As I mentioned in my post, the seven year requirement is, in principle, testable. It just takes seven years to test it. It is testability in principle that ensures the requirement is clear and unambiguous. (You are right that driving habits and such would also need to be included.)

The seven year requirement is not practical to test directly, however. Thus, as you suggest, we must devise a test that is reasonably expected to simulate (or predict) what will happen in seven years. But that is the job of the tester, not the requirements analyst. For testability in practice is not what ensures a good requirement. Testability in practice is important .. er .. for testing!

Scott

Cheers,
Jim

Overlap = A.start before B.end && B.start before A.end

Likewise, you can remove the negative logic with the following:

1. the right edge of A is to the *RIGHT* of the left edge of B
2. the left edge of A is to the *LEFT* of the right edge of B
3. the bottom of A is *BELOW* the top of B
4. the top of A is *ABOVE* the bottom of B

IF (1 && 2 && 3 && 4) THEN collision == TRUE;

Both solutions are fail-fast, so the change is mostly semantic.