1/64
Flashcards covering key vocabulary from lecture notes on Requirements Engineering, Data & Process Modeling, and Object Modeling in Systems Analysis and Design.
Name | Mastery | Learn | Test | Matching | Spaced |
---|
No study sessions yet.
System requirement
A characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users.
Requirements engineering
Composed of gathering, representing, validating, and verifying requirements to understand, describe, and agree on the problem.
Functional requirement
A statement of the services a system provides.
Non-functional requirement
A statement of operational system constraints.
Requirement challenges
Include imprecision (due to natural language), agreement (on exact meaning), and creep (rapidly changing requirements).
Scalability
Refers to a system’s ability to handle increased business volume and transactions in the future.
Security
Crucial for networked systems, it has changed from a non-functional requirement to a functional requirement.
Total cost of ownership (TCO)
Identification and documentation of indirect expenses contributing to the total cost of a system.
Joint application development (JAD)
A user-oriented technique for fact-finding and requirements engineering, involving iterative sessions facilitated by a moderator.
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.
Agile methods
Attempt to develop a system incrementally by building prototypes and constantly adjusting them to user requirements, emphasizing continuous feedback.
Scrum
An agile method that involves interaction with specific roles for agile team members.
Requirements elicitation (gathering)/Fact-finding
The first step in the requirements engineering process, involving collecting information using various techniques.
Interview
A planned meeting during which the analyst obtains information from another person.
Observation
A fact-finding technique allowing the analyst to verify statements made in interviews and determine whether procedures operate as described.
Questionnaire (survey)
Contains several standard questions that can be sent to many individuals to obtain information.
Brainstorming
A small group discussion of a specific issue, which can be structured or unstructured.
Sampling
A technique for collecting documents, such as systematic, stratified, or random sampling.
Scenario (also known as use case)
Describes a specific situation in which a system interacts with an end user or another system.
Functional decomposition diagram (FDD)
A top-down representation of a function or process.
Business process model (BPM)
Represents one or more business processes.
Data flow diagram (DFD)
Can be used to show how the system stores, processes, and transforms data.
Unified Modeling Language (UML)
A widely used modeling technique for visualizing and documenting software systems design.
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).
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.
Logical model
Shows what the system must do, regardless of how it will be implemented physically.
Physical model
Describes how the system will be constructed.
Process (DFD symbol)
A DFD symbol that contains business logic, transforms data, and produces the required results.
Data flow (DFD symbol)
A path for data to move from one part of the information system to another.
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.
Entity (DFD symbol)
A DFD symbol representing an external entity (source or sink) that provides data to the system or receives output from it.
Context diagram
A top-level view of an information system that shows the system’s boundaries and scope, represented by a single process 0.
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.
Leveling (DFDs)
Drawing increasingly detailed diagrams until all functional primitives are identified.
Balancing (DFDs)
Maintains consistency among DFDs by ensuring that input and output data flows align properly.
Data dictionary
Contains information about data, such as its meaning, relationships to other data, origin, usage, and format.
Data element
Also called a data item or field, which is documented in the data dictionary.
Record (Data dictionary)
A data structure containing related data elements stored and processed together, documented in the data dictionary.
Process description
Documents the details of a functional primitive and represents a specific set of processing steps and business logic.
Modular design
Based on combinations of three logical structures (control structures): sequence, selection, and iteration.
Structured English
A subset of standard English that describes logical processes clearly and accurately using the three building blocks of sequence, selection, and iteration.
Decision table
A logical structure that shows every combination of conditions and outcomes, best for describing complex sets of conditions.
Decision tree
A graphical representation of conditions, actions, and rules found in a decision table, showing the logic structure in a horizontal form.
Object-oriented (O-O) analysis
Describes an information system by identifying things called objects.
Object
Represents a real person, place, event, or transaction in an information system.
Attributes (Object)
Characteristics that describe an object.
State (Object attribute)
An adjective that describes an object’s current status.
Methods (Object)
Tasks or functions that the object performs when it receives a message.
Messages (Object)
How objects communicate and interact with each other within a system, invoking behaviors and exchanging information.
Polymorphism
Allows objects of different classes to respond differently to the same message (method call).
Class
A group or category of similar objects, defining their properties (attributes) and actions (methods).
Subclass
More specific categories into which objects within a class can be grouped.
Superclass
A more general category to which a class can belong.
Inheritance
The strongest relationship among objects, enabling a child object to derive one or more of its attributes from a parent object.
Use case (UML)
Represents the steps in a specific business function or process, symbolized by an oval.
System boundary (UML)
Represented by a rectangle in a use case diagram, showing what is included in the system.
Use case diagram (UML)
A visual summary of several related use cases within a system or subsystem.
Class diagram (UML)
Shows a use case’s object classes and relationships, including cardinality.
Cardinality (Class diagram)
Describes how instances of one class relate to instances of another class.
Sequence diagram (UML)
A dynamic model of a use case, showing the timing of interactions among classes during a specific period.
Lifeline (Sequence diagram)
Represents the time an object can interact with other objects in a use case.
Focus (Sequence diagram)
A narrow vertical shape that covers the lifeline, indicating when an object sends or receives a message.
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.
Activity diagram (UML)
Resembles a horizontal flowchart that shows actions and events as they occur.
CASE tools
Computer-Aided Software Engineering tools (e.g., Visio) used to record and document information and support object modeling.