A rough estimate for bare tables is pretty simple. The number of bytes in a row is roughly
Total number of bytes for all columns + dbms overhead
dbms overhead might include a fixed or variable number of bytes per row or per column. The number of bytes of overhead often depends on the datatype of the column. The dbms might also apply padding to make bit columns, for example, align with a machine word boundary.
Multiply the bytes per row by the expected number of rows one year, two years, or five years from now. Repeat for every table, or for only a statistically representative sample of the tables.
You can often find leads to the details for your dbms by searching for "your_dbms row format". If you searched for "sql server row format"
you'd probably find Types of data compression in SQL Server 2008.
Your dbms might require you to take into account compression, compact storage formats, and indexes. Compression and compact storage formats reduce the amount of storage space you need; indexes usually increase it.
If you want a really good estimate, build a testbed. Fill it with statistically representative sample data. Do the arithmetic based on what that tells you. Include estimates for new tables to implement new features.