Requirements versus design – which is what, when and why?
A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. Thanks to Cauvin for calling it to our attention. We can’t let the other folks have all the fun, so we’ll chime in too.
We’ve described the software development process before as being like an onion – having multiple layers of abstraction within which you describe the problem and solution. In this post we will translate that perspective into “what is a requirement” and “what is design”.
The layers of abstraction
- Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.
- Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD.
- Solution design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers – good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
- Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.
The point of contention
The debate is over the classification of product requirements. In this post we’ll talk about the red team and the blue team, much like the foosball players in the image above. We’ll also use one of the examples presented in the forum as the anecdote for describing our perspective. I want to avoid putting words in other people’s mouths, so I will hilight my interpretations as being just that. And as interpretations, they may very well be wrong.
My interpretation is that the blue team believes that market requirements are the requirements, and any further specificity should be classified as design (also this). My interpretation is that the red team agrees with what we’ll write in the rest of this post.
A red team quote:
My philosophy on this is simple. If the business or the business users care about it, it is a requirement.
That being said, the business often times cares or wants things that they shouldn’t care about or want, so they do have to be careful not to demand things that truly arent requirements.
An unambiguous description of requirements and design
There is a middle ground between market requirements and design. There is a step in the software development process that happens between “defining the problem” and “designing the solution.”
When talking about market requirements, we describe the problems and opportunities that define the space. A great place to document our insight into the market is in a market requirements document, or MRD. In this hypothetical example, our mythical company is losing customers because they have to wait too long when they are on the phone to get support.
There is an ideation step, where we perform an analysis – as engineers, we would call this a root cause analysis, where we identify why the customers make software decisions based on support-call length, why the call lengths are long, etc. After we identify the root causes, we determine which ones are properly addressed with software, versus process, project, expectation setting or any other solution.
Our mythical company has decided that there will be a software component to the solution, and it will have the goal of reducing support call times.
The instant we decide that this problem is going to be solved with software, it becomes a software product requirement. And a great place to record that information is in a product requirements document, or PRD. We talk more about this in our post, From MRD to PRD – the key to defining a spec. And this is the source of our disagreement with the red team – we believe that these are both requirements, they are distinct, and they should coexist – and still both be labeled as requirements.
At Tyner Blain, we strongly support the use of structured requirements as a means of capturing, managing, and communicating our software product requirements. We start with the GOAL of reducing the average support call time. We define the use cases that capture the support-call process (or story, or scenario – if that’s your term du jour). We articulate the functional requirements (sales rep can find the customer records for the customer on the phone). And we define the design constraints, or non-functional requirements.
This is where we think we agree with the blue team as long as we add the following clarifications. Design constraints are requirements. When our client expresses the need to conform to a corporate look and feel – that’s a constraint. When we describe support for color-blind users – it’s also a constraint (although it is an ambiguous requirement without supporting material or cross-domain experts on the team). Any time we define performance characteristics (search must happen in five seconds), it is a constraint.
In all these cases, we require the software developers to design a solution within the bounds of our constraints. Constraints are requirements.
The implementation team will design (and later develop and test) a solution based upon the requirements. The requirements include constraints on how the implementors are allowed to design and implement.
Where we disagree with the red team
While generally agreeing with the red team (that requirements do exist between markets and designs), there is one statement where we do disagree.
Red team:
If I specify that the support rep must be able to search by last name, partial names, customer ids, address, phone number etc. Is that requirements or design?
Lets say you can agree that the above are requirements
[…]
Are all of those things design? I think it depends on the capabilities of your teams.
We disagree – we believe that these implementation details (by what fields a user should be able to search – and, in fact, specifying that search is the implementation approach) are not part of requirements – they are part of design.
I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past.
Defining details like this (what, exactly, does the software do) are design decisions. Irrespective of the capabilities of the teams, these are design steps. It may be, for a given team, that the product or requirements manager has to help a particular software designer to make good decisions. But that doesn’t make those suggestions into requirements – it just means that the RM is helping with design. And those details would belong in a design document. Yes it’s more convenient for a product manager to put those details into the PRD, but they don’t belong there.
Summary
In conclusion – there is a natural flow from market opportunities to product requirements to design decisions in the state of all value-driven software development projects. These three concepts are distinct. They should be documented distinctly. We suggest using an MRD, a PRD, and a design document. As a simple checklist, think of each idea in this way:
- Am I describing an opportunity and it’s relative value? MRD
- Am I defining a particular opportunity that we’ve agreed to solve with software? PRD
- Am I describing the implementation of the solution? Design Document
Please join in on the discussion – if not here, then at the forum or on Cauvin’s blog.
Scott, thanks for contributing your observations and ideas on this topic.
I think the “ideation” step you describe is critical. Would you characterize it as a form of scoping; i.e. deciding what “system(s)” (software, hardware, manual procedure, documentation) will achieve the business goals?
Taking your example goal of reducing average support call time to five minutes per call, we might choose to achieve this goal partially through support rep training and partially via software. In doing so, we essentially are designing, at a very high level, a solution to the problem. You can almost think of it as “business process architecture”.
Once we complete that design step, we now are faced with specifying the responsibilities of the systems. I think it’s fair to characterize this next step as a requirements activity (correct me if I’m wrong, but you would call such a specification a PRD).
However, specifying the requirements at the scope of the software system does not mean we should mention any user interface or process entities. In fact, we can simply further scope the original business requirement.
The original requirement:
“The average support call should take no longer than five minutes.”
becomes something like:
“Assuming all support call representatives have x amount of training, the average support call should take no longer than five minutes.”
Thus you can see we still do not yet need to “design” any interface or interaction with the software system, even after we decide software will be part of the solution.
Thanks Roger!
I generally agree with what you’re saying – especially the part about not specifying implementation details. I do, however, believe that the process of creating a PRD does involve some articulation of what the software is expected to accomplish. I’ve just written a separate response (with more diagrams) titled Software requirements – process and roles.
I believe there are synergies in the process that require some steps to be performed by the same person, and some to be performed by different people.
Thanks again for reading and especially for commenting on several of our posts!
Agree that known business constraints are requirements.
Depends on Product process in a product company versus new business application inside an a company working with IT.
Mock up screens normally come into play for the end user experience. In your article these would be design. But the reality is that humans normally have a picture in mind (expectations). And expectation mgmt is key to any product/project.
My guidance for function requirements within a company with IT: If the product/businss application has a road map – write down everyhting you are willing to pay for (whether it is ver 1, or ver 2, or ver3) – as design for ver 1.0 must not limit ver 2or3.
Items where you need an impact analysis (can not determine until we get more information from design pass ) are clearly handled in DESIGN.
The line does blur inside large companies when dealing with learge business units.
Another item – requirements gathering has a tendancy to go on forever. If the group is no skill at requirements (and most businss units are not) change tactices. Get them in a room for a week. And force a lock down deadline. The document can and will change – but as long as you have address or identifed all reasonable issues that could inmpact scope/timeline – you must force them to a “its right not perfect” point – and then handle all future changes via formal change control in the mgmt reviews.
This one is alsways tough in business unit customers. For a Product Mgr at a product company, the line somewhat easier to handle.
Thanks for reading and commenting, Bruce!
Your lockdown idea is a good one – I’ve used it in a “past life” when working on a large engagement. It is easiest to use when you are either part of the organization (especially if you have some juice), or as an outsider with a strong reputation and good relationships. I would caution folks to not try the lockdown approach when they are relatively unknown. If that’s the case – get a project sponsor within the organization to create the lockdown, and then just facilitate it for them. If the group is resistant, take some cues from the movie, Twelve Angry Men, and be the jury foreman. Create an association of “we all have the same goal” – not – “You must tell me”.
Getting to ‘right’ not ‘perfect’ is another great piece of advice.
Keep sharing your thoughts with us!
Great post.
I just came here from this blog.
http://thebusinessanalyst.blogspot.com/
Seems to be talking the same thing.
Requirements and design are two separate areas.
Cheers
Hey, thanks Jim, and welcome to Tyner Blain!
Looks like some interesting content – it’s in my feed reader now, looking forward to checking it out.
Scott
Hello Scott,
I was looking here to find some hints, and I found this article great. A lot of good resources also.
Yesterday I was asked about the differences between a requirement and a functionality.
My answer to that question was that a requirement is the “what capability does we need” and for the functionality was “How we implement that capability”. And also pointed that a Requirements is a output of a process called “Requirements Elicitation” whereas Functionality is an output of design and build.
Let me try to explain. A user want a system X that allow him to perform monitoring and controlling the energy consumption of some machine. Here “Monitor and control the energy…” is a requirement whereas the screens with a dashboard is a functionality to meet that requirement.
Are my assumption correct, or am I completely wrong?
Joao, thanks and welcome to Tyner Blain! [Sorry, I don’t know how to make the cool a with the ~]
You’ve got it exactly right with your general statements.
You may also have it right with “monitor and control energy”, but I can’t know without knowing the details. Why do you want to monitor and control the energy? What benefit do you get from that.
You could easily argue that the benefit (lower cost, longer operating life, better process control – whatever it is) is more of a requirement, and “monitor and control energy” is more of a design decision (how you design your process to meet the requirement). Better process control would also force a “why?” question – higher yields? products that look better (and can garner a higher price in the market)? faster production?
What does faster production get you? Higher return on assets? Reduced cost per unit? Take a look at Defining Problems with Cause and Effect Diagrams and see if that helps.
I look forward to hearing more from you – your explanation about the difference between requirements and design is spot-on.
Hello Scott,
Thanks for your answer. I will try to rephrase my question.
Getting the case:
The company C knowns that it paid $20 000 last year of waste, created by the machine M. They want to reduce that waste a minimum of 70%, or save $14 000/year, in a rough calculation, and keep the production ratio planned for that machine for the next 2 years.
The engineering team, starts on analysing the problem and find that the machine is working without producing an average of 1 hour per day, while the machine is being feed. They have gone to the root cause and found that the user has to feed the machine very often during the day, and decide to cut the number of times the user has to feed the machine. But that was not sufficient to meet the @cut 70% of waste@.
They, then, decided to build a system that is be connected to the machine and turn off the machine while not producing, by using sensors and other stuff.
So, in this case we have “cut 70% of waste”, “keep the production ratio planned”, will be the requirements.
And we also have “reduce number of times the machine is feed”, “turn off the machine while not producing” as design (process design?)
And we also have “system that turn off the machine by using sensors and other stuff” also as design (system design?)
Are those assumptions correct?
Yes Joao,
You’ve got it exactly right! Thanks again!
If you chose to fix your semantics based on the phase of the project or the role of the people doing work, it’s quite practical to say that people who build and implement actual things (solutions) do so based on designs, and that people who create the designs do so based on requirements. Solutions are based on Designs are based on Requirements (I’d add “Requirements are based on Needs” to the end of that, by the way).
When you step outside the project (IT or not) to look at how business analysis is used in other domains, it’s a bit harder. Is a business case a requirements document or a design document? If you’re working in portfolio management, deciding how to allocate people and funds, each business case is a design option. If you’re working in a project to fulfill a business case, it’s a set of requirements. If you’re actually developing a business case, you’ll see elements of both. It’s the same actual document, but your point of view gives it a different meaning.
I’ve been doing a lot of thinking about this topic in recent weeks, and wonder if we can resolve the conflict by acknowledging these points of view. What if:
– Requirements are statements that help stakeholders understand the value that could be gained if a need is fulfilled.
– Designs are statements that help stakeholders understand how to realize potential value through a solution.
These definitions are closely related, and I think they encompass the normal attributes of good requirements. For example, both Requirements and Designs have to be testable so value (potential or realized) can be measured.
These definitions can provide a practical way to address “the business often times cares or wants things that they shouldn’t care about or want” without spending a lot of time telling them “you don’t really want that” (in subtle and careful ways). Just ask if this particular thing describes potential value, or how to realize that value. Eventually you’ll need to have both – have need/solution pairs.
In the example you used in your post, a coder would use ‘fields a user should be able to search’ and ‘search as an implementation approach’ to understand potential value, and would then design a way to make that value real. A business person would use the same ‘fields to search’ statements to understand how value will be realized by the proposed solution.
If these ideas hold up, it means you are right to “…believe that these are both requirements, they are distinct, and they should coexist – and still both be labeled as requirements.” It also means that from a specified point of view, they are both designs, they are distinct, and they should coexist.
Hey Julian,
What a great comment, thanks! I delayed responding as I feel there’s a “post-length” response I could write, but I finally realize I won’t get to that for a while. So I’ll respond here now.
I particularly like your insight about “need/solution pairs” – it cuts right to the heart of the matter. I find that why/how pairs live at multiple levels throughout the decomposition from extremely high level (strategy) all the way down to implementation details.
I think they are even more intertwined than that – that it isn’t pairs of needs and solutions, but a chain of alternating needs and solutions.
As an example working top down:
I’ll continue in the next comment (so that I can reference the line-item numbers from the list above.
At the high levels (steps 1 through 5), the needs and solutions alternate as pairs, as you described. The people making those decisions – in my experience – would all agree on the difference between “why” and “how.”
At the lower levels (steps 6 through 9), the notions of “why” and “how” are a matter of perspective. Step 6 is clearly a “how” to the non-engineer executives who “need” a 20% cost reduction. Step 6 is clearly a “why” to the design engineer who is tasked with redesigning the product with a lower-cost bill of materials.
Step 6 could have been “Reduce COGS by 20% by automating production, reducing the labor-costs in the finished product by 80%.”
This would still be a viable “how” for the executives, but would result in a completely different set of why/how statements, leading to design of automated equipment, redesigning components not to be cheaper, but to be cheaper to assemble and test, etc.
You mentioned “IT or not” in your comment, so I thought I’d use a mechanical-engineering example (my pre-software background was electro-mechanical controls design).
At the lower levels (steps 6 to 9), identifying each level of decomposition is more of a matter of perspective of “who’s asking?” than an implicit descriptor of the step. See Requirements Documents – One Man’s Trash for a discussion on how that plays out (in an IT world).
I’ve spent a lot of my time recently in the higher-level stages. I wonder if those steps are really also simultaneous need / solution steps as well, academically. In practice, people tend to think of them as pairs as you describe.
There might be a way to make the distinctions: perhaps “this must be” versus “here’s one way to achieve it” is the litmus test for defining if something is “universally” considered to be a need vs. a solution – or if it is still just a matter of perspective. I don’t know. I also don’t know if making the distinction adds value at this level. I have to think about it some more.
Thanks so much, Julian, for triggering some re-thinking about this!
Hey Scott – glad to contribute! I’ve put up a post over at http://community.IIBA.org/BABOK3 looking at the transitions of states from need to requirement to design to solution. You might find it interesting. I have some other ideas related to this noodling around, but they’re not quite ready for prime time. More to come!
@Julian, you wrote (among other insightful comments):
“Requirements are statements that help stakeholders understand the value that could be gained if a need is fulfilled.”
The emphasis on value to stakeholders is key here. A requirement should be logically equivalent to a statement of value. In product management, we often equate value with solving a prospect problem. So I define “requirement” as the least stringent condition that must hold to solve or avoid a prospect problem.
If the product creates a condition under which the customer no longer has a problem, it has delivered value for the customer. And if that condition does nothing more than describe the state of affairs that must exist for the problem to be considered solved, then it is a requirement.
So the simple procedure for formulating a requirement is to describe in measurable terms what the problem is, and then logically invert the problem statement to yield the requirement.
I should add that the requirements formulation method I described above doesn’t render the issue of what constitutes a requirement trivial. It only moves it up a level.
Before, we asked, “Is this a requirement?” Now, we ask, “Is this a problem for the customer, are we going to choose to solve that problem with the product, and what are the measurable conditions that indicate its existence?”
These new questions are by no means trivial to answer, but they ensure we are focused on customer value and on determining how to measure whether the product has delivered that value.
I think you’ve keyed in on the essence of where I think about it now – I’m always doing the “five whys” to get to “Would the user benefit from solving this problem?” or “Would having a solution to this problem cause the buyer to be more likely to buy?” All of the steps in the middle are, in a way, implementation.
The problem is, if you’re the guy slinging the code, that’s pretty abstract, without the chain that shows you why (someone believes that) having the ability to share your photo with friends is important to do, and that it better take no more than 2 gestures to share with your best friend.
:)
Always a fun discussion, thanks for chiming in!
@Scott, I like the way you framed and highlighted this issue:
“The problem is, if you’re the guy slinging the code, that’s pretty abstract, without the chain that shows you why (someone believes that) having the ability to share your photo with friends is important to do, and that it better take no more than 2 gestures to share with your best friend.”
Some people presume that any definition of requirement should be such that a “code slinger” can code directly from a requirement. I think this assumption is naive. A lot of design work lies between requirements and code. This design work includes not only design of the system’s internal software entities (packages, classes, functions, database tables and columns), but also interaction design, user interface design, and graphic design.
The output of all or a subset of these design activities can serve as a specification for what the developer will code. Calling it a “requirements” specification is odd or misleading, though, because it’s the output of design work and is only “required” insofar as the designers have prescribed and defined a solution that the coder “must” implement.
Agreed!
The challenge is there are a few million business analysts, and a few hundred product managers and product owners out there, who are “very close to the code slingers” on a daily basis. Almost all of the ones I’ve worked with would describe many of the steps between “make money” and “share with a friend” as _requirements_.
I think I’m moving more and more towards “I don’t care what you call it, as long as you can tell me why you think you must do it.” Hopefully I don’t sound flippant about it – it’s a triage thing, and many of the other “how to make better products” problems feel both more important and more urgent to me.
Underlying the semantic debate is a much more practical issue. As I mentioned, the notion that a developer should be able to code directly from requirements neglects a huge body of design work. In most cases, it conflates the skills and talents needed to:
1. Elicit and state the problem.
2. Analyze and redesign the business processes during which the problems occur.
3. Design the user-product interactions that will solve the problem.
4. Design the user interface that will enable those interactions.
5. Compose the graphic art that will be a part of the user interface.
6. Conceive the software architecture of the system.
7. Conceive the detailed software design of the internal components of the system.
8. Design the database model.
So the insistence on real requirements that represent customer value (#1) is a wake-up call that says, “No! You are not going to conflate these talents and skills. You must recognize that they are distinct, and that the organization probably needs several different people to fill the roles effectively. Furthermore, the customer value must drive the process, because it’s the only thing that’s truly required.”
This is a thrilling conversation, in that it validates a year of discussion and exploration by the BABOK3 Core Team.
Now that you’re softened up, here’s a wrench. :)
… the notion that a developer should be able to code directly from requirements neglects a huge body of design work. (Roger L. Cauvin)
If you truly take the view that an appropriately structured and represented blob of information can be referred to as a requirement and a design based on the point of view of a stakeholder — since Rs and Ds are the same thing — and that IT Projects are not full domain of business analysis, then the quote above is equally
… the notion that a builder should be able to create directly from designs neglects a huge body of requirements work. (conversion of Roger L. Cauvin)
Substituting, we get
… the notion that a builder should be able to create directly from statements that help stakeholders understand the value that could be gained neglects a huge body of statements that help stakeholders understand how to realize potential value.
and
… the notion that a builder should be able to create directly from statements that help stakeholders understand how to realize potential value neglects a huge body of statements that help stakeholders understand the value that could be gained.
In other words, you can’t have one without the other.
So… If all this is true — how do you meaningfully differentiate between the BA and the Designer?
@Julian, you asked:
“If all this is true — how do you meaningfully differentiate between the BA and the Designer?”
There is not one “designer”. Or, more precisely, there is more than one design role. I listed many of them in a previous comment.
One role is for a person who analyzes and redesigns the business processes during which the customer experiences the problems. I view this role as a form of business analysis, although I am open to the argument that, literally speaking, BA is just the analysis part.
Note that “business process” here encompasses all forms of customer interactions and experiences, not just interactions with software systems. And a BA does not necessarily automate business processes or involve software systems in any way.
@Julian & @Roger, thanks for driving forward this most-excellent discussion!
Since Julian broke out a wrench, I’ll break out a spanner, in a little post Independence Day nod to the folks across the pond.
I wonder if we can re-wrap everything up as requirements, design, and implementation. By simple analogy – the requirement is “feel safe at home” (hooray Maslov!).
One of several design steps is “form a good relationship with your neighbors.” I think the litmus test of “is it design?” would be are there alternative approaches? One alternative is “install a very effective security system.” This is analogous to Roger’s point about designing the business processes, but one step up – designing the business such that some processes will exist (or be more relevant than others). Essentially, allocating responsibility for meeting the requirement to a particular approach.
Within that “selected approach” is the process design. In this analogy, it could be “host a successful dinner party” as a means by which you form the good relationship. An alternative would be “bake them a cake.” My litmus test says this too is a design.
One of the things that is required (ahem) for a successful dinner party is to provide seating. In theory, but not in practice, seating is optional. You can have a “successful dinner party” with everyone standing around or sitting on the ground. If you treat “dinner party” as the root of the requirements, then you are at risk of that happening. If you are cognizant of the reason for the dinner party (good relationship – leading to safe at home), then you might constrain the design options to exclude all approaches that would undermine either of those – including anything that makes you look like a weirdo, or elicits avarice (like sitting on piles of money).
Again you have choice – and therefore it is design – you can have people on benches or chairs. You can introduce design concepts like “make your guests feel at home in your home” or “make your guests feel like you need help from them.” This is my analog of most of the tactical interface design work (interaction, visual, usability, etc). Your designer cannot design the chair effectively without knowing that you want your guest to feel at home – and would benefit from knowing why you want them to feel that way. The designer might design a chair that makes them an inch shorter than you (so that they feel inferior) without understanding the traceability back to “feel safe at home.”
A lot more design choices (analog of software & database design) now – selection of materials, dimensions, surface finish, and what a layman would call “the design” of the chair (ladder-back, straight-back, Quaker, office-generic, etc.). This ends up becoming a work-order for someone to go build.
The builder then chooses how to make the chair – choices like “fabricate and :assemble components” and “carve from a solid block of aluminum.” Also procedural stuff like roughing in the dimensions, then testing for materials-quality, then finishing – or electing some other sequence. The builder is not making choices about what to do – it must be a chair that meets specification, but is making choices about “how to deliver a chair.” So, there is more “design” work here – and that’s the problem.
From the chair-builder’s point of view, the chair-specifications are the “why”, the fabrication choices are the “how” and the chair is the “what.”
From the dinner-planner’s point of view, the goal of a successful dinner is the “why”, the election to have seating is the “how”, and the specification of a chair is the “what.”
From the home-owner’s point of view, the goal of feeling safe at home is the “why”, the strategy of forming good relationships with neighbors is the “how”, and the tactic of having them over for dinner is the “what.”
Based on my story above, my conclusion is that you cannot assign a single label to any of the steps of decomposition (except the endpoints) and have it be a semantically meaningful label for all the people in the process.
You shouldn’t feel too confident in labels for the endpoints either:
The chair-builder may outsource some of the assembly work – eventually, you have a mining company delivering aluminum ore to a smelter who delivers aluminum to a tubing manufacturer, who delivers it to someone who swages and forms it to the right geometry for the legs of the chair.
The home-owner may realize that feeling safe is part of achieving enlightenment, and discard the home-ownership thing entirely to go live in a remote tent and eat roots and berries in the wilderness.
To answer my opening question – no, we can’t wrap it up with universally acceptable terms. The context of the person doing the labeling matters.
@Scott, the argument you’ve made rests on a premise that the availability of a “choice” is the litmus test for whether a decision is design. In reductio ad absurdum fashion, you show that you can keep going down the chain and still view the upstream decision as a requirement, or you can keep going up the chain and still view the downstream decision as design.
I’ve explored both of these paths (the downstream and the upstream) before.
As a matter of fact, I’ve written about When to Stop Asking Why and, in connection with it, even mentioned Maslow in a comment on Tyner Blain.
I’m having trouble digging up the link, but I’ve also pointed out that, if you assume a “requirement” is a merely a specification that a downstream consumer takes as the “given” – with no choice from her perspective – then a coder must consider class and collaboration diagrams composed by a designer to be requirements.
We certainly can, as you seem to have done, adopt a definition of “choice” that is relative and dependent on the perspective of the consumer of the specification. But there is another way.
We can instead stipulate who is the producer and who is the consumer in the context of discussions of product requirements. The producer is the person who has chosen the prospect problems to solve and is specifying the criteria under which they are present. From the perspective of all downstream consumers, this specification represents the requirements.
When we use such terms as “interaction designer”, “UI designer”, “software architect”, and “object-oriented design”, we are unconsciously placing this same stake in the ground. In product development, we are trying to solve prospect problems, often for profit. We need everyone in the product development process to view prospect problems as the driving factor for their efforts, and therefore as “required”. And we need to unleash their creative and innovative talents by emphasizing the choices they have in solving those problems.
In short, it’s useful to choose this “absolute” definition of “requirement”, and it’s about as consistent as any definition can be with established usage in the context of product development.
Fantastic comment, @Roger! Also – thanks for reminding me of the phrase “reductio ad absurdum”, and for calling me out on it :).
I particularly like your statement – “We can instead stipulate who is the producer and who is the consumer in the context of discussions of product requirements. The producer is the person who has chosen the prospect problems to solve and is specifying the criteria under which they are present. From the perspective of all downstream consumers, this specification represents the requirements.” – and I completely agree.
My point is that in organizations where delegation takes place, if you don’t treat producing and consuming as relative roles in context, you end up with abstractions that are so far removed as to be ineffectual in practice. The CEO should not care if the code is implemented using a factory-of-factories design pattern for future efficiencies and elegance, when worrying about CAGR EBITDA. The coder should not be spending the (massively high) proportion of her time required to discover and appreciate that the reason she should make this decision for the user and allow that decision to be configured by the user, is to displace competitor X in market segment Y over the next two years. The decomposition of the problem (when looking up from the bottom of the hierarchy) / engendering of empowerment (when looking down from the top of the hierarchy) is necessary when large groups solve large problems. In practice, in my opinion, that means that different people will benefit from using different terms to communicate about the same things. The deeper the “stack” of responsibilities, the less useful (on a day-to-day basis) it is to only assign “requirement” as a label for the absolute endpoint – it is accurate when talking about the “thing”, but loses utility in practice for affecting behavior.
Before someone misinterprets my statement above – I believe everyone on the team absolutely benefits from understanding the decomposition of rationale, the “five why’s.” I believe an effective way to prevent the chaos of everyone trying to invest all of their time second-guessing all of the decisions is to treat each of them as both requirements and designs, in practice as an articulation of delegation of responsibility. This language can be used to clarify from a perspective of responsibility which decisions are within any particular person’s purview. I don’t remember if it was @bakevin or @sci_ba who pointed me to http://dschool.stanford.edu/wp-content/themes/dschool/method-cards/why-how-laddering.pdf but I like that as an abstract decomposition model. I’ve also been trying to figure out how to adapt @jurgenappelo ‘s awesome delegation game from a single manager-team dichotomy to a hierarchical model.
When I first wrote this article in 2006, my “labels matter” point of view was primarily a “don’t micromanage your implementation team” response. Too many BRDs, SRSs, MRDs, etc were telling the development teams how to do their jobs, not why to do their jobs. My personal pendulum swung the other way, because putting effort into naming stuff instead of doing stuff seemed pedantic and distracting, and I moved into the “labels don’t matter” camp, and comfortably sat there for a few years. With the BABoK update process, I’ve started thinking about it again, and my current opinion is still both of those points of view, but I’ve added the nuance of driving organizational (and individual) behavior – and that this is hurt by having the “wrong” labels. So, it may shift again, but that’s where I’m at right now.
@Scott, @Roger, @David – Great thoughts here. A touchstone we can use to anchor our abstractions is based in the question @Scott mentions – do we have what we need to do stuff? In most cases, ‘what we need’ includes enough agreement on terms and descriptions to allow a team to coordinate their work, so some rationale for choosing a useful name ,em>for this group of people in this situation is a discussion relevant to the underlying structure of the profession.
On the topic of getting too abstract, the BABOK 3 Core Team has used two tests: “Will this help a Business Analyst better perform BA tasks?” and “Will this help a Business Analyst better interact with stakeholders?” I’ve been responsible for revisions to the structure of BA Planning and Monitoring (BAPM). In the course of our team reviews we realized that plans are, at an abstract level, a kind of requirement/design: usable representations of needs and/or solutions (where the controlled organizational change is a kind of solution). We could have recast BAPM as a kind of Requirements Analysis and Design Analysis activity – but this would NOT pass the useful/usable tests above.
In a similar sense, these “performance over perfection” questions can be used with any team involved in a controlled organizational change. When you’re defining the handoffs between change agents, figure out what needs doing, and what information needs to be shared, and in what form. The name of these packages is important, but it’s just a handle.
@Roger, one more thing. In practice, when setting the standards for a BA practice a few years back, I explicitly chose an absolute context and point of view for the terms ‘requirement’ and ‘design’. In that organization, we defined requirements as anything coming ‘down from above’ in the project life cycle, and designs as all the stuff that came out of the project (until implementation). Somewhere inside the project requirements and designs met.
We did this for lots of reasons, but recognized (and talked a lot about) the consequences. For example, we tried to control for this choice promoting an organizational blind spot to BA involvement during the whole development life cycle. We were constantly fighting to keep BAs involved after some arbitrary cut-off point, when ‘we’re doing design and don’t need BAs because they do requirements.’
At the time, we were more concerned with the upstream BA practices that preceded project initiation (e.g. getting good business objectives, having meaningful business cases, etc.). We had a career ladder that took the BA role all the way up to the highest grade in the organization (after that you’re in executive territory), but many senior people didn’t really think of themselves as performing BA tasks. Our absoute R/D choice helped bring awareness and change to those roles; for example, having agreement that this BA work happened during e.g. portfolio management was a big deal.
If I’d stayed in that role, I would eventually have worked on the downstream practices, too.
Julian, at a personal level I’m not sure that “differentiating between the BA and the Designer” is a meaningful problem, at least at the level you’re thinking about it. Where business analysis stops depends on the kind of problem you’re trying to solve, and whether the kinds of skills that BAs have are useful for those problems. I think I’ve come to much the same place as Scott on this one…the meaningful difference between requirements and design is that you have choices about design. For each person, then, the line is different.
The traditional IT BA use of these terms pretty much adopts the developer’s perspective. Requirements are the things that the development team must deliver and design is what they have the freedom to decide (and “constraints”, as far as I can tell, usually mean “normally this would be a development decision but this time it isn’t”).
Scott, I agree that the question I asked isn’t really valid; it’s more like a riddle, where you have to think laterally.
Q: “How do you meaningfully differentiate between the BA and the Designer?”
A: “You don’t.”
Instead, as a BA, you ask, “Have I provided you with the information you need to do what you need to do?” If the answer is “No” you start figuring out what the next actions are, and what information the next person needs to act.
We have a related linguistic challenge. Design is a severely overloaded term.
– Designs are designed by designers, but
– Requirements are defined by business analysts.
If we overloaded ‘requirement’ the same way, we’d have
– Requirements are requiremented by requirementers.
:)
Ah, Pandora, you’ve opened the box.
Q: “Is X a requirement, or a design?”
A” “Yes.”
It’s a trick question. Depends on who you’re asking.
IMO, both terms are overloaded to the point that making the distinction (with a label) is as useful as rearranging deck chairs on the Titanic. What matters is that for whatever level of the problem you’re solving, you understand why you’re solving it, and if your solution involves someone else solving a smaller part, they understand it too. Basically, a recursive structure.
I think you guys have fallen victim to the relativism trap :-)
If we analyze the term “consumer packaged good” in the context of economics long enough, we might end up punting and saying, “The distinction between producer and consumer is as useful as rearranging deck chairs on the Titanic.”
After all, a package of computer parts that Dell assembles into a computer is “packaged”, and Dell is the “consumer” of those parts.
But it remains quite useful and meaningful to apply the “consumer” label in the term “consumer packaged good”, because there is an implied and fixed perspective.
The distinction between analysis and design cannot be that there was a choice – even agreeing that something is a requirement is a choice. Indeed every step from the initial spark that something is wrong or needs to change, through to flicking the switch on a new policy, process, or system, is a choice. These are the semantic steps between the ‘why’, the ‘what’, and the ‘how’. At each step, we can argue that we are choosing how to implement the higher level – stakeholder requirements choose how to realise business requirements, taking them one-step closer to implementation.
Analysts help design the solution whenever they talk about the ‘to-be’ rather than the ‘as-is’, designers help understand the need whenever they ask ‘why’ somethinpoint needed.
We know empirically, that the organisation frequently doesn’t get what their saying they need until they can see something. So, often, wireframes or paper prototypes are useful, and while these are design deliverables, they help us to understand the need.
It doesn’t matter which colour shirt we’re wearing, the important thing is to ensure that the product owner is with us every step of the way. Too often I’ve consulted at sites where ‘to design’ means to make choices in absence of the product owner, so they end up not understanding why what is delivered is not what they wanted. If there’s a choice to be made, even if it’s about with which data to search or the length of a name field, that’s a business choice not an analysis or design choice.
Thanks for the comment, David, and welcome to Tyner Blain!
I stand by my dinner party story, as far as labels go.
As to the choice of “length of a name field”, my hope is that the choice is made by someone who makes an informed decision. In my experience, that’s more likely to be an interface designer than a database designer, business analyst, or business stakeholder.
David, certainly it’s true that people have made choices about requirements. What I’m saying (and I think is what Scott is also saying) is that when we call something a requirement, we’re saying that the decision has already been made. My design can be someone else’s requirements. A sponsor defines performance goals for a process. Those then become requirements for the business analyst, who designs a process to achieve those goals. That process design can then become requirements for the developers who implement a system to support it.
Thanks Kevin, and yes, I think we’re on the same page.
You’ve introduced a temporal nuance that is worth reiterating – until the decision is made, it is design (e.g. what performance goals do I really need to meet my objectives, and are they feasible?). Once the decision is made (e.g. 100 concurrent users with 100ms response times) it becomes the business analyst’s requirement.
However, to get the business agility benefits from adopting the principles of agile development across the organization, we have to embrace the opportunity to change those decisions on the fly. Perhaps a competitor goes out of business and starts directing their traffic to us – causing the sponsor to rethink the performance goals, now requiring concurrent support for 1000 users. Since the decision is mutable, it is still design (for the sponsor) and a “requirements change” for the BA, who then designs a new procedure (or even a new process) that enables the implementation team to create something that now meets the new expectations.
When I think about truly great people, they will not only communicate current needs, but provide whatever information is available to bound the space of possible future change. And when they design solutions, they take that information into account – not necessarily creating a solution that would support them, but making the decisions explicitly with that knowledge in hand.
Great description, David!