As of late, there seems to be a lot of discussion about granular solutions compared to integrated solutions. I wrote about it a few months ago in a post titled Point Solutions, Integrated Solutions and the Granularity Value Proposition. And while discussing it at the highest level does lend a little clarity, it is still a little nebulous. For me, I need to dig a little deeper into specific application areas. That’s the purpose of this post.

Today, I’ll take a look at granular solutions versus integrated solutions for requirements management. As always, please weigh in with your own thoughts in the comments. The more perspectives, the more complete and valuable the discussion for the community. With all that said, let’s get started.

What is Requirements Management

To level set, I think it makes sense to start by defining requirements management. That way we can all have the same baseline for our discussion. Here’s the definition of requirements management from its entry in wikipedia.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

Furthermore, wikipedia points out the importance of traceability in requirements management, something that will become relevant to our discussion a little later.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

In general, I agree with this definition and the importance of traceability. If you feel this is inaccurate or missing some critical aspect, please post your dissenting view in the comments. Again, all perspectives are welcome as long as they are respectful.

OK. With that said, let’s start talking about different kinds of solutions.

Requirements Management Point Solutions

This type of system is fairly easily defined. A point solution that manages requirements is a centralized system, to which many clients connect, that manages the definition and modification of requirements. Specifically, each change is tracked as different versions and iterations of a requirements. Furthermore, requirements can be decomposed into sub-requirements.

These systems not only manage requirements. They sometimes also manage functions, which describes a capability of a system, assembly or part in a product. They also at times have some representation of the product structure or Bill of Materials. However, let’s be clear. These product structure or BOM representations are not tied to structures generated by CAD assemblies. Regardless, the critical capability is the means to allocate requirements to functions and functions to some aspect of the product structure (or architecture or BOM).

Furthermore, requirements are often split up into different categories or types. Some organizations need to manage the source of the requirements. Others may need to manage end requirements compared to technical requirements.

Another set of capabilities that requirements management point solutions often provide are focused on collaboration amongst teams. When many clients can see into the same centralized system, users within an organization can correspond back and forth on the definition, decomposition and modification of requirements. Such activities often require such interaction because of the interaction of different systems within products.

Requirements Management as Part of PLM Solutions

What capabilities does a PLM solution that includes requirements management offer? For the most part, practically all of the capabilities described above are part of requirements management in a PLM solution. But there are additional capabilities that also exist.

For one, a major difference between point solutions and a PLM solution is the real-time management of a product’s structure. This often is driven from PDM capabilities that manage Mechanical or Electrical CAD as well as Software Configuration Management. As engineers and designers develop products, the mechanical, electrical and software aspects of that product structure will change. This is one source of change that needs to managed and traced because there are serious implications for requirements. Furthermore, requirements often times will not just be allocated to a specific part, but actually be allocated to specific geometry within a part. Such allocation requires deeper integration with CAD PDM capabilities as well as the CAD application.

Another important set of capabilities that requirements management as part of a PLM solution provides is workflow. This functionality can automate and enforce compliance of business processes. When it comes to requirements, there are important processes that apply including: system engineering decomposition and allocation, simulation and prototyping as well as verification and validation.

Which is Better? A Granular or Integrated Approach?

OK, is there a clear winner here? Well, perhaps not.

If we were asking which kind of solution offered the most capabilities, then there would be no question. Requirements management as part of a PLM solution clearly provides more functionality. But that’s not the point. The whole movement towards granular solutions proffers a new and important question: are all of those additional capabilities worth it?

Answering that question isn’t quite a simple. For me, however, the answer is tied up in consequences. What happens if you don’t have those extra capabilities? Let’s look at it in that light. In fact, let’s go through them point by point.

• What happens if you don’t have functions? The importance of the implications here depends on how heavily your company depends on a system engineering process. The system engineering process pretty much requires the definition and decomposition of requirements. Those requirements are then allocated to functions (meaning the functions must fulfill the requirements). Those functions are then allocated to aspects of the product structure. The intermediary function is needed to execute that process. So you simply must ask yourself, do you run a system engineering process?
• What happens if you don’t represent the product structure? This actually is a biggie. One of the biggest central tenets of requirements management is somehow creating a relationship between the requirement and a singular item in the product structure. Without that, you have no traceability. And, well, that’s kinda the point. The lack of this capability is a non-starter in my mind.
• What happens if you don’t represent real-time product structure change? Ahhh. Now this is where we start to get down to the nitty-gritty details. You can certainly represent the product structure independently of CAD PDM, but that means you likely won’t be able to keep up with the pace of change occurring with CAD and IDEs, depending on the pace of change on your engineering teams. An important value that requirements management practices is to understand the implications of a change, whether that be from a modification to requirements or switching parts in a CAD assembly. Leading up to design release, change on the CAD side of things can be chaotic. At design release, you REALLY need to know if all the requirements are satisfied. In my eyes, this is terribly important.
• What happens if you can’t allocate requirements to CAD geometry? While it often sounds nice to allocate requirements to specific geometry, I haven’t seen it put into real practice that much. Furthermore, at some point, the engineer or designer has to make the connection in their mind between the requirements allocated to the part they are designing and geometry they are creating in CAD. I see this being critically important in a select few cases.
• What happens if you can’t automate processes with workflow? The processes around requirements management are increasingly important as products get more complex. So the importance of the answer to this question depends on your products and your organizational processes. Furthermore, can this sort of process be run without workflow automation? Absolutely. Is the use of workflow likely to catch more errors that could have gotten downstream? Yes. For me, the importance of this again depends on your organization.

As you can see, there’s no simple answer. But in my eyes, the need to represent change from the requirements side of things as well as the need to represent change from the CAD side of things is really important. Unless you have a very static product structure throughout development, then this single set of capabilities probably means that requirements management as part of a PLM solution is the best fit.

Summary and Questions

Let’s recap.

• Requirements management is a means to define, document, analyze and allocate requirements within a product.
• Requirements management as a point solution offers capabilities to define and track requirements, define kinds and types of requirements as well as enable collaboration amongst engineering teams. Some of these point solutions also offer capabilities to define functions and product structures that allow the allocation of requirements.
• Requirements management as part of PLM solutions offer additional capabilities. Most notably, these systems enable the representation of change to product structures from CAD models as well as workflow that automate processes like system engineering and verification and validation.
• There are many implications due to the absence of such capabilities. But one of the most critical is that the lack of representing change from CAD. This means that the full implications of changes to requirements or the changes to a CAD models and corresponding product structure will not be fully understood.

Alright folks, that’s my view. What’s yours? Any critical capabilities that I missed? Do you think any of these capabilities are more important than others? Interested to get your take!

Take care. Talk soon.