Software Requirement

Requirement Analysis

4/9/2014 2
 Requirements Analysis
• Software engineering task bridging the gap between
system requirements engineering and software design.
• Provides software designer with a model of:
– System information
– Function
– Behavior
• Model can be translated to data, architectural, and
component-level designs.
• Expect to do a little bit of design during analysis and a little bit of
analysis during design.

3
 Analysis Objectives
• Identify customer’s needs.
• Evaluate system for feasibility.
• Perform economic and technical analysis.
• Allocate functions to system elements.
• Establish schedule and constraints.
• Create system definitions.

4
 Analysis Principles
• Information domain of problem must be presented &
understood.
• Models depicting system information, functions, and
behavior should be developed.
• Models and problems must be partitioned in a
manner that uncovers detail in layers.
• Analysis proceeds from essential information
toward implementation detail
• Must be traceable.

5
 Information Domain
• Encompasses all data objects that contain numbers, text,
images, audio, or video.
• Information content or data model
– shows the relationships among the data and control objects
that make up the system
• Information flow
– represents manner in which data and control objects change
as each moves through system
• Information structure
– representations of the internal organizations of various data
and control items

6
 Modeling
• Data model
– shows relationships among system objects
• Functional model
– description of the functions that enable the
transformations of system objects
• Behavioral model
– manner in which software responds to events from the outside
world

7
 Partitioning
• Process that results in the elaboration of data,
function, or behavior.
• Horizontal partitioning
– breadth-first decomposition of the system function,
behavior, or information, one level at a time.
• Vertical partitioning
– depth-first elaboration of the system function, behavior, or
information, one subsystem at a time.

8
 Requirements Analysis [1]
• What is it?
– The process by which customer needs are understood and
documented.
– Expresses “what” is to be built and NOT “how” it is to be built.

• Example 1:
– The system shall allow users to withdraw cash. [What?]
• Example 2:
– A sale item’s name and other attributes will be stored in a hash
table and updated each time any attribute changes. [How?]
 Requirements Analysis [2]
• C- and D-Requirements
– C-: Customer wants and needs; expressed in language understood by the
customer.
– D-: For the developers; may be more formal.

• Why document requirements?

– Serves as a contract between the customer and the developer.
– Serves as a source of test plans.
– Serves to specify project goals and plan development cycles and increments.
 Requirements Analysis [3]
• Roadmap:
1. Identify the customer.
2. Interview customer representatives.
3. Write C-requirements, review with customer, and update when
necessary.
4. Write D-requirements; check to make sure that there is no
inconsistency between the C- and the D-requirements.
 Requirements Analysis [4]
• C-requirements:
– Use cases expressed individually and with a use case diagram. A use case
specifies a collection of scenarios.
• Scenarios that describe how the product will be used in specific
situations.
• Written narratives that describe the role of an actor (user or device) as
it interacts with the system.
– Data flow diagram:
• Explains the flow of data items across various functions. Useful for
explaining system functions.
– State transition diagram:
• Explains the change of system state in response to one or more
operations.
– User interface: Generally not a part of requirements analysis though may be
included.
 Data Flow Diagram
Employee Record
Overtime
Get employee rate
file
Pay rate Company records
*
ID * Weekl Pay
y Overtime
pay
pay

Regular *
hours Overtime
Worker hours Total pay
Deduct
taxes

Tax rates Net pay

Check Issue
paycheck
 State Transition Diagram (STD)
Elevator example (partial):
EBP(e,f)
EBOFF (e,f) EBON (e,f)
EBP(e,f)

EBOFF (e,f): Elevator e button OFF at floor f.

EBON (e,f): Elevator e button ON at floor f.

EBP(e,f): Elevator e button f is pressed.

 Requirements Analysis [5]
• D-requirements:
1. Organize the D-requirements.
2. Create sequence diagrams for use cases:
• Obtain D-requirements from C-requirements and customer.
• Outline test plans
• Inspect
3. Validate with customer
4. Release:
 Requirements Analysis [6]
Organize the D-requirements:
– Functional requirements: Ex) The blood pressure monitor will measure the
blood pressure and display it on the in-built screen.
– Non-functional requirements
• Performance: Ex) The blood pressure monitor will complete a reading within 10
seconds.
• Reliability: Ex)The blood pressure monitor must have a failure probability of less
than 0.01 during the first 500 readings.
• …
– Interface requirements: interaction with the users and other applications,
Ex) The blood pressure monitor will have a display screen and push
buttons. The display screen will….
– Constraints: timing, accuracy, Ex) The blood pressure monitor will take
readings with an error less than 2%.
 Requirements Analysis [7]
