Scribd
Upload
96 views

Week3 Lecture

System Analysis and Design - Part I Requirement Engineering System Engineering Data Modeling system engineering Input: a set of ideas in the client's minds Output: Formal document used for design activities (Discuss, Analyze, Present) Interaction with the client is crucial! clients don't usually think like systems people.

Uploaded by

api-218675166
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
96 views

Week3 Lecture

System Analysis and Design - Part I Requirement Engineering System Engineering Data Modeling system engineering Input: a set of ideas in the client's minds Output: Formal document used for design activities (Discuss, Analyze, Present) Interaction with the client is crucial! clients don't usually think like systems people.

Uploaded by

api-218675166
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 9

System Analysis and Design Part I

Requirement Engineering System Engineering Data Modeling

Requirement Engineering
Input: A set of ideas in the clients minds Output: Formal document used for design Activities (Discuss, Analyze, Present)

Requirement Requirement Requirement Requirement Requirement

Gathering Analysis Specification Validation Management

Sequence of activities- Figure 5.10

Requirement Gathering

Interaction with the client is the most important step


Questionnaires: Note very helpful because projects are always different from each other Interviews: Ask questions, get answers, and restate the requirements Facilitated Application Specification Techniques: Focus on objects, functions, and system constraints.

Requirement Analysis
Analysis between interviews in crucial! Clients dont usually think like systems people. It is necessary for the analysis team to work without the clients in between interviews to fully understand the requirements and clearly document them

Requirements Specification

The goal of analysis is to deliver formal documentation that explains


why the system is being built (this is done in the early stages) what data the new system will store and what functions it will help accomplish

Refining and managing requirements is an ongoing saga during a project.

Requirement Validation
Validation is done with the clients (owners) of the software Since the software owners frame the policies of the system, analysts must validate their interpretation of the requirements with them.

Requirement Management

Requirement supervision as the project begins and continues through the lifecycle
Changes in requirements Fulfillment of requirements

System Engineering
The focus of analysis and system engineering is on Activities that take place in a system (Functions) Objects involved in the activities Relationships between objects

Ex. A video store member rents a video and keeps it 1 day overdue. What are the objects? What are the events? What are the relationships?

System Models
Broad perspective of overall functionality Modeling Hierarchy

World Level: Entire business process Domain Level: Focus on domain of interest Element Level: Products Detailed Level: Components of each product

Software tools like Visio can help you whip one of these up lickety-split

Entities and Attributes

A primary goal of analysis is to identify


The major entities (objects) involved The attributes (fields) involved The relationships between the entities

These can be documented with an Entity Relationship Diagram (ERD) (lickety-split with Visio) The eventual result is a database structure or object model

You might also like