This is part 2 of a 2 part series

Investing in a Tool

An SE or RM tool is an important part of a successful project; however, organizations often select a tool without a clear understanding of their SE process (or lack of one) and may have unreasonable expectations about what it can do. This scenario can also result in trying to shoehorn development to fit the tool, resulting in unnecessary work. Prior to choosing a tool, there are several aspects that need to be evaluated. The process leading up to tool selection and putting it to use will take time, so it’s important to plan accordingly.

First, SE teams should perform a trade study on what functions are needed from the tool. They should have an understanding of what it will take to install, maintain and support, and to what extent IT teams need to be involved. Newer tools are cloud-based and may require less IT involvement than older server-based tools. There will be a need to have someone responsible as a tool administrator to maintain it and add functionality as needed. There should also be at least one subject matter expert available to support team members. These support roles can reside either internally or externally; many tool vendors provide support as part of their offerings.

Organization size will often drive some aspects of initial tool selection, and it is important to keep expansion in mind with the expectation that SE and RM practices will be rolled out to other projects and teams. Having everyone using the same tool facilitates familiarity and collaboration.

Training and integrating the tool into the organization is another facet that requires forethought. There must be a sufficient investment in time and training resources to ensure that team members accept the tool, become proficient in using it and incorporate it into their daily work.

Because of the significant organizational impact of adopting SE, RM and an associated tool, it is advisable to identify a pilot project to demonstrate the new approach and tool. The ideal scenario is a development process that is not in the critical path, but which can be folded into the main development effort once it’s been proven out. Planning for the pilot should take into consideration what it will take to scale the SE effort, RM and the selected tool.

Tool advantages. The right SE or RM tool can offer several advantages. First, a tool provides a configuration management process, either as part of the tool or by supporting the organization’s own existing process. Organizations need to ensure that only approved changes are made and a tool provides a level of security that changes can’t be made without the appropriate permissions.

Revision tracking and history keeps track of what was changed in the past and provides the ability to recover previous work in the event of a problem. Most tools allow creation of a baseline that can be reverted to if necessary.

Tools support allocation of requirements from top level to lower level documents, and allow standards to be incorporated by having them available within the tool so they can be linked from anywhere in the project. Linking and tracing functionality is critical, as it makes sure that all upper level requirements are addressed in the design, and that it can be proven that everything has been properly allocated and tested. The tool captures verification and validation planning, stores results and can link the plans and results to requirements, providing a complete picture of everything that’s been done.

Finally, and one of the most important advantages, is the ability to see the impact changes will have. It allows individual team members to see items that are linked and understand that if a particular item is changed, it may impact multiple other requirements. The single change may flow down and require a much greater amount of time and money to address than expected.

 

Planning and Implementation

Up-front planning is critical for successful SE and RM adoption. Processes and standard operating procedures need to be developed for use by the SE team and anyone doing requirements management so that everyone understands the way things are supposed to be done.

The lifecycle of requirements needs to be addressed, from initial release to delivery to customers, and taking into account changes that can occur both during the design phase and after a product has been delivered. Requirements may need revising due to changes in technology, customer expectations, standards, or other factors.

Processes need to be rolled out to the entire organization and understood by all design teams because everyone should be using the tool, processes and procedures. Done correctly, use of the tool will not be limited to systems engineers; it will provide a central repository for the entire design process that aims to eliminate the circulation of one-off documents.

Organizational factors must be given serious consideration. There will be changes to existing processes and resulting schedule impacts as the new processes and tool is implemented. Team members will need to have the time and resources to learn the new methods, and as they are rolled out, there are likely to be iterative changes to the new processes.

Once the new processes and tool have been implemented, it is important to uphold a policy of no waivers. For the new approach to be successful, all the projects in the organization need to be using the tool and SE process for the entire lifecycle of the product.

 

Moving Forward

An organization’s success is driven by having requirements that are clear and verifiable, traced to user needs, linked to all subsystem requirements and changes that are controlled and managed. Embracing SE practices and formal RM, along with choosing the right tool, can provide significant benefit to the product development process.

There must be unwavering support for whatever tool is selected, with a firm plan for tool administration and support to make sure it is always kept up to date. Likewise, the SE team needs to be fully supported with training, standard operating procedures and opportunities to continue to grow the system. Some examples are adding capabilities such as MBSE or making sure that new team members are fully trained on the use of the tool and the expectations to use it. With the right level of commitment, SE expertise, tool selection and training, development organizations can more effectively deliver high-quality products that meet stakeholder expectations for greater project and company success.

Paul Kostek

Paul Kostek

Advisory Systems Engineer

Paul is an Advisory Systems Engineer with Base 2 Solutions in Bellevue Washington. He has worked in a variety of fields such as aerospace, defense, medical devices and e-commerce. He is Experienced in requirements, architecture, risk management, interface definition, verification and project planning.