3 ms·

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do an

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.

vonmoltke 10y ago
There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces. Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
- qwertyuiop924 10y ago
  Huh. Fair enough. I wasn't really thinking quite like that, but that is true
king_magic 10y ago
Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.
- qwertyuiop924 10y ago
  I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
  - king_magic 10y ago
    And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.
    - qwertyuiop924 10y ago
      And I... Kind of agree? :). You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet. >It's not "certainly less complex". The total complexity of the system is still the same. The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze. So, I assume that this something you agree with. In which case, congrats, you've convinced me.
      - collyw 10y ago
        How is it reduced if you have everything needing to communicate back and forward? Sounds like more complexity to me.
        qwertyuiop924 10y ago
        The components aren't necessarily separate apps, but even if they are, that problem has been solved many times over. Take your pick: HTTP, raw sockets (TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory, pipe(2) (and friends), hell, even message queues and semaphores, if you hate yourself...
- Ace17 10y ago
  Sorry, I couldn't help myself :-) http://e-venue.org/wp/ignore-the-real-world/ http://e-venue.org/wp/ignore-the-real-world/

vonmoltke 10y ago

There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces. Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.

qwertyuiop924 10y ago
Huh. Fair enough. I wasn't really thinking quite like that, but that is true

king_magic 10y ago

Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.

qwertyuiop924 10y ago
I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
- king_magic 10y ago
  And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.
  - qwertyuiop924 10y ago
    And I... Kind of agree? :). You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet. >It's not "certainly less complex". The total complexity of the system is still the same. The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze. So, I assume that this something you agree with. In which case, congrats, you've convinced me.
    - collyw 10y ago
      How is it reduced if you have everything needing to communicate back and forward? Sounds like more complexity to me.
      - qwertyuiop924 10y ago
        The components aren't necessarily separate apps, but even if they are, that problem has been solved many times over. Take your pick: HTTP, raw sockets (TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory, pipe(2) (and friends), hell, even message queues and semaphores, if you hate yourself...
Ace17 10y ago
Sorry, I couldn't help myself :-) http://e-venue.org/wp/ignore-the-real-world/ http://e-venue.org/wp/ignore-the-real-world/