Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

Design should be traceable to the requirements model. The requirements model des

ID: 3639738 • Letter: D

Question

Design should be traceable to the requirements model. The requirements model describes the information domain of the problem, user-visible functions, system behavior, and a set of requirements classes that package business objects with the methods that service them. The design model translates this information into an architecture, a set of subsystems that Implement major functions, and a set of components that are the realization of requirements classes. The elements of the design model should be traceable to the requirements model. Always consider the architecture of the system to be built. Software architecture (Chapter 9) is the skeleton of the system to be built. It affects interfaces, data structures, program control How and behavior, the manner in which testing can be conducted, the maintainability of the resultant system, and much more. For all of these reasons, design should start with architectural considerations. Only after the architecture has been established should component-level issues be considered. Design of data is as important as design of processing functions. Data design is an essential element of architectural design. The manner in which data objects are realized within the design cannot be left to chance. A well-structured data design helps to simplify program flow, makes the design and Implementation of software components easier, and makes overall processing more efficient. Interfaces (both internal and external) must be designed with care. The manner in which data flows between the components of a system has much to do with processing efficiency, error propagation, and design simplicity. A well-designed Interface makes integration easier and assists the tester In validating component functions. User interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use. The user interface is the visible manifestation of the software. No matter how sophisticated its internal functions, no matter how comprehensive its data structures, no matter how well designed Its architecture, a poor Interface design often leads to the perception that the software is "bad." Component-level design should be functionally independent. Functional independence is a measure of the "single-mindedness" of a software component. The functionality that Is delivered by a component should be cohesive-that is, it should focus on one and only one function or subfunction.5

Explanation / Answer

Principle 1 : Tracable means your design must be verifiable and validated easily. You should design the system which is easy to test(more modular easier to test). Principle 2 : You should decide your architecture first and then do the coding. Architecture involves phase : requirements, design , code and test. All these phases connect and architecture is the backbone. The common architectural model is waterfall model, iterative model etc. Principle 3: You should make proper classes for your software. The objects should be designed in such a way that it is easier to manage data while designing the software(easily retrievable and usable). Principle 4: You should make functions in your code. Each function should perform one single task and easier to link the data through them. Attach proper methods to each object you will design. Principle 5: It talks about the front end of your software the user interface(GUI), design it simple to use by user Principle 6: That means each function should be designed in such a way that it carries out its own single task . One function should not be controlled by another function. Functions only exchange data among them , no share of control flags etc between them

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote