From my experience, requirements don't come from bottom but it should. Initiator is almost always manager who might have some idea or vision but it's not right originator. And this is the main issue. He is trying to remove outward manifestation not root cause. Employees are always struggling with deeper issues than manager is trying to solve.<p>Practical example: I am working with huge amount of data about customer's network infrastructure. Every item (device/contract/ticket) has own web page. There is huge items with wrong or dummy data. If I need report, verify and amend certain data i can't do it via bulk requests or automatically. Our application doesn't have such interface, we don't have API, we don't have CLI. I did talk to architect and he said me...no, we don't have it, and you are the first one who asked for it. Nobody need it. So sorry but no.<p>Another example: internal tool, have some features but are wrongly implemented. I reported that it doesn't work as expected. I received reply that nobody use it, so there is no chance to get resource for fix and improvement.<p>And another one...manager bring idea with time saving and required new internal tool which will do automatically sign-in to all day-to-day tools. It saved almost 5 minutes. But after password change it very often locked users account. In total it wasted few hours of raising incident with internal IT.<p>And I have lot of similar experiences. So from my point of view here are key features for corporate internal tools:<p>1) If tool or function doesn't work - hide it or remove it<p>2) If documentation is available - do it properly. Have some documents with terminology explanation. Explain purpose and dependency between fields. Also explain what is mandatory and why. This is whole story how can proper documentation save your time and money. Everybody need to understand what they use and why they have to fill field A, B, C and optionally D. You can save a lot of time, money and issues, especially with newcomers. This documentation can be studied at any time during future work. You can avoid misinterpretation from older colleague etc.<p>3) If tools are developed always talk to end user not only with manager. Ask 5 times why should we solve this? Isn't the real issue somewhere else?<p>4) Internal tools always needs to be supported from management. Otherwise is very small chance that your effort will be appreciated.<p>5) If you create tool have CLI version. GIU is some kind of protection against stupidity but it also restrict improvement and speedup of whole process.<p>6) If you work with data, use standardized format like csv, xml or json. Same format needs to be used for import and export. If other internal tools use csv don't use xml or json and vice-versa.<p>7) Other internal tools have to be able work with same format. Export from tool A have to be applicable (or with small amendment, no more than several clicks/removal and copy-paste actions) into tool B. So your format what is standardized for other tools.<p>8) Don't use insane level of nested features and choices. Something like Audit-> Results -> Failed/Succeeded -> Details/Settings/Re-run -> (Details) Result/Rule/Config/History -> (Result part) Output: " Filed X, Y, Z wasn't find in config" ... and you are thinking wtf? Why? And you have to open different window and verify it manually. I need to know what was found and why it didn't match. Very often is due to wrong regexp pattern, but it take almost 30 minutes to verify all possible paths and find root cause.<p>9) Use universally applicable language/environment. From my experience you create something which works at computer/server A but it will fail on computer/server B.<p>And there are tons of other issues I dont remember. Some of them are technical (software/system/hardware) some of them are social - people/management. I would say social issues is much harder to overcome than technical. Social issues are also more important, because if it fail to solve, entire project/tool can be damaged. Technical issues can be solved almost every time. If solution A doesn't work we can create B, but we always solve it.