Chapter_3_System_requirement_specifications_and_Analysis_October.ppt

Chapter Three
System Requirement Specifications
System Requirement Specifications
& Analysis
& Analysis
AASTU-SWEG3109-System Analysis and
Modeling.2024/2025 A/Y: 1st Semester
1

Chapter 3- System Requirement Specifications & Analysis
3.1. What is Requirement Determination?
3.2. Requirement Finding Techniques
3.2. Requirement Finding Techniques
3.3. Requirement Analysis
3.3. Requirement Analysis
3.4. Structured Analysis vs. Object Oriented System Analysis
3.4. Structured Analysis vs. Object Oriented System Analysis
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st Semester
2

3.1. WHAT IS REQUIREMENT
3.1. WHAT IS REQUIREMENT
DETERMINATION?
DETERMINATION?
3

 Requirements determination : -activity of:
 Transforming a system request’s
ransforming a system request’s high-level business
requirements into a more detailed, precise list of what the new
into a more detailed, precise list of what the new
system must do to provide the needed value to the business.
system must do to provide the needed value to the business.
 Requirement: -
 A statement of what the system must
A statement of what the system must do
do or what
or what characteristics
characteristics
it needs to have
it needs to have.
.
 Focus
Focus on the “
on the “what
what” of the system &
” of the system & needs
needs of business user
of business user.
.
 Usually called business/user requirements (
business/user requirements (Analysis phase)
Analysis phase)
 become
become system requirements
system requirements -
-written from the developer's
written from the developer's
perspective (
perspective (Design phase)
Design phase)
 Can be:
Can be: functional
functional or
or non-functional
non-functional in nature.
in nature.
4
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st
Semester

3.1. What is Requirement Determination?...
A. Business requirements:
A. Business requirements: reasons for proposing
reasons for proposing the
the project. Help:
 Define the overall goal(s) of the system
Define the overall goal(s) of the system; and
 Clarify system contributions
Clarify system contributions to the organization’s success.
Examples :-Provide:
oproduct search capabilities
search capabilities,
o accurate project status reports
status reports
o account access to mobile customers
access to mobile customers.
oProduce performance reports
performance reports,
 Are the key measures for a project’s success
key measures for a project’s success.
 Provide the overall direction for the project
overall direction for the project.
AASTU-SWEG3109-System Analysis and Modeling.2024/2025 A/Y: 1st Semester 5

Chapter 3- System Requirement Specs & Analysis
A. Business requirements…
A. Business requirements…
 are written from the
written from the perspective of the business
perspective of the business; and
 focus on what the system needs
what the system needs to do to satisfy user needs.
A good starting place : concentrate on what the user actually needs to
concentrate on what the user actually needs to
accomplish with the system
accomplish with the system in order to fulfill a needed task.
B. User requirements
B. User requirements:
: describe tasks users perform
tasks users perform using the system.
Examples:
o Schedule a client appointment
Schedule a client appointment;
o Place a
Place a new customer order
new customer order;
o Re-order inventory
Re-order inventory”;
o Determine available credit
Determine available credit; etc.
 By understanding such requirements, the analyst can determine
ways in which the new system can support the users’ needs.
6

C.
C. Functional requirements (FRs):
Functional requirements (FRs): relates directly to :
 a process
process the system should perform
the system should perform to support user task
user task & /or
 Information
Information it should provide/contain
it should provide/contain as user performs a task.
 Describe product capabilities/things that a product must do for users.
Example:
 User requirement: “Schedule a client appointment
Schedule a client appointment.”
Functional requirements associated with that task
Functional requirements associated with that task may include:
o “Find available openings matching client availability,”
Find available openings matching client availability,”
o “Select desired appointment
Select desired appointment,”
o “Record appointment
Record appointment,” and
o “Confirm appointment
Confirm appointment.”
 FRs: flow directly into the creation of functional, structural, & behavioral
creation of functional, structural, & behavioral
models
models that represent the functionality of evolving system.
See more examples (next table)

Functional
Requirement
Description Examples
Process-
Oriented
A process
the system
must
perform/do
The system must/should:
 allow registered customers to:
 review their order history for the past 3
yrs
 check incoming customer orders for
inventory availability
 allow students to view a course schedule
while registering for classes.
Information-
oriented
Information
the system
must
contain
The system must :
retain customer order history for 3 years
 include real-time inventory levels at all
warehouses
 include budgeted & actual sales & expense
amounts for the current year & 3 previous yrs.

D. Non-functional requirements (NFR):
D. Non-functional requirements (NFR):
 Refer to behavioral properties
behavioral properties that the system must have
that the system must have, such as
performance & usability
performance & usability. Example:- the ability to access the system
access the system
through a mobile device
through a mobile device.
 Quality
Quality attributes
attributes, design, and implementation constraints
constraints, and
external
external interfaces
interfaces which a product must have.
 Takes center stage in design phase when decisions are made about
Takes center stage in design phase when decisions are made about
the :
the :
 user interface,
user interface,
 hardware & software, and
hardware & software, and
 system’s underlying architecture.
system’s underlying architecture.
 Discovered during interactions with users in the
Discovered during interactions with users in the analysis phase
analysis phase and
should be recorded as they are identified
should be recorded as they are identified.
See types of NFR with examples (next table)
See types of NFR with examples (next table)

NFR Description Examples
Operational They physical &
technical env’ts in
which the system
will operate
The system should :
run on Android mobile devices
Be able to integrate with existing inventory system
Be able to integrate with existing inventory system
Be compatible with any Web browser
Performance The speed, capacity,
& reliability of the
system
 Interaction b/n user & system should not exceed 2 Secs.
Interaction b/n user & system should not exceed 2 Secs.
 System should receive updated inventory info every 5 mins.
