Aligning organization strategy and data: assuring continuity between needs and development

A good way to ensure the need and the solution are aligned is to ensure the implementation traceability. It means we do not lose the "continuity" between needs, analysis, design, and implementation. 

It will help formalize the out-of-scope, minimize scope creep, improve consistency, and maximize the implementation value. This "continuity" is also important to evaluate and manage change in the project.

A continuity model has been developed to help to manage complexity.

What is the continuity model?

It's a model with 4 layers: Need, Analysis, Design, and Implementation. The objective is to model the four layers to minimize the changes and ensure each implementation answers a business's needs.

They will be dependent on each other because each one is the result of the previous one.
They will also be independent, as they are modeled separately. They will last during the project, and it will help to evaluate the change impact.


The Need: clarifying the "Need" ("the snowflake" in the metaphor: link): this part is your business and organization objectives.

Analysis: analyze and formalize and interpret the need to functional requirements. At that stage, some needs are excluded from the scope.

Design: Defined the technical requirement. How the solution will meet your functional requirements.

Implementation: It's the physical implementation of the technical requirement. Ie: the script generated to implement the design.

This model could appear a little too theoretical at first, but it's beneficial to manage changes.

Formalizing the out-of-scope

Some time conversations on scope between stakeholders and project team are challenging. This continuity model helps to clarify the difference between the need and the scope.

Going down the continuity model, the team will estimate the cost (time and money, resources) of the solution. 



Then, it will be needed to match and prioritize the resources of the initiative. It will appear.


How it's helping to manage change?

To manage a change, only linked components in the model's downstream layers need to be considered

 


Let's take an example: a company sells products in stores.  Due to COVID, they change their strategy and decide to sell online too. You need to integrate the new online sales to the datamart. If you clearly defined the model and documentation, you will link the needs, requirement analysis, design, and implementation. You can identify (without much effort) which component is affected by the change and what needs to be done.

Maximize reuse and minimize side effects

It will help to figure out which component can/should be reused. Many users ask something "same same but different." They will express the need with process, reports, business unit organization already in place. Looking at your model continuity, you will be able to see which component is reusable


As you can see, if a component is filling more than one component from the previous layer. You can analyze the impact of a change on the previous layer.

Conclusion

This model is handy when the project is experiencing a lot of changes or scope creep. It will be beneficial to not end up with a "spaghetti plate."

How to do it? It could be done with a goal tree, a traceability matrix, or many other ways. Some softwares are implementing this traceability.

References

Engineering and Managing Software Requirements- Aybüke Aurum and Claes Wohlin (eds.) Springer Editions. Ch 3: Specification of Requirements Models. Ricardo J. Machado, Isabel Ramos, and João M. Fernandes.


No comments:

Post a Comment

Leave a comment here