Properties of D-requirements
• Traceability:
– Functional requirements: D-requirement  inspection report  design
segment  code segment  code inspection report  test plan  test
report
– Non-Functional requirements: Isolate each non-functional requirement 
Document each class/function with the related non-functional
requirement.
• Testability - It must be possible to test each requirement.
• Completeness - Self contained, no omissions.
• Error conditions - State what happens in case of an error. How
should the implementation react in case of an error condition?
 Prioritizing (Ranking) Use Cases
• Strategy :
– pick the use cases that significantly influence the core architecture
– pick the use cases that are critical to the success of the business.
– a useful rule of thumb - pick the use cases that are the highest risk.
 Consistency of Requirements
• Different requirements must be consistent.
Ex) R1.2: The speed of the vehicle will never exceed 250 mph.
R5.4: When the vehicle is cruising at a speed greater than 300
mph, a special “watchdog” safety mechanism will be
automatically activated
 What is Analysis and Design?
• Analysis - investigation of the problem (what);
- What does the system do?
• Investigation of the problem.

• Design - conceptual solution to fulfill the requirements

(how);
– How will the system do what it is intended to do.
• What (conceptual) solution will full the requirements
 What is OO analysis and design?
• Essence of OO analysis - consider a problem domain from
the perspective of objects (real world things, concepts)
Ex) in the case of library information systems, one would find
concepts like book, library, patron

• Essence of OO design - define the solution as a collection of

software objects (allocating responsibilities to objects)
Ex) emphasis on defining the software objects; ultimately these objects
are implemented in some programming language; Book may have a
method named print.
 Example - contd.
Representation in
Domain concept analysis of concepts

Book

title
print()

Representation in OO public class Book

programming {
language public void print();
private string title;
}
 Objects
 Objects: Anything that has a state and exhibits behavior.
 Real world objects: Bicycle, student, course, dog, university,….
 Software objects: Model real-world or abstract objects (e.g. a list).
 Methods: Procedures through which objects communicate amongst
themselves. Example: Bicycle: brake, park. Dog: bark, eat. Student: register,
study.

 Attributes: Variables that hold state information. Bicycle: speed,

color, owner. Dog:name, breed. Student: name, ID.
 Class
• Class: Prototype for all objects of a certain kind. Student, animal,
university, shape, etc.

• Objects: Created from a class. For example: s1, s2 are objects from class Student.
Ex) BITS and Purdue are objects from class University. myCircle and mySquare are
objects from class Shape.

• Inheritance: A class inherits attributes and methods from its super class. This
allows hierarchical organization of classes.

• Interface: A contract between a class and its users. A class implements an

interface (methods and attributes).
 What are business processes?
• First step - consider what the business must do; in the case of a
library - lending books, keeping track of due dates, buying new
books.

• In OO terms - requirements analysis; represent the business

processes in textual narration (Use Cases).
 Roles in the organization
• Identify the roles of people who will be involved in the
business processes.

• In OO terms - this is known as domain analysis

Ex) Examples - customer, library assistant, programmer, navigator,
sensor, etc.
 Who does what - Collaboration
• Business processes and people identified; time to determine how to
fulfill the processes and who executes these processes.

• In OO terms - object oriented design; assigning

responsibilities to the various software objects.
– Often expressed in class diagrams.
 In Summary...
Business OO Analysis and Associated
Analogy Design Documents
What are the business
Requirements analysis Use cases
processes?
What are employee
Domain analysis Conceptual model
roles?
Who is responsible for Responsibility Design class
what? assignment diagrams
 Analysis and Design models

• Analysis model - related to an investigation of the domain

and problem space
– Use case model qualifies as an example

• Design model - related to the solution

– Class diagrams qualifies as an example

86
 Requirement types
NO Requirement type Requirement id

1 System introduction and function list BR

2 Functional requirements FR
3 Performance requirements PR
4 Quality requirements QR
4.1 Reliability QRR
4.2 Usability QUR
4.3 Maintainability QMR
4.4 Portability QPR
4.5 Secutity QSR
5 Interface requirements IR
6 Data requirements DR
7 Operation requirements OR
8 Constraints CO

87
 1.1 System introduction
【overview】
Overal objectives and brief current system operational environment.
【contents】
▣ Requirement type: System introduction and function list
▣ Requirement number : BR-xx
▣ Requirement name : system introduction
▣ Requirement contents
(1) Describe the context and objectives of the system to be developed.
• context and objectives
• business expectations of stakeholders
(2) Define system operation concept of the systems to be developed.
• concept of system operations
• systems operation environment

88
 1.2 System development scope
