4 ms·

In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements ar

In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. You can't escape the business logic that needs to be enabled. It's like the old service industry joke "this job would be great...if it weren't for all the customers". There would be no software if there weren't a set of requirements.

coldtea 7y ago
>In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. It's not that clear cut. For me "Essential" is what captures the essence of the problem domain and the requirements in actual use. On top of that, there are lots of "requirements" that are there due to bribes, idiotic "brainstorming" where everyone felt obliged to chime in, what the CEO's spouse things should certainly be there, recent fads, over-thinking it from some execs, etc. The distinction between the "essential" is of utmost importance. First, because these "required but not essential" area is where an engineer can look for tradeoffs (to the benefit of essential areas). Second, because those items might hamper the essential functionality (like a requirement to build a website in C, because the CEO heard "it's the fastest language", can hurt security, maintainability and other aspects, or the requirement to make a banking webpage with small fancy grey on white fonts because they though the design is "cool" hurts readability). Third, because engineers should not just operate on a "follow orders" basis. They also have an ethical responsibility towards the final users (society at large for public software, customers, the customer's employees, etc). And, of course, because not being able to make that distinction, means that the engineer can't tell good from bad, useful for useless, and it's all the same to them. Whether they can convince the customer it's another thing. But engineers should absolutely be able to make the distinction. >There would be no software if there weren't a set of requirements. Which is neither here, nor there. There would also be a hell of a lot of better, faster, more reliable software, if bogus requirements would get pointed out, and removed.

coldtea 7y ago

>In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. It's not that clear cut. For me "Essential" is what captures the essence of the problem domain and the requirements in actual use. On top of that, there are lots of "requirements" that are there due to bribes, idiotic "brainstorming" where everyone felt obliged to chime in, what the CEO's spouse things should certainly be there, recent fads, over-thinking it from some execs, etc. The distinction between the "essential" is of utmost importance. First, because these "required but not essential" area is where an engineer can look for tradeoffs (to the benefit of essential areas). Second, because those items might hamper the essential functionality (like a requirement to build a website in C, because the CEO heard "it's the fastest language", can hurt security, maintainability and other aspects, or the requirement to make a banking webpage with small fancy grey on white fonts because they though the design is "cool" hurts readability). Third, because engineers should not just operate on a "follow orders" basis. They also have an ethical responsibility towards the final users (society at large for public software, customers, the customer's employees, etc). And, of course, because not being able to make that distinction, means that the engineer can't tell good from bad, useful for useless, and it's all the same to them. Whether they can convince the customer it's another thing. But engineers should absolutely be able to make the distinction. >There would be no software if there weren't a set of requirements. Which is neither here, nor there. There would also be a hell of a lot of better, faster, more reliable software, if bogus requirements would get pointed out, and removed.