When we're talking about system engineering, we're generally talking about "The big three ideas for System Engineering":
- Requirements
- Architecture
- Validation
Let it be said: We're from System Engineering, and we're here to help.....
Really? What can SE do for we agilists?
- Requirements: It's true that SEs are accustomed to structured analysis, decomposition, and lots of 'shalls' and 'wills'. Nonetheless, motivation to do requirements -- to develop not only a narrative from the many disparate statements, but to also fashion an architecture that supports the whole collection of requirements -- fits the agile need nicely.
The big transition for SEs is making the move from a traditional 'shall and will' project to an agile project of conversational style requirements. Now admittedly, some SE can't/won't make the transition, but others will, and their skills are very applicable
SEs are good at elicitation, modeling, risk assessment, and logic... all necessary ingredients when working with use cases and user stories. Hopefully, you're familiar with some of Scott Ambler's stuff on agile modeling, etc... all system engineering, all day.
- Architecture: A close cousin to requirements is architecture -- structure, interfaces, large scale design, and interrelationships. The big deal here is allocating requirements to the major objects, defining the object relationships, and adjudicating conflicts that would compromise coherence, cohesion, redundancy, and diversification.
- Validation: Validation -- checking things with the customer -- is not that much different, except for timing: more early and more often in agile compared to the traditional. But why SEs in the validation? Mostly, to bring the big picture and largest scale to validate the architecture (lower level validation is largely a team effort with various layers of release tests and integration tests). Such big picture stuff reassures the sponsor, gets marketing fully on board, and if there's to be manufacturing or post release support, then those entities can get on as well.
You've probably seen this V-model if you're a regular reader. It's basically the SEs view of how the project comes down. Validation just completes the loop with the original narrative (shown here as the Concept of Operations)
Check out these books I've written in the library at Square Peg Consulting
