System analysis discussions

1. Example of a KM (Knowledge Management) system

A KM system stores, organizes, and shares organizational knowledge.
Example: An internal SharePoint/Confluence portal with wikis, SOPs, FAQs, and search. Employees upload documents, tag them, search past solutions, and reuse knowledge instead of reinventing it.

2. AI implementation issue

A common issue is data quality and bias. If training data is incomplete, skewed, or biased, the AI will make unfair or inaccurate decisions, which can be hard to detect and even harder to fix once deployed.

3. What would be an innovative system?

An innovative system combines new tech + new business value.
Example: A retail system that uses computer vision to track items a customer picks up in a store and auto-checks them out (like cashier-less checkout), reducing friction and generating detailed behavioral data.

4. AI implementation – pros and cons

Pros:

• Automates repetitive tasks (cost/time savings)

• Can improve accuracy (e.g., fraud detection, predictions)

• Enables personalization at scale (recommendation engines)

Cons:

• Requires lots of good-quality data

• Can be opaque (“black box”) and hard to explain

• Risk of bias, privacy concerns, and regulatory issues

5. GIS implementation example

Example: A city uses a GIS system to map water pipes, power lines, and traffic patterns.
They overlay accident hotspots with road design and traffic volume to decide where to add signals, change speed limits, or fix infrastructure. GIS helps visualize spatial relationships and supports planning decisions.

6. Software maintenance issue

Issue: A library used by an app reaches end-of-life and has a critical security vulnerability.
Impact: System becomes vulnerable to attacks, compliance risk, and potential downtime.
Response: Patch or upgrade the library, regression test critical functions, and deploy the change with a rollback plan.

7. Change management issue

Example: Implementing a new ERP system but not involving end users early.
Result: Users feel forced, resist the system, stick to Excel, and the project fails to deliver benefits. Better change management would include communication, training, super-user champions, and phased adoption

8. Cloud migration case – example

Example case: A company moves its on-prem CRM to a SaaS cloud platform.
Benefits: Less hardware to manage, easier scaling, faster feature updates.
Challenges: Data migration complexity, integration with legacy systems, retraining users, and dealing with new security/compliance responsibilities.

9. Difference between test strategy and test case

• Test strategy: High-level document that describes the overall testing approach (what types of testing, environments, tools, responsibilities, entry/exit criteria).

• Test case: A specific, detailed scenario with steps, inputs, expected results, and pass/fail criteria for a particular feature.

---

10. Application example + architecture pros/cons

Example: E-commerce web app using a three-tier architecture (presentation, application, database).

Pros:

• Clear separation of concerns

• Easier to scale web and app tiers independently

• Simplified maintenance and role specialization

Cons:

• Can introduce latency between tiers

• More infrastructure and configuration

• Not as flexible or granularly scalable as microservices

11. Performance and security issues for an architecture

Performance issues:

• Too many network hops (chatty calls between services)

• Poor database design causing slow queries

• Bottlenecks in a single node or tier (no load balancing)

Security issues:

• Unencrypted data in transit or at rest

• Weak authentication/authorization between components

• Poorly segmented network making lateral movement easier for attackers

12. How dates affect programming systems

• Formats: Different regions use different formats (MM/DD/YYYY vs DD/MM/YYYY), causing parsing errors.

• Calculations: Time zones, leap years, daylight saving, and end-of-month logic matter for billing, subscriptions, and reports.

• Triggers: Jobs scheduled “at midnight” may behave oddly around DST changes; date-based triggers might fire too early/late if time zones aren’t handled properly.

13. Examples of codes we commonly use

• ZIP/Postal codes – reference geographic areas for shipping, taxes, and marketing.

• Product codes/SKUs – reference specific products to track inventory and sales.

• Country codes (ISO) – reference countries in shipping, localization, and reporting.

• Status codes – for orders (NEW, SHIPPED, CANCELLED), used to drive workflow logic.

14. Ethical issues in database planning

Yes, there are.

• Data minimization: Only storing what’s necessary.

• Access control & purpose limitation: Who can see what, and why.
  Storing highly sensitive personal data (e.g., medical info) in the same DBMS as salary/benefits is risky: a breach or misconfigured access could expose everything. Best practice is segregation of data, least-privilege access, and extra protections for highly sensitive sets.

15. Two important issues to know for a midterm (systems/dev context)

You can choose, but two big ones are:

1. Requirements quality – clear, testable, prioritized requirements are the foundation of successful systems.

2. Lifecycle models (waterfall vs agile) – understanding when each is appropriate and how they affect planning, risk, and user involvement.

16. How will AI impact systems development?

Automate parts of coding, testing, and documentation (code suggestions, test case generation).

• Improve requirements analysis with pattern detection in user stories and logs.

• Introduce new roles (AI trainers, model governors) and more focus on data and ethics.

• Systems will increasingly include AI components themselves (recommendations, predictions).

