• Better, Faster, Lighter Java
• Bruce A. Tate & Justin Gehland
• Publisher: O'Reilly
• ISBN: 0596006764
• Copyright © 2004, O'Reily Media, Inc.

I'm not sure I agree with the industry standard use of the term "technical requirements" because I was trained that there are no requirements without understanding the costs associated with the item. But it is a good idea to ask questions about requirements or desires or needs or whatever term makes sense in the context.

What are your external interfaces?

External interfaces are on obvious starting point for several classes of early decisions. An external interface is one that you can not fully control. Interfaces that cross major boundaries (such as programming lagnuages, networks, firewalls, operating systems, etc.) need special considerations. You need an explicit strategy for dealing with each before moving forward.

Who is your user?

In the early design states, look at your user interface as one more extrenal interface. A professional data entry cleark has more demanding requirements than an occasional departmental user. Supporting existing clients also dictates requirements.

What are your physical deployment restrictions?

The existing systems have major impact on the possibilities for new systems. You want to sanity-check compatibility at every turn.

What are your database requirements?

Depending on the application, you may or may not decide to treat the database as just another distributed interface. In many applications, the database is too important to be considered as incidental. It is often the key to the application success. You need to decide on a persistance strategy early in the design process. There are many key questions such as:

• Do you want to design the database usage so that the database engine (Oracle, MySql, SqlServer, etc.) can be replaced without a complete redesign.
• Is using an open access method such as ODBC or JDBC sufficient?
• What policies do you want for use of stored procedures? Triggers? specific report writing tools?
• What scaling and caching is appropriate for the database?
• Who owns the schema?

What components must/might you reuse?

The holy grail of software for the past 20 years has been reuse. With new systems, this breaks down into two separate areas:

1. What existing components do you want to use?
2. What components developed for this project are likely candidates for reuse in the future?

Be careful, reusing components is hard and may outweight the benefits claimed. Similarly, designing and developing components for reuse is very hard; so hard that doing so may make the current project infeasible.

What is your security policy?

While is it frequently thought of as an add-on service, proper security has to be built into the system. Some implementations are much easier when designed into and tested along with the system. This requires carefull consideration of the user community and the threats and attacks (along with the liabilities) that must be supported.

How fast does it need to be?

It is easy to waste large amounts of money over-engineering system's performance. It is also fairly easy to build systems that perform so poorly that they are unusable. The proper sizing of load, performance expectations, scaling, is critical for success.