9/28/2021
CSE304
Object Oriented Software
Engineering
Week 3
Dr. Iftikhar Azim Niaz
ianiaz@comsats.edu.pk
ianiaz@yahoo.com
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
Revision - 1
● Ways in which projects are identified and initiated
● It is important to link the information system to business needs of
the organization
● Purpose of the systems request and explain the contents of its
sections
● Create a systems request for a proposed project
● Purpose of the feasibility study
● Issues that are considered when evaluating a project’s technical
feasibility
● Develop an economic feasibility assessment for a project
● Evaluate the organizational feasibility of a project
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
1
2
2
9/28/2021
Revision - 2
● How projects are selected
● Describe a task
● Create a standard work breakdown structure, a Gantt Chart, and a
Network Diagram
● Perform PERT analysis and identify the critical path
● Estimate the system development effort using use-case points
● Create an evolutionary work breakdown structure
● Iterative and incremental development using timeboxing addresses
scope management
● Characteristics of a “jelled” team
● Issues relating to motivating software developers
● Importance of CASE tools, standards, and documentation managing
software development projects
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
3
Chapter 3:
Requirements Determination
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
3
4
4
Topics Covered
● Creating a Requirements Definition
● Requirements Analysis Techniques and Application
● Requirements Gathering Techniques
● Requirements Documentation Techniques
● Creation of a System Proposal
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
5
Introduction
● The systems development process transforms the
existing (as is) system into the proposed (to be)
system
● Requirements determination
 The single most critical step of the entire SDLC
 Changes can be made easily in this stage as little work has
been done yet
 Most (>50%) system failures are due to problems with
requirements
● The iterative process of OOSAD is effective because:
 Small batches of requirements can be identified and
implemented incrementally
 The system will evolve over time
6
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
5
6
Requirements Determination
● What is a requirement?
 A statement of what the system must do or a characteristic it must
have
 Will later evolve into a technical description of how the system will be
implemented
● Purpose: to convert high level business requirements (from
the system request) into detailed requirements that can be
used as inputs for creating models
● Types:
 Functional: relates directly to a process a system has to perform or
information it needs to contain
 Non-functional: relates to behavioural properties that the system
must have such as performance or usability
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
7
Requirements Determination
● Business Requirements
 They focus on the “What” of the system
 They focus on the needs of the business user, usually called
business requirements (and sometimes user requirements)
● System requirements
 They describe how the system will be implemented
 They are written from the developer’s perspective and are
usually called system requirements
8
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
7
8
Requirements Definition
● Requirements can be either functional or nonfunctional in nature.
● A functional requirement relates directly to a
process a system has to perform or information it
needs to contain. For example, requirements stating
that a system must have
 the ability to search for available inventory or
 to report actual and budgeted expenses
● Functional requirements flow directly into the
creation of functional, structural, and behavioral
models that represent the functionality of the
evolving system
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
9
Non-Functional Requirements
● Refer to behavioral properties that the system must have
 such as performance and usability
 The ability to access the system using a Web browser is considered a
nonfunctional requirement
● Can influence the rest of analysis (functional, structural, and
behavioral models) but often do so only indirectly;
● Nonfunctional requirements are used primarily in design
when decisions are made about
 the database, the user interface, the hardware and software, and the
system’s underlying physical architecture
● They describe a variety of characteristics regarding the
system
 operational, performance, security, and cultural and political
10
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
9
10
Non-Functional Requirements
● Operational requirements address issues related to
the physical and technical requirements in which the
system will operate
● Performance requirements address issues related to
the speed, capacity, and reliability of the system
● Security requirements deal with issues with regard
to who has access to the system and under what
specific circumstances
● Cultural and political requirements deal with issues
related to the cultural, political factors and legal
requirements that affect the system
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
11
Requirements from Quality Perspective
● Functional quality is related to the degree that the
software meets the functional requirements, i.e., how
much of the actual problem is solved by the software
solution provided.
● The nonfunctional requirements are associated
with the efficiency, maintainability, portability,
reliability, reusability, testability, and usability
quality dimensions.
● The nonfunctional related dimensions are associated
primarily with the actual detailed design and
implementation of the system
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
11
12
12
Requirements Definition
● The requirements definition report
 a straightforward text report
 lists the functional and nonfunctional requirements in an outline format
● The business requirements are prioritized
 They can have high, medium, or low importance in the new system, or
