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

Instructor Information 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 Requirements Specification Writing Requirements 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 S.Vidya,AP/CSE

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

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

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

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

Pseudo code Example of pseudo code end 8 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References 27 Managing Software Requirements: A Use Case Approach, Second Edition By Dean Leffingwell, Don Widrig, Addison- Wesley http://www.unf.edu/~broggio/cop3530/3530pseu.htm http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model 1. 2. 3. S.Vidya,AP/CSE

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