Yourproject'sanalysisphaseshouldyieldthreecri…

When the analysis phase of an application development project ends, a manager should know what the application looks like, how it functions, and how it is designed. The extensive information gathering and analysis of this phase provides extensive details on each of these aspects of the project. The final stage of the analysis phase is to organize this information into documents that will guide the work during the rest of the project.

The three important deliverables created during this phase are:

• The business requirements report.
• The conceptual systems design plan.
• The strategy documents.

The business requirements report lays out the business criteria of the project and includes any work associated with process and data models. The conceptual systems design plan is the transition from business requirements to the more detailed technical design. The plan contains high-level architecture diagrams, screen design, and report layouts.

The strategy documents describe the overall direction of the project in a number of areas, including testing, training, data conversion, and implementation. These are direction-setting documents that can be worked on with the business client and provide the overall direction to the more detailed planning that occurs later in the design phase.

---

---

Business requirements report
The business requirements report ties together the requirements and the modeling done earlier in the process. It describes the requirements in several formats that can be understood by the project team and the business clients and should include the following pieces of information:

• High-level requirements—This section defines the big-picture requirements that are common to the entire solution. An example of a general requirement is that everyone in the company must have access to the data. Each requirement should be numbered and prioritized. The numbering scheme can be used to track the requirements through the testing process.
• Functional requirements—These are the more specific requirements. If the solution includes a number of major functional subprocesses, the requirements for each piece should be listed separately in this section. For example, functional requirements might state that all finance users have update access to the information, while users from the marketing department have read-only access. These requirements should also be numbered and prioritized for tracking during testing.
• Acceptance criteria—This section should describe the client’s criteria for accepting the application, if it has not already been described elsewhere.
• Process model—If you created process models of the solution, they should be included here, along with the appropriate descriptions.
• Data model—If you created data models, they should be included here, along with any explanations.
• Additional information—Depending on the project and the particulars of the analysis phase, you may also need to include any assumptions made in the analysis process and other models, such as context diagrams, process decompositions, and entity diagrams.

Conceptual systems design plan
The conceptual systems design plan provides a bridge between the business-focused requirements document and the IT-focused technical design document that will be created in the design phase. The business client is normally not very involved in the design phase, so the conceptual document is the client’s chance to ensure that the application is designed as it should be. Sections in this document include the following:

• High-level technical architecture—This is a place to start laying out the technical solution. It should be diagramed at a high level that the business customer can understand.
• Screen layouts—In the past, the IT team would lay out the screen design based on the easiest way to program the layout. However, a better way is to work with the business client to define what the screens should look like and then design and code to those general specifications.
• Report layouts—The rules here are the same as the ones for designing screen layouts. Work with your clients to define the reports that are needed and the general columns and selection criteria of the reports.
• Interfaces—At this point, you should have a general idea of the internal and external interfaces needed for the solution. For each interface, define in general terms the information that is passed and the timing of when it will be passed. If the other side of the interface already exists, the actual layout can be included.

  标签：

  版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
  特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有