Object-Oriented System Analysis and

Design

Chapter III- Requirement Elicitation

Collecting and organizing users requirement- WHAT-
User needs
Basic objectives of the chapter
Define requirement and related concepts?
Understand requirement identification and
collection techniques
◦ using traditional method
◦ essential use case modeling
◦ CRC modeling
◦ essential user interfaces modeling
◦ Supplementary specifications
Beingfamiliar with validating, organizing and
documenting requirements

2
Requirement and related concepts
What is requirement?
◦ Definition
◦ Types
 Functional, non-functional, pseudo- requirement
Requirement engineering – includes
◦ Elicitation –system specification
◦ Analysis – system(structured analysis) models

05/28/24 3
 What is a Requirement ?
It is a statement describing either
◦ 1) an aspect of what the proposed system must do,
◦ or 2) a constraint on the system’s development.
◦ In either case it must contribute in some way towards
adequately solving the customer’s problem;
◦ the set of requirements as a whole represents a
negotiated agreement among the stakeholders.
A collection of requirements is a requirements
document.

05/28/24 4
Types of Requirements
Functional requirements
◦ Describe what the system should do
Non-functional requirements
◦ Quality requirements
 Constraints on the design to meet specified levels of
quality
Pseudo requirements
◦ Platform requirements
 Constraints on the environment and technology of the
system
◦ Process requirements
 Constraints on the project plan and development
methods

05/28/24 5
Functional Requirements
◦ What inputs the system should accept
◦ What outputs the system should produce
◦ What data the system should store that other
systems might use
◦ What computations the system should perform
◦ The timing and synchronization of the above

05/28/24 6
 Quality Requirementts
Allmust be verifiable
Examples: Constraints on
◦ Response time
◦ Throughput
◦ Resource usage
◦ Reliability
◦ Availability
◦ Recovery from failure
◦ Allowances for maintainability and enhancement
◦ Allowances for reusability

05/28/24 7
Cont..
Requirement elicitation
◦ Is about a communication b/n developers and
user in defining a new system
◦ Failure to do so will lead to “unwanted”
◦ Errors introduced at this stage are expensive
system
◦ Focus on describing the purpose of the system
◦ Results in system specification

05/28/24 8
Cont..
System specification Vs Analysis model
◦ Represent same information
◦ Difference only on the language and notation
they use
◦ Both- more of external aspect of the system
visible to users (users' view)
◦ They occur concurrently and iteratively

05/28/24 9
How to conduct?
Through techniques like
◦ Traditional methods
◦ Essential use case
◦ CRC model
 Identifying initial analysis objects
◦ Essential user interface
◦ Identification of non-functional requirement
Theseall techniques will help us in
making domain analysis

05/28/24 10
 Domain Analysis
The process by which a software engineer
learns about the domain to better understand the
problem:
◦ The domain is the general field of business or
technology in which the clients will use the software
◦ A domain expert is a person who has a deep
knowledge of the domain
Benefits of performing domain analysis:
◦ Faster development
◦ Better system
◦ Anticipation of extensions

05/28/24 11
Defining the Problem and the Scope
A problem can be expressed as:
◦ A difficulty the users or customers are facing,
◦ Or as an opportunity that will result in some
benefit such as improved productivity or sales.
The solution to the problem normally will
entail developing software/system
A good problem statement is short and
concise

05/28/24 12
Defining the Scope
Narrow the scope by defining a more
precise problem
◦ List all the things you might imagine the
system doing
 Exclude some of these things if too broad
 Determine high-level goals if too narrow
Example: A university registration system

05/28/24 13
Cont…

Initial list of problems Narrowed Scope of

with very broad scope scope another system

browsing courses browsing courses

room allocation room allocation
registering registering
exam scheduling exam scheduling
fee payment fee payment

05/28/24 14
 Who should be a member of
requirement elicitation team?
Identify stakeholders
◦ (any one who could be affected by the impl.
of the system)- customers, end-users..
Choose best Subject matter expert (SME)
◦ (who knows the business, think logically,
communicate well, willing to invest time on the
software development)
Choose good facilitator or scriber
◦ (with good communication skill)

05/28/24 15
Remarks on the process
Result in the specification of the system
that the client and user can understand
(natural language)
It should be validated for
correctness (according to the user)
completeness (all requirements)
Consistency (No contradiction)
Unambiguousness (clear)
realistic (that can be implemented)

05/28/24 16
Reviewing Requirements
◦ Each individual requirement should
 Have benefits that outweigh the costs of development
 Be important for the solution of the current problem
 Be expressed using a clear and consistent notation
 Be unambiguous
 Be logically consistent
 Lead to a system of sufficient quality
 Be realistic with available resources
 Be verifiable
 Be uniquely identifiable
 Does not over-constrain the design of the system

05/28/24 17
Requirements documents...
◦ The document should be:
 sufficiently complete
 well organized
 clear
 agreed to by all the stakeholders

◦ Traceability: Requirements
document
rationale Design
1.1 XXXX
document
.... because
1.2 YYYY
....due to
requirement 1.2

05/28/24 18
 Difficulties and Risks in Domain
and Requirements Analysis
◦ Lack of understanding of the domain or the real problem
 Do domain analysis and prototyping
◦ Requirements change rapidly
 Perform incremental development, build flexibility into the design,
do regular reviews
◦ Attempting to do too much
 Document the problem boundaries at an early stage, carefully
estimate the time
◦ It may be hard to reconcile conflicting sets of requirements
 Brainstorming, JAD sessions, competing prototypes
◦ It is hard to state requirements precisely
 Break requirements down into simple sentences and review them
carefully, look for potential ambiguity, make early prototypes

05/28/24 19
How to elicit (collect) requirement)
Research/Document Analysis
◦ The document Analysis part a method by
which the system analyst go through each
documents used and relevant to all the
processes covered by the system.
◦ The documents will give information about
the data to be captured and the presentation of
the data to the users of the system.

