AMITY

We nurture talent
System Analysis and Design
ADL-74
Session -2

Prof. OP Sangwan
Sangwan_op@aiit.amity.edu
System Analysis
Module : 4
 Analysis

• The analysis phase answers the questions of

who will use the system, what the system will do,
and where and when it will be used.

• During this phase the project team investigates

any current system (s), identifies improvement
opportunities, and develops a concept for the
new system.
 Steps in Analysis

1. Analysis strategy: This is developed to guide the

projects team’s efforts. This includes an analysis of the
current system.
2. Requirements gathering: The analysis of this
information leads to the development of a concept for a
new system. This concept is used to build a set of
analysis models.
3. System proposal: The proposal is presented to the
project sponsor and other key individuals who decide
whether the project should continue to move forward.
• The system proposal is the initial deliverable that
describes what business requirements the new system
should meet.

• The deliverable from this phase is both an analysis and

a high-level initial design for the new system.
System Requirement Specification
 Requirements Engineering
• The process of establishing the services that the
customer requires from a system and the constraints
under which it operates and is developed
• Requirements may be functional or non-functional
– Functional requirements describe system services or
functions
– Non-functional requirements is a constraint on the system or
on the development process
 What is a requirement?
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
• This is inevitable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore must be
open to interpretation.
– May be the basis for the contract itself - therefore must be
defined in detail.
– Both these statements may be called requirements.
Requirements definition/specification
• Requirements definition
– A statement in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
• Requirements specification
– A structured document setting out detailed descriptions of the
system services. Written as a contract between client and
contractor
• Software specification
– A detailed software description which can serve as a basis for a
design or implementation. Written for developers.
 Wicked problems
• Most large software systems address wicked problems
• Problems which are so complex that they can never be
fully understood and where understanding develops
during the system development
• Therefore, requirements are normally both incomplete
and inconsistent
 Requirements document structure
• Non-functional requirements definition
– Define constraints on the system and the development process
• System evolution
– Define fundamental assumptions on which the system is based and
anticipated changes
• Requirements specification
– Detailed specification of functional requirements
• Appendices
– System hardware platform description
– Database requirements (as an ER model perhaps)
• Index
 Writing requirements definitions
• Natural language, supplemented by diagrams and
tables is the normal way of writing requirements
definitions
• This is universally understandable but three types of
problem can arise
– Lack of clarity. Precision is difficult without making the
document difficult to read
– Requirements confusion. Functional and non-functional
requirements tend to be mixed-up
– Requirements amalgamation. Several different requirements
may be expressed together
 Requirements specification
• The specifications adds detail to the requirements
definition. It should be consistent with it.
• Usually presented with system models which are
developed during the requirements analysis. These
models may define part of the system to be developed
• Often written in natural language but this can be
problematical
TYPES OF REQUIREMENTS
 Types of Requirements

Known Unknown Undreamed

Requirements Requirements Requirements

Stakeholder: Anyone who should have some direct or indirect

influence on the system requirements.
--- User
--- Affected persons

Requirements

Functional Non-Functional
Functional requirements describe what the software has to
do. They are often called product features.
Non Functional requirements are mostly quality
requirements. That stipulate how well the software does,
what it has to do.
Availability
Reliability
For Users
Usability
Flexibility

Maintainability
Portability For Developers
Testability
User and system requirements
• User requirement are written for the users and include
functional and non functional requirement.
• System requirement are derived from user requirement.
• The user system requirements are the parts of software
requirement and specification (SRS) document.
Interface Specification
• Important for the customers.

TYPES OF INTERFACES

• Procedural interfaces (also called Application

Programming Interfaces (APIs)).
• Data structures
• Representation of data.
This is the way of representing requirements in a
consistent format

SRS serves many purpose depending upon who is writing

it.

-- written by customer
-- written by developer

Serves as contract between customer & developer.

Requirements Documentation
Nature of SRS

Basic Issues

• Functionality
• External Interfaces
• Performance
• Attributes
• Design constraints imposed on an Implementation
SRS Should
-- Correctly define all requirements
-- not describe any design details
-- not impose any additional constraints
Characteristics of a good SRS
An SRS Should be
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for important and/or stability

 Verifiable

 Modifiable

 Traceable
Correct
An SRS is correct if and only if every requirement
stated therein is one that the software shall meet.

Unambiguous
An SRS is unambiguous if and only if, every
requirement stated therein has only one interpretation.

Complete
An SRS is complete if and only if, it includes the
following elements

(i) All significant requirements, whether related to

functionality, performance, design constraints, attributes or
external interfaces.
(ii) Responses to both valid & invalid inputs.

(iii) Full Label and references to all figures, tables and diagrams
in the SRS and definition of all terms and units of measure.

Consistent

An SRS is consistent if and only if, no subset of individual

requirements described in it conflict.

Ranked for importance and/or Stability

If an identifier is attached to every requirement to

indicate either the importance or stability of that particular
requirement.
Verifiable
An SRS is verifiable, if and only if, every requirement
stated therein is verifiable.

Modifiable
An SRS is modifiable, if and only if, its structure and style
are such that any changes to the requirements can be made
easily, completely, and consistently while retaining structure and
style.

Traceable
An SRS is traceable, if the origin of each of the
requirements is clear and if it facilitates the referencing of each
requirement in future development or enhancement
documentation.
Organization of the SRS

