California Division | Federal Highway Administration

3.5.3 Component Level Detailed Design

OBJECTIVE:

Component Level Detailed Design is the build-to design of the hardware, software, and selection of commercial-off-the-shelf [COTS] products. For software development, this is the step where the software documentation is being prepared for coding. For hardware, it is the step where logic schematics, chip layout, and artwork are being prepared for fabrication. If COTS equipment is being used, this step is where alternative candidate products are evaluated and a selection is made.

DESCRIPTION:

Component design for software, hardware, communications, and databases describes HOW the components will be developed to meet the required functions of the system in great detail. For computer programs, this will describe the software in enough detail so the software coding team can write the individual software modules. For hardware, this step will describe the hardware elements in enough detail to be fabricated or purchased. This level of detail is best performed by the development team who writes the software code, designing the hardware and communications, then manages the design and development process starting in this phase to the end of the development of the software and hardware. Systems engineering supports this activity by monitoring and reviewing the detailed design process and clarifies the requirements when needed. Systems engineering is involved in the periodic technical reviews during the component design process. At the completion of this step, the system’s owner and stakeholders will have a Critical Design Review to review and approve the “build-to” design.

CONTEXT OF PROCESS:

COMPONENT LEVEL DETAILED DESIGN PROCESS

Inputs:

Concept of Operationsdocuments the users’ needs and expectations, and provides a description of the way the system is intended to work.

System Requirements provide the designer with the overall requirements of the system. Each of the system requirements should be traceable to a sub-system element.

High Level Design [Project Architecture] identifies interfaces and sub-system performance requirements.

Sub-system Requirements that each designed component should trace to.

System and Sub-system Verification Plans provide added information on how the system and sub-system is to be verified. This will assist the designer in designing the components and developing the component verification procedures.

COTS products relevant to the project that will be candidates for evaluation and selection for the project.

Control:

Project Plan/ Systems Engineering Management Plan [SEMP]defines the plan for how the detailed design work will be carried out. Progress of the design work activities should be monitored against this plan.

Configuration management [CM] process should have been defined by the development team and approved by the system’s owner. At this step Developmental Configuration Management is used. The Developmental CM must fit into the systems owner CM plan.

Risk management is used to monitor, control and mitigate design risks [e.g. technology and/or constraints].

Enablers:

Trade studiesare used to analyze and compare alternative COTS products, detailed design alternatives and their associated impacts on the system.

Technical reviews are used to identify defects, conflicts, and missing detailed design requirements to ensure that the component design is addressing all of the sub-system requirements and is fit for the intended purpose.

Traceability of detailed design elements to the high level design elements to ensure completeness

Outputs:

Selected COTS products and applications are the results of the evaluation of COTS products. Ideally this is done as late as possible in the timeline to provide the latest technologies at the best price. Sometimes, however, this may have to be done earlier because of legacy systems or internal standards.

Approved Component Level Detailed Design is now ready to move forward to implementation.

Unit Verification Plan is used to verify that the components work as designed.

Process Activities:

Evaluate commercial off-the-shelf products and applications [COTS]

The stakeholders must be involved in the review of any gaps between the requirements and the COTS product specification. If there is a gap then the stakeholders should decide whether to use the COTS product with a deviation from the requirements, modify the product, or develop a custom application or product.

Detailed Design

This process is performed by the development team, who will be generating the application software and integrating the hardware, databases, and communications with these applications. The development team will use a variety of techniques and tools based on the development team’s approach to development, such as coding languages, methodologies, and design tools.

Perform technical reviews [performed in accordance with the SEMP]

For design status: evaluation of the candidate solutions or COTS products, technical reviews should be held on a periodic basis to review the progress of the design or selection of COTS products.

Perform critical design review [CDR] [performed in accordance with the SEMP]

At the completion of the detailed design stage, a final “build to” review is held with the Stakeholders. The purpose is for the development team to get final approval of the design prior to starting the implementation of the solution. Component design through software development to unit test is the domain of the software, hardware, and database specialist of the development team. The systems engineer needs to be able to translate user requirements in the language of these disciplines. For example, if software engineering is using UML methodology, the systems engineer needs to interface between the user needs, systems requirements, and the software engineer to ensure that the design accurately reflects the intended purpose.

Where does the Component Level Detailed Design take place in the project timeline?

Is there a policy or standard that talks about Component Level Detailed Design?

The FHWA Final Rule does not specifically mention component level detailed design practices to be followed. For software, IEEE/ISO 12207 Software Life cycle process provides specific process guidance.

Which activities are critical for the system’s owner to do?

• Participate in the technical reviews
• Participate in the evaluation of COTS products
• Participate in the critical design review
• Approve the detailed design when completed
• Gain stakeholder support for the design

How do I fit these activities to my project? [Tailoring]

This activity is driven by the amount of custom development needed for the project. The more customized the development, the more effort there is at this step. For small systems that contain nearly all COTS products, the primary activity is the evaluation of these products.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

• Changes to requirements [High Priority, Cost, and Risk] due to detailed design activities. Changes lead to increased cost and increased technical risk. The goal is to minimize changes to requirements
• Incomplete design leads to increased technical risk and increased cost. The goal is to review and track the number of requirements that have been completely designed

On the project management side:

• Number of completed designed components per schedule and development plan. The goal is that completion rate of designed components should match or exceed the plan prediction

Checklist: Are all the bases covered?

Did each component have a technical review?

Did each component design trace to a sub-system requirement?

Were all sub-system requirements satisfied by the component design activity?

Was a verification plan for each component defined?

Was each component design checked for performance?

Was the component design documentation complete, up to date, and accurate?

Was a critical design review conducted?

Was an alternatives analysis done on the COTS products used in the system?

Have all system and sub-system requirements been updated at the time of the critical design review?

Are there any other recommendations that can help?

It is recommended that the development team who will be doing the software development also perform this component design activity. This continuity between the component design and development is critical.

Be sure that the development team has documented processes for developing software and hardware, and that they can share this information with the team. Some development teams will be reluctant to share this information for fear of revealing this information to their competition. If so, it may require that a non-disclosure agreement be in place. But it is important to review the development processes and have it as part of the Systems Engineering Management Plan.

Component design tools are essential for component level detailed design and there are many on the market. Each development team will have their favorite set of tools. These tools will be driven by the vendor of the tool, and the process that the development follows. This is especially true for software development.

If this is a custom development, request all tools at the completion of development. This will ensure that the system can be maintained and upgraded with or without the current development team. The tools that are used in the component design activity need to be carefully documented. If the project paid for these tools they need to be transferred to the system owner with all modifications, upgrades, and instructions on how they were used during the design activity. That way the development environment can be replicated for future modifications.

A closer look at software component design and development – Software design is unique relative to other disciplines, such as hardware or mechanical detailed designs. At the component level, it is tightly linked to the actual coding and implementation phase and there is a higher degree of interaction between the two phases of work. The software process parallels the systems engineering process to a high degree as illustrated below. The team’s development process should address each of the steps below. During the software design, the developer will use the system level documentation, such as the system concept of operations and system and sub-system level requirements, and revisit these from a software point of view. This is an important process if the software development team has not been involved with the system level concept of operations, or system level or sub-system requirements. In the software development environment, prototyping and spiral development methods are important tools for defining requirements. For example, prototyping graphical user interfaces for workstation will allow the stakeholder to discover features and functions that they will like or dislike before software coding. This, I KNOW IT WHEN I SEE IT [IKIWISI], is a powerful tool for software developers [see illustration below].

Figure3‑10 Spiral Software Development in Context with the Vee