they can be labeled with the version of the system that will address the
requirement (e.g., release 1, release 2, release 3).
 important when using object-oriented methodologies since they deliver
systems in an incremental manner
● Provide the information needed by the other deliverables in
analysis, which include functional, structural, and behavioral
models, and to support activities in design
● The purpose of the requirements definition, is to define the scope
of the system
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
13
Sample of
Requirements
Definition
Appointment
System for a
typical doctor’s office
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
13
14
14
Determining Requirements
● Business & IT personnel need to collaborate to
determine the business requirements
● Strategies for problem analysis:
 Root cause analysis
 Duration analysis
 Activity-based costing
 Informal benchmarking
 Outcome analysis
 Technology analysis
 Activity elimination
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
15
Determining Requirements
● Requirements are best determined by systems analysts and
business people together
● Analysts use a portfolio of requirements gathering
techniques to acquire information from the users.
● Techniques for identifying requirements





Interviews
Questionnaires
Observation
Joint application development (JAD) and
Document analysis
● information gathered using these techniques is critically
analyzed and used to craft the requirements definition report
16
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
15
16
Creating a Requirements Definition
● Determine the types of functional and non-functional
requirements applicable to the project
● Use requirements-gathering techniques to collect
details
● Analysts work with users to verify, change and
prioritize each requirement
● Continue this process through analysis workflow, but
be careful of scope creep(changes, continuous or
uncontrolled growth in a project’s scope)
● Requirements that meet a need but are not within
the current scope can be added to a list of future
enhancements
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
17
Problems in Requirements Determination
● Analyst may not have access to the correct set of users to
uncover the complete set of requirements
 Can lead to requirements being missed, misrepresented and/or
over specified
● Requirements specifications may be inadequate
● Some requirements may not be known in the beginning
of the development process
 However, as the system is developed, the users and analysts will
get a better understanding of both the domain issues and the
applicable technology
 This can cause new functional and non-functional requirements
to be identified and current requirements to evolve or be
canceled
● Verifying and validating requirements can be difficult
18
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
17
18
Topics Covered
● Creating a Requirements Definition
● Requirements Analysis Techniques and
Application
● Requirements Gathering Techniques
● Requirements Documentation Techniques
● Creation of a System Proposal
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
19
Requirements Analysis Strategies
● The basic process of analysis is divided into three (3) steps:
 understanding the as-is system,
 identifying improvements, and
 developing requirements for the to-be system
● Requirements analysis strategies help the analyst lead users
through the analysis steps so that the vision of the system
can be developed
● To move the users from the as-is system to the to-be system,
an analyst needs strong critical thinking skills
● Eight (8) strategies
 Problem Analysis, Root Cause Analysis, Duration Analysis, Activitybased Costing,
 Informal benchmarking, Outcome analysis, Technology Analysis and
Activity Elimination
20
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
19
20
1. Problem Analysis
● most commonly used requirements-analysis technique
● means asking the users and managers to identify problems with
the as-is system and to describe how to solve them in the to-be
system
● Improvements from problem analysis tend to be small and
incremental e.g.,
 provide more space in which to type the customer’s address
 provide a new report that currently does not exist
● This type of improvement often is very effective at improving a
system’s efficiency or ease of use.
● However, it often provides only minor improvements in business
value—the new system is better than the old, but it may be hard
to identify significant monetary benefits from the new system
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
21
2) Root Cause Analysis
● The ideas produced by problem analysis tend to be solutions to
problems.
● All solutions make assumptions about the nature of the problem,
assumptions that might or might not be valid
● Root cause analysis focuses on problems, not solutions
● The analyst starts by having the users generate a list of problems with
the current system and then prioritize the problems in order of
importance.
● Starting with the most important, the users and/or the analysts then
generate all the possible root causes for the problems.
● Each possible root cause is investigated (starting with the most likely
or easiest to check) until the true root causes are identified.
● If any possible root causes are identified for several problems, those
should be investigated first, because there is a good chance they are the
real root causes influencing the symptom problems
22
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
21
22
2) Root Cause Analysis - Example
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
23
3) Duration Analysis
● Duration analysis requires a detailed examination of the amount
of time it takes to perform each process in the current as-is
system.
● The analysts begin by determining the total amount of time it
takes, on average, to perform a set of business processes for a
typical input.
● They then time each of the individual steps (or sub-processes) in
the business process.
● The time to complete the basic step is then totaled and compared
to the total for the overall process.
● A significant difference between the two—the total time often can
be 10 or even 100 times longer than the sum of the parts—
indicates that this part of the process is badly in need of a major
overhaul.
24
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
23
24
4) Activity Based Costing
● Is a similar analysis
● examines the cost of each major process or step in a
business process rather than the time taken
● Analysts identify the costs associated with each of the
basic functional steps or processes, identify the most
costly processes, and focus their improvement efforts on
them
● Assigning costs is conceptually simple
● Analysts simply examine the direct cost of labor and
materials for each input
 Materials costs are easily assigned in a manufacturing process,
 whereas labor costs are usually calculated based on the amount
