Requirements Engineering
Requirements Engineering
• The first step of each process model
• What do we want to build?
• They may range from a high-level abstract
statement of a service or of a system
constraint to a detailed mathematical
functional specification: can be statements
(“The system shall…”), diagrams, use cases,
etc.
• Can be used as basis for contacts, etc.
Requirements specify external
behavior
• Functional requirements are statements of the
services that the system must provide
– “The system shall display the heart rate of the patient”
• Non-functional requirements are constraints on
the services and functions offered by the system
– “The system shall display the heart rate of the patient
within two seconds”
– Performance, Scalability, Capacity, Availability Reliability,
Recoverability, Maintainability, Serviceability,
Security, Regulatory, Manageability
• Exercise: list some functional and non-functional
requirements for an iPhone
Answer: list some functional and nonfunctional requirements for an iPhone
• Functional:
–
–
–
–
The system shall make a phone call
The system shall receive a phone call
The system shall allow the user to adjust volume
etc
• Non-functional:
– The system shall boot up in 60 seconds or less
– The system shall respond to touch within 1 second
– etc
Requirements qualities
• Three Cs:
– Clear
– Consistent
– Complete (internally and externally)
• Use the SE principle of incrementality to
derive requirements
• Remember, they must all be externally visible
– Why? They must all be testable
Exercise
• Give an unclear requirement, then fix it
• Give an inconsistent set of requirements, then
fix them
• Give an incomplete requirement, then fix it*
Answer
• Unclear: “The background shall be blue”
– There are many shades of blue…is #3333CC blue?
– Fix: “The background shall be #0000FF”
• Inconsistent: “The background shall be red” and, elsewhere
“The background shall be a cool color”
– Fix: “The background shall be #0000FF”
• Incomplete: This is the hardest; it means we’re missing a
requirement or information
– Fix: …make sure you have all your requirements (externally
complete)
– Fix: …make sure you have enough info; include supporting
documents when needed (i.e. what is 508 compliance?)
(internally complete)
Testable Requirements
• Do not use vague terminology; “errors shall be
minimized…”
Property
M eas ure
Proces sed tran sactions /seco nd
• Should NOT Speed
User/Event res ponse time
Screen refresh time
K Bytes
partially pass Size
Number of RAM chips
Ease of use
Training time
Number of help frames
or fail
R eliability
Mean time to failure
Probability of unavailability
• Should have
R ate of failure occurrence
Availability
R obustness
Time to restart after failure
a source
Percentage of events causin g failure
Portability
Probability of data corruption on failure
Percentage of target depend ent s tatements
Number of target s ystems
Requirements Validation
• It’s cheapest to fix faults at this step, than
later on (sometimes 100 times cheaper)
– Are they testable?
– Do any conflict?
– Do they cover all aspects of the system?
– Are they what the customer wanted?
Quiz review
• What is a functional requirement?
• What is a non-functional requirement?
• What do all requirements have to be?
In-class exercises
• Let’s imagine we have an ATM
– Come up with 5 functional requirements
– Show how each requirement could be improved
– Show how each requirement could have been worse
– Come up with 3 non-functional requirements
– Do the same as above
• Complete the exercises at
http://www.cs.gmu.edu/~kdobolyi/cs321/Requirements_Worksheet.docx
• Complete the exercises at
http://www.cs.gmu.edu/~kdobolyi/cs321/hwk01.html
Assignment (time permitting)
• Examine the Quiz Game description
• In your teams, come up with at least seven
functional requirements and at least two nonfunctional requirements
– Remember the three Cs
– Requirements specify external behavior
– Requirements must be testable
• Turn in this assignment through svn
– See instructions and grading rubric on project
page