Let Your Designs Become Your Requirements

Anyone care to take a stab at this, preferably from experience?

I find this hard to swallow; it strikes me as counterintuitive. Requirements flow from the users; we build software for a specific purpose, and a clear and complete expression of that purpose is the requirement. It is basic: What does the software need to do? What functions must it support? There can be great value in doing this largely in isolation from system considerations or design choices.

It's always a bad thing when "design decisions" become requirements. For example, requirements that inter-process communication be done with CORBA, or requirements for certain implementation languages, libraries, etc., requirements for a particular high-level architecture, or requirements that all design be done with a particular UML tool. There may be cases where a customer/client cares about such things (for example, when a client is going to maintain the code after you write it), but when they don't, then don't shoot yourself in the foot by locking yourself into particular implementations. --KrisJohnson

Given a project with a set of designs and no requirements, what do you do?* Kill the project on general principle? Figure out who the users are and consult them from scratch on requirements, ignoring the design work done so far? Or can you backfire a set of requirements from the existing designs? All of these are possible; which are the more feasible depends on local conditions, and to some extend on you and your talents. What do you choose? -- WaldenMathews

(*) If you're thinking this is a purely hypothetical problem set-up, think again.

-- WaldenMathews

Oh, I realize it isn't hypothetical. The project I'm working on now (a defense contract) is doing exactly that, and it is very silly. -- (strong responder)

Maybe you should try this, given that the conditions are nicely set up for it. Let me know how it turns out. -wm

I would hope this was an exception, and therefore, not try to generalize on it. --RobertDiFalco

Thanks for the calm reply, Robert. It's an exception except where it's more the norm. What I'm referring to is programmers uneducated in the business of requirements per se. I wouldn't bother to write about it (and based on results so far, may soon decide to abandon), except that I've noticed how the standard approaches to educating programmers to the slippery slopes of requirements elicitation don't work. The blunt introduction of "Requirements" causes hallucinations of large documents and all kinds of other distracting mental phenomena for these folk. Also, the connections to CMM and waterfall models are there. But requirements is a simple thing at base concept. The key is to find a way to get from programmerly design thinking to helpful requirements thinking without the distracting baggage. One way to do that, and perhaps the only way given the context I've described, is to "backfire" from design into questions about what's actually valued by the user. "Why CORBA; would Bill care?" is an example of how this would be done. It's accessible; that's the main thing.

To the person who reacted strongly at the top, the operative word is "become", and by that I mean that you may transform designs into requirements (if you know how), not that you should adopt a code design as a requirement. Our goals are apparently the same, while my tactic seems misunderstood. -- Walden

I believe I understand your "tactic", and I acknowledge that it could be done this way. I just personally find it backwards. As long as it works for you, cheers!

I would say in those cases where one is walking into a project with no requirements but a mature design, it is perfectly reasonable to harvest (reverse engineer) the requirements from the design. However, it is sometimes still worth the extra effort to go through the requirements process if for no other reason than to validate the current design. JMTC. --RobertDiFalco

I think of published APIs having this situation. You can't break legacy code, and often you have no idea why a function is defined as such. -- SunirShah

Purist designs also have this situation. The Smalltalk class hierarchy aimed to consistently express a particular design philosophy. Failure to do this often leads to unnecessarily complex systems, like the Java, POSIX, and Windows APIs. -- SunirShah

Frameworks, APIs, class hierarchies, etc. may be a special case. The potential user base is broad and intangible, and not the usual kind of "users." Requirements are probably usually implicit or informal, and certainly abstract and high-level. And things like "consistent design philosophy" are themselves informal but important requirements... -- (strong responder)

Sunir, published APIs and "purist designs" sound like very similar situations, driven at core by a "requirement" for reuse. But that's away from the topic I intended to open here. I meant user requirements, backfired from a design specification worked on by both programmers and users. Have you ever had this experience? --wm

Walden, I think you're "lucky". Don't complain too much or the next project you'll face "let the source code tell you the requirements". Or, God forbid, let the disassembler tell you the requirements.

