Requirements Gathering

The systems development process transforms the existing (as is) system into the proposed (to be) system.

due to problems with requirements

Small batches of requirements can be identified and implemented incrementally like itrative

avoid risk convert high level business requirements (from the system request) into detailed requirements that can be used as inputs for creating model

high to low require

what’s require

detail

fuctional user and do non - system persisty like AES encrypt, can be test

non Look and feel requirements (fun, motivating, etc.) no subjective language standers or guidlines pagelayout, color patterns, follow those and reach some effact, can be tested

May be prioritize, sometimes may overwhemled

Defines the scope of the system – useful to avoid scope creep

functional

noun - verb sb is doing sth

managment

do lab before the lab time

bring lab1 and lab2

relay on our system

is fuction requure don not have numbers?

non-functional method can be tested

everyone need to kown nuon-name, need to be it’s full name

Important Concepts of OOAD UseCases

we dont care what happen in black box, we put input and get output

encapsulation called information hiding, have to use a method 头 change data.

secure and easy to dubug

polymorphism, give one message, have different correspond result

UML

Use-case v-n no confusion sys boundry/ sys name.