System Design Specification Flashcards

1
Q

Derives from a comprehensive blueprint in creating software; this includes a software’s details with its functionality, development timeline, and goals.

A

System Design Specifications document (SDS)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Also focuses on the idea that security, maintainability, usability and reliability must be aligned with this and with the use of stories, use cases and data models to ensure a comprehensive design.

A

Nonfunctional requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

KEY PEOPLE IN THE DESIGN PROCESS

A

Software Architects
System Designers
UI/UX Designers
Database Architects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

They define the overall system architecture and make high-level design decisions.

A

Software Architects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

They translate architectural concepts into detailed system designs, ensuring alignment with architectural principles.

A

System Designers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

They focus on the user interface and experience, designing layouts and elements to enhance usability.

A

UI/UX Designers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

They handle the system’s database architecture, defining data models and optimizing performance.

A

Database Architects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

A
  1. Understand the Requirements
  2. Identify Design Constraints
  3. Define Quality Attributes
  4. Identify Control Classes
  5. Develop Sequence Diagrams
  6. Document Design Decisions
  7. Review and Iterate
  8. Finalize the Design Specifications
  9. Maintain Traceability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

It is crucial to understand the project requirements before
diving into design specifications.

A

Understand the Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

Analyze any design constraints, including technology stack, platform compatibility, budget, and existing architectural patterns.

A

Identify Design Constraints

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

Secure, reliable, maintainable, and usable features should be identified and prioritized.

A

Define Quality Attributes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

Coordinate interactions between components and enforce business rules.

A

Identify Control Classes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

Using user stories or use cases, in creating this diagrams to illustrate how classes interact and how actions flow within the system.

A

Develop Sequence Diagrams

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

By maintaining this documentation, future references can be made and stakeholders can be kept informed about the progress of the project.

A

Document Design Decisions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

Review design specifications with stakeholders, ensuring alignment with requirements and feasibility, and iterate based on feedback for necessary adjustments.

A

Review and Iterate

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

It should be comprehensive enough to guide the implementation phase, but should also be flexible enough to adapt to changes in requirements or constraints as they arise

A

Finalize the Design Specifications

17
Q

STEPS IN CREATING DESIGN SPECIFICATIONS

To ensure alignment between the implemented system and the intended design, between design specifications and requirements

A

Maintain Traceability

18
Q

Serves as the final plan in developing a system. It must include as much information as possible as it serves as the guideline for the developers, testers, and other professionals in the later stages of SDLC.

A

System Design Specifications (SDS)

19
Q

The following information can be found in the SDS:

Note that the SDS do not exactly have all these information and
varies depending on the system being developed and the business it serves

A

Business Rules and Requirements
Scope of the Project
People Involved
Work and Task Assignments
Features and Functionalities
Interface Design
Timetables and Schedule

Costs
Possible Issues and Solutions
Priority Levels
Models, Diagrams, and Charts
Architecture and Module details
Algorithms and Pseudocode
Testing Plans

20
Q

There are several methods of presenting information to enhance clarity and communication with people in the next stages of the development life cycle. It is a help in having an organized and stable workflow for developers and testers.

A

VISUAL AIDS IN SYSTEM DESIGN

21
Q

What are some of the Visual Aids in System Design?

A
  1. Design Specifications Table
  2. Wireframes
  3. Use Case Diagram
  4. Activity Diagram
  5. Class Diagram
  6. Physical Database Model
22
Q

for organizing requirements and specifications in a tabular format.

A

Design Specifications Table

23
Q

Drawn for planning the UI design of a system. Guides the UI developers to avoid redesigns in the interface.

A

Wireframes

24
Q

Used to depict the users’ interactions with the system. Important to use if there are different types of users with different accessible functionalities

A

Use Case Diagram

25
Q

Also known as an object-oriented flowchart, this diagram is used to model behaviors within the system. Used when there are multiple objects perceived in the system with multiple interactions with each other.

A

Activity Diagram

26
Q

Used to organize multiple classes in an object-oriented system. The attributes, methods and relationships between classes are depicted in this diagram. Bears similarities to a logical database model.

A

Class Diagram

27
Q

Used to model how the actual database architecture must look like. Includes the settings such as data type, key type, null allowed, etc.

A

Physical Database Model