System should be available for use 24 hrs/day, 365 days/Yr.
The system supports 300 simultaneous users from 9-11AM; 150
simultaneous users at all other times
Security Who has authorized
access to the system
under what
circumstances
 Only direct managers can see personnel records
Technicians can see only their own work assignments
Customers can see their order history only during bus. hrs.
Customers can see their order history only during bus. hrs.
 System includes all available safeguards from viruses, worms,
Trojan horses, etc.
Cultural &
Political
Cultural, political
factors & legal
requirements that
affect the system
 The system should be able to distinguish b/n local & foreign
currencies (e.g: ETB vs USD).
 Company policy says that we buy computers only from IBM
Company policy says that we buy computers only from IBM
Country managers are permitted to authorize custom user
interfaces within their units.
Personal info is protected in compliance with Data Prot. Laws.

E. System requirements:
E. System requirements:
 Analysis phase Functional
Analysis phase Functional & nonfunctional requirements flow into:
nonfunctional requirements flow into:
 the
the design phase
design phase, where they evolve to become :
more technical
more technical,
describing
describing how the system will
how the system will be implemented.
be implemented.
 reflect the developer’s perspective
the developer’s perspective,
 These requirements focus on describing how to create the
describing how to create the software
software
product
product t
that will be produced from the project.

3.1. What is Requirement Determination?... Exercise
Exercise
One of the most common mistakes by new analysts is to confuse functional &
nonfunctional requirements. Assume that you received the following list of
requirements for a sales system
a sales system.
Requirements for Proposed System
The system should:
1. be accessible to the Web users;
2. include the company standard logo and color scheme;
3. restrict access to profitability information;
4. include actual and budgeted cost information;
5. provide management reports;
6. include sales information that is updated at least daily;
7. have 2-secs max response time for predefined queries & 10-minut max response time for ad hoc queries;
8. include information from all company subsidiaries;
9. print subsidiary reports in the primary language of the subsidiary;
10. provide monthly rankings of salesperson performance.
Questions
1. Which requirements are functional business requirements? Provide two additional examples of your own.
2. Which requirements are nonfunctional business requirements? What kind of nonfunctional requirements
are they? Provide two additional examples of your own

3.1. What is Requirement Determination?... Missing NFR
Missing NFR
What can happen if you ignore NFRs
What can happen if you ignore NFRs (Dennis, Wixom & Tegarden, 2012, p.114)

The Process of Determining Requirements:
The Process of Determining Requirements:
 Both business & IT perspectives are needed.
 Analysts may not understand the true business needs of users,
 Business users may not be aware of promising new technologies.
 Therefore, the most effective approach is to have both: involves
involves
significant interactions of analyst with
significant interactions of analyst with new system stakeholders
new system stakeholders.
1st
, identify the primary sources of requirements:
the project sponsor, project champion(s), system users
2nd
, elicit requirements from stakeholders.
– Use elicitation techniques (discussed later on) : interviews,
observation, questionnaires, JAD, and document analysis
3rd
, Critically analyze info gathered & then craft the requirement
definition statement.

4th
, verify, change, & complete the list of requirements and, if necessary,
prioritize the importance of the requirements; work with project team
& business users to achieve this.
 Uses d/t models (covered in later chapters) to clarify & define ideas.
Limit Requirement Evolution
Limit Requirement Evolution:
 Otherwise the system will keep on growing & never gets finished
system will keep on growing & never gets finished.
 Team carefully identifies & evaluates which additions fit within scope
identifies & evaluates which additions fit within scope.
 When a requirement reflects a real business need
requirement reflects a real business need, but is not within the
not within the
scope
scope of the current system or current release:
 evaluate its addition to current project, along with appropriate
adjustments to the project budget and time frame.
 The management of requirements (and system scope
system scope) is one of the
hardest parts of managing a project!

Requirements Definition: text report
text report that simply lists the functional &
lists the functional &
nonfunctional requirements in an outline format
nonfunctional requirements in an outline format.
Sample requirements definition for an appointment system for a typical
an appointment system for a typical
doctor’s office
doctor’s office (Dennis, Wixom & Tegarden, 2012, p.115)

Sometimes business
business
requirements are prioritized on
requirements are prioritized on
the requirements definition
the requirements definition.
They can be ranked as having:
 high, medium, or low
high, medium, or low importance
in the new system, or
they can be labeled with the
can be labeled with the
version of the system that will
version of the system that will
address the requirement
address the requirement like:
 Release 1, release 2, release 3.
Release 1, release 2, release 3.
Purposes
Purposes of Requirements definition:
of Requirements definition:
 define the
define the scope
scope of the system
of the system.
 describes
describes to the analysts exactly what the system needs to end up doing
exactly what the system needs to end up doing;
 serves as the place to go for clarification
serves as the place to go for clarification.

3.2. REQUIREMENT
3.2. REQUIREMENT
FINDING/GATHERING TECHNIQUES
FINDING/GATHERING TECHNIQUES
18

3.2. Requirement Finding/Gathering Techniques
3.2. Requirement Finding/Gathering Techniques
The requirement gathering process:
 The requirement gathering process is critical for ensuring the success of a
project by identifying and understanding all stakeholders' needs. Key points
include:
 Involve All Stakeholders: Engage managers, employees, customers, and suppliers
to ensure comprehensive input. This involvement not only captures diverse
needs but also builds political support and trust in the project.
 Avoid Exclusion Risks: Leaving out key stakeholders may lead to resistance or
dissatisfaction later, as they may feel their needs or insights weren’t considered.
 Common Techniques:
 interviews
interviews, JAD sessions
JAD sessions (a special type of group meeting), questionnaires
questionnaires,
document
document analysis
analysis, and observation
observation.
 Using these techniques provides a balanced, inclusive approach to understanding
requirements and creating a well-supported, effective system.
 Each technique has its own strengths and weaknesses
