Systems Engineering ‘in the small’

In software engineering, you can think of two levels: micro-level and macro-level.

On the micro-level, this is systems engineering ‘in the small.’  On the macro-level, there’s systems engineering ‘in the large.’

The two levels are complimentary. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about systems engineering ‘in the small.’

Key Takeaways

Here are key takeaways:

• ‘in the small’ activities is micro-level systems engineering whereas ‘in the large’ is macro-level systems engineering.
• Systems engineering ‘in the small’ and systems engineering ‘in the large’ are complimentary.
• Systems engineering ‘in the small’ activities fit within systems engineering ‘in the large’ activities and phases.
• Systems engineering ‘in the small’ activities include: User Requirements Definition, System Requirements Definition , System Design/Architecture, Preliminary Design , Detailed Design , Implementation, Test and Integration , Acceptance and Certification

Systems Engineering ‘In the small’ Activities

Alexander and Maiden identify the following systems engineering ‘in the small’ activities:

• User Requirements Definition (URD)
• System Requirements Definition (SRD)
• System Design / Architecture (SD/A)
• Preliminary Design (PD)
• Detailed Design (DD)
• Implementation (Imp)
• Test and Integration (T&I)
• Acceptance and Certification (A&C)

Systems Engineering ‘In the small’ Activities Explained

Alexander and Maiden explain the key systems engineering ‘in the small’ activities as follows:

• User Requirements Definition (URD) – The process of finding out who the users are, what they do, and what their needs are.
• System Requirements Definition (SRD) – The process of finding the constraints  that have to be applied to the system acquisition process to obtain a fit-for-purpose result.  The system constraints can include detailed functional behavior, legislation, regulations, standards, technical interfaces, environmental and physical.
• System Design / Architecture (SD/A) – The overall shape of a compliant solution is worked out.  Principal subsystems are identified and their individual requirements flowed down and refined.
• Preliminary Design (PD) – Carry out sufficient design to provide confidence that the flowed-down system requirements are achievable at subsystem level.  It often concludes with a Preliminary Design Review (PDR).
• Detailed Design (DD) – Carry out sufficient design to support implementation.  It should provide confidence that subsystem flowed-down requirements will be met.  This activity should be concluded with a Critical Design Review (CDR).
• Implementation (Imp) – Here the subsystem designs are implemented using the relevant technologies, and tested at subsystem level.  Testing should determine that flowed-down requirements have been met.
• Test and Integration (T&I) – During this activity, the individual components come together for testing as an integrated whole.  Compliance with the user and system requirements should be demonstrated.
• Acceptance and Certification (A&C) – This activity is when the user community or their representatives take a tested and integrated system and confirm that what has been built is indeed what was wanted.  In highly regulated and/or high-integrity applications, this will involve approval by the appropriate certifying bodies.

You Might Also Like

4 Reasons Why Defining an Effective Software Process is Tough
A Process for Generating a Software Process
Waterfall, In the Large, and In the Small