Benefits from Traceability in product specification (dependencies management)

0 Comments

Before we analyze whether it is worth investing in traceability in product specification, let’s clarify the word “traceability”. What is traceability? What is the better way for dependencies management. Let’s explain it in most general terms. Traceability describes some routes of elements in the structure of the conceptual model . Those elements would be for example requirements or process steps.

To go further, we need to explain what those elements are exactly. Let’s focus on the most popular model which is the Requirement Model.

Examples of these elements in this model are

Needs (goals)
Business Rules
Business Requirements
Stakeholders Requirements
Functional requirements
Non-functional requirements

In the product core lab with nesting, this will look like in the above picture.

From another perspective, if you know UML, you should think about the elements like “stereotypes”. (https://en.wikipedia.org/wiki/Stereotype_(UML)). Stereotypes or archetypes define some principle, or basis. Stereotypes specify how elements in Software engineering describe architecture or some model and concept.

If we go outside, higher in the Software engineering hierarchy to the Business Layer (In the Business Model), we need some similar archetypes in the level-up of abstraction. We could use the name – “archetype” to describe Business rules and their principles or “Idea”, “Needs”, etc.

Ok so if we have clarity with elements of the product lifecycle and software documentation, let’s go back to Traceability.

Traceability is some kind of analyst process and type of modeling that gives you an opportunity to follow how one element influences another. Then, you can model and write great product specifications.

If you properly perform and document traceability, you can check what relations the elements have. Traceability focused on requirements is the most popular, but you can trace other elements of software engineering. You could describe dependencies between requirements and tests, mockups and tests, risk and requirement, or even business requirements and risks.

In my opinion, you can trace everything that gives you a better picture of the software product. So, if you want clear and consistent software documentation, add to it a model with the presentation of traceability.

Relations in the Traceability model.

On the one hand, we have some different types of project elements and on the other hand, we have types of relations between elements. So let’s go deeper into the types of relations. Some examples will be the best.

You can use

simple association
aggregation
usage relation

The name of the type of relationship explains its meaning. Next, a special type of dependency is “trace”. I like to explain it as “is a result of” or “is derived from” For example, some functionality is a result of a business requirement. Technical requirements are derived from business requirements or the functionality “trace” to the UI project.

From a general perspective benefit of Traceability is a better view of the relationship between Product Lifecycle Elements. If you want to dive deeper into Product Lifecycle Management, start on https://en.wikipedia.org/wiki/Product_life-cycle_management_(marketing) . Next, we divide PLM into main phases and activities.

Introduction,
- Idea (Innovation/Discover, Generate ideas, Create propositions, Conceptual model)
- Analysis (Requirements, Modeling, Design, Prototyping, Confirmed MVP)
- Develop (Focus on MVP, Deploy, Launch)
Growth
- Find Market Fit (Feedback, Development, Change Request, Fix)
Maturity (Maintain, Fix, Feedback, Development, Change Request)
Decline (Keep, Kill, Pivot, Reboot, Feedback)

In those, we find a good place and various benefits for Traceability.

Benefits from Traceability in Innovation or Analysis Phase in the product specification

In those two sections of the Product Lifecycle, Traceability helps devise the solution. For example, when you only have ideas with some business needs, you can model Business Requirements and track them together. You could define Business Requirements as a User Story. Next, you trace all the needs to User Stories. When you define Actors as meaning the users of the application, you could associate Actors, needs, and business requirements. In consequence, you have a great traceability map from a business perspective. Actors have needs and business requirements. In the Ideation phase, you generate a lot of ideas and hypotheses about what needs your customers, the actors of the Software, have. If you trace it all together, you can follow if you have an idea to satisfy all your customer’s needs. You might find some gaps or logical mistakes in your map.

Let’s take a look at some examples. Let’s assume you have an idea for some application that helps manage time and helps with productivity.

We could define some actors and specify the segment; This would be our simple stakeholder map thus focusing on the customer as our main stakeholder.

User/Client (Actor) as Student

User /Client (Actor) as Manager in a corporation

User/Client (Actor) as Entrepreneur (Freelancer)

We have the first association User/Client aggregating three ideas of segmentation. We have three types of Users. We could say that traceability here describes trace from User/Client as an element of PLM to three elements defined as actors. This type of traceability is called aggregation.

Let’s move further

Now that we have actors, we could use some brainstorming to figure out our discovery needs. So what needs could students have? They could quickly learn some school material. They want to focus on the most important material because they have a deadline for an exam. Somebody in a brainstorming session threw the idea that users all need to calculate time spent on some task. We could note this as some idea and define it in the archetype as “need”.

Now we have something like this:

User-> Student -> (need) Learn material quickly

User-> Student -> (need) Focus on the most important material

User-> (need) Count time spent on a task (Student, Entrepreneur, Manager)

If you are a product owner or founder, at the next meeting imagine you will invite an analyst and developer and you want to introduce your ideas. To better understand them, you prepare some user stories and some ideas for solutions in the product. But you have limited time to prepare everything, so you decide to describe only one story in one example.

User-> Student -> (need) Learn materials quickly -> User Story: As a Student, I want to use a timer because this will help me learn more quickly. I assume that the timer helps me to focus.

User-> Student ->(need) Learn materials quickly -> User Story: As a Student, I want to add a list of subjects because I want to define the most important material to learn.

The next step in our history is that the iteration of ideation is finished. You will meet with the team after the weekend.

If you have a list of all elements in this Phase of PLM and the traceability model, you could use it in a meeting.

At a quick glance at the product specifications and traceability, your team should understand the structure of your Idea. They can quickly see the product from a business perspective. So, the first benefit of traceability in software documentation is a quick reminder of some assumptions. In this case, assumptions in business view, business perspective.

The next benefit you have from this map is that you can quickly find gaps that elements aren’t carried for. We call them ”orphans”.

There are elements without parents.
You could find parents without children too.

In practice, at the next meeting, you have a list of tasks and elements that you should analyze. You will find “orphans” and analyze where and with what type of “relation“ you should join it to other elements. Let’s take a look again at our example

As you can see, managers don’t have any needs, the need “focus on the most important material” does not have any user story or even an associated Actor. This is a very interesting element. This is a typical orphan. This is a need without any connection to the user story or a need element. So, we have to think twice or try to come up with a reason why the Stakeholders or Client added this element.

The next benefit of investing in traceability is a quick glance at the scope of the product. Analysts or product owners could quickly see how many components are in the application. This could be the first insight into how to estimate the size and complexity of the new products.

Maybe this would be too early to estimate specifically how costly the application would be but Analysts could estimate how costly the process of the analysis will be.

For example, analysts could count how many types of actors would use the applications and how many have clear needs and user stories. On the next iteration, the analyst or project owner could count orphans and estimate how much time would be consumed by eliciting the needs and business requirements.

When you decompose the application into all elements and model the traceability, you find the next asset in the quick prioritization of functionalities. You could do this easiest because in one “picture,” you have to look at functionality saying “what” and business requirements saying “why”.

Benefits from Traceability in the Development phase

The best benefit at this phase of the product lifecycle is the communication that traceability indeed helps. As in the above phase, teams have a quick view of the product from different perspectives. In addition, they can quickly understand what comes from what.

This is the same benefit as a good documentation in itself. In teams where the rotation of members is big, onboarding and introducing all assumptions of a product is costly. Software documentation and a good traceability model cut this cost.

I know developers quickly understand the functionality and they could in a short time answer the question of how the applications work. However, they lack information on why some functionality is required. As a consequence, the team could have some misunderstandings at the business level of the product. Developers collect that information while developing a product but they don’t have the big picture at the beginning of work with the product. In my opinion, teams lose a lot without a model of traceability. This would be the center model in discussions about developing a product.

The next profit that is worthy of mentioning is something in the analysis and development phase. Very often in building applications, you probably find functionality that is the result of two business requirements. For example

Business Requirements: User wants to view the list of orders -> functionality: “Generating a list of orders”

Business Requirements: User wants to download a PDF report with orders -> functionality: “Generating a list of orders”

Two different Business Requirements and one and the same or similar functionality

With traceability, when you connect elements you might find a few examples that help you build applications with the same components which realize more than one business requirement or need. As a consequence, you could cut costs when building the solution.

A very popular usage of Traceability is connecting requirements and tests. In the Traceability matrix, you could check orphans without a plan of testing. In this process, you could verify that all requirements have a connection with test scenarios. In this case, traceability gives you better quality in your Product lifecycle management.

Benefits from Traceability in the Go-to-market phase

In this phase of the Product Lifecycle, you also find profits from preparing Traceability. When you build a “big picture” with all business requirements and functionalities decomposed, with all relations connected, then you probably create marketing materials quicker. In one view, you will have a list of functionalities and benefits to users and why it’s worth using the app. You have the entire marketing analysis prepared in phases before carrying it out.

What profits do you get from traceability in the Maintain phase

In my opinion, in this phase, traceability (dependencies management) is the most practical. This chapter on product specification could help with some changes in your or your client’s product. Product Owners, Analysts, or other team members frequently think about how new changes have an impact on other components. If there are any risks to changing requirements or modules or processes.

After requesting any changes in the application, you should always ask these questions:

“What will happen if we change it?”,
“Where does this requirement come from?”
“Will there be any hidden costs?”

If you have your map with a trace, showing what elements are joined to each other, you can answer the above question more quickly and more confidently.

Think about your product and all business or technical aspects like a combined vessel.

Any change could have an impact on some other elements. You have to be smart and understand which and how many elements.

Traceability could save your and your team’s time. I will give you an example from my experience.

We were analyzing some processes of managing the users. We were focused on some field in a form and stuck at a meeting. In the meeting, there were 5 business people (stakeholders) that use this form almost every day. We were analyzing business processes but we were stuck on functionality. Nobody knows why this field is in this form. They use one option in the dropdown menu and nobody knows why.

You probably think this is not a problem. Developers should be able to find everything in the code, and check where this field has a connection to other spaces in the application. But the problem was that it was a big company. The investigation was time-consuming. After the verification of developers, we had to meet again with stakeholders. Luckily, we were able to explain everything. I could bet that after six months everybody would forget about the reason why this field was in this form. In this company, nobody invests in Traceability.

Those issues can be found under “Impact analysis”. You can go deeper with this question on google.

Powerful Traceability in Product Core Lab

It is very important to highlight this concept, especially in Product Core Lab. ProcoLab covers the whole governance of the product. At three main levels of abstraction. At the level of the Product Life Cycle with phases of the live product based on a timeline. The next layer is the Business Model. This is a perspective on the product that comes from the Business Environment. The level of how you manage a product in the Market. This is the level of Selling Strategy, Delivery of the Product. Price strategy and all that give you advantages and duration on the market. Going further, we have the Requirement Model in the functional meaning. This is the most popular model analyzed in Software-Houses. Here, you model a product as a capacity that you or your client have or will have. If you think at this level, think about the product like material things, even if this is a service or a virtual product. For example, a product like a tomato. You have a product, this thing, tomato … you want to sell it. When you want to sell your resources, you have to go up a level and focus on the Business Model. Your Product and Business Model have to be set in the proper phase of the product lifecycle. Everything has a connection together.

In the Product Core Lab, we assume that elements from the highest level of abstraction have an impact on other elements from the nearest level. In the Product Core Lab, you can model, as mentioned above, all levels of abstraction. If you follow all elements from a high level to the nearest level, you have a really powerful Traceability. And that’s what you find in Product Core Lab.

Summary

From another perspective, you can say that traceability is some kind of map that provides a look at the relations between project elements. You could read a map like a model describing how an application looks from a business perspective and functional perspective in one picture.

As I’ve mentioned, you can think about traceability like the structure and you can use that structure. In Prolibase, you can model traceability as a table with nesting levels.

Takeaways

It is worth investing in Traceability (Take care more dependencies management) at the beginning of the project because depth is still growing over time
It is worth it to trace everything in the analysis phase. You will be able to find the gaps and “orphans”
Decomposition of Applications for business needs, requirements, and features is the first step in every new project. The next small step would be logically joining specific elements.
Traceability gives you a lot of benefits at every phase of the Product Life Cycle.
Traceability is like a 3d map. On one level, you have one perspective, on the next level, you have another perspective. In the cross of that, you have to trace elements from one perspective to another.
Product, Business, and Processes are like combined vessels.

About author

Karol Kordziński - Business Analyst I’m Karol Kordziński from Poland . I’m an analyst with a couple of years of experience. I’m the owner of ITGrowPartner where we help small- and medium-sized companies analyze projects. But mainly I’m the owner of Product Core Lab. Saas tool to manage a product in the whole Product Lifecycle. With this tool, you can explain your product and processes in a structural method. We introduce you to how to model software products step by step