strengths and weaknesses, many of which are
complementary
complementary, so most projects use a combination of techniques.
most projects use a combination of techniques.

3.2. Requirement Finding/Gathering Techniques…
3.2. Requirement Finding/Gathering Techniques…
3.2.1. Interview:
3.2.1. Interview:
A.
A. As-is system:
As-is system: learn about the bussiness domain & its vocabulary
1st
, interview
interview senior managers to understand/ get the “big picture
“big picture”.
2nd
, document analysis
document analysis and,
3rd
, observation
observation of business processes to learn
learn more about as-is system
as-is system.
.
B.
B. To-be system
To-be system:
: Identifying improvements
Identifying improvements for the to-be system
to-be system
1st
, Interviews
Interviews with senior managers
senior managers,
2nd
, conduct JAD sessions with users of all levels
JAD sessions with users of all levels,
3rd
, questionnaires
questionnaires sent to a much larger group of users to get a broad range
larger group of users to get a broad range
of opinions.
of opinions.
 Interviews may be conducted:
 1-1
1-1 (1 interviewer & 1 interviewee);
(1 interviewer & 1 interviewee);
 When time constraint,
When time constraint, many people may be interviewed at a time
many people may be interviewed at a time

3.2.1. Interview…
3.2.1. Interview…
 5 basic steps to the interview process:
1.
1. Selecting
Selecting interviewees
interviewees,
2.
2. designing interview questions
designing interview questions,
3.
3. preparing for the interview
preparing for the interview,
4.
4. conducting the interview
conducting the interview, and
5.
5. post-interview follow-up
post-interview follow-up.
3.2.1.1. Selecting Interviewees
3.2.1.1. Selecting Interviewees
 Selected: based on the analyst’s information needs.
 The project sponsor & key business users can help the analyst find
the best candidates
 An interview schedule includes: interviewee , purpose of the
interview, and where and when it will take place

3.2.1. Interview…
3.2.1. Interview…
3.2.1.2. Designing Interview Questions
3.2.1.2. Designing Interview Questions
 Initial (as-is process)
Initial (as-is process) can be unclear
can be unclear=> use unstructured interviews :
 Interviews that seek broad & roughly defined set of info
o few closed-ended questions to ask.
 These are most challenging interviews: as they require
interviewer to ask open-ended questions & probe for important
info “on the fly.”
 As project progresses, analyst understands the business process much
better, hence use:
 structured interviews (specific, more of closed type questions)
are used to elicit very specific info about how business processes
are performed (e.g., exactly how a customer credit request is
approved).
 Organize interview questions into a logical sequence so that the
interview flows well.

Types of Questions Examples
Closed-Ended
Questions
How many phone orders are received/day? How do customers place
orders? What info is missing from monthly sales report?
Open-Ended
question
What do you think about the way invoices are processed?
What are some of the problems you face everyday?
What are some of the improvements you would like to see in the way
invoices are processed?
Probing Questions Why? Can you give me an example?
Can you explain that in more detail?
3.2.1.2. Designing Interview Questions:
3.2.1.2. Designing Interview Questions: closed-ended, open-ended, & probing.
Question level Examples
High level: very general How can order processing be improved?
Medium-level:
moderately specific
How can we reduce the # of times that customers return
items they have ordered?
Low-level: very specific How can we reduce the # of errors in order processing
(like shipping the wrong products)?
organizing the interview questions: top/generic-down/specic (High/Low level)

3.2.1. Interview…
3.2.1. Interview…
3.2.1.3. Preparing for the Interview
3.2.1.3. Preparing for the Interview
1.
1. Lists the questions in the appropriate order
Lists the questions in the appropriate order; anticipate possible
answers and plan how you will follow up with them
plan how you will follow up with them.
2. Confirm the areas in which the interviewee has knowledge
2. Confirm the areas in which the interviewee has knowledge so you do
not ask questions that he or she cannot answer.
o Review topic areas, questions
Review topic areas, questions, & interview plan
interview plan, and clearly decide
which ones have the greatest priority in case you run out of time.
3. Be sure to prepare the interviewee as well
3. Be sure to prepare the interviewee as well.
o Inform interviewee of reason for the interview
Inform interviewee of reason for the interview in advance so that
he/she has time to think about issues & organize his/her thoughts.
 This is particularly important if you are external to the orgn
particularly important if you are external to the orgn; &
for interviewing lower-level employees- who may be uncertain
lower-level employees- who may be uncertain
about why you are interviewing them.
about why you are interviewing them.

3.2.1. Interview…
3.2.1. Interview…
3.2.1.4. Conduct the Interview
3.2.1.4. Conduct the Interview
 Be professional & an unbiased, independent
Be professional & an unbiased, independent seeker of information.
 Explain why you are there and why you have chosen to interview the person, and
then move into your planned interview questions.
 Carefully tape-record/write all the information
Carefully tape-record/write all the information that the interviewee provides
o If you do not understand something, be sure to ask again.
If you do not understand something, be sure to ask again.
 Before closing, give the interviewee time to ask questions/provide
give the interviewee time to ask questions/provide information
that he/she thinks is important but was not part of your interview plan.
 At last, briefly explain what will happen next
briefly explain what will happen next, say, to reassure the interviewee that
his or her time was well spent and very helpful to the project
his or her time was well spent and very helpful to the project.
3.2.1.5.
3.2.1.5. Post-interview Follow-up
 Write the interview report within 48 hours
Write the interview report within 48 hours to avoid forgetting the information.
 Send the interview report to the interviewee for comments
Send the interview report to the interviewee for comments.
 If interviewee suggests any significant changes, it means a second
interview will be required.
 Never distribute someone’s information without prior approval.
Never distribute someone’s information without prior approval.

3.2.2. Joint Application Development (JAD)
3.2.2. Joint Application Development (JAD)
 project team, users, & mgt work together
