2: Mapping Your Strategy
This chapter focuses on the planning approach, with specific emphasis on how the requirements for an on-line operation are defined as a precursor to the construction task. The author divides the task into eight steps:
- Transfer the business into functional requirements.
- Identify the existence of non-functional requirements.
- Verify the logical storage and movement of key elements.
- Plot the physical layout of the delivered goods.
- Break the physical model into granular components.
- Test the physical model for robustness in a typical operating environment.
- Test the physical model for robustness in extenuating circumstances.
- Guarantee the delivery of the required physical layout.
1. Transfer the Business into Functional Requirements
The business has a number of goals for undertaking a project, which must be translated into functional requirements. The author doesn't explain this in much detail, simply indicates that you must identify the "main functions" (in terms of what inputs it receives, how it handles them, and how it maintains or outputs the information), and makes reference to "use cases" that detail the way in which people will use it.
2. Identify the Existence of Non-functional Requirements
The non-functional requirements are often very important to a project, as they define the characteristics of a system and often pertain to topics such as security, resource management, scalability, capacity, and other aspects that, while not related to the core function, are nonetheless important
3. Verify the Logical Storage and Movement of Key Elements
For system design, the major functions of a system are detailed in a flowchart that tracks the data as it is received, processed, stored, and communicated. This should be done for every user taht the system is designed to accommodate (there is often more than one user to a system - such as the customer who enters an order, the processor who receives it, the shipping department, and management that oversees the entire operation).
4. Plot the Physical Layout of the Delivered Goods
The "physical layout" pertains to the systems that will be used: the client, network, Web server, databases, etc.
5. Break the model into granular components
A "general arrangement plan" divides the system into individual components and demonstrates how they interact with one another. This includes an "inventory model" taht provides a list of all systems and an "interdependency model" that shows how they interact with one another.
It is of particular interest to online operations because of the integration of back-end systems (often legacy systems) with front-end platforms to form a system with 24/7 availability and complex user roles.
6. Test the Physical Model in a Typical Operating Environment
A model or prototype is created, and is tested to ensures it does what it is designed to do under expected conditions. To do this, scenarios are created that simulate all of the interactions that various users will have with the system and ensure that each can succeed and the interactions among them do not cause conflict. Load testing is also done to ensure that the systems performance will be acceptable under conditions where multiple users are simultaneously accessing it.
7. Test the Physical Model in Extenuating Circumstances
In addition to testing the model to ensure that it performs the expected tasks under the expected load, the model should also be tested to ensure that unusual behavior/interactions do not cause a critical failure. This generally involves the creation of a number of "what if" scenarios for testing.
The author advises coming up with "worst case" scenarios and testing the system under a load that will "break" it, just to determine the theoretical maximum of the current design. Under this sort of testing, "critical" areas and components will be discovered.
In addition to testing for failure, you should also use this testing to plan recovery - to have a sense of what will be involved in getting the system back online and salvaging the data that may have been lost or damaged in a complete system failure..
8. Guarantee Delivery of the Required Physical Layout
Once all requirements are defined, they are documented in such a way that they can be used to negotiate a contract that clearly communicates expectations of the developers (internal or external) so that there are no ugly surprises.
Conclusion
The conclusion reiterates the key points of the chapter.
(EN: This chapter has been a brief overview of the planning process, and lacks much detail. There are other sources that aren't as general, and they should be consulted, as the planning phase is critical and much neglected.)