Last Updated on 1st November 2021 by
A Wide Range of Sectors
We’ve seen investment from a wide range of market sectors, all of whom have very differing products. However, there are many similarities in the processes that they use, based on their need to manage the same types of complexity.
Project Needs and Goals
Every project seeks to satisfy a set of requirements in a way that maximises compliance and minimises time, effort and cost. All projects must demonstrate that they have met the requirements by passing a variety of acceptance or validation checks. Therefore, RM (requirements management) is not unique to any individual industry.
Depending how you classify your ‘system’, the concepts and activities of Systems Engineering are also not ‘industry specific’. SE (systems engineering) may sound a little grandiose for some projects, but that depends where you draw your system boundaries. You could be modelling sensor data and control signals coming in, describing how these are manipulated and what outputs are expected. Alternatively you could be describing goods inward, shelving process and booking out.
What constitutes a ‘system’ depends on your industry sector, but the need for careful engineering of systems is common to all sectors.
Sector Investment 2020/21
Discover which industries are investing
Using 3SL’s end of year results grouped by sector we have highlighted an interesting change in RM and SE investment over the last year. Whereas aerospace, and military and defence projects had dominated in the past, construction and energy industries have made a heavier investment this year.
Is Requirements Management and Systems Engineering Right for Your Industry?
If you make, design, or maintain a product, process or a development area, the answer is likely yes. Projects are most successful when; they can capture the needs of the stakeholders; help plan and develop the solution; provide traceability and reporting at the end. Rather than asking whether you need a RM and/or SE tool, ask why you wouldn’t want to keep control of your project operations.
- Ignore Systems Engineering principles and do nothing
- Document using spreadsheets, word processor documents, paper files, cloud drives.
- Invest in an integrated tool
This first choice is hardly an option at all. How do you explain to your customers and stakeholders that you don’t really know what needs doing? You don’t know what the risks or boundaries are? You don’t know what you think you need to do to get to your undocumented goal?
Electronic or paper documents are a great start. They can support a basic set of activities, the skeleton of a process. At the very least you have notes as to what, how and where your project is going. The major problems are:
- Managing complexity
- Recording changes and defining the consequential effects of change
- Recording dependencies between documents and using these dependencies to ensure that consistency, once it has been achieved, is maintained as the information in all documents changes
- Your workload increases enormously as your documentation grows and you must keep each individual element under configuration control and then providing links between each of those documents. How long do you need to spend in that document reference register keeping each need linked to the appropriate design spreadsheet entry……
It is no surprise that we would suggest that an integrated tool as the most appropriate and efficient way to work; to link all parts of your design lifecycle together; provide the means to capture, store and process those requirements; optionally link in system engineering designs; provide full traceability to the output. (Report, document, views etc).
When selecting a tool it is important that it is a good fit for your process. It must meet the needs of your process without being so complex to use that it becomes self-defeating by transferring large amounts of work to manually maintain your documentation set into large amounts of work to manage the complexity of your software tools. This is the main reason why multiple tools can be a substantial drain on your resources, even assuming that you can actually interface the tools to each other.
Cradle can support some or all of your process… it is your choice. You decide which part or parts of your process could be helped by Cradle’s automation, its ability to link and cross reference information, and its ability to automatically track changes. The schema that you build in Cradle reflects how much of your process is Cradle to support, such as to manage and link:
- needs -> user requirements
- user requirements -> acceptance criteria
- user requirements -> system requirements
- system requirements -> validations
- system requirements -> SBS
- system requirements -> functions / behaviour
- SBS -> architecture
- architecture -> functions / behaviour
- architecture -> verifications
- functions / behaviour -> test cases
- test cases -> test results
- These process elements exist in the creation of aerospace / defence platforms, traditionally the main user of these sort of tools and methods. The design of process control systems, and the specification of I&C (instrumentation and control) systems in power plants has many parallels, and this is where we have noticed growth. However, we are pleased to say looking at the detailed data it can be seen that the processes are being applied in a wide range of other situations in so many sectors. The discipline of systems engineering is being applied to great effect to help to manage all their issues in so many industries. We build Cradle to try to automate and simplify the application of these systems engineering techniques, no matter what industry you are working in. Cradle provides our customers with the functionality giving them RM and SE power at their fingertips.
Still not sure whether you could benefit from an RM / SE tool? We’d be more than happy to discuss your projects and processes and make a recommendation. Book a webinar now.
Play video on YouTube