team, users, & mgt work together to identify requirements
 Developed by IBM
Developed by IBM in the late 1970s
in the late 1970s.
 Claimed to:
 reduce scope creep by 50%,
reduce scope creep by 50%, &
 prevent requirements from being too specific or too vague
prevent requirements from being too specific or too vague.
 Structured process
Structured process in which: 10–20 users meet guided by a facilitator
facilitator
 facilitator:
o sets meeting agenda
sets meeting agenda, guides the discussion
guides the discussion,
o does not provide opinions, i.e., remains neutral during session
does not provide opinions, i.e., remains neutral during session.
o may be an outside consultant,
outside consultant, having expertise
expertise in group process
group process
techniques, systems analysis & design
systems analysis & design techniques & business area
business area.
 1 or 2 scribes assist facilitator by recording notes, making copies, and so on.
 JAD group meets for several hours, several days, or several weeks
several hours, several days, or several weeks until all
issues have been discussed and the needed information is collected.

3.2.2. Joint Application Development (JAD)…
 Most JAD sessions take place in a specially prepared meeting room
specially prepared meeting room:
 with white board, projector, flip chart
white board, projector, flip chart… ,
 away from participants’ offices
away from participants’ offices, to avoid interruption.
Problem: offices may lead closing offices; curtail services of VIPs
Limitation
Limitation: people may be reluctant to challenge opinions of others
(particularly their boss); hence a few people often dominate the
discussion, and not everyone participates.
 Electronic JAD (via groupware): help to overcome these limitations.
 each participant can anonymously submit ideas,
anonymously submit ideas, view all ideas
generated by group, rate & rank ideas through voting.
 Facilitator guides process, maintain anonymity & enable group to
focus on each idea’s merits & not power/rank of person
 All participants contribute, without fear of reprisal
All participants contribute, without fear of reprisal
 Claimed: e-JAD
Claimed: e-JAD can reduce time required
reduce time required for JAD sessions
for JAD sessions by 50–80%
by 50–80%

3.2.2.1. Selecting Participants
 Based on
Based on ability to contribute
ability to contribute, to provide a broad
provide a broad mix of organizational
mix of organizational
levels
levels, & to build political support for new system
build political support for new system.
3.2.2.2. Designing the JAD Session
3.2.2.2. Designing the JAD Session
 Most JAD sessions
JAD sessions tend to last: 5–10 days spread over a 3-week
5–10 days spread over a 3-week.
 Most e-JAD sessions
e-JAD sessions tend to last: 1–4 days in a 1-week period
1–4 days in a 1-week period.
 Prepare questions
Prepare questions before the meeting.
 A difference between JAD & interviewing:
 All JAD sessions
All JAD sessions are structured
structured—they must be carefully planned
must be carefully planned.
 Seldom use Closed-ended questions:
Seldom use Closed-ended questions: they do not spark open & frank
do not spark open & frank
discussion
discussion that is typical of JAD.
 Proceed top-down/generic to specific/
Proceed top-down/generic to specific/ when gathering info.
 Typically, 30 minutes is allocated to each separate agenda item
30 minutes is allocated to each separate agenda item, and
 Frequent breaks
Frequent breaks are scheduled: because participants tire easily
because participants tire easily.

3.2.2.3. Preparing for the JAD Session
3.2.2.3. Preparing for the JAD Session
 Sessions can go deeper than interview
Sessions can go deeper than interview & are conducted off-site
conducted off-site,
 Make sure that participants understand what is expected of them
Make sure that participants understand what is expected of them.
 Goal->understand current system=>
Goal->understand current system=> bring procedure manuals & docs.
bring procedure manuals & docs.
 Goal-> identify system improvement(to-be system)=> think about ways
improvement(to-be system)=> think about ways
3.2.2.4. Conducting the JAD Session
3.2.2.4. Conducting the JAD Session
Common ground rules
Common ground rules: follow schedule
schedule, respecting others’ opinions &
respecting others’ opinions &
accept disagreement
accept disagreement, & only one person speaks
only one person speaks at a time
at a time.
3 Functions of JAD facilitator
3 Functions of JAD facilitator:
1. Ensure that the group sticks to the agenda
sticks to the agenda.
2. Help the group understand :
Help the group understand :
 the
the technical terms/jargons
technical terms/jargons of system development process
 the
the specific analysis techniques
specific analysis techniques used
used.
29

3.2.2.4. Conducting the JAD Session…
3. Make sure Group’s input is:
3. Make sure Group’s input is:
 visible on display area:
visible on display area: whiteboard/flip chart/projector
whiteboard/flip chart/projector,
 Structured
Structured ; => helps the group recognize key issues & solutions
helps the group recognize key issues & solutions.
 May use tools to fully define the new system:
 Create Use cases
Create Use cases: to describe how users will interact with new system,
 Create Prototypes
Create Prototypes: to understand user interface/ navigation
 Alternatively, use Process models
Process models to understand the software and
data models
data models to describe the data that will be captured & maintained.
3.2.2.5. Post-JAD Follow-up
 Prepare a JAD post-session report & circulate it among session attendees
circulate it among session attendees.
 Since the JAD sessions are longer and provide more information,
 usually takes one or two weeks
one or two weeks to complete preparing the report
preparing the report.

3.2.3. Questionnaires
3.2.3. Questionnaires
Questionnaire
Questionnaire: set of written questions for obtaining info from
obtaining info from
individuals
individuals.
 Used to solicit info from large number of people
solicit info from large number of people.
 Commonly used to gather information from:
 outside users- e.g., customers/vendors
outside users- e.g., customers/vendors or
 business users spread across many geographic locations.
users spread across many geographic locations.
 Can be distributed in electronic form: via e-mail or on the Web.
 Typically, a sample/subset/representative people are selected.
 Not everyone who receives a questionnaire will complete it
