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

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

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

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 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.

17 Quality Measures of Well

Documented Software

Requirements

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