Purpose and Scope of Problem Analysis

Each project life-cycle phase has a unique role within the overall process. The purpose of the problem analysis phase is to understand the resources used by the problem domain. These resources are modeled as objects, abstracted into class definitions, and placed on a class diagram showing the relationships between them.

The purpose of problem analysis during the project life cycle is to understand and define the problem that the project aims to address, establish the project's scope, and identify the needs and requirements of the stakeholders. Problem analysis provides a solid foundation for the project, as it informs subsequent stages of the project life cycle, such as planning, design, implementation, and testing. The scope of problem analysis during the project life cycle includes the following activities:

1. Identifying the problem: The first step in problem analysis is to identify and clearly define the problem that the project aims to solve. This involves understanding the context, stakeholders, and the underlying issues that need to be addressed.
2. Analyzing stakeholder needs: Problem analysis involves identifying and understanding the needs, expectations, and requirements of various stakeholders, including users, clients, project sponsors, and other relevant parties. This helps ensure that the project's outcomes align with the stakeholders' goals.
3. Gathering and documenting requirements: Problem analysis includes gathering and documenting the functional and non-functional requirements of the project. These requirements serve as a guide for the design, development, and testing stages of the project and help ensure that the final product meets the needs of its users.
4. Establishing project scope: Problem analysis helps define the project's scope by determining what functionality, features, and quality attributes the system should include, as well as what is out of scope. A clear understanding of the project's scope helps prevent scope creep and keeps the project on track.
5. Prioritizing requirements: During problem analysis, requirements are prioritized based on factors such as user needs, business value, and technical feasibility. This helps the project team focus on the most important features and allocate resources effectively.
6. Identifying risks and constraints: Problem analysis allows the project team to identify potential risks, constraints, and challenges that may affect the project's success. By proactively addressing these issues during the analysis phase, the team can minimize their impact on the project and improve the chances of successful project completion.
7. Defining success criteria: Problem analysis helps establish the criteria for measuring the success of the project. These criteria can include specific goals, deliverables, or performance indicators that can be used to evaluate the project's outcomes and determine whether the project has achieved its objectives.
8. Facilitating communication and collaboration: Problem analysis involves communication and collaboration between various stakeholders, including users, domain experts, project managers, developers, and testers. This collaboration helps create a shared understanding of the problem and requirements, ensuring that everyone is on the same page throughout the project life cycle.

By performing problem analysis during the project life cycle, the project team can ensure that they have a clear understanding of the problem, stakeholders' needs, and project scope. This foundation is essential for the successful planning, design, implementation, and testing of the project, ultimately leading to a solution that meets the needs and expectations of its users and stakeholders.

Software development is notorious for going over budget and being late. Scope creep, the tendency to try to do everything, the intention of completing all tasks within a specified timeline, sends us off on tasks not directly related to the immediate goal. Furthermore, human nature tends to lead us to work on those aspects of the problem that intrigue us the most. For programmers, the focus tends to be programming. For interface designers, the focus tends to be the user interface. For database administrators, the focus tends to relational database design. Focus on the requirements at hand and work one step at a time. Measure your progress of the individual steps against the larger objective in the project.

Preliminary Analysis: The objective of phase 1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations. Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself then you need to find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them. Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients , suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices:

1. leave the system as is,
2. improve it,
3. or develop a new system.

The scope of problem analysis is to define only those classes of objects that would be part of the problem domain even if you did not create any software. The scope of these class definitions is also limited to the purpose of the objects and the interfaces needed to use them. The implementation of the class is not needed at this point because it does not contribute to our understanding of the role of the resource in the problem domain.

The users should recognize every class of objects defined during this phase. The users would not use objects such as graphical user interfaces (GUIs) or databases. These resources support the software implementation choices, not the problem domain.

If you have completed a satisfactory task of creating the data dictionary, you probably have the most important objects identified and defined already. One way to keep the proper user perspective is to think manual. For example, most people who have programmed in Java or C++ are used to making "address" a class, that is, a reusable data type. But in a manual system, would the users have a file drawer full of addresses only?
No. The users would include address as an attribute of other objects such as customers and suppliers.
Only then does address have a context that gives it meaning to the users.