Not everyone who receives a questionnaire will complete it.
 On average only:
 30–50% of paper & e-mail questionnaires
paper & e-mail questionnaires are returned.
5–30% for Web-based questionnaires
Web-based questionnaires

3.2.3. Questionnaires…
3.2.3.2. Designing the Questionnaire
 Write Questions clearly
Write Questions clearly: to avoid misunderstanding;
 Commonly used questions: Closed-ended questions
 Separate opinion from facts:
Separate opinion from facts:
o Opinions
Opinions : agree/disagree. e.g., Are network problems common?
o Facts
Facts: seek precise values. e.g., How often does a network problem occur:
e.g., once an hour/a day/a week?.
 Key-issue: Be clear about to analyze and use the collected info.
Guidelines on questionnaire design
Guidelines on questionnaire design
Begin with nonthreatening & interesting questions; Group items logically;
Don’t put important items in the end; Avoid abbreviations;
Don’t crowd a page with too many items; Avoid biased/suggestive terms;
Number questions to avoid confusion;
Pretest the questionnaire to identify confusing questions;
Provide anonymity to respondents

3.2.3.3. Administering the Questionnaire
 Ensure participants will complete & send it back. Helpful
Helpful
techniques
techniques:
 Explaining purpose
purpose & why the respondent has been selected
why the respondent has been selected;
 State a returning date
returning date
 offering gift
offering gift (e.g., a free pen); and
 Promising to supply a summary
Promising to supply a summary of the questionnaire responses.
 With in an organization
With in an organization: you (analyst) can personally distribute &
collect.
3.2.3.4. Questionnaire follow-up
 Develop a report
Develop a report soon after the questionnaire deadline.
 This ensures respondents who requested copies of the results
copies of the results
receive them promptly.
receive them promptly.

3.2.4. Document Analysis:
3.2.4. Document Analysis: Often used to understand the as-is system
understand the as-is system.
 Review existing system documentation: reports, memorandums, policy
manuals, user training manuals, organization charts, &forms.
 Review problem reports:
Review problem reports: filed by the system users
 Documents represent the formal system:
 Quite often, “real,” /informal system differs from the formal one, and
 Large differences
