S/W pre-requisites - some thoughts

Security :
There is plenty of evidence that designing a security model as an afterthought and an add on to existing software is a recipe for problems down the road - and the received wisdom is that security should be designed into your systems and application from the start. There is a stark difference between the security models for Windows where it is relatively easy for non-priveleged applications do priveleged things (e.g. install or overwrite other applications) without any further user interaction ; vs the models for Unix and Linux where a priveleged action requires a definitive user interaction and confirmation (and in most cases the admin/root account is disabled). The Security model prevalent under MS Windows is widely regarded as the primary reason why Malicious software is so prevalent on that platform - it is far too easy for an application to get priveleges and get control, and many otherwise well written legitimate software require admin priveleges to be installed and operate correctly. If Windows had a Unix/Linux like security model then the Malware for it would be significantly curtailed - regardless of the market share, as simply put the opportunity to infect a platform would be significantly reduced simply because the act of infection itself would need to have user confirmation.
Ideally your security model for your application should cover the following areas :

• Authentication - who is using the application.
  
• Authority - does the person using the application has the priveleges to do what they are trying to do.
  
• Audit - Is a record kept of who does what to particular items of data.
  
• Integrity - is the data kept intact both under normal operations and in the case of errors, faults and crucially upgrades.
  

Allied to these principles are the topics of confidentiality - making sure data is not shared with people or systems who don't need to know - which is both a people problem and a systems problem), and availability - making sure that the right people or systems have access to the right data when they need it.

Reporting and Data extraction
In business targetted applications there is a strong argument for designing data extraction and reporting capabilities in the first release. There are plenty of cases where by an application is heavily used but where the actual reporting capability is inadequate, leading to potentially a number of different problems :

Key data items get re-keyed into spreadsheets or other applications in order to provide the level of granularity and analysis required by the system users and demanded by their senior managers (normally the same senior managers who mandate the use of the application in the first place - probably in the name of standardisation). This re-keying can lead :

• A proliferation of different spreadhseet styles, formats and analysis - breaking the golden rule of standardisation.
  
• Synchronisation issues between the manual data collected and the data collected on the "official" system leading to confusion over the accuracy of the various data sources.
  

Limited adoption of the main system. Users pay lip service to the system and the work flow it supports, as they know that the "value" of any detail they record is limited as they can't extract, analyse or report on it.

To mitigate against these issues there must be thought and effort given to the production of reporting and extraction capabilities in the very first release. Producing a fully customisable reporting and analysis suite within an application is potentially time consuming and complex activity (especially as it is likely to be unknown what analysis will be needed) but an application should as a minimum support a data extraction tool where by a user with the minimum of training can extract relevant data into a standard format. Not only would this solve the problems of synchronisation (no more re-keying of data), it woud improve the take up of the system as there is now value in keeping all the key data in one place. It also enables users to very quickly generate the anaysis and reports that they need using tool sets they are already familiar with. As an added benefit, there is a level of innovation from these "offline" analysis tools, which can be used to feedback into future requirements in the core systems.

Searching and browsing
Any system which contains a lot of data will need a decent search and data browsing capability, and the need for this should be recognised in the first release, even if those requirements cannot fully realised - or are not cost effective (due to the low initial volumes of data or end users). Design decisions (particularly in the area of data storage) should be taken in the light of the need to provide search capbilities.
Once the volume of data rises beyond more than a few key records per user, if a search capability does not exist then those users will user other tools (spreadsheets, notebooks etc) to keep their own index - leading to similar synchronisation problems explored above.