R/Systems_engineering - Question About Responsibilities of Systems Engineer

@tags:: #lit✍/📰️article/highlights
@links::
@ref:: R/Systems_engineering - Question About Responsibilities of Systems Engineer
@author:: reddit.com

=this.file.name

Book cover of "R/Systems_engineering - Question About Responsibilities of Systems Engineer"

Reference

Notes

Quote

Quote

Iteration Zero (or Sprint 0)Behavior: Old School engineers would tell you to start with a CONOPS with reference scenarios. The more modern approach is Epics, Use Cases, and User Stories. Sketch out a hypothetical mission for your underwater robot to execute that includes power up, launch, underwater operations, recovery, power down, and maintenance. How the does robot interact with people, other robots, fish, underwater objects? Now you have some idea of the behavior of the system.Architecture: From that set of behaviors, you should be able to sketch out your first high-level Architecture. You know it needs a water-proof body, a control computer, and power system. Does it need a grapple arm? A radio controller? A camera? lights?Interfaces: There will be logical interfaces between the architecture components. Which ones are physical? Which ones will require data schema?Requirements: Now that you have behavior, architecture, and interfaces - start identifying requirements. (or, ask yourself if the detailed model itself is sufficient)Model Development Plan: Create a list of work to be done (or a backlog.) You wont know all of the details but you can start with the big chunks. Perhaps Use Cases are the natural dividing line between chunks. Which use cases will be modeled first? Which models will need to come later? What can be done in parallel by allocating to separate teams?Schedule: start with a high-level roadmap. You know the start/end of the whole project. Fill in the release plan. When will the initial phase (iteration zero) be completed? Which Use Cases will you start with?Teams: If you must have separated teams, you can be the chairperson of an Integrated Product Team that meets periodically with sub-IPTs for various disciplines (electrical, mechanical, operations.) Or, if you use a sprint planning process this could be a sprint review. Either way, the teams are reporting and demonstrating their progress regularly.Iteration one (Sprint 1) - refine the specIteration two (Sprint 2) - refine the spec. (Rel Model v1.0)
- No location available
-


dg-publish: true
created: 2024-07-01
modified: 2024-07-01
title: R/Systems_engineering - Question About Responsibilities of Systems Engineer
source: hypothesis

@tags:: #lit✍/📰️article/highlights
@links::
@ref:: R/Systems_engineering - Question About Responsibilities of Systems Engineer
@author:: reddit.com

=this.file.name

Book cover of "R/Systems_engineering - Question About Responsibilities of Systems Engineer"

Reference

Notes

Quote

Quote

Iteration Zero (or Sprint 0)Behavior: Old School engineers would tell you to start with a CONOPS with reference scenarios. The more modern approach is Epics, Use Cases, and User Stories. Sketch out a hypothetical mission for your underwater robot to execute that includes power up, launch, underwater operations, recovery, power down, and maintenance. How the does robot interact with people, other robots, fish, underwater objects? Now you have some idea of the behavior of the system.Architecture: From that set of behaviors, you should be able to sketch out your first high-level Architecture. You know it needs a water-proof body, a control computer, and power system. Does it need a grapple arm? A radio controller? A camera? lights?Interfaces: There will be logical interfaces between the architecture components. Which ones are physical? Which ones will require data schema?Requirements: Now that you have behavior, architecture, and interfaces - start identifying requirements. (or, ask yourself if the detailed model itself is sufficient)Model Development Plan: Create a list of work to be done (or a backlog.) You wont know all of the details but you can start with the big chunks. Perhaps Use Cases are the natural dividing line between chunks. Which use cases will be modeled first? Which models will need to come later? What can be done in parallel by allocating to separate teams?Schedule: start with a high-level roadmap. You know the start/end of the whole project. Fill in the release plan. When will the initial phase (iteration zero) be completed? Which Use Cases will you start with?Teams: If you must have separated teams, you can be the chairperson of an Integrated Product Team that meets periodically with sub-IPTs for various disciplines (electrical, mechanical, operations.) Or, if you use a sprint planning process this could be a sprint review. Either way, the teams are reporting and demonstrating their progress regularly.Iteration one (Sprint 1) - refine the specIteration two (Sprint 2) - refine the spec. (Rel Model v1.0)
- No location available
-