Software Requirements Engineering

(SE2223)
Ibrar arhsad
[email protected]
SOFTWARE ENGINEERING GOAL

• To develop quality software—on time and on budget—that meets

customers' real needs
• A software is good if it meets stakeholders expectations
 Do all the stakeholders have same expectation(?)
 Can you make all the stakeholders happy at a time(?)
• Then,
 A software should be (at least) correct, reliable, maintainable, user-friendly …
 The total cost it incurs over all phases of its life cycle should be minimal and
within the budget

SE3513 Software Requirements Engineering 2

STAKEHOLDER ENVIRONMENT

SE3513 Software Requirements Engineering 3

SOFTWARE REQUIREMENT: DEFINITION (1)

• “A software capability that must be met or possessed by a system or

system component to satisfy a contract, standard, specification, or other
formally imposed documentation.”
[Leffingwell & Widrig 2003]
• Examples
 The system shall maintain records of all payments made to employees on accounts
of salaries, bonuses, travel/daily allowances, medical allowances, etc.
 The system shall interface with the central computer to send daily sales and
inventory data from every retail store
 The system shall allow users to search for an item by title, author, or by
International Standard Book Number

SE3513 Software Requirements Engineering 4

SOFTWARE REQUIREMENT: DEFINITION (2)

• IEEE Standard Glossary of Software Engineering Terminology

(1990)
1. A condition or capability needed by a user to solve a problem or
achieve an objective
2. A condition or capability that must be met or possessed by a system
component to satisfy a contract, standard, specification, or other
formally imposed document

SE3513 Software Requirements Engineering 5

SOFTWARE REQUIREMENT: DEFINITION (3)

• Sommerville and Sawyer, 1997:

 Requirements are…a specification of what should be implemented.
They are descriptions of how the system should behave, or of a
system property or attribute. They may be a constraint on the
development process of the system.
• Karl Wiegers
 Understanding what you intend to build before you’re done building
it

SE3513 Software Requirements Engineering 6

SE3513 Software Requirements Engineering 7
SE3513 Software Requirements Engineering 8
SE3513 Software Requirements Engineering 9
SE3513 Software Requirements Engineering 10
ROLE OF REQUIREMENTS: A CONTRACT

• The set of requirements constitute a contract between the

client and the software developer
 Software requirement documents are the medium used to
communicate user requirements to technical people responsible for
developing the software
 Requirement documents should emphasize user behavior and
activities
• Serves as a basis for project planning (schedule, budget)
• Requirements document is used both to drive the design
stage, and as a basis for test planning
SE3513 Software Requirements Engineering 11
WHY REQUIREMENTS ARE IMPORTANT

SE3513 Software Requirements Engineering 12

WHY REQUIREMENTS ARE IMPORTANT: STATS

• 31.1% of computer software projects get

canceled before they are completed
• 52.7% will overrun their initial cost estimates by
189%
• 94% of project start-ups are restarts of
previously failed projects
• Major reason:
Requirements
SE3513 Software Requirements Engineering 13
THE ROOT CAUSES OF PROJECT
FAILURE/SUCCESS (STANDISH)
• The Three Largest Problems in Software Industry:
 Lack of user input: 13 % of all “challenged” projects
 Incomplete requirements and specifications: 12% of all “challenged” projects
 Changing requirements specifications: 12% of all “challenged” projects

• The Three Primary Success Factors:

 User involvement: 16 % of all successful projects
 Executive management support: 14 % of all successful projects
 Clear statement of requirements: 12 % of all successful projects

SE3513 Software Requirements Engineering 14

 HIGH COST REQUIREMENTS ERRORS (1)

• If a unit cost of one is

assigned to the effort
required to detect and
repair an error during the
coding stage ….

SE3513 Software Requirements Engineering 15

HIGH COST REQUIREMENTS ERRORS (2)
• In order to repair the defect, we are likely to experience costs in some or all of the
following areas:
 Re-specification
 Redesign
 Recoding
 Retesting
 Change orders - telling users and operators to replace a defective version of the
system with the corrected version
 Corrective action - undoing whatever damage may have been done by
erroneous operation of the improperly specified system, which could involve
sending refund checks to angry customers, rerunning computer jobs, and so on
SE3513 Software Requirements Engineering 16
HIGH COST REQUIREMENTS ERRORS (3)
 Scrap - including code, design, and test cases that were carried out with the best of
intentions but then had to be thrown away when it became clear they were based on
incorrect requirements
 Recall of defective versions of shrink-wrapped software and associated manuals from
users - Since software is now embedded in products ranging from digital wristwatches
to microwave ovens to automobiles, the recall could include both tangible products
and the software embedded within them
 Warranty costs
 Product liability - if the customer sues for damages caused by the defective software
 Service costs - for a company representative to visit a customer's field location to
reinstall the new software.
 Documentation

SE3513 Software Requirements Engineering 17

REQUIREMENTS CHALLENGES

• Insufficient user involvement

• Creeping user requirements
• Ambiguous requirements
• Gold plating
• Minimal specification
• Overlooked user classes

SE3513 Software Requirements Engineering 18

WRITING REQUIREMENTS:
RECOMMENDATIONS (1)
• Write User Requirements from User’s Point of View
• E.g.
 Login Validation

• System shall prompt for user identification and password

(System’s perspective – bad/ineffective)
• User shall start accessing the system by identifying himself (User’s
perspective – good/effective)

SE3513 Software Requirements Engineering 19

WRITING REQUIREMENTS:
RECOMMENDATIONS (2)
The more specific the user Classes, the better will be the requirement documentation
• E.g.
 Sample requirement for time tracking system

 User will enter number of hours worked per day for the tasks that are assigned to him.
User will be able to view his tasks and view his team members task if he has a team
very generic - bad
OR
 Supervisors, Team members will use the system for assignment of tasks and
monitoring tasks
 Supervisor is interested in transferring his project plan of individual tasks into the
system
 Team Members will report time spent against each task - GOOD (addresses specific
requirements of individual Users)

SE3513 Software Requirements Engineering 20

VERIFICATION VS VALIDATION

• Is building a system in a right way is

enough (?)
 Don’t Just Build the System Right, Build
the Right System:

• Validation: Are we building the right

system?
• Verification: Are we building the
system right?

SE 2223 Software Engineering 21

SOLUTION TO REQUIREMENTS PROBLEMS

• … know what the system is supposed to do?

• … keep track of the current status of requirements?
• … determine the impact of a requirements change?
 Answer: By proper requirements engineering

SE 2223 Software Engineering 22

SOFTWARE REQUIREMENTS ENGINEERING
PROCESS (1)

SE 2223 Software Engineering 23

SOFTWARE REQUIREMENTS ENGINEERING
PROCESS (2)
• Elicitation
 Work with the customer on gathering requirements
• Analysis
 Process this information to understand it, classify in various categories, and
relate the customer needs to possible software requirements
• Specification
 Structure the customer input and derived requirements as written documents
and diagrams
• Validation
 You’ll ask your customer to confirm that what you’ve written is accurate and
complete and to correct errors.
SE 2223 Software Engineering 24