SYSTEMS REQUIREMENTS

BSAIS 3A
SINCE SYSTEMS ANALYSTS DO NOT WORK AS MANAGERS OR EMPLOYEES IN USER
DEPARTMENTS (SUCH AS MARKETING, PURCHASING, MANUFACTURING OR
ACCOUNTING), THEY DO NOT HAVE THE SAME BASE OF FACTS AND DETAILS AS THE
MANAGERS AND USERS IN THOSE AREAS. THEREFORE, AN EARLY STEP IN THE ANALYST’S
INVESTIGATION IS TO UNDERSTAND THE SITUATION. CERTAIN TYPES OF
REQUIREMENTS ARE SO FUNDAMENTAL AS TO BE COMMON IN MOST SITUATIONS.
DEVELOPING ANSWERS TO A SPECIFIC GROUP OF QUESTIONS WILL HELP YOU
UNDERSTAND THESE BASIC REQUIREMENTS.  
TOOLS FOR SYSTEM REQUIREMENTS

CONCEPTUALLY, REQUIREMENTS ANALYSIS INCLUDES THREE TYPES OF

ACTIVITY:
ELICITING REQUIREMENTS: THE TASK OF COMMUNICATING WITH
CUSTOMERS AND USERS TO DETERMINE WHAT THEIR REQUIREMENTS ARE.
TOOLS FOR SYSTEM REQUIREMENTS

ANALYZING REQUIREMENTS: DETERMINING WHETHER THE STATED REQUIREMENTS

ARE UNCLEAR, INCOMPLETE, AMBIGUOUS, OR CONTRADICTORY, AND THEN RESOLVING
THESE ISSUES.

 RECORDING REQUIREMENTS: REQUIREMENTS MAY BE DOCUMENTED IN VARIOUS

FORMS, SUCH AS NATURAL-LANGUAGE DOCUMENTS, USE CASES, USER STORIES, OR
PROCESS SPECIFICATIONS.
• REQUIREMENTS ANALYSIS CAN BE A LONG AND ARDUOUS PROCESS DURING WHICH
MANY DELICATE PSYCHOLOGICAL SKILLS ARE INVOLVED. NEW SYSTEMS CHANGE
THE ENVIRONMENT AND RELATIONSHIPS BETWEEN PEOPLE, SO IT IS IMPORTANT TO
IDENTIFY ALL THE STAKEHOLDERS, TAKE INTO ACCOUNT ALL THEIR NEEDS AND
ENSURE THEY UNDERSTAND THE IMPLICATIONS OF THE NEW SYSTEMS. ANALYSTS
CAN EMPLOY SEVERAL TECHNIQUES TO ELICIT THE REQUIREMENTS FROM THE
CUSTOMER. HISTORICALLY, THIS HAS INCLUDED SUCH THINGS AS HOLDING
INTERVIEWS, OR HOLDING FOCUS GROUPS AND CREATING REQUIREMENTS LISTS.
• MORE MODERN TECHNIQUES INCLUDE PROTOTYPING, AND USE CASES.
STAKEHOLDER INTERVIEWS
STAKEHOLDER INTERVIEWS ARE A COMMON METHOD USED IN REQUIREMENT ANALYSIS.
SOME SELECTION IS USUALLY NECESSARY, COST BEING ONE FACTOR IN DECIDING WHOM
TO INTERVIEW. THESE INTERVIEWS MAY REVEAL REQUIREMENTS NOT PREVIOUSLY
ENVISAGED AS BEING WITHIN THE SCOPE OF THE PROJECT, AND REQUIREMENTS MAY BE
CONTRADICTORY. HOWEVER, EACH STAKEHOLDER WILL HAVE AN IDEA OF THEIR
EXPECTATION OR WILL HAVE VISUALIZED THEIR REQUIREMENTS.
JOINT REQUIREMENTS DEVELOPMENT SESSIONS
REQUIREMENTS OFTEN HAVE CROSS-FUNCTIONAL IMPLICATIONS THAT ARE UNKNOWN
TO INDIVIDUAL STAKEHOLDERS AND OFTEN MISSED OR INCOMPLETELY DEFINED DURING
STAKEHOLDER INTERVIEWS. THESE CROSS-FUNCTIONAL IMPLICATIONS CAN BE ELICITED
BY CONDUCTING JRD SESSIONS IN A CONTROLLED ENVIRONMENT, FACILITATED BY A
BUSINESS ANALYST, WHEREIN STAKEHOLDERS PARTICIPATE IN DISCUSSIONS TO ELICIT
REQUIREMENTS, ANALYZE THEIR DETAILS AND UNCOVER CROSS-FUNCTIONAL
IMPLICATIONS
JOINT REQUIREMENTS DEVELOPMENT SESSIONS

A DEDICATED SCRIBE TO DOCUMENT THE DISCUSSION IS OFTEN USEFUL,

FREEING THE BUSINESS ANALYST TO FOCUS ON THE REQUIREMENTS
DEFINITION PROCESS AND GUIDE THE DISCUSSION.
CONTRACT-STYLE REQUIREMENT LISTS