differences b/n them give strong indications of what needs to be
b/n them give strong indications of what needs to be
changed
changed.
Example:
 forms/reports that are never used; (likely should be eliminated;
 Boxes on forms that are never filled in ; (should be rethought).
 The most powerful indication that the system needs to be changed:
 when users create their own forms/add information
users create their own forms/add information to existing ones.
 when users must access multiple reports to satisfy their info needs
access multiple reports to satisfy their info needs;
 it is a clear sign that new info or new formats
clear sign that new info or new formats are needed.

PREPARED GOOGLE FORM FOR YOUR
PROJECT REQUIREMENT COLLECTION AND
SEND THE LINK TO ME WITH FULL ACCESS
IF YOU DO DISCUSSION, AND/ OR ,
OBSERVATION BRING PHOTO AS EVIDENCE
35

3.2.5. Observation
3.2.5. Observation:
: act of watching processes being performed
 Powerful tool to gain insight into the as-is system
gain insight into the as-is system.
 Enables analyst to see the reality of a situation:
 Rather than listening to others describe it in interviews/ JAD
sessions.
 Many managers don’t remember how they work & allocate time
don’t remember how they work & allocate time.
 A good way to check validity of info gathered
check validity of info gathered from other methods
such as interviews and questionnaires.
 Often used to supplement interview information
supplement interview information.
 For example:- analyst might become skeptical of someone who
analyst might become skeptical of someone who
claims to use the existing computer system extensively
claims to use the existing computer system extensively
o if the computer is never turned on while the analyst visits.
 Mostly, observation will support the info provided in interviews.
o When it does not, it is an important signal that extra care
is an important signal that extra care
must be taken in analyzing the business system
must be taken in analyzing the business system.

Criteria Interview JAD Questionn-
aire
Doc
Analysis
Observ-
ation
Type of info As-is, improve-
ments, to-be
As-is, improve-
ments, to-be
As-is, improve-
ments,
As-is As-is
Depth of info High High Medium Low Low
Breadth of
info
Low Medium High High Low
Integration of
info
Low High Low Low Low
User
involvement
Medium High Low Low Low
Cost Medium Low-Medium Low Low Low-Medium
Selecting the Appropriate Elicitation Techniques
No single technique is always better than others;
 projects benefit form combinations of techniques
Analyst's experience: In general, document analysis & observation require
least amount of training, while JAD sessions are the most challenging
Comparison of Requirement Elicitation Techniques(Dennis, Wixon & Tegarden, 2012, p.141)
Comparison of Requirement Elicitation Techniques(Dennis, Wixon & Tegarden, 2012, p.141)

3.3. REQUIREMENT ANALYSIS
3.3. REQUIREMENT ANALYSIS
STRATEGY - RAS
STRATEGY - RAS
38

3.3. Requirement Analysis Strategies-RAS
3.3. Requirement Analysis Strategies-RAS
 Before determining requirements have a clear,
 vision of the kind of system that will be created
vision of the kind of system that will be created and
 level of change
level of change that it will bring to the organization.
 The basic process of analysis is divided into 3 steps:
1st
, understanding the as-is system
understanding the as-is system,
2nd
, identifying improvements
identifying improvements, and
3rd
, developing requirements for the to-be system
developing requirements for the to-be system.
 When no system exists/existing system & process are irrelevant to future
no system exists/existing system & process are irrelevant to future
system/if team uses RAD or Agile
system/if team uses RAD or Agile, 1st
step is skipped or performed briefly.
 3 requirements-analysis strategies :
– Business Process Automation-BPA,
Business Process Automation-BPA,
– Business Process Improvement-BPI, &
Business Process Improvement-BPI, &
– Business Process Reengineering-BPR
Business Process Reengineering-BPR
 RAS & Requirements-gathering techniques go hand in hand, i.e., concurrently
& are complementary activities

3.3. Requirement Analysis Strategies-RAS…
 Choice of RAS is based on the amount of change needed in the orgn:
 BPA: is based on small change that improves process efficiency
small change that improves process efficiency,
 BPI creates process improvements that lead to better effectiveness
improvements that lead to better effectiveness,
 BPR: revamps & transforms the way things work ; MAJOR CHANGE
revamps & transforms the way things work ; MAJOR CHANGE
3.3.1. Business Process Automation-BPA
3.3.1. Business Process Automation-BPA
 Leaves the basic way the organization operates unchanged
Leaves the basic way the organization operates unchanged & uses
computer technology to do some of the work
computer technology to do some of the work
 can
can make organization more efficient
make organization more efficient but has least impact on business
least impact on business.
 BPA projects need spending significant time understanding as-is system
significant time understanding as-is system
before moving on to improvements & to-be system requirements.
 Problem analysis & root cause analysis
Problem analysis & root cause analysis are two popular BPA techniques.
3.3.1.1.
3.3.1.1. Problem Analysis-
Problem Analysis- asking users & managers to:
 identify problems with the as-is system &
 describe how to solve them in the to-be system.

 Small & incremental Improvements
Small & incremental Improvements (e.g., add a field to store customer’s cell
phone number; provide a new report that currently does not exist).
 Often very effective at improving a system’s efficiency or ease of use
effective at improving a system’s efficiency or ease of use.
 However, it often provides only minor improvements in business value
provides only minor improvements in business value:
 the new system is better than the old
new system is better than the old,
 But hard to identify significant monetary benefits from the new system
hard to identify significant monetary benefits from the new system
 The solutions
solutions that users propose/analysts consider may address
may address either:
 Symptoms
Symptoms or
or causes
causes,
,
 but without careful analysis
but without careful analysis, it is difficult to tell which one.
3.3.1.2. Root Cause Analysis:
3.3.1.2. Root Cause Analysis: Focuses on problems first rather than solutions
Focuses on problems first rather than solutions
1st
, generate a list of problems
generate a list of problems with the current system, then:
 prioritizes the problems in order of importance
prioritizes the problems in order of importance;
 generate all possible root causes for the problem
possible root causes for the problem.
2nd
, Investigate each possible root cause to identify additional root causes
Investigate each possible root cause to identify additional root causes.

3.3. Requirement Analysis Strategies…
 Key point
Key point: always challenge the obvious & dig into the problem deeply
challenge the obvious & dig into the problem deeply so
that true underlying cause(s) is revealed. E.g.: Inventory Stock-outs
E.g.: Inventory Stock-outs

Example of Business Process Automation (BPA)
Amazon’s Order Processing
•As-Is System: Before automation, Amazon’s order processing relied heavily on
manual labor. Workers had to:
• Manually locate products within large warehouses.
• Physically pick, pack, and label orders.
• Transport items to shipping areas.
•Limitations: This manual process was labor-intensive, slower, and prone to human
error, leading to inefficiencies in order fulfillment times and accuracy, particularly
as demand grew..
43

3.3.2. Business Process Improvement (BPI)
 makes moderate changes
makes moderate changes to the way the organization operates- to take
advantage of new tech opportunities/copy what competitors are doing.
 Can improve efficiency
improve efficiency (doing things right, i.e., productivity ) and
improve effectiveness
improve effectiveness (doing the right things- quality of end results).
 BPI projects also spend time understanding the as-is system, but much
less time than with BPA projects; their primary focus is on improving
primary focus is on improving
business
business processes
processes, so time is spent on the as-is only to help with the
improvement analyses and the to-be system requirements.
 Three Popular BPI Activities:
 Duration analysis,
 activity-based costing, and
 informal benchmarking.

3.3.2.1.
3.3.2.1. Duration Analysis:
 Perform detailed examination of time taken
detailed examination of time taken for each process in as-is system.
1st
, determine total time it takes, on average, to perform a set of business
determine total time it takes, on average, to perform a set of business
processes for a typical input.
processes for a typical input.
2nd
, then time each of the steps/sub-processes of the business process
then time each of the steps/sub-processes of the business process.
3rd
, Aggregate the time to complete the basic steps
Aggregate the time to complete the basic steps & compare with the total
compare with the total
for the overall process.
for the overall process.
 A significant difference between the two—i.e., often total time taking
often total time taking
longer than sum of the parts—indicates that this part of the process is
longer than sum of the parts—indicates that this part of the process is
badly in need of a major overhaul.
badly in need of a major overhaul.
Example: Analysts are working on a home mortgage system
home mortgage system.
.
 Bank mortgage approval, on average, takes 30 days
takes 30 days
 Each basic step like data entry, credit check, title search, appraisal
data entry, credit check, title search, appraisal, etc.) for
each mortgage is actually about 8 hours
actually about 8 hours.
 Overall process is badly broken: taking 30 days to perform 1 day’s work
Overall process is badly broken: taking 30 days to perform 1 day’s work.

3.3.2.1.
3.3.2.1. Duration Analysis: …
 Major cause may be: badly fragmented process
Major cause may be: badly fragmented process.
 D/t people must perform d/t activities before the process is
D/t people must perform d/t activities before the process is
complete
complete.
 Mortgage application probably sits on many peoples’ desks for long
periods of time before it is processed.
 Processes in which many different people work on small parts of the
inputs are prime candidates for process integration or parallelization
process integration or parallelization.
 Process integration:
Process integration: changing fundamental process so that fewer
people work on input; may require retraining staff to do a wider range
of duties.
 Process parallelization:
Process parallelization: changing the process so that all individual steps
are performed at the same time.
Example:- Mortgage application process: The credit check
credit check can be
performed in parallel with the appraisal
appraisal and title check
title check

