This phase starts with gathering the high-level requirements and refining them according to project goals.

These requirements define the major functions of the intended application or system. Major functions include critical processes to be managed, including mission critical inputs, outputs, and reports.

The Requirements Definition Phase of the SDLC includes the scope of work necessary to define, analyze and document business and end-user requirements. When developing under a structured type of SDLC, requirements may be further refined within Functional and Non-Functional Requirements documents.

System requirements definition or analysis phase requires deeper thought, when compared to the feasibility studies and cost benefit analysis efforts described in the concept phase, in terms of understanding the capabilities, features and functions end-users will need to support the business enterprise. The requirements phase is typically divided into two distinct activities: requirements gathering and requirements analysis. In addition, depending on the type of product under development, these two activities are required across business, end-user, functional, and technical needs.

But there's much more to requirements than these rather straightforward activities. Often times, in order to derive the needs of the organization it's useful to first document how things are currently done today. This type of requirements analysis is referred to as the current state or "as is" assessment. The as is assessment helps the business analyst not only document how things are currently done, but also delve deeper into understanding how and where things are not working very well.

Next, the business analyst(s) will work with stakeholders, end-users and customers to-determine what capabilities they require to be more effective in the work or activities they perform, and will therefore seek feedback on how things could be done better in the future. This type of analysis provides a description of the future state, and is often described as a "to be" assessment. This type of analysis can also be called a capabilities needs assessment.

Once the as is assessment and to be analysis are complete, the business analyst will turn their attention to developing a "gap analysis." This is an important step that determines the magnitude of change that is required to move the "system" from how things are done today to how they need to be done in the future. Here we are intensely using the term the system again because the scope of change management any or all the enablers of the business.

As an example, a new business requirements may drive changes in the software that facilitates the business process. However, the software itself can drive changes to the business process, either by providing performance support to the end-users, making the process more efficient, adding new capabilities, and/or providing information more readily than was available before.

The business requirements for the implementation of new features and functions may require changes to the underlying IT infrastructure, including servers, networks, storage devices, etc. Since we are changing business processes the skills and roles of our people may have to change. And, of course, it's possible that new equipment and technologies are also involved to implement the new business requirements. In short, what may have initially seemed as a relatively simple business requirement can evolve into quite a complex system indeed.

Professional project managers will see this kind of complex project dynamics if they spent any time in IT at all. As a real-world example, this author has managed a project where there were eight seemingly simple business sponsor requirements (e.g. Customer) - each requirement described in one or two paragraphs - drove no less than 70 work orders of new features and functions that had to be implemented in the existing software.

The complexity of the system led to evaluation and procurement of new software testing and performance tools, as manual methods became increasingly slow and expensive. New servers had to be procured and deployed, and no less than four business processes and their related procedures had to be updated to accommodate the new business changes. And of course, the systems documentation and user guides also had to be updated, plus new training aids and wikis to support the overall deployment had to be developed and deployed.