Most people are familiar with requirements development as a process where you talk to the stakeholders and they tell you what they want. Usually when this is done, you get a long list of very specific “requirements.” These “requirements” usually are too solution-specific. In other words they specify using certain hardware, software, processes or something else that artificially constrains the solution space, and thus increases cost, schedule and performance. An example of this could be a requirement that states the software must use public cloud computing rather than stating the true need behind the requirement, “the software needs to be highly scalable.” Requirements that are too solution-specific prevent alternative solutions from being made, such as the hardware could be a very large private server farm for high scalability. You could also miss the fact that the software has to scale as well.
In addition to capturing the user requirements, a better way to get at the real requirements comes from deriving those requirements from a functional model (See the Action Diagram on the right). The functional model shows the current activities (business processes or warfighting tactics, techniques and procedures) and then uses these as the basis for the functional requirements. Performance requirements can also be derived through this approach, by putting realistic timing and resource constraints into the individual process steps, and then using simulators to run various scenarios. When you present your stakeholders with the results of the modeling they will be more likely to give you functional requirements.
At the same time, we recommend identifying any political or legal constraints, such as frequencies that are allowed to be used for the applications involved.
Another area for requirements comes from market analyses. You look at competitors and see how well you fit in the market. Those can provide many realistic constraints. Often government stakeholders do not take this into account, but they should. We should not be trying to do more than is necessary to defeat an adversary. We call this threat analysis in the military world, but you can apply SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats) to any industry.
The technologies that are available can provide opportunities to improve the processes. New technologies may provide significant improvements in the way you perform your business. However, you may have to re-architect the business processes to make best use of the new technologies.
Risk is another important factor often ignored by the “requirements only” folks. Most organizations are risk adverse. They often have to make difficult decisions that are risk-based.
Location is another factor to consider when performing requirements development and analysis. The requirements for one location may not be the same as for another. For example, equipment which has to operate in the Arctic or in Space will have a very different set of requirements due to its operating location.
Requirements also have cost implications. Thus capturing the associated costs help the decision makers understand what requirements drive the costs.
As you can see, this covers almost an entire taxonomy, the bins you use to collect the information that describes the system. Also note that these “bins” relate to one another, thus the term ontology fits your need. We recommend the Lifecycle Modeling Language (LML – see www.lifecyclemodeling.org) as having a complete ontology for you to use. To not capture all this information means you have not done the right job and that will lead to very poor decisions. Poor decisions can lead to loss of business or loss of life, depending on your industry.
When we apply Model-Based Systems Engineering (MBSE) techniques, such as LML, we can capture all the necessary information, linking it together logically and enabling better decision making. Both LML and Innoslate® were developed from the ground up for applying MBSE techniques to capture and develop proper requirements.