Systems Analysis and Design Flashcards: Requirements, Data & Process, and Object Modeling
Chapter 4: Requirements Engineering
System Requirements
Definition: A characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users.
Requirements Engineering Activities:
Gathering requirements: Understanding the problem.
Representing requirements: Describing the problem.
Validating and verifying requirements: Agreeing on the problem.
Classification of System Requirements:
Functional Requirement: A statement of the services a system provides.
Example: "A website shall report online volume statistics every four hours and hourly during peak periods."
Non-functional Requirement: A statement of operational system constraints.
Example: "The system must support 25 users online simultaneously."
Knowledge Check Answer: "The system shall respond within 2 seconds" is a non-functional requirement.
Requirement Challenges:
Imprecision: Requirements are often imprecise due to being represented using natural language.
Agreement: Difficulty in getting all stakeholders to agree on the exact meaning of requirement statements.
Creep: Business changes can lead to changing requirements, resulting in "feature creep," which causes problems for system analysts.
Additional Considerations for Systems Analysts:
Scalability: A system's ability to handle increased business volume and transactions in the future.
Security: Crucial for networked systems; has evolved from a non-functional to a functional requirement.
Total Cost of Ownership (TCO): System developers must identify and document indirect expenses contributing to TCO.
Team-Based Techniques
These techniques facilitate fact-finding and requirements engineering.
Joint Application Development (JAD):
Definition: A user-oriented technique for fact-finding and requirements engineering.
Process:
Sessions are planned by selecting participants, defining the scope, and setting goals/objectives.
Facilitated by a trained moderator.
Information is organized and documented clearly.
Often conducted iteratively for continuous refinement.
Typical JAD Participants and Roles:
JAD project leader: Develops agenda, facilitates, leads the session.
Top management: Provides enterprise-level authorization and support.
Managers: Provide department-level support and understanding of business functions.
Users: Provide operational-level input on current operations, desired changes, and day-to-day tasks.
Systems analysts and other IT staff: Provide technical assistance (security, backup, hardware, software, network).
Recorder: Documents results, assists in building system models and CASE tool documentation.
Benefits:
Stakeholder involvement.
Improved communication.
Time and cost efficiency.
Accelerated decision-making.
Reduced rework.
Rapid Application Development (RAD):
Definition: An iterative and incremental team-based approach focused on quickly developing high-quality software.
Process:
Follows an iterative and incremental development.
Emphasizes continuous, active user involvement.
Uses prototyping for working models.
Projects are "timeboxed" with fixed time frames for each phase.
Encourages collaborative development and reuse of components.
Four Phases of RAD Model:
Requirements planning.
User design (continuous interaction with construction).
Construction (continuous interaction with user design).
Cutover.
Objective: To cut development time and expense by involving users in every phase.
Benefits:
Faster time to market.
Improved user satisfaction.
Increased flexibility and adaptability.
Risk mitigation.
Enhanced collaboration.
Agile Methods:
Definition: Develops a system incrementally by building prototypes and constantly adjusting them to user requirements.
Characteristics:
Emphasizes continuous feedback; each incremental step is affected by previous learning.
Scrum: An agile method involving mental interaction with specific roles for team members.
Benefits:
Adaptability to changing requirements.
Continuous customer involvement.
Early and frequent delivery of value.
Increased transparency and visibility.
Continuous improvement and quality focus.
Requirements Elicitation (Gathering/Fact-Finding)
Definition: The first step in the requirements engineering process, involving collecting information.
Techniques Used:
Interviews.
Document review.
Observation.
Surveys and questionnaires.
Sampling and research.
Sample Questions Shifting Focus (Current to Proposed System):
Who?: Who does it? Why? Who should do it?
What?: What is done? Why? What should be done?
Where?: Where is it done? Why? Where should it be done?
When?: When is it done? Why? When should it be done?
How?: How is it done? Why? How should it be done?
Interviews
Definition: A planned meeting where an analyst obtains information from another person.
Steps in the Interview Process:
Determine the people to interview (look beyond formal organizational charts).
Establish objectives for the interview.
Develop interview questions.
Prepare for the interview (e.g., initial message to department head).
Conduct the interview.
Document and evaluate the interview (e.g., confirmation message).
Other Elicitation Techniques
Document Review:
Helps understand how the current system is supposed to work.
Observation:
Fact-finding technique to verify interview statements and determine if procedures operate as described.
Provides additional perspective and understanding; can reveal discrepancies between documentation, interviews, and actual practice.
Questionnaires (Surveys):
Definition: Contains standard questions; can be sent to many individuals.
Purpose: Obtain information on workloads, reports, transaction volumes, job duties, difficulties, and opinions.
Interviews vs. Questionnaires:
Interviews are more familiar and personal but costly and time-consuming.
Questionnaires allow many people to provide input on their own time; people may offer more candid responses.
The analyst should choose the best technique for the situation.
Brainstorming:
Definition: Small group discussion of a specific issue.
Structured Brainstorming: Participants speak in turn or pass.
Unstructured Brainstorming: Anyone can speak at any time.
Sampling:
Collecting documents using specific selection methods.
Systematic Sampling: Selecting every tenth customer.
Stratified Sample: Selecting five customers from each of four postal codes.
Random Sample: Selecting any 20 customers.
Research:
Sources: Internet, IT magazines, books for background, technical material, and industry trends.
Site Visit: Visiting a physical location to observe a system used elsewhere, noting problems, limitations, and vendor support.
Requirements Elicitation in Agile Projects
Characteristics:
Iterative and incremental progress.
Collaboration.
Adaptive process.
Backlog management.
Validation and verification.
Process:
Performed using variations of interviews.
Requirements begin as features, which are split into smaller user stories.
User stories are distilled into scenarios, often using storyboards.
Scenario (Use Case): Describes a specific situation where a system interacts with an end user or another system.
Representing Requirements
Once gathered, requirements must be recorded.
Documentation Principles:
Record information as soon as it is obtained.
Use the simplest recording method possible.
Record findings so someone else can understand them.
Organize documentation for easy access to related material.
Representation Techniques:
Natural Language: Most requirements are represented using unstructured natural language.
Can be stored in simple files, databases, or Excel spreadsheets.
Structured natural language can be stored on index cards.
Formal techniques based on mathematics can represent complex requirements.
Diagrams: For visual representation.
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): Shows how the system stores, processes, and transforms data.
Models: Provide a more formal representation.
Unified Modeling Language (UML): Widely used for visualizing and documenting software systems design.
SysML: A dialect of UML, standard for Model-Based Systems Engineering (MBSE).
Use Case Diagram: Visually represents interaction between users and the information system.
Sequence Diagram: Shows the timing of interactions between objects.
Validation and Verification (V&V)
Concern: Demonstrating that the requirements define the system the customer wants.
Essential Questions:
Validation: Are the correct requirements stated?
Verification: Are the requirements stated correctly?
Requirements Attributes to Check:
Validity, consistency, completeness, realism, verifiability, comprehensibility, traceability, and adaptability.
Techniques for V&V:
Requirements review.
Prototyping.
Test-case generation.
Automated consistency analysis.
Tools for Requirements Engineering Activities
Productivity Software: Used to record and document information.
Microsoft Word, Excel, database management software, presentation graphics software, collaboration software, graphic modeling tools.
Example: Evernote for information management.
Specialized Tools:
Example: IBM Engineering Requirements Management DOORS Family for optimizing requirements communication, collaboration, and verification.
Traceability:
Definition: The ability to follow a requirement backward to its origins and forward through the SDLC to link design documents, code fragments, and test artifacts.
Importance: Helps determine if requirements are consistent and complete, satisfying user needs. (Activity 4-3 Answer)
Chapter 5: Data & Process Modeling
Logical versus Physical Models
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.
Four-Model Approach:
A physical model of the current system.
A logical model of the current system.
A logical model of the new system.
A physical model of the new system.
Relationship: A logical model defines what the system does, and later a physical model defines how it will be built (Activity 5-1 Answer).
Data Flow Diagrams (DFD)
Definition: Uses various symbols to show how the system transforms input data into useful information.
Purpose: Shows how data moves through an information system.
What it doesn't show: Program logic or processing steps.
Outcome: A set of DFDs provides a logical model showing what the system does, not how.
Data Flow Diagram Symbols
DFDs use four basic symbols representing processes, data flows, data stores, and entities.
Versions: Gane and Sarson symbols (used in textbook examples) and Yourdon symbols are popular.
Process Symbols:
Representation: A rectangle with rounded corners (Gane and Sarson).
Function: Contain business logic, transform data, produce results.
Naming Convention: Verb followed by a singular noun (e.g., APPLY RENT PAYMENT).
Black Box Concept: Inputs, outputs, and functions are known, but underlying logic is hidden.
Correct Use: Data flows must connect processes to data stores or entities (e.g.,
DATA FLOWintoPROCESS,PROCESSoutDATA FLOW).Incorrect Use: Processes never directly connect to other processes without an intervening data flow or external entity.
Data Flow Symbols:
Representation: A line with a single or double arrowhead.
Function: Path for one or more data items to move between system parts.
Naming Convention: Singular noun and an adjective if needed (e.g.,
ORDER CONFIRMATION).
Data Store Symbols:
Representation (Gane and Sarson): A flat rectangle, open on the right, closed on the left.
Function: Represents data stored for later use by processes.
Naming Convention: Plural name (noun + adjectives if needed) (e.g.,
CUSTOMERS,ORDERS).Connection Rule: Must be connected to a process with a data flow.
Correct Use: Data flows in/out of data store to/from a process.
Incorrect Use: Data stores never connect directly to entities or other data stores without a process.
Entity Symbols (External Entities / Terminators):
Representation: A rectangle, possibly shaded.
Function: Represents external entities that provide data to (source) or receive output from (sink) the system.
DFD Scope: Shows only external entities, not internal system components.
Correct Use: Data flows connect entities to processes.
Incorrect Use: Entities never connect directly to data stores or other entities without a process.
Drawing Data Flow Diagrams
Guidelines:
Draw the context diagram to fit on one page.
Use the information system's name as the process name in the context diagram.
Use unique names within each set of symbols.
Do not cross lines.
Provide a unique name and reference number for each process.
Ensure the model is accurate, easy to understand, and meets user needs.
Drawing a Context Diagram
Definition: A top-level view showing the system's boundaries and scope.
Steps:
Place a single process symbol (Process 0) in the center, representing the entire system.
Place system entities around the perimeter.
Use data flows to connect entities to the central Process 0.
Drawing a Diagram 0 DFD
Definition: Provides an overview of all components interacting to form the overall system.
Relationship to Context Diagram: A more detailed view (exploded, partitioned, or decomposed) of Process 0 from the context diagram.
Contents: Shows major internal processes, data flows, and data stores.
Connections: All connections into and out of Process 0 from the context diagram must be retained.
Diverging Data Flow: Occurs when the same data travels to two or more locations.
Difference from context diagram: Context diagram has only one process (Process 0). Diagram 0 is an exploded version of Process 0 showing internal major processes, data flows, and data stores, while repeating entities and data flows from the context diagram (Activity 5-2 Answer).
Drawing Lower-Level DFDs
Leveling: Drawing increasingly detailed diagrams until all functional primitives are identified.
Functional primitives are elementary processes that do not need to be broken down further.
Balancing: Maintaining consistency between DFDs by ensuring input and output data flows align properly across levels.
Parent DFD: A higher-level DFD that is then