Week3 Lecture
Week3 Lecture
Requirement Engineering
Input: A set of ideas in the clients minds Output: Formal document used for design Activities (Discuss, Analyze, Present)
Requirement Gathering
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
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
These can be documented with an Entity Relationship Diagram (ERD) (lickety-split with Visio) The eventual result is a database structure or object model