I'd consider myself luckier if I knew who you were, but no matter. I think you may have confused the voices on this page, because I'm not the party complaining. I'm the party saying "People of zee worl, relax." Relax about those designs. Relax. Get sleepy. Fine. -- wm

Just for clarification, are we discussing the generation of requirements or the documentation of requirements? I can see generating a Functional Requirements Document after the design, but not the requirements themselves.

The discovery of requirements, but not necessarily isolated from the process of documenting them.

What is it with this trend towards making counterintuitive, backwards statements?

The concept of requirements before design is anything but intuitive. If you start out to solve a difficult problem using intuition, you will always throw some already baked solution at it to see how it fits. You may do this repeatedly, each time noticing how the fit was less than perfect. Similar to how ancient languages have been reconstructed through the discipline of comparative linguistics, you will eventually form an image of what's actually needed after witnessing a series of designs in partial failure. Strangely, as this body of needs comes into focus, you may feel as if your project is just beginning. Once the requirements are well known, the composition of an adequate design from them is not very difficult. An unexplained tendency to forget the difficult, failure-laden early stage leads to the fallaceous theory that requirements preceed design. Failed attempts to force strict stagewise forward-only lifecycles on hard problems are a clue that we are deceived as to the actual processes in place.

Turning the most entrenched assumptions on end is a technique for testing how accurate those assumptions are. It's about the freedom to change your thought patterns. Even if some backwards statements provide no light, it's a valuable asset to cultivate an imagination that can accommodate them briefly. The extreme inability to do that is called idiocy, a term we don't like to use because of its associations with verbal abuse, but a concept we need to be cognisant of.

Sure, I understand and agree with the spirit of challenging assumptions; I'm generally the guy who rocks the boat in my organization. But to me, this isn't just about "forward-only lifecycles" -- this is about why we build software in the first place.

Most of the time we build it for a specific purpose; a clear and complete expression of that purpose is the requirement. You can do that without even addressing design or any possible solution.

Yes, you can also approach the process of building software to serve a specific purpose by trial and error: first, you design (and possibly build) a solution, then you evaluate it with respect to the specific purpose (the requirements), and then revise your design/solution, and see if you've got a better "fit", and so on. Then you can say "Solution 7 does what we need, so what we need must be a Solution 7!" Bingo, you've backed into your "requirements," and nobody had to waste hours of the users' time in interviews and writing use cases (instead, we wasted weeks or months of developer time taking a stab at what the users need). I don't think this is necessarily a good way to go about deriving requirements...

Requirements come from the users, period.

Sometimes requirements come from God, but we can't discuss that here because it's off-topic. Requirements coming from users "period" are in the same category as requirements coming from God. Why is that? Because except in your wildest dreams, it's never that easy. A user who can competently write requirements without interaction with developers has to be too rare to warrant consideration. In the majority of cases, requirements pop out as the result of developers and users arguing the merits of one solution or another. Requirements are validated by users but they don't come exclusively from users.

You're muddling the issue here. When I said "requirements come from the users," I didn't mean they discover and document them and hand them to use (we should be so lucky!). I mean the purpose of the system flows from the users and their needs. It might often be tempting to put the cart before the horse -- even though design is hard, requirements is much harder. We have all kinds of great tools and techniques for modeling and building designs and systems, and they are far more tangible and "satisfying" than slippery requirements. My whole point, why the very premise of this page "gets my goat", is that with all our training and tools and such, IT people often start down the road to Building Systems too easily and early, and we forget WHY we are doing it. I think we must always strive to keep the ultimate purpose in mind, and more often than not, the purpose is to help someone do their (NON-IT) job...

This seems to be the crux, then. I see no inconsistency between keeping the ultimate purpose in mind and allowing expressions of system design to be the medium through which high quality requirements are found. The word flow to describe how the purpose of the system is bestowed by users is highly metaphoric, and on careful examination, somewhat inaccurate and damaging. I offer this present tactic precisely in the context where your goat was got. With all that training and tools, they still start down a different road. What can we do about that? When younger, I though about barricading the road, but that's silly. A better approach is for you and me (the holders of superior knowledge and talent, yea?) to join them on that road and see where we can come out together. Start with what they're comfortable with, and help make it about ten percent more useful. That's it. Help the design become the requirements. Let that happen.

