Based on the size and/or complexity of the project, the study effort may vary. The typical process steps for conducting a requirement study and proposal building are outlined below. These steps are often being conducted concurrently, iteratively and, in fact, some steps may be omitted entirely, depending on the complexity and criticality of the effort. Process steps include:
- Determine requirements for the study
- Determine objectives, scope and approach, and plan the effort
- Conduct a current state assessment
- Identify potential solutions
- Determine the feasibility of each option
- Document and communicate the results of the requirement study, and obtain approval to estimate development for the recommended solution
1. Determine Requirements for the Study: Business Problem or Opportunity
Requirement studies are used to determine the approach to solving a business problem or seize a new business opportunity, the approach is slightly different. In the case of a business problem, the Business Analyst first determines and documents the problems faced by the organization and the potential areas of study required to address the issues. The analyst then conducts root cause analysis to determine the full nature of the problem, the actual cause (or causes) of the problem, the adverse impact it is having on the business and the criticality and required timing of the resolution.
To take advantage of a new business opportunity, the analyst defines the opportunity in as much detail as possible to understand the scope and determine the nature of the study. This information is then used to determine the methodology or approach to be undertaken to complete the study. For each business problem and/or opportunity, the analyst drafts a requirements statement describing the business need for a solution.
2. Determine the Objectives, Scope and Approach and Plan the Study Effort
To plan the requirement study effort, the Pre-Sales/Business Analyst first assembles a team of skilled resources who collaboratively perform the following tasks:
2.1 Establish specific, measurable objectives that the recommended solution must meet. These objectives provide the basis for formulating options for consideration.
2.2 Develop benefit criteria upon which alternative solutions will be evaluated in the form of quantitative measurement criteria by which to judge the success of the investment in the recommended solution.
2.3 Define scope of activities to be performed during the study.
2.4 Define deliverable(s) to be produced from the study; if it does not exist, develop a template for the final proposal document.
3. Conduct a Current State Assessment
The study team conducts a limited amount of internal analysis when initiating the requirement study. These may include review of business objectives, strategy and vision; analysis of current business processes; and assessment of current (as-is) and future (to be) documentation. The current state assessment consists of a review of all or part of these elements, depending on the nature and scope of the study:
3.1 Strategy – Review the business vision, strategy, goals and measures.
3.2 Business Area – Describe the mission of each line of business or business unit that is a stakeholder for the area under study, and collect relevant organizational charts.
3.3 Locations – Document the physical location of each impacted business unit.
3.4 Data and Information – Identify the major types of business information required. It is also helpful to list the repositories which retain the information listed.
3.5 Infrastructure – List each of the current business technologies impacted by the initiative.
3.6 Processes – List and provide a description of each of the current business processes relevant to this project.
3.7 Competitive Arena – Describe the current business environment within which the business operates, including:
- Market analysis, competition, products and services available
- Emerging markets and technologies
- Regulatory or legislative changes.
4. Identify Potential Solutions
At this point the study team conducts external research activities to uncover general information about the industry, the competitive environment, best practices, risks and results of the actual similar approaches that have been implemented by others to solve the business problem or seize the new opportunity under consideration. Then, the team identifies as many potential options as possible to meet the objectives identified in the planning process. It is important to note that the list of possible alternatives should include the option of doing nothing.
5. Determine the Feasibility of each Option
For each potential solution, typical analysis steps include the following:
5.1 Describe the solution option in as much detail as possible, perhaps building a high-level work breakdown structure (WBS), a hierarchical decomposition of the solution, to bring the full scope of the effort into view.
5.2 Identify methods to assess the alternative, ensuring the analysis of the economic, operational and technical feasibility of the option. Examples of methods include: prototyping to prove the highest risk portions of the solution option are technically feasible, market surveys to ensure there is a demand for the solution and it will be economically feasible, technology capability assessment to ensure the solution does not require new, unproven technology, and business staff interviews and IT staff interviews to determine operational feasibility.
5.3 Identify expected results of the assessment.
5.4 Define assessment steps.
5.5 Undertake feasibility analysis for each option.
5.6 Review results to ensure completeness.
6. Document and Communicate the Results of the Requirement Study
Proposal document would describe the results of the requirement study for each identified alternative solution. Share the proposal document with the executive sponsor of the study, and secure approval to estimate development efforts for the recommended option.
Types of Requirement
The types of requirements that exist vary based on the problem domain and methodology that the Pre-Sales/Business Analyst works with. For the proposal, the following types of standard requirements types have been defined:
- Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. This describes such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
- User Requirements are statements of the needs of a particular stakeholder or class of stakeholders. This describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
- Functional Requirements describe the behavior and information that the solution will manage. This describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
- Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. This is also known as non-functional or supplementary requirements.
- Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
- Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.
The deliverable from this effort is the scope statement and supporting information defining the following components by inclusion or reference. This proposal documentation is input to determine the development efforts, and includes the following elements.
- Summary of activities the led up to the recommended solution including the business environment analysis and competitive analysis.
- Strategic alignment describing how the initiative fits with organizational direction or mission.
- Business objective(s) and high-level business requirements.
- Product description and scope.
- Project boundaries including context diagrams to provide a visual model of the scope of the project.
- Assumptions and constraints.
- Major project milestones, funding requirements and limitations.
- Initial project approach including resource requirements, methodology, tools, and training requirements.
- Current and future standards, policies, regulations to be adhered to and impacts to the initiative.
- Commercial Off-the-Shelf (COTS) packages available vs. customized development of the solution.
- Dependencies, including downstream systems, interfaces, supporting data required.