Timeline for Best practice to break-down requirements & architecture
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 31 at 2:56 | comment | added | Flater | My take on this question is that you've abstracted this process too far. There is no universally correct objective answer to how to break down each and every possible requirement without considering the context of those requirements in and of themselves. There are general tips and advice, but as with most things, it requires a degree of context and nuance in order to figure out what actually works in your given scenario. Reducing this down to an abstract discussion on a recurring nesting of faceless numbered levels is not a productive approach to learning how to break down requirements, IMHO. | |
| Oct 30 at 0:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 29 at 22:55 | answer | added | Adrian K | timeline score: 0 | |
| Aug 21 at 7:14 | comment | added | JosF | The complete set of documents belonging to the standard is still available at abelia archive. Look e.g. at the SSDD to see the contents of a design conform the MIL_STD-498. According to the standard the design is a complete elaboration of the requirements and therefore belongs at a lower level. | |
| Aug 19 at 7:18 | comment | added | felipe | @JosF Thanks for the reference, I will take a look. But I didnt get what you mean by "more than an architecture model". What else could this design contain? And why develop the Level N requirements at Level N+1 and not at Level N itself? Which would lead to the fact that Level 0 Design contains nothing or doesnt exist, right? | |
| Aug 19 at 7:15 | comment | added | felipe | @ThomasOwens as mentioned by Bart van Ingen Schenau, the levels are generically represented because we have at least 10 levels, since the system is big enough and has mechanics, electronics, SW, FPGA and so on. The "refine" relationship is just because it comes from SysUML (Enterprise Architecture) but it normally should be the relationship of "decomposes to" | |
| Aug 15 at 12:08 | comment | added | JosF | You could have a look at MIL-STD-498 or its successors. The essence of this methodology is that requirements at level n are developped into a design at level n + 1 (which contains more than just an architecture model) for which requirements can be written at level n + 2, etc. This was once considered best practice. | |
| Aug 15 at 7:08 | comment | added | Bart van Ingen Schenau | @ThomasOwens, If it works for your understanding, you can map Level 0 and Level 1 respectively to System and Subsystem/Component. The numbered levels start to get an advantage when you are building a system-of-systems and there are three or four levels of requirements before you can even start to make the distinction between hardware and software requirements. | |
| Aug 14 at 17:32 | comment | added | Ewan | yeah, you need to put your level 0 etc in the context of some system of architecture planning for it to make sense. Level 1 requirements? | |
| Aug 14 at 15:55 | comment | added | Thomas Owens♦ | I don't understand the "refine" relationship between the Level 0 and Level 1. Perhaps it's because I don't understand what "Level 0" and "Level 1" are. In my experience, I would call Level 0 "System" and Level 1 (and lower) would be "Subsystem" or "Component". The relationship would not necessarily be "refine", but requirement would be allocated to subsystems or components and have various types of decomposition and refinement performed. | |
| Aug 14 at 14:31 | review | Close votes | |||
| Aug 26 at 3:07 | |||||
| Aug 14 at 13:27 | history | asked | felipe | CC BY-SA 4.0 |