APPLICATION DEVELOPMENT AND EMERGING TECHNOLOGIES

REQUIREMENT ANALYSIS
AND MODELING
INTRODUCTION
• REQUIREMENT ANALYSIS AND MODELING ARE
SIGNIFICANT STEPS IN DEVELOPING ANY KINDS OF
SOFTWARE. IT REVIEWS ALL REQUIREMENTS AND
PROVIDES A GRAPHICAL VIEW OF THE ENTIRE SYSTEM
USING DIAGRAMS.
• THIS UNIT COVERS THE TOPICS ON SOFTWARE
REQUIREMENT SPECIFICATION, STEPS IN REQUIREMENT
ANALYSIS, DATA FLOW DIAGRAM AND ENTITY
RELATIONSHIP DIAGRAMS, AND CREATE DATA
DICTIONARIES FILES.
- SOFTWARE REQUIREMENTS
SPECIFICATION
• THE PRODUCTION OF THE REQUIREMENTS STAGE OF THE SOFTWARE
DEVELOPMENT PROCESS IS SOFTWARE REQUIREMENTS
SPECIFICATIONS (SRS) (ALSO CALLED A REQUIREMENTS DOCUMENT).
• SRS IS A FORMAL REPORT, WHICH ACTS AS A REPRESENTATION OF
SOFTWARE THAT ENABLES THE CUSTOMERS TO REVIEW WHETHER IT
(SRS) IS ACCORDING TO THEIR REQUIREMENTS.
• ALSO, IT COMPRISES USER REQUIREMENTS FOR A SYSTEM AS WELL
AS DETAILED SPECIFICATIONS OF THE SYSTEM REQUIREMENTS.
• THE SRS IS A SPECIFICATION FOR A SPECIFIC
SOFTWARE PRODUCT, PROGRAM, OR SET OF
APPLICATIONS THAT PERFORM PARTICULAR
FUNCTIONS IN A SPECIFIC ENVIRONMENT. IT SERVES
SEVERAL GOALS DEPENDING ON WHO IS WRITING IT.
FIRST, THE SRS COULD BE WRITTEN BY THE CLIENT OF
A SYSTEM. SECOND, THE SRS COULD BE WRITTEN BY A
DEVELOPER OF THE SYSTEM. THE TWO METHODS
CREATE ENTIRELY VARIOUS SITUATIONS AND
ESTABLISH DIFFERENT PURPOSES FOR THE DOCUMENT
ALTOGETHER. THE FIRST CASE, SRS, IS USED TO DEFINE
THE NEEDS AND EXPECTATION OF THE USERS. THE
SECOND CASE, SRS, IS WRITTEN FOR VARIOUS
PURPOSES AND SERVES AS A CONTRACT DOCUMENT
BETWEEN CUSTOMER AND DEVELOPER.
SOFTWARE REQUIREMENT SPECIFICATION
REPORT SAMPLE CONTENT

• INTRODUCTION.
• FUNCTIONAL DATA DESCRIPTION.
• SUBSYSTEM DESCRIPTION.
• SYSTEM MODELING AND SIMULATION RESULTS.
• PRODUCTS.
• APPENDICES.
TYPES OF REQUIREMENTS

THERE ARE TWO TYPES OF REQUIREMENTS WHICH ARE:

• FUNCTIONAL REQUIREMENTS
-FUNCTIONAL REQUIREMENTS DEFINE THE BASIC SYSTEM BEHAVIOR.
ESSENTIALLY, THEY ARE WHAT THE SYSTEM DOES OR MUST NOT DO, AND
CAN BE THOUGHT OF IN TERMS OF HOW THE SYSTEM RESPONDS TO INPUTS.
FUNCTIONAL REQUIREMENTS USUALLY DEFINE IF/THEN BEHAVIORS AND
INCLUDE CALCULATIONS, DATA INPUT, AND BUSINESS PROCESSES.
• NON-FUNCTIONAL REQUIREMENTS
NONFUNCTIONAL REQUIREMENTS (NFRS) DEFINE
SYSTEM ATTRIBUTES SUCH AS SECURITY,
RELIABILITY, PERFORMANCE, MAINTAINABILITY,
SCALABILITY, AND USABILITY. THEY SERVE AS
CONSTRAINTS OR RESTRICTIONS ON THE DESIGN
OF THE SYSTEM ACROSS THE DIFFERENT
BACKLOGS.
• FUNCTIONAL REQUIREMENTS
a) INPUT/OUTPUT
b) PROCESSING
c) ERROR HANDLING
• NON-FUNCTIONAL REQUIREMENTS
a) PHYSICAL ENVIRONMENT
b) INTERFACE
c) HUMAN FACTORS
d) PERFORMANCE
e) DOCUMENTATION
f) DATA
g) RESOURCES
h) SECURITY
i) QUALITY
CHARACTERISTICS OF A GOOD
SRS
FOLLOWING ARE THE FEATURES OF A GOOD
SRS DOCUMENT:
• CORRECTNESS: USER REVIEW IS USED TO PROVIDE THE ACCURACY OF
REQUIREMENTS STATED IN THE SRS. SRS IS SAID TO BE PERFECT IF IT COVERS ALL
THE NEEDS THAT ARE TRULY EXPECTED FROM THE SYSTEM.
• COMPLETENESS: THE SRS IS COMPLETE IF, AND ONLY IF, IT INCLUDES THE
FOLLOWING ELEMENTS:
1. ALL ESSENTIAL REQUIREMENTS, WHETHER RELATING TO FUNCTIONALITY,
PERFORMANCE, DESIGN, CONSTRAINTS, ATTRIBUTES, OR EXTERNAL INTERFACES.
2. DEFINITION OF THEIR RESPONSES OF THE SOFTWARE TO ALL REALIZABLE
CLASSES OF INPUT DATA IN ALL AVAILABLE CATEGORIES OF SITUATIONS.
3. FULL LABELS AND REFERENCES TO ALL FIGURES, TABLES, AND DIAGRAMS IN THE
SRS AND DEFINITIONS OF ALL TERMS AND UNITS OF MEASURE.
SUBSET OF INDIVIDUAL REQUIREMENTS DESCRIBED IN ITS
CONFLICT. THERE ARE THREE TYPES OF POSSIBLE CONFLICT IN
THE SRS:
1. THE SPECIFIED CHARACTERISTICS OF REAL-WORLD OBJECTS MAY
CONFLICTS. FOR EXAMPLE,
a) THE FORMAT OF AN OUTPUT REPORT MAY BE DESCRIBED IN ONE
REQUIREMENT AS TABULAR BUT IN ANOTHER AS TEXTUAL.
b) ONE CONDITION MAY STATE THAT ALL LIGHTS SHALL BE GREEN WHILE
ANOTHER STATES THAT ALL LIGHTS SHALL BE BLUE.
2. THERE MAY BE A REASONABLE OR TEMPORAL CONFLICT BETWEEN THE
TWO SPECIFIED ACTIONS. FOR EXAMPLE,
a) ONE REQUIREMENT MAY DETERMINE THAT THE PROGRAM WILL ADD TWO
INPUTS, AND ANOTHER MAY DETERMINE THAT THE PROGRAM WILL
MULTIPLY THEM.
b) ONE CONDITION MAY STATE THAT "A" MUST ALWAYS FOLLOW "B," WHILE
OTHER REQUIRES THAT "A AND B" CO-OCCURS.
3. TWO OR MORE REQUIREMENTS MAY DEFINE THE SAME REAL-WORLD OBJECT
BUT USE DIFFERENT TERMS FOR THAT OBJECT. FOR EXAMPLE, A PROGRAM'S
REQUEST FOR USER INPUT MAY BE CALLED A "PROMPT" IN ONE REQUIREMENT'S
AND A "CUE" IN ANOTHER. THE USE OF STANDARD TERMINOLOGY AND
• UNAMBIGUOUSNESS: SRS IS UNAMBIGUOUS WHEN EVERY
FIXED REQUIREMENT HAS ONLY ONE INTERPRETATION. THIS
SUGGESTS THAT EACH ELEMENT IS UNIQUELY INTERPRETED. IN
CASE THERE IS A METHOD USED WITH MULTIPLE DEFINITIONS,
THE REQUIREMENTS REPORT SHOULD DETERMINE THE
IMPLICATIONS IN THE SRS SO THAT IT IS CLEAR AND SIMPLE TO
UNDERSTAND.
• RANKING FOR IMPORTANCE AND STABILITY: THE SRS IS
RANKED FOR IMPORTANCE AND STABILITY IF EACH
REQUIREMENT IN IT HAS AN IDENTIFIER TO INDICATE EITHER
THE SIGNIFICANCE OR STABILITY OF THAT PARTICULAR
REQUIREMENT.
TYPICALLY, ALL REQUIREMENTS ARE NOT EQUALLY IMPORTANT. SOME
PREREQUISITES MAY BE ESSENTIAL, ESPECIALLY FOR LIFE-CRITICAL
APPLICATIONS, WHILE OTHERS MAY BE DESIRABLE. EACH ELEMENT
SHOULD BE IDENTIFIED TO MAKE THESE DIFFERENCES CLEAR AND
EXPLICIT. ANOTHER WAY TO RANK REQUIREMENTS IS TO DISTINGUISH
CLASSES OF ITEMS AS ESSENTIAL, CONDITIONAL, AND OPTIONAL.
• MODIFIABILITY: SRS SHOULD BE MADE AS
MODIFIABLE AS LIKELY AND SHOULD BE CAPABLE OF
QUICKLY OBTAIN CHANGES TO THE SYSTEM TO SOME
EXTENT. MODIFICATIONS SHOULD BE PERFECTLY
INDEXED AND CROSS-REFERENCED.
• VERIFIABILITY: SRS IS CORRECT WHEN THE SPECIFIED
REQUIREMENTS CAN BE VERIFIED WITH A COST-
EFFECTIVE SYSTEM TO CHECK WHETHER THE FINAL
SOFTWARE MEETS THOSE REQUIREMENTS. THE
REQUIREMENTS ARE VERIFIED WITH THE HELP OF
REVIEWS.
• TRACEABILITY: THE SRS IS TRACEABLE IF THE ORIGIN
OF EACH OF THE REQUIREMENTS IS CLEAR AND IF IT
FACILITATES THE REFERENCING OF EACH CONDITION
IN FUTURE DEVELOPMENT OR ENHANCEMENT
DOCUMENTATION.
• THERE ARE TWO TYPES OF TRACEABILITY:
• 1. BACKWARD TRACEABILITY: THIS DEPENDS UPON EACH
REQUIREMENT EXPLICITLY REFERENCING ITS SOURCE IN
EARLIER DOCUMENTS.
• 2. FORWARD TRACEABILITY: THIS DEPENDS UPON EACH ELEMENT
IN THE SRS HAVING A UNIQUE NAME OR REFERENCE NUMBER.
• THE FORWARD TRACEABILITY OF THE SRS IS ESPECIALLY
CRUCIAL WHEN THE SOFTWARE PRODUCT ENTERS THE
OPERATION AND MAINTENANCE PHASE. AS CODE AND DESIGN
DOCUMENT IS MODIFIED, IT IS NECESSARY TO BE ABLE TO
ASCERTAIN THE COMPLETE SET OF REQUIREMENTS THAT MAY
BE CONCERNED BY THOSE MODIFICATIONS.
• DESIGN INDEPENDENCE: THERE SHOULD BE AN OPTION TO
SELECT FROM MULTIPLE DESIGN ALTERNATIVES FOR THE FINAL
SYSTEM. MORE SPECIFICALLY, THE SRS SHOULD NOT CONTAIN
ANY IMPLEMENTATION DETAILS.
• TESTABILITY: AN SRS SHOULD BE WRITTEN IN SUCH A METHOD
THAT IT IS SIMPLE TO GENERATE TEST CASES AND TEST PLANS
FROM THE REPORT.
• UNDERSTANDABLE BY THE CUSTOMER: AN END USER MAY BE
AN EXPERT IN HIS/HER EXPLICIT DOMAIN BUT MIGHT NOT BE
TRAINED IN COMPUTER SCIENCE. HENCE, THE PURPOSE OF
FORMAL NOTATIONS AND SYMBOLS SHOULD BE AVOIDED TOO
AS MUCH EXTENT AS POSSIBLE. THE LANGUAGE SHOULD BE
KEPT SIMPLE AND CLEAR.
• THE RIGHT LEVEL OF ABSTRACTION: IF THE SRS IS
WRITTEN FOR THE REQUIREMENTS STAGE, THE
DETAILS SHOULD BE EXPLAINED EXPLICITLY. WHERE
AS, FOR A FEASIBILITY STUDY, FEWER ANALYSIS CAN
BE USED. HENCE, THE LEVEL OF ABSTRACTION
MODIFIES ACCORDING TO THE OBJECTIVE OF THE SRS.
PROPERTIES OF A GOOD SRS DOCUMENT
THE ESSENTIAL PROPERTIES OF A GOOD SRS DOCUMENT
ARE THE FOLLOWING:

