1. SOFTWARE REQUIREMENTS ENGINEERING
LECTURE # 13
REFINING THE SYSTEM DEFINITION
(SOFTWARE REQUIREMENTS SPECIFICATION)
S.Vidya,AP/CSE

2. Instructor Information2
Course Instructor: Engr. Ali Javed
Assistant Professor
Department of Software Engineering
U.E.T Taxila
Website:
 Contact No:
Office hours:
 Monday, 09: :00, Office # 7 S.E.D
Lab Instructor: Engr. Asra, Engr. Sobia

3. Presentation Outline Requirements Specification Writing Requirements3
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
S.Vidya,AP/CSE

4. Technical Methods for Requirements Specification4
Technical Methods for Requirements Specification
S.Vidya,AP/CSE

5. Technical Methods for Requirements Specification5
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.
S.Vidya,AP/CSE

6. 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.
S.Vidya,AP/CSE

7. 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" constructed
Decisions represented with a formal IF-ELSE-ENDIF structure
Iterative activities represented with Loops like DO-WHILE or FOR etc.
verbs from which the sentences must be
S.Vidya,AP/CSE

8. Pseudo code Example of pseudo code end8
Example of pseudo code
If student's grade is greater than or equal to 60 Print "passed"
else
Print "failed"
end
S.Vidya,AP/CSE

9. Pseudo code Example of pseudo code9
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
S.Vidya,AP/CSE

10. 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.
S.Vidya,AP/CSE

11. Finite state machines Figure 1:: Example of a state transition diagram11
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.
S.Vidya,AP/CSE
Figure 1:: Example of a state transition diagram

12. Object Oriented Modeling12
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
because
Examples
Class Diagram
Sequence Diagram etc.
S.Vidya,AP/CSE

13. 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.
S.Vidya,AP/CSE

14. Entity-relationship model of HRMS14
S.Vidya,AP/CSE

15. Decision Tables and Decision Trees15
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.
S.Vidya,AP/CSE

16. Decision Tables and Decision Trees16
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.
S.Vidya,AP/CSE
Figure 2:: Example of a graphical decision tree

17. Quality Measures of Well Documented Software Requirements17
Quality Measures of Well Documented Software Requirements
S.Vidya,AP/CSE

18. Quality Measures Correct Un-ambiguous Complete Consistent Verifiable18
Correct
Un-ambiguous
Complete
Consistent
Verifiable
Modifiable
Traceable
S.Vidya,AP/CSE

19. Correct Requirements 19
A set of Requirements is Correct if an only if every requirements stated therein represents something required of the system to built A C B
User Needs
Stated Requirements
S.Vidya,AP/CSE

20. Un-Ambiguous Requirements20
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
S.Vidya,AP/CSE

21. Completeness of the Requirements Set21
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 be checked against a checklist.
in which
each non functional requirement can
Design Constraints can also be checked through static testing techniques
S.Vidya,AP/CSE

22. Consistency in the Requirements Set22
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)
S.Vidya,AP/CSE

23. Verifiable Requirement23
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
S.Vidya,AP/CSE

24. Modifiable Requirements Set24
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.
S.Vidya,AP/CSE

25. Traceable Requirements25
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
S.Vidya,AP/CSE

26. Understandable Requirements26
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.
S.Vidya,AP/CSE

27. References 27
Managing Software Requirements: A Use Case Approach, Second Edition By Dean Leffingwell, Don Widrig, Addison- Wesley 1. 2. 3.
S.Vidya,AP/CSE

28. For any query Feel Free to ask28
S.Vidya,AP/CSE