3.3.2.2.
3.3.2.2. Activity-Based Costing:
Examines the
Examines the cost
cost of each major process/step
of each major process/step in a business process
rather than the
rather than the time
time taken
taken.
 Analysts identify costs associated with each basic functional
identify costs associated with each basic functional
steps/processes
steps/processes, identify the most costly processes
identify the most costly processes, and focus their
focus their
improvement efforts on them.
improvement efforts on them.
 Assigning costs is conceptually simple: Examine
e the direct cost of
direct cost of
labor & materials
labor & materials for each input.
for each input.
Materials costs: are easily assigned in a manufacturing process,
labor costs: calculated on the basis of amount of time spen
calculated on the basis of amount of time spent on
the input and the hourly cost of the staff.
hourly cost of the staff.
However, there are indirect costs
indirect costs such as rent
rent, depreciation
depreciation, etc
so on that also can be included in activity costs.

3.3.2.3. Informal Benchmarking:
3.3.2.3. Informal Benchmarking:
Benchmarking: studying how other organizations perform a business process
studying how other organizations perform a business process
in order to learn how your organization can do something better
to learn how your organization can do something better.
 helps the organization by introducing ideas that employees may never
have considered, but that have the potential to add value
have the potential to add value.
 Informal benchmarking : fairly common for “customer-facing” business
processes (i.e., those processes that interact with the customer).
 Managers & analysts think about other organizations, or visit them as
visit them as
customers to watch how the business process is performed
customers to watch how the business process is performed. In many
cases, the business studied may be a known leader in the industry
business studied may be a known leader in the industry or
simply a related firm
a related firm.
Example: Developing a website for a car dealer.
Developing a website for a car dealer.
 The project sponsor, key managers, and key team members would likely
visit the website of competitors, those of others in the car industry
visit the website of competitors, those of others in the car industry (e.g.,
manufacturers, accessories suppliers), and those of other industries that
have won awards for their websites.
48

Example of Business Process Improvement (BPI)
Starbucks’ Mobile Ordering System
•As-Is System: Previously, Starbucks relied on in-person orders only:
• Customers had to wait in line, order at the counter, and pay in person.
• During peak hours, long queues resulted in customer dissatisfaction and increased wait times.
•Limitations: The traditional process was time-consuming, especially during busy
times, leading to slower service and missed sales opportunities as customers
opted out of waiting.
49

3.3.3.
3.3.3. Business Process Reengineering-BPR
BPR: changing the fundamental way the organization operates,
changing the fundamental way the organization operates, obliterating the
obliterating the
current way of doing business
current way of doing business and
and making major changes
making major changes to take advantage of
take advantage of
new ideas
new ideas and
and new technology
new technology.
 BPR projects spend little time understanding the as-is
spend little time understanding the as-is, because their goal is to
focus on new ideas and new ways of doing business.
 BPR activities: outcome
outcome & technology
technology analysis, & activity elimination
activity elimination .
3.3.3.1. Outcome Analysis:
3.3.3.1. Outcome Analysis: focuses on understanding the fundamental
focuses on understanding the fundamental
outcomes
outcomes that provide value to customers.
Example: an insurance company handling customers with car accident.
 Traditional insurance companies assumption: customer wants to receive the insurance payment
quickly.
 Customer: payment is only a means to the real outcome: a repaired car.
 Insurance company might benefit: not only paying for repairs but performing
repairs/contracting with an authorized body shop to do them.
 With this approach, system analysts encourage managers & project sponsor to pretend that
they are customers & to think carefully about what the organization’s products & services
enable customers to do—and what they could enable the customer to do.
50

3.3.3.2. Technology Analysis
3.3.3.2. Technology Analysis
 Many major changes in business can be enabled by new technologies
changes in business can be enabled by new technologies.
1st
, analysts & managers develop a list of important & interesting technologies
develop a list of important & interesting technologies.
2nd
, Systematically identify how each and every technology could be applied to
identify how each and every technology could be applied to
the business process & identifies how the business would benefit
the business process & identifies how the business would benefit.
Example: Using Extranet application.
Using Extranet application.
 A manufacturer could develop an extranet application for its suppliers
develop an extranet application for its suppliers.
 Rather than ordering parts for its products, the manufacturer:
manufacturer:
 makes its production schedule available electronically to its suppliers
makes its production schedule available electronically to its suppliers,
 Supplier ships the needed parts so that they arrive at the plant just in time
Supplier ships the needed parts so that they arrive at the plant just in time.
 This saves significant costs because it eliminates the need for people to:
saves significant costs because it eliminates the need for people to:
 monitor the production schedule and
monitor the production schedule and
 issue purchase orders.
issue purchase orders.

3.3.3.3. Activity Elimination:
3.3.3.3. Activity Elimination: is exactly what it sounds like.
 Analysts & managers work together to identify how organization could eliminate :
 each & every activity in the business process, how the function could
each & every activity in the business process, how the function could
operate without it, and what effects are likely to occur.
operate without it, and what effects are likely to occur.
 This is a “force-fit” exercise: managers must eliminate each possible activity.
Sometimes, the results are silly; nonetheless, participants must address each and
participants must address each and
every activity in the business process.
every activity in the business process.
Example:- mortgage approval process
 Managers & analysts would start by eliminating the first activity, entering the data
into the mortgage company’s computer. This leads to one of two obvious
possibilities: (1) Eliminate the use of a computer system or (2) make someone else
do the data entry (e.g., customer, over the Web).
 They would then eliminate the next activity, the credit check. How? If almost all
applicants have good credit & are seldom turned down by a credit check, then cost
of the credit check may not be worth the benefit of the few bad loans it prevents.
Eliminating it may actually result in lower costs, even with the cost of bad loans,
unless the number of applicants with poor credit greatly increases.

