Software Requirements Engineering Lecture #13, Slides of Software Engineering

Download Software Requirements Engineering Lecture #13 and more Slides Software Engineering in PDF only on Docsity!

SOFTWARE REQUIREMENTS

ENGINEERING

LECTURE # 13

REFINING THE SYSTEM

DEFINITION

(SOFTWARE REQUIREMENTS

SPECIFICATION)

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

4

Technical Methods for Requirements

Specification

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.

Light Box

Example

6

 The Requirements Specification of the following features have been written

in the natural language (plane) 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.

Pseudo code

[ 2 ]

7  (^) Pseudocode is an artificial and informal language that helps programmers develop algorithms.  (^) In the extreme form, pseudo code consists of combinations of:  (^) Imperative sentences  (^) A limited set, typically not more than 40–50, of "action- oriented" constructed  (^) Decisions represented with a formal I F-ELSE-ENDIF structure  (^) Iterative activities represented with Loops like DO-WHILE or FOR etc. verbs from which the sentences must be

Pseudo

code

8 

Example of pseudo code

If student's grade is greater than or

equal to 60 Print "passed"

else

Print "failed"

end

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

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.

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

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 of the popularity of OOD, OOP and the adoption of UML as a standard becau se  (^) Examples  (^) Class Diagram  (^) Sequence Diagram etc.

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.

Entity-relationship model of

HRMS

14

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.

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Username

(T/F)

F T F T

Password

(T/F)

F F T T

Output (E/H) E E E H

17 Quality Measures of Well

Documented Software

Requirements

Quality

Measures

18

 Correct



Un-

ambiguous



Complete



Consistent



Verifiable



Modifiable

 Traceable

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

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

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

 Completen

ess

of Non-functional

requirements

can be verified by

using

stat

testing techniques ic

like Inspection

in which each non functional

be checked against a checklist requirement. can

 Design Constraints can also be checked through static testing

techniques

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 ― i f 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 canbe checked

through careful manual review and analysis of the

complete set of requirements (static testing techniques)

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

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.

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