1. Requirements System design 2010 Autumn Morten Bo Nielsen Mon@eal.dk

2. Project background Vital questions Project owner Costumer User More on this later inthe course Is this a good metaphor for project backgrounds?System design - Mon@eal.dk 2 3. Analysis phaseSDLC phases Analysis phase Planning What to built? Analysis What should it do?Design What should it not do?Implementation Does this relate toproblem statements?System design - Mon@eal.dk 3 4. Requirements Project is done when requirements are fulfilled. Functional requirements What should the system be able to do? Non-functional requirements Extra stuff: Performance, company imposed constraints and other stuff. Be prepared for the question Why is that a requirement? Check background...System design - Mon@eal.dk4 5. Requirements - functional Process requirements What should the system do? Data/information requirements What should the system containThis is the requirements which define what the system should do.System design - Mon@eal.dk5 6. Requirements non-functional Operational Environment for proper operation. E.g. No direct sunlight. Performance Specific values of how well the system functions Security Cultural and political E.g. Must be CE certified.System design - Mon@eal.dk6 7. Gathering requirements How to identify theNowimprovement/featuresAs-is system Think long enough? Ask someone? Improvement Who decides the requirements? FutureTo-be systemSystem design - Mon@eal.dk7 8. Example Mashing example (again)System design - Mon@eal.dk 8 9. ExerciseYou are to built a remotecontrolled car. Decide on project owner, costumer and user Optional: Do a block diagram Discuss and decide on 10 requirements.System design - Mon@eal.dk9 10. Top-down or bottom-up Both ways work Result differ Mileage differ Recall the technician vs. engineer difference.System design - Mon@eal.dk10