Requirement Basics

Nguyen Thai Son

Business Analyst

© Copyright 2006 FPT Software 1

 Topics Covered

§ Requirement Overview
§ Requirement Engineering Process
§ Types of Requirement
§ Requirement Documents
§ How to analyze the requirements?

© Copyright 2006 FPT Software 2

 Requirement Overview
What is software life cycle?

§ Waterfall (V-Model) § Agile (Scrum, Extreme)

© Copyright 2006 FPT Software 3

 Requirement Overview
Definition

§ Requirements are descriptions of the services that a

software system must provide and the constraints under
which it must operate.

§ Requirements can range from high-level abstract

statements of services, or system constraints to detailed
functional specifications.

© Copyright 2006 FPT Software 4

 Requirement Overview
Requirement Types

§ Functional requirements specify what the product must

do
– Use Cases
– System Behavior
Functional user requirements: what system should do in high-level.
Functional system requirements: describe system services in detail.
§ Non functional requirements: the properties that the
product must have
– Security
– Usability
– Performance
– Look and Feel
– Maintainability, Portability
– Other interacting systems
© Copyright 2006 FPT Software 5
 Requirement Overview
Requirement Types (cont.)
Requirement Types Sample - Library Management System
§ The system shall maintain records of all library materials
including books, serials, newspapers and magazines, video and
audio tapes, reports, collections of transparencies, computer
disks and CD-ROMS.
§ The system shall allow the users to search for an item by title,
author, or ISBN.
§ The system’s user interface shall be displayed using Internet
Explorer 5 and above
§ The system shall support at least 20 transactions per second.
§ There should be no more than 3 clicks from homepage to reach
search results.
§ The access permissions for system data may only be changed
by the system’s data administrator
© Copyright 2006 FPT Software 6
 Requirement Overview
Requirement Types (cont.)
Requirement Types Sample - Library Management System
§ The system shall maintain records of all library materials
[General requirements: set out in broad terms what the system should do]
§ The system shall allow the users to search for an item by title, author,
or ISBN.
[Functional requirements]
§ The system’s user interface shall be displayed using Internet Explorer
5 and above
[Implementation requirements]
§ The system shall support at least 20 transactions per second.
[Performance requirements to specify minimum acceptable performance]
§ There should be no more than 3 clicks...
[Usability]
§ The access permissions for system data may
[Security]

© Copyright 2006 FPT Software 7

 Requirement Overview
Requirement vs. Design
§ Separate activities? Focus on What vs. How
initially
– What: Abstract behavior of system feature
+ User will be able to register
– How: How it is implemented
+ System will persist user data using JDBC, Oracle
and JavaBeans

§ In reality, often there are overlaps. Some design

may be needed to articulate requirement.
– system has to fit within existing environment (e.g.
’data has to be read from ORACLE DB’)
– large systems decompose into subsystems which
have their own requirements
– Re-use of existing software (will use Company’s
existing e-Commerce Suite to implement X,Y,Z)
– Re-use of approved ’patterns’ or solutions project
© Copyright 2006 FPT Software 8
 Requirement Process
Development Steps

© Copyright 2006 FPT Software 9

 Requirement Documents

§ Q&A file
§ Change request form
§ Requirement management sheet
§ SRS review check list
§ Use case review checklist

© Copyright 2006 FPT Software 10

 Requirement Documents – URD, SRS
§ URD = User Requirement Document
– Address what users need to do their jobs
– Composed all business requirements formulated by customer,
business rules and other constrains to software
§ SRS = Software Requirement Specification.
– A set of software requirements as complete, consistent, and
correct as possible, from the developer's point of view
– Document which after baselining, common reference point of the
software requirements for customer, developer, tester and PM .
§ From URD to SRS: the focus of the project moves from the
broad statement of user needs, goals and objectives,
target markets and features of the system to the details of
how these features are going to be implemented in the
solution.
© Copyright 2006 FPT Software 11
 Requirement Documents – URD, SRS
Benefits of good SRS

§ Basis for agreement between the customers and

the team on what the software product is to do.
§ Reduce the development effort.
§ Provide a basis for estimating costs, schedules.
§ Provide a baseline for validation and verification.
§ Facilitate transfer.
§ Serve as a basis for enhancement

© Copyright 2006 FPT Software 12

 Requirement Documents
Characteristics of good SRS

§ Correct: requirement ~ what the software shall meet.

§ Unambiguous:
– Has only one interpretation (to both creator & user)
– Use natural language & avoid the words like: maybe, generally, etc.
§ Complete
– Include all significant requirements.
– Define all the software responses & include all the refs/labels.
– Use of TBD: should avoid OR mention why, what to do, who, when.
§ Consistent: no conflict between individual requirements.
§ Verifiable: reviewable & testable in finite cost-effective
process.
§ Traceable: clear origin & good reference for future dev/
enhance documents.

© Copyright 2006 FPT Software 13

 Requirement Documents - RMS
§ Requirement Management Sheet, Excel sheet, used to
track the status, relationship and change of requirements
during the whole project.
§ A mandatory document (dynamic version of SRS)
– To maintain the common reference for all related parties
– To track the project progress
– To track the change
– To collect requirement related metrics for reporting
§ The sheet is created the first time client requirement come
§ Baseline together with SRS

© Copyright 2006 FPT Software 14

 Requirement Documents
Requirement Traceability Matrix
Why is traceability necessary?
– The requirements can change at any stage during the product’s life.
– If the requirements are traceable, then when changes happen, it is far
easier to find the impacted parts of the product
Software Work
User Needs
Requirements Products

Use cases/
Software
User Requirements
Requirements

Test cases

© Copyright 2006 FPT Software 15

 How to Analyze Requirements

© Copyright 2006 FPT Software 16

 Analyzing Requirements
Methodologies

§ 5W1H (What, Where, When, Why, Who, How)

– What happened? (What is the story?)
– Where did it take place?
– When did it take place?
– Why did it happen?
– Who is it about? (Who is impacted?)
– How did it happen?
§ CRUD (Create, Read, Update, Delete)
– Create/Read/Update/Delete an object
§ I/O and Flow
– What is Input information?
– What is Output information?
– Flow to process from Input to Output?

© Copyright 2006 FPT Software 17

 Analyzing Requirements
5W1H

© Copyright 2006 FPT Software 18

 Analyzing Requirements
CRUD

© Copyright 2006 FPT Software 19

 Analyzing Requirements
Input-Output-Flow

© Copyright 2006 FPT Software 20

 Analyzing Requirements
Clarifying requirement via Q&A

§ Why do we need Q&A?

– Problems of understanding
– Want for knowledge, must be asked

© Copyright 2006 FPT Software 21

 Analyzing Requirements
Clarifying requirement via Q&A (cont.)

§ How to make Q&A effectively?

– Identify the issue: unclear, get for more information, etc.
– Check in all documents that customer supplied to make sure
your question has not solved;
– With technical question, check your team/group/company or
ask “Google” to solve it before asking out
– Give the cross-reference clearly, completely
– Attach sample screen, demo, give your suggestions if any
– Convert questions to Y/N or multiple-choice types if possible
– In Q&A, give deadline that you want to receive the answer.
It there is no answer until the deadline, what is impact?

© Copyright 2006 FPT Software 22

 Thank You

© Copyright 2006 FPT Software 23