ONE TRADITIONAL WAY OF DOCUMENTING REQUIREMENTS HAS BEEN

CONTRACT STYLE REQUIREMENT LISTS. IN A COMPLEX SYSTEM SUCH
REQUIREMENTS LISTS CAN RUN TO HUNDREDS OF PAGES.
MEASURABLE GOALS

BEST PRACTICES TAKE THE COMPOSED LIST OF REQUIREMENTS MERELY AS CLUES AND
REPEATEDLY ASK “WHY?” UNTIL THE ACTUAL BUSINESS PURPOSES ARE DISCOVERED.
STAKEHOLDERS AND DEVELOPERS CAN THEN DEVISE TESTS TO MEASURE WHAT LEVEL OF
EACH GOAL HAS BEEN ACHIEVED THUS FAR. SUCH GOALS CHANGE MORE SLOWLY THAN
THE LONG LIST OF SPECIFIC BUT UNMEASURED REQUIREMENTS. ONCE A SMALL SET OF
CRITICAL, MEASURED GOALS HAS BEEN ESTABLISHED, RAPID PROTOTYPING AND SHORT
ITERATIVE DEVELOPMENT PHASES MAY PROCEED TO DELIVER ACTUAL STAKEHOLDER
VALUE LONG BEFORE THE PROJECT IS HALF OVER.
 PROTOTYPES

• IN THE MID-1980S, PROTOTYPING WAS SEEN AS THE SOLUTION TO THE REQUIREMENTS

ANALYSIS PROBLEM. PROTOTYPES ARE MOCK-UPS OF AN APPLICATION. MOCK-UPS ALLOW
USERS TO VISUALIZE AN APPLICATION THAT HASN’T YET BEEN CONSTRUCTED. PROTOTYPES
HELP USERS GET AN IDEA OF WHAT THE SYSTEM WILL LOOK LIKE, AND MAKE IT EASIER FOR
USERS TO MAKE DESIGN DECISIONS WITHOUT WAITING FOR THE SYSTEM TO BE BUILT.
MAJOR IMPROVEMENTS IN COMMUNICATION BETWEEN USERS AND DEVELOPERS WERE
OFTEN SEEN WITH THE INTRODUCTION OF PROTOTYPES. EARLY VIEWS OF APPLICATIONS LED
TO FEWER CHANGES LATER AND HENCE REDUCED OVERALL COSTS CONSIDERABLY.
REQUIREMENTS DETERMINATION

IT IS HELPFUL TO VIEW REQUIREMENTS DETERMINATION THROUGH

THE THREE MAJOR ACTIVITIES OF REQUIREMENTS WHICH ARE
DISCUSSED BELOW:
ACTIVITIES IN REQUIREMENTS ANALYSIS

REQUIREMENTS INVESTIGATION
 REQUIREMENTS SPECIFICATION
REQUIREMENTS ANTICIPATION
REQUIREMENTS INVESTIGATION

•THIS ACTIVITY IS AT THE HEART OF SYSTEM ANALYSIS. USING A

VARIETY OF TOOLS AND SKILLS, ANALYSTS STUDY THE CURRENT
SYSTEM AND DOCUMENT ITS FEATURES FOR FURTHER ANALYSIS.
•REQUIREMENTS INVESTIGATION RELIES ON FACT FINDING
TECHNIQUES DISCUSSED LATER AND INCLUDES METHODS FOR
DOCUMENTING AND DESCRIBING THE SYSTEM FEATURES.
 REQUIREMENTS SPECIFICATION

THE DATA PRODUCED DURING THE FACT FINDING STUDY ARE ANALYZED TO
DETERMINE REQUIREMENTS SPECIFICATIONS – THE DESCRIPTION OF FEATURES
FOR A NEW SYSTEM. THIS ACTIVITY HAS THREE INTERRELATED PARTS:
(I) ANALYSIS OF FACTUAL DATA: THE DATA COLLECTED DURING THE FACT FINDING
STUDY AND INCLUDED IN DATA FLOW AND DECISION ANALYSIS DOCUMENTATION
ARE EXAMINED TO DETERMINE HOW WELL THE SYSTEM IS PERFORMING AND
WHETHER IT WILL MEET THE ORGANIZATION’S DEMANDS.
 REQUIREMENTS SPECIFICATION

(II) IDENTIFICATION OF ESSENTIAL REQUIREMENTS: FEATURES THAT MUST BE

INCLUDED IN A NEW SYSTEM, RANGING FROM OPERATION DETAILS TO
PERFORMANCE CRITERIA, ARE SPECIFIED.
(III) SELECTION OF REQUIREMENTS STRATEGIES: THE METHODS THAT WILL BE
USED TO ACHIEVE THE STATED NOTES REQUIREMENTS ARE SELECTED. THESE FORM
THE BASIS FOR SYSTEM DESIGN, WHICH FOLLOWS REQUIREMENTS
SPECIFICATIONS.
BASIC REQUIREMENTS

ANALYSIS STRUCTURES THEIR INVESTIGATION BY SEEKING ANSWER TO THESE FOUR

