SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 13

REFINING THE SYSTEM DEFINITION (SOFTWARE REQUIREMENTS SPECIFICATION)

Engr. Ali Javed 10th July, 2013

Instructor Information

Engr. Ali Javed

2

Course Instructor: Engr. Ali Javed

Assistant Professor

Department of Software Engineering

U.E.T Taxila

Email: ali.javed@uettaxila.edu.pk

Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk

Contact No: +92-51-9047747

Office hours:

Monday, 09:00 - 11:00, Office # 7 S.E.D

Lab Instructor: Engr. Asra, Engr. Sobia

Presentation Outline 3

Requirements Specification

Writing Requirements

Modern SRS Package

Software Requirements Specification Template/Package

Technical methods for Requirements Specification

Pseudo code

Finite state machines

Decision trees

Object Oriented Modeling Class Diagram

Sequence Diagram

Entity-relationship models and many others.

Quality Measures of Software Requirements

Engr. Ali Javed

4

Technical Methods for Requirements Specification

Engr. Ali Javed

Technical Methods for Requirements

Specification 5

Technical methods for specifying requirements are appropriate when the

requirement description is too complex for natural language or if you cannot afford

to have the specification misunderstood.

Technical methods include

Pseudo code

Finite state machines

Decision trees

Object Oriented Modeling

Entity-relationship models and many others.

Engr. Ali Javed

Light Box Example 6

The Requirements Specification of the following features have been written in the natural language style, which are::

After On pushed but before Off pushed, system is termed "powered on."

After Off pushed but before On pushed, system is termed "powered off,―

Since most recent On press, if Count has been pressed an odd number of times, Odd shall be lit

Since most recent On press, if Count has been pressed an even number of times, Even shall be lit

If either light burns out, the other light shall flash every 1 second.

Engr. Ali Javed

Pseudo code [2] 7

Pseudocode is an artificial and informal language that helps programmers develop algorithms

An attempt to combine the informality of natural language with the strict syntax and control

structures of a programming language.

In the extreme form, pseudo code consists of combinations of:

Imperative sentences

A limited set, typically not more than 40–50, of "action-oriented" verbs from which the sentences must be

constructed

Decisions represented with a formal IF-ELSE-ENDIF structure

Iterative activities represented with Loops like DO-WHILE or FOR etc.

Engr. Ali Javed

Pseudo code 8

Example of pseudo code

If student's grade is greater than or equal to 60

Print "passed"

else

Print "failed"

end

Engr. Ali Javed

Pseudo code 9

Example of pseudo code

The algorithm for glowing the Even and Odd lit from the Box example is:

Set COUNT (x)=0

FOR each INPUT X (Button Press)

IF COUNT / 2 == 0

THEN SWITCH ON Even Lit

ELSE

SWITCH ON Odd Lit

END

Engr. Ali Javed

Finite state machines 10

Sometimes it's convenient to look the system as a "proposed machine that can be in only

one of a given number of 'states' at any specific time".

In response to an input, such as data entry from the user or an input from an external

device, the machine changes its state and then generates an output or carries out an action.

Both the output and the next state can be determined exclusively on the basis of understanding

the current state and the event that caused the transition.

In that way, a system's behavior can be said to be deterministic; we can mathematically

determine every possible state and, therefore, the outputs of the system, based on any set of

inputs provided.

Engr. Ali Javed

Finite state machines 11

A popular notation for FSMs is the state transition diagram.

In this notation, the boxes represent the state the device is in, and the arrows represent

actions that transition the device to alternative states.

Figure 1 illustrates state transitions for the light box described earlier.

Figure 1:: Example of a state transition diagram Engr. Ali Javed

Object Oriented Modeling 12

If the requirements that must be refined involve a description of the structure and

relationships among entities within the system, it's often beneficial to use Object Oriented

Models to fully describe the behavior of the system

These diagrams are becoming the part of the Requirement Specification document because

of the popularity of OOD, OOP and the adoption of UML as a standard

Examples

Class Diagram

Sequence Diagram etc.

Engr. Ali Javed

Entity-relationship models [3] 13

If the requirements within a set involve a description of the structure and relationships among

data within the system, it's often convenient to represent that information in an entity-relationship

diagram

Entity–relationship model (ER model) is a data model for describing a database in an abstract

way.

Note that the ERD provides a high-level "architectural" view of the data.

ERD has the potential disadvantage of being difficult for a non-technical reader to understand.

Engr. Ali Javed

Entity-relationship model of HRMS 14

Engr. Ali Javed

Decision Tables and Decision Trees 15

It's common to see a requirement that deals with a combination of inputs; different combinations

of those inputs lead to different behaviors or outputs.

