Requirements Analysis and Specification Lecture 3 Dr R

Requirements Analysis and Specification (Lecture 3) Dr. R. Mall 1

Organization of this Lecture z. Brief review of previous lectures z. Introduction z. Requirements analysis z. Requirements specification z. SRS document z. Decision table z. Decision tree z. Summary 2

Requirements Analysis and Specification z. Many projects fail: ybecause they start implementing the system: ywithout determining whether they are building what the customer really wants. 3

Requirements Analysis and Specification z. It is important to learn: yrequirements analysis and specification techniques thoroughly. 4

Requirements Analysis and Specification z. Goals of requirements analysis and specification phase: yfully understand the user requirements yremove inconsistencies, anomalies, etc. from requirements ydocument requirements properly in an SRS document 5

Requirements Analysis and Specification z. Consists of two distinct activities: x. Requirements Gathering and Analysis x. Specification 6

Requirements Analysis and Specification z. The person who undertakes requirements analysis and specification: yknown as systems analyst: ycollects data pertaining to the product yanalyzes collected data: xto understand what exactly needs to be done. ywrites the Software Requirements Specification (SRS) document. 7

Requirements Analysis and Specification z. Final output of this phase: y. Software Requirements Specification (SRS) Document. z. The SRS document is reviewed by the customer. yreviewed SRS document forms the basis of all future development activities. 8

Requirements Analysis z. Requirements analysis consists of two main activities: y. Requirements gathering y. Analysis of the gathered requirements 9

Requirements Analysis z. Analyst gathers requirements through: yobservation of existing systems, ystudying existing procedures, ydiscussion with the customer and end-users, yanalysis of what needs to be done, etc. 10

Requirements Gathering z. If the project is to automate some existing procedures ye. g. , automating existing manual accounting activities, ythe task of the system analyst is a little easier yanalyst can immediately obtain: x input and output formats x accurate details of the operational procedures 11

Requirements Gathering (CONT. ) z. In the absence of a working system, ylot of imagination and creativity are required. z. Interacting with the customer to gather relevant data: yrequires a lot of experience. 12

Requirements Gathering (CONT. ) z. Some desirable attributes of a good system analyst: y. Good interaction skills, yimagination and creativity, yexperience. 13

Analysis of the Gathered Requirements z. After gathering all the requirements: yanalyze it: x. Clearly understand the user requirements, x. Detect inconsistencies, ambiguities, and incompleteness. z. Incompleteness and inconsistencies: yresolved through further discussions with the end-users and the customers. 14

Inconsistent requirement z. Some part of the requirement: y contradicts with some other part. z. Example: y. One customer says turn off heater and open water shower when temperature > 100 C y. Another customer says turn off heater and turn ON cooler when temperature > 100 C 15

Incomplete requirement z. Some requirements have been omitted: ydue to oversight. z. Example: y. The analyst has not recorded: when temperature falls below 90 C xheater should be turned ON xwater shower turned OFF. 16

Analysis of the Gathered Requirements (CONT. ) z. Requirements analysis involves: yobtaining a clear, in-depth understanding of the product to be developed, yremove all ambiguities and inconsistencies from the initial customer perception of the problem. 17

Analysis of the Gathered Requirements (CONT. ) z. It is quite difficult to obtain: ya clear, in-depth understanding of the problem: xespecially if there is no working model of the problem. 18

Analysis of the Gathered Requirements (CONT. ) z. Experienced analysts take considerable time: yto understand the exact requirements the customer has in his mind. 19

Analysis of the Gathered Requirements (CONT. ) z. Experienced systems analysts know often as a result of painful experiences --ywithout a clear understanding of the problem, it is impossible to develop a satisfactory system. 20

Analysis of the Gathered Requirements (CONT. ) z. Several things about the project should be clearly understood by the analyst: y. What is the problem? y. Why is it important to solve the problem? y. What are the possible solutions to the problem? y. What complexities might arise while solving the problem? 21

Analysis of the Gathered Requirements z. Some anomalies and inconsistencies can be very subtle: (CONT. ) yescape even most experienced eyes. y. If a formal model of the system is constructed, xmany of the subtle anomalies and inconsistencies get detected. 22

Analysis of the Gathered Requirements (CONT. ) z. After collecting all data regarding the system to be developed, yremove all inconsistencies and anomalies from the requirements, ysystematically organize requirements into a Software Requirements Specification (SRS) document. 23

Software Requirements Specification z. Main aim of requirements specification: ysystematically organize the requirements arrived during requirements analysis ydocument requirements properly. 24

Software Requirements Specification z. The SRS document is useful in various contexts: ystatement of user needs ycontract document yreference document ydefinition for implementation 25

Software Requirements Specification: A Contract Document z. Requirements document is a reference document. z. SRS document is a contract between the development team and the customer. y. Once the SRS document is approved by the customer, xany subsequent controversies are settled by referring the SRS document. 26

