The best option is probably to take an existing template or two (for purchase - also found in the appendices of Software Requirements) or three and tailor them. Remove sections that are irrelevant to your needs or add new sections that you like from one template into the rest of another template. Merge sections together if that makes sense. When combined, these would probably cover every possible type of question that might be asked, it's just a matter of filling in the details where they are needed.
Tailoring would make it not match templates by major standards organizations, but tailoring is a key component of process improvement and deployment programs. I don't think that anyone would have a problem with a tailored template, in most cases. To me, the explicit removal of sections makes for a nicer and more reader-friendly document than text that says "does not apply".
As far as providing specifications, I'd be hesitant on what is provided. If you will be providing inputs in a specified format, provide that format. If another system will be consuming outputs, provide the expected output format. These could be railroad diagrams, XML schemas, byte layout maps, and any sample inputs/outputs (sanitized, if necessary). If you're specifying something that needs to be a drop-in replacement for another system, specifying the public interface may be necessary as well. However, I'd recommend leaving as much leeway to the developer as possible to design and build a system around your requirements.
In my experiences, there's often a separation of the requirements of the system and a detailed description of the interfaces between components. I don't think this is always necessary, though. Conformance to a specified interface is, technically, a communication or environment requirement ("the system shall provide output in XML that conforms to the schema defined in schema file"). Separating the two is probably more appropriate when describing a system of related components rather than a single component, where I'd argue that having a single, comprehensive resource for what I'm expected to produce is better.
I'd recommend approaching this as defining only what you need from this system, leaving as much as possible up to the developer. If you spend too much time doing the specification such that there's only one or two solutions, then you've done most of the time intensive work (in my experience). As a developer yourself, you probably know what questions you might ask if you were presented with the general scope of the system you want - answer those as clearly and specifically as possible and hope the developer will ask any other questions you might not have thought of.
Bluntly, there isn't any one standard. Within the US, there are differing notations for states, counties, and regions (zip codes, area codes, metropolitan regions, etc.). While the US does have a standardized address format, even that is highly subject to variations. Also, address standards change regularly. Before the age of the internet, mailing a letter could be done without a zip code (because they hadn't been invented at the time) and you used a 3 letter abbreviation for most states.
Canada has a similar addressing scheme to the US. However, the postal codes in Canada are 6 or 7 digits. Including a space after the 3rd character of the postal code may appear to be the same region, but it isn't. I have also heard rumors of Canada moving to an 8 digit postal code.
Almost every country has an online guide from their official postal service with detailed information about acceptable address formats.
Google, ESRI, and other map data providers have come up with varying ways to associate an address with a lat/long pair. Google uses KML (a specific standard of XML used for addresses). They break an address into a street number, street name, lat/long, and several political hierarchies. You will find that in some countries, the political divisions can be 7 or 8 layers deep (maybe more since the last time I did research into this area).
If you are looking at what you need to store in a database for your customers, follow the US address format with several additional address lines (I typically store a minimum of 3 address lines for international addresses), a city, a state or province, a postal code (international needs to allow for at least 15 characters, digits and alpha), and a country. I have started to include lat/long recently as addresses can change without warning.
There are ISO standards for country code which a quick search will turn up a bunch of links. Beyond that, you are pretty much on your own for formatting though.
Best Answer
Short answer: 830-1998 is not a standard, it is a recommended best practice on how to write SRS in the style of 1998.
I can't find how it was superseeded (even with IEEE's advanced search :( )
But I guess it's because the whole method on how we specify requirements has changed drastically in recent years.
So, from now on, I try to answer a bit of modified question:
What is the industrial best practice / What are the recommended best practices on writing SRSs in the style of 2012?
On classical methods:
Usually I use IEEE 1471 recommendations for software documentation, although that was also superseeded recently by ISO/IEC 42010. This is a very complex kind of documentation, it's mainly used for handovers, although it does contain the requirements mostly (it's chapter 7 in the new ISO style document)
A moderately good book on formal documentation is Documenting Software Architectures, a surprisingly good book is the old iconix book, and an old classic is Cockburn's Writing Effective Use Cases.
On how it is actually done in the industry today:
Truth to be told, formal project documentation, especially requirements documentation was killed off mostly in the age of Agile, as the Agile Manifesto discourages formal documentation. There is no one, single, large formal specification, but instead, there are so called user stories, product backlogs and such. This is because of iterative development, only a handful of features are specified informally for each cycle of 2-4 weeks. A renowned book is User Stories Applied.
There are so-called "executable" specifications, which are formal, since they are essentially domain-specific languages (DSLs) for testing. They are no better or worse than UML's OCL, but they're more easier to grasp perhaps but also less scientific. Most of them are called BDD frameworks, and examples include FitNesse, Cucumber, Jasmine - you'll find a big bunch of these. There are also renowned books on BDD and TDD in general.
Also, specification by software engineers was superseeded by UX design, including information architecture and interaction design, so it's not done by people who can actually code nowadays, which can lead to conflict sometimes. This is a not-so-bad example on how one looks like (it's not a standard!), but you'll find a lot more inside the UX / interaction community, but there's even a whole separate stackexchange site for them. They have their own standards, recommended best practices, etc.
But what if you want to stick with the old methods, eg. for university work?
In general, try to adhere to the IEEE 830 (can't find on their webpage what was it superseeded with, although IEEE was never good with this, I guess it's because it doesn't matter anymore unfortunately), and make sure you try to record useful information (eg, I don't think that a single actor stick figure -> single bubble with a verb-subject is considered useful) from which the overall goals of the users, the overall range of users and the overall methods of usage can be reconstructed anytime.
Why do you recommend books? Why don't you show me standards instead?
Again, I guess this document was "superseeded" because today, we have a bit of chaos around requirements specification: there are many-many viewpoints on how it should be done.
There is no single authority who is able to tell you: "this is how specifications should be made". There are best practices, and I tried to provide you with a representative list of documents and directions, albeit by no means complete, and perhaps personally biased.
At the end of the day, what matters is wether the document you create is able to fulfill all the goals all the people who ever read it have with it: what people want to see, what people need to know in order to understand the requirements are pretty well described in these books, and these are best practices on their own right, albeit in much smaller communities than a single, undivided IT community what we had perhaps in 1998.