Structured Analysis

• It is often been used as a common technique during requirement analysis

• It consists of Focuses on functions/processes and data flowing between
them
• Uses top-down decomposition approach
-Initially see whole the application as a single process and identify inputs,
outputs, users and data sources
-Decompose the process into sub processes, show data flows for them
- Two technics commonly used in SA are Function Decomposition and Data
Flow Diagrams(FDD, DFD) very useful
Structured Methodology
• Once the overall functionality as a single process is decomposed into sub
processes or sub tasks and what kind of data flow exists among them is
identified
• Study existing system: What is done and how it is done
• We then proceed to establish/prepare Physical current DFD – we start by
studying the existing system, identify the sub systems
-Beginning point is the existing system, the DFD produced
corresponds to the current system and corresponds to the physical
view of what is happening in the real world
Structured Methodology
• Convert this DFD to logical DFD
- by removing physical implementation-specific details (what is to be
done rather how it is to be done)
• Define boundary for automation (scope)
• Prepare DFD for proposed system- requires innovation from the
analyst, experience of the analyst, vision (proposed systems is not the
duplication of the existing system it depends on the vision of the user
and the analyst or developer who is assisting the user)
- Incorporate new needs
- Improve work flows (BPR: business process re-engg)
- Introduce efficiency/effectiveness
Requirement Specification Format Document
• Baseline for the development, it’s a contract between the user and
developed
• Based on IEEE Recommendation
• 1. Introduction
1.1 PURPOSE: clearly state purpose of this document (and what is
covered in this document)
1.2 SCOPE: by whom and how it will be used for what purpose
1.3 Definitions: Acronyms, Abbreviations as applicable
1.4 REFERENCES: to other documents
1.5 Overview of Developer’s Responsibilities: In terms of development,
installation, training, maintenance, etc.
Requirement Specification Format
2. GENERAL DESCRIPTION
2.1 PRODUCT PERSPECTIVE: relationship with other products and
principle interfaces
2.2 PRODUCT FUNCTIONS OVERVIEW: general overview of tasks;
including data flow diagrams
2.3 USER CHARACTERISTICS: who they are and what training they
may need
2.4 GENERAL CONSTRAINTS: about schedule, resources, cost, etc.
Requirement Specification Format
3 FUNCTIONAL REQUIREMENT
3.1 INTRODUCTION
3.2 INPUTS
3.3 PROCESSING
3.4 OUTPUTS
We give functional details, we define every function (ex: cancellation of
a ticket function) by giving a brief introduction to this function, inputs,
processing and outputs.
It is really the body of SRS Document.
3.5 …..(repeat similarly for each function)
Requirement Specification Format
4. External Interface Requirements
4.1 User Interfaces: a preliminary user manual giving commands,
screen formats, outputs, error messages, etc. (logical contents
of these components not the layout of the screen, output)
4.2 Hardware Interfaces: with existing as well as new or special
purpose hardware
4.3 Software Interfaces: with other software packages, operating
systems, etc. (railway reservation system may be interfacing with
the accounting packages so that all fund transfer may be handled)
Requirement Specification Format
5. Performance Requirements
Capacity requirements (no of users, no of files(volume of data)),
response time, throughput (in measurable terms)
Ex: Bank Transactions – how long it takes, how many transactions
will be possible over a given period
6. Design Constraints
6.1 Standards Compliance: software development standards as well as
organizational standards (e.g., for reports- regulatory needs,
auditing requirements)
6.2 Hardware Limitations: available machines, operating systems,
storage capacities, etc.
Requirement Specification Format
7. Other Requirements
Possible future extensions
Note:
All sections are not required for all projects.
• It has taken into account various aspects of the software. We can
handover this SRS document to the development/design team. Then
they can convert this specification into a design.
• SRS document needs to detailed and ensure we have collected all
required data put it in the form of a document
• There should be a formal review meeting with the users and users
should sign off that SRS document clearly defined what the software
system needs to do. It is also ensured that the document contains
enough design details required.
 Examples of Bad SRS Documents
• Unstructured Specifications:
• Narrative essay --- one of the worst types of specification
document:
• Difficult to change,

• Difficult to be precise,

• Difficult to be unambiguous,

• Scope for contradictions, etc.

 Examples of Bad SRS
Documents
• Noise:
• Presence of text containing information
irrelevant to the problem.

• Silence:
• Aspects important to proper solution of the
problem are omitted.
 Examples of Bad SRS Documents