• CONCISE: THE SRS REPORT SHOULD BE CONCISE AND AT THE SAME

TIME, UNAMBIGUOUS, CONSISTENT, AND COMPLETE. VERBOSE AND
IRRELEVANT DESCRIPTIONS DECREASE READABILITY AND ALSO
INCREASE ERROR POSSIBILITIES.
• STRUCTURED: IT SHOULD BE WELL-STRUCTURED. A WELL-
STRUCTURED DOCUMENT IS SIMPLE TO UNDERSTAND AND MODIFY.
IN PRACTICE, THE SRS DOCUMENT UNDERGOES SEVERAL REVISIONS
TO COPE UP WITH THE USER REQUIREMENTS. OFTEN, USER
REQUIREMENTS EVOLVE OVER A PERIOD OF TIME. THEREFORE, TO
MAKE THE MODIFICATIONS TO THE SRS DOCUMENT EASY, IT IS VITAL
TO MAKE THE REPORT WELL-STRUCTURED.
• BLACK-BOX VIEW: IT SHOULD ONLY DEFINE WHAT THE SYSTEM
SHOULD DO AND REFRAIN FROM STATING HOW TO DO THESE.
THIS MEANS THAT THE SRS DOCUMENT SHOULD DEFINE THE
EXTERNAL BEHAVIOR OF THE SYSTEM AND NOT DISCUSS THE
IMPLEMENTATION ISSUES. THE SRS REPORT SHOULD VIEW THE
SYSTEM TO BE DEVELOPED AS A BLACK BOX AND SHOULD
DEFINE THE EXTERNALLY VISIBLE BEHAVIOR OF THE SYSTEM.
FOR THIS REASON, THE SRS REPORT IS ALSO KNOWN AS THE
BLACK-BOX SPECIFICATION OF A SYSTEM.
• CONCEPTUAL INTEGRITY: IT SHOULD SHOW CONCEPTUAL
INTEGRITY SO THAT THE READER CAN MERELY UNDERSTAND IT.
RESPONSE TO UNDESIRED EVENTS: IT SHOULD CHARACTERIZE
ACCEPTABLE RESPONSES TO UNWANTED EVENTS. THESE ARE
CALLED SYSTEM RESPONSE TO EXCEPTIONAL CONDITIONS.
• VERIFIABLE: ALL REQUIREMENTS OF THE SYSTEM, AS
DOCUMENTED IN THE SRS DOCUMENT, SHOULD BE
CORRECT. THIS MEANS THAT IT SHOULD BE POSSIBLE
TO DECIDE WHETHER OR NOT REQUIREMENTS HAVE
BEEN MET IN AN IMPLEMENTATION.
END