If you are providing a solution, and not just writing some code, you have to consider many things.
Are you writing software or delivering a system? This question is intended to be rhetorical.
If you are delivering a system,
It operates in an environment.
There are interoperability requirements.
There are maintainability requirements (Upgrade, Configuration Validation, Commissioning & Decommissioning).
There are performance requirements (fast enough to be worth using)
There are reliability requirements.
[In the embedded space, power outage is a common occurrence.]
I used to ask a power outage question when I was interviewing for software engineers to work on critical systems.
A journaling File system and TWO copies of critical, files that get written to covers a multitude of sins.
If the power goes out, your system should act appropriately.
If the OS is capable of supporting all your reliability requirements, that is great.
If the Hardware is capable of supporting all your reliability requirements, (One good answer to my power outage question was "Get a UPS") that is great.
Sometimes engineering has to happen to make reliability.
Customers often fail to specify things in requirements, then might not pay until the product fits their initially un-stated requirements. Requirements elicitation and requirements validation can make life much easier for software engineers. Look at the (FREE!) CMMI standard for an idea of what those activities might encompass.
If you are a programmer TL;DR Someone else does it.