Precisely describes each module in your design. As needed, each module should be further broken down into sub-modules. To assist with understanding, also draw your sub-modules (e.g., Fig 2-1 below). Each module, at whatever level, must be described as follows. If you are using interfaces provided by another team, please refer to the project name and their module. The purpose of the module: State the generic purpose of the module. Specify which part of the requirements document it addresses, if this is appropriate. (Appropriate items to address here include such topics as: What secret does this module hide? Does the module represent a specific data type or data format?) The provided interface: Define the provided interface by listing all its methods with descriptive names. The definition includes the names of the methods, their parameters, and their return types. Provide a short commentary describing each of the methods (i.e. what it does). The required interface: Define the required interface by listing all its modules/methods. Note that every one of the modules/methods listed should be described elsewhere in this document, either as part of the design which you are creating or else as an externally provided service. Constraints on the module: E.g., performa

Scenario:

Mobile Apps: You lead a small experienced team of 7 developers from a gaming

company. Your team is responsible for quickly developing educational games based on

preliminary and evolving set of requirements. You have internal and external customers

who expect to use your games ASAP for their own testing efforts. You have a team

member who participates on educational conferences as well as acts a marketing

representative to your customers, the teachers and administrators at your local school

district.