Software Requirements Specification: A Contract Document z. Once customer agrees to the SRS document: ydevelopment team starts to develop the product according to the requirements recorded in the SRS document. z. The final product will be acceptable to the customer: yas long as it satisfies all the requirements recorded in the SRS document. 27

SRS Document (CONT. ) z. The SRS document is known as black-box specification: ythe system is considered as a black box whose internal details are not known. yonly its visible external (i. e. input/output) behavior is documented. Input Data S Output Data 28

SRS Document (CONT. ) z. SRS document concentrates on: ywhat needs to be done ycarefully avoids the solution (“how to do”) aspects. z. The SRS document serves as a contract ybetween development team and the customer. y. Should be carefully written 29

SRS Document (CONT. ) z. The requirements at this stage: ywritten using end-user terminology. z. If necessary: ylater a formal requirement specification may be developed from it. 30

Properties of a good SRS document z. It should be concise yand at the same time should not be ambiguous. z. It should specify what the system must do yand not say how to do it. z. Easy to change. , yi. e. it should be well-structured. z. It should be consistent. z. It should be complete. 31

Properties of a good SRS document (cont. . . ) z. It should be traceable yyou should be able to trace which part of the specification corresponds to which part of the design and code, etc and vice versa. z. It should be verifiable ye. g. “system should be user friendly” is not verifiable 32

SRS Document (CONT. ) z. SRS document, normally contains three important parts: yfunctional requirements, ynonfunctional requirements, yconstraints on the system. 33

SRS Document (CONT. ) z. It is desirable to consider every system: yperforming a set of functions {fi}. y. Each function fi considered as: ytransforming a set of input data to corresponding output data. Input Data fi Output Data 34

Example: Functional Requirement z. F 1: Search Book y. Input: x an author’s name: y. Output: xdetails of the author’s books and the locations of these books in the library. Author Name f 1 Book Details 35

Functional Requirements z. Functional requirements describe: y. A set of high-level requirements y. Each high-level requirement: xtakes in some data from the user xoutputs some data to the user y. Each high-level requirement: xmight consist of a set of identifiable functions 36

Functional Requirements z. For each high-level requirement: yevery function is described in terms of xinput data set xoutput data set xprocessing required to obtain the output data set from the input data set 37

Nonfunctional Requirements z. Characteristics of the system which can not be expressed as functions: xmaintainability, xportability, xusability, etc. 38

Nonfunctional Requirements z. Nonfunctional requirements include: yreliability issues, yperformance issues, yhuman-computer interface issues, y. Interface with other external systems, ysecurity, maintainability, etc. 39

Constraints z. Constraints describe things that the system should or should not do. y. For example, xstandards compliance xhow fast the system can produce results • so that it does not overload another system to which it supplies data, etc. 40

Examples of constraints z. Hardware to be used, z. Operating system yor DBMS to be used z. Capabilities of I/O devices z. Standards compliance z. Data representations yby the interfaced system 41

Organization of the SRS Document z. Introduction. z. Functional Requirements z. Nonfunctional Requirements y. External interface requirements y. Performance requirements z. Constraints 42

Example Functional Requirements z. List all functional requirements ywith proper numbering. z. Req. 1: y. Once the user selects the “search” option, xhe is asked to enter the key words. y. The system should output details of all books xwhose title or author name matches any of the key words entered. x. Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library. 43

Example Functional Requirements z. Req. 2: y. When the “renew” option is selected, xthe user is asked to enter his membership number and password. y. After password validation, xthe list of the books borrowed by him are displayed. y. The user can renew any of the books: xby clicking in the corresponding renew box. 44

Req. 1: z R. 1. 1: y. Input: “search” option, y. Output: user prompted to enter the key words. z R 1. 2: y. Input: key words y. Output: Details of all books whose title or author name matches any of the key words. x. Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library. y. Processing: Search the book list for the keywords 45

Req. 2: z. R 2. 1: y. Input: “renew” option selected, y. Output: user prompted to enter his membership number and password. z. R 2. 2: y. Input: membership number and password y. Output: xlist of the books borrowed by user are displayed. User prompted to enter books to be renewed or xuser informed about bad password y. Processing: Password validation, search books issued to the user from borrower list and display. 46

Req. 2: z. R 2. 3: y. Input: user choice for renewal of the books issued to him through mouse clicks in the corresponding renew box. y. Output: Confirmation of the books renewed y. Processing: Renew the books selected by the in the borrower list. 47

Examples of Bad SRS Documents z. Unstructured Specifications: y. Narrative essay --- one of the worst types of specification document: x. Difficult to change, xdifficult to be precise, xdifficult to be unambiguous, xscope for contradictions, etc. 48

Examples of Bad SRS Documents z. Noise: y. Presence of text containing information irrelevant to the problem. z. Silence: yaspects important to proper solution of the problem are omitted. 49

Examples of Bad SRS Documents z. Overspecification: y. Addressing “how to” aspects y. For example, “Library member names should be stored in a sorted descending order” y. Overspecification restricts the solution space for the designer. z. Contradictions: y. Contradictions might arise xif the same thing described at several places in different ways. 50