05/28/24 20
Cont…
Direct Observation
◦ Direct observation is a method used to verify the
already gather information and to add on to
requirement.
◦ The method will help to see how users behave and
do things in their day to day activity.
Questionnaires and Surveys
◦ The Survey Method is an electronic or paper
based method of soliciting needs or requirements
from stakeholders.
◦ The survey method is a list of questions, directed
at identifying stakeholder needs or requirements.

05/28/24 21
 Cont…
Interviews
◦ An interview is a conversation with stakeholders to
elicit or validate needs and requirements.
◦ An interview may include one or more
stakeholders.
◦ The interview may also involve a question and
answer session used to discover other potential
stakeholders and any discrepancies between needs;
the high-level requirements derived from those
needs; and the resulting detailed requirements.
◦ Interviews facilitate obtaining approval from
stakeholders on their needs, requirements, and any
changes to them.

05/28/24 22
Cont…
Joint Application Design (JAD):
◦ The Joint Application Development (JAD)
technique is an extended, facilitated
workshop.
◦ It involves collaboration between stakeholders
and systems analysts to identify needs or
requirements in a concentrated and focused
effort.

05/28/24 23
Remarks on Gathering and Analysing
Requirements
 On Observation
◦ Read documents and discuss requirements with users
◦ Shadowing important potential users as they do their work
 ask the user to explain everything he or she is doing
◦ Session videotaping
 On Interviewing
◦ Conduct a series of interviews
 Ask about specific details
 Ask about the stakeholder’s vision for the future
 Ask if they have alternative ideas
 Ask for other sources of information
 Ask them to draw diagrams

05/28/24 24
Cont...
 On Brainstorming
◦ Appoint an experienced moderator
◦ Arrange the attendees around a table
◦ Decide on a ‘trigger question’
◦ Ask each participant to write an answer and pass
the paper to its neighbour

! !

! !
!

 Joint Application Development (JAD) is a technique

based on intensive brainstorming sessions
05/28/24 25
Cont…
Using essential use case modeling
◦ Use Cases are used to capture the intended
behaviour of the system under development
(requirements of a system)
◦ In terms of Use case, actors and relationships
(use case diagram) and use case
documentation

05/28/24 26
Cont…
Requirement Elicitation tasks (using use
case)
◦ Identify actors: Hints
 Actors are external to the system- human or another system
 Represent roles
 Question you should ask
 Which user group are supported by the syetm to perform
their task?
 Which user groups execute the systems major function?
 Will the system interact with any external hardware or
software?

05/28/24 27
Cont…
◦ Identify use cases
 First identify scenarios or examples of
system usage and compile or represent some
similar scenarios with one case.
 Question to be asked
 What are the tasks that the actor wants the system
to perform?

05/28/24 28
 Cont…
◦ Identify relationships
 To reduce complexity and increase understandability
 Communication(association), include (use), extend, and
generalization
 Questions to be asked
 Is there any relationship that needs to be factored out among use
cases? If yes ‘include’ will solve it
 Is there any exceptional or optional cases? If yes “extend” will
solve it
 Is there two or more possibilities for accomplishing a case? If yes
“generalization” will solve it

05/28/24 29
So…
Now at this stage you have some
understanding about the system/software
to be developed from functional point of
view
What is next should be
◦ Again collecting requirements from structural
point of view

05/28/24 30
END OF CHAPTER III-PART
I

TO BE CONTINUED

05/28/24 31