of time spent on the input and the hourly cost of the staff
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
25
5) Informal Benchmarking
● Benchmarking refers to studying how other organizations
perform a business process in order to learn how your
organization can do something better
● Benchmarking helps the organization by introducing ideas that
employees may never have considered but that have the potential
to add value
● Informal benchmarking is fairly common for customer-facing
business processes (i.e., processes that interact with the
customer)
● With informal benchmarking, the managers and analysts think
about other organizations or visit them as customers to watch
how the business process is performed
● In many cases, the business studied may be a known leader in the
industry or simply a related firm
26
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
25
26
6) Outcome Analysis
● focuses on understanding the fundamental outcomes that provide
value to customers
● Although these outcomes sound as though they should be obvious,
they often are not
 e.g., consider an insurance company. One of its customer has had a car
accident. What is the fundamental outcome from customer’s perspective
 For Insurance Company, customer wants insurance payment quickly
 For Customer, payment is only a means to real outcome: a repaired car
● With this approach, system analysts encourage the managers and
project sponsor to pretend they are customers and
● to think carefully about what the organization’s products and
services enable the customers to do—and
● what they could enable the customer to do
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
27
7) Technology Analysis
● Many major changes in business since the turn of the
century have been enabled by new technologies
● Technology analysis starts by having the analysts and
managers develop a list of important and interesting
technologies
● Then the group systematically identifies how every
technology could be applied to the business process and
identifies how the business would benefit
● It is important to note the technology analysis in no way
implies adopting technology for technology’s sake
● Rather the focus is on using new technologies to meet the
goals of the organization
28
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
27
28
8) Activity Elimination
● The analysts and managers work together to identify
 how the organization could eliminate each activity in the
business process,
 how the function could operate without it, and
 what effects are likely to occur
● Initially, managers are reluctant to conclude that
processes can be eliminated, but this is a force-fit
exercise in that they must eliminate each activity
● In some cases, the results are silly;
● nonetheless, participants must address every activity
in the business process
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
29
Topics Covered
● Creating a Requirements Definition
● Requirements Analysis Techniques and Application
●Requirements Gathering Techniques
● Requirements Documentation Techniques
● Creation of a System Proposal
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
29
30
30
Requirements Gathering Techniques
● Process is used to:
 Uncover all requirements for the new system
 (those uncovered late in the process are more difficult to incorporate)
 Build political support for the project
 Build support and trust among the project team building the system
and users
● Which technique(s) to use to gather information?





Interviews
Joint Application Development (JAD)
Questionnaires
Document analysis
Observation
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
31
Interviews
● Most common and popular technique—if you need to know
something, just ask
● Generally conducted one-to-one but sometime due to time
constraints, several people are interviewed at the same time
● Process consists of five (5) basic steps:
1. Select people to interview & create an interview schedule
1. Who will be interviewed, when and for what purpose
2. Design interview questions (Open-ended, closed-ended, & probing
types of questions)
3. Prepare for the interview (Unstructured vs. structured interview
organized in a logical order)
4. Conduct the interview (Top-down vs. bottom-up)
5. Follow-up after the interview
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
31
32
32
Interview Question Types
34
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
Sample Interview Schedule
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
9/28/2021
33
33
34
CSE304 Object Oriented Software
Engineering Week 3
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
Interviewing Strategies
Top‐down
High‐level:
Very general
Medium‐level:
Moderately specific
Low‐level:
Very specific
How
can order
processing be
improved?
How can we reduce the
number of times that customers
return ordered items?
How can we reduce the number of
errors in order processing (e.g., shipping
the wrong products)?
Bottom‐up
35
Post-Interview
● Prepare notes and send to the interviewee for verification
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
35
36
36
Joint Application Development (JAD)
● An information-gathering technique that allows the project team,
users, and management to work together to identify requirements
for the system
● JAD is a structured process in which Joint user-analyst meeting
hosted by a facilitator skilled in JAD techniques
 10 to 20 users
 1 to 2 scribes as needed to record the session
 Usually in a specially prepared room
