2430 - Analyze Application Requirements (DEMO)
|
|
Use this task package to develop a formal and rigorous model of the previously gathered requirements. The project team creates cohesive models of the application (event, process, content, and data) and establishes metrics and goals that can be verified with stakeholders for each model. When open issues remain, actively manage them to an agreed conclusion. If necessary, create a prototype of the business process and iterate it to stakeholder satisfaction. Meet to review the requirements specifications, and then make appropriate modifications. |
Key Inputs
|
Secondary Inputs
Key Deliverables
|
Secondary Deliverables
|
Outcomes
|
Accepted application requirements |
Planning Considerations
 |
This task package should be performed after the project initiates a requirements gathering process and defines an initial set of requirements. This allows for some iteration between requirements gathering and requirements analysis. |
|
This task package occurs prior to the initiation of design efforts. The requirements models provide a major input into the application's design. However, projects can return to this task package at any stage of development. Returning to analysis often clarifies issues or enhances the effectiveness of the application. |
| Avoid viewing analysis activities as the end goal of the project. The analysis models are a means of structuring and integrating the requirements. This view should help the project avoid "analysis paralysis."
The requirements model is a means for understanding and representing the stakeholder requirements. Although the models provide logical representations of the application, they are not the end goal of the development effort. The goal of the development effort is the successful implementation of the running application that achieves its business benefits. Development efforts that lose sight of this relationship between the analysis and the application run the risk of analysis paralysis. The analysis paralysis trap is especially dangerous when the team is composed of many inexperienced people. Working with the three requirements models (event, data, and process) is intellectually gratifying because it results in a highly structured and coherent view of a complex business area. Moreover, less experienced personnel need to study any domain in more detail than experienced personnel before they can satisfy themselves that their work is complete and consistent. For example, a process model for a transaction processing application need not depict file maintenance activities. A data model need not specify all the attributes of each entity; nor do all the possible relationships between entities need to be drawn on the entity-relationship diagram. The Application Requirements Analysis Exit Conditions job aid offers some focused questions for the team to ask themselves in order to determine when they are finished with the formal activities for analyzing application requirements. This checklist can be used to establish the proper level of detail. |
|
| Assign experienced personnel, with skills in the various analysis techniques and with different skills and knowledge of the business. These experts may be assisted by less experienced people. However, their involvement should be viewed in part as a training experience.
Event and process modeling activities usually are performed by business analysts or business representative analysts. However, data modeling is most often performed by people with database backgrounds. The obvious merit of this approach is that the data modeling team can then design the logical and physical data models with little or no learning curve. The involvement of people with different backgrounds is very important. Technology is a means to support an effective business process. Personnel that have a strong knowledge of the business process, that know the organization and its people, and that are aware of possible training and performance support, are needed in the teams analyzing the requirements. Only then can a complete, consistent picture of the future application evolve from the tasks in this task package. |
|
| When media content is required for an application, include media designers as core members of the project design team.
When media content is required for an application (for example, a Computer Based Training application), media designers add a great deal to the design and to the development team. It is more effective to include media artists throughout the entire development process rather than bringing them in at the end. Sponsoring organizations value and expect the unique skills media artists bring. It is extremely important to immerse the media designers in all facets of your project. Media design is not an activity that can occur on its own. It is closely related to the development of the entire application. The media designers must be included in design meetings and have close interaction with all project and sponsoring organization personnel. It is very easy for a design to go astray if the media designers feel segregated. Without constant and open dialog, their interpretation of the media requirements may not match exactly with the business requirements. Therefore, be sure to include the media designers as core members of the project team. |
|
|
The analysis models should be created in unison. On large projects, it will be necessary to partition the analysis into major subsystems. Each subsystem should have a small team assigned to analysis activities. A central data administration team would be responsible for consolidating each team's data models into the project data model. |
|
The metrics and goals defined for the application should relate back into the Business Performance Model. |
| Use the quality requirements and trade-off guidelines as the main drivers for resolving architectural issues.
There is no direct connection between a quality requirement and some corresponding application object (module or record). The link between the quality requirements and the design of the application is most often the application architecture. As the design is created, it is measured against the quality goals. Falling short of these goals may result in design changes. As the team determines the desired levels for each quality attribute, it also must assess the feasibility of achieving each desired level. This feasibility is determined largely by the hardware, application software, and architectural style. The information and expertise available from the architecture team also are needed to determine feasibility. The quality requirements themselves also may influence the design or selection of architectural components, and may affect the initial capacity planning done while the architecture is being designed and prototyped. |
|
| Cross-validate the application process model, the event model, and the data model by analyzing the relationships between the three models.
The application process model represents the internal structure of the application. That structure must produce the appropriate responses to the business events captured in the event model. The processes create responses by managing the data entities found in the data model. These relationships support the concurrent development of all three models and their cross-validation. |
|
|
Ensure that the tasks within the Identify Application Requirements task package are completed and the corresponding results are incorporated in this effort before this task package is completed. |
© 2025 CSAT. All Rights Reserved.