The SDLC activities in this phase overlap significantly with those of the project life cycle, which may be why some organizations try to use the SDLC to manage their projects—the overlapping activities give a false sense of doing everything that needs to be done to manage the project. But there also are some different activities as well. In both models, this is the data-gathering phase—trying to get a handle on what the project is all about and, in the case of the SDLC, what the product is.
It is important to realize that in project management we deal with two scopes: the project scope and the product scope. Whereas the project scope is general in that it addresses all those activities required to support developing the product—the reason for the project—the product scope is very specific and focuses only on the product (or service). The basis of the product scope, as with the project scope, is its requirements.
The challenge in requirements identification is understanding what the customer wants. Generally, requirements are poorly written or incomplete, or the customer simply does not know what he wants. Even when the requirements seem clear and straightforward, the wise project manager will restate them back to the customer to ensure they both understand the direction the product definition is taking.
Product requirements are best stated in terms of functionality desired. Functional requirements relieve the customer of the burden of developing detailed specifications, and it makes describing her product needs easier. Likewise, functional requirements free the provider to develop creative, and usually more cost-effective, solutions. Again, this subject is treated in detail in the next chapter.
Once the product requirements are identified and verified with the customer, the next step in the SDLC is the feasibility analysis.
A major problem in any project, but particularly in the IT industry, is that too few organizations actually do a feasibility analysis of the requirements to determine whether they have the resources or technical capability to meet the customer's needs. All too often, the organization simply takes the position that "we can do any project" with no consideration about whether they have the right amount of expertise.
A recent Government Accounting Office (GAO) study revealed that every contract they reviewed failed, or was late and over budget, if the providing organization did not map the customer's requirements against the provider's capability before design approval. A feasibility study is crucial to the success of a project, and it should be a part of the requirements identification and high-level WBS development.
Feasibility studies demonstrate to a prospective project owner or investor that a given concept is financially viable and whether further study and/or a business plan is warranted.
For a feasibility study, basic data is obtained from the client through a series of queries, questions, and meetings, wherein the client provides some of the research. Other data and facts need to be gained from a variety of sources.
The typical feasibility study contains, among other items, notes on financial projections, a general description of the business, general details describing how the company/project will be formed, managed, and marketed, statements concerning the competition, and a cash-flow projection based on averages. Further notes can be included as to general details of the project and revelations discovered during the research stage. The study will normally be completed quickly, and it will be presented in a very general format (unlike a business plan). A feasibility study should answer five questions:
Will it work?
Do we have the expertise and resources to do it?
Will it benefit the company?
What will it cost to start?
Does it fit into the company's strategic plan?
The feasibility analysis serves several purposes. Not only does it help to determine whether the company has the technical and resource capabilities to do the project, but perhaps more important, it answers the question of whether the project would contribute to the company's long-term growth plans. If the project doesn't fit the strategic plan, then whether or not there is sufficient expertise and resources is a moot point—the project should not be started. One further major benefit of a feasibility analysis is that it helps identify and reduce business risks. Technical risks, to some degree, can also be identified by the feasibility analysis, but a more thorough risk assessment is done when the systems architecture is developed.
If the feasibility analysis indicates that the project does fit the company's strategic goals but reveals shortcomings in the provider's capability or resource pool, then the opportunity exists to either hire additional capability, contract with a consultant, or team with another company. Another legitimate strategy is to negotiate with the customer to reduce the product scope, or at least postpone some of the options until the company can develop the requisite capability.
With the feasibility analysis completed, the product scope can be definitized. Product scope is simply the amalgamation of the requirements identification and feasibility study into a statement of product definition.
Product scope can be defined as the features and functions that characterize a product or service. With the requirements definition completed and a well-researched feasibility analysis in hand, the scope of the work to design, develop, and implement the product is well under way.
The product scope is different from the project scope in that the emphasis here is on defining the functions and characteristics of the product and the technical considerations for building it. This is not the process of actually designing the product but defining the parameters within which the product is likely to be built. In other words, the product scope defines the boundaries around the product (i.e., how big, what color, how responsive, and how reliable it is), but it does not dictate a solution. In fact, a good product scope definition won't even suggest a technical approach: It will just specify the product's minimum functionality and characteristics. The technical approach is determined by developing the systems architecture, which determines the product specifications.
The National Aeronautics and Space Administration (NASA) defines a systems architecture as:
... How functions are grouped together and interact with each other. The architecture applies to the mission and to inter- and intra-system, segment, element, and subsystem. 
In other words, the architecture includes every aspect of the system. And "system" is the keyword when defining the IT project. All too often, the emphasis is on the software development component, with the rest of the system being designed almost as an afterthought.
The key elements of architectural design are:
Functional design of alternatives
Analysis of alternatives
Formulation of a preferred system architecture
The architectural design process then is one of identifying the requirements and developing several technical alternative solutions to meeting the customer's needs. The obvious reason for this approach is to determine the most efficient and cost-effective solution. Once the analysis of these alternatives yields the preferred solution, then it is important to establish evaluation criteria to measure whether the alternative is indeed the proper one and how well it meets the requirements.
The architectural design process ultimately results in the formulation of a preferred architecture, which means a detailed analysis and description or specification of the system. With the preferred architecture identified, the serious project and product planning can begin.
National Aeronautics and Space Administration, NASA Engineering Management Council, The NASA Mission Design Process (Washington, D.C., 1992).