● The JAD group meets for several hours, several days, or several
weeks until all the issues have been discussed and the needed
information is collected
● Sometimes people are reluctant to challenge the opinions of others
(particularly their boss), a few people often dominate the
discussion, and not everyone participates
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
37
electronic JAD, or e-JAD
● A new form of JAD
● In an e-JAD meeting room, each participant uses special
software on a networked computer to send anonymous ideas
and opinions to everyone else
● Meetings can be held electronically and anonymously
 Reduces problems in group settings
 Can be held remotely
● Sessions require careful planning to be successful
 Users may need to bring documents or user manuals
 Ground rules should be established
● One difference between JAD and interviewing is that all JAD
sessions are structured—they must be carefully planned
38
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
37
38
Five Steps of JAD Approach
● Select participants
 selected in the same way as are interview participants
● Design a JAD session
 JAD sessions can run from as little as half a day to several weeks, depending upon
the size and scope of the project
● Preparing for a JAD session
 important to prepare the analysts and participants for a JAD session
 Important that the participants understand what is expected of them
● Conducting a JAD Session
 Most JAD sessions follow a formal agenda, and most have formal ground rules that
define appropriate behavior
 Common ground rules include following the schedule, respecting others’ opinions,
accepting disagreement, and ensuring that only one person talks at a time
● Post JAD Follow up
 a JAD post-session report is prepared and circulated among session attendees
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
39
Questionnaires
● A set of written questions used to obtain information from
individuals
● used when there is a large number of people from whom
information and opinions are needed.
● a common technique with systems intended for use outside
the organization
 e.g., by customers or vendors or
 for systems with business users spread across many geographic
locations
● May be paper based or electronic (e.g., e-mail or web based)
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
39
40
40
Questionnaires
● Common uses:
 Large numbers of people
 Need both information and opinions
 When designing for use outside the organization (customers,
vendors, etc.)
● Typical response rates: < 50% (paper); < 30% (Web)
● Questions on questionnaires must be very clearly written
and leave little room for misunderstanding
 so closed-ended questions tend to be most commonly used
● The key issue in administering the questionnaire is
getting participants to complete the questionnaire and
send it back
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
41
Questionnaire Steps
● Select the participants
 Identify the population
 Use representative samples for large populations
● Designing the questionnaire
 Careful question selection
 Remove ambiguities
● Administering the questionnaire
 Working to get good response rate
 Offer an incentive (e.g., a free pen)
● Questionnaire follow-up
 Send results to participants
 Send a thank-you
42
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
41
42
Good Questionnaire Design
● Begin with non-threatening and interesting questions
● Group items into logically coherent sections
● No important items at the very end
● Do not crowd a page with too many items
● Avoid abbreviations
● Avoid biased or suggestive items or terms
● Number questions to avoid confusion
● Pretest to identify confusing questions
● Provide anonymity to respondents
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
43
Document Analysis
● Project teams often use document analysis to understand the
as-is system
● Under ideal circumstances, the project team that developed
the existing system will have produced documentation that
was then updated by all subsequent projects
 In this case, the project team can start by reviewing the documentation
and examining the system itself
● Unfortunately, many systems are not well documented
because project teams fail to document their projects along the
way, and when the projects are over, there is no time to go
back and document
 Therefore, there might not be much technical documentation about the
current systems available, or
 it might not contain updated information about recent system changes
44
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
43
44
Document Analysis
● Provides information about the “as-is” system
● Review technical documents when available
● Review typical user documents:
 Forms
 Paper Reports
 Policy manuals
 Memorandums
 User-training manuals
 Organization charts
 User interface with the existing system
● Look for user additions to forms
● Look for unused form elements
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
45
Performing a Document Analysis
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
45
46
46
Observation
● the act of watching processes being performed,
● a powerful tool for gathering information about the as-is
system
● it enables the analyst to see the reality of a situation, rather
than listening to others describe it in interviews or JAD
sessions
● Observation is a good way to check the validity of
information gathered from indirect sources such as
interviews and questionnaires
● Analyst walks through the organization and observes the
business system as it functions
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
47
Observation
● Users/managers often don’t remember everything they
do
● Checks validity of information gathered in other ways
● Behaviors may change when people are watched
 Workers tend to be very careful when watched
