Requirements Engineering

CSCI 5801: Software Engineering

Requirements Engineering

What are Requirements?

• The services that the customer needs a system to perform

• The constraints under which the system operates and is developed

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!

Major Activities

• Requirement Elicitation– 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

Major Activities

• May be handled differently in different models

• Waterfall Requirement Specification Document• Extreme Programming User stories

• Usually cyclical

Elicitation Validation

Documentation

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

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

SystemUser input, sensor readings, data in databases…

Output displays, reports, updated data in databases…

FURPS+

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

Usability

• Ease of user:– 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

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.)

“Enter patient TH level”

Negative number?100 digits (overflow)SQL injection…

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

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, …

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”

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

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?

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

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

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”

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