Object-Oriented System Analysis and

Design

Chapter III- Requirement Workflow

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
• Being familiar with validating, organizing and
documenting requirements

1
 The Unified Process (UP)

The five core workflows are:

● requirements – capturing what the system should do;
● analysis – refining and structuring the requirements;
● design – realizing the requirements in system
architecture;
● implementation – building the software;
● test – verifying that the implementation works as
desired.

7/9/2018 3

Why do we need Requirements?

• When 38 IT professionals in the UK were asked about

which project stages caused failure, respondents
mentioned “requirements definition” more than any other
phase.

2
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 requirement is a statement about an intended product
that specifies what it should do or how it should perform.
•A collection of requirements is a requirements
document.

7/9/2018 5

7/9/2018 6

3
 Requirements Engineering

Requirements Engineering

Requirements Requirements
Development Management

Elicitation Analysis Specification Verification

Larry Boldt, Trends in Requirements Engineering

People-Process-Technology, Technology Builders, Inc., 2001

Requirements management

• What is it?
• a systematic approach to eliciting, organizing, and
documenting the requirements of the system,
• a process that establishes and maintains changing
requirements.
• Important and helpful for real projects
• Common problems
• No.1: Can’t track change
• No.2: Difficult to write
• More…

4
About the steps…

•Requirements elicitation
• Requirements discovered through consultation with stakeholders
•Requirements analysis and negotiation
• Requirements are analyzed and conflicts resolved through
negotiation
•Requirements specification
• A precise requirements document is produced
•Requirements validation
• The requirements document is checked for consistency
and completeness

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
such as availability, performance, usability, etc
•Pseudo requirements
• Platform requirements
• Constraints on the environment and technology of the
system
• Process requirements
• Constraints on the project plan and development methods

7/8/2018 10

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

7/8/2018 11

Example – ATM System:

Functional requirements might be:

1. The ATM system shall check the validity of the inserted ATM card.
2. The ATM system shall validate the PIN number entered by the
customer.
3. The ATM system shall dispense no more than $250 against any ATM
card in any 24-hour period.

A non-functional requirement is a constraint placed on the system.

For the ATM system, non-functional requirements might be:
1. The ATM system shall be written in C++.
2. The ATM system shall communicate with the bank using 256-bit
encryption.
3. The ATM system shall validate an ATM card in three seconds or less.
4. The ATM system shall validate a PIN in three seconds or less.

7/9/2018 12

6
Quality Requirements

• All must be verifiable

• Examples: Constraints on
◦ Response time
◦ Throughput
◦ Resource usage
◦ Reliability
◦ Availability
◦ Recovery from failure
◦ Allowances for maintainability and enhancement
◦ Allowances for reusability

7/8/2018 13

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” system
• Focus on describing the purpose of the system
• Results in system specification

7/8/2018 14

7
Cont..

• System specification Vs Analysis model

• Represent same information
• Difference only on the language and notation they use
• Both describe more of external aspect of the system
visible to users (users' view)
• They occur concurrently and iteratively

7/8/2018 15

How to conduct?

• Through techniques like

• Traditional methods like interview
• Essential use case
• CRC model
• Identifying initial analysis objects
• Essential user interface
• Identification of non-functional requirement
• All the above techniques will help us in making domain
analysis

7/8/2018 16

8
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,
e.g. Finance, personnel, marketing, etc
• A domain expert is a person who has a deep
knowledge of the domain e.g. accountant for finance
system
•Benefits of performing domain analysis:
• Faster development
• Better system
• Anticipation of extensions

7/8/2018 17

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

7/8/2018 18

9
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

7/8/2018 19

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

7/8/2018 20

10
Example: Library System
• Idea: A Library Management System should be
designed. Information on books, CDs, DVDs,
Journals, etc. can be stored and retrieved
• Possible Requirements
• Searching by Title, Author, and/or ISDN should be possible
• User Interface should be web-based (accessible via WWW Browser)
• At least 20 transactions per seconds should be possible
• All services should be available within 10 minutes
• Users have no access to personal data of other users

7/8/2018 21

Member of Elicitation team?

• Identify stakeholders
• (any one who could be affected by the implementation 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)

7/8/2018 22

11
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)

7/8/2018 23

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

7/8/2018 24

12
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
.... bec ause
1.2 YYYY
....due to
requirement 1.2

7/8/2018 25

Difficulties and Risks in Domain and

Requirements Analysis guides
• 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

7/8/2018 26

13
How to Elicit (collect) Requirements
• Research/Document Analysis
• The document Analysis is 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.

7/8/2018 27

Data Gathering Techniques

• Questionnaires: Series of questions designed to
elicit specific information from us. The questions
may require different kinds of answers: some
require a simple Yes/No, others ask us to choose
from a set of pre-supplied answers.

• Interviews: Interviews involve asking someone a

set of questions. Often interviews are face-to-face,
but they don’t have to be (more on next page).

14
Data Gathering Techniques (continued)

• Interviews:
• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
• Good for exploring issues
• But are time consuming and may be
infeasible to visit everyone

Data-gathering techniques
• Focus groups and workshops: Interviews tend to be
one on one, and elicit only one person’s
perspective. It can be very revealing to get a group
of stakeholders together to discuss issues and
requirements.

• Naturalistic Observation: It can be very difficult for

humans to explain what they do or to even describe
accurately how they achieve a task. (more on next
page)

15
Data-gathering Techniques (continued)
• Naturalistic observation:
• Spend time with stakeholders in their day-to-day tasks,
observing work as it happens
• Gain insights into stakeholders’ tasks
• Good for understanding the nature and
context of the tasks
• But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
• Ethnography is one form : entire class devoted to this.

Cont…

•Direct Observation
• Direct observation is a method used to verify the
already gathered 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.

7/8/2018 32

16
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.

7/8/2018 33

Data-gathering techniques

• Studying documentation: Procedures and rules are often

written down in a manual and these are a good source of
data about the steps involved in an activity and any
regulations governing a task.

Use All of the above In Combination :

Constraints of Time and Money

17
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

7/8/2018 35

Cont…

• Joint Application Design (JAD):

• The Joint Application Development (JAD) technique is an
extended, facilitated workshop.
• It involves collaboration between users, managers and systems
analysts and system designers to identify needs or
requirements in a concentrated and focused group discussion.

7/8/2018 36

18
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

7/8/2018 37

Elicitation – Essential use case

• 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

7/8/2018 38

19
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?

7/8/2018 39

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?

7/8/2018 40

20
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

7/8/2018 41

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

7/8/2018 42

21
System Modeling will continue

7/8/2018 43

22