System Engineering has several schools. It is common for a System Engineer to have training in only one school, and consider all other schools as a form of heresy. All of these schools are taught and work fine under the appropriate circumstances. It should be obvious that the methods used to add a feature to a well established entity with a large, generic user base should be very different than methods used to develop something brand new for a small group of expert users. Choose the right tool for the job.
This was formalized primarily use in contracted Defense efforts to support large, distributed design activities. The customers identity generally is known, as well as the application, specific user base, etc. There is typically a formal contract an statement of work involved. There are many standards describing this method, two are ISO/IEC 15288 and MIL-STD-499. I have come across at least 35 specifications that include some form of this method.
In a nutshell:
The Specification contains formal requirements, usually each is numbered. A formal requirement contains a "shall", for example:
The computer shall have four USB 2.0 ports.
Each formal requirement is verified , as proof of compliance, by an agreed upon test. The requirements document contains contextual material to assist in understanding, but the specific requirements are all that is tested. Must is sometimes used instead of shall.
Each requirement is written to stand in isolation, so it can be understood and tested independently. Frankly, this is an excellent exercise in understanding the effort, and worth doing, even if you throw the resulting document away.
Will, when used in these documents, refers to something that happens outside of the control of the entity executing the requirements. This is usually an assumption of conditions, or a customer responsibility. The sun will come up. When the sun comes up, you shall get out of bed. Unless it is not a work day, in which case, you may get out of bed.
Requirements are rarely implemented as independent elements. Any design combines requirements into a practical package. Each requirement is then verified independently, to make sure that the design is a complete solution for all requirements.
This method also allows for straight forward development of subsystem specifications. Each of the top level requirements can be allocated, or broken down, to each of the subsystems. When these requirements are collected, a subsystem specification can be easily generated.
This method also supports the Parallel Development method for schedule enhancement. For more on this, see this article: Requirements: How to Use Them to Drastically Improve Schedule Performance
While appropriate for many types of systems, this method has it's weaknesses. For example, once the requirements are partitioned, it is very difficult to implement further design integration or improvement. As a result, Integrated Product Teams were developed, to allow sub system designers to compare notes and find efficiencies. But frankly, at that point, any improvements are marginal. It is far better to get a good requirement set together, quickly finish the design, and use the lessons learned to make the next version better.
Use of Commercial Off The Shelf (COTS) equipment, or any reuse does not work well with this method. And value/priority are dirty words to the system engineers using this method. Requirements are usually all weighted equally, and improved performance beyond the requirement is typically not rewarded. You won't find many commercial products developed using this method.
This method is generally used when the customer is anonymous.
How does a manufacturer decide how many USB ports to put on a laptop? Whether to include bluetooth? Do I light the keyboard? How much horsepower?
Do they just go on gut feel? Not likely. Although many people would like to believe they know exactly what everything the new product should do, these people usually run out of steam, and eventually have to start dealing with the more clinical Value based method of system definition. It centers on this equation:
Value = Performance/Cost
Sometimes this is called the Feature Point method. A product has features, each of which make it more (or less) desirable. The effect of each feature is projected into it's effect on sales. This sums to a Net present value, which incorporates the cost of implementation, construction, marketing, etc. This method depends on focus groups, market studies and customer inquiries.
Reducing the power consumption 10W will cost $100k, and will yield another $50k in margin due to increased sales. Not worth it. Not doing it.
This requires the customers to have at least a working understanding of the product, so that the value of each feature can be calculated. There are methods, and companies dedicated, to teasing this out of the general population.
What the PMI PMBoK is based on. You bid a scope. A university will work for 1000 man-hours, and several results will be presented for your acceptance or rejection. A front end loader will spend two days on the site, and the pool will be whatever size the operator can make it. Generally used for operations, but sometimes you will see an engineering effort that is scope based.
The function or component to be provided has a specific test it must pass. A customer may provide a complete test process/procedure. For instance, if you are designing an oil filter for a high performance engine.
Whatever you said in the proposal, that is what the customer expects. Be careful what you say...