SOFTWARE REQUIREMENTS
ANALYSIS (SWRA)
Instructor: Dr. Hany H. Ammar
Dept. of Computer Science and
Electrical Engineering, WVU
OUTLINE
Introduction to Requirements Engineering
 Introduction to Requirements Analysis and
Specifications (SRS) document
 Introduction to Object-Oriented Analysis
techniques using UML

What is Requirements Engineering ?

Requirements Engineering
What is Requirements Engineering?


Requirements Management:
Requirements management activities include
evaluating the impact of proposed changes, tracing
individual requirements to downstream work
products, and tracking requirements status during
development
Several Requirements management tools are
available in industry
What is Requirements Engineering?
Major Requirements Management Tools:
1. Caliber-RM by Technology Builders, Inc.;
www.tbi.com
2. RequisitePro by Rational Software
Corporation; www.rational.com
3. RTM Workshop by Integrated Chipware,
Inc.; www.chipware.com

What is Requirements Engineering?

Requirements Elicitation
–
is the process of gathering the different types of requirements
from suitable stakeholders.
 Business requirements describe why the product is being
built and identify the benefits for both the customers and the
business.
 User requirements, describe the tasks or business processes a
user will be able to perform with the product. (Developing
use-cases)
 Functional requirements describe the specific system
behaviors that must be implemented (Developing usage
scenarios)
 Non-functional requirements, describe the non-functional
features such as quality attributes of Reliability, Performance,
availability, and maintainability.
What is Requirements Engineering?

Requirements analysis:
Requirements analysis includes decomposing high-level
requirements into detailed functional requirements,
constructing graphical requirements models or logical
models (structured Analysis models, or Object-Oriented
Analysis models) (for developers), and building prototypes.

Analysis models and prototypes provide alternative views of
the requirements, which often reveal errors and conflicts that
are hard to spot in a textual SRS.
What is Requirements Engineering?
Requirements Specification
 Specification key practice is to write down the
requirements in some accepted, structured format
as you gather and analyze them.
 The objective of requirements development is to
communicate a shared understanding of the new
product among all project stakeholders.
 Historically, this understanding is captured in the
form of a textual SRS document written in natural
language, augmented by appropriate analysis
models. (to be discussed in detail)
What is Requirements Engineering?


Requirements Verification
Verification involves evaluating the correctness and
completeness of the requirements, to ensure that a system
built to those requirements will satisfy the users’ needs and
expectations. The goal of verification is to ensure that the
requirements provide an adequate basis to proceed with
design
Prototyping (or executable specifications) is a major
technique used in verification. Examples include GUI
development for user requirements verification, and
Formal requirements specification environments
OUTLINE
Introduction to Requirements Engineering
 Introduction to Requirements Analysis and
Specifications (SRS) document
 Introduction to Object-Oriented Analysis
techniques using UML

Introduction to Requirements Analysis and
Specification: The SRS Document



The specification of SWRA phase in the DOD
standard MIL-STD-498 also focuses on analyzing
the requirements and developing a logical model
for each computer software configuration item
(CSCI)
The output of this phase is the the Software
Requirements Specification (SRS) document (See
Table 1, section 3.1.3 of the notes)
The SRS starts in the first section by identifying
the scope of the CSCI, presenting a system
overview, and a document overview
Introduction to Requirements
Analysis, The SRS Doc



The second section lists the number, title, revision,
date, and source of all documents referenced in
this specification.
The third section, the largest and most important
section contains the detailed specifications of the
CSCI as follows
The states and modes of operation of the CSCI are
clearly specified (e.g., idle, ready, active, post-use
analysis, training, degraded, emergency, backup,
wartime, peacetime)
Introduction to Requirements
Analysis, The SRS Doc



Each requirement or group of requirements in this
specification must be correlated to the states and
modes in which they belong.
The SRS specifies the capability or functionality
requirements in terms of control processing and
data processing capabilities of the CSCI (e.g., data
flow/control flow diagrams are used in SART)
Requirements pertaining to the CSCI's external
interfaces may be presented in the SRS or in one
or more Interface Requirements Specifications
(IRSs) documents referenced from the SRS
Introduction to Requirements
Analysis, The SRS Doc



