HEADINGS

WHAT IS REQUIREMENT?

• IEEE:
• A CONDITION OR CAPABILITY THAT MUST BE MET OR POSSESSED BY A SYSTEM
OR SYSTEM COMPONENT TO SATISFY A CONTRACT, STANDARD, SPECIFICATION
OR OTHER FORMALLY IMPOSED DOCUMENTS.
• IT MAY RANGE FROM A HIGH LEVEL ABSTRACT STATEMENT OF A SERVICE OR OF
A SYSTEM CONSTRAINT TO A DETAILED MATHEMATICAL FUNCTIONAL
SPECIFICATION.
 WHAT ARE SOFTWARE REQUIREMENTS?

• SOFTWARE REQUIREMENTS ARE THE WANTS AND NEEDS OF THE STAKEHOLDERS.

• SOFTWARE REQUIREMENTS FOR A SYSTEM ARE THE DESCRIPTION OF WHAT THE SYSTEM
SHOULD DO, THE SERVICE OR SERVICES THAT IT PROVIDES AND THE CONSTRAINTS ON ITS
OPERATION. 
• THE SOFTWARE REQUIREMENTS ARE DESCRIPTION OF FEATURES AND FUNCTIONALITIES OF
THE TARGET SYSTEM.
• REQUIREMENTS CONVEY THE EXPECTATIONS OF USERS FROM THE SOFTWARE PRODUCT.
• THE REQUIREMENTS CAN BE OBVIOUS OR HIDDEN, KNOWN OR UNKNOWN, EXPECTED OR
UNEXPECTED FROM CLIENT’S POINT OF VIEW.
 WHAT IS REQUIREMENT ENGINEERING?

• REQUIREMENTS ENGINEERING IS THE PROCESS OF ELICITING STAKEHOLDER NEEDS AND DESIRES

AND DEVELOPING THEM INTO AN AGREED-UPON SET OF DETAILED REQUIREMENTS THAT CAN
SERVE AS A BASIS FOR ALL SUBSEQUENT DEVELOPMENT ACTIVITIES.
• THE PURPOSE OF REQUIREMENTS ENGINEERING METHODOLOGIES IS TO MAKE THE PROBLEM THAT
IS BEING STATED CLEAR AND COMPLETE, AND TO ENSURE THAT THE SOLUTION IS CORRECT,
REASONABLE, AND EFFECTIVE.
• THE PROCESS TO GATHER THE SOFTWARE REQUIREMENTS FROM CLIENT, ANALYZE AND
DOCUMENT THEM IS KNOWN AS REQUIREMENT ENGINEERING.
• THE GOAL OF REQUIREMENT ENGINEERING IS TO DEVELOP AND MAINTAIN ‘SYSTEM
REQUIREMENTS SPECIFICATION’ DOCUMENT.
 CLASSIFICATION OF REQUIREMENTS

1. FUNCTIONAL REQUIREMENTS
2. NON-FUNCTIONAL REQUIREMENTS
3. DOMAIN REQUIREMENTS
4. BUSINESS REQUIREMENTS
5. USER REQUIREMENTS
6. SYSTEM REQUIREMENTS
 WHAT IS REQUIREMENT ENGINEERING
PROCESS?
• IT IS A FOUR STEP PROCESS, WHICH INCLUDES –
• REQUIREMENT ELICITATION
• REQUIREMENT ANALYSIS
• REQUIREMENT SPECIFICATION
• REQUIREMENT VALIDATION
• REQUIREMENT MANAGEMENT & EVALUATION
 ARTIFACTS OF REQUIREMENT DISCIPLINE

1) INPUT ARTIFACT
 VISION ARTIFACT
EXPLANATION OF “WHATS” & “WHYS” OF SYSTEM.
 GLOSSARY
DEFINES IMPORTANT TERMINOLOGIES.
SHOULD BE UNIQUE.
INFORMAL DATA DICTIONARY.
 CONT..

2) MODELLING ARTIFACT
 USE CASES & USE CASE MODEL

3) DESCRIPTIVE ARTIFACT
 SRS
SOFTWARE REQUIREMENT SPECIFICATION
FUNCTIONAL & NON-FUNCTIONAL REQUIREMENT
 LEVELS OR LAYERS OF REQUIREMENTS

1. BUSINESS REQUIREMENTS
2. USER REQUIREMENTS
3. PRODUCT REQUIREMENTS
 REQUIREMENT CHARACTERISTICS

• CLEAR & UNDERSTANDABLE

• CORRECT & COMPLETE
• CONSISTENT & NOT REDUNDANT
• UNAMBIGUOUS
• MEASURABLE & TESTABLE
• TRACEABLE
• VERIFIABILITY
• MODIFIABILITY
 REQUIREMENT TRACEABILITY

• INTRODUCTION
• TYPES OF REQ TRACEABILITY

FORWARD
BACKWARD
BIDIRECTIONAL
• REQ TRACEABILITY MATRIX
• CHALLENGES OF TRACEABILITY
• BENEFITS OF TRACEABILITY