I would want to know two things that aren't always clear at the beginning of a project; 1. A 50-words-or-less summary of what the project is all about when it'

I would want to know two things that aren't always clear at the beginning of a project; 1. A 50-words-or-less summary of what the project is all about when it's finished. Scope creep and lack of clarity often prevent this sort of thing at the outset. 2. A summary of where the requirements ultimately derive from. For instance on a credit card processing system I worked on (I was in the 3rd "generation" of programmers to work on it), it seemed like requirements came from 6 main drivers: (1) Real time authorization of payments. (2) Search for previously authorized and settled payments. (3) Refunds of payments (4) End-of-day "batch" payment settlements (5) Crediting settled payments to customer accounts (6) The boogey-man named "PCI DSS". Organizing requirements under "main drivers" would really help maintenance, and people reviewing the project.