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 in
the course
Is this a good metaphor for project
backgrounds?
System design - Mon@eal.dk 2
3. Analysis phase
SDLC phases
● Analysis phase
Planning ● What to built?
Analysis ● What should it do?
Design ● What should it not do?
Implementation ● Does this relate to
“problem 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.dk 4
5. Requirements - functional
● Process requirements
● What should the system do?
● Data/information requirements
● What should the system contain
This is the requirements which define
what the system should do.
System design - Mon@eal.dk 5
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.dk 6
7. Gathering requirements
● How to identify the
Now improvement/features
As-is system ● Think long enough?
● Ask someone?
Improvement
● Who decides the
requirements?
Future
To-be system
System design - Mon@eal.dk 7
8. Example
● Mashing example (again)
System design - Mon@eal.dk 8
9. Exercise
You are to built a remote
controlled car.
● Decide on project
owner, costumer and
user
● Optional: Do a block
diagram
● Discuss and decide
on 10 requirements.
System design - Mon@eal.dk 9
10. Top-down or bottom-up
● Both ways work
● Result differ
● Mileage differ
● Recall the “technician
vs. engineer”
difference.
System design - Mon@eal.dk 10