Systems Analysis and Design Flashcards: Requirements, Data & Process, and Object Modeling

0.0(0)
studied byStudied by 0 people
0.0(0)
linked notesView linked note
full-widthCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/64

flashcard set

Earn XP

Description and Tags

Flashcards covering key vocabulary from lecture notes on Requirements Engineering, Data & Process Modeling, and Object Modeling in Systems Analysis and Design.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

65 Terms

1
New cards

System requirement

A characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users.

2
New cards

Requirements engineering

Composed of gathering, representing, validating, and verifying requirements to understand, describe, and agree on the problem.

3
New cards

Functional requirement

A statement of the services a system provides.

4
New cards

Non-functional requirement

A statement of operational system constraints.

5
New cards

Requirement challenges

Include imprecision (due to natural language), agreement (on exact meaning), and creep (rapidly changing requirements).

6
New cards

Scalability

Refers to a system’s ability to handle increased business volume and transactions in the future.

7
New cards

Security

Crucial for networked systems, it has changed from a non-functional requirement to a functional requirement.

8
New cards

Total cost of ownership (TCO)

Identification and documentation of indirect expenses contributing to the total cost of a system.

9
New cards

Joint application development (JAD)

A user-oriented technique for fact-finding and requirements engineering, involving iterative sessions facilitated by a moderator.

10
New cards

Rapid Application Development (RAD)

An iterative and incremental team-based approach to systems analysis and design focusing on quickly developing high-quality software applications, emphasizing user involvement and prototyping.

11
New cards

Agile methods

Attempt to develop a system incrementally by building prototypes and constantly adjusting them to user requirements, emphasizing continuous feedback.

12
New cards

Scrum

An agile method that involves interaction with specific roles for agile team members.

13
New cards

Requirements elicitation (gathering)/Fact-finding

The first step in the requirements engineering process, involving collecting information using various techniques.

14
New cards

Interview

A planned meeting during which the analyst obtains information from another person.

15
New cards

Observation

A fact-finding technique allowing the analyst to verify statements made in interviews and determine whether procedures operate as described.

16
New cards

Questionnaire (survey)

Contains several standard questions that can be sent to many individuals to obtain information.

17
New cards

Brainstorming

A small group discussion of a specific issue, which can be structured or unstructured.

18
New cards

Sampling

A technique for collecting documents, such as systematic, stratified, or random sampling.

19
New cards

Scenario (also known as use case)

Describes a specific situation in which a system interacts with an end user or another system.

20
New cards

Functional decomposition diagram (FDD)

A top-down representation of a function or process.

21
New cards

Business process model (BPM)

Represents one or more business processes.

22
New cards

Data flow diagram (DFD)

Can be used to show how the system stores, processes, and transforms data.

23
New cards

Unified Modeling Language (UML)

A widely used modeling technique for visualizing and documenting software systems design.

24
New cards

Requirements validation and verification (V&V)

Concerned with demonstrating that the requirements define the system the customer wants, answering 'Are the correct requirements stated?' (validation) and 'Are the requirements stated correctly?' (verification).

25
New cards

Traceability

The ability to follow a requirement backward to its origins and forward through the SDLC to link design documents, code fragments, and test artifacts.

26
New cards

Logical model

Shows what the system must do, regardless of how it will be implemented physically.

27
New cards

Physical model

Describes how the system will be constructed.

28
New cards

Process (DFD symbol)

A DFD symbol that contains business logic, transforms data, and produces the required results.

29
New cards

Data flow (DFD symbol)

A path for data to move from one part of the information system to another.

30
New cards

Data store (DFD symbol)

A DFD symbol used to represent data that the system stores because one or more processes need to use it later.

31
New cards

Entity (DFD symbol)

A DFD symbol representing an external entity (source or sink) that provides data to the system or receives output from it.

32
New cards

Context diagram

A top-level view of an information system that shows the system’s boundaries and scope, represented by a single process 0.

33
New cards

Diagram 0 DFD

Provides an overview of all the components that interact to form the overall system, zooming in on the context diagram's process 0 to show major internal processes, data flows, and data stores.

34
New cards

Leveling (DFDs)

Drawing increasingly detailed diagrams until all functional primitives are identified.

35
New cards

Balancing (DFDs)

Maintains consistency among DFDs by ensuring that input and output data flows align properly.

36
New cards

Data dictionary

Contains information about data, such as its meaning, relationships to other data, origin, usage, and format.

37
New cards

Data element

Also called a data item or field, which is documented in the data dictionary.

38
New cards

Record (Data dictionary)

A data structure containing related data elements stored and processed together, documented in the data dictionary.

39
New cards

Process description

Documents the details of a functional primitive and represents a specific set of processing steps and business logic.

40
New cards

Modular design

Based on combinations of three logical structures (control structures): sequence, selection, and iteration.

41
New cards

Structured English

A subset of standard English that describes logical processes clearly and accurately using the three building blocks of sequence, selection, and iteration.

42
New cards

Decision table

A logical structure that shows every combination of conditions and outcomes, best for describing complex sets of conditions.

43
New cards

Decision tree

A graphical representation of conditions, actions, and rules found in a decision table, showing the logic structure in a horizontal form.

44
New cards

Object-oriented (O-O) analysis

Describes an information system by identifying things called objects.

45
New cards

Object

Represents a real person, place, event, or transaction in an information system.

46
New cards

Attributes (Object)

Characteristics that describe an object.

47
New cards

State (Object attribute)

An adjective that describes an object’s current status.

48
New cards

Methods (Object)

Tasks or functions that the object performs when it receives a message.

49
New cards

Messages (Object)

How objects communicate and interact with each other within a system, invoking behaviors and exchanging information.

50
New cards

Polymorphism

Allows objects of different classes to respond differently to the same message (method call).

51
New cards

Class

A group or category of similar objects, defining their properties (attributes) and actions (methods).

52
New cards

Subclass

More specific categories into which objects within a class can be grouped.

53
New cards

Superclass

A more general category to which a class can belong.

54
New cards

Inheritance

The strongest relationship among objects, enabling a child object to derive one or more of its attributes from a parent object.

55
New cards

Use case (UML)

Represents the steps in a specific business function or process, symbolized by an oval.

56
New cards

System boundary (UML)

Represented by a rectangle in a use case diagram, showing what is included in the system.

57
New cards

Use case diagram (UML)

A visual summary of several related use cases within a system or subsystem.

58
New cards

Class diagram (UML)

Shows a use case’s object classes and relationships, including cardinality.

59
New cards

Cardinality (Class diagram)

Describes how instances of one class relate to instances of another class.

60
New cards

Sequence diagram (UML)

A dynamic model of a use case, showing the timing of interactions among classes during a specific period.

61
New cards

Lifeline (Sequence diagram)

Represents the time an object can interact with other objects in a use case.

62
New cards

Focus (Sequence diagram)

A narrow vertical shape that covers the lifeline, indicating when an object sends or receives a message.

63
New cards

State transition diagram (UML)

Shows how an object changes from one state to another depending on events that affect the object, with states appearing as rounded rectangles.

64
New cards

Activity diagram (UML)

Resembles a horizontal flowchart that shows actions and events as they occur.

65
New cards

CASE tools

Computer-Aided Software Engineering tools (e.g., Visio) used to record and document information and support object modeling.