1. Requirements Engineering
CSCI 5801: Software Engineering

2. Requirements Engineering

3. What are Requirements?
The services that the customer needs a system to perform
The constraints under which the system operates and is developed

4. Standish survey of software development projects (1994)
Factors Reported for Failure
13.1% - Incomplete Requirements
10.6% - Lack of Resources
9.9 % - Unrealistic expectations
9.3 % - Lack of Executive support
8.7 % - Changing requirements and specification
8.1 % - Lack of Planning
7.5 % - System no longer Needed
Most common cause of project failure!

5. Major Activities Requirement Elicitation Requirement Documentation
Identify stakeholders
Communicate with them to attempt to understand their requirements
Requirement Documentation
Creating representation of requirements understood and agreed to by all
Requirement Validation
Making sure requirements correct
May involve negotiation with stakeholders

6. Major Activities May be handled differently in different models
Waterfall  Requirement Specification Document
Extreme Programming  User stories
Usually cyclical
Elicitation
Validation
Documentation

7. What Must be Specified? Functional requirements
Interactions between system and environment independent of implementation
Most common way to think of requirements
Nonfunctional requirements
Constraints on how system performs its functional requirements (speed, reliability, usability, etc.)
Context in which constraints must be met
Often as important as functional requirements

8. Functional Requirements
Can be treated like mapping between system inputs and outputs
Example: password system
User enters name, password
(name, password) found in database  go to main menu
Otherwise  Error message and re-prompt
User input, sensor readings, data in databases…
System
Output displays, reports, updated data in databases…

9. FURPS+ One definition of major requirement types Functional Usability
Reliability
Performance
Sustainability
+ (anything else)

10. Usability Ease of user: Based on user knowledge Operation of system
Acquiring and entering inputs
Interpreting outputs
Learning to use
Based on user knowledge
Knowledge of domain
Expertise in computing in general
“Enter patient TH level”
“Error: improper TH level entered”
context

11. Reliability Doing specified tasks while minimizing error
Durability: Errors do not exceed specified level
Mean time to failure, % of transactions with error, …
Security: Ability to resist given types of attack
Robustness: Ability to handle illegal input
Safety: Avoidance of catastrophic results to environment (erasure of database, etc.)
Negative number?
100 digits (overflow)
SQL injection…
“Enter patient TH level”

12. Performance
Ability to perform specified tasks within time/ space constraints
Response time “Must show available courses within 5 seconds”
Throughput “Must process 50 requests/second”
Memory usage
Context: Must specify conditions under which system operates for constraints to be meaningful
…when running on X hardware and Y operating system
…with Z users running simultaneously

13. Sustainability
Ease with which specified types of expected maintenance can be done
Expected future increments to system
“May need to be able to enforce prerequisite constraints”
Portability
Hardware (PC  Mac)
Software (MySQL  Oracle, JSP  ASP, etc.)
Internationalization
English  Spanish, Chinese, …

14. All Others (the “+”) Organizational requirements
What your organization requires/usually does
“Implemented in Java using RAD and standard UI”
Interface requirements
External entities in customer environment
Existing databases
Legacy software
Legal requirements
“Must meet FERPA and ADA requirements”

15. Measurable Requirements
Must have some way to verify that delivered system meets requirements
Waterfall: has company met contract?
XP/Agile: how can test be created with customer?
Functional requirements: System generally does or does not give desired response

16. Measurable Requirements
Nonfunctional requirements: Many must be quantifiable in some way
Otherwise have no way of proving have been met!
Examples of bad requirements
“The interfaces must be user-friendly”
“The system must rarely crash”
“Student records must be stored securely”
“The system must respond within 1 second”
Why is this last one bad?

17. Requirements in Context
Quantified requirements must be defined in terms of rest of system
Hardware and software (OS, etc.)
Load on system (other programs, number of users)
Knowledge levels of users

18. Usability Requirements
Average errors/task
“On average a student who has registered for one semester previously should make mo more than 3 mistakes during an entire session…
Average time to complete task
…and should be able to add all of their courses within 15 minutes”
Training time
“Registration personnel should require no more that 2 hours of training to reach 99% correctness rate”
Can test with user focus groups

19. Reliability Requirements
Mean time to failure
“The system should be able to run for at least 100 consecutive hours on average without failure, under expected load of 50 simultaneous registrations”
Transactions per error
“There shall be no more than 1 failure per 1000 transactions on average”
Algorithm security
“Student information will be encrypted with AES-128”

20. Performance Requirements
Response Time
“For requests for open sections, the system response time should be less than 2 seconds in 90% of cases under normal load”
Throughput
“The server should be able to handle 100 requests per second on a Dell T-130 running Windows 7 and Apache Tomcat”
Can usually test empirically