The life of a business analyst appears to revolve around requirements. Every working day we go about eliciting, analysing, prioritizing and communicating requirements.
So it might come as a bit of a shock to discover something:
There’s no such thing as a requirement.
At least, not in my view. Let me explain why.
Contexts and Ideas
Business analysts work on projects to deliver business change. Often, but not always, these projects involve changes to IT systems, but in the general case we are delivering business change.
All business change occurs within a context. This is what we call the “as-is”. The business is currently operating in a certain way. BABOK refers to this as the domain in which the change is to occur.
Then, somebody who is exposed to that context has an idea. The idea they have is an idea about how the business could be improved. They have observed something about the context (the “as-is”) and they have imagined a future in which the business operates differently – hopefully better (the “to-be”).
Sometimes the idea is labelled as an opportunity. Sometimes, the context is labelled as a problem and the idea is labelled as a solution to that problem. But these are merely labels. In the general case, what we have is an idea for business change – to move from the “as-is” to the “to-be”.
Sometimes, there is initially no clear view on what the “to-be” would actually be. This occurs when the context contains something that is perceived as a problem, but as yet we don’t have an idea as to what the solution might be. So there is a desire to move away from the “as-is” to a better, as-yet undefined, place. Note that labelling the context as a problem is just that – a label; a subjective view; a perception. A (perceived) problem does not necessarily need to be solved.
Cost and Value
The purpose of business change is to make the business better in some way. In other words, the change adds value, or delivers a benefit. Value is sometimes subjective, but let’s ignore that for now. Let’s imagine that value is objective enough that I can put a dollar figure on it.
Business change also has a cost. The cost includes the cost of making changes to an IT system, maintaining that system, altering defined business processes, re-training, hiring, firing and so on. The cost also includes any downsides to the idea. Sometimes, making an improvement to one aspect of the business has an adverse impact elsewhere.
Not all Ideas are Good
Business people (and business analysts) have ideas all the time. They are not all good ideas. For an idea to be a good one, the value it delivers has to outweigh the cost. In other words, the business case needs to stack up.
Most bad ideas are rejected before they even get to the point of cost/benefit analysis. They get discussed informally at the water cooler and it’s soon realised that it just wouldn’t work, or it would cost too much, or that the downside is too great.
Some ideas are on the cusp. Or more likely, the value is over-estimated and/or the costs are under-estimated, so the business case appears to stack up when the project starts. In this case, a project to deliver a bad idea might actually go ahead. We’ve all seen this – it’s called a doomed project.
It’s very important to note that nobody can be absolutely sure whether an idea for business change is a good one until it has been fully implemented and the total costs and benefits have been measured.
There Are Always Options
When someone has an idea to change the business, they are usually focussed on delivering a specific outcome. An outcome is not a solution. An outcome delivers specific benefits and has an associated value. In general, a given outcome can be achieved in many different ways (there is always more than one way to skin a cat).
Sometimes, the options are considered. If a well-trained business analyst is involved early enough in the process, they can perform enterprise business analysis (as per BABOK v2, Chapter 5). Sometimes, however, the idea is for a specific solution approach, and other options to deliver the same outcome (possibly at a lower cost) are not considered.
And there is always the option to not proceed. This is an especially good option if the idea is a bad idea, because it avoids launching a doomed project.
There are always options, and all business change is optional. Sometimes, the consequence of no change is total business collapse or, in the case of illegality, imprisonment of directors. But these are edge cases. In general, all business change is optional.
Once a project has been launched to implement the (good or bad) idea, the idea starts being referred to as a business need. This is an interesting term to use for an idea that is (a) possibly a bad idea, (b) possibly not the best way to achieve a specific outcome and (c) almost certainly optional.
Remember, even if a well-trained business analyst has been involved from the outset, and all options have been considered, and a well-reasoned business case has been produced, it might still be a bad idea – we don’t know for sure until the business change has actually been implemented and the costs and benefits have been measured.
In my view, there’s no such thing as a business need. There are ideas for business change, but they are not needed, they are optional.
As soon as we label an idea as a business need, it effectively becomes set in concrete. We cannot challenge it. We cannot point out that there might be better alternatives, or that it might be better not to implement the idea at all.
At the start of a project we probably don’t want to challenge the business need. But as we go through the process of elicitation and analysis, and we discover that actually it’s a whole load more complicated than we thought, or that actually the benefit might be smaller than expected, we are unable to challenge the need, because, apparently, it’s needed.
So, on to requirements. According to BABOK v2, a requirement is
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
First of all, as previously discussed, calling something a problem is just giving it a label. So we are left with a requirement being
A condition or capability needed by a stakeholder to achieve an objective.
Notice that this definition of a requirement is implicitly conditional. If the objective is to be achieved then I need a certain condition or a capability. That’s good news – it sort of recognises that the objective is optional.
But according to the above definition, the requirement itself is, apparently, needed. It must be delivered. I don’t agree with this because, again, there are usually options. For a given objective, there are usually many ways to achieve it, if you think hard enough. And, as mentioned above, there is always the option not to achieve the objective, which is a good option if the cost of the requirement turns out to be greater than the benefit.
Specific conditions and capabilities are never needed. There are always options. Hence:
There’s no such thing as a requirement.
The things we call requirements are actually all just aspects of the proposed business change. I prefer to label them as aspects of the design of the business change, because I believe that the process of generating options and selecting a preferred option is a process of design. Labeling these things as requirements discourages the considering of alternatives.
Requirements are Designs
At this point, many business analysts will shout: “Ah, you’ve misunderstood. Requirements and designs are not the same. Requirements state what the stakeholder wants. Designs state how that will be delivered.” This is the classic requirements-versus-design debate, or the what-versus-how debate (see the references below for examples of the debate taking place). In my view, it’s a red herring. The terms “requirement” and “design” are both labels for aspects of a proposed business change. Which one you use depends on your viewpoint – one man’s how is another man’s what.
Some business analysts point out that the difference between requirements and design is that business analysts do requirements and designers do design. This implies that business analysts don’t, or shouldn’t, consider options and make recommendations. And I have met many business analysts who work this way. In my view this is badly wrong. Business analysts should work with stakeholders and technical people to consider options and select a preferred approach. One of the problems with BABOK v2 is that it doesn’t make this clear.
I prefer to avoid the debate entirely by labeling everything as a design. So for example, I refer to:
- Business process design – a representation of the “to-be” business process
- System functional design – a representation of the “to-be” IT system, as it is visible to its users
- System technical design – a representation of the “to-be” IT system, the internal bits that the users don’t care about (somebody else’s job, not mine)
When I label these things as designs, I am sending out a clear message: we have chosen to do it this way. None of it is needed, it’s a conscious decision – the result of considering the options and selecting the preferred approach – every step of the way.
To put it another way, it’s all design.
More importantly, business analysts are designers. We need to work collaboratively with business stakeholders and technical teams to consider all the possible options and deliver business change that gives the most value for the least cost.
Acknowledgements and References
I’ve had a number of discussions on this topic with various business analysts. The debates have been both stimulating and thought-provoking. It’s a contentious topic and not everybody agrees. Sometimes people agree but appear to disagree because of differences in terminology. Anyway, here’s a list of some of the people and articles that have influenced my thinking:
- Julian Sammy and his articles Some Thoughts on Requirements States and Needs and Solutions, Requirements and Designs
- Adriana Beal and her articles Requirement is what we have to do to achieve an objective and Requirements vs Design
- Scott Selhorst and his article Requirements vs Design – Which is Which and Why?
- Steve Blais and his article Stop Gathering Requirements
- The BABOK Guide (version 2)
- Everyone who commented on my previous article on this topic, Requirements Versus Design: It’s All Design
Great article. The distinction between requirements and design definitely has merit. But like any good idea, when it is repeated over and over it runs the risk of becoming a cliche. Nice job of scrambling up the categories and making this topic fresh.
This is thoughtful work – but it appears to be based on a some weak or incorrect premises. In particular, this argument seems to be based on a narrow, absolutist definition of requirement, and an overly broad definition of ‘optional’.
This is certainly not my experience with business needs. Certainly, the needs may be real, and my be well defined, and may even be concrete. That does not mean that these needs can not be discussed, compared to alternatives, or reconsidered. It is also not the case that all requirements are always met, or that all requirements are of equal priority. Even taking the strongest definitions in the dictionary (that which is necessary; an order, command, injunction, directive, demand, claim) there is no guarantee that the requirement will be met. Humans all require food to live, and we know how well that one is going.
Bottom line: Some things are necessary for other things to happen; these are also called dependencies. There are many ways to violate a dependency. This can be damaging (‘ran out of air in SCUBA tank while 100m down’) or helpful (‘funding cancelled for a project that did not align to organizational vision’).
This idea sounds great, but it does not withstand scrutiny. The people who have the power and authority to make a GO/NO GO decision – the ones who have the option to not proceed – are often motivated by factors that are independent of the change itself. The BA on a project – or a PM or even a Sponsor – may not have the option to not proceed. Those people may be able to remove themselves from the change at great personal cost (by quitting their jobs, for example) – but that may not stop the change, either.
You are correct to observe that some people do this. It is also true that the vast majority of people do not. Most of the time, most humans have less choice than we feel we have. This is hard to accept, but it is the case: you can’t decide not to have a broken leg, you can’t decide to not be clinically depressed, and you can’t decide to make a GO / NO GO decision if you’re not the one with the power.
Bottom Line: The people responsible for executing a change may have no option about whether to proceed or not.
Only just seen this debate (and that in Tony’s previous post). Julian: I think you are effectively right but you don’t invalidate Tony’s argument, just clarify one aspect of it. Let me explain….
By acknowledging that requirements (business needs) aren’t non-negotiable and aren’t of equal priority, you are in one way just confirming that they are just as much elements of the design as anything else (and so actually confirming Tony’s position).
*However*, it is true that the people angle (here and in your replies to the previous post) is important and reflects the ‘on-the-ground realities’ that one might want to label as requirements. But what they are really to do with is the *context of (external constraints on) the design* and thus still naturally fit into the ‘all-design’ perspective. So I agree in the sense that designs should *always* have such a context made explicit (often called design decisions, design constraints, etc.). In my experience (mainly as a software architect rather than BA), this is the thing most often missing from documentation: even if a separate requirements document exists, it normally doesn’t give you any context (effectively why the requirements are like this beyond what they would be if working from a blank slate; this context is often entirely un-obvious even 6 months later as politics, enterprise architecture and personnel change).
Such constraints can come from ‘lower layers’, such as having to use some software package.
As constraints, they are naturally more ‘touchy-feely’ and related to business politics and individuals, as you say. Without thinking about it further, I suspect that thinking in this way also ties in how there are chains of whats and hows, with one man’s how another man’s what.
Does this work? I think I may have boiled things down to an overly simplified “It’s all design *and design constraints*’ (or ‘There are no requirements, only design constraints.’)
Thanks for your comments Julian.
With this article I am looking to change behaviours on IT projects. I believe the language of needs and requirements drives behaviours which discourage challenging “requirements” and looking at options. Even if BAs understand the subtleties involved in the process, other players – project managers in particular – do not. For me, the language of design makes it clearer.
In terms of choosing not to proceed, I agree it’s uncommon for the BA to force an entire project to be cancelled. But the option not to proceed exists at a smaller level – every “requirement” that is proposed by a stakeholder can be challenged on the basis of cost versus value and rejected if it doesn’t stack up. It’s all too easy to hear a “requirement” and write it down as a “must have” without really thinking about it. I’ve done it myself! If we can adopt a designer mindset, we are constantly thinking about options, and those around us are aware of that process too.
I agree with your general premise. Back in the 80’s, I was responsible for creating the cobol programs for receiving, interpretting and loading customer and account data from purchased banks being brought into our bank’s IMS databases. Our requirements were to convert all of their customers to look like our customers and add information that flagged them as originating at the bank we purchased.
Our requirments were not the design and I can prove it with one piece of information about how we did the work: If the number of customers at the bank was below a certain threshhold (I believe it was around 10,000), we just hired a bunch of data entry people to load them manually. Sure, there were data entry errors and other issues, but it was deemed the most cost effective “design” for smaller conversions.
The business requirement is not a design. It is a desired outcome.
1) Pretty sure I commented on the previous article, arguing against, probably using a variation on “A rose by any other name is still a rose.”
2) And Julian S. has captured the argument here very well, not really anything to add, “As soon as we label an idea as a business need, it effectively becomes set in concrete. ” jumps out as me as well.
3) In the end, use of a common terminology is to aid communication. Like it or not, “requirement” is out there in wide use, without commonly causing problems, so edging it out with another term, ‘design’ that is also well used already, does not seem useful. … Hey, if it takes off, I will follow along, but I would not bet anything on it.
Nice discussion. Tony, your perspective is very inspiring. However, I must agree with David. The reason more is that BABOK points out to Determine Solution Approach (p88, v2), as a specific task of a BA. Therefore, using your perspective, a BA might be called Determiner (not Designer). Furthermore, if we don’t have something called a Business Need, then we don’t know against what to evaluate possible solutions (solution options).
Hi Mirce. Thanks for commenting.
You are right that BABOK v2 includes activities to define solution options. But they are confined to the section in Enterprise Business Analysis, and the way it’s written implies it’s a once-only task to be done at the start of a project. Whereas in my experience, solution options crop all the way through the process – in my view it’s an inherent part of what we call “requirements elicitation” and “requirements analysis”.
In the absence of a business need, solution options can be evaluated based on cost and benefit – select the option which gives the most benefit for the least cost. It’s not always as simple as this of course – options occur right across a solution, large and small, and it’s not always easy to ascribe value directly to one small part of a solution.
Hi all, Great thread. I certainly see the merits of Julian’s (and others’) argument, but I really think Tony is on to something here.
It’s been my experience that on some projects the requirements take on a sanctified status where they are not questioned. Like Tony said, in these situations it tends to feel like the requirements are “set in concrete”.
Obviously, everyone in this thread agrees that requirements need to – in Julian’s words – “be discussed, compared to alternatives, or reconsidered”. I’ve just found in practice there are times when the project team becomes reluctant to clarify requirements once they have been “set”. This actually reminded me of a lecture I watched recently by Martin Fowler (of agile and NoSQL fame, among other accomplishments). In the course of the talk, he presented a very interested use case where the process of system design informs and clarifies the requirements themselves. See 36:16-40:06 in the video:
I can think of situations where a project team would be reluctant to “re-open” a requirements conversation even when the design really begs it (like in Fowler’s example).
For me, applying the term “design” to requirements seems to promote a kind of dynamic, conversational process, rather than a stiff and contractual one. At the same time, we are dealing in a subjective space (language) and I certainly can see how there are other word choices that would get us to the same place.
Good thread, all!
A requirement according to V3 of the BABOK (still in review) is “a usable representation of a need”. Design is “a usable representation of a solution”. The BABOK still differentiates, but the differentiation may be very subtle and certainly subject to interpretation as are all things in the business analysis world.
I agree in general with the concept and find the article well written and logical.
I immediately consider the resistance. There is a reason why the “what” and ‘how’ have been separated over the years, and I don’t think it was to accommodate the different positions. If everything is design, can we still, as humans, successfully differentiate between the different designs. Unless you do not feel it is necessary to determine what we have to do before we determine how we do it.
One of the discussions when including more ‘design” in our definitions of business analysis work is the line of demarcation between the business analyst and the systems analyst or architect (just including the word brings the controversy). There will be a major resistance from the technical analysts who will claim infringement. There has been over the years continuing border disputes between the business analyst and system analyst. Part of this dispute stems from the number of business analysts who have gravitated from the more technical analysis arena. The mere suggestion that business analysts are now going to be doing design (not requirements) will likely drive many technical analysts and developers into a feeding frenzy.
Perhaps a better approach would be to change everything to ”design’ and then change the names of the roles to “business idea analysts” and “technical solution analysts”.
Your comment touches on what I believe to be a fundamental problem with the roles & responsibilities of business analysts, systems analysts and architects as they are currently defined. People talk about requirements being the “what” and designs being the “how”, but as has been widely discussed, in general there is a cascading set of whats and hows of increasing levels of detail. The consequence (in my experience) is that nobody is really clear where the business analyst’s responsibility ends and the architect’s responsibilities start. There’s this woolly line between “requirements” and “design”, constant disagreements over whether a given requirement is “solution free” and, as you indicate, constant battles over whose job it is to “do the design”.
For me, the only way to make a clear demarcation is to say that the BA is responsible for everything that is *user visible* (I call this the functional design) and that the architect is responsible for everything beyond that (I call this technical design).
And I think you are right that we need some new role names – but if I tell you mine now it will spoil my next article
first, I go away for a few days and I miss 30 comments!
” but as has been widely discussed, in general there is a cascading set of whats and hows of increasing levels of detail.”
Widely? Where? I missed that discussion somehow, other than the one previous article mentioned originally.
IIBA V2 Definition is based on IEEE definitions of which are redefined now. Perhaps this article should be updated with latest definitions.
The latest IEEE definitions for system and software requirements are
contained in the new ISO/IEC/IEEE 29148:2011, Requirements engineering,
which replaces IEEE 830 and 1233.
Requirement: statement which translates or expresses a need and its
associated constraints and conditions NOTE Requirements exist at different
tiers and express the need in high-level form (e.g. software component
Software requirements specification: structured collection of the
requirements (functions, performance, design constraints, and attributes)
of the software and its external interfaces.
NOTE Adapted from IEEE Std 1012:2004.
System requirements specification: structured collection of the
requirements (functions, performance, design constraints, and attributes)
of the system and its operational environments and external interfaces NOTE
Adapted from IEEE Std 1233:1998 and IEEE Std 1012:2004.
Further, “Defining requirements begins with stakeholder intentions
(referred to as needs, goals, or objectives), that evolve into a more
formal statement before arriving as valid stakeholder requirements. Initial
stakeholder intentions do not serve as stakeholder requirements, since they
often lack definition, analysis and possibly consistency and feasibility.”
Paul R. Croll
Chair, IEEE Software and Systems Engineering Standards Committee
Hi Putcha, thanks for commenting.
I’m not sure the specific wording of the definition of “requirement” makes that much difference to my argument. I do like the term “stakeholder intention” – that’s much better for me than “stakeholder need” – it’s about what the stakeholder intends to do as opposed to what he needs to do.
But even then I think I prefer to talk in terms of proposed changes, benefits and costs.
Hi, Tony, everyone,
I’ve just written a post commenting on Tony’s view (too long to capture here, summary below, you can find the full text clicking on my name). Here’s a shorter version:
1) I think there is a very good reason to resist doing away with the word “requirement” (and to me it has nothing to do with IIBA, even because there are lots of things I disagree with in the current version of the BABOK, and probably will continue disagreeing when the next version comes :-).
2) I agree with Tony when he says “it’s all design”.
3) Some designs (process, functional, and in many cases technical, for example when you are required by law to use a certain type of cryptography in data transmission) ARE requirements = something the solution must deliver to pass acceptance tests and be considered “fit-for-purpose”.
4) If the term “requirements” is not used, I’d still need another term to differentiate “design that is a choice” from “design that is a must-have to declare the project successful”. Call it contract clause, must-have design, whatever, it still need to be spelled out. In my projects we spell them out in the “software requirements specification” (which is not called “software specification” because it does not include all specifications, it excludes any design decisions that are NOT required for the solution to be deemed acceptable).
5) The convention became to name the phases “requirements” and “design” to differentiate between the investigation of what MUST be delivered vs. the work done to detail how the requirements are going to be met, described in terms of specifications of the user interaction, technical infrastructure, system components, integrations needed, etc.. The design phase aims to both to fulfill the requirements and to ensure the solution is produced using the best cost-benefit alternatives. I agree that because “design” permeates every single phase of a project, including testing and deployment, it may not have been the best decision to use “design” as the name of a phase or group of activities in a project. (That doesn’t mean the word requirements need to go away though).
6) I disagree that calling something a “requirement” prevents discussion from happening and make it “set in concrete”. First of all, if it was made into a requirement with the involvement of a solid BA, it should a crucial capability that the solution must deliver–unless something changes, or new information makes it necessary to revisit that particular need. Still, in my projects, we look at options and challenge requirements all the time, from project inception to final delivery. While Tony’s intent is good (ensure you keep evaluating and selecting the options which gives the most benefit for the least cost), to me this objective can be perfectly achieved with the word “requirement” still in use.
Great article – your worked example gives a very clear explanation of the process you go through to arrive at a functional design.
If I were to summarise – there are some features of the design which you agree with a particular stakeholder which are classified as “deal breakers” for that stakeholder, and these are the features that you call “requirements”. Other features are implicitly not deal breakers and the design team can make autonomous decisions on them without consulting the stakeholder.
What’s interesting is that the “deal breakers” are actually not deal breakers – you comment that if you want to change them, it’s possible, but you would need to go back to the stakeholder to discuss (for example, a “can’t submit” warning instead of a disabled submit button).
And also your non deal-breakers might actually be deal breakers – as implied by the need to make a quick call to the sales team to check that the non-deal breaking feature (a progress bar) is OK.
This is exactly my experience of how functional design proceeds – things that were apparently requirements are not, and things that weren’t specified as requirements actually are – especially when you present a design which the stakeholder doesn’t agree with. For example, the design has red text on a green background but the stakeholder is colourblind – they never mentioned they needed WAI compliance but you soon discover that they do.
That’s why I don’t like to have a subset of the functional design classified as “requirements” and I especially don’t like to have them signed off.
But for me there’s a more important reason to move away from the term “requirements” and towards the term “design”, and it’s to do with people and skills. In my view, functional design is the hardest part of software delivery – and bad functional design is one of the main reasons that so many IT projects fail. And I have seen a lot of bad functional design, and it’s been done by people who don’t have design skills. Whilst we seasoned BAs understand the complexities of business analysis/functional design, nobody else does – especially not the IT managers and also not the tecchies, who are convinced that they do all the design. In my view, the BA profession badly needs designers, and the way to attract them is to call it what it is – “design”.
Tony, just so that the terminology is consistent, would you define what you mean by ‘functional’ design and contrast is with ‘design’ with other adjectives (such as ”non-functional’ design )?
“for example, a “can’t submit” warning instead of a disabled submit button” (I know I am way behind the discussion)
This and the other examples in that particular comment are all design choices; I didn’t see a requirement among them.
Classic requirement – I need to deposit a check in my bank account. Technology has now supplied multiple designs/solutions: (1) still give it to a person, the teller, in the bank, (2) deposit it an ATM, (3) scan it on a smart device,,,
The requirement is the same, no matter what design supports it. This one-to-many relationship shows the difference between the concepts, clean and neat. So why all the fuss of this discussion?
“for example, a “can’t submit” warning instead of a disabled submit button”
This and the other examples in that particular comment are all design choices; I didn’t see a requirement among them.”
Hmmm… David, I don’t see much difference between your example:
“Classic requirement – I need to deposit a check in my bank account.”
“As a business owner, I want my sales people to only be able to submit a sales form after they have collected all the necessary information, to avoid costly rework that happens when they submit an incomplete form”.
(This was the requirement that in my example was not possible to fulfill, and was renegotiated to “As a business owner, I want the solution to AT LEAST display a warning to the sales people to hopefully prevent them from submitting an incomplete form.”).
I completely agree that “submit button”, “dropdown” and other UI design terms should not be part of a requirement (and they aren’t in my example).
If you check out the references at the end of the article you’ll find a few examples of debates on “one man’s what is another man’s how” – cascading levels of detail. Put another way what is a “requirement” depends on who you are (and where you are in the solution food chain).
To take your own example – “I need to deposit a check in my bank account”. You say this is a clear example of a requirement. I say it is one possible design for a higher level objective – to transfer money from someone else’s bank account to mine. There are other designs – such as an electronic transfer. In fact, the check design is pretty much obsolete in the UK now – I haven’t paid a check into my account for a long time, and many shops don’t accept them any more.
To take it even further, the existence of a bank account is a design for an objective of keeping money in an alternative form to hard cash. And hard cash in itself is a design for an objective to allow people to trade goods & services. Cigarettes are used as an alternative form of currency in prison. Some collective communities manage without any such barter token. And so on, ad infinitum.
You can call them requirements, but in my view, “design” is a more accurate and illuminating term.
Tony wrote”to take your own example – “I need to deposit a check in my bank account”. You say this is a clear example of a requirement. I say it is one possible design for a higher level objective – to transfer money from someone else’s bank account to mine. There are other designs – such as an electronic transfer. In fact, the check design is pretty much obsolete in the UK now – I haven’t paid a check into my account for a long time, and many shops don’t accept them any more.”
This is precisely the crux of our divergence here.
Looking from a business owner who has all the decisions ahead of him, I agree with Tony. It may very well turn out not to be a requirement. But that’s not the reality of most IT projects. My reality is this:
“A bank owner decides that it’s important to allow customers check their bank account balance using the Web. They contact the IT department / external provider, and together they discuss the “requirements” -> something the business needs in order to achieve the objective of “allowing customers to check their bank account”.
Again, it’s all design, but “enable customer to check their bank account” is now a requirement for this particular project. This is something the solution MUST deliver in order to be considered fit for purpose. Is it a design? Yes, along with all design choices that will be made throughout the project: how customers will identify and authenticate themselves; then after deciding that via username/password, how the login screen will look like, etc.
If the subsequent design decisions change (instead of username/pwd, let’s use fingerprints), that’s fine, the project is still meeting it’s objectives. If I’m a developer and say, “hey, you know what, the balance won’t be available once you log in”, then I know we either have to remove this obstacle or kill the project, because it won’t meet the original requirement.
Most requirements may be designs, but not all designs are requirements. Thus the reason, in my projects, to differentiate “requirements” from “non-requirements”.
Reposting here my reply to Tony also posted in the comments section of my post:
TONY: “What’s interesting is that the “deal breakers” are actually not deal breakers – you comment that if you want to change them, it’s possible, but you would need to go back to the stakeholder to discuss (for example, a “can’t submit” warning instead of a disabled submit button).”
ADRIANA: Oh, but it *is* a deal breaker if I decide to move forward with the project without getting into a new agreement with the stakeholders first! Of course, contracts can be amended, but not unilaterally — both parties need to agree with the change.
TONY: “And also your non deal-breakers might actually be deal breakers – as implied by the need to make a quick call to the sales team to check that the non-deal breaking feature (a progress bar) is OK.”
ADRIANA: I don’t see this example as a “deal-breaker”, not in the same way as the non-delivery of a requirement would be. See, as part of the “contract”, there’s typically a UAT process. If users don’t consider a design usable or appropriate, they may not approve of it. Whether their objection will require a change in design or not, will depend on the severity of the issue raised by the end-users. The project sponsor may very well override the objection and accept the design proposal (because it still meets the requirements), or he/she can side with the end-users and request a different design so that non-functional requirements such as usability and performance can be met. But both sides — business and technical — can definitely have a conversation and come up with a solution to meet the requirement that they both agree with. There is no scope change or contract breach here, regardless of how the two sides decide to proceed.
TONY: “This is exactly my experience of how functional design proceeds – things that were apparently requirements are not.”
ADRIANA: But that’s not true in the example I’m providing. If we eliminate from a project a requirement such as “prevent users from submitting an incomplete form”, it’s just a requirement that we decided will be left out of scope because of technical limitations — it is still a requirement the customer had, just now agreed to be out-of-scope due to technical limitations.
TONY: “But for me there’s a more important reason to move away from the term “requirements” and towards the term “design”, and it’s to do with people and skills. In my view, functional design is the hardest part of software delivery – and bad functional design is one of the main reasons that so many IT projects fail. “
ADRIANA: I’ll can’t argue against the importance of having great functional design, but my experience is a bit different — in projects I help bring back on track, by far the largest reason for failure is lack of understanding of business objectives (there was a good conversation around this topic in one of Scott Selhorst’s recent posts: http://tynerblain.com/blog/2013/07/17/why-write-requirements/). If you don’t know “why” you are building a project (hint: it’s not to deliver a set of features or functions), it’s much harder for you to achieve a successful project.
“If you don’t know “why” you are building a project (hint: it’s not to deliver a set of features or functions), it’s much harder for you to achieve a successful project.”
Excellent observation, Adriana. Too many business analysts, project managers, developers, whole projects and agile teams, including product owners focus on features and functions because they can be delivered within an iteration or sprint. While there is value in that kind of focus, we value knowing why the effort or initiative is being done more (to paraphrase a well known Manifesto.)
Good paraphrasing, Steve :-).
My definition of functional design is the design of all user-visible aspects of an IT system. This includes non-functionals. I use the term to distinguish from technical design – the design of the internal workings of the system.
“This includes non-functionals.”
Woah, non-functional ‘what’?
Steve’s earlier jibe about non-functional design made me smile, but now I need to know what you mean. Non-functional requirements is an even more agreed-upon term than functional requirements (which is ironic, I think…) Usability, security, accessibility, performance, responsiveness… all requirements that can be met with different designs.
I hate to switch a physical analogy, but I read history for pleasure, and the development of aircraft since the Wright brothers has been driven by stated requirements —-military wants an interceptor , or a long range bomber, etc—- which are responded to with multiple designs from different manufacturers (when there still were multiples!). I strongly believe that software and its development is inherently different than any other thing people make, but these basics do resonate – here is what I want — Ok, here is one way of doing it, here’s another etc.
As you say, stakeholders have “wants” (very different from “needs”. I call these wants “ideas for business change”. The key point of my article is that these ideas are just that: ideas. Sometimes they are good ideas (benefit > cost), other times they turn out to be bad ideas (cost > benefit). None of them are needed or required.
The process that follows is the elaboration of the idea – adding further detail, making decisions about how the idea is to be manifested (e.g. is it a manual process, or will it be automated via an IT system?). At some point, a specification is written for an IT system to be built. Some people call that the requirements. I call it “a design for business change which has a defined benefit and a defined cost”.
As a side note, “non-functionals” is short for “non-functional qualities”, or NFQs for short – the new “it’s all design” alternative to NFRs. Just you wait and see – everyone will be using it soon enough
I too agree, “it’s all design.” And I also agree with the need to continue distinguishing aspects of ‘design’. As such, I see ‘requirements’ as good as any other term for doing so. Besides, the use of the term is consistent, and has been so for decades. So, why change it?
The problem I have is with the term ‘business requirements’, which use is NOT consistent. Perhaps that’s a topic for another day :).
Adriana, I believe your point about using ‘design’ as a name of a phase is the real issue here. I had not previously considered that.
Duane, perhaps the reason why we keep butting heads about business requirements is because you see the confusion around the term and think, “let’s remove the confusion by removing the term”, while I think “let’s bring clarity around this term so that we can go to a health progression from business objectives to business requirements to product requirements and beyond”.
(I’m actually working on a project that could become a great case study for this. I’ll write about it at some point.)
Tony, just to add to my points above, here’s an analogy that may help further explain my perspective:
I have a requirement (a condition that someone hiring me to provide a day long workshop must meet as part of the contract) to be able to eat every 4 hours to avoid getting a headache due to low blood sugar levels. If I have to go without food for more hours, my requirement is not being met, and not only I’ll be working under diminish capacity, but there might be financial consequences for the company that signed the agreement with me.
It’s the same thing with the requirement “prevent incomplete form from being submitted” — if it’s not met, there will be inefficiencies associated with a person receiving the incomplete form and realizing it’s not ready for processing (that’s why the condition was made into a requirement in the first place–it’s necessary to fulfill a business need of efficiency or whatever). But if due to technical constraints that would be too costly to overcome, the client decides to go ahead with a solution that doesn’t meet this particular need, that doesn’t mean the requirement is no longer a requirement — it just stopped being a requirement for this particular project where the requirement was made out-of-scope due to implementation constraints.
This is very different than the choices we made to fulfill a requirement. I can eat an apple or a full meal, and my requirement will still be met. I can use asterisks, red font, or any other method of highlighting , and the requirement of highlighting missing fields is still met. Knowing what is a requirement (eat every 4 hours) vs. a design choice (any fruit or cereal bar will do) is very important in all my projects, and that’s why, everything being design, I still need words to differentiate “requirements” from “design choices”.
To echo Steve’s point, the value of making a distinction between requirements and functional design is to clearly understand the business need independent of functionality. If you’ve ever worked on a project where the business need was glossed over to jump right into functional design (or even user interface design) you know the importance of making that distinction. Knowing that the high level business requirement is, for instance, to “report the company’s income statement to internal stakeholders on a monthly basis, by business day 5” is very importantly to articulate before you get into data modeling, data definition and report writing.
With that said, I think there are times when the distinction between requirements and design are more subjective. Adriana raised one example: a particular functional solution is externally mandated. In the income statement example I mentioned above there could be ambiguity as well. Where exactly do requirements stop and functional design begin? I think we can all agree that the line I wrote above is a pure requirement. But once we get into things like data definitions the distinction is not so clear (at least to me). Again, having an awareness of the distinction between requirements and design is valuable, but there are times on a project when “requirements” and “design” are completely interrelated.
Aside from the distinction between requirements and design, I think Tony nails it with his observation that (a) functional design is, in fact, design and (b) it is an important, rare and undervalued skill. That is what really resonated with me in Tony’s post. In my experience there is still a perception in the marketplace that business analysis is “requirements gathering” (a term that implies, to me, passively documenting requirements from the stakeholder). Developing useful requirements entails myriad skills above and beyond a vague “ability to communicate”. And part of the required skill set is design thinking. Likewise, developing a robust functional design requires strong design chops, plain and simple. I think that’s a message whose time has come.
Thanks for the great conversation all!
Thanks for your comments all – a really good debate.
I think we are drawing two separate themes here – one is the skill set needed to be a BA – which is actually the one I really care about – and I don’t think anyone is in disagreement about the need for design thinking skills to be a BA. In this context, for me the term “requirement” is a hindrance.
The second theme is more about process – the declaration of a set of “contract clauses” for a system to be built. I completely agree with the principle of having “contractual” documentation that defines what is to be built – that the stakeholder and the delivery team both sign up to. But I don’t like the idea of the traditional single “requirements” document being that contract, for a number of reasons – and I’m planning a separate article to explain why in more detail. But my key observation is that once a “contract” is in place, then (to Steve’s point) there is a tendency to ignore the “why” of a project – the answer to “why” becomes “because the contract says so”.
A real-life joke that I hope everyone here will enjoy:
I was recently meeting with a top executive of a client company to discuss an enterprise analysis project, and while discussing the next steps, he mentioned his expectation that I would be overseeing the software requirements specification later on (since they had a poor experience with a previous BA, leading to faulty architecture and technical design).
I immediately said, “oh, there’s no such thing as requirements. Let’s work under the assumption that we are developing an idea for a business change, to move from the “as-is” to the “to-be”. We’ll make decisions as we move forward, refining the business process and functional design as we go.”
He paused. Looked at me and saw that I was grinning . And then started laughing with relief when he saw I was just joking (because that would NEVER going to fly in a customer-provider relationship like this one). This executive expects as a deliverable of the pre-project phase a proposed scope and estimate of effort and cost for a minimum viable product (MVP) in order to even get approval for the multi-million dollar project. You bet that there will be a business requirements document describing both the business objectives and business requirements =”ability statements” describing the must-haves for the MVP before the project is even approved to move forward.
And the contract will definitely include penalties if the requirements agreed between both parties are not met (we as the providers are not responsible for meeting the business objectives, as they include assumptions that are beyond our control, but we are definitely accountable for delivering anything marked as a “requirement” in the BRD and MVP requirements documents).
Adriana, you produce detailed “ability statements” during the pre-project phase?
Duane: it depends on what you call “detailed”.
Here’s an example of the level of “ability statements” that are captured in the pre-project phase in my projects (this one wasn’t created by me, but is at the same level of granularity of the ones I produce):
“Ability to notify users of scheduled and unscheduled outages in the system.”
(Now, that’s as far as it goes in the pre-project phase. During the MVP requirements phase, the BA will decompose this requirement into more specific requirements, discussing with the end-users and decision-maker, for example, the methods of notification they consider “must-have” capabilities for the solution, which may include the ability to view notification when accessing the system’s login screen but also opt-in/out to receive notifications by email.)
Good joke! Unfortunately you conflated the concepts “defining the requirements/high level solution is actually a process of design” and “no design/estimates up front”. You can, of course, recognise that business analysis is actually a process of design and still do some up-front work to scope/estimate the project.
It’s a shame, because you missed the opportunity for an even better joke. When asked if you would be overseeing the software requirements specification, you could have replied: “Oh, there’s no need for that. All we need is someone who can elicit (draw out) the requirements from the business stakeholders. Anyone with good communication/facilitation skills can do that – they don’t need to have any design experience because we’ll get someone more experienced to do the design at a later stage.”
Oh, the second joke would go over his head, Tony, because the word “design” is so intrinsically associated with “the work that the architect/tech lead does after you have specified what needs to be built, both from a functional and non-functional (“itilities”) perspective :-).
Seriously, while you have a dislike for the word “requirements” (the part of the “functional and non-functional design” that are non-negotiable for a project), as previously mentioned I would like to, instead, do away with the word “design” as a set of project activities, because as you say, everything is design, so why have a set of activities called design like we do today even in my agile projects.
We need good designers at all stages: designing a market strategy, designing the process to retire legacy, etc. So when you say “design experience”, to me it’s too ample to really mean anything!
I’m strongly in favour of reducing the number of phases in projects. The project I’m currently working on has four “design” phases, all of which involve formal documentation and heavy-weight review/approval processes:
1) Scope definition, including high level approach & design
2) “Requirements” definition (i.e. a partial functional/non-functional design) – not enough detail to build or system test against
3) Functional/non-functional design – a detailed definition of the user-visible behaviour of the system – enough detail to system test against
4) Technical design – a definition of the internal (non user-visible) workings of the system
(we are semi-agile in that we have broken the functionality down into slices – but we have still gone through all four phases for each slice)
For me, there is one phase too many here. My preferred approach is to combine phases (2) and (3) into a single phase. The functional/non-functional design then becomes the “contract” between my business users and the development team. Any higher level “requirements” (including the overall objective) are included with the design to provide rationale, rather than existing as a separate signed-off contract in their own right.
And by the way, I would generally produce a separate design per functionality “slice” (feature/story/use case/whatever) – not a single uber-design for the whole project.
From my recent reading, it looks like some people already work this way, but prefer to use the term “software requirements specification” to refer to the output of the combined phase 2+3.
Re. phase (4) – technical design – I’m not convinced this phase is needed either – and agilists of the NODUF variety would agree – but in some cases it might be justified. For example, my current project is a data warehouse, and it appears that the penalty for getting the physical design of the DW wrong early on is high – so the NODUF approach is questionable on this project.
Adriana, forgive my badgering…
So, you’re saying, “Ability to notify users of scheduled and unscheduled outages in the system” is a scope statement. That makes sense. But are you also saying that your scope statement is a requirement as well?
I guess I don’t regard a statement of scope as a requirement.
Yes, Duane — in my projects, “ability statements” are business requirements derived from business objectives, and define the product scope. There are two types of scope in my projects:
Project Scope = The work that will be delivered.
Product Scope = The capabilities of the product that will be delivered as part of the project scope.
A project scope may include things like training / knowledge transfer for the internal dev team, that are not part of the product scope (but ability statements are). At least that’s how it works in my consulting projects since 2004 in NYC, now in Austin with clients here and in Florida. Like they say, YMMV, and others in this thread may have different perspectives to add.
Thanks! I’m always on the lookout for ways to improve my own model. I’ve come to the point where I don’t like calling scope statements requirements, as I deem ‘requirements’ that which is delivered to initiate development. Semantics!
There’s a related article on this topic on BA Times:
We Are All Designers Now
Tony, wonderful article! A few comments, though.
I often use the metaphor of a (building) architect facing a transformation job (renovating something). That is essentially what we do a lot of the time. Analysis (inspection) is bound to find stuff in need of re-work and holes to be filled. That is why design in obviously an issue even when looking at as-is. (Which is also ill-defined in many cases). Add to that that as-is is really also a design, but an old one.
Delivering value is another thing, which is a design issue. In fact, validity is driving designers all over the spectra of design activites. So, analysis and design must go together in one process (at least if you want the business people to participate, and you do). That is what much of my book (Design Thinking Business Analysis) is about.
In your list of designs I am missing “business information design – a representation of the business information to-be conceptual structure”? I use concept mapping (not mind mapping) for that. Ron Ross calls it concept models (after the advent of SBVR 1.1).
This is great stuff! Anybody coming to London for the BA2013 conference must look me up to discuss these matters!
What a relief to find someone else who can so eloquently put to words what I’ve only experienced as a “splinter in the mind” to borrow from The Matrix!
Why fades to What fades to How. It just depends up to which point you choose to challenge and question.
Thank you for this wonderful post.
Pingback: Why it makes sense to write requirements for software projects
Pingback: I'm Not a Business Analyst - I'm a Business Analyst Designer | its-all-design.com
Pingback: IIBA UK North West & East Event - Leeds - 18/03/2014 | its-all-design.com
Pingback: Requirements are really Desirements | its-all-design.com
Generating options and selecting a preferred one is certainly a design activity but shouldn’t be called as the design process itself. The design is a process about getting to an unknown solution. However in business analysis we’re usually dealing with stakeholders who already visualised the desired solution in their minds. Of course it’s BA’s job to discuss the feasibility of their suggestion and to come up with alternatives, but I believe the requirements should state what the stakeholders want as opposed to how those will be delivered. Despite its controversial title I still liked this interesting article and also need to mention that I do agree with the ‘need’ aspect of usual requirements that you pointed out. Kind regards
This is true if you only think about requirements for software development which is what many business analysts think is their only job. But what about non-software development requirements that business analysts define? For example, in a recent organizational move from one office building to another being built down the street, the business analysts determined the requirements – where the offices were going to be, the sequence of the move, which moving company was going to move what, etc. – and there were no software development involved in the project at all. This was perhaps the largest project in terms of those affected and budget in the organization’s recent history. The business analysts’ task was to effect the move with as little down time for the employees as possible. They did it. And they defined the requirements for doing so first.
It sounds to be like the BA designed the business process for the office move. It was a creative, inventive activity that generated the design of that business process, based on various constraints/objectives supplied (e.g. “have as little downtime as possible”) it’s not like the requirements were “out there” ready to be gathered or elicited. I’ve read your excellent article “Stop Gathering Requirements”, so I think you would agree that the BA is creating/inventing something here, so I think it’s just a terminology debate – you say requirements, I say pot-ah-to, erm, sorry, design. I prefer “design” as a term because it better reflects the creative/inventive nature of the activity.
Alistair Cockburn has coined a new phrase recently to replace “requirements” – he says “deciding what to build”. In your example, it would more be a case of “deciding what to do”. He says deciding, I say designing. Same thing really.
If deciding and designing are the same thing, why use both terms, why not just one to avoid confusion?
In the real example, the business analysts did not design the move, the movers did. They specified what was necessary to be done from the organization’s perspective for the move to be successful for the organization. The moving companies and other contracted companies figured out how they were going to do it – how many trucks, how many people, who did what, when it happened, etc. What the business analysts physically created was a basically a list.
In this particular case, and in other similar projects, there are contractual arrangements that clearly delineate the separation of activities. However, it might be the same even without a contract. The business defined what was to be done – what it needed – the requirements – and the contractors designed how it was implemented. This is particularly clear with the interior designers who took the business analysts list and designed how to implement it in the new building.
So the lexicon question, similar to the one I started with, is – if what the business analysts did in this case is design or decide, what did the executives do who decided which various alternative to implement and what did the movers and other contractors do? What do you call the diagrams and paperwork the other contractors did which was then approved by those executives?
“However in business analysis we’re usually dealing with stakeholders who already visualised the desired solution in their minds. Of course it’s BA’s job to discuss the feasibility of their suggestion and to come up with alternatives, but I believe the requirements should state what the stakeholders want as opposed to how those will be delivered. ”
Hmm… Murad, I have a problem with your statement here. While it’s very true that most stakeholders come to the table with a solution already defined in their minds, a skilled BA will quickly change the conversation to discuss the underlying problem to be solved. To go back to the beaten example of “what customers would have said if Ford asked them what they wanted: a faster horse”, the path to the optimal solution to a business problem or opportunity does not start with “requirements that state what the stakeholders want”.
I like the mantra “act not on the request of your stakeholder, but on their behalf”. So when you say “it’s BA’s job to discuss the feasibility of their suggestion and to come up with alternatives”, I’d say it’s even more important to take a step back and ask “why” five times to understand why the stakeholder is making that suggestion. Only then you’ll be able to start the analysis to come up with the best solution to address that particular need. Once there is agreement around the best solution is when we come into consensus about what’s supposed to be delivered, and define the final requirements that will be the main reference for the delivery team.
On a side note, I like “deciding what to do” as a description of what leads to what we call “requirements” in the world of software projects.
Pingback: Systemanalyse 3.0 – Literatur | SEQIS - Weil Softwaretest wichtig ist!