Sorry that this page irritates you so much. What would you like me to do?

-- WaldenMathews

Walden, you don't need to do anything! If I understand your point and purpose in creating this page, to stimulate thought and discussion, then you've succeeded nicely. As for me, my particular reaction to having a basic assumption exposed and questioned has been, well, irritation. Is that my problem or yours? I'd say mostly mine. (I hope you've noticed that I've gone back and toned down some of my argumentative, derisive comments. I apologize for those.)

Let's run with the road metaphor a bit. Would you agree that a roughly equivalent expression might be something like "Let your road become your destination."? If so, then I agree, yes, you can do that, and it would be great fun, an adventure, a learning experience, and so on. Look at what happened to Bilbo Baggins in "The Hobbit"! BUT, if you need to accomplish some task or mission (or quest, here we get more like "The Lord of the Rings"), then you have to keep your destination in mind at all times, regardless of the distractions and side trips along the way. As one of those hopefully somewhat more experienced people (Gandalf?), then when my companions start merrily down a road (presumably because it is well known, familiar, etc.), I am going to stand still and call to them "Do any of you know where we're actually going yet?" (smile)

p.s. -- For some reason I don't feel comfortable including my name here lately. I think part of it is that I think my ideas (and everyone else's here) need to stand on their on merits, and not on an reputation of the authors. At first I always signed, but now I prefer to stay anonymous. But I periodically question myself about what I would say differently if required to sign. I suspect that I wouldn't be so absolute and derisive, and I'm trying to get to that point from the start, rather than have to revise my outbursts later.

Exactly how would one go about implementing LetYourDesignsBecomeYourRequirements?

Pretty much according to nature. Design ideas will surface all by themselves, as explained above. A developer may document a set of "accepted" design decisions, and even call those requirements (by naming the document that). Although these decisions are more constrained than they have to be, they represent learning had through interaction with the users. The thing to do here is not to ditch them on the basis of process purity: "Those are designs, not requirements." The thing is to use them to get to a more suitable, less constrained basis for doing the project. The key question to use in eliciting requirements from proposed and partially adopted designs is "Why", and the key context in which to use that question is a comparative one. "Why would you use so-and-so as opposed too doing such-and-such?". The answer will be closer to a value or valued condition than the design from which the question arose. Because of the prevalent mental model that "requirements come before designs", I'm calling this backfiring of requirements from designs, to aid in the visualization of the process.

First, there is no software in nature; software is entirely a man-made artifact. You can characterize design ideas as "surfacing all by themselves" if you like, but they aren't magic -- they come from your brain or mine! There is no doubt that early in a project, design ideas come unbidden, and I generally note them down and set them aside and try to focus on understanding the requirements. Now, if you want to use prototyping or iterative, incremental development approaches to go through multiple cycles, and use that to define/refine your requirements, that's fine. But I don't see that as "designs becoming requirements"...

Third party interjection: I am not sure you are both using the same definition for "requirement." If we first agree on what we mean by a requirement, then it will be easier to decide when the requirement must come into being.

So the question remains. Is there anyone out there with experience in helping "requirements challenged" software teams work off their software designs in order to get a bang up set of requirements for the project? Come on, the universe is a big place. There must be one instance in someone's memory somewhere.

The underlying question is why? I have created after the fact Functional Requirements Documents to satisfy a customer's SDLC (Software Development Life Cycle) audit trail requirements, but we had a pretty good understanding of what the software was intended to do before we began. What do you mean by "requirements challenged" and if you have working software why do want to generate something else?

This is off-topic and I invite you to move it to another page if you value it. If you're not concerned with a clear understanding of requirements, then the technique I propose will have no interest for you. I'm definitely not discussing post-deployment document production here. If you're not sure about the relationship between requirements and "working software", we could discuss that on a page of its own, but please not here. -- WaldenMathews