Example of Business Process Reengineering (BPR)
Netflix’s Shift from DVD Rental to Streaming
•As-Is System: Netflix originally operated as a DVD rental-by-mail service:
• Customers placed orders for DVDs on Netflix’s website.
• DVDs were physically mailed to customers, who returned them when finished.
• The process involved shipping times, inventory management of physical DVDs, and postal service dependencies.
•Limitations: This business model was slower, required physical inventory
management, and incurred high shipping costs. With the rise of internet speeds
and demand for instant content, the DVD model was increasingly outdated.
53

Comparing Analysis Strategies
 Each strategy has its own purpose: No one technique is inherently
better than the others.
 Remember that an organization will likely have a wide range of projects
in its portfolio;
 The analysis strategy should be chosen to fit the nature of the project.
 BPA-Problem analysis and root cause analysis tend to be most useful in
situations with a narrow focus where efficiency gains
narrow focus where efficiency gains are sought.
 BPI-Duration analysis and activity-based costing strategies help the
team find the most “broken” business processes
find the most “broken” business processes so that those processes
can be redesigned and improved.
 BPR-Outcome analysis, technology analysis, and informal benchmarking
help the team think “outside the box” and are very useful when the
think “outside the box” and are very useful when the
team is trying to create completely new ways
team is trying to create completely new ways of accomplishing the
business processes.

Factor/Characteristics BPA BPI BPR
Potential Business Value Low-moderate Moderate High
Project Cost Low Low-moderate High
Breadth of analysis Narrow Narrow-moderate Very broad
Risk Low-moderate Low-moderate Very high
Characteristics of Analysis Strategies

20 Min Writing
Write the functional requirement from user perspective for the following
scenario. NOTE: You honest opinion is required
The MoH aims to develop a mobile application to provide adolescents and
young adults (ages 10-24) with health-related information and services
regarding topics such as HIV, sexually transmitted diseases, hepatitis,
sexual reproductive health, and substance use. The app will cater to three
age groups (10-14, 15-19, and 20-24) and include features like community
discussions, healthcare provider information, and AI-based counseling.
– Age-Specific Content Delivery
– Account Creation
– Community Forum
– Healthcare Provider Information
– Incentive System
– Content Formats
56

3.4. STRUCTURAL ANALYSIS (SA) VS.
3.4. STRUCTURAL ANALYSIS (SA) VS.
OBJECT ORIENTED ANALYSIS (OOA )
OBJECT ORIENTED ANALYSIS (OOA )
57

3.4. Structural Analysis (SA) Vs. Object Oriented Analysis (OOA )
3.4. Structural Analysis (SA) Vs. Object Oriented Analysis (OOA )
 Both methods provide:
 their own representational notations for constructing a set of models during the
SDLC.
 techniques and constructs to model an IS in terms of its data and processes that act
upon the data.
 Both methods aim to dissect and comprehend the intricacies of a system
 They differ significantly in their principles, techniques & conceptual frameworks
Structured Analysis:
Structured Analysis:
 Principle
Principle: emphasize to breakdown/decompose a system into smaller, more
emphasize to breakdown/decompose a system into smaller, more
manageable components, focusing on data flow and processes
manageable components, focusing on data flow and processes.
 Represent system components primarily using DFDs & DDs, emphasizing data flow and
DFDs & DDs, emphasizing data flow and
relationships
relationships
 Models focus/emphasize on processes/behavior
processes/behavior
 Relies on concepts of functions, data flows and hierarchies
concepts of functions, data flows and hierarchies.

3.4. Structural Analysis (SA) Vs. Object Oriented Analysis (OOA )…
3.4. Structural Analysis (SA) Vs. Object Oriented Analysis (OOA )…
Object-Oriented Analysis (OOA):
Object-Oriented Analysis (OOA):
 Principle
Principle: modeling the system as a network of
a network of interacting
interacting
objects, encapsulating both data and behavior
objects, encapsulating both data and behavior, to mirror real-
, to mirror real-
world entities
world entities closely
 Emphasizes: the identification of classes, objects, attributes,
identification of classes, objects, attributes,
and methods
and methods, facilitating a more modular, reusable, and
modular, reusable, and
intuitive design approach
intuitive design approach.
 Benefits
Benefits: provides a continuum of representation from analysis
to design to implementation, thus engendering a seamless
transition from one model to another.
 Provides significant reusability features thus speeding
significant reusability features thus speeding
up/simplifying system maintenance and change management
up/simplifying system maintenance and change management.

Aspect Structured Analysis OOA
Basic
Concept
Focuses on breaking down a system
into smaller components using DFDs
Models a system as a collection of
interacting objects
Abstraction Primarily deals with processes and
data flow
Abstracts the system into objects
encapsulating data and behavior
Modularity Components are primarily processes/
functions & data elements
Encourages modular design through
classes and objects
Relationship
Representation
Emphasizes DFDs & Data Dictionary Focuses on identifying classes, objects,
attributes & methods
Reusability Limited scope for reusability due to
procedural nature
Facilitates reusability through class
inheritance & composition
Flexibility &
Scalability
Less flexible & scalable due to rigid
structure
Offers greater flexibility and scalability
through inheritance
Real-World
Modeling
May struggle to mirror real-world
entities closely
Offers a more intuitive approach to
modeling real-world entities
Developmen
t
Environment
Suitable for projects with straight
forward requirements & relatively
simple systems
Suitable for complex projects with
evolving requirements, as it offers
greater flexibility, modularity and
scalability

Chapter_3_System_requirement_specifications_and_Analysis_October.ppt

More Related Content

Similar to Chapter_3_System_requirement_specifications_and_Analysis_October.ppt (20)

Recently uploaded (20)

Chapter_3_System_requirement_specifications_and_Analysis_October.ppt

Editor's Notes