Examples of Bad SRS Documents z. Ambiguity: y. Literary expressions y. Unquantifiable aspects, e. g. “good user interface” z. Forward References: y. References to aspects of problem xdefined only later on in the text. z. Wishful Thinking: y. Descriptions of aspects xfor which realistic solutions will be hard to find. 51

Representation of complex processing logic: z. Decision trees z. Decision tables 52

Decision Trees z. Decision trees: yedges of a decision tree represent conditions yleaf nodes represent actions to be performed. z. A decision tree gives a graphic view of: ylogic involved in decision making ycorresponding actions taken. 53

Example: LMS z. A Library Membership automation Software (LMS) should support the following three options: ynew member, yrenewal, ycancel membership. 54

Example: LMS z. When the new member option is selected, ythe software asks details about the member: xname, xaddress, xphone number, etc. 55

Example(cont. ) z. If proper information is entered, ya membership record for the member is created ya bill is printed for the annual membership charge plus the security deposit payable. 56

Example(cont. ) z. If the renewal option is chosen, y. LMS asks the member's name and his membership number xchecks whether he is a valid member. y. If the name represents a valid member, xthe membership expiry date is updated and the annual membership bill is printed, xotherwise an error message is displayed. 57

Example(cont. ) z. If the cancel membership option is selected and the name of a valid member is entered, ythe membership is cancelled, ya cheque for the balance amount due to the member is printed ythe membership record is deleted. 58

Decision Tree - Get details - Create record - Print bills New member User input Renewal Cancel Invalid option - Get Details - Update record - Print bills - Get Details - Print Cheque - Delete record - Print error message 59

Decision Table z. Decision tables specify: ywhich variables are to be tested ywhat actions are to be taken if the conditions are true, ythe order in which decision making is performed. 60

Decision Table z. A decision table shows in a tabular form: yprocessing logic and corresponding actions z. Upper rows of the table specify: ythe variables or conditions to be evaluated z. Lower rows specify: ythe actions to be taken when the corresponding conditions are satisfied. 61

Decision Table z. In technical terminology, ya column of the table is called a rule: y. A rule implies: xif a condition is true, then execute the corresponding action. 62

Example: z Conditions Valid selection NO New member -YES Renewal -NO Cancellation -z Actions Display error message Ask member's name etc. Build customer record -Generate bill -Ask membership details -Update expiry date -Print cheque -Delete record ---- YES NO NO NO YES -- ----- --63

Comparison z. Both decision tables and decision trees ycan represent complex program logic. z. Decision trees are easier to read and understand ywhen the number of conditions are small. z. Decision tables help to look at every possible combination of conditions. 64

Formal Specification z. A formal specification technique is a mathematical method to: yaccurately specify a system yverify that implementation satisfies specification yprove properties of the specification 65

Formal Specification z. Advantages: y. Well-defined semantics, no scope for ambiguity y. Automated tools can check properties of specifications y. Executable specification 66

Formal Specification z. Disadvantages of formal specification techniques: y. Difficult to learn and use y. Not able to handle complex systems 67

Formal Specification z. Mathematical techniques used include: y. Logic-based yset theoretic yalgebraic specification yfinite state machines, etc. 68

Semiformal Specification z. Structured specification languages y. SADT (Structured Analysis and Design Technique) y. PSL/PSA (Problem Statement Language/Problem Statement Analyzer) x. PSL is a semi-formal specification language x. PSA can analyze the specifications expressed in PSL 69

Executable Specification Language z. If specification is expressed in formal language: yit becomes possible to execute the specification to provide a system prototype. z. However, executable specifications are usually slow and inefficient. 70

Executable Specification Language z. Executable specifications only test functional requirements: y. If non-functional requirements are important for some product, xthe utility of an executable specification prototype is limited. 71

4 GLs z 4 GLs (Fourth Generation Languages) are examples of yexecutable specification languages. z 4 GLs are successful ybecause there is a lot of commonality across data processing applications. 72

4 GLs z 4 GLs rely on software reuse ywhere common abstractions have been identified and parameterized. z. Rewriting 4 GL programs in higher level languages: yresult in upto 50% lower memory requirements yalso the programs run upto 10 times faster. 73

Summary z. Requirements analysis and specification yan important phase of software development: yany error in this phase would affect all subsequent phases of development. z. Consists of two different activities: y. Requirements gathering and analysis y. Requirements specification 74

Summary z. The aims of requirements analysis: y. Gather all user requirements y. Clearly understand exact user requirements y. Remove inconsistencies and incompleteness. z. The goal of specification: y systematically organize requirements ydocument the requirements in an SRS document. 75

Summary z. Main components of SRS document: yfunctional requirements ynonfunctional requirements yconstraints z. Techniques to express complex logic: y. Decision tree y. Decision table 76

Summary z. Formal requirements specifications have several advantages. y. But the major shortcoming is that these are hard to use. 77