● The goal of observation is to
 keep a low profile,
 not interrupt those working, and
 not influence those being observed
● Be careful not to ignore periodic activities
 Weekly … Monthly … Annually
48
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
47
48
Selecting the Appropriate Technique
●
●
●
●
A combination of techniques may be used
Document analysis & observation require little training
JAD sessions can be very challenging
Analyst experience also makes a significant impact
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
49
Topics Covered
● Creating a Requirements Definition
● Requirements Analysis Techniques and Application
● Requirements Gathering Techniques
●Requirements Documentation Techniques
● Creation of a System Proposal
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
49
50
50
Requirements Documentation Techniques
● Other requirements-gathering and documentation
techniques include:
● Throwaway prototyping
● Use cases
● Role-playing
● CRC cards with use-case-based scenarios
● Concept mapping, and
● Recording user stories on story cards and task lists
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
51
Concept Maps
● Represent meaningful relationships between concepts
● Useful for focusing individuals on a small number of key
ideas on which they should concentrate
● A concept map is essentially a node-and-arc representation
 where the nodes represent the individual requirements and
 the arcs represent the relationships among the requirements
 Each arc is labeled with a relationship name
● is not limited to a hierarchical representation
● allow the relationships among the functional and
nonfunctional requirements to be explicitly represented
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
51
52
52
Concept Maps
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
53
User Stories, Story Cards & Task Lists
● Associated with agile development methods
● Very low tech, high touch, easily updatable, and very portable
● Captured using story cards (index cards) and are recorded on a
task list. File card with single requirement
● Capture both functional and nonfunctional requirements.
● e.g., with regard to the doctor’s office appointment example, a
functional requirement-based story could be:
● As a secretary, I want to be able to schedule appointments for our
patients so that we can meet our patients’ needs.
● While an operational nonfunctional requirement-based story
could be: As a secretary, I want to be able to print the daily
schedule using wireless technology so that all printing can be
performed using a shared printer without having to deal with
printer cables connecting all of the computers to the printer
54
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
53
54
User Stories, Story Cards & Task Lists
● Once the story is written down, it is discussed to determine
the amount of effort it will take to implement it
 During the discussion, a task list is created for the story
 If the story is deemed to be too large—e.g., there are too many tasks
on the task list—the story is split up into multiple stories each being
recorded on its own story card and the tasks are allocated across the
new stories
● The story can be prioritized by importance by placing a
rating on the card
● The story can also be evaluated for the level of risk
associated with it
● The importance level and amount of risk associated with the
story can be used to help choose which requirements to
implement first
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
55
Topics Covered
● Creating a Requirements Definition
● Requirements Analysis Techniques and Application
● Requirements Gathering Techniques
● Requirements Documentation Techniques
●Creation of a System Proposal
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
55
56
56
The System Proposal
● Combines all material created in planning & analysis
into a single comprehensive document
● Included sections:
 Executive summary
 Provides all critical information is summary form
 Helps busy executives determine which sections they need to read in
more detail
 The system request
 The workplan
 The feasibility analysis
 The requirements definition
 Models of the new system (expected to evolve)
 Functional, structural and behavioral models
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
57
System Proposal Template
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
57
58
58
Summary
● Creating a requirement definition
● Discussion of functional and non-functional requirements
determination
● Requirements analysis strategies
 Problem analysis
 Root cause analysis
 Duration analysis
 Activity-based costing analysis
 Informal benchmarking analysis
 Outcome analysis
 Technology analysis and
 Activity elimination
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
59
Summary
● Requirements Gathering Techniques
 Interviews
 Joint Application Development (JAD)
 Questionnaires
 Document analysis and
 Observation
● Requirements Documentation Techniques
 Concept maps
 Story cards and
 Task lists
● Purpose and contents of the system proposal
60
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
59
60
Recommended Readings
1. System Analysis and Design: An Object-Oriented
Approach with UML by Alan Dennis, Barbara Haley
Wixom and David Tegarden, 5th Ed, John Wiley & Sons,
2015
 Chapter 3
9/28/2021
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
CSE304 Object Oriented Software
Engineering Week 3
61
Thank
You
CSE304
Object Oriented Software Engineering
COMSATS University, Islamabad (CUI)
61
62
62