TABLE OF CONTENTS The requirements phase for many software-oriented projects has been largely restricted to requirements gathering. In probably far too many cases, design and even coding were started before requirements were known or stabilized to a sufficient point. This chapter presents the "recursive" nature of the total requirements gathering and analysis process. It includes concepts from the initial identification of stakeholders, to deriving requirements, to validating requirements at all stages. It will also include the more formal decision making concepts of decision analysis and resolution.
Requirements are the basis for design. Requirements, gathered according to CMMI , will address the needs of all relevant stakeholders including testing, quality assurance, and database, as well as software, hardware, systems, and so forth. Requirements may be focused on specific life-cycle phases. They may be focused on quality attributes such as maintainability, expandability, or reliability. Requirements may also address constraints caused by the selection of certain design solutions such as using an off-the-shelf database.
The following list may provide some insight into the question: What are requirements?
Customer's needs, expectations, and measures of effectiveness;
Items that are necessary, needed, or demanded;
Implicit or explicit criteria that must, should, or might be met;
Contain system and software information;
Will not contain details regarding the internal implementation of a solution;
May be derived from other requirements during analysis, operational concept and operational scenarios development;
Describe the services the system is to provide;
Describe how the system should behave;
Describe the circumstances under which the...