Internal interfaces and data requirements between
capabilities of the CSCI must be specified
Non-functional requirements such as safety,
Security and privacy requirements, and quality
factors such as reliability and availability
requirements must also be specified along with the
environmental requirements
Computer resource requirements in terms of HW,
SW, and Communication resources must be
specified
Introduction to Requirements
Analysis, The SRS Doc




Design and implementation constraints (e.g., required
databases,particular design or implementation standards or
languages, Flexibility to changes in technology, and
expendability)
Precedence and criticality of requirements listed in the
previous subsections
Section 4 specifies the qualification methods used to ensure
that the requirement in section 3 has been met.
In Section 5, Traceability is established from each CSCI
requirement in this specification to specific components and
sections in the SSS and SSDD docs
Example of an SRS Document
THE INSTRUMENT A
DATA PROCESSING UNIT
FOR THE
COMPANY X GAMMA RAY DETECTOR
EXPLORER
Prepared for NASA Contract
OUTLINE
Introduction to Requirements Engineering
 Introduction to Requirements Analysis and
Specifications (SRS) document
 Introduction to Object-Oriented Analysis
techniques using UML

Structured Analysis Vs ObjectOriented Analysis
The Structured Analysis model
 The SA model is divided into two main types of
elements; data processing functions and control
functions
 Data processing functions process input data,
produce output data and controls, and send control
information to the controllers
 Control functions process input controls, activate
or deactivate data processing functions thr’ control
signals, and also produce output controls
The Structured Analysis Methodology
Uses Data Flow/Control Flow diagrams and state
diagrams to model the functional requirements
The DFD/CFD model of
The Automatic Teller Machine (ATM) Example
The Structured Analysis Model
The Object-Oriented Analysis
(OOA) Methodology




Based on describing the logical model of the
system and the environment as a set of interacting
objects
Defines the external objects (actors) interacting
with the system as well as the internal objects that
the system must contain
Defines the static architecture of objects and the
behavioral interactions between them
Defines the internal behavior of objects
The Unified Modeling Language
UML
What is the UML?



UML stands for Unified Modeling Language
The UML is the standard language for visualizing,
specifying, constructing, and documenting the
artifacts of a software-intensive system
It can be used with all processes, throughout the
development life cycle, and across different
implementation technologies.
UML Concepts

The UML may be used to:
1.
2.
3.
4.
5.
6.
Display the boundary of a system & its major functions
using use cases and actors
Illustrate use case realizations with interaction diagrams
Represent a static structure of a system using class
diagrams
Model the behavior of objects with state transition
diagrams
Reveal the physical implementation architecture with
component & deployment diagrams
Extend your functionality with stereotypes
Putting the UML to Work
A Simple Example
Example requirements
 The ESU University wants to computerize their registration system
– -The Registrar sets up the curriculum for a semester
–
-One course may have multiple course offerings
–
-Students select 4 primary courses and 2 alternate courses
-Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
-Students may use the system to add/drop courses for a period
of time after registration
-Professors use the system to receive their course offering
rosters
-Users of the registration system are assigned passwords which
are used at logon validation
–
–
–
–
UML Use Case Diagrams:
Defining Actors (External objects)

An actor is someone or some thing that
must interact with the system under
development
Registrar
Professor
Student
Billing System
UML Use Case Diagrams:
Defining Use Cases
A use case captures the user requirements, it is a pattern of
behavior the system exhibits
– Each use case is a sequence of related transactions
performed by an actor and the system in a dialogue
 Actors are examined to determine their needs
– Registrar -- maintain the curriculum
– Professor -- request roster
– Student -- maintain schedule
– Billing System -- receive billing information from
registration
Maintain Curriculum
Request Course Roster
Maintain Schedule

Documenting Use Cases



A flow of events document is created for each use cases
– Written from an actor point of view
Details what the system must provide to the actor when the
use cases is executed
Typical contents
– How the use case starts and ends
– Normal flow of events
– Alternate flow of events
– Exceptional flow of events
Example: Maintain Curriculum
Use case Flow of Events