17. New system for a real estate firm using O-O with no experience

How to begin:

• Identify key objects: Property, Agent, Client, Listing, Offer, Contract.

• Define their attributes and methods (e.g., Property.show(), Listing.publish()).

• Draw class diagrams and use cases before coding.

Difference vs structured analysis:

• Structured analysis focuses on processes and data flows (DFDs, process decomposition).

• O-O focuses on objects and their interactions (classes, messages, encapsulation).

• In O-O you organize around entities with behavior, not just functions and data files.

18. League Bowlers – possible states in a state diagram

Possible states for a League Bowler object:

• Registered

• Active (bowling this season)

• Suspended/Inactive (temporarily not playing)

• Left League

• Rejoined

If a bowler quits, they move to Left League/Inactive. If they rejoin in a later season, they transition back to Active, perhaps with a new season record but keeping historical stats linked.

19. How to tell if UML is correct (not just pretty)

• The model is consistent (no contradictions between diagrams).

• It is traceable to requirements and use cases.

• Stakeholders can walk through real scenarios using the diagrams and everything makes sense.

• It can be used as a basis for design/code without ambiguity or missing pieces.

20. Attribute of enterprise architecture (EA)

Example attribute: Alignment.
EA should align technology, data, and processes with the organization’s strategy. You can see alignment when projects trace back to business capabilities, and EA standards guide what platforms, data models, and integrations are allowed.

21. Attributes of requirements & how to verify/validate

Common attributes: Correct, complete, consistent, feasible, testable, traceable, unambiguous, prioritized.

• Verification (building the requirement right): reviews, checklists, inspections, making sure the requirement is clear, testable, and consistent with other requirements.

• Validation (building the right thing): prototypes, demos, user walkthroughs, acceptance tests tied to real business scenarios.

22. Group meeting advantages & disadvantages

Advantages:

• Efficient – hear from many stakeholders at once

• Stimulates ideas (people build on each other’s comments)

• Helps find conflicts and common ground early

Disadvantages:

• Dominant personalities can skew results

• Some participants may stay quiet or feel intimidated

• Harder to go deep into individual concerns; can drift off topic

23. Home improvement shows – common project management mistakes

Amateur homeowners often:

• Underestimate time and cost (no realistic schedule or budget)

• Add scope (“might as well do this too”) without adjusting time/budget

• Skip risk planning (e.g., not planning for hidden damage or permits)

• Fail at stakeholder communication (e.g., not aligning with spouse/contractor expectations)

24. Using qualitative vs quantitative risk analysis

• Qualitative risk analysis (high/medium/low likelihood & impact):
  Used for prioritizing risks, deciding where to focus attention, what to monitor closely, and which risks require mitigation plans.

• Quantitative risk analysis (numbers, probabilities, expected monetary value):
  Used for cost/schedule decisions, contingency reserves, “go/no-go” analyses, and comparing alternative strategies based on quantified risk exposure.

25. Reconciling short-term vs long-term project benefits

You’d typically:

• Build a portfolio view: score projects on short-term ROI and long-term strategic value.

• Balance “quick wins” that build credibility and cash flow with “strategic bets” that enable future capabilities.

• Sometimes split a long-term project into phases: early phases deliver visible value, later phases deliver the full long-term benefits.

26. VP of accounting wants to bypass request procedure – comments

You might say:

• The procedure exists to ensure prioritization, feasibility, and alignment, and to avoid chaos and rework.

• Skipping steps for one department sets a precedent and could overload IT, harming everyone.

• Offer a compromise: streamline the process (templates, fast-track criteria) for urgent, high-impact requests, while still following essential analysis steps.

27. How a company’s financial status affects systems projects

• If finances are strong, the company can invest in larger, strategic projects and experiment with new tech.

• If finances are tight, projects are more focused on cost savings, quick payback, and lower risk; some projects may be delayed, downsized, or canceled.

• Budget constraints affect staffing, tools, training, and vendor choices.

28. Waterfall vs Agile and criteria

Waterfall:

• Linear phases (requirements → design → build → test → deploy)

• Works better when requirements are stable and well-known

• Heavy documentation, less frequent stakeholder feedback

Agile:

• Iterative, incremental delivery in sprints

• Emphasizes changing requirements, frequent feedback, working software

• Smaller batches, more collaboration

Criteria:

• Use waterfall when scope is stable, compliance is heavy, and change is expensive.

• Use agile when requirements are evolving, user feedback is critical, and delivering value early is important.

29. Difference between efficiency and effectiveness

• Effectiveness: Doing the right things – achieving the desired outcome.

  • Example: A system that actually improves customer satisfaction.

• Efficiency: Doing things the right way with minimal waste (time, cost, resources).

  • Example: Processing 1,000 transactions per minute with minimal CPU usage.

A system can be efficient but not effective (fast, but solving the wrong problem).