• Overspecification:
• Addressing “how to” aspects
• For example, “Library member names should be stored in a
sorted descending order”
• Overspecification restricts the solution space for the
designer.
• Contradictions:
• Contradictions might arise
• if the same thing described at several places in different ways.
 Examples of Bad SRS Documents
• Ambiguity:
• Literary expressions
• Unquantifiable aspects, e.g. “good user interface”
• Forward References:
• References to aspects of problem
• defined only later on in the text.
• Wishful Thinking:
• Descriptions of aspects
• for which realistic solutions will be hard to find.
Suggestions for Writing Good Quality Requirements

• Keep sentences and paragraphs short.

• Use active voice.
• Use proper grammar, spelling, and punctuation.
• Use terms consistently and define them in a
glossary.
• To see if a requirement statement is sufficiently well
defined,
• Read it from the developer’s perspective
Suggestions for Writing Good Quality Requirements

• Split a requirement into multiple sub-

requirements:
• Because each will require separate test cases and because each
should be separately traceable.
• If several requirements are strung together in a paragraph, it is
easy to overlook one during construction or testing.
 SRS Review
• Review done by the Developers along withneeds
the user representatives. Gathering

Analysis
• To verify that SRS confirms to the
actual user requirements Specification

• To detect defects early and correct them. Review

• Review typically done using standard SRS Document

inspection process:
• Checklists.
 A Sample SRS Checklist
• Have response times been specified for functions ?

• Have all the HW, external SW and data interfaces

been defined ?

• Is each requirement testable ?

• Is the initial state of the system defined ?

• Are the responses to exceptional conditions

specified ?
 Representation of complex processing logic

• Decision trees
• Decision tables
 Decision Trees - Get details

- Create record

• Decision trees: - Print bills

New member

• Edges of a decision tree represent

- Get Details
conditions - Update record
User Renewal
input
• Leaf nodes represent actions to be - Print bills

Cancel

performed. - Get Details

- Print Cheque

• A decision tree gives a graphic view Invalid option

- Delete record

of:
- Print error message

• Logic involved in decision making

• Corresponding actions taken.
 Example: LMS
- Get details

• A Library Membership automation

- Create record

- Print bills

New member

Software (LMS) should support the - Get Details

following three options: User

input
Renewal
- Update record

- Print bills

Cancel

• New member,
- Get Details

- Print Cheque

- Delete record

Invalid option

• Renewal,
- Print error message

• Cancel membership.
 Example: LMS
• When the new member option
is selected, - Get details
- Create record
- Print bills
New member

• The software asks details about - Get Details

- Update record
User Renewal

the member: input

Cancel
- Print bills

- Get Details
- Print Cheque
• name, - Delete record
Invalid option

• address,
- Print error message

• phone number, etc.

 Example (cont.)

• If proper information is entered,

• A membership record for the member is created

• A bill is printed for the annual membership charge plus the

security deposit payable.
 Example (cont.)

• If the renewal option is chosen,

• LMS asks the member's name and his
membership number
• checks whether he is a valid member.

• If the name represents a valid member,

• the membership expiry date is updated and the
annual membership bill is printed,
• otherwise an error message is displayed.
 Example (cont.)

• If the cancel membership option is

selected and the name of a valid
member is entered,
• The membership is cancelled,
• A cheque for the balance amount due to the
member is printed
• The membership record is deleted.
 Decision Tree

- Get details
- Create record
- Print bills
New member

- Get Details
User Renewal - Update record
input - Print bills
Cancel
- Get Details
- Print Cheque
- Delete record
Invalid option

- Print error message

 Decision Table

• Decision tables specify:

• Which variables are to be tested
• What actions are to be taken if the conditions are true,
• The order in which decision making is performed.
 Decision Table
• A decision table shows in a tabular form:
• Processing logic and corresponding actions
• Upper rows of the table specify:
• The variables or conditions to be evaluated
• Lower rows specify:
• The actions to be taken when the
corresponding conditions are satisfied.
 Decision Table

• In technical terminology,
• A column of the table is called a rule.
• A rule implies:
• If a condition is true, then execute the corresponding action.
• Conditions
Valid selection NO YES YES YES
New member
Renewal
--
--
YES
NO
NO
YES
NO
NO
Example
Cancellation -- NO NO YES

• Actions
Display error message -- -- --

Ask member's name etc.

Build customer record -- -- --
Generate bill -- --
Ask membership details --
Update expiry date -- -- --
Print cheque -- -- --
Delete record -- -- --
 Comparison
• Both decision tables and decision trees
• Can represent complex program logic.
• Decision trees are easier to read and
understand
• When the number of conditions are small.
• Decision tables help to look at every
possible combination of conditions.