Scott Sehlhorst (@sehlhorst) has written an excellent article titled Requirements vs Design – Which is Which and Why? Some of my own thoughts are in this post, but read Scott’s article first to get the context.
Scott seems to gather the problems a business sees with its current model (e.g., inefficient practices, outdated rules, failure to comply with the law) and any opportunities which have arisen (e.g., because of changes in the law, new markets opening, the availability of new technology) and to which the business would like to adapt under the heading “market requirements”. I would be uncomfortable calling these “requirements” because I see them instead as observations of the current state of affairs. But all I disagree with here is the label.
He goes on to talk about analysing the problems and opportunities in order to produce a set of goals. I would refer to such goals as “business needs” which have to be satisfied in order to mitigate the problems and take advantage of the opportunities. Scott would see such goals being documented within a Product Requirements Document, whereas I do not see business needs as product requirements, since not all business needs are going to be satisfied by building a particular product. Some will be satisfied simply by changing the approach to staffing or by modifying a manual process. I do agree with him that goals (business needs) are the outcome of what he calls “ideation” and that they need to be documented. Again, we don’t seem to be at odds with regard to the underlying concepts, just the terminology and documentation.
I would document the problem/opportunity statements, the analysis of each and its consequent business goal all together in the same place. Subsequent to that, I would expect to see a “future state” model of the business which reflects how the business needs to change in order to attain those goals. Only if part of that future state needed new or enhanced software would we start talking about product requirements.
I disagree that “design constraints” are requirements. However, that could also be down to our different use of terminology. Scott seems to use the term to refer to constraints imposed by the business, e.g., product look-and-feel, performance, accessibility. I refer to such constraints as “non-functional requirements”. NFRs are always provided by the business and as such are business requirements.
In my head, a design constraint is imposed by the solution design (a term also used by Scott and I happen to use that term in the same way) or by the chosen technology (e.g., a configurable BPM tool). The following are examples of what I would consider design constraints:
- Use of a particular set of coding standards
- Use of a particular messaging layer
- Use of an “out of the box” GUI that comes with a particular technology
If by “design constraints”, Scott means what I call NFRs, then I agree that his design constraints are requirements. However, what I call design constraints are usually not requirements, although they can be. The last example I provided above could be a design constraint imposed by the business because they want to get maximum ROI out of the tool they have licensed by avoiding customised GUIs.
[Edit: In his comment below, Scott points out that NFRs, such as coding standards, could be imposed by the development team, and I agree. It is merely my preference to label constraints coming from the business side as NFRs and those coming from the technical side as design constraints. In the end, Scott and I are talking about the same thing.]
The solution design can also generate technical requirements. TRs are not of interest to the business but they are not simply design constraints. A TR means that some functionality must be built in order to realise the solution design, but the business has not requested it. Such functionality is invisible to the business.
I think it is essential for product requirements, solution design and choice of technology all to be traceable back to business needs. However, business representatives often provide product requirements which are at odds with the stated business needs or which are not traceable back to any stated business needs. Many times I have challenged requirements, asking “What is the business need here?”, only to be met with blank expressions. In some cases, there are no documented business needs. I have often found that requirements analysts fail to actually analyse the product requirements and merely document them without understanding the underlying needs.
Those who procure a particular technology (e.g., a customisable workflow tool), often do so based on a slick sales pitch, rather than its ability to realise the business vision. Programmers, too, often fail by simply building what was required, never questioning whether the solution really satisfies the needs of the business, even if it fulfills the product requirements.
Thus, for me, business needs have primacy over requirements (see the image below). The latter should always be sub-ordinate to the former (as should the solution design and the chosen technology) and good analysts will think and work accordingly. Unfortunately, a lot of analysts choose to behave merely as requirements stenographers. [Edit: Scott knows this, of course, so this paragraph is dedicated to you junior analysts reading this post: Think! Challenge! Understand! Don’t merely take notes.]
I assume you have read Scott’s article by now, but I suggest you read it a few times. I prefer the terminology that I use (Well, I would, wouldn’t I?), but believe I agree with Scott’s underlying principles.
If I have misunderstood any aspect of Scott’s article, I’m sure he will set me straight and I will update this post accordingly. [Edit: Which I have!]
Kind regards,
Declan Chellar
Related posts:
Hey Declan, thanks for contributing your thoughtful response / analysis to the community!
FWIW, I feel like my perspective has evolved a bit over the last 6.5 years since I originally wrote that article, and would say that my most recent comments (July of 2012) better reflect my current thinking.
That said, I would point out a couple things that probably weren’t clear in the way I wrote the original article (sorry about that!).
1. The only goals that would be captured in a PRD are the ones that are relegated to being addressed with the product. That’s the point of the ideation step – to _choose_ which market problems (worth solving) should be solved in this product.
2. The “design constraints” I mention are the non-functional requirements – per Karl Wiegers’ schema of structured requirements. Not the constraints imposed by the selection of a particular implementation approach, but the constraints that bound the set of acceptable solutions. By definition, these are non-functional requirements. The examples you use, I would content, are also non-functional requirements. Following coding standards, as an example, is a non-functional requirement, imposed by the stakeholders who are responsible for managing (or outsourcing the management of) the code. They exist to reduce the long term total cost of ownership (manifested as ramp-up time for new developers on the team, avoiding broken-windows scenarios, etc), or to create lift – by establishing standards for an open source project, in order to attract more developers (or more development from more developers) and thereby increase the demand for the associated product. I think the same rationale applies to the other examples you listed – the only thing you have to do for this rationale to be valid is to acknowledge the development team as (internal) stakeholders.
FWIW, I agree with your point of view about the primacy of the overall objectives of the business.
Thanks again,
Scott