MAJOR QUESTIONS:
 WHAT IS THE BASIC BUSINESS PROCESS?
 WHAT DATA ARE USED OR PRODUCED DURING THE PROCESS?
 WHAT ARE THE LIMITS IMPOSED BY TIME AND VOLUME OF WORK?
 WHAT PERFORMANCE CONTROLS ARE USED?
UNDERSTAND THE PROCESS

BEGIN WITH THE BASIC. ANALYSTS MUST RAISE QUESTIONS THAT, WHEN
ANSWERED, WILL PROVIDE A BACKGROUND OF FUNDAMENTAL DETAILS
ABOUT THE SYSTEM AND DESCRIBE IT. ASKING THE FOLLOWING QUESTIONS
WILL HELP ACQUIRE THE NECESSARY UNDERSTANDING:
 WHAT IS THE PURPOSE OF THIS BUSINESS ACTIVITY? (OBJECTIVE)
 WHAT STEPS ARE PERFORMED?
UNDERSTAND THE PROCESS

 WHERE ARE THEY PERFORMED?  WHO PERFORMS THEM?

 HOW LONG DOES THIS TAKE?  HOW OFTEN IS IT DONE?
 WHO USES THE RESULTING INFORMATION?
UNDERSTAND THE PROCESS

•  SUPPOSE YOU ARE INVESTING AN INVENTORY RECORDING SYSTEM, SOMETHING

ABOUT WHICH YOU KNOW VERY LITTLE. YOU ASK ALL THE ABOVE QUESTIONS WITH
REFERENCE TO THE INVENTORY RECORDING SYSTEM.

• ANSWERS TO THESE QUESTIONS PROVIDE A BROAD UNDERSTANDING OF WHAT

INVENTORY RECORDING IS ALL ABOUT AND SHOW THAT THE OBJECTIVE OF INVENTORY
RECORDING IS MORE THAN JUST BUYING STOCK. BUT THERE IS NOT YET ENOUGH
INFORMATION TO FULLY UNDERSTAND THE SYSTEM.
TYPES OF REQUIREMENTS

1. FUNCTIONAL REQUIREMENT: IT POINTS TO THE STATEMENTS OF

SERVICES THAT THE SYSTEM SHOULD OFFER, HOW THE SYSTEM
SHOULD RESPOND TO SPECIFIC INPUTS AND HOW THE SYSTEM
SHOULD PERFORM IN SPECIFIC SITUATION.
 TYPES OF REQUIREMENTS

FUNCTIONAL REQUIREMENTS ESSENTIALLY:

 ILLUSTRATE FUNCTIONALITY OR SYSTEM SERVICES
 DEPEND ON THE CATEGORY OF SOFTWARE, PREDICTABLE USERS AND THE SORT OF
SYSTEM WHERE THE SOFTWARE IS USED
 FUNCTIONAL USER REQUIREMENTS MAY BE ELEVATED STATEMENTS OF WHAT THE
SYSTEM SHOULD DO; FUNCTIONAL SYSTEM REQUIREMENTS SHOULD ILLUSTRATE THE
SYSTEM SERVICES DETAIL.
 TYPES OF REQUIREMENTS

EXAMPLE:
 THE CONSUMER SHALL BE ABLE TO INVESTIGATE EITHER ALL OF THE PRELIMINARY SET OF
DATABASES OR CHOOSE A SUBSET FROM IT
 THE SYSTEM SHALL OFFER SUITABLE VIEWERS FOR THE USER TO READ DOCUMENTS IN
THE DOCUMENT STORE
 EACH ORDER SHALL BE ASSIGNED A UNIQUE IDENTIFIER (ORDER ID) WHICH THE USER
SHALL BE ABLE TO COPY TO THE ACCOUNT’S PERMANENT STORAGE REGION.
 TYPES OF REQUIREMENTS

2. NONFUNCTIONAL REQUIREMENT:
A PROPERTY OR EMINENCE THE SYSTEM MUST HAVE
 PERFORMANCE
 SECURITY
 COSTS
RESTRICTIONS ON THE SERVICES OR FUNCTIONS PROVIDED BY THE SYSTEM LIKE TIMING
CONSTRAINTS, RESTRICTIONS ON THE DEVELOPMENT PROCESS, STANDARDS, ETC.
A NON-FUNCTIONAL REQUIREMENT INCLUDES:
 PRODUCT REQUIREMENTS
 REQUIREMENTS WHICH STATE THAT THE DELIVERED PRODUCT MUST PERFORM IN A
SPECIFICMANNER, E.G. EXECUTION SPEED, RELIABILITY ETC.
 REQUIREMENTS WHICH ARE A RESULT OF ORGANIZATIONAL PLANS AND PROCEDURES, E.G.
PROCESS STANDARDS USED IMPLEMENTATION REQUIREMENTS ETC.
 REQUIREMENTS WHICH HAPPEN FROM FACTORS WHICH ARE EXTERNAL TO THE SYSTEM
AND ITS GROWTH PROCESS, E.G. INTEROPERABILITY REQUIREMENTS, GOVERNMENTAL
REQUIREMENTS ETC.