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
[…] Engineering ‘in the small’ Posted in June 22nd, 2008 by in Uncategorized Systems Engineering ‘in the small’ Preliminary Design (PD) – Carry out sufficient design to provide confidence that the flowed-down […]