Suppose, for example, that we have a system with five inputs—A, B, C, D, and E—and we see a

requirement that starts with a pseudo code-like statement: "If A is true, then if B and C are also

true, generate output X, unless E is true, in which case the required output is Y.―

The combination of IF-THEN-ELSE clauses quickly becomes twisted, especially if, as in this example,

it involves nested IFs.

Typically, non-technical users are not sure that they understand any of it, and nobody is sure

whether all the possible combinations and permutations of A, B, C, D, and E have been covered.

The solution in this case is to list all the combinations of inputs and to describe each one explicitly

in a decision table.

Engr. Ali Javed

16

In our example, if the only permissible values of the inputs are "true" and "false," we have

2^5, or 32, combinations. These can be represented in a table containing 5 rows—one for

each input variable—and 32 columns.

Alternatively, a decision tree can be drawn to portray the same information.

Figure 2:: Example of a graphical decision tree Engr. Ali Javed

Decision Tables and Decision Trees

17

Quality Measures of Well Documented

Software Requirements

Engr. Ali Javed

Quality Measures 18

Correct

Un-ambiguous

Complete

Consistent

Verifiable

Modifiable

Traceable

Engr. Ali Javed

C Stated

Requirements

B A

User Needs

Correct Requirements

A set of Requirements is Correct if an only if every requirements stated therein

represents something required of the system to built

19

Engr. Ali Javed

Un-Ambiguous Requirements 20

A Requirement is unambiguous if an only if it can subject to only one interpretation

Although correctness is obviously a key concern in any requirement, ambiguity often

turns out to be a larger problem

If a statement of requirements can be interpreted differently by the developers,

users and other stakeholders in the project, it’s quite possible to build a system

that’s completely different from what the user had in mind

Engr. Ali Javed

Completeness of the Requirements Set 21

A set of Requirements is complete if an only if it describes all significant

requirements of concern to the user, including requirements associated with the

functionality, performance, design constraints, attributes, or external interfaces.

Completeness of functional requirements can be verified by using Omission testing

which is achieved through Prototyping

Completeness of Non-functional requirements can be verified by using static

testing techniques like Inspection in which each non functional requirement can

be checked against a checklist.

Design Constraints can also be checked through static testing techniques

Engr. Ali Javed

Consistency in the Requirements Set 22

A Requirement set is consistent if an only if no subset of individual requirements

describe within it are in conflict with one another.

The conflicts can take various forms and are visible at various levels of detail.

One part of the requirement can say ―if A occurs then carry out action B, whereas

at another part of the requirements might say,―if A occurs then carry out action C.

Consistency in the Requirements Set can be checked through careful manual

review and analysis of the complete set of requirements (static testing techniques)

Engr. Ali Javed

Verifiable Requirement 23

Requirements must be verifiable or testable

A Requirement is verifiable in the aggregate if an only if each of the component

requirements contained within it is verifiable

It is necessary to define requirements so that we can later test them and determine

whether they were achieved.

It is the responsibility of the testing and quality assurance personnel to create the

appropriate test procedures to carry out the verification once the software has been

developed

Engr. Ali Javed

Modifiable Requirements Set 24

A Requirement is modifiable if an only if its structure and style are such that any changes to the

requirements can be made easily, completely, and consistently, while retaining the existing

structure and style of the set.

This requires that the containing package have minimum redundancy and that it be well organized.

Requirements will be modified, whether anyone likes it or not; the alternative is a frozen

requirements package which is equivalent to a non existing package and a failed project.

Engr. Ali Javed

Traceable Requirements 25

A Requirement is traceable if an only if the origin of each of its component requirements is

clear and if there is a mechanism that makes it feasible to refer to that requirement in future

development efforts.

This means that the requirements are identified with unique numbers or labels

Refers to ability to describe and follow the life of a requirement, in both a forwards and

backwards direction

Requirements traceability information can be kept in traceability tables, each table relating

requirements to one or more aspects of the system

Engr. Ali Javed

Understandable Requirements 26

A Requirement is understandable if both the user and the developer communities are able to

fully understand the individual requirements and the aggregate functionality implied by the set.

Vision document was much abstract and in less technical terms but later on in SRS the document

gets more detailed and the use of the technical terms increases

So the writer needs to understand the vocabulary and culture terms for the audience

To make users understand the document, usecase diagrams or other technical ways just

discussed earlier can be used.

Engr. Ali Javed

References 27

1. Managing Software Requirements: A Use Case Approach, Second Edition By

Dean Leffingwell, Don Widrig, Addison- Wesley

2. http://www.unf.edu/~broggio/cop3530/3530pseu.htm

3. http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

Engr. Ali Javed

For any query Feel Free to ask 28

Engr. Ali Javed