IEEE has published guidelines and standards to organize an

SRS.
First two sections are same. The specific tailoring occurs in
section-3.

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
1.5 Overview
2. The Overall Description

2.1 Product Perspective

2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements

3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
Check the document for:

 Completeness & consistency

 Conformance to standards
 Requirements conflicts
 Technical errors
 Ambiguous requirements
REQUIREMENT VALIDATION
 SRS document
List of problems

Validation
Organizational process
standards

Organizational Approved actions

knowledge
 Distribute Read
Plan review SRS documents
documents

Requirements Review Process Organize

review

Revise Follow up
document actions
Problem actions
• Requirements clarification
• Missing information
• find this information from stakeholders
• Requirements conflicts
• Stakeholders must negotiate to resolve this conflict
• Unrealistic requirements
• Stakeholders must be consulted
• Security issues
• Review the system in accordance to security standards
 Review Checklists
 Redundancy
 Completeness
 Ambiguity
 Consistency
 Organization
 Conformance
 Traceability
 Prototyping
Validation prototype should be reasonably complete &
efficient & should be used as the required system.
Feasibility Study
Is cancellation of a project a bad news?
As per IBM report, “31% projects get cancelled before they
are completed, 53% over-run their cost estimates by an
average of 189% & for every 100 projects, there are 94
restarts.

How do we cancel a project with the least work?

CONDUCT A FEASIBILTY STUDY

Feasibility depends upon non technical Issues like:

• Are the project’s cost and schedule assumption realistic?

• Does the business model realistic?

• Is there any market for the product?

Purpose of feasibility study

“evaluation or analysis of the potential impact of a

proposed project or program.”

Focus of feasibility studies

• Is the product concept viable?
• Will it be possible to develop a product that matches the
project’s vision statement?
• What are the current estimated cost and schedule for the
project?
Focus of feasibility studies

• How big is the gap between the original cost & schedule
targets & current estimates?
• Is the business model for software justified when the
current cost & schedule estimate are considered?
• Have the major risks to the project been identified & can
they be surmounted?
• Is the specifications complete & stable enough to
support remaining development work?
Focus of feasibility studies

• Have users & developers been able to agree on a

detailed user interface prototype? If not, are the
requirements really stable?
• Is the software development plan complete & adequate
to support further development work?
 Types of Feasibility Study
• A feasibility study assesses the operational, technical,
and economic merits of the proposed project
• There are three types of feasibility:
– Technical feasibility
– Economic feasibility
– Operational feasibility
 Technical Feasibility
• Technical feasibility assesses whether the current
technical resources are sufficient for the new system
• If they are not available, can they be upgraded to
provide the level of technology necessary for the new
system
 Economic Feasibility
• Economic feasibility determines whether the time
and money are available to develop the system
• Includes the purchase of
– New equipment
– Hardware
– Software
 Operational Feasibility
• Operational feasibility determines if the human
resources are available to operate the system once it
has been installed
• Users that do not want a new system may prevent it
from becoming operationally feasible
 Steps in Feasibility Analysis
• Form a project team and appoint a project leader.
• Prepare system flowcharts
• Enumerate potential candidate systems.
• Describe and identify characteristics of candidate systems.
• Determine and evaluate performance and cost effectiveness of
each candidate system.
• Weight system performance and cost data.
• Select the best candidate system.
 Feasibility Report
I. TITLE PAGE
II. TABLE OF CONTENTS
III. SCOPE
IV. STATEMENT OF PROBLEM
V. SUMMARY/ABSTRACT (optional)
VI. COST/BENEFITS
VII. IMPLEMENTTAION SCHEDULE
VIII. HARDWARE CONFIGURATION (optional)
IX. CREDITS
X. APPENDIX
 Q/A Sessions
Q1. Which of the following is a main component on a decision tree?
a) entity
b) process
c) Action
d) condition

Q2. A decision tree:

a) models the state of an object and the events that cause the object to change from
one state to another
b) depicts the interactions among objects during a certain period of time
c) is a matrix representation of the logic of a decision, which specifies the possible
conditions for the decision and the resulting actions
d) is a graphical representation of a decision situation in which decision situation
points are connected together by arcs and terminate in ovals
Q3. On an entity-relationship diagram, a relationship is
represented by a(n):
a) rectangle
b) Ellipse
c) Arrow
d) diamond

Q4. An attribute whose value is unique across all occurrences of

a relation best describes a:
a) primary key
b) data marker
c) recursive key
d) join attribute
Q5. Which of the following is not a key information system component?
a) design stability
b) Data
c) data flows
d) processing logic

Q6. Which is not a type of requirements under quality function deployment

(a)Normal requirements
(b)Abnormal requirements
(c)Expected requirements
(d)Exciting requirements
Q7. Which one is not a type of requirements?

(a) Known requirements

(b) Unknown requirements
(c) Undreamt requirements
(d) Complex requirements

Q8. Which one is not a requirements elicitation technique?

(a) Interviews
(b) The use case approach
(c) FAST
(d) Data flow diagram
Q9. Which one is not a step of requirement engineering?

(a)Requirements elicitation
(b) Requirements analysis
(c)Requirements design
(d)Requirements documentation

Q10. Requirements elicitation means

(a)Gathering of requirements
(b) Capturing of requirements
(c)Understanding of requirements
(d)All of the above
 At Amity
…learning never ends
the journey of excellence
continues…

Thank You