【overview】
Define business scope and boundary supported by the system to be developed and describe the
things to be excluded outside of the system
【contents】
▣ Requirement type: System introduction and function lis
▣ Requirement number : BR-xx
▣ Requirement name : system scope
▣ Requirement contents
(1) Describe business contents briefly inside the scope to be treated including the
interfaces with outside systems
• Interfaces among systems
• Describe business contents to be developed
(2) Business excluded outside of the system

89
 1.3 Function list
【overview】
Understanding the stakeholder’s overal system structure and functions develop function list with 4
hierarchical structure to achieve the business objectives.
【contents】
▣ Requirement type: System introduction and function lis
▣ Requirement number : BR-xx
▣ Requirement name : Function list
▣ Requirement contents
(1) Main function - the highest hierarchical order functions which should de decomposed into major
functions
(2) Major function – the second highest hierarchical order functions which should achieve main
functions and be decomposed into functions
(3) Function – the third highest hierarchical order functions which should achieve major functions
and be decomposed into unit functions.
(4) Unit function – the lowest function of the function hierarchy which has input/ouput data as a real
business function
 1.4 System constraints
【overview】
Describe considerations which could give effects on the development or business organization
【contents】
▣ Requirement type: System introduction and function lis
▣ Requirement number : BR-xx
▣ Requirement name : System constraints
▣ Requirement contents
(1) Business considerations – estimated development cost, time, labor etc.
(2) Organization consideration – client’s capability of operations and
responsibilities, authorities etc.
(3) Other considerations
 2. Functional Requirements
Requirement number FR-2

Requirement name function name (the 3rd order)

Requirement contents
1. Unit function name 1
- description of unit function

Input data
Data information Output data
In/out type
File type ILF/EIF
Application name
Function performance Quality Interface Data Operation constraints
Related requirements
id
 3. Performance Requirements
Requirement
PR-1
number

Requirement
Average response time (ex)
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 4. Quality Requirements
Requirement QRR-1(Reliability), QUR-1(usability), QMR-1(maintainability), QPR-1(p
ortability), QSR-1(security)
number

Requirement
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 5. Interface Requirements
Requirement
IR-1
number

Requirement
System interface requirement name 1
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 6. Data Requirements
Requirement
DR-1
number

Requirement
Data base system requirement name 1
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 7. Operation Requirements
Requirement
OR-1
number

Requirement
Operational hardware requirement name 1
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 8. Constraints
Requirement
CO-1
number

Requirement
Development constraints 1
name

Requirement
contents
1.

Function performance Quality Interface Data Operation constraints

Related requirements

id
 Function list
Requirement
BR-4
number
Requirement Function List
Name
Requirement Main Major
contents Function Unit function
function function
- Event registration
1.1.1 Event - Event change
- Event cancel
1. Business 1.1 General management
- Event inquiry
Operation - Event participation
managemen management request
t
1.1.2 Committee
management

2014-04-09 99
 Functional Requirements
Requirement
FR-1.1.1
number
Requirement Event management
Name
Requirement 1. Event registration
contents
• Input basic event information
• Input event related information such as related organizations & associations, programs,
and other materials
2. Event change
• Change basic information of the selected event
• Change event related information such as related organizations & associations, programs,
and other materials of the selected event
3. Event cancel
• Delete all the basic and related information of the selected event
4. Event inquiry
• Retrieve event list information using event name, event place, event date • Inquire all
the basic and related information of the selected event
5. Event participation request
• Retrieve event list information using event name, event place, event date • Input
event participation information of the selected event

Event basic information: event name, event place, event start date, number of event participants,
Data event summery, budget, sponsor fee, cooperation fee, participation fee,
information event introduction materials, name list, pictures etc.

Related Performanc Quality Interface Data Operation

Related Constraint
Function e 100
2 014re-0q4u-
0ir9ements
 Use Case – Event management
Event management
Notation – UML
Event simplified
registration

Event
change

Event cancel
Admin.
Event
inquiry
Event
participation
request
Event participant

101
 Use Case Scenario – Event registration
Use Case No. 1
Use Case Event registration
name
Use Case Input basic and additional information and announce the event would be open
Description
Use Case 1. Enter Event basic information(event name, event place, event start date, number of event
participants, event summery, budget, sponsor fee, cooperation fee, participation fee, event
Flow introduction materials, name list, pictures etc.). Sponsor fee, cooperation fee is accumulated
automatically according to the input of additional event related information.
2. Enter Event related information(organization or association name, role, sponsor or
cooperation fee, note) as a additional information. Here the fees of sponsor or cooperate shall
be accumulated to be entered as a item of sponsor fee or cooperate fee in the basic
information.
3. Enter event program information( title, contents, presenter, present materials)
4. Register event related materials with its name.

102
The End
103