This use case begins when the Registrar logs onto the
Registration System and enters his/her password. The
system verifies that the password is valid (E-1) and
prompts the Registrar to select the current semester or a
future semester (E-2). The Registrar enters the desired
semester. The system prompts the Registrar to select the
desired activity: ADD, DELETE, REVIEW, or QUIT.
If the activity selected is ADD, the S-1: Add a Course
subflow is performed.
If the activity selected is DELETE, the S-2: Delete a
Course subflow is performed.
If the activity selected is REVIEW, the S-3: Review
Curriculum subflow is performed.
If the activity selected is QUIT, the use case ends.
UML: Use Case Diagram

Use case diagrams are created to visualize the
relationships between actors and use cases
Request Course Roster
Professor
Student
Maintain Schedule
Billing System
Maintain Curriculum
Registrar
Use Case Diagram: Includes and
Extends Use Case Relationships

As the use cases are documented, other use case relationships
may be discovered
– The includes relationship shows behavior that is common to
one or more use cases
– An extends relationship shows optional behavior
<<includes>>
Register for courses
<<includes>>
Maintain curriculum
Logon validation
Use Case Realizations
(Object Interaction diagrams)
The use case diagram presents an outside
view of the system
 Interaction diagrams capture the functional
requirements and describe how use cases
are realized as interactions among societies
of objects (objects interact to accomplish a
function of the system)
 Two types of interaction diagrams

–
–
Sequence diagrams
Collaboration diagrams
UML: Sequence Diagram

A sequence diagram displays object interactions
arranged in a time sequence
registration
form
: Student
registration
manager
math 101
math 101
section 1
1: fill in info
2: submit
3: add course(joe, math 01)
4: are you open?
5: are you open?
6: add (joe)
7: add (joe)
Time
UML Class Diagrams


A class diagram shows the existence of classes
and their relationships in the logical view of a
system
UML modeling elements in class diagrams
1. Classes and their structure and behavior
2. Association, aggregation, and inheritance
relationships
3. Multiplicity and navigation indicators
4. Role names
Class Diagrams:
Defining Classes
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Course
StudentInfo
ProfessorInfo
CourseOffering
Class Diagrams:
Defining Class Operations


The behavior of a class is represented by its operations
Operations may be found by examining interaction
diagrams
registration
form
registration
manager
RegistrationManager
3: add course(joe, math 01)
addCourse(Student,Course)
Class Diagrams:
Defining Class Attributes


The structure of a class is represented by its attributes
Attributes may be found by examining class definitions,
the problem requirements, and by applying domain
knowledge
From the requirements statements
Each course offering
has a number, location
and time
CourseOffering
number
location
time
Class Diagrams:
Class Relationships



Relationships provide a pathway for communication
between objects
Object interaction diagrams are examined to determine
what links (dependencies) between objects need to exist to
accomplish the behavior -- if two objects need to “talk”
there must be a link or a dependency between them
Three types of relationships are:
– Association
– Aggregation
– Inheritance
Class Diagrams:
Finding Class Relationships

Relationships are discovered by examining
interaction diagrams
–
If two objects must “talk” there must be a
pathway for communication
RegistrationManager
Registration
Manager
Math 101:
Course
3: add student(joe)
Course
Class Diagrams:
with Relationships
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
StudentInfo
open()
addStudent(StudentInfo)
name
major
ProfessorInfo
name
tenureStatus
CourseOffering
location
open()
addStudent(StudentInfo)
UML:
The State of an Object

A state transition diagram shows
–
–
–

The life history of a given class
The events that cause a transition from one state
to another
The actions that result from a state change
State transition diagrams are created for
objects with significant dynamic behavior
State Transition Diagram
Add student[ count < 10 ]
Initialization
Add Student /
Set count = 0
do: Initialize course
Open
entry: Register student,
And Increment count
Cancel
Cancel
[ count = 10 ]
Canceled
do: Notify registered students
Cancel
Closed
do: Finalize course